From owner-freebsd-net@freebsd.org Sun Mar 19 09:59:41 2017 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 06430D11255 for ; Sun, 19 Mar 2017 09:59:41 +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 DD09B1BD4 for ; Sun, 19 Mar 2017 09:59:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2J9xe0Q000722 for ; Sun, 19 Mar 2017 09:59:40 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Sun, 19 Mar 2017 09:59:41 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: julian@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: 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.23 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, 19 Mar 2017 09:59:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 Julian Elischer changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |julian@FreeBSD.org --- Comment #28 from Julian Elischer --- to me it looks like the client is implementing TTCP. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Mar 19 13:13:35 2017 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 E70F0D10FDC for ; Sun, 19 Mar 2017 13:13:35 +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 C9CE210F5 for ; Sun, 19 Mar 2017 13:13:35 +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 v2JDDWHP007475 for ; Sun, 19 Mar 2017 13:13:35 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Sun, 19 Mar 2017 13:13: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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tuexen@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.23 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, 19 Mar 2017 13:13:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #29 from Michael Tuexen --- (In reply to Julian Elischer from comment #28) No, I think even FreeBSD would behave the same as a client if the client do= es socket() connect() send(part1) send(part2) and the third segment from the three way handshake is lost and both segments triggered by the send() calls are lost. It will retransmit the whole data a= fter a timeout. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Mar 19 13:26:15 2017 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 16818D122C2 for ; Sun, 19 Mar 2017 13:26:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0617415B2 for ; Sun, 19 Mar 2017 13:26:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2JDQE3t032286 for ; Sun, 19 Mar 2017 13:26:14 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Sun, 19 Mar 2017 13:26:14 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: slw@zxy.spb.ru 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.23 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, 19 Mar 2017 13:26:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #30 from slw@zxy.spb.ru --- (In reply to Michael Tuexen from comment #29) I am ask again about CLOSE_WAIT state and retransmit lost replay. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Mar 19 14:04:54 2017 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 17446D132C0 for ; Sun, 19 Mar 2017 14:04: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 058A1DE4 for ; Sun, 19 Mar 2017 14:04: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 v2JE4rNL034074 for ; Sun, 19 Mar 2017 14:04:53 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Sun, 19 Mar 2017 14:04:54 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tuexen@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.23 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, 19 Mar 2017 14:04:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #31 from Michael Tuexen --- (In reply to slw from comment #30) The client retransmits the whole data and only acks the SYN. So he hasn't processed the FIN sent by the server. All that has been dropped. So I think= the client is not in CLOSE_WAIT, but in ESTABLISED. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Mar 19 14:13:40 2017 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 31F98D13774 for ; Sun, 19 Mar 2017 14:13:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 21E5818F7 for ; Sun, 19 Mar 2017 14:13:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2JEDe1F055286 for ; Sun, 19 Mar 2017 14:13:40 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Sun, 19 Mar 2017 14:13:40 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: slw@zxy.spb.ru 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.23 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, 19 Mar 2017 14:13:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #32 from slw@zxy.spb.ru --- server CLOSE_WAIT, not client. after application close socket server must wait for acknowledgment sended d= ata and resend it if need. So client retransmit must be routed to existing inpcb in CLOSE_WAIT state a= nd server must resend lost segments and FIN again. Not RST, not droped incoming segments. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Mar 19 17:10:55 2017 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 7BDDCD0F50D for ; Sun, 19 Mar 2017 17:10:55 +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 60C8BFB8 for ; Sun, 19 Mar 2017 17:10:55 +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 v2JHAteZ099150 for ; Sun, 19 Mar 2017 17:10:55 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Sun, 19 Mar 2017 17:10: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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tuexen@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.23 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, 19 Mar 2017 17:10:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #33 from Michael Tuexen --- (In reply to slw from comment #32) The server does socket() listen() accept() read() write() close() which means it reads the first part of the request, sends the response (en error message) and closes the socket. Then the state is FIN-WAIT-1. Then it receives the second part of the request. Since the socket is closed, it responds with a = RST segment and moves the connection to CLOSED. This covers the first TCP connection of the two. After that that the client retransmits the complete request, which results = in establishing the second TCP connection (via the syncookie processing). The server sends a response (the same error message) and closes the socket. So = it is again in FIN-WAIT-1. The FIN gets acked by the client. So the server goes into FIN-WAIT-2. Then the client sends its fin. This is processed by the se= rver and acked. Now the server is in TIME-WAIT. However, the ACK is not received= by the client and the client retransmits the FIN-ACK. So I don't see any end point moving into CLOSE-WAIT state... --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Mar 19 18:03:30 2017 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 E92AAD13354 for ; Sun, 19 Mar 2017 18:03:30 +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 C0A6CECB for ; Sun, 19 Mar 2017 18:03:30 +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 v2JI3UWf067780 for ; Sun, 19 Mar 2017 18:03:30 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Sun, 19 Mar 2017 18:03:30 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: slw@zxy.spb.ru 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.23 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, 19 Mar 2017 18:03:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #34 from slw@zxy.spb.ru --- (In reply to Michael Tuexen from comment #33) Right, FIN_WAIT_1. > Then the state is FIN-WAIT-1. Then it receives the second part of the req= uest. Since the socket is closed, it responds with a RST segment and moves = the connection to CLOSED. I am don't understund this. CLOSING must be only after got FIN. FIN don't received, data in buffer don't ack, what reasson to CLOSING transition and lost data? I mean resend response and FIN again. "If a socket structure is associated with the file structure, soclose is called, f_data is cleared, and any posted error is returned.=20 soclose Function This function aborts any connections that are pending on the socket (i.e., = that have not yet been accepted by a process), waits for data to be transmitted to the foreign sys= tem, and releases the data structures that are no longer needed. soclose is shown in Figure 15.39." "In general, TCP must still process incoming data, so it calls tcpacked to handle incoming acknowledgements, tcpdata to process data in the segment, and tcpswindow to adjust its sending window size. Once= the input has been processed, tcpfin1 checks to see if it should make a state transition. If the TCBF_RDONE bit is set, a FIN has arrived and so has all = data in the sequence up to the FIN. If the TCPF_FIN bit is cleared, an ACK has arrived for the outgoing FIN. Tcpfin1 uses these two bits to determine whet= her to make a transition to the CLOSING, FINWAIT2, or TIMEWAIT states" --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Mar 19 18:32:06 2017 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 304E4D13EAE for ; Sun, 19 Mar 2017 18:32:06 +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 1D51F65F for ; Sun, 19 Mar 2017 18:32:06 +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 v2JIW5EL015024 for ; Sun, 19 Mar 2017 18:32:05 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Sun, 19 Mar 2017 18:32:06 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tuexen@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.23 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, 19 Mar 2017 18:32:06 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #35 from Michael Tuexen --- (In reply to slw from comment #34) > I am don't understund this. CLOSING must be only after got FIN. > FIN don't received, data in buffer don't ack, what reasson to CLOSING tra= nsition > and lost data? I haven't said that the state CLOSING is ever used. Not sure why you bring = this up... > I mean resend response and FIN again. This doesn't happen because NEW data arrives and the application has called close(). So this new data cannot be delivered to the application. The TCP stack has = do drop it. That is why a RST is sent and the connection is moved to CLOSED. I"m not sure which text you are citing, but are you trying to argue that a = TCP stack should drop data and not signal this to the other side? Just letting = the peer think everything is fine? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Mar 19 18:49:16 2017 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 EFBECD13675 for ; Sun, 19 Mar 2017 18:49:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C59F510C8 for ; Sun, 19 Mar 2017 18:49:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2JInGdT048065 for ; Sun, 19 Mar 2017 18:49:16 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Sun, 19 Mar 2017 18:49:16 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: slw@zxy.spb.ru 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.23 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, 19 Mar 2017 18:49:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #36 from slw@zxy.spb.ru --- (In reply to Michael Tuexen from comment #35) > This doesn't happen because NEW data arrives and the application has call= ed close(). So this new data cannot be delivered to the application. The TCP stack has = do drop it. That is why a RST is sent and the connection is moved to CLOSED. I mean in this case RST must send in sequence, w/ ACK set and ACKed recv da= ta. And don't moved to CLOSED. RFC793: " 3.5. Closing a Connection CLOSE is an operation meaning "I have no more data to send." The notion of closing a full-duplex connection is subject to ambiguous interpretation, of course, since it may not be obvious how to treat the receiving side of the connection. We have chosen to treat CLOSE in a simplex fashion. The user who CLOSEs may continue to RECEIVE until he is told that the other side has CLOSED also. Thus, a program could initiate several SENDs followed by a CLOSE, and then continue to RECEIVE until signaled that a RECEIVE failed because the other side has CLOSED. We assume that the TCP will signal a user, even if no RECEIVEs are outstanding, that the other side has closed, so the user can terminate his side gracefully. A TCP will reliably deliver all buffers SENT before the connection was CLOSED so a user who expects no data in return need only wait to hear the connection was CLOSED successfully to know that all his data was received at the destination TCP. Users must keep reading connections they close for sending until the TCP says no more data. Case 1: Local user initiates the close In this case, a FIN segment can be constructed and placed on the outgoing segment queue. No further SENDs from the user will be accepted by the TCP, and it enters the FIN-WAIT-1 state. RECEIVEs are allowed in this state. All segments preceding and including FIN will be retransmitted until acknowledged. When the other TCP has both acknowledged the FIN and sent a FIN of its own, the first TCP can ACK this FIN. Note that a TCP receiving a FIN will ACK but not send its own FIN until its user has CLOSED the connection also. " --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Mar 19 20:17:31 2017 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 1DA12D132B6 for ; Sun, 19 Mar 2017 20:17:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0DB61304 for ; Sun, 19 Mar 2017 20:17:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2JKHUXr078475 for ; Sun, 19 Mar 2017 20:17:30 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Sun, 19 Mar 2017 20:17:31 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tuexen@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.23 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, 19 Mar 2017 20:17:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #37 from Michael Tuexen --- (In reply to slw from comment #36) Please note that RFC 793 defines the CLOSE operation as "I have no more dat= a to send." So this does NOT map to the close() system call in the socket API, but to t= he shutdown(..., SHUT_WR) system call. When doing this, you can continue to receive data. But I guess the server call close(), not shutdown() in the case we are look= ing at. That is why the RST gets send. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Mar 19 21:00:05 2017 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 1224CD1206D for ; Sun, 19 Mar 2017 21:00:05 +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 092211B9E for ; Sun, 19 Mar 2017 21:00:05 +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 v2JL01Xm070714 for ; Sun, 19 Mar 2017 21:00:04 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201703192100.v2JL01Xm070714@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-net@FreeBSD.org Subject: Problem reports for freebsd-net@FreeBSD.org that need special attention Date: Sun, 19 Mar 2017 21:00:04 +0000 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 19 Mar 2017 21:00:05 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- In Progress | 165622 | [ndis][panic][patch] Unregistered use of FPU in k In Progress | 203422 | mpd/ppoe not working with re(4) with revision 285 In Progress | 206581 | bxe_ioctl_nvram handler is faulty New | 204438 | setsockopt() handling of kern.ipc.maxsockbuf limi New | 205592 | TCP processing in IPSec causes kernel panic New | 206053 | kqueue support code of netmap causes panic New | 213410 | [carp] service netif restart causes hang only whe New | 215874 | [patch] [icmp] [mbuf_tags] teach icmp_error() opt Open | 148807 | [panic] "panic: sbdrop" and "panic: sbsndptr: soc Open | 193452 | Dell PowerEdge 210 II -- Kernel panic bce (broadc Open | 194485 | Userland cannot add IPv6 prefix routes Open | 194515 | Fatal Trap 12 Kernel with vimage Open | 199136 | [if_tap] Added down_on_close sysctl variable to t Open | 202510 | [CARP] advertisements sourced from CARP IP cause Open | 206544 | sendmsg(2) (sendto(2) too?) can fail with EINVAL; Open | 211031 | [panic] in ng_uncallout when argument is NULL Open | 211962 | bxe driver queue soft hangs and flooding tx_soft_ 17 problems total for which you should take action. From owner-freebsd-net@freebsd.org Sun Mar 19 21:01:55 2017 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 33F98D12761 for ; Sun, 19 Mar 2017 21:01:55 +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 16A1E6B4 for ; Sun, 19 Mar 2017 21:01:55 +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 v2JL1sZL052654 for ; Sun, 19 Mar 2017 21:01:54 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Sun, 19 Mar 2017 21:01: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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: slw@zxy.spb.ru 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.23 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, 19 Mar 2017 21:01:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #38 from slw@zxy.spb.ru --- (In reply to Michael Tuexen from comment #37) RST+ACK, in sequence of data. And don't do transition from FIN-WAIT-1 until got ACK to FIN. "All segments preceding and including FIN will be retransmitted until acknowledged." This is irrelevant to close()/shutdown(). Only after acknowledged FIN RST may generated and this RST may be w/ ACK set (because this state is "state except SYN-SENT"). --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Mar 19 23:13:23 2017 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 89EB0D13B2C for ; Sun, 19 Mar 2017 23:13:23 +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 79F8C1CF7 for ; Sun, 19 Mar 2017 23:13:23 +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 v2JNDMTd021334 for ; Sun, 19 Mar 2017 23:13:23 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Sun, 19 Mar 2017 23:13:23 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tuexen@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.23 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, 19 Mar 2017 23:13:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #39 from Michael Tuexen --- (In reply to slw from comment #38) The text you are referring to deals with the case that the application has called shutdown(..., SHUT_WR), not close(). So the text doesn't apply here.= .. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 00:47:04 2017 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 BA348D1473F for ; Mon, 20 Mar 2017 00:47:04 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail.karels.net (mail.karels.net [63.231.190.5]) by mx1.freebsd.org (Postfix) with ESMTP id 0CD5E1FE1; Mon, 20 Mar 2017 00:47:03 +0000 (UTC) (envelope-from mike@karels.net) Received: from [10.0.2.11] (mjk-mac2.karels.net [10.0.2.11]) by mail.karels.net (8.15.2/8.15.2) with ESMTP id v2K0kudV066711; Sun, 19 Mar 2017 19:46:57 -0500 (CDT) (envelope-from mike@karels.net) From: "Mike Karels" To: "Andrey V. Elsukov" Cc: freebsd-net@FreeBSD.org, "Alexander V. Chernikov" , "Eugene Grosbein" , karels@FreeBSD.org, "George Neville-Neil" Subject: Re: LLE reference leak in the L2 cache Date: Sun, 19 Mar 2017 19:46:49 -0500 Message-ID: In-Reply-To: <70D2287B-664C-48E4-9E8B-68B574BE6CE6@karels.net> References: <201703140840.v2E8ecH2040827@mail.karels.net> <3a4c5d87-d42e-5615-5d2b-2a8801376600@yandex.ru> <70D2287B-664C-48E4-9E8B-68B574BE6CE6@karels.net> MIME-Version: 1.0 Embedded-HTML: [{"HTML":[1288, 6450], "plain":[454, 3801], "uuid":"7D643933-1464-4AC1-9E8C-EEE1313B6096"}] X-Mailer: MailMate (1.9.6r5347) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 20 Mar 2017 00:47:04 -0000 The context has gotten messy here, so I=E2=80=99m going to break down and= =20 top-post. I started review https://reviews.freebsd.org/D10059 with a fix for the=20 reference-count leak. It changes the semantics so only routes within an in_pcb automatically=20 do L2 caching. I=E2=80=99ll put the tcp_output change for V6 in a separate review when t= his=20 one is done. Andrey, could you try your iperf test again? Thanks, Mike On 14 Mar 2017, at 21:39, Mike Karels wrote: > On 14 Mar 2017, at 3:50, Andrey V. Elsukov wrote: > >> On 14.03.2017 11:40, Mike Karels wrote: >>>> Hi All, >>> >>>> Eugene has reported about the following assertion in the ARP code: >>>> http://www.grosbein.net/freebsd/crash/arp-kassert.txt >>> >>>> After some investigation I found that L2 cache has reference leak,=20 >>>> that >>>> can lead to integer overflow and this assertion. >>>> The one of the ways to reproduce this overflow can be demonstrated=20 >>>> with >>>> simple IP forwarding, when ip_forward() is used (not=20 >>>> ip_tryforward). >>> >>>> I asked olivier@ to reproduce this leak and he got this result: >>>> http://slexy.org/view/s21ql7nA0q >>> >>>> After further investigation I found similar leak in the IPv6 TCP=20 >>>> path. >>>> Simple iperf test shows these results: >>> >>>> # dtrace -n 'fbt::in6_lltable_dump_entry:entry {printf("%d", >>>> args[1]->lle_refcnt);}' >>>> dtrace: description 'fbt::in6_lltable_dump_entry:entry ' matched 1=20 >>>> probe >>>> CPU ID FUNCTION:NAME >>>> 51 18589 in6_lltable_dump_entry:entry 55721 >>>> 51 18589 in6_lltable_dump_entry:entry 1 >>>> 51 18589 in6_lltable_dump_entry:entry 1 >>>> 51 18589 in6_lltable_dump_entry:entry 2 >>>> 38 18589 in6_lltable_dump_entry:entry 111417 >>>> 38 18589 in6_lltable_dump_entry:entry 1 >>>> 38 18589 in6_lltable_dump_entry:entry 1 >>> >>>> -- >>>> WBR, Andrey V. Elsukov >>> >>> Thanks! Could you try the following patch (compiles, but untested): >>> >>> Index: netinet/ip_input.c >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- netinet/ip_input.c (revision 315160) >>> +++ netinet/ip_input.c (working copy) >>> @@ -60,6 +60,7 @@ >>> #include >>> #include >>> #include >>> +#include >>> #include >>> #include >>> #include >>> @@ -1066,6 +1067,8 @@ >>> if (error =3D=3D EMSGSIZE && ro.ro_rt) >>> mtu =3D ro.ro_rt->rt_mtu; >>> RO_RTFREE(&ro); >>> + if (ro.ro_lle) >>> + LLE_FREE(ro.ro_lle); >>> >>> if (error) >>> IPSTAT_INC(ips_cantforward); >> >> I think it would be better to set RT_LLE_CACHE flag only for=20 >> protocols >> that expect presence of L2 cache. I.e. only for the TCP and UDP and=20 >> do >> it in the corresponding protocol output routine, not in the=20 >> ip[6]_output. > > Hmm, let me think about that. TCP and UDP know nothing about L2=20 > cache, > they just use the in_pcb cache which handles it. L3 caching was=20 > removed > earlier by someone who thought of it as a layering violation, which is=20 > why > I tried to keep in the IP layer for the most part. I can probably=20 > find a > way to encapsulate it. > >> >>> Index: netinet6/ip6_forward.c >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- netinet6/ip6_forward.c (revision 315160) >>> +++ netinet6/ip6_forward.c (working copy) >>> @@ -52,6 +52,7 @@ >>> #include >>> #include >>> #include >>> +#include >>> #include >>> #include >>> >>> @@ -431,4 +432,6 @@ >>> out: >>> if (rt !=3D NULL) >>> RTFREE(rt); >>> + if (rin6.ro_lle) >>> + LLE_FREE(rin6.ro_lle); >>> } >> >> I don't think this chunk will help. ip6_forward() doesn't use >> ip6_output(). And IPv6 forwarding is not affected by this problem.=20 >> Look >> at the tcp_output(), it uses local route variable for IPv6 output. > > Ah, right, I obviously didn=E2=80=99t read closely enough earlier. I=E2= =80=99ve=20 > attached > a patch that should fix this, as well as adding route caching for=20 > TCP/IPv6. > >> I'm not sure, but probably SCTP also can be affected by this problem. > > Probably true. SCTP could probably benefit from L2 caching, but this=20 > also > argues for making this more transparent. > > Mike From owner-freebsd-net@freebsd.org Mon Mar 20 02:35:55 2017 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 C8AADD13EEE for ; Mon, 20 Mar 2017 02:35:55 +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 91598FE3 for ; Mon, 20 Mar 2017 02:35:55 +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 v2K2Zrw0014525 for ; Mon, 20 Mar 2017 02:35:55 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 02:35:53 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sepherosa@gmail.com 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.23 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, 20 Mar 2017 02:35:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #40 from Sepherosa Ziehau --- (In reply to Michael Tuexen from comment #33) I think the code that transit the FIN-WAIT-1 to CLOSED is this: /* * If new data are received on a connection after the * user processes are gone, then RST the other end. */ if ((so->so_state & SS_NOFDREF) && tp->t_state > TCPS_CLOSE_WAIT && tlen) { KASSERT(ti_locked =3D=3D TI_RLOCKED, ("%s: SS_NOFDEREF && " "CLOSE_WAIT && tlen ti_locked %d", __func__, ti_locked)= ); INP_INFO_RLOCK_ASSERT(&V_tcbinfo); if ((s =3D tcp_log_addrs(inc, th, NULL, NULL))) { log(LOG_DEBUG, "%s; %s: %s: Received %d bytes of da= ta " "after socket was closed, " "sending RST and removing tcpcb\n", s, __func__, tcpstates[tp->t_state], tlen); free(s, M_TCPLOG); } tp =3D tcp_close(tp); TCPSTAT_INC(tcps_rcvafterclose); rstreason =3D BANDLIM_UNLIMITED; goto dropwithreset; } I don't completely understand the background for the ->CLOSED transition he= re. RFC 793 on page 36 seems to say: If an incoming segment has a security level, or compartment, or precedence which does not exactly match the level, and compartment, and precedence requested for the connection,a reset is sent and connection goes to the CLOSED state. The reset takes its sequence number from the ACK field of the incoming segment. I don't think we actually implemented any security level/compartment/precedence. So do we really need to do the ->CLOSED transition here? Thanks, sephe --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 04:41:03 2017 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 AF443D0CF86 for ; Mon, 20 Mar 2017 04:41:03 +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 9E70A1CB3 for ; Mon, 20 Mar 2017 04:41:03 +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 v2K4f3t9039774 for ; Mon, 20 Mar 2017 04:41:03 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 203735] Transparent interception of ipv6 with squid and pf causes panic Date: Mon, 20 Mar 2017 04:41:03 +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.2-STABLE X-Bugzilla-Keywords: crash, needs-patch, needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kp@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-pf@FreeBSD.org X-Bugzilla-Flags: mfc-stable10? mfc-stable11? 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.23 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, 20 Mar 2017 04:41:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D203735 Kristof Provost changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kp@freebsd.org --- Comment #7 from Kristof Provost --- The good news is this no longer panics, but it still doesn't work. This turns out to be somewhat tricky.=20 The underlying problem is one of address scope. It can be fixed on the receive side with a patch like this: diff --git a/sys/netpfil/pf/pf.c b/sys/netpfil/pf/pf.c index 81290f91b40..d68f81ddf15 100644 --- a/sys/netpfil/pf/pf.c +++ b/sys/netpfil/pf/pf.c @@ -6538,8 +6538,12 @@ done: pd.proto =3D=3D IPPROTO_UDP) && s !=3D NULL && s->nat_rule.ptr = !=3D NULL && (s->nat_rule.ptr->action =3D=3D PF_RDR || s->nat_rule.ptr->action =3D=3D PF_BINAT) && IN6_IS_ADDR_LOOPBACK(&pd.dst->v6)) - m->m_flags |=3D M_SKIP_FIREWALL; + m->m_flags |=3D M_SKIP_FIREWALL | M_FASTFWD_OURS; This tells ip6_input() to skip the scope checks, which seems appropriate. It still fails on the reply packet though, so this doesn't actually fix the whole use case. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 05:10:54 2017 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 A2491D13756 for ; Mon, 20 Mar 2017 05:10: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 922F518FF for ; Mon, 20 Mar 2017 05:10: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 v2K5AsQh021584 for ; Mon, 20 Mar 2017 05:10:54 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 05:10:54 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: karels@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: 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.23 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, 20 Mar 2017 05:10:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 Mike Karels changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |karels@freebsd.org --- Comment #41 from Mike Karels --- Yes, if new data are received after the close, there is no way to deliver d= ata anywhere. If we ack it, the peer may just keep sending data, the window ma= y go closed, and the peer could probe it forever. The appropriate response is an RST. And the connection can't do anything further, so CLOSED is the correct state. It seems to me that this situation is an unavoidable flaw of syn cookies. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 05:38:28 2017 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 92FACD13FBF for ; Mon, 20 Mar 2017 05:38:28 +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 82EA915DB for ; Mon, 20 Mar 2017 05:38:28 +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 v2K5cQ0X084200 for ; Mon, 20 Mar 2017 05:38:28 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 05:38:27 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sepherosa@gmail.com 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.23 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, 20 Mar 2017 05:38:28 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #42 from Sepherosa Ziehau --- (In reply to Mike Karels from comment #41) Would transition from {FIN-WAIT-1,FIN-WAIT-2,CLOSING} to TIME-WAIT for this code segment be more "appropriate" than transition to CLOSED? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 08:11:58 2017 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 CD5B7D14834 for ; Mon, 20 Mar 2017 08:11:58 +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 BCF3F1C19 for ; Mon, 20 Mar 2017 08:11:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2K8Bw49001651 for ; Mon, 20 Mar 2017 08:11:58 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 213015] openvswitch and vnet jails - panic when bridge is destroyed and recreated Date: Mon, 20 Mar 2017 08:11:58 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@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: 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.23 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, 20 Mar 2017 08:11:58 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213015 --- Comment #11 from commit-hook@freebsd.org --- A commit references this bug: Author: ae Date: Mon Mar 20 08:10:58 UTC 2017 New revision: 315624 URL: https://svnweb.freebsd.org/changeset/base/315624 Log: MFC r315192: Ignore ifnet renaming in the bpf ifnet departure handler. PR: 213015 Changes: _U stable/11/ stable/11/sys/net/bpf.c --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 08:13:54 2017 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 47CAFD1493D for ; Mon, 20 Mar 2017 08:13: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 370A91D7B for ; Mon, 20 Mar 2017 08:13: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 v2K8Dsb8007943 for ; Mon, 20 Mar 2017 08:13:54 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 213015] openvswitch and vnet jails - panic when bridge is destroyed and recreated Date: Mon, 20 Mar 2017 08:13:54 +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-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ae@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc resolution assigned_to bug_status 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.23 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, 20 Mar 2017 08:13:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213015 Andrey V. Elsukov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ae@FreeBSD.org Resolution|--- |FIXED Assignee|freebsd-net@FreeBSD.org |ae@FreeBSD.org Status|New |Closed --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 09:06:20 2017 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 9342BD0C85D for ; Mon, 20 Mar 2017 09:06:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 830841C82 for ; Mon, 20 Mar 2017 09:06:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2K96JKk077275 for ; Mon, 20 Mar 2017 09:06:20 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 09:06:20 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: alexandre.martins@stormshield.eu 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.23 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, 20 Mar 2017 09:06:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #43 from Alexandre martins -= -- I tested on Linux. Its TCP stack just continue to reset the connection by increment its sequence. -> SYN (seq 1) <- SYN/ACK (seq 80 ACK 1) -> ACK (seq 1 ACK 81) -> [DATA] (seq 1 ACK 81) <- [DATA 100] (seq 81) <- FIN (delayed/lost/ignored/...) -> [DATA] <- RST (seq 181) -> [DATA] <- RST (seq 182) -> [DATA] <- RST (seq 183) -> [DATA] <- RST (seq 184) -> [DATA] ... --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 09:40:40 2017 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 93910D0CF81 for ; Mon, 20 Mar 2017 09:40:40 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3434818D0 for ; Mon, 20 Mar 2017 09:40:39 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v2K9eaNw074342; Mon, 20 Mar 2017 10:40:36 +0100 (CET) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id A68BCFF2; Mon, 20 Mar 2017 10:40:36 +0100 (CET) Message-ID: <58CFA394.8070901@omnilan.de> Date: Mon, 20 Mar 2017 10:40:36 +0100 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Vincenzo Maffione CC: freebsd-net Subject: Re: [panic] netmap(4) and if_lagg(4) References: <58CBCD7A.8060301@omnilan.de> <58CC23F5.7060507@omnilan.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Mon, 20 Mar 2017 10:40:36 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 20 Mar 2017 09:40:40 -0000 Bezüglich Vincenzo Maffione's Nachricht vom 17.03.2017 22:28 (localtime): > Two things here: > > - We pushed an important fix to stable/11 1-2 months ago, that prevents > panic on emulated netmap mode. Maybe you are still getting that panic > because you are using an older stable/11 image, you should check. > - If you are using "software devices" like if_lagg or even vlan > interfaces, netmap and VALE won't help you a lot, because the drivers > are not patched for netmap (and cannot be) Thank you for your explanation. I'm aware of loosing most advantages, but it gives me the possibility to use different MTUs with one switch/bridge. I'll try to provide more info about the panic this week. Like discussed offlist, the panic happend on a machine with the mentioned fix (latest stable). Perhaps this panic can be fixed, especialy for the vlan children. Otoh., I guess it's NIC (igb) related and em/igb overhaul will hit stable/11 eventually. And afaik, theres no native netmap support anymore :-( So probably resources are better spent on that instead of fixing a panic which doesn't seem to affect anyone else than me. Thanks, -harry From owner-freebsd-net@freebsd.org Mon Mar 20 09:51:05 2017 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 38A35D13276 for ; Mon, 20 Mar 2017 09:51:05 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A4E0A1E70 for ; Mon, 20 Mar 2017 09:51:04 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v2K9p3Db074441; Mon, 20 Mar 2017 10:51:03 +0100 (CET) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id A961EFF6; Mon, 20 Mar 2017 10:51:02 +0100 (CET) Message-ID: <58CFA606.7090306@omnilan.de> Date: Mon, 20 Mar 2017 10:51:02 +0100 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Vincenzo Maffione CC: "freebsd-net@freebsd.org" Subject: Re: Are ./valte-ctl and ./bridge friends or competitors? References: <58CBA727.3040108@omnilan.de> <58CBBF7A.8050604@omnilan.de> <58CC26CF.5050708@omnilan.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Mon, 20 Mar 2017 10:51:03 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 20 Mar 2017 09:51:05 -0000 Bezüglich Vincenzo Maffione's Nachricht vom 18.03.2017 09:29 (localtime): >… >>> Actually, there is pending work on bhyve and netmap, that is going to be >>> merged soon, available at https://github.com/vmaffione/freebsd/ in >>> branch ptnet-head. >>> >>> If you are interested, here there is some information >>> https://wiki.freebsd.org/DevSummit/201609?action= >> AttachFile&do=view&target=20160923-freebsd-summit-ptnet.pdf >>> > AttachFile&do=view&target=20160923-freebsd-summit-ptnet.pdf> >>> together with bhyve cmdlines. Congratulations, nice work and presentation :-) … >> So I'm a bit lost regarding furhter decisions. My prefered if_lagg(4) >> setup doesn't work with netmap at the moment, if_bridge(4) has >> in-house-overhead and forces me to either drop jumbo frames completely >> or use 9k MTU for any bridge member. >> Will look into openvSwitch. Or better get some card providing VFs? >> Or wait the ptnet merge and check if I can deploy my desired setup then? >> And, I want to keep TSO and HWVLAN_TAG on the host interfaces… >> >> > It depends on your requirements, in terms of connectivity between VMs and > NICs and required performance (for a given workload, e.g. average > packet-size, average packet rate, etc.). > If you really want TSO an other offloadings on the phyisical NIC, then you > cannot use that NIC in netmap mode (e.g. attaching it to VALE). So to summarize for newbies exploring netmap(4) world in combination with physical uplinks and virtual interfaces, it's important to do the following uplink NIC configuration (ifconfig(8)): -rxcsum -txcsum -rxcsum6 -txcsum6 -tso -lro promisc I guess vlanhwtag, vlanhwfilter and vlanhwtso don't interfere, do they? Thanks, -harry From owner-freebsd-net@freebsd.org Mon Mar 20 10:15:09 2017 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 7BD18D13A63 for ; Mon, 20 Mar 2017 10:15: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 6108BC85 for ; Mon, 20 Mar 2017 10:15: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 v2KAF95s018426 for ; Mon, 20 Mar 2017 10:15:09 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217606] Bridge stops working after some days Date: Mon, 20 Mar 2017 10:15: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: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: aiko@torrentkino.de 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: 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.23 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, 20 Mar 2017 10:15:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217606 --- Comment #12 from Aiko Barz --- I am sorry=E2=80=A6 We had a spontaneous failover[1] at Saturday once more. Since I installed t= he latest firmware blobs for every piece of hardware, what can I do now? I don= 't find anything in the logs. It just stops passing traffic=E2=80=A6 So long, Aiko [1]: The failover gets handled by a different system. Those two bridges act alone without knowledge of each other. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 10:39:02 2017 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 0D41AD13F9F for ; Mon, 20 Mar 2017 10:39:02 +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 E6C2A16E1 for ; Mon, 20 Mar 2017 10:39:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2KAd1wV072494 for ; Mon, 20 Mar 2017 10:39:01 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217862] ixgbe broken after 315333 Date: Mon, 20 Mar 2017 10:39:02 +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-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: lampa@fit.vutbr.cz 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: 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.23 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, 20 Mar 2017 10:39:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217862 --- Comment #2 from lampa@fit.vutbr.cz --- Fix is ok, can be closed. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 11:17:52 2017 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 7D470D13CC6 for ; Mon, 20 Mar 2017 11:17: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 6D281CA8 for ; Mon, 20 Mar 2017 11:17: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 v2KBHpZ1077548 for ; Mon, 20 Mar 2017 11:17:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217606] Bridge stops working after some days Date: Mon, 20 Mar 2017 11:17:52 +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-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: fk@fabiankeil.de 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.23 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, 20 Mar 2017 11:17:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217606 Fabian Keil changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fk@fabiankeil.de --- Comment #13 from Fabian Keil --- There's a uma-related regression in FreeBSD 11 that can result in somewhat similar symptoms. For details see #209680. You could check the vmstat -z output and try the patch: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209680#c2 which reverts some of the problematic commits (only in the tcp code, though). Apparently some of the other uma-consumers are affected as well: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209680#c10 and I'm wondering if if_bridge is one of them. You could try if it makes a difference if you let if_bridge set the UMA_ZONE_NOFREE flag and preallocate a couple of items. >From your report it isn't obvious to me that your problem is uma-related so if you have other leads you may want to investigate them first. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 11:50:42 2017 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 7347DD1458C for ; Mon, 20 Mar 2017 11:50:42 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::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 293C81C30 for ; Mon, 20 Mar 2017 11:50:42 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-ot0-x22d.google.com with SMTP id x37so130506057ota.2 for ; Mon, 20 Mar 2017 04:50:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sNPLlaP9TXAH7+iFn6N8rJN9kSyyOOfOtm+WQQ3C53w=; b=H063e6bM+gEzSwAd15hDzkopsKI9oA4d+5tGSecRiY9B1vHrVCyTY4XJUAgvHvWD9T 3A+c1erAzHv/ExUcjjs39OKlJtZA/uAJpk2fCemLdOTK+70hdDY5e1hPMmcDOlLGwCT0 jb1bznm9GWJ/8KLUlC1noJHKN29KYweYh4nkF52q/mSEE5emb0BBDnMPqDwYyI5SfQwo 5g5DBpuVXsnsn3s5hPjjDPRhK5oU3cxdmb1gM6FMdbYIi/Jng1vtkk0iO/P42MOBQZ9/ oSe0E7r8YEqaiZsQVlyfb9AQqA4IRN/cSr6R7oUmqckqh18N+BH4CEE0QjezmEKWEyOc +QhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sNPLlaP9TXAH7+iFn6N8rJN9kSyyOOfOtm+WQQ3C53w=; b=MobzEG31n1XnwdZ38hQneXyDHOOeXVJI4gLwbbdCBUZXNHMdkgIHTcy/q2htspdmXh H6xeX6btNKMa3JZFdk3XkvQ76m/UDzytQFkZJ80ZMDTSXWstqH7SxFKiTkOPM5W0bXzq e33MCCWMHh4e9Wl7X4qxH/R2XBYSbn2TLOllvBlANKRKDI5nNjRDXy0nOfbLvyw0/aG7 G+RltSgJszT+vt9u8e+JG2XQtt0/vYFjPRIq8fSMQV7p/VeJYkt9/Zmpaakqs7+mf4xs DMXoKf+UH/ZtvIiXqWwcZM3B5VXaK5HFwk5BB4LZFQefQEPLLbkRZFIIUygkqnBsTGw+ 1ojw== X-Gm-Message-State: AFeK/H1otH96JSIaE1B99XXdtqo0hvR2yp1hZsSmqY4tbfj26DogLAXbj/gJFoR1tBniqdYqvPxEsqlETNUjWA== X-Received: by 10.157.11.28 with SMTP id a28mr17521314ota.121.1490010641429; Mon, 20 Mar 2017 04:50:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.50.45 with HTTP; Mon, 20 Mar 2017 04:50:40 -0700 (PDT) In-Reply-To: <58CFA606.7090306@omnilan.de> References: <58CBA727.3040108@omnilan.de> <58CBBF7A.8050604@omnilan.de> <58CC26CF.5050708@omnilan.de> <58CFA606.7090306@omnilan.de> From: Vincenzo Maffione Date: Mon, 20 Mar 2017 12:50:40 +0100 Message-ID: Subject: Re: Are ./valte-ctl and ./bridge friends or competitors? To: Harry Schmalzbauer Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 20 Mar 2017 11:50:42 -0000 2017-03-20 10:51 GMT+01:00 Harry Schmalzbauer : > Bez=C3=BCglich Vincenzo Maffione's Nachricht vom 18.03.2017 09:29 (localt= ime): > >=E2=80=A6 > >>> Actually, there is pending work on bhyve and netmap, that is going to > be > >>> merged soon, available at https://github.com/vmaffione/freebsd/ in > >>> branch ptnet-head. > >>> > >>> If you are interested, here there is some information > >>> https://wiki.freebsd.org/DevSummit/201609?action=3D > >> AttachFile&do=3Dview&target=3D20160923-freebsd-summit-ptnet.pdf > >>> >> AttachFile&do=3Dview&target=3D20160923-freebsd-summit-ptnet.pdf> > >>> together with bhyve cmdlines. > > Congratulations, nice work and presentation :-) > Thanks! > > =E2=80=A6 > >> So I'm a bit lost regarding furhter decisions. My prefered if_lagg(4) > >> setup doesn't work with netmap at the moment, if_bridge(4) has > >> in-house-overhead and forces me to either drop jumbo frames completely > >> or use 9k MTU for any bridge member. > >> Will look into openvSwitch. Or better get some card providing VFs? > >> Or wait the ptnet merge and check if I can deploy my desired setup the= n? > >> And, I want to keep TSO and HWVLAN_TAG on the host interfaces=E2=80=A6 > >> > >> > > It depends on your requirements, in terms of connectivity between VMs a= nd > > NICs and required performance (for a given workload, e.g. average > > packet-size, average packet rate, etc.). > > If you really want TSO an other offloadings on the phyisical NIC, then > you > > cannot use that NIC in netmap mode (e.g. attaching it to VALE). > > So to summarize for newbies exploring netmap(4) world in combination > with physical uplinks and virtual interfaces, it's important to do the > following uplink NIC configuration (ifconfig(8)): > -rxcsum -txcsum -rxcsum6 -txcsum6 -tso -lro promisc > Exactly. This is mentioned at the very end of netmap(4): "netmap does not use features such as checksum offloading, TCP segmentation offloading, encryption, VLAN encapsulation/decapsulation, etc. When using netmap to exchange packets with the host stack, make sure to disable these features." But it is probably a good idea to add these example ifconfig instructions somewhere (man page or at least the README in the netmap repo). > > I guess vlanhwtag, vlanhwfilter and vlanhwtso don't interfere, do they? > Well, I think they interfere: if you receive a tagged packet and the NIC strips the tag and puts it in the packet descriptor, then with netmap you will see the untagged packet, and you wouldn't have a way to see the tag. Cheers, Vincenzo > > Thanks, > > -harry > --=20 Vincenzo Maffione From owner-freebsd-net@freebsd.org Mon Mar 20 12:21:10 2017 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 6142DD13597 for ; Mon, 20 Mar 2017 12:21:10 +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 5145F1143 for ; Mon, 20 Mar 2017 12:21:10 +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 v2KCLA72043656 for ; Mon, 20 Mar 2017 12:21:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 12:21:10 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tuexen@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.23 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, 20 Mar 2017 12:21:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #44 from Michael Tuexen --- (In reply to Alexandre martins from comment #43) Please share a .pcap file. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 12:45:53 2017 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 D41ACD13FF4 for ; Mon, 20 Mar 2017 12:45:53 +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 BC0311DF0 for ; Mon, 20 Mar 2017 12:45:53 +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 v2KCjrdm009097 for ; Mon, 20 Mar 2017 12:45:53 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 12:45:53 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: slw@zxy.spb.ru 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.23 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, 20 Mar 2017 12:45:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #45 from slw@zxy.spb.ru --- (In reply to Alexandre martins from comment #43) Can you do additional tests in this setup? 1. Lost DATA from server, FIN and first RST 2. Lost DATA from server, FIN and TWO first RST --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 13:42:56 2017 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 25F8ED14D45 for ; Mon, 20 Mar 2017 13:42: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 0F9091997 for ; Mon, 20 Mar 2017 13:42: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 v2KDgs4c060264 for ; Mon, 20 Mar 2017 13:42:55 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 13:42:54 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: alexandre.martins@stormshield.eu 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: 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.23 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, 20 Mar 2017 13:42:56 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #46 from Alexandre martins -= -- Created attachment 180996 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D180996&action= =3Dedit Linux server, short delay between header and data Capture using the scapy script. A short delay (<200ms) is done between header and data --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 13:44:06 2017 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 7DC01D14DF3 for ; Mon, 20 Mar 2017 13:44:06 +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 6D66B1AAE for ; Mon, 20 Mar 2017 13:44:06 +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 v2KDi5Q4061901 for ; Mon, 20 Mar 2017 13:44:06 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 13:44:06 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: alexandre.martins@stormshield.eu 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: 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.23 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, 20 Mar 2017 13:44:06 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #47 from Alexandre martins -= -- Created attachment 180997 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D180997&action= =3Dedit Linux server, long delay between header and data Capture using the scapy script. A short delay (>400ms) is done between header and data We can see that the Linux stack don't do the same thing ... --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 14:02:01 2017 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 168ACD13326 for ; Mon, 20 Mar 2017 14:02:01 +0000 (UTC) (envelope-from v.maffione@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 C95DD7EB for ; Mon, 20 Mar 2017 14:02:00 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-oi0-x229.google.com with SMTP id r203so18244797oib.3 for ; Mon, 20 Mar 2017 07:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UZXac3X8WkbIgIDGNGomPsIehQsoBLuRA6QFoFSVcMU=; b=dfIhcwLRlLeuJcUMgnypP+JwS3ER/w2lVKr+7dhOKPCkhHtgmziFNobyotCURKfLl5 X8A3Cy84VPBY46VcAiTICkdzpa57HQ62/1nhG52SdDeoIJDMhzFGg7zQZutwyChF6yRg tBmkw3gLzho93yACmPlgbcxs8sy7TlF/Jw+lzwIexfeIkLJj3++z+fhazjVYLPoILgI7 Ae38zjKgf6CJdYyPtZc/77lt3UdiJaUNIRO2GWyLV9vZs/PAZJADLU+dDqcCzgZys6pz ZbEykET+GLkO0ryal9dywhQNWA5hnQmVttsiFxKZSrOkiffVe0Pnq8nAW29Tk/I3z7sp 8YLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UZXac3X8WkbIgIDGNGomPsIehQsoBLuRA6QFoFSVcMU=; b=jxmiKVdPwbe+/55UeU9Qiitbp1BDMJ940OO8MDfoJuRK1BBUOBxV12p0ysfiFcN7yd J/xmkBWNG4MP11CObXFvJAf2ZVr7nJM8opJn+2mruQ9tWX7TGVoT4JTXmHOQZhkCS3Yh go0wcUb6VFSDEgm0QbhqK2WJfSlpGSDvGk6O1LPRoSOA0wNcT5hzJ4Zv3p6o6nJp40Ih 33VfNXyfT3qMLlOlnCQ4wY/CZ8PCKd2omYQdulJu+3lTYK7pMhLWG+RNrUtPPjkue1Co wpzxyqsTPJPkUEkFJwLPmYa45bx7vvzLksV6L9CR40XVY85K43gijdXbzz3tB4NRvvt+ AI6Q== X-Gm-Message-State: AFeK/H2Ou/B31M3Q91T5U3p8NNP1PpKY0K7wowvwsus3T7C72qFmmXb9VIxQoDcbm9Gb8x1OplemOcXfcBGiyg== X-Received: by 10.202.68.132 with SMTP id r126mr13159651oia.32.1490018520081; Mon, 20 Mar 2017 07:02:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.50.45 with HTTP; Mon, 20 Mar 2017 07:01:59 -0700 (PDT) In-Reply-To: <58CFA394.8070901@omnilan.de> References: <58CBCD7A.8060301@omnilan.de> <58CC23F5.7060507@omnilan.de> <58CFA394.8070901@omnilan.de> From: Vincenzo Maffione Date: Mon, 20 Mar 2017 15:01:59 +0100 Message-ID: Subject: Re: [panic] netmap(4) and if_lagg(4) To: Harry Schmalzbauer Cc: freebsd-net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 20 Mar 2017 14:02:01 -0000 2017-03-20 10:40 GMT+01:00 Harry Schmalzbauer : > Bez=C3=BCglich Vincenzo Maffione's Nachricht vom 17.03.2017 22:28 (localt= ime): > > Two things here: > > > > - We pushed an important fix to stable/11 1-2 months ago, that prevents > > panic on emulated netmap mode. Maybe you are still getting that panic > > because you are using an older stable/11 image, you should check. > > - If you are using "software devices" like if_lagg or even vlan > > interfaces, netmap and VALE won't help you a lot, because the drivers > > are not patched for netmap (and cannot be) > > Thank you for your explanation. I'm aware of loosing most advantages, > but it gives me the possibility to use different MTUs with one > switch/bridge. > > > I'll try to provide more info about the panic this week. Like discussed > offlist, the panic happend on a machine with the mentioned fix (latest > stable). > Perhaps this panic can be fixed, especialy for the vlan children. > Ok, so if you create a vlan on an interface, and use netmap over the vlan, you get a deterministic crash? Does the crash happen when you start transmitting, receiving or both? > Otoh., I guess it's NIC (igb) related and em/igb overhaul will hit > stable/11 eventually. And afaik, theres no native netmap support > anymore :-( > So probably resources are better spent on that instead of fixing a panic > which doesn't seem to affect anyone else than me. > There is an overhaul in progress, yes, but netmap support is going to be restored. > > Thanks, > > -harry > --=20 Vincenzo Maffione From owner-freebsd-net@freebsd.org Mon Mar 20 14:17:59 2017 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 83D05D138AE for ; Mon, 20 Mar 2017 14:17:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 73AB512DC for ; Mon, 20 Mar 2017 14:17:59 +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 v2KEHwKO049269 for ; Mon, 20 Mar 2017 14:17:59 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 14:17:59 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: slw@zxy.spb.ru 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.23 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, 20 Mar 2017 14:17:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #48 from slw@zxy.spb.ru --- (In reply to Mike Karels from comment #41) > Yes, if new data are received after the close, there is no way to deliver= data anywhere. If we ack it, the peer may just keep sending data, the win= dow may go closed, and the peer could probe it forever. The appropriate res= ponse is an RST. And the connection can't do anything further, so CLOSED is= the correct state. RFC requried to retransmit data until acked. No matter how to application c= lose socket (do you realy mean this retransmit must be depeneds on apllication reading socket? this is strange and irrational). Yes, ack all received data= may be not good. Not sure. May be don't ack it before got ACK to FIN? And only after ACKed FIN generate RST+ACK (RST MUST be w/ ACK, w/o correct ACK RST ignored by Linux and Windows, I am check this before. And accepte such RST = for live connection by FreeBSD is bug, violate RFC and security issuse). Generated RST before ACKed FIN don't allow to make sure about "All segments preceding and including FIN will be retransmitted until acknowledged." > It seems to me that this situation is an unavoidable flaw of syn cookies. Please, ignore syn cookies here. See only to "last data chunk not acked, FIN lost". --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 14:35:48 2017 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 4AE49D13E37 for ; Mon, 20 Mar 2017 14:35:48 +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 3AC221C16 for ; Mon, 20 Mar 2017 14:35:48 +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 v2KEZlwc093713 for ; Mon, 20 Mar 2017 14:35:48 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 14:35:48 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tuexen@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: 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.23 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, 20 Mar 2017 14:35:48 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #49 from Michael Tuexen --- Created attachment 180999 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D180999&action= =3Dedit packetdrill script to show how Linux handles data on closed socket --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 14:37:49 2017 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 95025D13EE2 for ; Mon, 20 Mar 2017 14:37:49 +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 84FF51D10 for ; Mon, 20 Mar 2017 14:37:49 +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 v2KEbmtE096162 for ; Mon, 20 Mar 2017 14:37:49 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 14:37:49 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tuexen@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.23 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, 20 Mar 2017 14:37:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #50 from Michael Tuexen --- (In reply to Michael Tuexen from comment #49) I have added a packetdrill script to show how Linux handles the reception of data when the user called closed before the data is received. It does the s= ame a FreeBSD (as I would expect): It sends a reset and closes the socket. If t= he peer retransmits the data, a new RST is generated. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 14:46:24 2017 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 4E16BD146EE for ; Mon, 20 Mar 2017 14:46:24 +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 3E0D23FD for ; Mon, 20 Mar 2017 14:46:24 +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 v2KEkNWA014912 for ; Mon, 20 Mar 2017 14:46:24 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 14:46: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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: slw@zxy.spb.ru 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.23 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, 20 Mar 2017 14:46:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #51 from slw@zxy.spb.ru --- (In reply to Michael Tuexen from comment #50) =3D=3D=3D +0.00 write(4, ..., 395) =3D 395 +0.00 > P. 1:396(395) ack 46 win 58 +0.00 close(4) =3D 0 +0.00 > F. 396:396(0) ack 46 win 58 +0.00 < P. 46:54(8) ack 396 win 8192 =3D=3D=3D this is different case: remote side ACK response from server. for correct comparation "+0.00 > P. 1:396(395) ack 46 win 58" must be lost --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 14:54:40 2017 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 1E9D9D14A62 for ; Mon, 20 Mar 2017 14:54:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0E8F6AF6 for ; Mon, 20 Mar 2017 14:54:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2KEsdap035564 for ; Mon, 20 Mar 2017 14:54:39 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 14:54:39 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tuexen@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.23 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, 20 Mar 2017 14:54:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #52 from Michael Tuexen --- I ran the script on Ubuntu 16.10 (kernel 4.8). Not sure if the behaviour depends on the version... @Alexandre: Can you figure out whether the server calls shutdown() or close= ()? Not sure why the behaviour is different. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 14:59:20 2017 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 D3810D14DAF for ; Mon, 20 Mar 2017 14:59:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C3636EC6 for ; Mon, 20 Mar 2017 14:59:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2KExK0T041828 for ; Mon, 20 Mar 2017 14:59:20 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 14:59:20 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tuexen@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: 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.23 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, 20 Mar 2017 14:59:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #53 from Michael Tuexen --- Created attachment 181000 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D181000&action= =3Dedit Updated packetdrill script to show how Linux handled data on closed socket This corrects the bug in the script that the data from the server was acked. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 15:00:05 2017 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 6B44AD14E38 for ; Mon, 20 Mar 2017 15:00:05 +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 5B506FA5 for ; Mon, 20 Mar 2017 15:00:05 +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 v2KF04RS044355 for ; Mon, 20 Mar 2017 15:00:05 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 15:00:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tuexen@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.23 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, 20 Mar 2017 15:00:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #54 from Michael Tuexen --- (In reply to slw from comment #51) Right. I updated the script. The behaviour hasn't changed. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 15:01:18 2017 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 7FE8AD14EDA for ; Mon, 20 Mar 2017 15:01:18 +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 6F72E1127 for ; Mon, 20 Mar 2017 15:01:18 +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 v2KF1Hau099722 for ; Mon, 20 Mar 2017 15:01:18 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 15:01:18 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: alexandre.martins@stormshield.eu 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.23 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, 20 Mar 2017 15:01:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #55 from Alexandre martins -= -- (In reply to Michael Tuexen from comment #52) In all of my tests, the server call close() because of the error. I didn't check the shutdown(.., SHUT_WR) case. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 15:09:42 2017 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 91BB7D130DE for ; Mon, 20 Mar 2017 15:09:42 +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 81B8D1531 for ; Mon, 20 Mar 2017 15:09:42 +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 v2KF9gBw026275 for ; Mon, 20 Mar 2017 15:09:42 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 15:09:42 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: slw@zxy.spb.ru 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.23 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, 20 Mar 2017 15:09:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #56 from slw@zxy.spb.ru --- (In reply to Michael Tuexen from comment #54) 1. Linux generated RST w/ ACK. socket don't moved to CLOSED state? 2. This is also wrong behavior: server try to reset connection, client igno= re this (by wrong ACK on RST packet). Also, data is lost. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 15:29:31 2017 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 8EBA4D13626 for ; Mon, 20 Mar 2017 15:29:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7EC0D1E3E for ; Mon, 20 Mar 2017 15:29:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2KFTUag028076 for ; Mon, 20 Mar 2017 15:29:31 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 15:29:31 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tuexen@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.23 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, 20 Mar 2017 15:29:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #57 from Michael Tuexen --- (In reply to Alexandre martins from comment #55) Great. That is what I'm also testing. It seems that the trace with the long delay shows the same as my testing. However, the trace with a short delay is different. Not sure why. And I don't see a reason why they should be different... --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 15:32:23 2017 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 ADB06D13862 for ; Mon, 20 Mar 2017 15:32:23 +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 9DC051EE for ; Mon, 20 Mar 2017 15:32:23 +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 v2KFWNQJ042003 for ; Mon, 20 Mar 2017 15:32:23 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 15:32:23 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tuexen@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.23 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, 20 Mar 2017 15:32:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #58 from Michael Tuexen --- (In reply to slw from comment #56) > 1. Linux generated RST w/ ACK. socket don't moved to CLOSED state? Linux generates a RST, not a RST-ACK. I guess it is moved to the CLOSED sta= te. Can't check. > 2. This is also wrong behavior: server try to reset connection, client ig= nore > this (by wrong ACK on RST packet). Also, data is lost. You are right, user data is lost (the second part of the request). There is= no way around that. since the user closed the socket before the data arrived. That= is why the server sends a RST. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 15:35:22 2017 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 7BA6CD1392A for ; Mon, 20 Mar 2017 15:35:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6BAA0350 for ; Mon, 20 Mar 2017 15:35:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2KFZLgJ047275 for ; Mon, 20 Mar 2017 15:35:22 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 15:35:22 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: slw@zxy.spb.ru 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.23 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, 20 Mar 2017 15:35:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #59 from slw@zxy.spb.ru --- (In reply to Michael Tuexen from comment #58) > Linux generates a RST, not a RST-ACK.=20 May bad, yes > You are right, user data is lost (the second part of the request). There = is no way around that. since the user closed the socket before the data arr= ived. That is why the server sends a RST. No, different data: server response. And no reasson to not deliver/resend i= t to client. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 15:43:06 2017 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 C1C50D13BFA for ; Mon, 20 Mar 2017 15:43:06 +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 B1B11AE5 for ; Mon, 20 Mar 2017 15:43:06 +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 v2KFh6kn066857 for ; Mon, 20 Mar 2017 15:43:06 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 15:43:06 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tuexen@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.23 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, 20 Mar 2017 15:43:06 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #60 from Michael Tuexen --- (In reply to slw from comment #59) > No, different data: server response. And no reasson to not deliver/resend > it to client. Well, the server knows that he has to drop incoming data, since the applica= tion has closed the socket and there is new data to deliver. I guess we agree on tha= t. The reaction is to let the peer now as soon as possible that something went wrong. I guess this is what we might no agree upon.=20 However this is the reason why the server sends a RST without trying to retransmit data he has sent but which has not been acknowledged by the peer. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 15:58:57 2017 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 60248D141B2 for ; Mon, 20 Mar 2017 15:58:57 +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 5007512C9 for ; Mon, 20 Mar 2017 15:58:57 +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 v2KFwum9095036 for ; Mon, 20 Mar 2017 15:58:57 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 15:58:57 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: slw@zxy.spb.ru 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.23 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, 20 Mar 2017 15:58:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #61 from slw@zxy.spb.ru --- (In reply to Michael Tuexen from comment #60) > Well, the server knows that he has to drop incoming data, since the appli= cation > has closed the socket and there is new data to deliver. I guess we agree = on that. Agree. > The reaction is to let the peer now as soon as possible that something we= nt wrong. > I guess this is what we might no agree upon.=20 > However this is the reason why the server sends a RST without trying to r= etransmit > data he has sent but which has not been acknowledged by the peer. Now server have several task: 1. retransmit his response and (optional) FIN 2. let the peer that something went wrong. I am don't see ideal answer to this. Send RST now may be don't allow to be sure about acknowledged server data. = Not sure. Need some tests: retransmit data, retransmit FIN, send RST+ACK, SEQ=3DFIN.SEQ+1, see reaction from remote: got ACK to data? got ack to FIN? In any cases retransmit is mandatory, by RFC. Some tricks to discard client data may be used here (zero window? silent discard and only SEQ/ACK analize? ACk and discard? send RST+ACK (as you see, RST w/o ACK ignored by client) a= fter client acknowledged server data? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 16:02:00 2017 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 8F723D142B7 for ; Mon, 20 Mar 2017 16:02:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7F6871563 for ; Mon, 20 Mar 2017 16:02:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2KG1xii019857 for ; Mon, 20 Mar 2017 16:02:00 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217862] ixgbe broken after 315333 Date: Mon, 20 Mar 2017 16:01:59 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.3-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: erj@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution 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.23 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, 20 Mar 2017 16:02:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217862 Eric Joyner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |FIXED --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 16:19:49 2017 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 70EBCD1487D for ; Mon, 20 Mar 2017 16:19:49 +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 60E6A1089 for ; Mon, 20 Mar 2017 16:19:49 +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 v2KGJmM3056271 for ; Mon, 20 Mar 2017 16:19:49 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 16:19:49 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tuexen@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.23 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, 20 Mar 2017 16:19:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #62 from Michael Tuexen --- (In reply to slw from comment #61) I don't see why just sending a RST is not allowed. The RFC describes a grac= eful termination of a TCP connection. We are in a situation where it is not graceful. It is more like handling the ABORT primitive... --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 16:29:18 2017 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 4B69AD14BE0 for ; Mon, 20 Mar 2017 16:29:18 +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 308E4185C for ; Mon, 20 Mar 2017 16:29:18 +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 v2KGTH5s078548 for ; Mon, 20 Mar 2017 16:29:18 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 16:29:18 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: slw@zxy.spb.ru 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.23 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, 20 Mar 2017 16:29:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #63 from slw@zxy.spb.ru --- (In reply to Michael Tuexen from comment #62) Accepted RST can cause silent, immediatly closing connection by client. No acknowledged will be sent to server (in case of serevr responce will be delivered to client) and server will be retransmit response until also got = RST. In case of responce not delivered to client responce will be lost and no ch= ance to deleivered. Sending RST is ok in case RST accepted and processed after client sent ACK = so server FIN (FIN, not server data). Need test this on real clients (Linux, windows, android and iOS). Server can do graceful termination of this TCP connection and no reason to don't do this (application do gracefull close and only rare combination of packet loss case this behaviour). --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 16:47:29 2017 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 78ACAD13157 for ; Mon, 20 Mar 2017 16:47:29 +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 688B584C for ; Mon, 20 Mar 2017 16:47:29 +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 v2KGlSOe020850 for ; Mon, 20 Mar 2017 16:47:29 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 16:47:29 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tuexen@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.23 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, 20 Mar 2017 16:47:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #64 from Michael Tuexen --- (In reply to slw from comment #63) > Accepted RST can cause silent, immediatly closing connection by client. > No acknowledged will be sent to server (in case of serevr responce will be > delivered to client) and server will be retransmit response until also go= t RST. No. The server sends a RST and move the connection to CLOSED. The connectio= n is terminated immediately from the server perspective. > In case of responce not delivered to client responce will be lost and no = chance > to deleivered. > Sending RST is ok in case RST accepted and processed after client sent ACK > so server FIN (FIN, not server data). Need test this on real clients > (Linux, windows, android and iOS). No. This is an ungraceful termination. No need to wait for anything. All pe= ers should handle the RST. > Server can do graceful termination of this TCP connection and no reason to > don't do this (application do gracefull close and only rare combination > of packet loss case this behaviour). No. Incoming user data is lost on the server side. I think the server should notify the peer as soon as possible. Please note that the RST is only sent if the server has to drop user data. If that is not the case, a graceful shutdown will be performed. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 16:54:33 2017 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 60B6AD13537 for ; Mon, 20 Mar 2017 16:54: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 50B04E4B for ; Mon, 20 Mar 2017 16:54: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 v2KGsWWV040065 for ; Mon, 20 Mar 2017 16:54:33 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 16:54: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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: slw@zxy.spb.ru 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.23 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, 20 Mar 2017 16:54:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #65 from slw@zxy.spb.ru --- (In reply to Michael Tuexen from comment #64) > No. The server sends a RST and move the connection to CLOSED. The connect= ion is > terminated immediately from the server perspective. This is wrong behaviour. This is cause lost of server data. > No. This is an ungraceful termination. No need to wait for anything. All = peers > should handle the RST. No. pwrite(); close(); This is graceful termination. > No. Incoming user data is lost on the server side. I think the server sho= uld notify > the peer as soon as possible. Please note that the RST is only sent if the server > has to drop user data. If that is not the case, a graceful shutdown will = be performed. User data is second question for server. Main question is resend server res= pond to client. This is RFC requiriment. And this is more impotant for user -- s= ee respond from server, not just droped connection. Server can send RST after client ACK server respose and server FIN. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 17:31:08 2017 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 36715D14214 for ; Mon, 20 Mar 2017 17:31:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 260A610DE for ; Mon, 20 Mar 2017 17:31:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2KHV7F9036321 for ; Mon, 20 Mar 2017 17:31:08 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 17:31:08 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tuexen@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.23 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, 20 Mar 2017 17:31:08 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #66 from Michael Tuexen --- (In reply to slw from comment #65) > This is wrong behaviour. This is cause lost of server data. No, the loss of data is caused by the application calling close() *before* incoming user data arrived. So the TCP stack on the server has to drop that user data. > pwrite(); > close(); > This is graceful termination. Sure. This is what the application triggers. However, when user data arrives after the close call, this gets ungraceful, since this user data can't be deliver= ed to the user anymore. To avoid this, the application could call shutdown(..., SHUT_WR) to trigger the sending of the FIN, then process incoming data until a FIN f= rom the peer arrives and then calling close(). But the application didn't. This wou= ld be more in line of how RFC 793 describes a connection termination. Please note that the CLOSE primitive in RFC 793 maps to a shutdown(..., SHUT_WR) system call, not to the close() system call. Bad naming...=20 I don't see text in RFC 793, where it is required that you continue to proc= ess a connection after you know that it failed. I think the RFC doesn't cover t= he case where the application says "I don't want to receive anymore". --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 18:41:32 2017 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 D2FA2D14192 for ; Mon, 20 Mar 2017 18:41:32 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 566161E55 for ; Mon, 20 Mar 2017 18:41:32 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v2KIfTGR081855; Mon, 20 Mar 2017 19:41:29 +0100 (CET) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 79868294; Mon, 20 Mar 2017 19:41:29 +0100 (CET) Message-ID: <58D02259.9010101@omnilan.de> Date: Mon, 20 Mar 2017 19:41:29 +0100 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Vincenzo Maffione CC: "freebsd-net@freebsd.org" Subject: Re: Are ./valte-ctl and ./bridge friends or competitors? References: <58CBA727.3040108@omnilan.de> <58CBBF7A.8050604@omnilan.de> <58CC26CF.5050708@omnilan.de> <58CFA606.7090306@omnilan.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Mon, 20 Mar 2017 19:41:29 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 20 Mar 2017 18:41:32 -0000 Bezüglich Vincenzo Maffione's Nachricht vom 20.03.2017 12:50 (localtime): … >> So to summarize for newbies exploring netmap(4) world in combination >> with physical uplinks and virtual interfaces, it's important to do the >> following uplink NIC configuration (ifconfig(8)): >> -rxcsum -txcsum -rxcsum6 -txcsum6 -tso -lro promisc >> > > Exactly. This is mentioned at the very end of netmap(4): > > "netmap does not use features such as checksum offloading, TCP segmentation > offloading, encryption, VLAN encapsulation/decapsulation, etc. When using > netmap to exchange packets with the host stack, make sure to disable these > features." > > But it is probably a good idea to add these example ifconfig instructions > somewhere (man page or at least the README in the netmap repo). > > >> >> I guess vlanhwtag, vlanhwfilter and vlanhwtso don't interfere, do they? >> > > Well, I think they interfere: if you receive a tagged packet and the NIC > strips the tag and puts it in the packet descriptor, then with netmap you > will see the untagged packet, and you wouldn't have a way to see the tag. Hmm, if I connect a vlan child to VALE (once I provided crash info and someone capable fixed it), it's intentional that the tag was removed. Otoh, if I attach the parent interface to VALE, stripping isn't done yet, even if there are children defined for a specific vlan id. I see all frames tagged on the parent, at least it was so when I checked that last time, maybe 2 years ago. I'm always creating childs with vlan id 1 if I want a interface without taged frames. Hope I'm not missing something obvious again, I'm about to call it a day here. Thanks, -harry From owner-freebsd-net@freebsd.org Mon Mar 20 18:47:50 2017 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 59ABBD143FF for ; Mon, 20 Mar 2017 18:47:50 +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 3ECBB1A5 for ; Mon, 20 Mar 2017 18:47:50 +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 v2KIln9K041556 for ; Mon, 20 Mar 2017 18:47:50 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 18:47:49 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: slw@zxy.spb.ru 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.23 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, 20 Mar 2017 18:47:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #67 from slw@zxy.spb.ru --- (In reply to Michael Tuexen from comment #66) > No, the loss of data is caused by the application calling close() *before= *=20 > incoming user data arrived. Loss of sended application data caused by close() before incoming user data arrived? Realy? TCP don't have such claim. > So the TCP stack on the server has to drop that user data. No problem. This is not application data. > Sure. This is what the application triggers. However, when user data arri= ves after > the close call, this gets ungraceful, since this user data can't be deliv= ered to > the user anymore. I am not afraid about user data, I am afraid about server data. Server data lost and this is problem. No problem about lose user data. > I don't see text in RFC 793, where it is required that you continue to pr= ocess > a connection after you know that it failed.=20 What reason to failed connection? > I think the RFC doesn't cover the case > where the application says "I don't want to receive anymore". Yes, RFC says all CLOSE is 'means "I have no more to send" but does not mea= n "I will not receive any more."' I mean "Thus, it should be acceptable to make several SEND calls, followed = by a CLOSE, and expect all the data to be sent to the destination." have precend= ece over all. "Reset Generation" allow generation RST from ESTABLISHED/FIN-WAIT-1/fIN-WAI= T-2 state only "If an incoming segment has a security level, or compartment, or precedence which does not exactly match the level" Also, "3.9. Event Processing", "SEGMENT ARRIVES" don't generate RST in ESTABLISHED/FIN-WAIT-1/FIN-WAIT-2 STATE. I mean conection not in failed state until all server data and FIN will be ACKed. Or at timeout. After this, connection may be moved to failed state. Not until. PS: May proposal resolve next issuse: 1. server response not lost any more 2. client see valid replay from server, not just 'connection droped' 3. late segments from client don't mach syn-cookei and don't re-open connec= tion 4. no new restrictions for first segment syn cookie processing 5. client side of connection clearly closed (currently generated RST w/o ACK ignored by all clients except FreeBSD. this is another bug) 6. this is compatible w/ existing applications --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 20:44:27 2017 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 96011D14E3C for ; Mon, 20 Mar 2017 20:44:27 +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 804B0156B for ; Mon, 20 Mar 2017 20:44:27 +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 v2KKiRaI047307 for ; Mon, 20 Mar 2017 20:44:27 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 20:44:27 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tuexen@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.23 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, 20 Mar 2017 20:44:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #68 from Michael Tuexen --- (In reply to slw from comment #67) > Loss of sended application data caused by close() before incoming user > data arrived? Realy? TCP don't have such claim. Hmm. My understanding is that TCP provides a reliable bi-directional byte-stream. This means that no user data is lost in any of the two directions. > No problem. This is not application data. For me it doesn't matter in which direction user data is dropped. If that happens, TCP fails. > I am not afraid about user data, I am afraid about server data. > Server data lost and this is problem. > No problem about lose user data. I don't agree. TCP does not provide a service which is reliable in one direction and unreliable in the other. If user data is dropped, the connection failed. RFC 793 only talks about the CLOSE primitive, which shuts down only the wri= ting direction, not the reading one. This is not related to the close() call, the program is using. The problem comes up because the reading direction is shut down. = This is not described in the RFC. Therefore you have to go back to the high level description of the service TCP provides. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 21:00:39 2017 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 187CED1411B for ; Mon, 20 Mar 2017 21:00:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 019B71B28 for ; Mon, 20 Mar 2017 21:00:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2KL0cN3087812 for ; Mon, 20 Mar 2017 21:00:38 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 21:00:38 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: slw@zxy.spb.ru 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.23 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, 20 Mar 2017 21:00:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #69 from slw@zxy.spb.ru --- (In reply to Michael Tuexen from comment #68) > Hmm. My understanding is that TCP provides a reliable bi-directional byte= -stream. > This means that no user data is lost in any of the two directions. "Lost" in this context is "not delivered to remote IP stack". Not applicati= on, IP stack. Remote system ACK data after place in system buffer, not after reading by application. I.e. while system can accept data and generate ACK -- all ok. Data delivere= d. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 21:10:49 2017 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 86C1AD143AD for ; Mon, 20 Mar 2017 21:10:49 +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 763EF1F69 for ; Mon, 20 Mar 2017 21:10:49 +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 v2KLAnwS074988 for ; Mon, 20 Mar 2017 21:10:49 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217871] SLAAC on a newly created epair sometimes fails to add routes Date: Mon, 20 Mar 2017 21:10:49 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: asomers@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: 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.23 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, 20 Mar 2017 21:10:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217871 --- Comment #3 from Alan Somers --- In https://reviews.freebsd.org/D9451, jhujhiti noticed that the IFDISABLED = flag doesn't get added to epair0b immediately upon creation, but shortly after. = He suspected that was the cause of the problem. However, it's not. It's just= red herring. The IFDISABLED flag gets added by devd, which runs pccard_ether, which runs "service netif quietstart" on the new interfaces. Disabling devd does not fix the test. On the second interface creation, the address from = the previous run is still present. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 21:12:16 2017 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 94FE8D1445F for ; Mon, 20 Mar 2017 21:12:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 84F262C3 for ; Mon, 20 Mar 2017 21:12:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2KLCGGr044814 for ; Mon, 20 Mar 2017 21:12:16 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 21:12:16 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tuexen@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.23 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, 20 Mar 2017 21:12:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #70 from Michael Tuexen --- (In reply to slw from comment #69) > "Lost" in this context is "not delivered to remote IP stack". > Not application, IP stack. The semantic of an ACK is "delivered to the remote TCP stack. Not received = by the application. But the service is from app to app. In my understanding the TCP should sign= al to the peer if it knows that some data will not be delivered to the app. Th= is signalling is sending an RST. > Remote system ACK data after place in system buffer, not after reading > by application. > I.e. while system can accept data and generate ACK -- all ok. Data delive= red. That is fine by the semantic of an ACK. But my point is that a TCP connection fails if some data can't be delivered= to the application. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 21:22:54 2017 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 DA47BD1487D for ; Mon, 20 Mar 2017 21:22: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 C9FDB9C7 for ; Mon, 20 Mar 2017 21:22: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 v2KLMsca055258 for ; Mon, 20 Mar 2017 21:22:54 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 21:22:54 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: slw@zxy.spb.ru 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.23 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, 20 Mar 2017 21:22:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #71 from slw@zxy.spb.ru --- (In reply to Michael Tuexen from comment #70) RFC: "An acknowledgment by TCP does not guarantee that the data has been delivered to the end user, but only that the receiving TCP has taken the responsibility to do so." Nothing about failed delivered to application. This information is unavaila= ble on TCP level. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 21:40:29 2017 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 20BD4D14C16 for ; Mon, 20 Mar 2017 21:40:29 +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 10A08E51 for ; Mon, 20 Mar 2017 21:40:29 +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 v2KLeQpE088440 for ; Mon, 20 Mar 2017 21:40:28 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 21:40:27 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tuexen@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.23 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, 20 Mar 2017 21:40:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #72 from Michael Tuexen --- (In reply to slw from comment #71) I'm not arguing the semantic of the TCP level ACKs. I'm saying that if a TCP stack knows that some user data can not be deliver= ed to its application, it should signal that to the peer. This includes: * receiving data after the socket was closed or shutdown(..., SHUT_RD) was called. * closing the socket or calling shutdown(..., SHUT_RD) with user data still= in the receive buffer. I think: * these four cases should be handled the same way. * Resetting the TCP connection is what I would expect. I can write some packetdrill test scripts to see what the current behaviour= is under FreeBSD (and Linux). --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 23:07:50 2017 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 4B532D1519D for ; Mon, 20 Mar 2017 23:07:50 +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 3AFD81C10 for ; Mon, 20 Mar 2017 23:07:50 +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 v2KN7nIi012193 for ; Mon, 20 Mar 2017 23:07:50 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217871] sys/netinet/fibs_test;slaac_on_nondefault_fib6 fails when run twice Date: Mon, 20 Mar 2017 23:07:50 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: asomers@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: short_desc 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.23 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, 20 Mar 2017 23:07:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217871 Alan Somers changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|SLAAC on a newly created |sys/netinet/fibs_test;slaac |epair sometimes fails to |_on_nondefault_fib6 fails |add routes |when run twice --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 23:08:23 2017 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 D5123D1522D for ; Mon, 20 Mar 2017 23:08:23 +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 C49C01D84 for ; Mon, 20 Mar 2017 23:08:23 +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 v2KN8NcW012853 for ; Mon, 20 Mar 2017 23:08:23 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217871] sys/netinet/fibs_test;slaac_on_nondefault_fib6 fails when run twice Date: Mon, 20 Mar 2017 23:08:23 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: asomers@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: bug_status 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.23 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, 20 Mar 2017 23:08:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217871 Alan Somers changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress --- Comment #4 from Alan Somers --- Turned out to be a bug in the test, not the kernel. Fixed in r315656 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 23:08:28 2017 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 1B069D1523F for ; Mon, 20 Mar 2017 23:08:28 +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 025471DA6 for ; Mon, 20 Mar 2017 23:08:28 +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 v2KN8RSO012959 for ; Mon, 20 Mar 2017 23:08:27 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217871] sys/netinet/fibs_test;slaac_on_nondefault_fib6 fails when run twice Date: Mon, 20 Mar 2017 23:08:28 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@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.23 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, 20 Mar 2017 23:08:28 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217871 --- Comment #5 from commit-hook@freebsd.org --- A commit references this bug: Author: asomers Date: Mon Mar 20 23:07:35 UTC 2017 New revision: 315656 URL: https://svnweb.freebsd.org/changeset/base/315656 Log: Fix back-to-back runs of sys/netinet/fibs_test;slaac_on_nondefault_fib6 This test was failing if run twice because rtadvd takes too long to die. The rtadvd process from the first run was still running when the second run created its interfaces. The solution is to use SIGKILL during the cleanup instead of SIGTERM so rtadvd will die faster. While I'm here, randomize the addresses used for the test, which makes bu= gs like this easier to spot, and fix the cleanup order to be the opposite of the setup order PR: 217871 MFC after: 18 days X-MFC-With: 315458 Sponsored by: Spectra Logic Corp Changes: head/tests/sys/netinet/fibs_test.sh --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 20 23:08:56 2017 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 BFACDD15314 for ; Mon, 20 Mar 2017 23:08: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 AAD371F16 for ; Mon, 20 Mar 2017 23:08: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 v2KN8uEs013499 for ; Mon, 20 Mar 2017 23:08:56 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217871] sys/netinet/fibs_test;slaac_on_nondefault_fib6 fails when run twice Date: Mon, 20 Mar 2017 23:08: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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: asomers@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: asomers@FreeBSD.org X-Bugzilla-Flags: mfc-stable10? mfc-stable11? X-Bugzilla-Changed-Fields: assigned_to flagtypes.name 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.23 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, 20 Mar 2017 23:08:56 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217871 Alan Somers changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-net@FreeBSD.org |asomers@FreeBSD.org Flags| |mfc-stable10?, | |mfc-stable11? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Mar 21 01:23:10 2017 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 A85FCD14A38 for ; Tue, 21 Mar 2017 01:23:10 +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 986FF5F5 for ; Tue, 21 Mar 2017 01:23:10 +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 v2L1NAT5057562 for ; Tue, 21 Mar 2017 01:23:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Tue, 21 Mar 2017 01:23:10 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sepherosa@gmail.com 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.23 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, 21 Mar 2017 01:23:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #73 from Sepherosa Ziehau --- (In reply to Michael Tuexen from comment #72) IMO, transition from {FIN-WAIT-1,FIN-WAIT-2,CLOSING} to TIME_WAIT instead of CLOSED upon receiving data from a closed socket can partially cover this ca= se by leveraging the 2MSL waiting, i.e. keep sending RST. Once 2MSL is done, syncookie kicks in, which is unfixable. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Mar 21 02:24:32 2017 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 742F1D15541 for ; Tue, 21 Mar 2017 02:24:32 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3D3C8117C; Tue, 21 Mar 2017 02:24:32 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: by mail-io0-x234.google.com with SMTP id z13so41238994iof.2; Mon, 20 Mar 2017 19:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mt0hLXLaDy+MvgI3S90TAiyAiPQ+i3mbJ1DxPp6rQn8=; b=Vot5Ir5zOf9FaAAloAp3SxS8tH9vkDDYEcQ5+VFBTTH9EfyhkDKlyz/mwx8hQsBZe+ +Xt2TSP5mA8sbfreatB1ydi97mW4UTMaCxTcrEbRuOJo0xVRy9m1bBhyduXRu+NO/uM6 ck1emmnnd9cQ+G4H+j56U9Yx5FhwooSPzPvAyuJaiZgmbUX1jeXEYDvPwaE633IRSnAe 32bJ8cAsDbZ7dZjqt2iy38LyENjvhfXjLdDayZtPbc7REHeZLB6QY8KngeED6YcbcxiU 43VpVLD/Wpt9Ml3MoazM1RfBfMKUevf2A3LUHCGXOc/xBPlBzt5BDN88/OphifTScxuK 3VnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mt0hLXLaDy+MvgI3S90TAiyAiPQ+i3mbJ1DxPp6rQn8=; b=elJBwEq18zMffvIIbxhYwKuKFK0g0KDAq463D1sxXdG2EhBlK/4TDhoNvTqmoTn9Dh 7LOvj5ip7J3P1Gh1zixWG2bAEPitZT/ExjOo+ZfJeFFMYh0KchIGLt0s+XCMDH1mpmVB l/0pF6Cu+dZrteTLkZTzMbafu2Kgx7lQm4cqB0qDVaUvFOIbw+63mxfklhZaZOcJLGe+ FCXsHP73ip4dI1PPzgVHOeMaT2QBuljvjQjlipvNenPc7Ggn99BOAF1siYHrqRw13GCf fpwIBobIBA1EXCxI+1fWVep2l3DBkuoKkikIeeDpvNNJK0aVWYdU8yvuZi4DGeHY+f0q ifrQ== X-Gm-Message-State: AFeK/H0eFY2cE6Hnl+Sme7fZIg13AeQl8vnDYqT5WG5C6LBQ/kzdtLzhtHfWqHpU+f8U85lJOxBNftGcLgIucA== X-Received: by 10.107.31.11 with SMTP id f11mr29004515iof.183.1490063071425; Mon, 20 Mar 2017 19:24:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.149.135 with HTTP; Mon, 20 Mar 2017 19:24:30 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Ermal_Lu=C3=A7i?= Date: Mon, 20 Mar 2017 19:24:30 -0700 Message-ID: Subject: Re: [Bug 203735] Transparent interception of ipv6 with squid and pf causes panic To: bugzilla-noreply@freebsd.org Cc: freebsd-net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 21 Mar 2017 02:24:32 -0000 On Sun, Mar 19, 2017 at 9:41 PM, wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203735 > > Kristof Provost changed: > > What |Removed |Added > ------------------------------------------------------------ > ---------------- > CC| |kp@freebsd.org > > --- Comment #7 from Kristof Provost --- > The good news is this no longer panics, but it still doesn't work. > > This turns out to be somewhat tricky. > The underlying problem is one of address scope. > > It can be fixed on the receive side with a patch like this: > > diff --git a/sys/netpfil/pf/pf.c b/sys/netpfil/pf/pf.c > index 81290f91b40..d68f81ddf15 100644 > --- a/sys/netpfil/pf/pf.c > +++ b/sys/netpfil/pf/pf.c > @@ -6538,8 +6538,12 @@ done: > pd.proto == IPPROTO_UDP) && s != NULL && s->nat_rule.ptr != > NULL && > (s->nat_rule.ptr->action == PF_RDR || > s->nat_rule.ptr->action == PF_BINAT) && > IN6_IS_ADDR_LOOPBACK(&pd.dst->v6)) > - m->m_flags |= M_SKIP_FIREWALL; > + m->m_flags |= M_SKIP_FIREWALL | M_FASTFWD_OURS; > I am not sure this is really what is happening here. Can you provide more data from your analysis? > > This tells ip6_input() to skip the scope checks, which seems appropriate. > It still fails on the reply packet though, so this doesn't actually fix the > whole use case. > > -- > You are receiving this mail because: > You are on the CC list for the bug. > _______________________________________________ > 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" > -- Ermal From owner-freebsd-net@freebsd.org Tue Mar 21 03:08:32 2017 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 37538D150DB for ; Tue, 21 Mar 2017 03:08:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2742B1063 for ; Tue, 21 Mar 2017 03:08:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2L38UO9072387 for ; Tue, 21 Mar 2017 03:08:32 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Tue, 21 Mar 2017 03:08:30 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: karels@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.23 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, 21 Mar 2017 03:08:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #74 from Mike Karels --- In responding to an earlier comment directed to me, and to the comments sin= ce: This connection is dead. Only an RST and CLOSED state apply. Data cannot = be delivered to the application, which has lost the handle to this connection,= and may not even be alive in some cases. TCP cannot wait for a FIN, for exampl= e, because there may be gigabytes of data to deliver before the FIN, and there= is no where for them to go. fwiw, I added the original version of this code about 30 years ago. I beli= eve it was in 4.3BSD. It is still correct. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Mar 21 04:19:10 2017 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 7FE59D1598C for ; Tue, 21 Mar 2017 04:19:10 +0000 (UTC) (envelope-from kristof@sigsegv.be) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 192E21F76; Tue, 21 Mar 2017 04:19:09 +0000 (UTC) (envelope-from kristof@sigsegv.be) Received: from [172.19.248.15] (unknown [104.153.224.169]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id 57E541E6C7; Tue, 21 Mar 2017 05:18:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigsegv.be; s=mail; t=1490069947; bh=G+hljfR5KXlqnmarM9eReEA/ANxY0mY8wizgn7lFY08=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=dNPqMX/sNPG9AWdwgFan+TEI8MEyBQmt5Rc4ZQUDT5fKP9CFfmsKZOQB+XAQ3mN7r tThwj0WMsT3oS7Kx+1H1YXcc4YQmPg97Hh6diGSWz66Fbqj7LLwBLP3W03fjZpMO97 n5ONnDsB+MONIge6FCQIDSAgl4Q0FttxVJ2LTFIM= From: "Kristof Provost" To: "Ermal =?utf-8?q?Lu=C3=A7i?=" Cc: bugzilla-noreply@freebsd.org, freebsd-net Subject: Re: [Bug 203735] Transparent interception of ipv6 with squid and pf causes panic Date: Tue, 21 Mar 2017 13:18:47 +0900 Message-ID: In-Reply-To: References: MIME-Version: 1.0 X-Mailer: MailMate (2.0BETAr6080) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 21 Mar 2017 04:19:10 -0000 On 21 Mar 2017, at 11:24, Ermal Luçi wrote: > On Sun, Mar 19, 2017 at 9:41 PM, wrote: >> + m->m_flags |= M_SKIP_FIREWALL | M_FASTFWD_OURS; >> > > > I am not sure this is really what is happening here. > Can you provide more data from your analysis? > > In ip6_input(), immediately after the pfil hook there’s a check for M_FASTFWD_OURS. If that flag is set we jump to hbhcheck, which skips all of the scope validation. In the given test case (rdr log on vtnet0 inet6 proto tcp from any to any port 80 -> ::1 port 8000 for example), I also see, in the output of `netstat -s -6` ‘X packets that violated scope rules’ increment. That still doesn’t work, but now I do see ip6_output() being called, and the packet being discarded due to scope issues there (through simple printf()s in the function). Regards, Kristof From owner-freebsd-net@freebsd.org Tue Mar 21 07:34:25 2017 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 D607FD1699A for ; Tue, 21 Mar 2017 07:34: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 C61111D77 for ; Tue, 21 Mar 2017 07:34: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 v2L7YOlS012383 for ; Tue, 21 Mar 2017 07:34:25 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Tue, 21 Mar 2017 07:34: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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tuexen@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.23 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, 21 Mar 2017 07:34:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #75 from Michael Tuexen --- (In reply to Mike Karels from comment #74) I agree completely with Mike. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Mar 21 10:57:50 2017 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 B6028D14B75 for ; Tue, 21 Mar 2017 10:57:50 +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 8C1951974 for ; Tue, 21 Mar 2017 10:57:50 +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 v2LAvnJk024555 for ; Tue, 21 Mar 2017 10:57:50 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Tue, 21 Mar 2017 10:57:49 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: slw@zxy.spb.ru 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.23 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, 21 Mar 2017 10:57:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #76 from slw@zxy.spb.ru --- (In reply to Mike Karels from comment #74) Im don't talk "TCP wait FIN", only "TCP wait ACK=3DSERVER_FIN.SEQ". Server = TCP have sending and not confirmed data, what reason to discard this server response? After got ACK=3DFIN.SEQ no objection to send RST. About incoming data to server. Is close(fd) equalent to sutdown(fd, SHUT_RD= WR)? If yes -- incoming data can acknowledged and then silently discarded: =3D=3D SHUT_RD The read half of the connection is closed=E2=80=94 No more data can be rece= ived on the socket and any data currently in the socket receive buffer is discarded. The process can no longer issue any of the read functions on the socket. Any da= ta received after this call for a TCP socket is acknowledged and then silently discarded. SHUT_WR The write half of the connection is closed=E2=80=94 In the case of TCP, thi= s is called a half-close (Section 18.5 of TCPv1). Any data currently in the socket send buffer will be sent, followed by TCP's normal connection termination sequence. As = we mentioned earlier, this closing of the write half is done regardless of whe= ther or not the socket descriptor's reference count is currently greater than 0. The process can no longer issue any of the write functions on the socket. SHUT_RDWR The read half and the write half of the connection are both closed=E2=80=94= This is equivalent to calling shutdown twice: first with SHUT_RD and then with SHUT= _WR. =3D=3D --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Mar 21 12:26:51 2017 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 4FA9FD14B9D for ; Tue, 21 Mar 2017 12:26:51 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 0B794F78 for ; Tue, 21 Mar 2017 12:26:51 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: by mail-qt0-x22b.google.com with SMTP id n21so129320231qta.1 for ; Tue, 21 Mar 2017 05:26:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=RKSSrweFfXFqkGPGQWDHXp2eKJ1FJpWZaSG3CubvHdU=; b=tetBdOUVYzA/rOVtD0ESt/c3zOYlvcpnxS939dMVlc7nKjB9cxErV1J3J2gjILPWTV IOZ5p4UbGF4ZIfqQK6zlYK9O2xpkZQ7EP4U2wHuiS8t1zWZyxVVC09NNWd2lI/XJQGr9 lzNxuLbqIqsd/NnTCFcyxBGTQTkP/V0CoDWebu6Av6/ZJJ/f99GfWuuav+TYcJ4PZDDf h5GgVQ1SHNHP97NzRo72+mqeJniKN6wwN+aNlSy2PDJO9+z0zu7cCfkaDLCBfkWsUMgx Iw42r9JVth+u4Mp/gD4QUG093myCnJ0bva25HMJPPbX81X6kng5c1sIRcDf8OPrHTpAD 3Wqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=RKSSrweFfXFqkGPGQWDHXp2eKJ1FJpWZaSG3CubvHdU=; b=RZr3HIoZKC+ifQ/AlRDvlsNnPaAq8vBgMUHOOjIEJg/mM0AImAzEV4XnLtrTKKFipc oR0AuNhD+n8MmRbJgzbyllXIRc/3I2/qLqDePX3chgB6sYsHlaOTkvMpkI8tA7pyfayf Gc3YlPNbr3wBaNDy1mbm+AyUN3YGpnb2WhWETH8sMtJ2uLxHGf660BkBO2ohh1k9+vOl w93RZZXWfpxNtZtN5LjQEk4ZRLt62KscsHvh99G+mrUAdu/SobTerEVapOXwWdwmsCd7 gck5axyiw2cs6Uj6hRVH5yXwWcKiy2orlN+Fh04g2tWRVbKdGU4mEGpDVCWKRHE3enPK 6Oew== X-Gm-Message-State: AFeK/H0Iu2ARyB5kibkUvDHG4sY8G1plgO2OimzuXjkBU2HkQ7DUQkAxwyrE95f/qHrpZmhdg4l6FeVUSmXc6w== X-Received: by 10.237.48.66 with SMTP id 60mr16211551qte.25.1490099209707; Tue, 21 Mar 2017 05:26:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.179.135 with HTTP; Tue, 21 Mar 2017 05:26:49 -0700 (PDT) From: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Date: Tue, 21 Mar 2017 15:26:49 +0300 Message-ID: Subject: if_epair altq support problem To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 21 Mar 2017 12:26:51 -0000 Hello, I sent this email also to freebsd-pf list. But I think that the main problem is belongs to sys/net/if_epair.c. I'm using FreeBSD 10.3-p17 amd64. epair pseudo device is listed as supperted deviced at the Man page of altq(4). >From man page of altq : *SUPPORTED DEVICES * The driver modifications described in altq(9) are required to use a cer- tain network card with *ALTQ*. They have been applied to the followin= g hardware drivers: ae(4) , age(4) , alc(4) , ale(4) , an(4) , ath(4) , aue(4) , axe(4) , bce(4) , bfe(4) , bge(4) , bxe(4) , cas(4) , cxgbe(4) , dc(4) , de(4) , ed(4) , em(4) , ep(4) , epair(4) , .... But while trying to use it the system says that it's not suppoerted. I tried on FreeBSD 11 also. The output is below: pf.conf : altq on epair0b hfsc bandwidth 1Mb queue { ftp, ssh, icmp, other } queue ftp bandwidth 30% priority 0 hfsc (upperlimit 99%) queue ssh bandwidth 30% priority 2 hfsc (upperlimit 99%) queue icmp bandwidth 10% priority 2 hfsc (upperlimit 99%) queue other bandwidth 30% priority 1 hfsc (default upperlimit 99%) # ifconfig epair0 create # ifconfig epair0a up # ifconfig epair0b up # pfctl -f pf.conf pfctl: epair0b: driver does not support altq # sysctl -a | grep ALTQ options ALTQ_NOPCC options ALTQ_PRIQ options ALTQ_CDNR options ALTQ_HFSC options ALTQ_RIO options ALTQ_RED options ALTQ_CBQ options ALTQ I have a look on /usr/src/sys/net/if_epair.c, and found the ALTQ section: 514 #ifdef ALTQ 515 /* Support ALTQ via the clasic if_start() path. */ 516 IF_LOCK(&ifp->if_snd); 517 if (ALTQ_IS_ENABLED(&ifp->if_snd)) { 518 ALTQ_ENQUEUE(&ifp->if_snd, m, NULL, error); 519 if (error) 520 ifp->if_snd.ifq_drops++; 521 IF_UNLOCK(&ifp->if_snd); 522 if (!error) { 523 ifp->if_obytes +=3D len; 524 if (mflags & (M_BCAST|M_MCAST)) 525 ifp->if_omcasts++; 526 527 if ((ifp->if_drv_flags & IFF_DRV_OACTIVE) =3D= =3D 0) 528 epair_start_locked(ifp); 529 else 530 (void)epair_add_ifp_for_draining(ifp); 531 } 532 return (error); 533 } 534 IF_UNLOCK(&ifp->if_snd); 535 #endif I have no idea that why it says that it doesn't support altq altough the source code contains ALTQ section. Regards =C3=96zkan KIRIK From owner-freebsd-net@freebsd.org Tue Mar 21 18:05:04 2017 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 595B9D16FAC for ; Tue, 21 Mar 2017 18:05:04 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::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 0F9C213CF for ; Tue, 21 Mar 2017 18:05:04 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-ot0-x22d.google.com with SMTP id y88so1065509ota.2 for ; Tue, 21 Mar 2017 11:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ynAEAKdZaefkZrlnPGPlFurLB23dUC6qgdO02suvWrY=; b=NltuU1QpDW8kEC4lgdRRVOnHcIASXWJpnwEaas2swvJ4/HJk3BYrZwULub11yKEFfE GRgGDFgb8UvoOFjqi5CzZQUArCfpIL6JoWFolWxuUCZFsweSc+sCzbqwps6ttwcvLhoZ XQdvq7slL0k3Fb1ebqXGpxPdToMgEZC9ENPCdqf6aDsaNzqAtoUpOmjUUMT0pbwCv6ew I6b799tupynybQU8CXoeZrIOZGJzozP37XNs0TRtnJNcWoLZmzUG7YQ1xaOemB8VJRh8 yIVDDT5ZL1WuYe0c83uEbnqGeVbEk/6uv9IJNkvZalqrvrweh3JV5toC53ehV0nl1zZT CVug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ynAEAKdZaefkZrlnPGPlFurLB23dUC6qgdO02suvWrY=; b=T1uuO4fXORWKFbJSjQSqAY8QdJHNj55ME7UCruNclyDGNNuzaUT9tFFB7xjunI07TM /EAG8/Nzz61aSGkX9OiBYPKwnrh1042tmAGcm+t60vq1uHQU/eZdaBQWl9AMRFF5BubX fWJHt+2mP+QkOK/HhyvHXsGiy8B53vZ8toz3AtG/pu1LF3kwdGeQOgjNu0lq/jWpEDUd LLhhHw2wQjTao/L8PR/u1/wFN+C4C+FLd8qJVMwIEac6op2v1nl7Fo6ueMrzr2tBhuqs okPvJheKtYZ18dI0yuVdfAC+YNQVMZzHUbn3yGAEaIBiwDY10Y3e51d/BhCUF3eXw+6Q ZCEA== X-Gm-Message-State: AFeK/H3ugZnj4BZ07TYvuiR4dzzF/HwvN0D7tgMJ9PgWxQAu/asEdVoHHeT+TeAukIZR68VU5xqlOflynx65mg== X-Received: by 10.157.48.167 with SMTP id s39mr21328691otc.108.1490119503379; Tue, 21 Mar 2017 11:05:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.11.184 with HTTP; Tue, 21 Mar 2017 11:05:02 -0700 (PDT) In-Reply-To: <58D02259.9010101@omnilan.de> References: <58CBA727.3040108@omnilan.de> <58CBBF7A.8050604@omnilan.de> <58CC26CF.5050708@omnilan.de> <58CFA606.7090306@omnilan.de> <58D02259.9010101@omnilan.de> From: Vincenzo Maffione Date: Tue, 21 Mar 2017 19:05:02 +0100 Message-ID: Subject: Re: Are ./valte-ctl and ./bridge friends or competitors? To: Harry Schmalzbauer Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 21 Mar 2017 18:05:04 -0000 2017-03-20 19:41 GMT+01:00 Harry Schmalzbauer : > Bez=C3=BCglich Vincenzo Maffione's Nachricht vom 20.03.2017 12:50 (localt= ime): > =E2=80=A6 > >> So to summarize for newbies exploring netmap(4) world in combination > >> with physical uplinks and virtual interfaces, it's important to do the > >> following uplink NIC configuration (ifconfig(8)): > >> -rxcsum -txcsum -rxcsum6 -txcsum6 -tso -lro promisc > >> > > > > Exactly. This is mentioned at the very end of netmap(4): > > > > "netmap does not use features such as checksum offloading, TCP > segmentation > > offloading, encryption, VLAN encapsulation/decapsulation, etc. When > using > > netmap to exchange packets with the host stack, make sure to disable > these > > features." > > > > But it is probably a good idea to add these example ifconfig instructio= ns > > somewhere (man page or at least the README in the netmap repo). > > > > > >> > >> I guess vlanhwtag, vlanhwfilter and vlanhwtso don't interfere, do they= ? > >> > > > > Well, I think they interfere: if you receive a tagged packet and the NI= C > > strips the tag and puts it in the packet descriptor, then with netmap y= ou > > will see the untagged packet, and you wouldn't have a way to see the ta= g. > > Hmm, if I connect a vlan child to VALE (once I provided crash info and > someone capable fixed it), it's intentional that the tag was removed. > Otoh, if I attach the parent interface to VALE, stripping isn't done > yet, even if there are children defined for a specific vlan id. I see > all frames tagged on the parent, at least it was so when I checked that > last time, maybe 2 years ago. I'm always creating childs with vlan id 1 > if I want a interface without taged frames. It depends on the NIC hw capabilities. If you "see" the frames with tcpdump, tcpdump can show you something different from the packet format. Anyway, netmap patches just ignore VLAN tags, so that if the NIC does not strip tags, you will see them in your netmap application. Cheers, Vincenzo > > Hope I'm not missing something obvious again, I'm about to call it a day > here. > > Thanks, > > -harry > --=20 Vincenzo Maffione From owner-freebsd-net@freebsd.org Tue Mar 21 21:05:28 2017 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 43634D173E9 for ; Tue, 21 Mar 2017 21:05:28 +0000 (UTC) (envelope-from quartz@sneakertech.com) Received: from douhisi.pair.com (douhisi.pair.com [209.68.5.179]) (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 2886C1CAE for ; Tue, 21 Mar 2017 21:05:27 +0000 (UTC) (envelope-from quartz@sneakertech.com) Received: from [192.168.0.1] (pool-72-74-34-8.bstnma.fios.verizon.net [72.74.34.8]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by douhisi.pair.com (Postfix) with ESMTPSA id 03D3F3F531 for ; Tue, 21 Mar 2017 17:05:20 -0400 (EDT) Message-ID: <58D19590.4090207@sneakertech.com> Date: Tue, 21 Mar 2017 17:05:20 -0400 From: Quartz MIME-Version: 1.0 To: freebsd-net@FreeBSD.org Subject: Filtering multicast and/or 6to4? Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 21 Mar 2017 21:05:28 -0000 After all these years, I'm still not 100% sure I understand multicast and 6to4. I'm trying to figure out when/why/if I should be filtering stuff, and in which direction(s). Is this the correct list to ask these sorts of questions? From owner-freebsd-net@freebsd.org Tue Mar 21 21:53:21 2017 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 1170AD170CF for ; Tue, 21 Mar 2017 21:53:21 +0000 (UTC) (envelope-from freebsd@str.komkon.org) Received: from tissa.komkon.org (tissa.komkon.org [52.5.170.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "komkon.org", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D15981ED8 for ; Tue, 21 Mar 2017 21:53:20 +0000 (UTC) (envelope-from freebsd@str.komkon.org) Received: from auth (localhost [127.0.0.1]) by tissa.komkon.org (8.15.2/8.15.2) with ESMTPSA id v2LLqwLv022649 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 21 Mar 2017 17:53:19 -0400 (EDT) (envelope-from freebsd@str.komkon.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=str.komkon.org; s=mail; t=1490133199; bh=u1AeK+ivzlgQyEjP/ZKbbfkAB5A5kkXpfXEJuDVgKLU=; h=Date:From:To:Subject; b=RhbNdI4o54ZbzeWSyu/xOawiwAahf5bHxs7EzfbVZ7GbBljU2TdBL7OukwJNJIZd1 /xqasW8PKsG0J4RcqGUS7kiTS7JOFYDp6C4KICloJSAVBDzXyOSCwVOKV+NcSwT6F9 ZbqBXMRp90agaxlHSEYpkyMPBNHIh7migkXzjWgs= Date: Tue, 21 Mar 2017 17:52:58 -0400 (EDT) From: "Igor R." To: freebsd-net@freebsd.org Subject: multiple nameservers in resolvconf.conf Message-ID: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.99.2 at tissa.komkon.org X-Virus-Status: Clean X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 21 Mar 2017 21:53:21 -0000 How one can specify multiple name servers in each of the following options in resolvconf.conf: (note, it is not resolv.conf!) https://www.freebsd.org/cgi/man.cgi?query=resolvconf.conf&sektion=5 append_nameservers and prepend_nameservers ? Even though the options have "nameservers" in plural, I could not find any example anywhere on the net that would indicate multiple values for these two options. I've tried append_nameservers=127.0.0.1, 192.168.15.2 append_nameservers=127.0.0.1,192.168.15.2 append_nameservers=127.0.0.1 192.168.15.2 append_nameservers=127.0.0.1; 192.168.15.2 as well as specifying them on separate lines: append_nameservers=127.0.0.1 append_nameservers=192.168.15.2 These different version yield 3 different outcomes, but none of them produces resolv.conf (upon running resolvconf -u) with both servers in there. (Not that it matters, but there is an active information from dhcp server/client. Tested on 10.* system.) I wonder if it is a bug... Thank you in adavnce, Igor From owner-freebsd-net@freebsd.org Wed Mar 22 00:34:49 2017 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 8D5D4D1608E for ; Wed, 22 Mar 2017 00:34:49 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id 6BEBC13DB for ; Wed, 22 Mar 2017 00:34:48 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from imac.home.vangyzen.net (unknown [76.164.15.242]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 9F45C56486; Tue, 21 Mar 2017 19:34:42 -0500 (CDT) Subject: Re: multiple nameservers in resolvconf.conf To: "Igor R." , freebsd-net@freebsd.org References: From: Eric van Gyzen Message-ID: <0b82f5db-810e-6076-2587-e687b6ce7f5e@vangyzen.net> Date: Tue, 21 Mar 2017 19:34:43 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 22 Mar 2017 00:34:49 -0000 On 3/21/17 4:52 PM, Igor R. wrote: > > How one can specify multiple name servers in each of the > following options in resolvconf.conf: (note, it is not resolv.conf!) > https://www.freebsd.org/cgi/man.cgi?query=resolvconf.conf&sektion=5 > > append_nameservers > and > prepend_nameservers ? > > > Even though the options have "nameservers" in plural, I could not find > any example anywhere on the net that would indicate multiple values for > these two options. > > I've tried > append_nameservers=127.0.0.1, 192.168.15.2 > append_nameservers=127.0.0.1,192.168.15.2 > append_nameservers=127.0.0.1 192.168.15.2 > append_nameservers=127.0.0.1; 192.168.15.2 > as well as specifying them on separate lines: > append_nameservers=127.0.0.1 > append_nameservers=192.168.15.2 > > These different version yield 3 different outcomes, but none of them > produces resolv.conf (upon running resolvconf -u) with both servers in > there. The config file is in /bin/sh syntax, so I imagine it would be: append_nameservers='127.0.0.1 192.168.15.2' Give that a shot. Eric From owner-freebsd-net@freebsd.org Wed Mar 22 01:34:55 2017 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 ED3D4D17332 for ; Wed, 22 Mar 2017 01:34:55 +0000 (UTC) (envelope-from freebsd@str.komkon.org) Received: from tissa.komkon.org (tissa.komkon.org [52.5.170.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "komkon.org", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B76E51747 for ; Wed, 22 Mar 2017 01:34:55 +0000 (UTC) (envelope-from freebsd@str.komkon.org) Received: from auth (localhost [127.0.0.1]) by tissa.komkon.org (8.15.2/8.15.2) with ESMTPSA id v2M1Yl5C025082 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Mar 2017 21:34:48 -0400 (EDT) (envelope-from freebsd@str.komkon.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=str.komkon.org; s=mail; t=1490146490; bh=16oZ8PS6Dz4rFFXR3q8A18iUuB4VLqlgtQFNhiumauo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Hud9pxLJDaS4gXrh69jq3tV2oTO/KVrer6moYm+nyNH7mDPzzTi1BZeKl5iCJ+oPQ hMMIDs2mZOtjyzx9wdST6p2oUqnPblswiVFb/5v5vQbfn7v2gAY02AJW6cf1uAS4lE znh54exzLdtxzArPc8c0/yY+7B8XjN5knsJw2S6c= Date: Tue, 21 Mar 2017 21:34:47 -0400 (EDT) From: "Igor R." To: Eric van Gyzen cc: freebsd-net@freebsd.org Subject: Re: multiple nameservers in resolvconf.conf In-Reply-To: <0b82f5db-810e-6076-2587-e687b6ce7f5e@vangyzen.net> Message-ID: References: <0b82f5db-810e-6076-2587-e687b6ce7f5e@vangyzen.net> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.99.2 at tissa.komkon.org X-Virus-Status: Clean X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 22 Mar 2017 01:34:56 -0000 Yes! That worked! Thank you, Eric! I don't know how I didn't think about it... Igor On Tue, 21 Mar 2017, Eric van Gyzen wrote: > On 3/21/17 4:52 PM, Igor R. wrote: >> >> How one can specify multiple name servers in each of the >> following options in resolvconf.conf: (note, it is not resolv.conf!) >> https://www.freebsd.org/cgi/man.cgi?query=resolvconf.conf&sektion=5 >> >> append_nameservers >> and >> prepend_nameservers ? >> >> >> Even though the options have "nameservers" in plural, I could not find >> any example anywhere on the net that would indicate multiple values for >> these two options. >> >> I've tried >> append_nameservers=127.0.0.1, 192.168.15.2 >> append_nameservers=127.0.0.1,192.168.15.2 >> append_nameservers=127.0.0.1 192.168.15.2 >> append_nameservers=127.0.0.1; 192.168.15.2 >> as well as specifying them on separate lines: >> append_nameservers=127.0.0.1 >> append_nameservers=192.168.15.2 >> >> These different version yield 3 different outcomes, but none of them >> produces resolv.conf (upon running resolvconf -u) with both servers in >> there. > > The config file is in /bin/sh syntax, so I imagine it would be: > > append_nameservers='127.0.0.1 192.168.15.2' > > Give that a shot. > > Eric > From owner-freebsd-net@freebsd.org Wed Mar 22 03:59:51 2017 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 8440FD17B0B for ; Wed, 22 Mar 2017 03:59:51 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 4956965C for ; Wed, 22 Mar 2017 03:59:51 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: by mail-io0-x22d.google.com with SMTP id l7so59799915ioe.3 for ; Tue, 21 Mar 2017 20:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=+UibLifpseIprdwr2DNmB1xChRjLW+W2U49/w9oZVLI=; b=YMjXQqsEloN2sFy+KunB4EK6GFNANwbOGwXHxvybu26AK8PKfIvqjesViAimY8sTTY Dva0Z1GcNgISYOQCrJBdCNY73Mw9gccJxxqSDLZqWiI7Up7GmMhRM1/H/6VGGFLNrvAu TGrTEpEaiUdzks9a9fS10CyKsyRrBrzpgWch3aEeqN8t8MukfwxXpmOEmZoD8gR6vdJb LO9F/Rnn3aepGmcEf/DWMdW51PpG0EqbH7B/1b6SUW+rhSLKu1eT4FENJKfzABrCIpQj zAUXcPz/WNLrip90d7NFf9RvYDdW8/d9tePf5kCan806dBwfngWsiW7aTjTd6Yg+i9pC hVCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=+UibLifpseIprdwr2DNmB1xChRjLW+W2U49/w9oZVLI=; b=jo5egQCTxVk1JQJ8nX5DCk1Gkdi8j9vXF6H4SuDrkMvSfz8HZu7aa3RmgLvo5WlI/T XXy+cSDtpj9yuAN6rdAj5kmMmyCIF6iYCWyCmgPSGThVm0f1BHupRHCigzX7WhWNRGc8 FL/Xheew2PW3Tp5eJENcGnizCBocnXYbfR123arAbmIf32764F4wCXAIYYvP5i/rhaMu 8xlwNuFNKUFGdvwLx0k6Nbt6vQHqJVmBHri+qnZh6JdO3mBuqm0fuDkgI04kQ303Fi2U emx5dZSTv3RC1WffPdyz5/hPaU8hb1BInRp+QbthK6Ys1qXWCUr+pK1UvyabVH7yseQi 0hxQ== X-Gm-Message-State: AFeK/H3JYMqsXSTEAhHzNUzuJyGc1U4nUfYKnRaE6nDS+ojkgOGMTwwobaB/KqkzSv9Isf6ts+Rwf6tmfmyBhw== X-Received: by 10.107.155.16 with SMTP id d16mr33971108ioe.125.1490155190638; Tue, 21 Mar 2017 20:59:50 -0700 (PDT) MIME-Version: 1.0 Sender: ermal.luci@gmail.com Received: by 10.107.149.135 with HTTP; Tue, 21 Mar 2017 20:59:50 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Ermal_Lu=C3=A7i?= Date: Tue, 21 Mar 2017 20:59:50 -0700 X-Google-Sender-Auth: _Xq6TigvxH_xBVWuDnJHvukJzhw Message-ID: Subject: Re: if_epair altq support problem To: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 22 Mar 2017 03:59:51 -0000 On Tue, Mar 21, 2017 at 5:26 AM, =C3=96zkan KIRIK w= rote: > Hello, > > I sent this email also to freebsd-pf list. But I think that the main > problem is belongs to sys/net/if_epair.c. > > I'm using FreeBSD 10.3-p17 amd64. epair pseudo device is listed as > supperted deviced at the Man page of altq(4). > From man page of altq : > > *SUPPORTED DEVICES = * > > The driver modifications described in altq(9) > apropos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports> > are required to use a cer- > tain network card with *ALTQ*. They have been applied to the > following > hardware drivers: ae(4) > apropos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, > age(4) apropos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, > alc(4) apropos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, > ale(4) apropos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, > an(4) apropos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, > ath(4) apropos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, > aue(4) apropos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, > axe(4) apropos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, > bce(4) apropos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, > bfe(4) apropos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, > bge(4) apropos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, > bxe(4) apropos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, > cas(4) apropos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, > cxgbe(4) apropos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, > dc(4) apropos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, > de(4) apropos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, > ed(4) apropos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, > em(4) apropos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, > ep(4) apropos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, > epair(4) apropos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, > .... > > But while trying to use it the system says that it's not suppoerted. I > tried on FreeBSD 11 also. The output is below: > > pf.conf : > altq on epair0b hfsc bandwidth 1Mb queue { ftp, ssh, icmp, other } > queue ftp bandwidth 30% priority 0 hfsc (upperlimit 99%) > queue ssh bandwidth 30% priority 2 hfsc (upperlimit 99%) > queue icmp bandwidth 10% priority 2 hfsc (upperlimit 99%) > queue other bandwidth 30% priority 1 hfsc (default upperlimit 99%) > > > # ifconfig epair0 create > # ifconfig epair0a up > # ifconfig epair0b up > # pfctl -f pf.conf > pfctl: epair0b: driver does not support altq > > # sysctl -a | grep ALTQ > options ALTQ_NOPCC > options ALTQ_PRIQ > options ALTQ_CDNR > options ALTQ_HFSC > options ALTQ_RIO > options ALTQ_RED > options ALTQ_CBQ > options ALTQ > > > I have a look on /usr/src/sys/net/if_epair.c, and found the ALTQ section: > > 514 #ifdef ALTQ > 515 /* Support ALTQ via the clasic if_start() path. */ > 516 IF_LOCK(&ifp->if_snd); > 517 if (ALTQ_IS_ENABLED(&ifp->if_snd)) { > 518 ALTQ_ENQUEUE(&ifp->if_snd, m, NULL, error); > 519 if (error) > 520 ifp->if_snd.ifq_drops++; > 521 IF_UNLOCK(&ifp->if_snd); > 522 if (!error) { > 523 ifp->if_obytes +=3D len; > 524 if (mflags & (M_BCAST|M_MCAST)) > 525 ifp->if_omcasts++; > 526 > 527 if ((ifp->if_drv_flags & IFF_DRV_OACTIVE) = =3D=3D > 0) > 528 epair_start_locked(ifp); > 529 else > 530 (void)epair_add_ifp_for_ > draining(ifp); > 531 } > 532 return (error); > 533 } > 534 IF_UNLOCK(&ifp->if_snd); > 535 #endif > > Just apply manually this patch to make it work. diff --git a/sys/net/if_epair.c b/sys/net/if_epair.c index 540f06c..04733a5 100644 --- a/sys/net/if_epair.c +++ b/sys/net/if_epair.c @@ -827,9 +827,11 @@ epair_clone_create(struct if_clone *ifc, char *name, size_t len, caddr_t params) ifp->if_capabilities =3D IFCAP_VLAN_MTU; ifp->if_capenable =3D IFCAP_VLAN_MTU; ifp->if_start =3D epair_start; + if_setstartfn(ifp, epair_start); + if_setsendqlen(ifp, ifqmaxlen); + if_setsendqready(ifp); ifp->if_ioctl =3D epair_ioctl; ifp->if_init =3D epair_init; - ifp->if_snd.ifq_maxlen =3D ifqmaxlen; /* Assign a hopefully unique, locally administered etheraddr. */ eaddr[0] =3D 0x02; eaddr[3] =3D (ifp->if_index >> 8) & 0xff; @@ -852,10 +854,11 @@ epair_clone_create(struct if_clone *ifc, char *name, size_t len, caddr_t params) ifp->if_flags =3D IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST; ifp->if_capabilities =3D IFCAP_VLAN_MTU; ifp->if_capenable =3D IFCAP_VLAN_MTU; - ifp->if_start =3D epair_start; + if_setstartfn(ifp, epair_start); + if_setsendqlen(ifp, ifqmaxlen); + if_setsendqready(ifp); ifp->if_ioctl =3D epair_ioctl; ifp->if_init =3D epair_init; - ifp->if_snd.ifq_maxlen =3D ifqmaxlen; /* We need to play some tricks here for the second interface. */ strlcpy(name, epairname, len); error =3D if_clone_create(name, len, (caddr_t)scb); > I have no idea that why it says that it doesn't support altq altough the > source code contains ALTQ section. > > > Regards > =C3=96zkan KIRIK > _______________________________________________ > 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 Ermal From owner-freebsd-net@freebsd.org Wed Mar 22 08:06:13 2017 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 5DDA3D178EC for ; Wed, 22 Mar 2017 08:06:13 +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 4D123312 for ; Wed, 22 Mar 2017 08:06:13 +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 v2M86B9B057086 for ; Wed, 22 Mar 2017 08:06:13 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Wed, 22 Mar 2017 08:06:12 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sepherosa@gmail.com 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.23 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, 22 Mar 2017 08:06:13 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #77 from Sepherosa Ziehau --- (In reply to Mike Karels from comment #74) Is this {FIN-WAIT-1,FIN-WAIT-2,CLOSING} to CLOSED transition by the quoted = code kinda similar to TWA (RFC1337)? And would it suffer the same hazards liste= d in that RFC? Thanks, sephe --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Wed Mar 22 14:20:10 2017 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 A6336D17EA6 for ; Wed, 22 Mar 2017 14:20:10 +0000 (UTC) (envelope-from deborah.perry@datadynamicsit.biz) Received: from mail-pf0-x246.google.com (mail-pf0-x246.google.com [IPv6:2607:f8b0:400e:c00::246]) (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 84F6718DA for ; Wed, 22 Mar 2017 14:20:10 +0000 (UTC) (envelope-from deborah.perry@datadynamicsit.biz) Received: by mail-pf0-x246.google.com with SMTP id c23so356879161pfj.0 for ; Wed, 22 Mar 2017 07:20:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=datadynamicsit-biz.20150623.gappssmtp.com; s=20150623; h=mime-version:message-id:date:subject:from:to; bh=7V0TkySiNsloszm+OW8D3ZYKTecgDWfDFLKYseq2kgQ=; b=dvKZj8MPaNAVQhlwUkYqHU7DIHwAC02BNYMxR2a5Jk00nWpdSbNeAzt+bRMnzQNoV6 +k3WEmIL6OeM7NXTDjL9nz50qmbkY8tw7G7XxLEnL+l0ZGls/YUJOTwtaXfh4aJS4D6p VR8RmRHQi6yNQw1IlTBx/0zGHbz306w4UeWJtPEJmRPnN6uDap6nRWN6vFEbnpJ7IRdF IoPgyfdjnzttTcMHcBLkrv6vIr9VTG/KsarK6mwO4w3k4uzgSwJTmnUKZ+YJgXsnhxl/ Uu83e+ZbXD0lRguFjkYYsRDvsWqKxiQNfZch8EkKfzuD6sTZz9hwiNNG6qBLFfdrKht5 cYWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:message-id:date:subject:from:to; bh=7V0TkySiNsloszm+OW8D3ZYKTecgDWfDFLKYseq2kgQ=; b=i4HI6LHmTMTgUemZRoP7YktxWhpgdZN6e2PUa4O+EUcqncg61/R+C1etkuCxO4SK5U Y81m+OVllTKBkXDtIKzJJKku9colGK1yTnsTglD9SIbca0ffsKSKWsfETqzxqe5Oa0NB 8TXjby9WZcnzHXDdfL46n5Q/eQCIvEa+q+amTw2hzM7PaNegaAvFnlAyNYpv3E0JOe0+ EQHenUts8gQVg/2h31KSG4tNuFQ5vExZbTDYGGFAdfFEl1CBh276ovaRsRLtc03zwZP0 Ahn6z0rd8UqC7lppL6WY/8E8/14J7kunRXWHgi4JPKI4IFyc4TLzgNTBMVNC6VRy0gdK ybNA== X-Gm-Message-State: AFeK/H2lZcYRNh/KIpsaG7HMgDXopRnBqkEwlDz7OweAhwbFWc5I7zhih12DDCE0TeEC21RxSygZOhLuROdIHQ== MIME-Version: 1.0 X-Received: by 10.99.142.74 with SMTP id k71mr6974859pge.76.1490192409784; Wed, 22 Mar 2017 07:20:09 -0700 (PDT) Message-ID: <94eb2c03334e3b79ab054b527547@google.com> Date: Wed, 22 Mar 2017 14:20:09 +0000 Subject: Re:Embedded Systems Users List From: deborah.perry@datadynamicsit.biz To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 22 Mar 2017 14:20:10 -0000 DQoNCkhpLA0KDQpBIHF1aWNrIGZvbGxvdyB1cCB0byBrbm93IGlmIHlvdSB3b3VsZCBiZSBpbnRl cmVzdGVkIGluICpFbWJlZGRlZCBTeXN0ZW1zKg0KVXNlcnMgbGlzdCBmb3IgeW91ciBtYXJrZXRp bmcgY2FtcGFpZ24/DQoNCipMaXN0IENvbnRhaW5zOiogTmFtZSwgQ29tcGFueSdzIE5hbWUsIFBo b25lIE51bWJlciwgRmF4IE51bWJlciwgSm9iIFRpdGxlLA0KRW1haWwgYWRkcmVzcywgQ29tcGxl dGUgTWFpbGluZyBBZGRyZXNzLCBTSUMgY29kZSwgQ29tcGFueSByZXZlbnVlLCBzaXplLA0KV2Vi IGFkZHJlc3MgZXRjLg0KDQpTcGVjaWFsdGllczogVkxTSSwgTWljcm8gQ29udHJvbGxlciwgR2Vu ZXJhbCBjb21wdXRpbmcgc3lzdGVtcywgTmV0d29ya2luZywNClBMQywgV2ViIERldmVsb3BtZW50 DQoNCg0KDQpMZXQgbWUga25vdyB5b3VyIHRob3VnaHRzIG9yIHBhc3Mgb24gdGhlIG1lc3NhZ2Ug dG8gdGhlIHJpZ2h0IHBlcnNvbiBpbg0KeW91ciBjb21wYW55Lg0KDQoNCklmIHlvdSBhcmUgbG9v a2luZyBmb3IgYW55IG90aGVyIHRlY2hub2xvZ2llcyBwbGVhc2UgbGV0IG1lIGtub3cgeW91cg0K Y3JpdGVyaWEgSSB3aWxsIGdldCBiYWNrIHRvIHlvdSB3aXRoIHRoZSBzYW1lIHRhcmdldC4NCg0K VGhhbmtzICYgcmVnYXJkcywNCkRlYm9yYWggUGVycnkNCk1hcmtldGluZyBBbmFseXN0DQoNCklm IHlvdSBkb27igJl0IHdhbnQgdG8gcmVjZWl2ZSBhbnkgbWVzc2FnZSBmcm9tIHVzIHRoZW4gcGxl YXNlIHR5cGUg4oCcT1BUIE9VVOKAnQ0KaW4gdGhlIFN1YmplY3QgTGluZS4NCg== From owner-freebsd-net@freebsd.org Wed Mar 22 17:18:50 2017 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 7CED5D1856C for ; Wed, 22 Mar 2017 17:18:50 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 351BC1175; Wed, 22 Mar 2017 17:18:50 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: by mail-qk0-x231.google.com with SMTP id p22so22008418qka.3; Wed, 22 Mar 2017 10:18:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xEjOUJ2Uul4pLhxWeF8A35j67wwiZ0j5aj9LaSh0g0s=; b=bdj9BjoIxJ64yN34ipwdb0i3ye3Os92BeSsElV/BZnwoJp9EyhHk5aaL41ie3FI1mF a3KkhJv8tgkZt0KQAmgryD/o/gqZP8/YBvLJ6nL1K3dafCAHDC1aUfSJt/biHHL6xjgi iAwpiQ0IkcYVY2OafAeoP7oGgZq/byUZ60+el5FTKsoTvfU2EMBccLuoLrCfYrhYPNCt zfXiLVArhhs7FLwTr8qzAe7vjntMdzswmaIr6FR4JCxQD0o/LLfKMuygObA2XT5wq5CF 7Sv5lsp4PAwN5k19isYs74JU91dzije8GDkmK2aVMssMy80JH9SrYVa1lkiPqnlaVi6y 9L9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xEjOUJ2Uul4pLhxWeF8A35j67wwiZ0j5aj9LaSh0g0s=; b=FCqEygt9d/bOFSpzZOz8mJYJp0itIjsQsWV/ZYaWcgdSTSYH0URwkF3QFEnAYBalj4 8Uuy5v3zeLyoO1rtMhoa5XK7U/bZN1BspgnZgPFUEAa98lr6mKeTM8ZSkn39OvzCjujY 5RN0ldtAVDISvLUtTb0HsXXtwdcbYj7taAw8btMH07IqN7cS+QIRlcNT9EDRXY0Lvtmt +VP2FvprkVxGmV1UQlGQOoV+DKbSJKaFjztLCQb1TUcOsjttozz5gkdBwazPupK9+RZM 75M5NRruGRSpzRKLb7dLs99z3tP+JClFm0iAlkpTReBAXFXV2Ap9/UBIttvmiBC+h0Mk 6kzg== X-Gm-Message-State: AFeK/H3/OjbIrY6JAZBLN+IlBIXfzy+EH6DCyCY0THtzEUS3aMa8vaJ0lVpgLCJiXPfKqrhx2GTWWnVgLhdU5Q== X-Received: by 10.55.131.68 with SMTP id f65mr36471345qkd.1.1490203129064; Wed, 22 Mar 2017 10:18:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.179.135 with HTTP; Wed, 22 Mar 2017 10:18:48 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Date: Wed, 22 Mar 2017 20:18:48 +0300 Message-ID: Subject: Re: if_epair altq support problem To: =?UTF-8?Q?Ermal_Lu=C3=A7i?= Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 22 Mar 2017 17:18:50 -0000 Thank You Ermal ! It works perfectly, can you commit this patch to 11.0 RELENG and MFC to 10.3 RELENG ? Regards On Wed, Mar 22, 2017 at 6:59 AM, Ermal Lu=C3=A7i wrote: > > > On Tue, Mar 21, 2017 at 5:26 AM, =C3=96zkan KIRIK > wrote: > >> Hello, >> >> I sent this email also to freebsd-pf list. But I think that the main >> problem is belongs to sys/net/if_epair.c. >> >> I'm using FreeBSD 10.3-p17 amd64. epair pseudo device is listed as >> supperted deviced at the Man page of altq(4). >> From man page of altq : >> >> *SUPPORTED DEVICES * >> >> The driver modifications described in altq(9) >> > ropos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports> >> are required to use a cer- >> tain network card with *ALTQ*. They have been applied to the >> following >> hardware drivers: ae(4) >> > pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >> age(4) > opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >> alc(4) > opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >> ale(4) > opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >> an(4) > pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >> ath(4) > opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >> aue(4) > opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >> axe(4) > opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >> bce(4) > opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >> bfe(4) > opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >> bge(4) > opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >> bxe(4) > opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >> cas(4) > opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >> cxgbe(4) > propos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >> dc(4) > pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >> de(4) > pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >> ed(4) > pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >> em(4) > pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >> ep(4) > pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >> epair(4) > propos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >> >> .... >> >> But while trying to use it the system says that it's not suppoerted. I >> tried on FreeBSD 11 also. The output is below: >> >> pf.conf : >> altq on epair0b hfsc bandwidth 1Mb queue { ftp, ssh, icmp, other } >> queue ftp bandwidth 30% priority 0 hfsc (upperlimit 99%) >> queue ssh bandwidth 30% priority 2 hfsc (upperlimit 99%) >> queue icmp bandwidth 10% priority 2 hfsc (upperlimit 99%) >> queue other bandwidth 30% priority 1 hfsc (default upperlimit 99%) >> >> >> # ifconfig epair0 create >> # ifconfig epair0a up >> # ifconfig epair0b up >> # pfctl -f pf.conf >> pfctl: epair0b: driver does not support altq >> >> # sysctl -a | grep ALTQ >> options ALTQ_NOPCC >> options ALTQ_PRIQ >> options ALTQ_CDNR >> options ALTQ_HFSC >> options ALTQ_RIO >> options ALTQ_RED >> options ALTQ_CBQ >> options ALTQ >> >> >> I have a look on /usr/src/sys/net/if_epair.c, and found the ALTQ section= : >> >> 514 #ifdef ALTQ >> 515 /* Support ALTQ via the clasic if_start() path. */ >> 516 IF_LOCK(&ifp->if_snd); >> 517 if (ALTQ_IS_ENABLED(&ifp->if_snd)) { >> 518 ALTQ_ENQUEUE(&ifp->if_snd, m, NULL, error); >> 519 if (error) >> 520 ifp->if_snd.ifq_drops++; >> 521 IF_UNLOCK(&ifp->if_snd); >> 522 if (!error) { >> 523 ifp->if_obytes +=3D len; >> 524 if (mflags & (M_BCAST|M_MCAST)) >> 525 ifp->if_omcasts++; >> 526 >> 527 if ((ifp->if_drv_flags & IFF_DRV_OACTIVE) = =3D=3D >> 0) >> 528 epair_start_locked(ifp); >> 529 else >> 530 (void)epair_add_ifp_for_drain >> ing(ifp); >> 531 } >> 532 return (error); >> 533 } >> 534 IF_UNLOCK(&ifp->if_snd); >> 535 #endif >> >> > > Just apply manually this patch to make it work. > > diff --git a/sys/net/if_epair.c b/sys/net/if_epair.c > index 540f06c..04733a5 100644 > --- a/sys/net/if_epair.c > +++ b/sys/net/if_epair.c > @@ -827,9 +827,11 @@ epair_clone_create(struct if_clone *ifc, char *name, > size_t len, caddr_t params) > ifp->if_capabilities =3D IFCAP_VLAN_MTU; > ifp->if_capenable =3D IFCAP_VLAN_MTU; > ifp->if_start =3D epair_start; > + if_setstartfn(ifp, epair_start); > + if_setsendqlen(ifp, ifqmaxlen); > + if_setsendqready(ifp); > ifp->if_ioctl =3D epair_ioctl; > ifp->if_init =3D epair_init; > - ifp->if_snd.ifq_maxlen =3D ifqmaxlen; > /* Assign a hopefully unique, locally administered etheraddr. */ > eaddr[0] =3D 0x02; > eaddr[3] =3D (ifp->if_index >> 8) & 0xff; > @@ -852,10 +854,11 @@ epair_clone_create(struct if_clone *ifc, char *name= , > size_t len, caddr_t params) > ifp->if_flags =3D IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST; > ifp->if_capabilities =3D IFCAP_VLAN_MTU; > ifp->if_capenable =3D IFCAP_VLAN_MTU; > - ifp->if_start =3D epair_start; > + if_setstartfn(ifp, epair_start); > + if_setsendqlen(ifp, ifqmaxlen); > + if_setsendqready(ifp); > ifp->if_ioctl =3D epair_ioctl; > ifp->if_init =3D epair_init; > - ifp->if_snd.ifq_maxlen =3D ifqmaxlen; > /* We need to play some tricks here for the second interface. */ > strlcpy(name, epairname, len); > error =3D if_clone_create(name, len, (caddr_t)scb); > > > > > >> I have no idea that why it says that it doesn't support altq altough the >> source code contains ALTQ section. >> >> >> Regards >> =C3=96zkan KIRIK >> _______________________________________________ >> 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" > > > > > -- > Ermal > From owner-freebsd-net@freebsd.org Wed Mar 22 17:50:52 2017 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 8A552D18E13 for ; Wed, 22 Mar 2017 17:50:52 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 433091901; Wed, 22 Mar 2017 17:50:52 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: by mail-qk0-x234.google.com with SMTP id p64so162405298qke.1; Wed, 22 Mar 2017 10:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AJ0AN35Q2lTrQPpEANb/vaV6fNisAR5jElxiZxb0ACQ=; b=hDA06R9q+V2Mw1Q9wzmMcgwMJdPjwU5gFUpKIIrIa86L/U7fach8WtysEMcb84PA/r tsv6aKQCmXAZVZox5tsEHwBDKhTj2OVNpEzZyxbRoQpPQPos9F4W5Vwfq4H1iSovrc5x OrodRIqoVyzqgXgoftQsCB0IijSN+dpwqHiGqPGqr3o9rGZvOsy3vUvRMT9XKaiQeiSs r1lxXKGPk62LTrKzCapOYdlRq2KbdTvnESaD7WvUzekxSkvJKiZBYqpsZVLJ/wlXk50o vLRnnB+lUeLK32W8m/imqloG3XTYojv8xCBtyRbaefh6mKMGM8THolzb7N6diXQ4sLu9 kwqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AJ0AN35Q2lTrQPpEANb/vaV6fNisAR5jElxiZxb0ACQ=; b=ihZQZx3TFYlKnWfi7N45oNEqRsH/AqmHIsbis79+VtbWgNf07LeQu3GTD5Vmat9yad AQMaog6zd7EHNu/T/KMJGGUDxx5U7yNWgMGdvDrpH1UN3Eq8e3uBScv5pxds78L9Gwh1 JTbDPy9cRhgn5bLic54wej424q8skCFaSyEuGZhIFBQpR5Pe7UCZUOeo+tNLtDtIELrg isHLteEf2/UvYHnFeObIYKDYPGnhejmZ1q6bxRdf7JL6qfrn+E3JztyrGNYNUnklLUok qrQ3pSO/p5crKKUolokB/1nCfh/yq5fKCoj8OTnLb6D/HNu6tD8gBMo3CONiJ6b+3Jux A5wg== X-Gm-Message-State: AFeK/H3naIFCz4DMoVZn4DTAoMMMC/Ft/NXxH9vhPorB6O9jznLXaAHEqvrZtWZyM7YR95sv7zBGd/3G6+eBAQ== X-Received: by 10.55.131.68 with SMTP id f65mr36620875qkd.1.1490205050879; Wed, 22 Mar 2017 10:50:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.179.135 with HTTP; Wed, 22 Mar 2017 10:50:50 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Date: Wed, 22 Mar 2017 20:50:50 +0300 Message-ID: Subject: Re: if_epair altq support problem To: =?UTF-8?Q?Ermal_Lu=C3=A7i?= Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 22 Mar 2017 17:50:52 -0000 Sorry, I mistested on 10.3RELENG. it works on 11 RELENG, But at 10.3RELENG it throws /usr/src/sys/modules/if_epair/../../net/if_epair.c:830:2: error: implicit declaration of function 'if_setstartfn' is invalid in C99 [-Werror,-Wimplicit-function-declaration] On Wed, Mar 22, 2017 at 8:18 PM, =C3=96zkan KIRIK w= rote: > Thank You Ermal ! > > It works perfectly, can you commit this patch to 11.0 RELENG and MFC to > 10.3 RELENG ? > > Regards > > On Wed, Mar 22, 2017 at 6:59 AM, Ermal Lu=C3=A7i wrote: > >> >> >> On Tue, Mar 21, 2017 at 5:26 AM, =C3=96zkan KIRIK >> wrote: >> >>> Hello, >>> >>> I sent this email also to freebsd-pf list. But I think that the main >>> problem is belongs to sys/net/if_epair.c. >>> >>> I'm using FreeBSD 10.3-p17 amd64. epair pseudo device is listed as >>> supperted deviced at the Man page of altq(4). >>> From man page of altq : >>> >>> *SUPPORTED DEVICES * >>> >>> The driver modifications described in altq(9) >>> >> ropos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports> >>> are required to use a cer- >>> tain network card with *ALTQ*. They have been applied to th= e >>> following >>> hardware drivers: ae(4) >>> >> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>> age(4) >> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>> alc(4) >> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>> ale(4) >> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>> an(4) >> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>> ath(4) >> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>> aue(4) >> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>> axe(4) >> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>> bce(4) >> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>> bfe(4) >> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>> bge(4) >> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>> bxe(4) >> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>> cas(4) >> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>> cxgbe(4) >> propos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>> dc(4) >> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>> de(4) >> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>> ed(4) >> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>> em(4) >> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>> ep(4) >> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>> epair(4) >> propos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>> >>> .... >>> >>> But while trying to use it the system says that it's not suppoerted. I >>> tried on FreeBSD 11 also. The output is below: >>> >>> pf.conf : >>> altq on epair0b hfsc bandwidth 1Mb queue { ftp, ssh, icmp, other } >>> queue ftp bandwidth 30% priority 0 hfsc (upperlimit 99%) >>> queue ssh bandwidth 30% priority 2 hfsc (upperlimit 99%) >>> queue icmp bandwidth 10% priority 2 hfsc (upperlimit 99%) >>> queue other bandwidth 30% priority 1 hfsc (default upperlimit 99%) >>> >>> >>> # ifconfig epair0 create >>> # ifconfig epair0a up >>> # ifconfig epair0b up >>> # pfctl -f pf.conf >>> pfctl: epair0b: driver does not support altq >>> >>> # sysctl -a | grep ALTQ >>> options ALTQ_NOPCC >>> options ALTQ_PRIQ >>> options ALTQ_CDNR >>> options ALTQ_HFSC >>> options ALTQ_RIO >>> options ALTQ_RED >>> options ALTQ_CBQ >>> options ALTQ >>> >>> >>> I have a look on /usr/src/sys/net/if_epair.c, and found the ALTQ sectio= n: >>> >>> 514 #ifdef ALTQ >>> 515 /* Support ALTQ via the clasic if_start() path. */ >>> 516 IF_LOCK(&ifp->if_snd); >>> 517 if (ALTQ_IS_ENABLED(&ifp->if_snd)) { >>> 518 ALTQ_ENQUEUE(&ifp->if_snd, m, NULL, error); >>> 519 if (error) >>> 520 ifp->if_snd.ifq_drops++; >>> 521 IF_UNLOCK(&ifp->if_snd); >>> 522 if (!error) { >>> 523 ifp->if_obytes +=3D len; >>> 524 if (mflags & (M_BCAST|M_MCAST)) >>> 525 ifp->if_omcasts++; >>> 526 >>> 527 if ((ifp->if_drv_flags & IFF_DRV_OACTIVE) >>> =3D=3D 0) >>> 528 epair_start_locked(ifp); >>> 529 else >>> 530 (void)epair_add_ifp_for_drain >>> ing(ifp); >>> 531 } >>> 532 return (error); >>> 533 } >>> 534 IF_UNLOCK(&ifp->if_snd); >>> 535 #endif >>> >>> >> >> Just apply manually this patch to make it work. >> >> diff --git a/sys/net/if_epair.c b/sys/net/if_epair.c >> index 540f06c..04733a5 100644 >> --- a/sys/net/if_epair.c >> +++ b/sys/net/if_epair.c >> @@ -827,9 +827,11 @@ epair_clone_create(struct if_clone *ifc, char *name= , >> size_t len, caddr_t params) >> ifp->if_capabilities =3D IFCAP_VLAN_MTU; >> ifp->if_capenable =3D IFCAP_VLAN_MTU; >> ifp->if_start =3D epair_start; >> + if_setstartfn(ifp, epair_start); >> + if_setsendqlen(ifp, ifqmaxlen); >> + if_setsendqready(ifp); >> ifp->if_ioctl =3D epair_ioctl; >> ifp->if_init =3D epair_init; >> - ifp->if_snd.ifq_maxlen =3D ifqmaxlen; >> /* Assign a hopefully unique, locally administered etheraddr. */ >> eaddr[0] =3D 0x02; >> eaddr[3] =3D (ifp->if_index >> 8) & 0xff; >> @@ -852,10 +854,11 @@ epair_clone_create(struct if_clone *ifc, char >> *name, size_t len, caddr_t params) >> ifp->if_flags =3D IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST; >> ifp->if_capabilities =3D IFCAP_VLAN_MTU; >> ifp->if_capenable =3D IFCAP_VLAN_MTU; >> - ifp->if_start =3D epair_start; >> + if_setstartfn(ifp, epair_start); >> + if_setsendqlen(ifp, ifqmaxlen); >> + if_setsendqready(ifp); >> ifp->if_ioctl =3D epair_ioctl; >> ifp->if_init =3D epair_init; >> - ifp->if_snd.ifq_maxlen =3D ifqmaxlen; >> /* We need to play some tricks here for the second interface. */ >> strlcpy(name, epairname, len); >> error =3D if_clone_create(name, len, (caddr_t)scb); >> >> >> >> >> >>> I have no idea that why it says that it doesn't support altq altough th= e >>> source code contains ALTQ section. >>> >>> >>> Regards >>> =C3=96zkan KIRIK >>> _______________________________________________ >>> 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" >> >> >> >> >> -- >> Ermal >> > > From owner-freebsd-net@freebsd.org Wed Mar 22 20:44:38 2017 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 1E9C7D1865E for ; Wed, 22 Mar 2017 20:44:38 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::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 D671C1A06 for ; Wed, 22 Mar 2017 20:44:37 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: by mail-io0-x235.google.com with SMTP id z13so71826730iof.2 for ; Wed, 22 Mar 2017 13:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=n7hbI1mvWJySa3Dv0tr38B043eRoWfL09j613XjqJJI=; b=sf4rVsRrayZ4eYeNCHGADf1lMUeIX8QqxzC44N6LsAv4dg/Ff/3Tvc7507KyVT4Q/Z zQP7zGeE5iDSjaPOKud2BEgQWNYhYfnJUMyT+E0Kub4gsYB7e5MHoMxN7Ob38Lwy/44w JbhfoTaCDPaiqQ1+BHgz2w8zotdbrDWnf246gq/hx8bgYtXobLTUzVCEhbRGgNV0zqwZ bGM9ySf9kfldBeebliNEd8DUCkdTByhElaXxFvRZ+j2Qke1XT+ciLw3BMgFIA1piUvmX syzfikaQSvZF5Ng94CjS6Q+sFo/rrLmXkO3dee4yL/eCSG5bOgryZrikoAHMUgWQ5t6k ryKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=n7hbI1mvWJySa3Dv0tr38B043eRoWfL09j613XjqJJI=; b=OstYHdjXlo/ML6xM5pLwPBQJlQMvhZ4Idv1H4BWzFCgtOHO9m1uofTaL64YO3nv1j1 QnBT+B2ezLjaeu4Z1J/lkHsd5Z1mWGoJEI/cJ8yA9YzC5CZuAm7Y2wWzPPokwPvCKCEl MfOh+4torTK8A4KtS/CToGQUjlWlmu6dLH5O2IhZlhy8Ptchr+aNHAnnC8yxk89hMKfk lgumvvBS/8Ed1563vikkE1ukAB2Rv93OjFzcrjdDCyKiSw/9gtwNPgj+KkBw5tLpWWT1 6DI2GkKndfi6jPDmJNNV5hThKHaNzPOq7ThpLhPsOEXGSRMQhP8P8OR9R2PkOPACnpdV hk8g== X-Gm-Message-State: AFeK/H0qqY4eX72/psPo6Cby6iPaKR/yFXS3UO86Tz9Fcn3xONub1expkK6eBKvWFZxRnFoJarS88IAfk3mF9Q== X-Received: by 10.107.155.16 with SMTP id d16mr37982524ioe.125.1490215477105; Wed, 22 Mar 2017 13:44:37 -0700 (PDT) MIME-Version: 1.0 Sender: ermal.luci@gmail.com Received: by 10.107.149.135 with HTTP; Wed, 22 Mar 2017 13:44:36 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Ermal_Lu=C3=A7i?= Date: Wed, 22 Mar 2017 13:44:36 -0700 X-Google-Sender-Auth: OSuaARf4LsE8HKJMSVhN0zGd3ho Message-ID: Subject: Re: if_epair altq support problem To: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 22 Mar 2017 20:44:38 -0000 On Wed, Mar 22, 2017 at 10:50 AM, =C3=96zkan KIRIK = wrote: > Sorry, I mistested on 10.3RELENG. > it works on 11 RELENG, But at 10.3RELENG it throws > > /usr/src/sys/modules/if_epair/../../net/if_epair.c:830:2: error: implicit > declaration of function 'if_setstartfn' is invalid in C99 > [-Werror,-Wimplicit-function-declaration] > > > On Wed, Mar 22, 2017 at 8:18 PM, =C3=96zkan KIRIK > wrote: > >> Thank You Ermal ! >> >> It works perfectly, can you commit this patch to 11.0 RELENG and MFC to >> 10.3 RELENG ? >> >> Thanks, for confirming that it fixes your issues. Yeah, on 10.3 its almost the same fix i will deal with it. > Regards >> >> On Wed, Mar 22, 2017 at 6:59 AM, Ermal Lu=C3=A7i wrote= : >> >>> >>> >>> On Tue, Mar 21, 2017 at 5:26 AM, =C3=96zkan KIRIK >>> wrote: >>> >>>> Hello, >>>> >>>> I sent this email also to freebsd-pf list. But I think that the main >>>> problem is belongs to sys/net/if_epair.c. >>>> >>>> I'm using FreeBSD 10.3-p17 amd64. epair pseudo device is listed as >>>> supperted deviced at the Man page of altq(4). >>>> From man page of altq : >>>> >>>> *SUPPORTED DEVICES >>> >* >>>> >>>> The driver modifications described in altq(9) >>>> >>> ropos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports> >>>> are required to use a cer- >>>> tain network card with *ALTQ*. They have been applied to >>>> the following >>>> hardware drivers: ae(4) >>>> >>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>> age(4) >>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>> alc(4) >>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>> ale(4) >>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>> an(4) >>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>> ath(4) >>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>> aue(4) >>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>> axe(4) >>> an.cgi?query=3Daxe&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.0-RE >>>> LEASE+and+Ports>, >>>> bce(4) >>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>> bfe(4) >>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>> bge(4) >>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>> bxe(4) >>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>> cas(4) >>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>> cxgbe(4) >>> propos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>> dc(4) >>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>> de(4) >>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>> ed(4) >>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>> em(4) >>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>> ep(4) >>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>> epair(4) >>> propos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>> >>>> .... >>>> >>>> But while trying to use it the system says that it's not suppoerted. I >>>> tried on FreeBSD 11 also. The output is below: >>>> >>>> pf.conf : >>>> altq on epair0b hfsc bandwidth 1Mb queue { ftp, ssh, icmp, other } >>>> queue ftp bandwidth 30% priority 0 hfsc (upperlimit 99%) >>>> queue ssh bandwidth 30% priority 2 hfsc (upperlimit 99%) >>>> queue icmp bandwidth 10% priority 2 hfsc (upperlimit 99%) >>>> queue other bandwidth 30% priority 1 hfsc (default upperlimit 99%) >>>> >>>> >>>> # ifconfig epair0 create >>>> # ifconfig epair0a up >>>> # ifconfig epair0b up >>>> # pfctl -f pf.conf >>>> pfctl: epair0b: driver does not support altq >>>> >>>> # sysctl -a | grep ALTQ >>>> options ALTQ_NOPCC >>>> options ALTQ_PRIQ >>>> options ALTQ_CDNR >>>> options ALTQ_HFSC >>>> options ALTQ_RIO >>>> options ALTQ_RED >>>> options ALTQ_CBQ >>>> options ALTQ >>>> >>>> >>>> I have a look on /usr/src/sys/net/if_epair.c, and found the ALTQ >>>> section: >>>> >>>> 514 #ifdef ALTQ >>>> 515 /* Support ALTQ via the clasic if_start() path. */ >>>> 516 IF_LOCK(&ifp->if_snd); >>>> 517 if (ALTQ_IS_ENABLED(&ifp->if_snd)) { >>>> 518 ALTQ_ENQUEUE(&ifp->if_snd, m, NULL, error); >>>> 519 if (error) >>>> 520 ifp->if_snd.ifq_drops++; >>>> 521 IF_UNLOCK(&ifp->if_snd); >>>> 522 if (!error) { >>>> 523 ifp->if_obytes +=3D len; >>>> 524 if (mflags & (M_BCAST|M_MCAST)) >>>> 525 ifp->if_omcasts++; >>>> 526 >>>> 527 if ((ifp->if_drv_flags & IFF_DRV_OACTIVE) >>>> =3D=3D 0) >>>> 528 epair_start_locked(ifp); >>>> 529 else >>>> 530 (void)epair_add_ifp_for_drain >>>> ing(ifp); >>>> 531 } >>>> 532 return (error); >>>> 533 } >>>> 534 IF_UNLOCK(&ifp->if_snd); >>>> 535 #endif >>>> >>>> >>> >>> Just apply manually this patch to make it work. >>> >>> diff --git a/sys/net/if_epair.c b/sys/net/if_epair.c >>> index 540f06c..04733a5 100644 >>> --- a/sys/net/if_epair.c >>> +++ b/sys/net/if_epair.c >>> @@ -827,9 +827,11 @@ epair_clone_create(struct if_clone *ifc, char >>> *name, size_t len, caddr_t params) >>> ifp->if_capabilities =3D IFCAP_VLAN_MTU; >>> ifp->if_capenable =3D IFCAP_VLAN_MTU; >>> ifp->if_start =3D epair_start; >>> + if_setstartfn(ifp, epair_start); >>> + if_setsendqlen(ifp, ifqmaxlen); >>> + if_setsendqready(ifp); >>> ifp->if_ioctl =3D epair_ioctl; >>> ifp->if_init =3D epair_init; >>> - ifp->if_snd.ifq_maxlen =3D ifqmaxlen; >>> /* Assign a hopefully unique, locally administered etheraddr. *= / >>> eaddr[0] =3D 0x02; >>> eaddr[3] =3D (ifp->if_index >> 8) & 0xff; >>> @@ -852,10 +854,11 @@ epair_clone_create(struct if_clone *ifc, char >>> *name, size_t len, caddr_t params) >>> ifp->if_flags =3D IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST; >>> ifp->if_capabilities =3D IFCAP_VLAN_MTU; >>> ifp->if_capenable =3D IFCAP_VLAN_MTU; >>> - ifp->if_start =3D epair_start; >>> + if_setstartfn(ifp, epair_start); >>> + if_setsendqlen(ifp, ifqmaxlen); >>> + if_setsendqready(ifp); >>> ifp->if_ioctl =3D epair_ioctl; >>> ifp->if_init =3D epair_init; >>> - ifp->if_snd.ifq_maxlen =3D ifqmaxlen; >>> /* We need to play some tricks here for the second interface. *= / >>> strlcpy(name, epairname, len); >>> error =3D if_clone_create(name, len, (caddr_t)scb); >>> >>> >>> >>> >>> >>>> I have no idea that why it says that it doesn't support altq altough t= he >>>> source code contains ALTQ section. >>>> >>>> >>>> Regards >>>> =C3=96zkan KIRIK >>>> _______________________________________________ >>>> 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" >>> >>> >>> >>> >>> -- >>> Ermal >>> >> >> > --=20 Ermal From owner-freebsd-net@freebsd.org Thu Mar 23 10:55:19 2017 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 1FACED19389 for ; Thu, 23 Mar 2017 10:55:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0F42B255 for ; Thu, 23 Mar 2017 10:55:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2NAtIVu062018 for ; Thu, 23 Mar 2017 10:55:18 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 211643] ixgbe(4) does not reliably bring up 10G links with ZyXEL XS1920 switches Date: Thu, 23 Mar 2017 10:55:19 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.3-RELEASE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: pi@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.23 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, 23 Mar 2017 10:55:19 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211643 Kurt Jaeger changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pi@FreeBSD.org --- Comment #1 from Kurt Jaeger --- I see the same with a Supermicro X11SSZ-TLN4F against a Ubiquity EdgeSwitch= 16 XG copper port: https://www.ubnt.com/edgemax/edgeswitch-16-xg/ see also: https://forums.freebsd.org/threads/57536/ --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Mar 23 11:23:34 2017 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 6EEC4D1A001 for ; Thu, 23 Mar 2017 11:23:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5E7C9186D for ; Thu, 23 Mar 2017 11:23:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2NBNYPF043879 for ; Thu, 23 Mar 2017 11:23:34 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 211643] ixgbe(4) does not reliably bring up 10G links with ZyXEL XS1920 switches Date: Thu, 23 Mar 2017 11:23:34 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.3-RELEASE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: pi@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: 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.23 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, 23 Mar 2017 11:23:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211643 --- Comment #2 from Kurt Jaeger --- Ticket at Ubiquity https://help.ubnt.com/hc/requests/682423 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Mar 23 13:00:46 2017 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 4B649D182A6 for ; Thu, 23 Mar 2017 13:00:46 +0000 (UTC) (envelope-from Joe@stream-technologies.com) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0066.outbound.protection.outlook.com [104.47.2.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BD5BA129A for ; Thu, 23 Mar 2017 13:00:44 +0000 (UTC) (envelope-from Joe@stream-technologies.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=streamtechnologiesuk.onmicrosoft.com; s=selector1-streamtechnologies-com01e; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9SqpF7FjDv8ma6EwQeLCRdeZ5AemZmRJvHxkT4eOwrk=; b=LOerqFXZ6dPf6gqBC/AqyZrNoHLuK6hBK65cqjBQAzr3cn2eiAkHxl5Ana5zrZguEAu5jnREWXeHeEYeZnKm9KbTwL+D3q64nlrbj2q+9z3R2nL2S6T8sPJCXCcfOruffPh+oMl7Z3UitWCVYKXCkQEhFCuRZjUDUevhJFuHc54= Authentication-Results: freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=stream-technologies.com; Received: from [192.168.6.128] (212.20.240.118) by HE1PR07MB1034.eurprd07.prod.outlook.com (10.162.27.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Thu, 23 Mar 2017 13:00:41 +0000 To: From: Joe Jones Subject: cxgbe netmap promiscuous mode? Message-ID: <58D3C6F4.6010500@stream-technologies.com> Date: Thu, 23 Mar 2017 13:00:36 +0000 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-Originating-IP: [212.20.240.118] X-ClientProxiedBy: VI1P18901CA0018.EURP189.PROD.OUTLOOK.COM (10.173.66.156) To HE1PR07MB1034.eurprd07.prod.outlook.com (10.162.27.26) X-MS-Office365-Filtering-Correlation-Id: 029369ef-0b5a-469b-db89-08d471ec9cb4 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:HE1PR07MB1034; X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1034; 3:nBIGEC2/vqGlHwmVsQQhcdReiX8qbi/V64Li3cXs1gP0/Zs3zwE//m3zMwi7EoA4uXRzwbr3IyernXB4eZOmp5Wt2TT5cAF7b38opAwKMjstRW3XVRnpFGVxg6lVopZi0jC664nl0Iizxu0ERQo/I6Kh/NX3z1D+9JcV+399bQyZPjkiacnhOPorHyu3i/Js2o38ljYhp3s/naXhRHC+pmddQc+sZ70gkvV3A7UT8swMH9ext8NWGXHh52WVGXP72KLzjVFIiYNn9VsMZcE4Tw==; 25:kh7vlNu/JPUETbXlLjIr1QnV+7rzPeWguEw4TMc41fBoALjf37M/ANJlxwfygSLuxYyoLriy8m/UJa0BOsyfzSH+FjDWrpP22ywkJP64/odoCIXPUzUW9YecBLftVDC04n+f3WJ8MiD/tDIMOyDXxoG+GBWaLm4tbbBliuzCB7f/8Rs2BDqTc84KGcc4JYdelPdC4DCjbVZuLpSXJ/fJcox2xcxnWKLYdjguVIDY+/bwLUldKGdZBPe9wnweXiFD+PCiGfSoCk5VmFP01A7N1eh3HSdrCSMDnHXVKXlM9UVJ9A6TLJqkxpu2UklfFk6fzotgT+5Ly8GZXPehX+JlTWPzgRWR+MbjLFt1yuB3iki9k3Yj61bSed3hnEWuJiHDktzX5X4jTW0loQxGD7NhYXl/yPVbFyq4bKroVeG79eXK+oXzatz725gfgrPJu9CrSjvntjGs+L2ba9NvoZHtpw== X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1034; 31:r6EsqpjI1P+KSPjA6NYDxr8D43ZnLwUTKWpVyjxgQdz+84VNYDxsN9zWW2YxK9b0VxDdYjv9rpBt81SaQ5TxyYdMKN6zVBvNX7ZHNUG7FFlwnzZZvApfeA2kxWEXvyjidDbEjNaZwrvcWvWyQGcqeyJB20GWj+UU/ztFzVHspH/7aiClhILY8dsF/wU30/PZhcU3cQ0FejAbxHmsYZe+/9Fuah1rxj0Nd/JrWtnghXwRMuRKU0F8ta3TI74Iis0eOrumbkCqb/uCyaC+q0cz4qOxBjcHnGlolP1fOWEpLsY=; 4:wgMA0+qdmb0rqBxydBbVqHkfEL4ZrL4OWZZdTSbuaIIbZcaEJ0yvtIgOoe/A45XXIDxObTTeYQ70ZkbkjgbJ7WbskC96+5By516RCagxs3YApOjGqkI5UhYj7rgRO26r4XWIDcxpWlIvldxalva31YySWxqAUkqaMyokOGp7GNpRYUYNlCoP2usUle1FcVZeJdYk1TpDbexCLSJI+DsMJvkWf1JStimWOLUdICz03HRPt1OU4yZQQubroSSWxyJx122COgg2W/OiUW3/E2pb5XKPgKmavHQwSiCpUMPmlJUfPTeZijkl2kw6q1L9MwhaH3fwe1qbXMmw02hjSa0qFAnrwSK18J0k5JRD6Fx7if9wGdjlGgbGcROVsQsL5Hk1mdoLCBD5CouHisvyFIEThkmidRkFhiO1LWsbFOg4efmrdnyX1dZzIKS2LCq2XU57xrEDlQ9k1FzdEpNpxTHNvb51AvsYaR7FQhuWzNRy6sec6hYGZlQz95B8VlJ1jqynKGi1t/KleM2SqkJHe61I/ck3n3zECVq8SOjs+dc8xnUwlBLpGqJVTbBcvJMzcu3yN3W1T0zocvaGKM/lKk6SNDhW+3vBupWw/2zSaViMMsc= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(20161123558025)(6072148); SRVR:HE1PR07MB1034; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1034; X-Forefront-PRVS: 0255DF69B9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(6049001)(39450400003)(66654002)(90366009)(33656002)(81166006)(23676002)(3846002)(86362001)(6116002)(54356999)(65816999)(3480700004)(8676002)(50986999)(2351001)(77096006)(6486002)(230700001)(110136004)(38730400002)(36756003)(80792005)(4001350100001)(5660300001)(83506001)(305945005)(47776003)(7736002)(6666003)(2906002)(65956001)(66066001)(189998001)(59896002)(50466002)(117156001)(25786009)(53936002)(42186005)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB1034; H:[192.168.6.128]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3TUIxMDM0OzIzOi85MkdLQ3RJTlo1Rjd5Y24xRXo0ODhsbVVW?= =?utf-8?B?NFJnd1dvMkRlLzBIZWVYdHc2Vm1wU2dXeVRwU05wUGFpcmttOE1DUXZnRU5y?= =?utf-8?B?YVc3MUJ2ekFXVC9WWldSZWhlMVh6YjJCdCtxN0M5THhXU3o1Y1VEZUhuaHgv?= =?utf-8?B?eHFBVTNXeGhzTm1QU0RreC9QOXlFR1JtMzRVKy81QXpuNkNXVm1WTzBOTlN1?= =?utf-8?B?Ly9RbHlRSnFUTmxjajZ1UmZzekpzbVJQaklXVzhocks5c1MyOG9aTEdqY1g0?= =?utf-8?B?MkQ0aGtJZWdGWm5TRnZVWGg0aGpQRFV1NzhvZU5NVm5FL0VFbkNSUWpFcXF0?= =?utf-8?B?aWJVbm1pcG0yVE5YLy9hakdoc0s0K0gyeXNGUUk5cEVZcGZmSFc1UWw0eW5Y?= =?utf-8?B?SnJDVW10ZkI0TisxNFhoeW5HZXQreEFHb09jS1lDZzUxSXRxYmVtY0tsb2lM?= =?utf-8?B?djRmaEVxUUk5ZFdXTkUrZ3F3NUZNM1NLNm0rVVI4VkJic0YyU2VsT1B1UDdO?= =?utf-8?B?NkdQS0haOUJEclVjUXNITVFhaWxLelQwVkZ0WVNHczFNM3hLWFZwODVYckc4?= =?utf-8?B?MHhCeG0xWmJRUWp5RWQ0NkRaMCtla2k0WUVGY1N0SnVCYnRwVWliaExwS0xw?= =?utf-8?B?NUdIMmxIejliQTJjejBtREdZand5cUhyWmQzTnFEaVliYWJjYmR2S1ZVZjNU?= =?utf-8?B?dzBSVWxqeStna0hTUkdwdWdUSXd3L2wrc0hYY2NLU2RXbS9BdGdVZUMxU05s?= =?utf-8?B?NmlpT1EwTjNTSjY1elhYOSt2S1JBZzNUSGI4U1luaEtpZzU0WmlpcUprK0Vq?= =?utf-8?B?UXJPTjBOSnNsdXkyOGwxUHpubm5sTi93bFpRUDZleldiRlpqVWY3cExvYU9P?= =?utf-8?B?TGVoaXRpZ3Myc1UrVHpscldlZ000MmF2TE1tUk9TQ0hvZ05id3dZSVJZS1cv?= =?utf-8?B?YjlHNDRkNllZY1JQc3BDZzMvWHRJZEpjZE00S3o2QVhYZmpyTzd3V1ZjaGZj?= =?utf-8?B?eDhRWGpETldaYnRHTVM5SmZtYXk0SFNoWGZLTXRqWTF4cE5tVndRbHFBK2ZG?= =?utf-8?B?NUhTYkFqTVExQXZCUzRsclNSN2NyUE1KMWUzbml4MjJDekpBU3lHcGhPMW9G?= =?utf-8?B?c2VBTW15Uk1jTEdOcUhhaGZRUjJWSHMvK1ZDdUJFMzJnWVduWldMZ3ZJdnRQ?= =?utf-8?B?ZnlkMnpBRzFtSkhzTWMwMFptbXVySXFIcitMT1o0VjFPTXdMYkhDVHZkRStU?= =?utf-8?B?VmNsK2tja24vNXd0ZkFYSk1pR1VEcE0wU3FNTGlVZ0p3WmdPL2VJVUo5aE5M?= =?utf-8?B?M1l2VGlqeTVMQU5PdXpPcFVhdGtSR2ttaDE2SEtpYjdmTFpLUTRUelBqYVd5?= =?utf-8?B?ZVphZmFoWFcxY3REZ05qa2sxb1J6VmFwK0xSbFIxTUY5Z0Uvc04ySzBTVEUx?= =?utf-8?Q?QXl5zDnlhOIifOrcggY26BnrE4M?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1034; 6:gU6Ta+zKhDCWh/5mmOT5PlQOZxKqI6wVlKVdSrA/c5+R+ZeelAZKUHSANZck/0+ZZJ43GzF1aR4NRTP+89YfpAhd3CZ6UZ9V2rM49lq5AQgTPykMaPd7B2QbrtkrNfbu7tTbIsJttpTFu0tel4c2GtSNOb7mYkDWKy7Jkq6S9+RcgOGYuHjYMQYi11l24agAysDXvxLXkCLyXQr0XNXJK6eTnoLjenDhnqUdsxNqTeebZ60SO2tOEmFv83RG9zoY5j5K+3TC30AA83tSHJkbguVI6g+4QdoWqmBmifT8YpA4lgG8RpvjiXjVOeiCYaPTsO+fWr4+lptG9xm6XZiyKN5XoGG4jo0fpNlGWzxNhlFzezQsmsuhkW1BVGmWNfudeHk0GU+j28mNZQ+CuamEGg==; 5:WH5hzif7UjhBwOH12ImbrF0u4sL/Wb5f6CCXdLJkFRzxEA1ZHOx5mbrWoV4Xv6s7NetdF1hhNc2/GdZb56zDqkCse29NvXqepHvzuybfNZNRIHGKKo6c7TFw8fQ8OyAQlygf4rPSgBPN/uJQFijCaw==; 24:mxsipLQGfOPOOp6wOBGOXQp1LwcrwEmERPfBuez7feJnlmSgujKevlWY/hTm6hu33kPlLiSruVjz1twsx57BObf1aQS9kkYm2aDzKf3bp9c= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1034; 7:HrUTmCa4QvkFKnS1YaOfBB2nP+UfbYxIfv35tHDZVloDTuzDsu+g0UnK5klGKS1j8RFaPCaqlYCJP2Vc2HAxC35fDE5fO1H6EVTaZJ1S1TRaa7fSiaNwrXS0WXNSMFCPi2thQRJhUIHwFinNIQd1pZ8X6ed5J94xnWWVqnsIbJ4trZSYU/stzCiiCp8BeLIKlOMQWzaiIiBoQnAl55k6Idvl/j6pJZVsZYRxvjhmP7L3zgqp1tzXtq53yHwuLHdlUkdAsrW99E2fSxorBBMVPbKskcBPL/+oZpVJF7Etk+frXu9VFlBxwFyORiHerontJfBGkhb7KjmTuupTBpyr+w== X-OriginatorOrg: stream-technologies.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Mar 2017 13:00:41.8819 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1034 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 23 Mar 2017 13:00:46 -0000 Hello, We have a T520-SO and have made a new install of 11.0, to begin with the box would panic every time we tried to switch the card into netmap mode. So we recompiled the kernel with netmap removed, then compiled the netmap kernel module from github, as this in our experience generally leads to a more stable netmap. we have uname -a FreeBSD goose2 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 #0: Wed Mar 22 16:52:35 UTC 2017 joe@goose2:/usr/obj/usr/src/sys/GENERIC amd64 and the following in /boot/loader.conf t4fw_cfg_load="YES" t5fw_cfg_load="YES" if_cxgbe_load="YES" hw.cxgbe.fl_pktshift=0 hw.cxgbe.toecaps_allowed=0 hw.cxgbe.nnmtxq10g=8 hw.cxgbe.nnmrxq10g=8 hw.cxgbe.num_vis=2 Before I run our application I run ifconfig cxl1 promisc -vlanhwtag up Now our application can now start without panicking the kernel. Here is where it gets interesting, our application is able to announce it's self via ARP, I can see the ethernet switch learning which port it's on, and other hosts adding it to their ARP tables. When I try an ICMP ping it goes missing. After watching the TX packet graph for the connected port on the switch while starting and stopping a flood ping to the application, I'm sure the packets are getting sent to the card, however I don't see them in the netmap ring. If I kill our application, then use ifconfig to create and configure a vlan port I can confirm that the card is working and has connectivity. Here's what I think is happening. ARP requests are received because they are sent to the broadcast address. Our application then announces it's self. However traffic destined for the application is send to a MAC address which is neither the broadcast or the MAC programed into the hardware and is dropped. My understanding of promiscuous it that it informs the card that we want these dropped packets. It looks to me like, when the card is in netmap mode the promisc flag is being ignored. I have also tried using freebsd-update to update to p8. As with the p0 kernel we get a panic when we switch the card into netmap mode. We did previously have these cards working in netmap mode. We were using a pre 11 snapshot of the svn head though . Many Thanks Joe Jones Stream Technologies From owner-freebsd-net@freebsd.org Thu Mar 23 14:02:45 2017 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 9756CD19B69 for ; Thu, 23 Mar 2017 14:02:45 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward4p.cmail.yandex.net (forward4p.cmail.yandex.net [IPv6:2a02:6b8:0:1465::14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1B19018E1; Thu, 23 Mar 2017 14:02:44 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp2p.mail.yandex.net (smtp2p.mail.yandex.net [77.88.29.85]) by forward4p.cmail.yandex.net (Yandex) with ESMTP id A019720D12; Thu, 23 Mar 2017 17:02:31 +0300 (MSK) Received: from smtp2p.mail.yandex.net (localhost.localdomain [127.0.0.1]) by smtp2p.mail.yandex.net (Yandex) with ESMTP id 9B9781A80092; Thu, 23 Mar 2017 17:02:23 +0300 (MSK) Received: by smtp2p.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 4VsbccFCUt-2JiKDvbh; Thu, 23 Mar 2017 17:02:19 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1490277739; bh=kGkGpoeDdidqv45pyL9v865QNOdWyge1IGfS0R2Nq6M=; h=Subject:To:References:Cc:From:Message-ID:Date:In-Reply-To; b=Gc/X0B7zNdJbEilYeYc4Ie72qWdHIUe8si1CWC+yCZrTBcZXLwE7msAcGUfzD4Qe3 IzEaHB5cBGKWOe0aM99pPQEguFSgGJH7yQ8PuXQSEPpytoxlZSpSsMpT3eh02djH0q EYrilZCbbhyVhFFAXxpHFVfFTkS+bqG6aWanyGx8= Authentication-Results: smtp2p.mail.yandex.net; dkim=pass header.i=@yandex.ru X-Yandex-Suid-Status: 1 0,1 0,1 0,1 0,1 0,1 0,1 0 Subject: Re: LLE reference leak in the L2 cache To: Mike Karels References: <201703140840.v2E8ecH2040827@mail.karels.net> <3a4c5d87-d42e-5615-5d2b-2a8801376600@yandex.ru> <70D2287B-664C-48E4-9E8B-68B574BE6CE6@karels.net> Cc: Eugene Grosbein , freebsd-net@FreeBSD.org, George Neville-Neil , "Alexander V. Chernikov" , karels@FreeBSD.org, =?UTF-8?Q?Olivier_Cochard-Labb=c3=a9?= From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Message-ID: <18768a71-3169-469a-f3c3-b9c9e544ff6b@yandex.ru> Date: Thu, 23 Mar 2017 17:02:07 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DCn7JwDqN4diIFwVbARFL3I5WvTEpTkx8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 23 Mar 2017 14:02:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DCn7JwDqN4diIFwVbARFL3I5WvTEpTkx8 Content-Type: multipart/mixed; boundary="G7SoA0K46AlP3qxWoAJSncMEGO5PC5SqI"; protected-headers="v1" From: "Andrey V. Elsukov" To: Mike Karels Cc: Eugene Grosbein , freebsd-net@FreeBSD.org, George Neville-Neil , "Alexander V. Chernikov" , karels@FreeBSD.org, =?UTF-8?Q?Olivier_Cochard-Labb=c3=a9?= Message-ID: <18768a71-3169-469a-f3c3-b9c9e544ff6b@yandex.ru> Subject: Re: LLE reference leak in the L2 cache References: <201703140840.v2E8ecH2040827@mail.karels.net> <3a4c5d87-d42e-5615-5d2b-2a8801376600@yandex.ru> <70D2287B-664C-48E4-9E8B-68B574BE6CE6@karels.net> In-Reply-To: --G7SoA0K46AlP3qxWoAJSncMEGO5PC5SqI Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 20.03.2017 03:46, Mike Karels wrote: > The context has gotten messy here, so I=E2=80=99m going to break down a= nd top-post. >=20 > I started review https://reviews.freebsd.org/D10059 with a fix for the > reference-count leak. > It changes the semantics so only routes within an in_pcb automatically > do L2 caching. >=20 > I=E2=80=99ll put the tcp_output change for V6 in a separate review when= this one > is done. >=20 > Andrey, could you try your iperf test again? Thanks, Hi Mike, The test with IPv6 works without reference leak now, as supposed, because it doesn't use LLE cache :) For IPv4 forwarding the problem seems also fixed, but I did only basic test. --=20 WBR, Andrey V. Elsukov --G7SoA0K46AlP3qxWoAJSncMEGO5PC5SqI-- --DCn7JwDqN4diIFwVbARFL3I5WvTEpTkx8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAljT1V8ACgkQAcXqBBDI oXpiRwgAiNCkhLpZ3UmqraduJ4AmlCUD4+AWzlVWf5BnYahI7hdhZwKsLvODqykm IHznT5XB9H2IFQr5dQsYoAuv7c1f5DceioLNhUMrsoBCiC8IO0DEiYpjNGdCrcjz uOa8z52U3ed1z2YobTzy5Y/uVag4ygoHj8fwMjGweg32aqHvcnWBLHo33oIcZpGL l4KbMiFTng1CNr2YtaCyuQcmKIuremBF7UNXUhkCyb3LiUIUVAy3JsysmdU8ky8J p0XN7bylo9eTwD8k4Cen7Af1Lb6+5H+aZUVhxxpradw1VByg8C+2heelbNMZDZxS SmJDx/fWitolP74k0cQJH0wgdleJBg== =M+Rl -----END PGP SIGNATURE----- --DCn7JwDqN4diIFwVbARFL3I5WvTEpTkx8-- From owner-freebsd-net@freebsd.org Thu Mar 23 14:25:15 2017 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 04A8FD1A234 for ; Thu, 23 Mar 2017 14:25:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DEA541623 for ; Thu, 23 Mar 2017 14:25: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 v2NEPE2Q022052 for ; Thu, 23 Mar 2017 14:25:14 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 211643] ixgbe(4) does not reliably bring up 10G links with ZyXEL XS1920 switches Date: Thu, 23 Mar 2017 14:25:14 +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-RELEASE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: pi@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: 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.23 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, 23 Mar 2017 14:25:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211643 --- Comment #3 from Kurt Jaeger --- Ticket with supermicro: SM1703233787 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Mar 23 18:06:44 2017 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 EBBF0D1A2A5 for ; Thu, 23 Mar 2017 18:06:44 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 A1C781515; Thu, 23 Mar 2017 18:06:44 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: by mail-qt0-x22d.google.com with SMTP id r45so182331346qte.3; Thu, 23 Mar 2017 11:06:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=c3Z51nxhfSOFHIMsop6UhaPDqqAz3rqKUc21hOZn+ow=; b=s+yBBgdXM92LQMNHb/wvKDYt+6Ik2yJSigUryNKxyaAuR7xsJfoecYK0gdwC1ZzPi4 Ymhfkk/Lia1mGkTJLh4va5jvAfBpnWkKqMzrBXzptLH6g5o8mBAI4Uf9ulhYRgKCtlCy Y+/p3f8AVuA7FPKUuA8BaneUwTEsHuNl9fo60W+lq8V1e016kZj5tj06CSkMx4inpesi kkVoLLE5c7qyPJyUGKSXadbMCc/1zbOb5ACyBIGlltr5N+5loRPhxbGo/u5dxu3IqwOp gwxIgMowB2UH6wyq+q/vFrMsdPba1TZSK6CdPzg0hFvCll96Ac8vp83qESOKPLtLdObw /VXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=c3Z51nxhfSOFHIMsop6UhaPDqqAz3rqKUc21hOZn+ow=; b=axsV1AYJsPONKgVXD5j/0uTvI/raE7PUMZsqyyVPHhZHhUzlQkPSlIn9/87SFYTzIA 5uYNXcpQ23yMR0Aez0W0N+SqzPqkDvyuofGUWsr8SpisePwQ1eUuOkMa7+e9vajuq8nq VpMR/11pof8At/CdE0NKkKruGi623yiUPDN/P3rTTtbq3jAiLtcFVrZOopZLtcA30IPE RaP6e4h5CkDFPBbMoFrPYuxFHv9dypPM/oG3/XXvJaAPMcip73bJN3FiRizFcKdzIsgn PMN0NloSvEW26BxaFeUoj2JEnnTK/+dVDolP8x4ldzvBzh1vB8Y5P9+NNU/rRP/953+A CqEg== X-Gm-Message-State: AFeK/H2lQhLM4B5vS4lpvL+1k8JOzdIo7m7WnjeTSC4NB+jIvPHjMi3jYYzrA4Xsl9WMWhpfR//x/TX5q4ZmrA== X-Received: by 10.200.44.116 with SMTP id e49mr3909193qta.243.1490292403198; Thu, 23 Mar 2017 11:06:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.179.135 with HTTP; Thu, 23 Mar 2017 11:06:42 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Date: Thu, 23 Mar 2017 21:06:42 +0300 Message-ID: Subject: Re: if_epair altq support problem To: =?UTF-8?Q?Ermal_Lu=C3=A7i?= Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 23 Mar 2017 18:06:45 -0000 Thank you, I'm waiting for 10.3 fix :) have a nice day On Wed, Mar 22, 2017 at 11:44 PM, Ermal Lu=C3=A7i wrote: > > On Wed, Mar 22, 2017 at 10:50 AM, =C3=96zkan KIRIK > wrote: > >> Sorry, I mistested on 10.3RELENG. >> it works on 11 RELENG, But at 10.3RELENG it throws >> >> /usr/src/sys/modules/if_epair/../../net/if_epair.c:830:2: error: >> implicit declaration of function 'if_setstartfn' is invalid in C99 >> [-Werror,-Wimplicit-function-declaration] >> >> >> On Wed, Mar 22, 2017 at 8:18 PM, =C3=96zkan KIRIK >> wrote: >> >>> Thank You Ermal ! >>> >>> It works perfectly, can you commit this patch to 11.0 RELENG and MFC to >>> 10.3 RELENG ? >>> >>> > Thanks, for confirming that it fixes your issues. > Yeah, on 10.3 its almost the same fix i will deal with it. > > >> Regards >>> >>> On Wed, Mar 22, 2017 at 6:59 AM, Ermal Lu=C3=A7i wrot= e: >>> >>>> >>>> >>>> On Tue, Mar 21, 2017 at 5:26 AM, =C3=96zkan KIRIK >>>> wrote: >>>> >>>>> Hello, >>>>> >>>>> I sent this email also to freebsd-pf list. But I think that the main >>>>> problem is belongs to sys/net/if_epair.c. >>>>> >>>>> I'm using FreeBSD 10.3-p17 amd64. epair pseudo device is listed as >>>>> supperted deviced at the Man page of altq(4). >>>>> From man page of altq : >>>>> >>>>> *SUPPORTED DEVICES >>>> >* >>>>> >>>>> The driver modifications described in altq(9) >>>>> >>>> ropos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports> >>>>> are required to use a cer- >>>>> tain network card with *ALTQ*. They have been applied to >>>>> the following >>>>> hardware drivers: ae(4) >>>>> >>>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>> age(4) >>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>> alc(4) >>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>> ale(4) >>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>> an(4) >>>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>> ath(4) >>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>> aue(4) >>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>> axe(4) >>>> an.cgi?query=3Daxe&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.0-RE >>>>> LEASE+and+Ports>, >>>>> bce(4) >>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>> bfe(4) >>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>> bge(4) >>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>> bxe(4) >>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>> cas(4) >>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>> cxgbe(4) >>>> propos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>> dc(4) >>>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>> de(4) >>>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>> ed(4) >>>> an.cgi?query=3Ded&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.0-REL >>>>> EASE+and+Ports>, >>>>> em(4) >>>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>> ep(4) >>>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>> epair(4) >>>> propos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>> >>>>> .... >>>>> >>>>> But while trying to use it the system says that it's not suppoerted. = I >>>>> tried on FreeBSD 11 also. The output is below: >>>>> >>>>> pf.conf : >>>>> altq on epair0b hfsc bandwidth 1Mb queue { ftp, ssh, icmp, other } >>>>> queue ftp bandwidth 30% priority 0 hfsc (upperlimit 99%) >>>>> queue ssh bandwidth 30% priority 2 hfsc (upperlimit 99%) >>>>> queue icmp bandwidth 10% priority 2 hfsc (upperlimit 99%) >>>>> queue other bandwidth 30% priority 1 hfsc (default upperlimit 99%) >>>>> >>>>> >>>>> # ifconfig epair0 create >>>>> # ifconfig epair0a up >>>>> # ifconfig epair0b up >>>>> # pfctl -f pf.conf >>>>> pfctl: epair0b: driver does not support altq >>>>> >>>>> # sysctl -a | grep ALTQ >>>>> options ALTQ_NOPCC >>>>> options ALTQ_PRIQ >>>>> options ALTQ_CDNR >>>>> options ALTQ_HFSC >>>>> options ALTQ_RIO >>>>> options ALTQ_RED >>>>> options ALTQ_CBQ >>>>> options ALTQ >>>>> >>>>> >>>>> I have a look on /usr/src/sys/net/if_epair.c, and found the ALTQ >>>>> section: >>>>> >>>>> 514 #ifdef ALTQ >>>>> 515 /* Support ALTQ via the clasic if_start() path. */ >>>>> 516 IF_LOCK(&ifp->if_snd); >>>>> 517 if (ALTQ_IS_ENABLED(&ifp->if_snd)) { >>>>> 518 ALTQ_ENQUEUE(&ifp->if_snd, m, NULL, error); >>>>> 519 if (error) >>>>> 520 ifp->if_snd.ifq_drops++; >>>>> 521 IF_UNLOCK(&ifp->if_snd); >>>>> 522 if (!error) { >>>>> 523 ifp->if_obytes +=3D len; >>>>> 524 if (mflags & (M_BCAST|M_MCAST)) >>>>> 525 ifp->if_omcasts++; >>>>> 526 >>>>> 527 if ((ifp->if_drv_flags & IFF_DRV_OACTIVE= ) >>>>> =3D=3D 0) >>>>> 528 epair_start_locked(ifp); >>>>> 529 else >>>>> 530 (void)epair_add_ifp_for_drain >>>>> ing(ifp); >>>>> 531 } >>>>> 532 return (error); >>>>> 533 } >>>>> 534 IF_UNLOCK(&ifp->if_snd); >>>>> 535 #endif >>>>> >>>>> >>>> >>>> Just apply manually this patch to make it work. >>>> >>>> diff --git a/sys/net/if_epair.c b/sys/net/if_epair.c >>>> index 540f06c..04733a5 100644 >>>> --- a/sys/net/if_epair.c >>>> +++ b/sys/net/if_epair.c >>>> @@ -827,9 +827,11 @@ epair_clone_create(struct if_clone *ifc, char >>>> *name, size_t len, caddr_t params) >>>> ifp->if_capabilities =3D IFCAP_VLAN_MTU; >>>> ifp->if_capenable =3D IFCAP_VLAN_MTU; >>>> ifp->if_start =3D epair_start; >>>> + if_setstartfn(ifp, epair_start); >>>> + if_setsendqlen(ifp, ifqmaxlen); >>>> + if_setsendqready(ifp); >>>> ifp->if_ioctl =3D epair_ioctl; >>>> ifp->if_init =3D epair_init; >>>> - ifp->if_snd.ifq_maxlen =3D ifqmaxlen; >>>> /* Assign a hopefully unique, locally administered etheraddr. = */ >>>> eaddr[0] =3D 0x02; >>>> eaddr[3] =3D (ifp->if_index >> 8) & 0xff; >>>> @@ -852,10 +854,11 @@ epair_clone_create(struct if_clone *ifc, char >>>> *name, size_t len, caddr_t params) >>>> ifp->if_flags =3D IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST; >>>> ifp->if_capabilities =3D IFCAP_VLAN_MTU; >>>> ifp->if_capenable =3D IFCAP_VLAN_MTU; >>>> - ifp->if_start =3D epair_start; >>>> + if_setstartfn(ifp, epair_start); >>>> + if_setsendqlen(ifp, ifqmaxlen); >>>> + if_setsendqready(ifp); >>>> ifp->if_ioctl =3D epair_ioctl; >>>> ifp->if_init =3D epair_init; >>>> - ifp->if_snd.ifq_maxlen =3D ifqmaxlen; >>>> /* We need to play some tricks here for the second interface. = */ >>>> strlcpy(name, epairname, len); >>>> error =3D if_clone_create(name, len, (caddr_t)scb); >>>> >>>> >>>> >>>> >>>> >>>>> I have no idea that why it says that it doesn't support altq altough >>>>> the >>>>> source code contains ALTQ section. >>>>> >>>>> >>>>> Regards >>>>> =C3=96zkan KIRIK >>>>> _______________________________________________ >>>>> 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= " >>>> >>>> >>>> >>>> >>>> -- >>>> Ermal >>>> >>> >>> >> > > > -- > Ermal > From owner-freebsd-net@freebsd.org Thu Mar 23 18:20:42 2017 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 4564ED1A9DF for ; Thu, 23 Mar 2017 18:20:42 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 03CDA1FF1 for ; Thu, 23 Mar 2017 18:20:42 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-ot0-x22a.google.com with SMTP id a12so123583122ota.0 for ; Thu, 23 Mar 2017 11:20:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9qcUhwERearcaIDvmy9HEbJZ8OgdYBwZTAk8MsrOlsE=; b=AFBivKnkJtrrtJIiG8CiIM1uhgFQMk3gOULwX4PQSF4WbRNeqnKV0EvP5T82RnqffQ yH2T+sT227/KYsuKof8pzN+V+brDwN6MovHxVFfzDmQZ5zA7mRK2zP6GVvGS5fupoxu9 Hqu1fJh0bfDRakwBs4CIf/t5k9rB1+9S4rWrBrYXEuYf+RjKuQsCPGpPQBCo+ZhQX19C oJJwvCYrLYILlE8m8MLUiaAREaq9XaGF0djtTL3DjonzWu84TOYjXdzfLVQor4c+ZPOi 1UXEOuXXTIuJy43GXQXU+YLFRohUBTTwsDWF25yeIWBTbhrItdCGGPZ2EvNJntbGUo7h l1Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9qcUhwERearcaIDvmy9HEbJZ8OgdYBwZTAk8MsrOlsE=; b=bRgcElAwd2SfXbUw4FjXv7VyLec1ungGUI/IEcAMumpJAd+GkmCo8lcLmcnm6lEQs4 Gz7WG+dF6pVbzgNiU7gBgynRSfwS7AvmMTFp4UTc5sm0ofUMD/xsJEh7Si4PlwKsP79i Min2F5hy3POKvKA3HybwMrossysd6aTibpkd7qov7bPCvht8mz5l8NyHNJFmWFFZJU57 k8oi3d+jo6qo+N55awcgX8Kcipbkc+zd8g+uwmeJod6M5f9W9cq8CQMSXTaEn4HFICiv AX8E1C7AVZISgHtwEp/e90twzeEV5Xi/RrlfcqyYteV+lr/hHnDs4rJFPL23rLjLJpcJ Ix8A== X-Gm-Message-State: AFeK/H0C/cJuychvu83KqhGzWiWnznuoW0je1EiDwEGfVfxOA/rZMjKf9gLUdKSpxciW55i4yUdqK9sNBoBdPA== X-Received: by 10.157.52.116 with SMTP id v107mr287768otb.61.1490293241290; Thu, 23 Mar 2017 11:20:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.50.45 with HTTP; Thu, 23 Mar 2017 11:20:40 -0700 (PDT) In-Reply-To: <58D3C6F4.6010500@stream-technologies.com> References: <58D3C6F4.6010500@stream-technologies.com> From: Vincenzo Maffione Date: Thu, 23 Mar 2017 19:20:40 +0100 Message-ID: Subject: Re: cxgbe netmap promiscuous mode? To: Joe Jones Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 23 Mar 2017 18:20:42 -0000 Hi, You could try to use netmap in emulated mode (sysctl dev.netmap.admode=2). If this works, at least you know that the problem is in the cxgbe netmap support and not in the netmap core itself. Cheers, Vincenzo 2017-03-23 14:00 GMT+01:00 Joe Jones : > Hello, > > We have a T520-SO and have made a new install of 11.0, to begin with the > box would panic every time we tried to switch the card into netmap mode. So > we recompiled the kernel with netmap removed, then compiled the netmap > kernel module from github, as this in our experience generally leads to a > more stable netmap. > > we have > > uname -a > FreeBSD goose2 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 #0: Wed Mar 22 > 16:52:35 UTC 2017 joe@goose2:/usr/obj/usr/src/sys/GENERIC amd64 > > and the following in /boot/loader.conf > > t4fw_cfg_load="YES" > t5fw_cfg_load="YES" > if_cxgbe_load="YES" > hw.cxgbe.fl_pktshift=0 > hw.cxgbe.toecaps_allowed=0 > hw.cxgbe.nnmtxq10g=8 > hw.cxgbe.nnmrxq10g=8 > hw.cxgbe.num_vis=2 > > Before I run our application I run > > ifconfig cxl1 promisc -vlanhwtag up > > Now our application can now start without panicking the kernel. Here is > where it gets interesting, our application is able to announce it's self > via ARP, I can see the ethernet switch learning which port it's on, and > other hosts adding it to their ARP tables. When I try an ICMP ping it goes > missing. After watching the TX packet graph for the connected port on the > switch while starting and stopping a flood ping to the application, I'm > sure the packets are getting sent to the card, however I don't see them in > the netmap ring. If I kill our application, then use ifconfig to create and > configure a vlan port I can confirm that the card is working and has > connectivity. > > Here's what I think is happening. ARP requests are received because they > are sent to the broadcast address. Our application then announces it's > self. However traffic destined for the application is send to a MAC address > which is neither the broadcast or the MAC programed into the hardware and > is dropped. My understanding of promiscuous it that it informs the card > that we want these dropped packets. It looks to me like, when the card is > in netmap mode the promisc flag is being ignored. > > I have also tried using freebsd-update to update to p8. As with the p0 > kernel we get a panic when we switch the card into netmap mode. > > We did previously have these cards working in netmap mode. We were using a > pre 11 snapshot of the svn head though . > > Many Thanks > > Joe Jones > Stream Technologies > > _______________________________________________ > 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" > -- Vincenzo Maffione From owner-freebsd-net@freebsd.org Thu Mar 23 18:38:50 2017 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 AA72DD1A0B7 for ; Thu, 23 Mar 2017 18:38:50 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e: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 7E1B61C40 for ; Thu, 23 Mar 2017 18:38:50 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: by mail-pg0-x22f.google.com with SMTP id w20so25419779pgc.0 for ; Thu, 23 Mar 2017 11:38:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MZEZ7eraxmGS0M14CDjRXI4iKQL8YwYQmecwiA4XfKg=; b=OMUfvqrKvjN+ROhybRnCNuOT37PtbhX1Qe2/SpCMywonHbT3PtwsCJRLSxiYpfEXTs Y9wmX8qu0/G8oEhdokTGX5Z8g/DClxHfA28mG+7Z8W9fGNY/b3kMLlY/vbloQJro3uJv dhgKRZSrY2cBjjybDQC0iRYoXOB5fKSdEmAw0g2yJBgHA7eLti2wDm3lbsMkjKu5j+i5 JWe9GB/nXzjvEEDPvPo7209dM0lk9ijeNkCytJzYoUtG+dTTCHcXmjBOem6+rZeguUvd O2cuY8bItgvIUu+L3s3Me/IcE0edxRRp7Y0jTxIjtj6XNHnOlhsl5XgJMYzN9vTafmLX L4aA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MZEZ7eraxmGS0M14CDjRXI4iKQL8YwYQmecwiA4XfKg=; b=Dn3RPWimABXguBZgBmfU1+0NtFF7bOdPKXUEFreZmWjhKTpEidpsPVHEquR0614WrQ /DrIueNQBhCGrwhBAE/cl4JCyTcxxjL7M4ivXpcaj8TM4gubLA5j6AkuxDM/Na+RrKOX WxeTsIndkDYl5s09CH+dlLMNLzTX8WKaKo0leXSo4zQaqsNI+qzk9t9So1xFpWQUVdEa 7djzwrs4SwGP611qC9B7GQtarKVtWfeJ8FtJ34ZsQmT1vJjFIyih+KFLUP7Sk67mI7W5 nq1/mH7yi5dm3GHrpIj8+pq+eTdY+D525N+/5qOQwa7LAcJJiRVzSm+xbUrABKEFooSx U81w== X-Gm-Message-State: AFeK/H113JpLLSsIlb5AuTo649PR6eV/6AaBAhMUFyIi/IjXQmvFlDD7HYSpX8s9s33W/8b/F6J6Khi1I/omUA== X-Received: by 10.98.54.196 with SMTP id d187mr4712935pfa.33.1490294330053; Thu, 23 Mar 2017 11:38:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.168.13 with HTTP; Thu, 23 Mar 2017 11:38:49 -0700 (PDT) In-Reply-To: <58D3C6F4.6010500@stream-technologies.com> References: <58D3C6F4.6010500@stream-technologies.com> From: Navdeep Parhar Date: Thu, 23 Mar 2017 11:38:49 -0700 Message-ID: Subject: Re: cxgbe netmap promiscuous mode? To: Joe Jones Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 23 Mar 2017 18:38:50 -0000 Your netmap application should be using the 'vcxl' interface, not the cxl interface. Even though they share a physical port they have different MAC addresses and are totally autonomous. The peer should use the vcxl interface's MAC if it wants to reach the netmap application. Do you have the panic message and stack? I know of a couple of panics that have been fixed in -STABLE -- one was one related to emulated mode and the second one was an illegal lock acquisition. Regards, Navdeep On Thu, Mar 23, 2017 at 6:00 AM, Joe Jones wrote: > Hello, > > We have a T520-SO and have made a new install of 11.0, to begin with the box > would panic every time we tried to switch the card into netmap mode. So we > recompiled the kernel with netmap removed, then compiled the netmap kernel > module from github, as this in our experience generally leads to a more > stable netmap. > > we have > > uname -a > FreeBSD goose2 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 #0: Wed Mar 22 > 16:52:35 UTC 2017 joe@goose2:/usr/obj/usr/src/sys/GENERIC amd64 > > and the following in /boot/loader.conf > > t4fw_cfg_load="YES" > t5fw_cfg_load="YES" > if_cxgbe_load="YES" > hw.cxgbe.fl_pktshift=0 > hw.cxgbe.toecaps_allowed=0 > hw.cxgbe.nnmtxq10g=8 > hw.cxgbe.nnmrxq10g=8 > hw.cxgbe.num_vis=2 > > Before I run our application I run > > ifconfig cxl1 promisc -vlanhwtag up > > Now our application can now start without panicking the kernel. Here is > where it gets interesting, our application is able to announce it's self via > ARP, I can see the ethernet switch learning which port it's on, and other > hosts adding it to their ARP tables. When I try an ICMP ping it goes > missing. After watching the TX packet graph for the connected port on the > switch while starting and stopping a flood ping to the application, I'm sure > the packets are getting sent to the card, however I don't see them in the > netmap ring. If I kill our application, then use ifconfig to create and > configure a vlan port I can confirm that the card is working and has > connectivity. > > Here's what I think is happening. ARP requests are received because they are > sent to the broadcast address. Our application then announces it's self. > However traffic destined for the application is send to a MAC address which > is neither the broadcast or the MAC programed into the hardware and is > dropped. My understanding of promiscuous it that it informs the card that we > want these dropped packets. It looks to me like, when the card is in netmap > mode the promisc flag is being ignored. > > I have also tried using freebsd-update to update to p8. As with the p0 > kernel we get a panic when we switch the card into netmap mode. > > We did previously have these cards working in netmap mode. We were using a > pre 11 snapshot of the svn head though . > > Many Thanks > > Joe Jones > Stream Technologies > > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@freebsd.org Thu Mar 23 18:46:55 2017 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 45294D1A3C5 for ; Thu, 23 Mar 2017 18:46:55 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001: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 1133C1234 for ; Thu, 23 Mar 2017 18:46:55 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: by mail-io0-x229.google.com with SMTP id z13so3176332iof.2 for ; Thu, 23 Mar 2017 11:46:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=+AAb/ObeFdbg1HYC4oHnbbwpn5YXAxyBJfS5ITu8zns=; b=ITjDtlPuHZVkj4WSCD89dPrtOKo9gSvFXdbOrjoJvCbQC/VQ5NqlA7lOE+4gFc/0le aGnSzPZGMI37zBa6vGZULXlUs1DIctSdBazIMKVawIljDNjcHQsEDGsp5L/XT8c6ATT5 lH0+D78h3Ympe7ksVq++2FcqdE4QBR7EsTcLah70FwVPQ8GmL2n1Nlp8zQq0sixlUU++ u2QxyGT75gb2ptendIK/U43AbDntB8PLlVYdXZppNK/kEcDenn/q7KrHXzYO6s/xIRjf peiaVrvIWK59/8HQViXQgzGcBAe7bPzhCVGiYdcB4GrVmYclDUSC0po2egXCJlfgdLmE ZtFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=+AAb/ObeFdbg1HYC4oHnbbwpn5YXAxyBJfS5ITu8zns=; b=amzZR02Zmi73VPoSqGkmNOEgduB8oqvaqWMkqsH955/tx6fH/6Nw5JzS3mtH+wVBbl 4PONvj/9jNU0/FWOBSHJIiJsIRrCsbZ+E1o7TCO/JTDhTzuDC/b0Rqiq4AxrXbDTl3Db 6HloAeNkUwy1aTT1mfl6U4xNxM88a8rNa1uD/g5Qax74UxwxpwPNbz4FGQbVKD2sOm3i ljSZbPfYaC4zEwQPYsDHbusIb23xEnRH0SfJ+Xp9E1eOocYD3OCjfopSfoSfXvL9ZPwO +eu5pRSa/XoilzaVicX3VLkib2h3M0iy+rs3ZbXQC18Kkf+jFPoLaMvX6Ivh0tm23PK/ w10A== X-Gm-Message-State: AFeK/H3sSmq7co0XacoXVTYWbHyR3K5QA0xR/QbdXxHXNU9t+B693ixp5hFJVLi9jiDOmtBYu8gpIxj53HOOsg== X-Received: by 10.107.155.16 with SMTP id d16mr4061999ioe.125.1490294814426; Thu, 23 Mar 2017 11:46:54 -0700 (PDT) MIME-Version: 1.0 Sender: ermal.luci@gmail.com Received: by 10.107.149.135 with HTTP; Thu, 23 Mar 2017 11:46:53 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Ermal_Lu=C3=A7i?= Date: Thu, 23 Mar 2017 11:46:53 -0700 X-Google-Sender-Auth: qPI4HsJPlI_a8eMTTfqO9Wldql8 Message-ID: Subject: Re: if_epair altq support problem To: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 23 Mar 2017 18:46:55 -0000 On Thu, Mar 23, 2017 at 11:06 AM, =C3=96zkan KIRIK = wrote: > Thank you, I'm waiting for 10.3 fix :) > have a nice day > This should work for 10.3++ diff --git a/sys/net/if_epair.c b/sys/net/if_epair.c index 540f06c..d028a95 100644 --- a/sys/net/if_epair.c +++ b/sys/net/if_epair.c @@ -829,7 +829,8 @@ epair_clone_create(struct if_clone *ifc, char *name, size_t len, caddr_t params) ifp->if_start =3D epair_start; ifp->if_ioctl =3D epair_ioctl; ifp->if_init =3D epair_init; - ifp->if_snd.ifq_maxlen =3D ifqmaxlen; + IFQ_SET_MAXLEN(&ifp->if_snd, ifqmaxlen); + IFQ_SET_READY(&ifp->if_snd); /* Assign a hopefully unique, locally administered etheraddr. */ eaddr[0] =3D 0x02; eaddr[3] =3D (ifp->if_index >> 8) & 0xff; @@ -855,7 +856,8 @@ epair_clone_create(struct if_clone *ifc, char *name, size_t len, caddr_t params) ifp->if_start =3D epair_start; ifp->if_ioctl =3D epair_ioctl; ifp->if_init =3D epair_init; - ifp->if_snd.ifq_maxlen =3D ifqmaxlen; + IFQ_SET_MAXLEN(&ifp->if_snd, ifqmaxlen); + IFQ_SET_READY(&ifp->if_snd); /* We need to play some tricks here for the second interface. */ strlcpy(name, epairname, len); error =3D if_clone_create(name, len, (caddr_t)scb); On Wed, Mar 22, 2017 at 11:44 PM, Ermal Lu=C3=A7i wrote: > >> >> On Wed, Mar 22, 2017 at 10:50 AM, =C3=96zkan KIRIK >> wrote: >> >>> Sorry, I mistested on 10.3RELENG. >>> it works on 11 RELENG, But at 10.3RELENG it throws >>> >>> /usr/src/sys/modules/if_epair/../../net/if_epair.c:830:2: error: >>> implicit declaration of function 'if_setstartfn' is invalid in C99 >>> [-Werror,-Wimplicit-function-declaration] >>> >>> >>> On Wed, Mar 22, 2017 at 8:18 PM, =C3=96zkan KIRIK >>> wrote: >>> >>>> Thank You Ermal ! >>>> >>>> It works perfectly, can you commit this patch to 11.0 RELENG and MFC t= o >>>> 10.3 RELENG ? >>>> >>>> >> Thanks, for confirming that it fixes your issues. >> Yeah, on 10.3 its almost the same fix i will deal with it. >> >> >>> Regards >>>> >>>> On Wed, Mar 22, 2017 at 6:59 AM, Ermal Lu=C3=A7i wro= te: >>>> >>>>> >>>>> >>>>> On Tue, Mar 21, 2017 at 5:26 AM, =C3=96zkan KIRIK >>>>> wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> I sent this email also to freebsd-pf list. But I think that the mai= n >>>>>> problem is belongs to sys/net/if_epair.c. >>>>>> >>>>>> I'm using FreeBSD 10.3-p17 amd64. epair pseudo device is listed as >>>>>> supperted deviced at the Man page of altq(4). >>>>>> From man page of altq : >>>>>> >>>>>> *SUPPORTED DEVICES >>>>> an.cgi?query=3Daltq#end>* >>>>>> >>>>>> The driver modifications described in altq(9) >>>>>> >>>>> ropos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports> >>>>>> are required to use a cer- >>>>>> tain network card with *ALTQ*. They have been applied to >>>>>> the following >>>>>> hardware drivers: ae(4) >>>>>> >>>>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>> age(4) >>>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>> alc(4) >>>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>> ale(4) >>>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>> an(4) >>>>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>> ath(4) >>>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>> aue(4) >>>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>> axe(4) >>>>> an.cgi?query=3Daxe&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.0-RE >>>>>> LEASE+and+Ports>, >>>>>> bce(4) >>>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>> bfe(4) >>>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>> bge(4) >>>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>> bxe(4) >>>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>> cas(4) >>>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>> cxgbe(4) >>>>> propos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>> dc(4) >>>>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>> de(4) >>>>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>> ed(4) >>>>> an.cgi?query=3Ded&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.0-REL >>>>>> EASE+and+Ports>, >>>>>> em(4) >>>>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>> ep(4) >>>>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>> epair(4) >>>>> propos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>> >>>>>> .... >>>>>> >>>>>> But while trying to use it the system says that it's not suppoerted.= I >>>>>> tried on FreeBSD 11 also. The output is below: >>>>>> >>>>>> pf.conf : >>>>>> altq on epair0b hfsc bandwidth 1Mb queue { ftp, ssh, icmp, other } >>>>>> queue ftp bandwidth 30% priority 0 hfsc (upperlimit 99%) >>>>>> queue ssh bandwidth 30% priority 2 hfsc (upperlimit 99%) >>>>>> queue icmp bandwidth 10% priority 2 hfsc (upperlimit 99%) >>>>>> queue other bandwidth 30% priority 1 hfsc (default upperlimit 99%) >>>>>> >>>>>> >>>>>> # ifconfig epair0 create >>>>>> # ifconfig epair0a up >>>>>> # ifconfig epair0b up >>>>>> # pfctl -f pf.conf >>>>>> pfctl: epair0b: driver does not support altq >>>>>> >>>>>> # sysctl -a | grep ALTQ >>>>>> options ALTQ_NOPCC >>>>>> options ALTQ_PRIQ >>>>>> options ALTQ_CDNR >>>>>> options ALTQ_HFSC >>>>>> options ALTQ_RIO >>>>>> options ALTQ_RED >>>>>> options ALTQ_CBQ >>>>>> options ALTQ >>>>>> >>>>>> >>>>>> I have a look on /usr/src/sys/net/if_epair.c, and found the ALTQ >>>>>> section: >>>>>> >>>>>> 514 #ifdef ALTQ >>>>>> 515 /* Support ALTQ via the clasic if_start() path. */ >>>>>> 516 IF_LOCK(&ifp->if_snd); >>>>>> 517 if (ALTQ_IS_ENABLED(&ifp->if_snd)) { >>>>>> 518 ALTQ_ENQUEUE(&ifp->if_snd, m, NULL, error); >>>>>> 519 if (error) >>>>>> 520 ifp->if_snd.ifq_drops++; >>>>>> 521 IF_UNLOCK(&ifp->if_snd); >>>>>> 522 if (!error) { >>>>>> 523 ifp->if_obytes +=3D len; >>>>>> 524 if (mflags & (M_BCAST|M_MCAST)) >>>>>> 525 ifp->if_omcasts++; >>>>>> 526 >>>>>> 527 if ((ifp->if_drv_flags & >>>>>> IFF_DRV_OACTIVE) =3D=3D 0) >>>>>> 528 epair_start_locked(ifp); >>>>>> 529 else >>>>>> 530 (void)epair_add_ifp_for_drain >>>>>> ing(ifp); >>>>>> 531 } >>>>>> 532 return (error); >>>>>> 533 } >>>>>> 534 IF_UNLOCK(&ifp->if_snd); >>>>>> 535 #endif >>>>>> >>>>>> >>>>> >>>>> Just apply manually this patch to make it work. >>>>> >>>>> diff --git a/sys/net/if_epair.c b/sys/net/if_epair.c >>>>> index 540f06c..04733a5 100644 >>>>> --- a/sys/net/if_epair.c >>>>> +++ b/sys/net/if_epair.c >>>>> @@ -827,9 +827,11 @@ epair_clone_create(struct if_clone *ifc, char >>>>> *name, size_t len, caddr_t params) >>>>> ifp->if_capabilities =3D IFCAP_VLAN_MTU; >>>>> ifp->if_capenable =3D IFCAP_VLAN_MTU; >>>>> ifp->if_start =3D epair_start; >>>>> + if_setstartfn(ifp, epair_start); >>>>> + if_setsendqlen(ifp, ifqmaxlen); >>>>> + if_setsendqready(ifp); >>>>> ifp->if_ioctl =3D epair_ioctl; >>>>> ifp->if_init =3D epair_init; >>>>> - ifp->if_snd.ifq_maxlen =3D ifqmaxlen; >>>>> /* Assign a hopefully unique, locally administered etheraddr. >>>>> */ >>>>> eaddr[0] =3D 0x02; >>>>> eaddr[3] =3D (ifp->if_index >> 8) & 0xff; >>>>> @@ -852,10 +854,11 @@ epair_clone_create(struct if_clone *ifc, char >>>>> *name, size_t len, caddr_t params) >>>>> ifp->if_flags =3D IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST= ; >>>>> ifp->if_capabilities =3D IFCAP_VLAN_MTU; >>>>> ifp->if_capenable =3D IFCAP_VLAN_MTU; >>>>> - ifp->if_start =3D epair_start; >>>>> + if_setstartfn(ifp, epair_start); >>>>> + if_setsendqlen(ifp, ifqmaxlen); >>>>> + if_setsendqready(ifp); >>>>> ifp->if_ioctl =3D epair_ioctl; >>>>> ifp->if_init =3D epair_init; >>>>> - ifp->if_snd.ifq_maxlen =3D ifqmaxlen; >>>>> /* We need to play some tricks here for the second interface. >>>>> */ >>>>> strlcpy(name, epairname, len); >>>>> error =3D if_clone_create(name, len, (caddr_t)scb); >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> I have no idea that why it says that it doesn't support altq altough >>>>>> the >>>>>> source code contains ALTQ section. >>>>>> >>>>>> >>>>>> Regards >>>>>> =C3=96zkan KIRIK >>>>>> _______________________________________________ >>>>>> freebsd-net@freebsd.org mailing list >>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-net >>>>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.or= g >>>>>> " >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Ermal >>>>> >>>> >>>> >>> >> >> >> -- >> Ermal >> > > --=20 Ermal From owner-freebsd-net@freebsd.org Thu Mar 23 19:16:12 2017 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 CB8EECBA672 for ; Thu, 23 Mar 2017 19:16:12 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 828FD1FE3; Thu, 23 Mar 2017 19:16:12 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: by mail-qt0-x234.google.com with SMTP id i34so184439233qtc.0; Thu, 23 Mar 2017 12:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PnaAMduy2BCGNgles2Nffa63nbt0h9Di7mIMorVztlA=; b=Kpb/SilIX925nrE8cUmIaAMNPDyAsK2FwITh17pK6B/AYpw/1SE/dNPJZyjLCdCqM0 77GK+B8cEY3h/g6c9IzhTedNmaFbkxonGxJd2nTji+4/zxiRYIxC/6IBFqbGmAVBEs2N zhK2niBwIG+NzdRlSkq2+RGnCv3Omwxem6m0X5lhwyb0fIq2Eb79UvqiLpgFvAnDvGgn onuZ+MjUz5NLUrkIxC1wxSjnCk5V/KWu1YZs2Em2W0J0SHpYb4H7tZe5TYEH0NELj8at KAiDdd2qxekXhFsT9BHaf1zHzb1dCV47q5pYKKGh0x/4o8GtDrsuO5BzeDx6qf0eY3LV fMCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PnaAMduy2BCGNgles2Nffa63nbt0h9Di7mIMorVztlA=; b=WDNcnTmMOFG65fP22zeS0CjUp+SGhwJ0EvVfqXd2AU2QaGG7xLCgNWhS/Mzdk3F9M4 GDNoOyzATJcSMyHmjGiXugmKODSuSnzT2N+2+XbTavVvUAelNb0H9pFThXkclBaeTQYJ qkx+GS29vSdzf67Tr4XZ9L0gxPjcKmjQ1ZrZ5hVsjYKQ1XPHyB8RtS4LTMOJcjdknG9Y uNjsOrZPl/x8zb9sFL0Zapa+jMue73SBZ+aVez3BY6zQl/NZf8mERmlRv3Dw1x+Mc/2T kU8j/9ZQrvahTgFxLm6dy/Xiw6jMChBeFkwnd2AUKT1n5zEkfenbLlnt3UOBTRl9BEor BIFA== X-Gm-Message-State: AFeK/H1nsPdcLE/mYg64ZY87TO/q571T3BLAE3+RSj+cunSMKRWxym8DScRXWU7kh8wcqZQrVR4YYDyONgVShA== X-Received: by 10.200.40.42 with SMTP id 39mr3952123qtq.149.1490296571112; Thu, 23 Mar 2017 12:16:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.179.135 with HTTP; Thu, 23 Mar 2017 12:16:10 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Date: Thu, 23 Mar 2017 22:16:10 +0300 Message-ID: Subject: Re: if_epair altq support problem To: =?UTF-8?Q?Ermal_Lu=C3=A7i?= Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 23 Mar 2017 19:16:12 -0000 Ermal thank you again, It compiles but pf still says that "pfctl: epair0b: driver does not support altq" :/ On Thu, Mar 23, 2017 at 9:46 PM, Ermal Lu=C3=A7i wrote: > > On Thu, Mar 23, 2017 at 11:06 AM, =C3=96zkan KIRIK > wrote: > >> Thank you, I'm waiting for 10.3 fix :) >> have a nice day >> > > > This should work for 10.3++ > > diff --git a/sys/net/if_epair.c b/sys/net/if_epair.c > index 540f06c..d028a95 100644 > --- a/sys/net/if_epair.c > +++ b/sys/net/if_epair.c > @@ -829,7 +829,8 @@ epair_clone_create(struct if_clone *ifc, char *name, > size_t len, caddr_t params) > ifp->if_start =3D epair_start; > ifp->if_ioctl =3D epair_ioctl; > ifp->if_init =3D epair_init; > - ifp->if_snd.ifq_maxlen =3D ifqmaxlen; > + IFQ_SET_MAXLEN(&ifp->if_snd, ifqmaxlen); > + IFQ_SET_READY(&ifp->if_snd); > /* Assign a hopefully unique, locally administered etheraddr. */ > eaddr[0] =3D 0x02; > eaddr[3] =3D (ifp->if_index >> 8) & 0xff; > @@ -855,7 +856,8 @@ epair_clone_create(struct if_clone *ifc, char *name, > size_t len, caddr_t params) > ifp->if_start =3D epair_start; > ifp->if_ioctl =3D epair_ioctl; > ifp->if_init =3D epair_init; > - ifp->if_snd.ifq_maxlen =3D ifqmaxlen; > + IFQ_SET_MAXLEN(&ifp->if_snd, ifqmaxlen); > + IFQ_SET_READY(&ifp->if_snd); > /* We need to play some tricks here for the second interface. */ > strlcpy(name, epairname, len); > error =3D if_clone_create(name, len, (caddr_t)scb); > > > > On Wed, Mar 22, 2017 at 11:44 PM, Ermal Lu=C3=A7i wrote= : >> >>> >>> On Wed, Mar 22, 2017 at 10:50 AM, =C3=96zkan KIRIK >>> wrote: >>> >>>> Sorry, I mistested on 10.3RELENG. >>>> it works on 11 RELENG, But at 10.3RELENG it throws >>>> >>>> /usr/src/sys/modules/if_epair/../../net/if_epair.c:830:2: error: >>>> implicit declaration of function 'if_setstartfn' is invalid in C99 >>>> [-Werror,-Wimplicit-function-declaration] >>>> >>>> >>>> On Wed, Mar 22, 2017 at 8:18 PM, =C3=96zkan KIRIK >>>> wrote: >>>> >>>>> Thank You Ermal ! >>>>> >>>>> It works perfectly, can you commit this patch to 11.0 RELENG and MFC >>>>> to 10.3 RELENG ? >>>>> >>>>> >>> Thanks, for confirming that it fixes your issues. >>> Yeah, on 10.3 its almost the same fix i will deal with it. >>> >>> >>>> Regards >>>>> >>>>> On Wed, Mar 22, 2017 at 6:59 AM, Ermal Lu=C3=A7i wr= ote: >>>>> >>>>>> >>>>>> >>>>>> On Tue, Mar 21, 2017 at 5:26 AM, =C3=96zkan KIRIK >>>>>> wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I sent this email also to freebsd-pf list. But I think that the ma= in >>>>>>> problem is belongs to sys/net/if_epair.c. >>>>>>> >>>>>>> I'm using FreeBSD 10.3-p17 amd64. epair pseudo device is listed as >>>>>>> supperted deviced at the Man page of altq(4). >>>>>>> From man page of altq : >>>>>>> >>>>>>> *SUPPORTED DEVICES >>>>>> an.cgi?query=3Daltq#end>* >>>>>>> >>>>>>> The driver modifications described in altq(9) >>>>>>> >>>>>> ropos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports> >>>>>>> are required to use a cer- >>>>>>> tain network card with *ALTQ*. They have been applied t= o >>>>>>> the following >>>>>>> hardware drivers: ae(4) >>>>>>> >>>>>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>> age(4) >>>>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>> alc(4) >>>>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>> ale(4) >>>>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>> an(4) >>>>>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>> ath(4) >>>>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>> aue(4) >>>>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>> axe(4) >>>>>> an.cgi?query=3Daxe&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.0-R= E >>>>>>> LEASE+and+Ports>, >>>>>>> bce(4) >>>>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>> bfe(4) >>>>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>> bge(4) >>>>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>> bxe(4) >>>>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>> cas(4) >>>>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>> cxgbe(4) >>>>>> an.cgi?query=3Dcxgbe&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.0= - >>>>>>> RELEASE+and+Ports>, >>>>>>> dc(4) >>>>>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>> de(4) >>>>>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>> ed(4) >>>>>> an.cgi?query=3Ded&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.0-RE= L >>>>>>> EASE+and+Ports>, >>>>>>> em(4) >>>>>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>> ep(4) >>>>>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>> epair(4) >>>>>> an.cgi?query=3Depair&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.0= - >>>>>>> RELEASE+and+Ports>, >>>>>>> >>>>>>> .... >>>>>>> >>>>>>> But while trying to use it the system says that it's not suppoerted= . >>>>>>> I >>>>>>> tried on FreeBSD 11 also. The output is below: >>>>>>> >>>>>>> pf.conf : >>>>>>> altq on epair0b hfsc bandwidth 1Mb queue { ftp, ssh, icmp, other } >>>>>>> queue ftp bandwidth 30% priority 0 hfsc (upperlimit 99%) >>>>>>> queue ssh bandwidth 30% priority 2 hfsc (upperlimit 99%) >>>>>>> queue icmp bandwidth 10% priority 2 hfsc (upperlimit 99%) >>>>>>> queue other bandwidth 30% priority 1 hfsc (default upperlimit 99%) >>>>>>> >>>>>>> >>>>>>> # ifconfig epair0 create >>>>>>> # ifconfig epair0a up >>>>>>> # ifconfig epair0b up >>>>>>> # pfctl -f pf.conf >>>>>>> pfctl: epair0b: driver does not support altq >>>>>>> >>>>>>> # sysctl -a | grep ALTQ >>>>>>> options ALTQ_NOPCC >>>>>>> options ALTQ_PRIQ >>>>>>> options ALTQ_CDNR >>>>>>> options ALTQ_HFSC >>>>>>> options ALTQ_RIO >>>>>>> options ALTQ_RED >>>>>>> options ALTQ_CBQ >>>>>>> options ALTQ >>>>>>> >>>>>>> >>>>>>> I have a look on /usr/src/sys/net/if_epair.c, and found the ALTQ >>>>>>> section: >>>>>>> >>>>>>> 514 #ifdef ALTQ >>>>>>> 515 /* Support ALTQ via the clasic if_start() path. */ >>>>>>> 516 IF_LOCK(&ifp->if_snd); >>>>>>> 517 if (ALTQ_IS_ENABLED(&ifp->if_snd)) { >>>>>>> 518 ALTQ_ENQUEUE(&ifp->if_snd, m, NULL, error); >>>>>>> 519 if (error) >>>>>>> 520 ifp->if_snd.ifq_drops++; >>>>>>> 521 IF_UNLOCK(&ifp->if_snd); >>>>>>> 522 if (!error) { >>>>>>> 523 ifp->if_obytes +=3D len; >>>>>>> 524 if (mflags & (M_BCAST|M_MCAST)) >>>>>>> 525 ifp->if_omcasts++; >>>>>>> 526 >>>>>>> 527 if ((ifp->if_drv_flags & >>>>>>> IFF_DRV_OACTIVE) =3D=3D 0) >>>>>>> 528 epair_start_locked(ifp); >>>>>>> 529 else >>>>>>> 530 (void)epair_add_ifp_for_drain >>>>>>> ing(ifp); >>>>>>> 531 } >>>>>>> 532 return (error); >>>>>>> 533 } >>>>>>> 534 IF_UNLOCK(&ifp->if_snd); >>>>>>> 535 #endif >>>>>>> >>>>>>> >>>>>> >>>>>> Just apply manually this patch to make it work. >>>>>> >>>>>> diff --git a/sys/net/if_epair.c b/sys/net/if_epair.c >>>>>> index 540f06c..04733a5 100644 >>>>>> --- a/sys/net/if_epair.c >>>>>> +++ b/sys/net/if_epair.c >>>>>> @@ -827,9 +827,11 @@ epair_clone_create(struct if_clone *ifc, char >>>>>> *name, size_t len, caddr_t params) >>>>>> ifp->if_capabilities =3D IFCAP_VLAN_MTU; >>>>>> ifp->if_capenable =3D IFCAP_VLAN_MTU; >>>>>> ifp->if_start =3D epair_start; >>>>>> + if_setstartfn(ifp, epair_start); >>>>>> + if_setsendqlen(ifp, ifqmaxlen); >>>>>> + if_setsendqready(ifp); >>>>>> ifp->if_ioctl =3D epair_ioctl; >>>>>> ifp->if_init =3D epair_init; >>>>>> - ifp->if_snd.ifq_maxlen =3D ifqmaxlen; >>>>>> /* Assign a hopefully unique, locally administered etheraddr= . >>>>>> */ >>>>>> eaddr[0] =3D 0x02; >>>>>> eaddr[3] =3D (ifp->if_index >> 8) & 0xff; >>>>>> @@ -852,10 +854,11 @@ epair_clone_create(struct if_clone *ifc, char >>>>>> *name, size_t len, caddr_t params) >>>>>> ifp->if_flags =3D IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAS= T; >>>>>> ifp->if_capabilities =3D IFCAP_VLAN_MTU; >>>>>> ifp->if_capenable =3D IFCAP_VLAN_MTU; >>>>>> - ifp->if_start =3D epair_start; >>>>>> + if_setstartfn(ifp, epair_start); >>>>>> + if_setsendqlen(ifp, ifqmaxlen); >>>>>> + if_setsendqready(ifp); >>>>>> ifp->if_ioctl =3D epair_ioctl; >>>>>> ifp->if_init =3D epair_init; >>>>>> - ifp->if_snd.ifq_maxlen =3D ifqmaxlen; >>>>>> /* We need to play some tricks here for the second interface= . >>>>>> */ >>>>>> strlcpy(name, epairname, len); >>>>>> error =3D if_clone_create(name, len, (caddr_t)scb); >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> I have no idea that why it says that it doesn't support altq altoug= h >>>>>>> the >>>>>>> source code contains ALTQ section. >>>>>>> >>>>>>> >>>>>>> Regards >>>>>>> =C3=96zkan KIRIK >>>>>>> _______________________________________________ >>>>>>> freebsd-net@freebsd.org mailing list >>>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-net >>>>>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freeb >>>>>>> sd.org" >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Ermal >>>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> Ermal >>> >> >> > > > -- > Ermal > From owner-freebsd-net@freebsd.org Thu Mar 23 19:57:41 2017 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 A5600CA108F for ; Thu, 23 Mar 2017 19:57:41 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 66C711B09 for ; Thu, 23 Mar 2017 19:57:41 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: by mail-it0-x233.google.com with SMTP id 190so4192468itm.0 for ; Thu, 23 Mar 2017 12:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=R1vs91MSFxMjszD34ySHCHTJaP5I4OgKjSMwf3wUF7k=; b=pD7DskSQbKBJpNfgCTzvOjX9gP5M8wPR3elVgmxKtCLMCJmpaRvR2gkUiJqx5e4gvX yam6fkIWwkrgfhmmtZWcmT6rtTNQAX7bffqq9Y7vK+5sGhcLIYu7Lfn4H/89zvY3Q8Y2 +u41QdhOAMl7igVfqNfZqG99b116Ddn2whrFMTqnMqwL+ub1JPd5ZfASF6thjWJzj1H2 mNUVZrVqHBt0B8OVQp7aEhHe8jlZLP7YrmbIJkmGFhBadSAzC2RryHhaKuYlILp+IqAD NBPVqKosFUgHzpARVLWKjyfazgpbJ9AvBWYr7Wi72CkXkA1TWqIh9FAvzfQusz2vGKI8 5k2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=R1vs91MSFxMjszD34ySHCHTJaP5I4OgKjSMwf3wUF7k=; b=jh1rTFaSKJvf/6Km2Snnkam6E997niJDrguyZBMxTCTbPTv5njEOYVU10RUnD4N4K2 QqtJXLpGUq8X1/A5sYQLbocL+uX5ZTwgqFA4PZSzF1sL9AOcEj25pfqHd4IT/j8InjyM LjOs6KT3wIMaXgLTkPcIiZU0U0z1zIUGgOwy6FcY+N7HeUJ1qQwlORnRDmOsKsB8EDyr yBW80IxHHvP76SPd3OXwpT5nHIBLzcsfTC543u3aK1yIwRmx4sUNJLNxomorN2WW562f BHK7RkOIybJauvWe28qXh9mZggku0s3CTeJs2rJ8azyKhbfnmcqm7MSyp4sp+MOtHRGe KSfQ== X-Gm-Message-State: AFeK/H2xl8AXSU8WT2XlpCbLTYKhPqaoJJgTYIN6FDn595xMbK1TQ8ts69cSbhKZyiIsKCuvUxmkmPb9RB0lZQ== X-Received: by 10.36.86.142 with SMTP id o136mr4592948itb.69.1490299060761; Thu, 23 Mar 2017 12:57:40 -0700 (PDT) MIME-Version: 1.0 Sender: ermal.luci@gmail.com Received: by 10.107.149.135 with HTTP; Thu, 23 Mar 2017 12:57:39 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Ermal_Lu=C3=A7i?= Date: Thu, 23 Mar 2017 12:57:39 -0700 X-Google-Sender-Auth: 6-D4UNtu6FUdkjPWzfduJW7Vdkg Message-ID: Subject: Re: if_epair altq support problem To: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 23 Mar 2017 19:57:41 -0000 On Thu, Mar 23, 2017 at 12:16 PM, =C3=96zkan KIRIK = wrote: > Ermal thank you again, > It compiles but pf still says that "pfctl: epair0b: driver does not > support altq" > :/ > The only way to get that error is by not applying the patch properly :) > > On Thu, Mar 23, 2017 at 9:46 PM, Ermal Lu=C3=A7i wrote: > >> >> On Thu, Mar 23, 2017 at 11:06 AM, =C3=96zkan KIRIK >> wrote: >> >>> Thank you, I'm waiting for 10.3 fix :) >>> have a nice day >>> >> >> >> This should work for 10.3++ >> >> diff --git a/sys/net/if_epair.c b/sys/net/if_epair.c >> index 540f06c..d028a95 100644 >> --- a/sys/net/if_epair.c >> +++ b/sys/net/if_epair.c >> @@ -829,7 +829,8 @@ epair_clone_create(struct if_clone *ifc, char *name, >> size_t len, caddr_t params) >> ifp->if_start =3D epair_start; >> ifp->if_ioctl =3D epair_ioctl; >> ifp->if_init =3D epair_init; >> - ifp->if_snd.ifq_maxlen =3D ifqmaxlen; >> + IFQ_SET_MAXLEN(&ifp->if_snd, ifqmaxlen); >> + IFQ_SET_READY(&ifp->if_snd); >> /* Assign a hopefully unique, locally administered etheraddr. */ >> eaddr[0] =3D 0x02; >> eaddr[3] =3D (ifp->if_index >> 8) & 0xff; >> @@ -855,7 +856,8 @@ epair_clone_create(struct if_clone *ifc, char *name, >> size_t len, caddr_t params) >> ifp->if_start =3D epair_start; >> ifp->if_ioctl =3D epair_ioctl; >> ifp->if_init =3D epair_init; >> - ifp->if_snd.ifq_maxlen =3D ifqmaxlen; >> + IFQ_SET_MAXLEN(&ifp->if_snd, ifqmaxlen); >> + IFQ_SET_READY(&ifp->if_snd); >> /* We need to play some tricks here for the second interface. */ >> strlcpy(name, epairname, len); >> error =3D if_clone_create(name, len, (caddr_t)scb); >> >> >> >> On Wed, Mar 22, 2017 at 11:44 PM, Ermal Lu=C3=A7i wrot= e: >>> >>>> >>>> On Wed, Mar 22, 2017 at 10:50 AM, =C3=96zkan KIRIK >>>> wrote: >>>> >>>>> Sorry, I mistested on 10.3RELENG. >>>>> it works on 11 RELENG, But at 10.3RELENG it throws >>>>> >>>>> /usr/src/sys/modules/if_epair/../../net/if_epair.c:830:2: error: >>>>> implicit declaration of function 'if_setstartfn' is invalid in C99 >>>>> [-Werror,-Wimplicit-function-declaration] >>>>> >>>>> >>>>> On Wed, Mar 22, 2017 at 8:18 PM, =C3=96zkan KIRIK >>>>> wrote: >>>>> >>>>>> Thank You Ermal ! >>>>>> >>>>>> It works perfectly, can you commit this patch to 11.0 RELENG and MFC >>>>>> to 10.3 RELENG ? >>>>>> >>>>>> >>>> Thanks, for confirming that it fixes your issues. >>>> Yeah, on 10.3 its almost the same fix i will deal with it. >>>> >>>> >>>>> Regards >>>>>> >>>>>> On Wed, Mar 22, 2017 at 6:59 AM, Ermal Lu=C3=A7i w= rote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Mar 21, 2017 at 5:26 AM, =C3=96zkan KIRIK >>>>>>> wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I sent this email also to freebsd-pf list. But I think that the >>>>>>>> main >>>>>>>> problem is belongs to sys/net/if_epair.c. >>>>>>>> >>>>>>>> I'm using FreeBSD 10.3-p17 amd64. epair pseudo device is listed as >>>>>>>> supperted deviced at the Man page of altq(4). >>>>>>>> From man page of altq : >>>>>>>> >>>>>>>> *SUPPORTED DEVICES >>>>>>> an.cgi?query=3Daltq#end>* >>>>>>>> >>>>>>>> The driver modifications described in altq(9) >>>>>>>> >>>>>>> ropos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports> >>>>>>>> are required to use a cer- >>>>>>>> tain network card with *ALTQ*. They have been applied >>>>>>>> to the following >>>>>>>> hardware drivers: ae(4) >>>>>>>> >>>>>>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>>> age(4) >>>>>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>>> alc(4) >>>>>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>>> ale(4) >>>>>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>>> an(4) >>>>>>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>>> ath(4) >>>>>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>>> aue(4) >>>>>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>>> axe(4) >>>>>>> an.cgi?query=3Daxe&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.0-= RE >>>>>>>> LEASE+and+Ports>, >>>>>>>> bce(4) >>>>>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>>> bfe(4) >>>>>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>>> bge(4) >>>>>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>>> bxe(4) >>>>>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>>> cas(4) >>>>>>> opos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>>> cxgbe(4) >>>>>>> an.cgi?query=3Dcxgbe&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.= 0- >>>>>>>> RELEASE+and+Ports>, >>>>>>>> dc(4) >>>>>>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>>> de(4) >>>>>>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>>> ed(4) >>>>>>> an.cgi?query=3Ded&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.0-R= EL >>>>>>>> EASE+and+Ports>, >>>>>>>> em(4) >>>>>>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>>> ep(4) >>>>>>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>>> epair(4) >>>>>>> an.cgi?query=3Depair&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.= 0- >>>>>>>> RELEASE+and+Ports>, >>>>>>>> >>>>>>>> .... >>>>>>>> >>>>>>>> But while trying to use it the system says that it's not >>>>>>>> suppoerted. I >>>>>>>> tried on FreeBSD 11 also. The output is below: >>>>>>>> >>>>>>>> pf.conf : >>>>>>>> altq on epair0b hfsc bandwidth 1Mb queue { ftp, ssh, icmp, other } >>>>>>>> queue ftp bandwidth 30% priority 0 hfsc (upperlimit 99%) >>>>>>>> queue ssh bandwidth 30% priority 2 hfsc (upperlimit 99%) >>>>>>>> queue icmp bandwidth 10% priority 2 hfsc (upperlimit 99%) >>>>>>>> queue other bandwidth 30% priority 1 hfsc (default upperlimit 99%) >>>>>>>> >>>>>>>> >>>>>>>> # ifconfig epair0 create >>>>>>>> # ifconfig epair0a up >>>>>>>> # ifconfig epair0b up >>>>>>>> # pfctl -f pf.conf >>>>>>>> pfctl: epair0b: driver does not support altq >>>>>>>> >>>>>>>> # sysctl -a | grep ALTQ >>>>>>>> options ALTQ_NOPCC >>>>>>>> options ALTQ_PRIQ >>>>>>>> options ALTQ_CDNR >>>>>>>> options ALTQ_HFSC >>>>>>>> options ALTQ_RIO >>>>>>>> options ALTQ_RED >>>>>>>> options ALTQ_CBQ >>>>>>>> options ALTQ >>>>>>>> >>>>>>>> >>>>>>>> I have a look on /usr/src/sys/net/if_epair.c, and found the ALTQ >>>>>>>> section: >>>>>>>> >>>>>>>> 514 #ifdef ALTQ >>>>>>>> 515 /* Support ALTQ via the clasic if_start() path. */ >>>>>>>> 516 IF_LOCK(&ifp->if_snd); >>>>>>>> 517 if (ALTQ_IS_ENABLED(&ifp->if_snd)) { >>>>>>>> 518 ALTQ_ENQUEUE(&ifp->if_snd, m, NULL, error); >>>>>>>> 519 if (error) >>>>>>>> 520 ifp->if_snd.ifq_drops++; >>>>>>>> 521 IF_UNLOCK(&ifp->if_snd); >>>>>>>> 522 if (!error) { >>>>>>>> 523 ifp->if_obytes +=3D len; >>>>>>>> 524 if (mflags & (M_BCAST|M_MCAST)) >>>>>>>> 525 ifp->if_omcasts++; >>>>>>>> 526 >>>>>>>> 527 if ((ifp->if_drv_flags & >>>>>>>> IFF_DRV_OACTIVE) =3D=3D 0) >>>>>>>> 528 epair_start_locked(ifp); >>>>>>>> 529 else >>>>>>>> 530 (void)epair_add_ifp_for_drain >>>>>>>> ing(ifp); >>>>>>>> 531 } >>>>>>>> 532 return (error); >>>>>>>> 533 } >>>>>>>> 534 IF_UNLOCK(&ifp->if_snd); >>>>>>>> 535 #endif >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Just apply manually this patch to make it work. >>>>>>> >>>>>>> diff --git a/sys/net/if_epair.c b/sys/net/if_epair.c >>>>>>> index 540f06c..04733a5 100644 >>>>>>> --- a/sys/net/if_epair.c >>>>>>> +++ b/sys/net/if_epair.c >>>>>>> @@ -827,9 +827,11 @@ epair_clone_create(struct if_clone *ifc, char >>>>>>> *name, size_t len, caddr_t params) >>>>>>> ifp->if_capabilities =3D IFCAP_VLAN_MTU; >>>>>>> ifp->if_capenable =3D IFCAP_VLAN_MTU; >>>>>>> ifp->if_start =3D epair_start; >>>>>>> + if_setstartfn(ifp, epair_start); >>>>>>> + if_setsendqlen(ifp, ifqmaxlen); >>>>>>> + if_setsendqready(ifp); >>>>>>> ifp->if_ioctl =3D epair_ioctl; >>>>>>> ifp->if_init =3D epair_init; >>>>>>> - ifp->if_snd.ifq_maxlen =3D ifqmaxlen; >>>>>>> /* Assign a hopefully unique, locally administered >>>>>>> etheraddr. */ >>>>>>> eaddr[0] =3D 0x02; >>>>>>> eaddr[3] =3D (ifp->if_index >> 8) & 0xff; >>>>>>> @@ -852,10 +854,11 @@ epair_clone_create(struct if_clone *ifc, char >>>>>>> *name, size_t len, caddr_t params) >>>>>>> ifp->if_flags =3D IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICA= ST; >>>>>>> ifp->if_capabilities =3D IFCAP_VLAN_MTU; >>>>>>> ifp->if_capenable =3D IFCAP_VLAN_MTU; >>>>>>> - ifp->if_start =3D epair_start; >>>>>>> + if_setstartfn(ifp, epair_start); >>>>>>> + if_setsendqlen(ifp, ifqmaxlen); >>>>>>> + if_setsendqready(ifp); >>>>>>> ifp->if_ioctl =3D epair_ioctl; >>>>>>> ifp->if_init =3D epair_init; >>>>>>> - ifp->if_snd.ifq_maxlen =3D ifqmaxlen; >>>>>>> /* We need to play some tricks here for the second >>>>>>> interface. */ >>>>>>> strlcpy(name, epairname, len); >>>>>>> error =3D if_clone_create(name, len, (caddr_t)scb); >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> I have no idea that why it says that it doesn't support altq >>>>>>>> altough the >>>>>>>> source code contains ALTQ section. >>>>>>>> >>>>>>>> >>>>>>>> Regards >>>>>>>> =C3=96zkan KIRIK >>>>>>>> _______________________________________________ >>>>>>>> freebsd-net@freebsd.org mailing list >>>>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-net >>>>>>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freeb >>>>>>>> sd.org" >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Ermal >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Ermal >>>> >>> >>> >> >> >> -- >> Ermal >> > > --=20 Ermal From owner-freebsd-net@freebsd.org Thu Mar 23 21:37:42 2017 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 794B1D19B81 for ; Thu, 23 Mar 2017 21:37:42 +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 6819F1D8E for ; Thu, 23 Mar 2017 21:37:42 +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 v2NLbgOj052485 for ; Thu, 23 Mar 2017 21:37:42 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 218041] sys/dev/e1000/if_em.c: PVS-Studio: V646: possible 'else' keyword missing Date: Thu, 23 Mar 2017 21:37:42 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: IntelNetworking, patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@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: short_desc assigned_to cc keywords 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.23 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, 23 Mar 2017 21:37:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218041 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|sys/dev/e1000/if_em.c: |sys/dev/e1000/if_em.c: |PVS-Studio: V646 |PVS-Studio: V646: possible | |'else' keyword missing Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org CC| |sbruno@FreeBSD.org Keywords| |IntelNetworking, patch --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Mar 23 21:49:18 2017 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 56860CA1511 for ; Thu, 23 Mar 2017 21:49:18 +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 45E061A42 for ; Thu, 23 Mar 2017 21:49:18 +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 v2NLnIhG076909 for ; Thu, 23 Mar 2017 21:49:18 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 218005] sys/netinet/sctp_pcb.c: PVS-Studio: Unreachable code detected (CWE-561) Date: Thu, 23 Mar 2017 21:49:18 +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: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@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: assigned_to short_desc keywords 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.23 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, 23 Mar 2017 21:49:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218005 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org Summary|sys/netinet/sctp_pcb.c: |sys/netinet/sctp_pcb.c: |PVS-Studio: Dead Code |PVS-Studio: Unreachable |(CWE-561) |code detected (CWE-561) Keywords| |patch --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Mar 23 21:50:13 2017 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 DC68BCA1671 for ; Thu, 23 Mar 2017 21:50:13 +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 CBA121BB5 for ; Thu, 23 Mar 2017 21:50:13 +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 v2NLoDsg078314 for ; Thu, 23 Mar 2017 21:50:13 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 218004] sys/dev/sfxge/common/efx_mcdi.c: PVS-Studio: Unreachable code detected (CWE-561) Date: Thu, 23 Mar 2017 21:50:14 +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: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@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: short_desc keywords 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.23 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, 23 Mar 2017 21:50:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218004 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|sys/dev/sfxge/common/efx_mc |sys/dev/sfxge/common/efx_mc |di.c: PVS-Studio: Dead Code |di.c: PVS-Studio: |(CWE-561) |Unreachable code detected | |(CWE-561) Keywords| |patch 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 Thu Mar 23 21:53:48 2017 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 A7AB2CA1A7A for ; Thu, 23 Mar 2017 21:53:48 +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 977401170 for ; Thu, 23 Mar 2017 21:53:48 +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 v2NLrlOS090562 for ; Thu, 23 Mar 2017 21:53:48 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217920] [PATCH] ipfilter discard bytes - 3072 instead of 1024 Date: Thu, 23 Mar 2017 21:53: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: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@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: 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.23 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, 23 Mar 2017 21:53:48 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217920 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- 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 24 00:50:27 2017 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 8C0BBCA1179 for ; Fri, 24 Mar 2017 00:50:27 +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 712901459 for ; Fri, 24 Mar 2017 00:50:27 +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 v2O0oPUS052846 for ; Fri, 24 Mar 2017 00:50:27 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Fri, 24 Mar 2017 00:50: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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: karels@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.23 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, 24 Mar 2017 00:50:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #78 from Mike Karels --- (In reply to Sepherosa Ziehau from comment #77) I don't think it is similar, although I haven't thought it through in great detail. For starters, there is no TIME_WAIT to assassinate. I don't see h= ow the situations would be similar. The only way I can think of to stop this would be to invent a new state, similar to TIME_WAIT but not awaiting only FIN, that would remember that the connection has terminated unsuccessfully. I don't think this is warranted. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Mar 24 02:26:47 2017 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 B3D1ACA2B92 for ; Fri, 24 Mar 2017 02:26: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 969C21FC for ; Fri, 24 Mar 2017 02:26: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 v2O2Qk7e092460 for ; Fri, 24 Mar 2017 02:26:47 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Fri, 24 Mar 2017 02:26: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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sepherosa@gmail.com 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.23 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, 24 Mar 2017 02:26:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #79 from Sepherosa Ziehau --- (In reply to Mike Karels from comment #78) Hmm, WAIT1, WAIT2 and CLOSING will transit to TIME_WAIT, so killing them (moving to CLOSED) in the code we talked assassinates TIME_WAIT indirectly. Or add a flag to tcpcb for TIME_WAIT state. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Mar 24 02:39:13 2017 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 721B6CA2D99 for ; Fri, 24 Mar 2017 02:39:13 +0000 (UTC) (envelope-from David.Somayajulu@cavium.com) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0079.outbound.protection.outlook.com [104.47.40.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 25BC1841; Fri, 24 Mar 2017 02:39:12 +0000 (UTC) (envelope-from David.Somayajulu@cavium.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aRiJvFLE9lHfQrxU4JuNhnAadDnQklrGlpVb4v55eCg=; b=biTzmJjOqQzLHtbwk9ajnXtKDlIemuhviT3JlycpKHcAgrjGUoeLfSil+CBRUjhyZ5EiR4Ug4rXHnv0PIbmhjI5hG0YIFfoziDfXMJNjQRq3l8JnHQC0Mhg3yLHHo2XYXCjJLVPA/gQxbRKmp6PZZZBmMVAGf7Y/dR221QNEWPQ= Received: from BY2PR07MB1474.namprd07.prod.outlook.com (10.162.76.152) by BY2PR07MB1473.namprd07.prod.outlook.com (10.162.76.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Fri, 24 Mar 2017 02:39:10 +0000 Received: from BY2PR07MB1474.namprd07.prod.outlook.com ([10.162.76.152]) by BY2PR07MB1474.namprd07.prod.outlook.com ([10.162.76.152]) with mapi id 15.01.0977.021; Fri, 24 Mar 2017 02:39:10 +0000 From: "Somayajulu, David" To: "freebsd-net@freebsd.org" CC: "'gnn@freebsd.org'" Subject: Committing a new 25G/40G/100G Ethernet Driver Thread-Topic: Committing a new 25G/40G/100G Ethernet Driver Thread-Index: AdKkRalu7VV4vKFWSnmaZ/zhD2lYYA== Date: Fri, 24 Mar 2017 02:39:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=cavium.com; x-originating-ip: [198.186.0.2] x-microsoft-exchange-diagnostics: 1; BY2PR07MB1473; 7:iQADAsjPwt42vpC0mF3Vjzy1pqf/KOWdI7pF3qVSxQ7UzIhkMSV9IzAQJHBLNpa6JCHtZuh506vnZFa66KrSe0nDXXfZ0XPqZinccN54c3sbgPXMmrcfoXD/x3GarrBPxxkfb3wPJAygL4l8j2SQj2TXLOpIR6FxIwCruum1pTsWIZgj6KImpr5fLyxh1ztdQEPJSiuP2PRf77cXy1zUwdRH6kEenYZ+lEGbmJeYOMYXAKeZmWpgwY1beejWMNG87TH3hDSCM6/6JHElT7QuoobAred+AUZt0etGOIh+wW86jozUEqddXBc1tXYalYbOCr5/vf5hmEEx1GzxIywAfQ== x-ms-office365-filtering-correlation-id: b4de6502-68fb-40df-0261-08d4725ef36e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:BY2PR07MB1473; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(20161123558025)(6072148); SRVR:BY2PR07MB1473; BCL:0; PCL:0; RULEID:; SRVR:BY2PR07MB1473; x-forefront-prvs: 0256C18696 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400002)(39410400002)(39450400003)(501624003)(53754006)(6506006)(33656002)(86362001)(122556002)(236005)(9686003)(53936002)(66066001)(74316002)(77096006)(55016002)(38730400002)(8676002)(110136004)(5640700003)(6306002)(81166006)(5660300001)(606005)(9326002)(81156014)(450100002)(6436002)(4326008)(54896002)(8936002)(99286003)(7906003)(189998001)(3846002)(7696004)(54356999)(3660700001)(50986999)(3280700002)(6916009)(2900100001)(2351001)(7736002)(2906002)(25786009)(790700001)(2501003)(6116002)(5630700001)(102836003); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR07MB1473; H:BY2PR07MB1474.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: cavium.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2017 02:39:09.9435 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR07MB1473 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 24 Mar 2017 02:39:13 -0000 Hi All, I have a brand new Cavium 25G/40G/100G Ethernet Driver to commit to HEAD. The patch generated using "svn diff" is about 22Mb. Per gnn's advice I ha= ve tried to submit the patch via Phabricator at https://reviews.freebsd.org= /differential/diff/create/ for review. The file uploads fine but I get the = following error "413 Request Entry Too Large". I would appreciate if someo= ne can help me circumvent this problem. Also would it be o.k if I break the= patch into smaller portions and submit to Phabricator ? Thanks David S. (davidcs@freebsd.org) P.S: The last few brand new drivers were directly committed to HEAD and I d= id not have this issue. From owner-freebsd-net@freebsd.org Fri Mar 24 07:36:15 2017 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 809AFD1B323 for ; Fri, 24 Mar 2017 07:36:15 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 36A1F390; Fri, 24 Mar 2017 07:36:15 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 978C225D386E; Fri, 24 Mar 2017 07:36:12 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 9919ED1F7EA; Fri, 24 Mar 2017 07:36:11 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id r8rdI3BaWoWs; Fri, 24 Mar 2017 07:36:10 +0000 (UTC) Received: from [10.111.64.116] (unknown [IPv6:fde9:577b:c1a9:4410:bdf6:42ba:903d:22f]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id E794DD1F7E9; Fri, 24 Mar 2017 07:36:09 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Somayajulu, David" Cc: "freebsd-net@freebsd.org" , "gnn@freebsd.org" Subject: Re: Committing a new 25G/40G/100G Ethernet Driver Date: Fri, 24 Mar 2017 07:36:07 +0000 Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (2.0BETAr6080) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 24 Mar 2017 07:36:15 -0000 On 24 Mar 2017, at 2:39, Somayajulu, David wrote: > Hi All, > I have a brand new Cavium 25G/40G/100G Ethernet Driver to commit to > HEAD. > The patch generated using "svn diff" is about 22Mb. Per gnn's advice > I have tried to submit the patch via Phabricator at > https://reviews.freebsd.org/differential/diff/create/ for review. The > file uploads fine but I get the following error "413 Request Entry Too > Large". I would appreciate if someone can help me circumvent this > problem. Also would it be o.k if I break the patch into smaller > portions and submit to Phabricator ? Try contacting that alias: https://www.freebsd.org/administration.html#t-phabric-admin They should be able to help. /bz From owner-freebsd-net@freebsd.org Fri Mar 24 10:19:59 2017 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 0DEEACA2771 for ; Fri, 24 Mar 2017 10:19:59 +0000 (UTC) (envelope-from Joe@stream-technologies.com) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0043.outbound.protection.outlook.com [104.47.1.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 61F3711D4 for ; Fri, 24 Mar 2017 10:19:57 +0000 (UTC) (envelope-from Joe@stream-technologies.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=streamtechnologiesuk.onmicrosoft.com; s=selector1-streamtechnologies-com01e; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Hfz85j5731DZfOzCatMvO6LeHDkzLSmHuLO8FfG8rnc=; b=K3Nj999W0T8Q13ROhe70kn4jH95E8yXTZd/OeKvnUTXxUkJpjsMc/+20Ttv0uORnBncE9HiR+Ul/1n/BEHYzkXKyedP0AX4fLJEZaG6pN6ZcvjeIwuD0JnWP3f32/Vf+r9njfwo4Py0ftgnr+TOC+rytLSQ+Yl01nOnOTK6qBzU= Authentication-Results: freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=stream-technologies.com; Received: from [192.168.6.128] (212.20.240.118) by VI1PR07MB1039.eurprd07.prod.outlook.com (10.161.111.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Fri, 24 Mar 2017 10:19:53 +0000 Subject: Re: cxgbe netmap promiscuous mode? To: Vincenzo Maffione References: <58D3C6F4.6010500@stream-technologies.com> CC: "freebsd-net@freebsd.org" From: Joe Jones Message-ID: <58D4F2C5.9020204@stream-technologies.com> Date: Fri, 24 Mar 2017 10:19:49 +0000 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: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [212.20.240.118] X-ClientProxiedBy: AM4PR0501CA0058.eurprd05.prod.outlook.com (10.172.222.154) To VI1PR07MB1039.eurprd07.prod.outlook.com (10.161.111.143) X-MS-Office365-Filtering-Correlation-Id: 2622253a-ad95-465e-c8eb-08d4729f5030 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:VI1PR07MB1039; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1039; 3:Dirm8ilRS2AgLyhJG5r+D3zw4bGJpOItjCSfS1QoLbWeiyU2j3jJPfPyKUgQYM5pPi6gQp8ImMxjCsQaKt1ncg8WvoNcbLmOxRvXHIqFroGoBRm6C6+UEJkJjjBo1tRX+q+Er0494RZiakBsgIvaDbJA4CNBm+rLQl1iib400rw6zUVtksCFEezJHmI+krf1YwxIzz8wGza84qrAsH37tkySch36YxxyIQZY5bv2ZGVl0sGflLHWUKBn7UVmbaCHMM+TkzF3/sCBL+gXiTC58Q==; 25:6TpSPziYXw5inCovglPwDenOfERsExDu4KKr3jbBXeT3RGwVM84bDu5PUbwbgTn4AdXzj3pXsHlx4RGL55+UuYs5gnmRaPuMPnYOumZq/duuwe9ED3ThdM6ja2iMxB8pvAMMelHySwpkmkgDxOPKwxPdiegmgSgNipoLrXumiWsrlxHQBaeqO5BHCJSchc27Wcc5GGsd1BFF5nsvIspGkR/Lipe+GuMQ96kHPVV8V0GCvCZ670SGsR4/fNVZR9WsgaE19gkuk1Dui6a9/aHb+nXkvHN6lGbfi30EHetsamFTUqc/ijPQ+GKW/WaadFFEovJ1JoH9KqZWPzKf4jJpvlAbgCfH4TJFqZ7eYnt4o5SBQjb7GHlmoIZikCuEIOBQVlux7T1WCJ/R+P1LzGgegxBWzQTfyuHEYz4oNvvbNnWgHr0F6xbOJ65CqPnjEiC50ikdnGKA0dxqcOiNb0eI0A== X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1039; 31:6D6JcX2kgyNIStLt3Va22KgNBrylPPgkSNAXiYBeX5TZCJUM8w2uN81s0Fne8zV2my2Id73DeThJktR0NshJLpDUlITObZ48jjKDPTN7kyz8MO79pfVS3m1FxbeIyyolP5yprK+xuQ6uAxmPCxTbPZTrOX6u1Y+FSdsiE+7wbtgwt1CwYEWr1TZtpyL2BacVQHRnPn7mnCvv/pZhZsiShmKHA45FxhIKQWIGr6fsfcZj8PbnB0gx7Lfsx5dAEYyDJXsYfCc+2lJndFYFuGjKtJH1Q2/IhydFOqFGj4/Yi+U= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(75325880899374); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(20161123558025)(6072148); SRVR:VI1PR07MB1039; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1039; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1039; 4:26UaO05r0JNfs4iDF86fvK1/i0IJg4weW7/NiS1bJf5Ky5HJeP5CcElUCWbjkyi2yydyjl6uUIMktsoM3gcTcYH09l8Fe6jfPVKn64Kxfw34PUkT1f5iqr3aHjhOCaalgvlGQCVLWLYRK5dBCVWnh4vMfzAdLkWNi4N6WAN2B8IJfessCp/pjyJco+n4jR/xGVsGugLuBEPBBFfC9Jak+oN3EyS9sAQnxRTP9gTfehK6xvlMIvH2QjbIolurBSJWoKV4LJmlcI0lIxBmGpZhjH68eypmY/UFRFmQHasKldr3wuyCVxH4ljiitrRMo7OBzQ2CAFnf+joSx7IpZNyAYjuR1fjCNVCBHeVYzBHVYgJTs3LPBbO1jUy+AzKksnOF95IidIkF9uG653BY/P/meLFtEEzDL6aXYowleXN1CBLYpQSY8/HnQdqexFbE22cTZALO4cdJVLKW3P+oHlOe58NyvBu/u/9bW3m01jpAeqNQ2dhKbrLQ13H32dU/uknZe8zfQpgV0zCeL1SodhkFdOmhYw1zqCkeMwqxwTySb2xp+ljJG1NKQKuwDjEskUujGAgA5tr+gcTMYV2gBcS/lB7euQUxx0QE96WHqNLERuZJgVxmM6eu+buWeAsymwKAobqo1BIFeFzhB8oFFtXcKQ== X-Forefront-PRVS: 0256C18696 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(6049001)(39410400002)(39450400003)(39830400002)(66654002)(24454002)(377424004)(189998001)(65956001)(36756003)(230700001)(23676002)(66066001)(65806001)(5660300001)(6486002)(50986999)(87266999)(110136004)(86362001)(53546009)(65816999)(76176999)(6246003)(54356999)(53936002)(25786009)(83506001)(47776003)(229853002)(6916009)(33656002)(3846002)(38730400002)(2950100002)(77096006)(4326008)(6306002)(117156001)(90366009)(6666003)(6116002)(305945005)(64126003)(50466002)(42186005)(8676002)(3480700004)(80792005)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB1039; H:[192.168.6.128]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA3TUIxMDM5OzIzOnVjSkc5NXhkZkQxVDdFQ2lScWJZTE1QZThH?= =?utf-8?B?L3hFTHhYU1NWNU5Cd2lxcWx2YjN0ZGVzalBMK0RjRWpzazRmUEpmaFRuUkxY?= =?utf-8?B?ZkxDY1Q5U1JXb0RDZEVMTFZHc29UWWRCOGxmK1lTaXBadkFXbitkVnFLazVF?= =?utf-8?B?VTNwek9CUmRiWHp2RzUrSnFhcm5lQVpRb0ZhZkdwMW5Oam1Oc3J3aEtGaFBN?= =?utf-8?B?Zk5kUE9HUjZycXg1TVJ6eTBudW9hUk9wZ2h5RjB2NGRRcTMrR1MxUTRTTmds?= =?utf-8?B?OUNBZCsxbGxNeDdoeTd0Q3g3Qk5oK05KWE90RDRJS2hScGYvd1ltdUhFSjJQ?= =?utf-8?B?aTllV1dIdzZJZ3JHNG1ZUlFKdllIZnU4ZUpTM2lvVWRaZjZQWVM5VG84TS9o?= =?utf-8?B?RmZvbmFZMmd2NkdQTzhKUUhNeDg2LzJoRGh0WW1uSldCbHF3RlhzUWRsUUlD?= =?utf-8?B?NnFaYTRydlFIVDFOVXNvaGJ4SmRrL3pSdDFyMmJKdnJRZ3dtelNpamt6RkFP?= =?utf-8?B?MGxxc0dKVjA2aGxsZERSYzZsUWE5OUN1N0x6emJ5My9Tc1hTTFRGcDk1VkVW?= =?utf-8?B?ekswTVpkZkxWUkhxQzBZRU01Y1hscUFPV0sxbmloa21EczFNL0xUeXE4N3JG?= =?utf-8?B?VHhpOU5FTFRwOWdqZk1sZWJhb3AzVHB2S0VqVzF1Zk8rK3p0UGZSYm43Zml0?= =?utf-8?B?R2ZHVzIxbndFL1gxVnUxYytUR0FrcFdlaHF1c3cyNUlTQ1lUUjdMM1llWjVO?= =?utf-8?B?WDZLRXBjM0lWUGd3Nk16RURzdnl0ZXcyaDZBZk1hV0I5cFJTZGhMNG5LTU9Z?= =?utf-8?B?c3RWR1haQllia2ZkaGczYXJhbE9nVlp0aS9Oc1lwb214Z0ZCZGowcXRmS2pQ?= =?utf-8?B?NVdMTzFUZ0hEOTRnRzJBU2FQYkVuVkZDb1NVcjN2SzNTOTdwUkFKVlJjZnk5?= =?utf-8?B?OEt6S2M4QlkzekJBV3g3WEdFUGZ2WFBxaTV1cGpBaGo1N0xIVVJlVkVWNkhR?= =?utf-8?B?MDVpeGlFOU45UGpodjhJYkJ5a3VBZm9wb1ZtakQ0QnIrcUw4QWZCYjNmOFRI?= =?utf-8?B?K0xpWXFzaGhSUk4xbmNpRTl6Qyt3NG5ZS1V1V1JveUxCNDdKenptZDdkRWlt?= =?utf-8?B?d2RRbVE5MGFFL2NjemNiOVMrSFA0Ky81N2ZObFkyWm03K2hBNzFRc0owREV6?= =?utf-8?B?UFRZcVBmTTR5TTVYdFI1dEwxamxjTmFUYndZcEl3NWo4UTlhRXIzeGFreGgr?= =?utf-8?B?SnRqNXRGckMvZHN4c0RPTVQxOU8vR1FFWFBiMHlUL3FKYjJBUHdyUFNPb2xM?= =?utf-8?B?M0VraTJJQy9sN2JoSVFyV0QwbFR1Q2FHekgrNnQzeEprNTUvYXAyUUUzWmRs?= =?utf-8?B?MzdJWU1YTDAyNENJcWFVejdQSklUeHpsTGJ5Umw2MFNVUkJ1ZUplKy9UbFI0?= =?utf-8?B?V1BmRk9Jd3pWMStnbGZTWUVleGlIN0tTSktOaHBieWdPWkl0bmhjMHczR25B?= =?utf-8?B?TUNCSWtsRFRRQitaenlnbVAzcDk4cDJEUi95bWtzLzJvOU1oQ3ZYa3puQXVW?= =?utf-8?B?VEVnSXFBYmFYOGdGc1RHdXk5OEZSU1N3aUIyS0d0RDdCaXdVMW8zd2dUQkJV?= =?utf-8?B?SGtPNkR4VG9xUFl3NWV3UkZjWVdtSTJZQktFQzNOelNoQi9GdFhUL0xJdVVy?= =?utf-8?Q?ElXOE0AIh9d8w2uOdHLUrPJEayPyW0lDlkcEd6M?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1039; 6:UzGmr+zygZFZBywyqSQkqzdLU7yiGAshLsRujNiANc8eKvTAy7EsBWU2vX1zzbixdn0oDwTShEAlI+hoHK/SOzxrGNm31/XIkWDKappgvLxvDBOxoC49v6quTZ2xFh/6E7ueBpPP5wQ5E+YY+dwWue8ZWGSauPsvH9oVsTM05LCfxHXNKb8uc3o4yMiRnrC61uTrhJCS+zOPeA26ybIiglIQA/ENAsyFnrR1x9srHFk/NM/EKePhiPTsRqhRBvFyGwoDCwUCu2dBCc6aaittaUUy2ykTGXQOpqV7L1YD4XiG4f5XW0bp1FhzVMxtUXnUkMhf+f9qaOzt17CbSkrVSUfYAv7NxieoQxNuVXRar7gx2iCXUY/u8gDf3WIDTR1ObiVnNfxfwTRkO5Ss5vKdGg==; 5:KrYhaNZqy+7+ZS73gkJXlKwTE29wewZnVhc0P0xcHxhay9EOH0npy/G66kPcyoOsweC+13i6KY5LlC7TqNHTmnRLGubJe2CEAEYoD4p12DoiUaiBrD1PVjqPCo/Xy1G/4lnfaXnmX8qJxUZo+0Aj6w==; 24:95mGpagA4sA5VfAmnvcuRDVCLtLxOP6JGqx5/yLLzBzHQjte4lKH0PQrR8vdsOfXW5gcp3Brbf2P71EED8jw94NxBKVrzEeGEeMq4fSPttE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1039; 7:0HonQt3gAG6XVZvbHKYcdlRfa4vbzNgTfG8eCSgtljUHumi3lPbcqZsA3BTwYri1kChvoZkRw+hJBLoSe/3k8FtOEYSImp3bDc3iYQkCE7j+XKiUeAmzqIfnsnq0Xv3KYa5P2AGgy/9+ABNNe594wG2cyRcI4jOlKQH5PApTIqNZLAmLpCotVmo7B5XTrMBy5FBZDOjSqVFOEPi3uUL8ZgsIrWsR5SkKTChctFWuD1UXUuCHeTeONfL/VNHTX9AgJS6q/qJhT7bN6GZtWmSZBlBBmPZjfzQM6FFtR301lLcx7KPiXR01awfUQ+F5L7IifnMaO2EtXjWS4NjdRzjJDg== X-OriginatorOrg: stream-technologies.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Mar 2017 10:19:53.4882 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1039 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 24 Mar 2017 10:19:59 -0000 Hi Vincenzo, I just tried with that sysctl set to 2, I get a similar looking panic to before Fatal trap 12: page fault while in kernel mode cpuid = 7; apic id = 0e fault virtual address = 0x1 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff806e38aa stack pointer = 0x28:0xfffffe047ba18440 frame pointer = 0x28:0xfffffe047ba18490 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2205 (main) trap number = 12 panic: page fault cpuid = 7 KDB: stack backtrace: #0 0xffffffff80b240f7 at kdb_backtrace+0x67 #1 0xffffffff80ad9462 at vpanic+0x182 #2 0xffffffff80ad92d3 at panic+0x43 #3 0xffffffff80fa1d51 at trap_fatal+0x351 #4 0xffffffff80fa1f43 at trap_pfault+0x1e3 #5 0xffffffff80fa14ec at trap+0x26c #6 0xffffffff80f841c1 at calltrap+0x8 #7 0xffffffff806e5a80 at generic_netmap_txsync+0x330 #8 0xffffffff806e06f9 at netmap_ioctl+0x279 #9 0xffffffff8098624f at devfs_ioctl_f+0x13f #10 0xffffffff80b41b34 at kern_ioctl+0x2d4 #11 0xffffffff80b417f1 at sys_ioctl+0x171 #12 0xffffffff80fa26ae at amd64_syscall+0x4ce #13 0xffffffff80f844ab at Xfast_syscall+0xfb This is on 11.0-RELEASE-p8 Thanks, Joe Jones On 23/03/17 18:20, Vincenzo Maffione wrote: > Hi, > You could try to use netmap in emulated mode (sysctl > dev.netmap.admode=2). If this works, at least you know that the > problem is in the cxgbe netmap support and not in the netmap core itself. > > Cheers, > Vincenzo > > 2017-03-23 14:00 GMT+01:00 Joe Jones >: > > Hello, > > We have a T520-SO and have made a new install of 11.0, to begin > with the box would panic every time we tried to switch the card > into netmap mode. So we recompiled the kernel with netmap removed, > then compiled the netmap kernel module from github, as this in our > experience generally leads to a more stable netmap. > > we have > > uname -a > FreeBSD goose2 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 #0: Wed Mar > 22 16:52:35 UTC 2017 joe@goose2:/usr/obj/usr/src/sys/GENERIC amd64 > > and the following in /boot/loader.conf > > t4fw_cfg_load="YES" > t5fw_cfg_load="YES" > if_cxgbe_load="YES" > hw.cxgbe.fl_pktshift=0 > hw.cxgbe.toecaps_allowed=0 > hw.cxgbe.nnmtxq10g=8 > hw.cxgbe.nnmrxq10g=8 > hw.cxgbe.num_vis=2 > > Before I run our application I run > > ifconfig cxl1 promisc -vlanhwtag up > > Now our application can now start without panicking the kernel. > Here is where it gets interesting, our application is able to > announce it's self via ARP, I can see the ethernet switch learning > which port it's on, and other hosts adding it to their ARP tables. > When I try an ICMP ping it goes missing. After watching the TX > packet graph for the connected port on the switch while starting > and stopping a flood ping to the application, I'm sure the packets > are getting sent to the card, however I don't see them in the > netmap ring. If I kill our application, then use ifconfig to > create and configure a vlan port I can confirm that the card is > working and has connectivity. > > Here's what I think is happening. ARP requests are received > because they are sent to the broadcast address. Our application > then announces it's self. However traffic destined for the > application is send to a MAC address which is neither the > broadcast or the MAC programed into the hardware and is dropped. > My understanding of promiscuous it that it informs the card that > we want these dropped packets. It looks to me like, when the card > is in netmap mode the promisc flag is being ignored. > > I have also tried using freebsd-update to update to p8. As with > the p0 kernel we get a panic when we switch the card into netmap mode. > > We did previously have these cards working in netmap mode. We were > using a pre 11 snapshot of the svn head though . > > Many Thanks > > Joe Jones > Stream Technologies > > _______________________________________________ > 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 > " > > > > > -- > Vincenzo Maffione From owner-freebsd-net@freebsd.org Fri Mar 24 10:29:41 2017 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 457AFCA2AB0 for ; Fri, 24 Mar 2017 10:29:41 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 096FB19C6 for ; Fri, 24 Mar 2017 10:29:41 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-oi0-x22c.google.com with SMTP id r203so4714247oib.3 for ; Fri, 24 Mar 2017 03:29:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l8W8EvGkbsSngq0PDRi1VEVL1+NdeND1NumGKuZGzf8=; b=nlPR53vBFNg8NpeI/YdIgQxpkOeKQC+J4PeWn+a2g3KqNRgp66nAaTT0YLOgWZc1aJ QGaYYw1ntog2G7oFaDQfwiqXDwivJWnd+73dUnefmJZYLf9IF7NZaJNqhiwtoKRR1HBo F1mAEfvlzPXg4h+Sgxf/D7KQsG14ajGNG8rnU3iU5KBrlfFwKuTNCzpF+VhBslXDFCDx zK1rdzLeTgdEBF9oGEmkNFduebD6kJxv/rbWp02fZYihGIbOcj9WtMXDfjsv5DsQlHgG vNqL+oZRMdPMBMyjmSeJ9Wav1O4frNvADchIXkzv8Gro+bAdC9xQES9BgLoERVCN1zkt FUnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l8W8EvGkbsSngq0PDRi1VEVL1+NdeND1NumGKuZGzf8=; b=YhGhEP8yiZ/JNu+Yt4+vvg39TR/tlFer2/W6OjtqyB2V33d/vU9O/sMF/eqxvpSWz6 zTfgBih/Q4PZFIru/q+5ued2Qf5XraPhHCPBcbhL9r1tC8X8M2M2IMWi12Hu/WqtcIH6 g54jN0Cmkwb6ummI3sNDTUPTe5w4asC6s/2U/imrJgGkax6/6V0k1dtZfeLB4/gKL7kA SigYCOSrK6vg0BrXeKz7Gi0sMFpL0hkwLmgXzyq/Hxt0iqSMXlXUpFmN+yllaeCw3c7C Zz7ouxmKim3rZVzvHFH0wqqYKSZ44x5MLlGUwvvUrG9NDdfT7iMu41e0kiscDug3GBTG pQeQ== X-Gm-Message-State: AFeK/H2Nn3hzt4Mip6HTL1JloAvn+PKppjzmLgWSBMshN4Po0q7CG8cZX9VkYwQnbh/S/nzCitk00f3TTq+j0g== X-Received: by 10.202.196.194 with SMTP id u185mr1340046oif.153.1490351377280; Fri, 24 Mar 2017 03:29:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.50.45 with HTTP; Fri, 24 Mar 2017 03:29:36 -0700 (PDT) In-Reply-To: <58D4F2C5.9020204@stream-technologies.com> References: <58D3C6F4.6010500@stream-technologies.com> <58D4F2C5.9020204@stream-technologies.com> From: Vincenzo Maffione Date: Fri, 24 Mar 2017 11:29:36 +0100 Message-ID: Subject: Re: cxgbe netmap promiscuous mode? To: Joe Jones Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 24 Mar 2017 10:29:41 -0000 Hi Joe, There was a fix for a panic in emulated mode that was applied stable/11 branch, so I guess it also ended up into FreeBSD-11.0-STABLE. I don't know whether the same fix ended up into in 11.0-RELEASE-p8 (I'm not familiar with FreeBSD releasing process, sorry!). Or maybe this panic happens with netmap upstream? If this is a new bug, it would be nice to have the kernel with the debug symbols enabled, so that we can get more detailed information from the stack trace. Cheers, Vincenzo 2017-03-24 11:19 GMT+01:00 Joe Jones : > Hi Vincenzo, > > I just tried with that sysctl set to 2, I get a similar looking panic to > before > > Fatal trap 12: page fault while in kernel mode > cpuid = 7; apic id = 0e > fault virtual address = 0x1 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff806e38aa > stack pointer = 0x28:0xfffffe047ba18440 > frame pointer = 0x28:0xfffffe047ba18490 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 2205 (main) > trap number = 12 > panic: page fault > cpuid = 7 > KDB: stack backtrace: > #0 0xffffffff80b240f7 at kdb_backtrace+0x67 > #1 0xffffffff80ad9462 at vpanic+0x182 > #2 0xffffffff80ad92d3 at panic+0x43 > #3 0xffffffff80fa1d51 at trap_fatal+0x351 > #4 0xffffffff80fa1f43 at trap_pfault+0x1e3 > #5 0xffffffff80fa14ec at trap+0x26c > #6 0xffffffff80f841c1 at calltrap+0x8 > #7 0xffffffff806e5a80 at generic_netmap_txsync+0x330 > #8 0xffffffff806e06f9 at netmap_ioctl+0x279 > #9 0xffffffff8098624f at devfs_ioctl_f+0x13f > #10 0xffffffff80b41b34 at kern_ioctl+0x2d4 > #11 0xffffffff80b417f1 at sys_ioctl+0x171 > #12 0xffffffff80fa26ae at amd64_syscall+0x4ce > #13 0xffffffff80f844ab at Xfast_syscall+0xfb > > This is on 11.0-RELEASE-p8 > > Thanks, > Joe Jones > > On 23/03/17 18:20, Vincenzo Maffione wrote: > >> Hi, >> You could try to use netmap in emulated mode (sysctl >> dev.netmap.admode=2). If this works, at least you know that the problem is >> in the cxgbe netmap support and not in the netmap core itself. >> >> Cheers, >> Vincenzo >> >> 2017-03-23 14:00 GMT+01:00 Joe Jones > >: >> >> Hello, >> >> We have a T520-SO and have made a new install of 11.0, to begin >> with the box would panic every time we tried to switch the card >> into netmap mode. So we recompiled the kernel with netmap removed, >> then compiled the netmap kernel module from github, as this in our >> experience generally leads to a more stable netmap. >> >> we have >> >> uname -a >> FreeBSD goose2 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 #0: Wed Mar >> 22 16:52:35 UTC 2017 joe@goose2:/usr/obj/usr/src/sys/GENERIC amd64 >> >> and the following in /boot/loader.conf >> >> t4fw_cfg_load="YES" >> t5fw_cfg_load="YES" >> if_cxgbe_load="YES" >> hw.cxgbe.fl_pktshift=0 >> hw.cxgbe.toecaps_allowed=0 >> hw.cxgbe.nnmtxq10g=8 >> hw.cxgbe.nnmrxq10g=8 >> hw.cxgbe.num_vis=2 >> >> Before I run our application I run >> >> ifconfig cxl1 promisc -vlanhwtag up >> >> Now our application can now start without panicking the kernel. >> Here is where it gets interesting, our application is able to >> announce it's self via ARP, I can see the ethernet switch learning >> which port it's on, and other hosts adding it to their ARP tables. >> When I try an ICMP ping it goes missing. After watching the TX >> packet graph for the connected port on the switch while starting >> and stopping a flood ping to the application, I'm sure the packets >> are getting sent to the card, however I don't see them in the >> netmap ring. If I kill our application, then use ifconfig to >> create and configure a vlan port I can confirm that the card is >> working and has connectivity. >> >> Here's what I think is happening. ARP requests are received >> because they are sent to the broadcast address. Our application >> then announces it's self. However traffic destined for the >> application is send to a MAC address which is neither the >> broadcast or the MAC programed into the hardware and is dropped. >> My understanding of promiscuous it that it informs the card that >> we want these dropped packets. It looks to me like, when the card >> is in netmap mode the promisc flag is being ignored. >> >> I have also tried using freebsd-update to update to p8. As with >> the p0 kernel we get a panic when we switch the card into netmap mode. >> >> We did previously have these cards working in netmap mode. We were >> using a pre 11 snapshot of the svn head though . >> >> Many Thanks >> >> Joe Jones >> Stream Technologies >> >> _______________________________________________ >> 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 >> " >> >> >> >> >> -- >> Vincenzo Maffione >> > > -- Vincenzo Maffione From owner-freebsd-net@freebsd.org Fri Mar 24 11:00:58 2017 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 6615DD196D0 for ; Fri, 24 Mar 2017 11:00:58 +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 55E06C8F for ; Fri, 24 Mar 2017 11:00:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2OB0wI2063750 for ; Fri, 24 Mar 2017 11:00:58 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 206567] [msk] msk0: watchdog timeout - 88E8053 on i386 Date: Fri, 24 Mar 2017 11:00:58 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.3-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: greg@unrelenting.technology 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.23 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, 24 Mar 2017 11:00:58 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206567 Greg V changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |greg@unrelenting.technology --- Comment #1 from Greg V --- Same thing happens to my Mac mini (2006 upgraded to Core2Duo & firmware from the 2007 model, HardenedBSD 11-STABLE amd64, booted via GRUB2 i386 EFI). One workaround I found on the freebsd.org forum is suspend_bounce, that wor= ked for me once but now my mini is not coming back from that suspended state. I guess using Wi-Fi is a better solution, since the Atheros card of the min= i is very well supported :D By the way, another msk problem =E2=80=94 trying to add msk0 as a laggport = to lagg0 results in a kernel panic. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Mar 24 11:20:51 2017 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 33ACBD19F41 for ; Fri, 24 Mar 2017 11:20:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 232E41A66 for ; Fri, 24 Mar 2017 11:20:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2OBKoNY009315 for ; Fri, 24 Mar 2017 11:20:51 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 211643] ixgbe(4) does not reliably bring up 10G links with ZyXEL XS1920 switches Date: Fri, 24 Mar 2017 11:20:50 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.3-RELEASE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: pi@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: 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.23 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, 24 Mar 2017 11:20:51 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211643 --- Comment #4 from Kurt Jaeger --- Supermicro provided a firmware upgrade for the ethernet interface firmware, tested with ubiquity, looks good. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Mar 24 11:28:58 2017 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 B6DF8D1B31C for ; Fri, 24 Mar 2017 11:28:58 +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 A65F41041 for ; Fri, 24 Mar 2017 11:28:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2OBSwiH027902 for ; Fri, 24 Mar 2017 11:28:58 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 211643] ixgbe(4) does not reliably bring up 10G links with ZyXEL XS1920 switches Date: Fri, 24 Mar 2017 11:28:58 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.3-RELEASE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: pi@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: 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.23 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, 24 Mar 2017 11:28:58 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211643 --- Comment #5 from Kurt Jaeger --- still open: Should the interface autonegotiate 10g ? It only works with ifconfig ix0 media 10gbase-t --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Mar 24 12:46:36 2017 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 970CDD18346 for ; Fri, 24 Mar 2017 12:46:36 +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 7B56AAE for ; Fri, 24 Mar 2017 12:46:36 +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 v2OCkZK8036467 for ; Fri, 24 Mar 2017 12:46:36 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 218005] sys/netinet/sctp_pcb.c: PVS-Studio: Unreachable code detected (CWE-561) Date: Fri, 24 Mar 2017 12:46:36 +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: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: tuexen@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.23 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, 24 Mar 2017 12:46:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218005 Michael Tuexen changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tuexen@freebsd.org --- Comment #1 from Michael Tuexen --- I would like to keep the code as is. In case of a panic I can still investi= gate the vrf. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Mar 24 13:40:26 2017 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 F0CFFD14664 for ; Fri, 24 Mar 2017 13:40:26 +0000 (UTC) (envelope-from Joe@stream-technologies.com) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00089.outbound.protection.outlook.com [40.107.0.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 539D11E25 for ; Fri, 24 Mar 2017 13:40:25 +0000 (UTC) (envelope-from Joe@stream-technologies.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=streamtechnologiesuk.onmicrosoft.com; s=selector1-streamtechnologies-com01e; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=an50YkUhRRQogfOM4aoWApFjJyXhPMcaIqmWTexZHzU=; b=kqF2Qe5DhoJr3VlLk2UmmH1cmaa4Da11gexRi2pBq3dwtO+73evK4Nm3ki9tuYOf14xMqP8F+DGHbsxPYSA2x5HuT/RZI8Ex6pCwe/3ganXDLwMmbhtwPAefya/jahegQ2z7cMX0MacReQPNtt5O4pxDO+9OMpses94+1ObIOls= Authentication-Results: freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=stream-technologies.com; Received: from [192.168.6.128] (212.20.240.118) by DB5PR07MB1031.eurprd07.prod.outlook.com (2a01:111:e400:510d::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Fri, 24 Mar 2017 13:40:21 +0000 Subject: Re: cxgbe netmap promiscuous mode? To: Navdeep Parhar References: <58D3C6F4.6010500@stream-technologies.com> CC: "freebsd-net@freebsd.org" From: Joe Jones Message-ID: <58D521C0.1000804@stream-technologies.com> Date: Fri, 24 Mar 2017 13:40:16 +0000 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: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [212.20.240.118] X-ClientProxiedBy: VI1PR0602CA0011.eurprd06.prod.outlook.com (2603:10a6:800:bc::21) To DB5PR07MB1031.eurprd07.prod.outlook.com (2a01:111:e400:510d::24) X-MS-Office365-Filtering-Correlation-Id: 0dba802f-2984-4c23-e74b-08d472bb515f X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DB5PR07MB1031; X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1031; 3:GMe6xcfCxqUqqMq4Wpgw3vR5afPH9dRlGFuIh7ie/y2jwjuhN24Mt50Hrw3jycYzMNL+4fMdRi2/zVgEEdetunGuweQ7vgeTr7TX4yQBr25ud85e6cdAx491eWuTV/wzobyCQzY3aS4OL2u4XY5vHyoHXJRIFgPoORBl/E6kP7JbNV/hzQqzx5Cs9kcUiPa/HhOMaf76h9hAcjEtssdYPmbJnPkRZD2e4LrFhmav9K79J+XY9ch4IxP2rgb/5c/o3Ad2C8c8BN+hbfMY71YRZg==; 25:MT9JdXshlS3TtFPaOfFp31G9giyWGUJMCQez+FefgakKIEXk2ntspe+CFobkqh5vt93gQcWHywoJ6iEkE+GFYGRnmjnb/zgj6dq1NsChWEylarnvxfxYHXHkhn0CbEPyGPW+dAEDcRD2X3oSXVOVuNBU2O2gMEknATCHm1yjCQuqZqk2tIYeP6ryz+qQ1c6KHP9ogmBTdu6J4sE016rLSyrhynJu7sRQJBfZyzkmMLqN3dDBIIvkqodcMzFTg8dWkvuZUKqHjjY68uT/yPm5okUXNKo5rV/rGYFPZcikxPBT0nZgYOKr9Avh5dMC5Sm7CyPuUl15jvxCpZvJbW5ZRa6Nz5n8Hik5p4polDUbkf5LPvZ3knCuYC2Q+5E1UDmqUFWmoscgU8c+bbdcPNWUF8PhsYxKLqFwB/vf5z+3/JBbZC2w57/A53dwLOKTmH4wqO0drDzRmRsxhjWWkl4ywg== X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1031; 31:Fubd3cSCKk9S9slOLz1wyUW9hC8yO8f4QjCwA+BxrscS1vfiZWL/gJVkzjEz20DgEjuq6HJWYG/5IguBHxMzjE9Mcp8iUSu5k42abBn/5DTCXF30sxmqlXif0YXhPDAn+kOcYTBidV17wu8f2eDsTljJRTrvh2LE7tYxXg0K8OybjdYzXnlE/cpg3BroYfE/saptCHVxW583iB5a2FVuTIErzzs3QgsWk0yeaHUZDmXQQUFjBqTVaED2dBIwsAGeXMf5Soo+ddF9ZhSLGbZIq+6LeCDxOUT1TKTIIK/RclM= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(75325880899374); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123558025)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:DB5PR07MB1031; BCL:0; PCL:0; RULEID:; SRVR:DB5PR07MB1031; X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1031; 4:6IPyuk3DEUPd4QcZROIppqfDYIIxEPWA7/k90GRzuowcxRQoeqvxtW7BairGFN9R5+jZfvHNK/efIFy8HeQf8lI5xS/DqxNJcgsKKCOZAwhlQL9J/2cUcxzv6ZJzq9ds0kXi11fgZ8HeOSi+uiOhNQITrE9o/66+QIh79W4PNZmVl9yQ/7evWD3y3nMGZl6EOd3kvF6CRlCWJ2NSKZnG+d/Q8K8dFPWDxBmyfwY43TM7GwUM8yoeQmyfyDuIP0GaFKa+rOOAYe0UU4bs9fpi/gC71rcGp10u9gGDFF3hz6x2EvZw84Z8RTSxlx9Q6CU+ac3/rqsGln9NoqPawhxn1bnHBLY6+bky/XF3RBVwwt97yYLxz1haXXIwkT58JzFezWzcvfVYspE65YShma8jEsqzeFmDoI/6XS8S8BBwt5OH5qJFI8vVNHCAwjqlyfBZYtbnDaowtI7d/psZxgSQMWEz0T2cTx1zb1rW7F8L+NlhnpV6WtbZRUfj7dj+Ad7emhk9HysxXL+/Hjb61XFg/quCH4rT9MJAt2TGlklJjIfVxxlIwaV2k1DOwGruc9lWijHzvstF5nYufYktpokdWcJdMHvHZ9eQUNlBJGWHxK5+XB0C8s+n/oBA6/KE0LU/fxAISIBeUk7EQnEY3xDSsQ== X-Forefront-PRVS: 0256C18696 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(6049001)(39410400002)(39450400003)(39830400002)(24454002)(377454003)(66654002)(6116002)(80792005)(76176999)(3846002)(80316001)(86362001)(64126003)(50986999)(65816999)(54356999)(4001350100001)(38730400002)(6666003)(23676002)(50466002)(6916009)(33656002)(66066001)(65806001)(110136004)(6246003)(117156001)(65956001)(47776003)(4326008)(230700001)(5660300001)(8676002)(3480700004)(81166006)(305945005)(53936002)(7736002)(2906002)(25786009)(2950100002)(1411001)(77096006)(36756003)(6486002)(229853002)(42186005)(83506001)(6306002)(189998001)(59896002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR07MB1031; H:[192.168.6.128]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjVQUjA3TUIxMDMxOzIzOlZ4VjE1cGFxNUlDT1Ewd2Z6d0xzK3cwOEdQ?= =?utf-8?B?Q2JwV29tWHVDckRCTHhyWWQ4bU9PdXVjaVhEMEsva2svUWhCeU15aDFGOXcy?= =?utf-8?B?T0w5OHNwOVZDTy9URWZ6MXU1bXI3b29yb3dTSUpEekZ1VG8xTmFlNVdVVjdh?= =?utf-8?B?Ym5MRGJuOWV0amVBUlh4c1U3VXBlaU1XMDc1d1NZMDNjYU5KTWNtMXFhL1VK?= =?utf-8?B?K1JIT0x3V0pyREVSeFEwYzA0TVBDVmV2WFlUQXFraGdMYXhFbDBTV1VHa2dT?= =?utf-8?B?LzAyRldxRGlOUDlDbzk4R1pNREFKWEZ1TC9sY3llSGptYnVYN0Y2QWNCQUty?= =?utf-8?B?ekYrZXRaN1QrQ2lOdnpYa1UvTnlhME5ScVBUR24vWGh4UXhrWFo1WnloV2ZQ?= =?utf-8?B?K1UzaUdSdjVXT2J2czZXQ2lFcDMwTXpOeFhLc2R1cXFFM3VwWC93MlkvVEQw?= =?utf-8?B?V3RTQk1XODRFYjFmT1BNNXRuZHUra3BkZEQ5ZW0rWXlCamFvS3BnZlBjclRZ?= =?utf-8?B?eGFyL09GTWw4S1E2UGs2aFFvQjB5YXdsNjVmbnRhME5BcytwOWo5QTEzTFhK?= =?utf-8?B?eG1TZjRPWjlaZUlDM0pvbVJsdzFrWkIrL1FEaVFRQVhiTEVjY2J6U1Q2RHhL?= =?utf-8?B?S29kVUZYeDdtR2tnR1JETUE5SFRxQlZ6Zk1kRFdTcFJCdHFYN3pwNkdEaFBn?= =?utf-8?B?NS9NNEJZM0s3UWRXdURTYjc3OURtWHNSRVQvTW9yTFJyT0RDSlNRTG9lQVBi?= =?utf-8?B?RjFOVlM2UVArR2tNQnJiUjlGRmJ6d1QvcFRZdi9SV1k4TThWSk5ZZ1pldDNh?= =?utf-8?B?T3ptdDhwZ1czcVhLUlhBYUF4UjU3bjVYYlF4bS9pUTZhSHNLOWgyZC9ncjZE?= =?utf-8?B?bkVCOWhpZlhrcHNtRkZHaWhLU1ZzcFlNdUVpa2tXdmRRRWJyd0tMUXBzZ1ZK?= =?utf-8?B?c2J5emw4RlcwdUZ6N3gyYnM4SFlySE1GSGlqcUdsS2xRNGVrZ1F6WXFwVDFP?= =?utf-8?B?b2pjMlhRbVhJVjlieHBRand4ZEh1OXhCTVMvSEtIWmhGOEcvVS9vOWFiN2xT?= =?utf-8?B?UHkxOVpCOTN4NjZYMEdkSUNSMjVkUTF0WndEME9sR3lzeVd3MlZ3ZDJyT0Vi?= =?utf-8?B?MS82N2R1cEozZm0zYnVrUnlNOTVMdHM4TXcrOFNvV25aMjh6d1o0RDQ3NTlM?= =?utf-8?B?VnhGcUQ1Nytwb0lqMEF3VHFZbDRrTW90VXlFcWM3L2UyUWRQL1hzOGEzZHd0?= =?utf-8?B?dTdPMUE1K1oxRnI3RVFvSDZBQzh2MU1qWURWa0xFNGJXM3dNRVNXQVNuYkE3?= =?utf-8?B?OXlNam91bGMvWDQzRGpmYzJZZ1lFVFRpcDJ5OERub2llb2VxdjBkdXdBVUtB?= =?utf-8?B?eHdFeHpsdXB0ZTYxeWFUaUxPdGQxWTN2S2UxbnhNMXRld010WnRGNWE1L2xK?= =?utf-8?B?bDFGaDZnSnJPbDNleDRiRFpvVEYvUVV1SDFJMmJpQ2UwMGI4cWgzSnZNeWdR?= =?utf-8?B?TnJaTFBuc2FlUjVNTTllSWJLOTZRUFd5L2FORGwrRFhDbUVqRGw5dXVJbjA3?= =?utf-8?B?Vjc5aUNGM2JkRCtWSkNsL25GWnk4bjh6eWQ5NHhhUmpicEtYck1OQTdLdXph?= =?utf-8?B?Ny9EQzhhZTQ2R2w1TTBRTHJhK2FvNkZkZTdDUElsaFFKNnY5eXNUQUwxNTRq?= =?utf-8?B?RG5ZR2hnV1VLcTgzMjFqcWJFQzdST1BHbEZMSTJ0WHVlUGVicDJZYU9sZkM4?= =?utf-8?B?RG9VQ3lUT00zdUs4MXMyRDJDMXFGRFNESjJnMkVSZnQ2T1ZDY0Qxc0tkYXlJ?= =?utf-8?Q?lA56U6qUKJLR3?= X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1031; 6:xxmaLFsmgvw6Od7F1PV2TNgRM+yId7xv9p2s/N27+l6c4drQB67+IvldPB8sL2jyLINarwtufDNO9V6PcERdQKYDkL0RgIgM+usxRR9MKIfe/PkzG0+BmMbxKoLhYBmWTyZ4ekvVqI+FEWh1eCpmHHATU88BvcbmwnJJRv5OycvAOTyIKuIRwzCwyuH+pCFLuKuTYLUEuoYbmiosha6IQ1xtPTNa21JLVVCmJG1IVai10dASZb4PleJtWxIDd/xiYxsFnLSUfqP6nUqXqwD65Y6OI3vsfb8ZTtpwQevmYIaLtBkG7+MCWZSm28Dmy0kDnKncuaPOwaLuXILdqlCRMdmETK8sl45HugGEYQhU1/0qFQUZlWOTpMmkozxxIM6x0emHgSzLI4OGt0rLYaAb5w==; 5:q8pECWFT+Z6WHHccM8KK8zZAsrlz8iuagDSUaqoKoPmcYMTSmRCCZzaFlhh1EsLE6MK6cZGncsemHlifPMz6gnNc20yl8NEB76LtBOT+qZWeBSiKvps9SQcrsuSQTQtDuHz9TGF0TPzssQbeD74Vrw==; 24:AMn0MrObvUM9gS7blwjS3P6XAqfi6fpFx9aDcZHwiSO1PzfZnzV/8j2u+rpaFzAq8ul1Q/m4aDoKCuGtWaU/wNpH0yQL9+lHbLX+iXRyZIc= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1031; 7:z0IITXbF7QwOFprbzZJRedNEbkyI5u7EdPxMzYY6eaYl/REf5cbdjdCqjefxji28H6kEY/XzJGo2oyru9dSemI0Lj3JESF0lrPz9qYD+rz1eEYZRrmTh7qyFcQHJbNbZtXi4qtsbtVUzBdEx9/XrG1bZgu+VbyiUV+R7uuJrM/YPPbTVpT5sHVUUvkVOiM50X0V0tyQ1PAE2BFaNOqibXmJNSZ7QLfxdXqLrD3XBsoWoFWklCkndgWWa3P2aH22QJGmq/7DHcBlwK/v/LHcVIrRkTcjI7k+tepk7UWpN1d2fWoUrZU5kROMmWDPCD5K7wI7U0eqPAo0XIF0DL7Y8mw== X-OriginatorOrg: stream-technologies.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Mar 2017 13:40:21.2320 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1031 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 24 Mar 2017 13:40:27 -0000 Hello Navdeep, This is the panic from 11.0-RELEASE-p8, I think p0 panicked in the same generic_netmap_txsync function. Fatal trap 12: page fault while in kernel mode cpuid = 5; apic id = 0a fault virtual address = 0x1 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff806e38aa stack pointer = 0x28:0xfffffe047ba18440 frame pointer = 0x28:0xfffffe047ba18490 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2191 (main) trap number = 12 panic: page fault cpuid = 5 KDB: stack backtrace: #0 0xffffffff80b240f7 at kdb_backtrace+0x67 #1 0xffffffff80ad9462 at vpanic+0x182 #2 0xffffffff80ad92d3 at panic+0x43 #3 0xffffffff80fa1d51 at trap_fatal+0x351 #4 0xffffffff80fa1f43 at trap_pfault+0x1e3 #5 0xffffffff80fa14ec at trap+0x26c #6 0xffffffff80f841c1 at calltrap+0x8 #7 0xffffffff806e5a80 at generic_netmap_txsync+0x330 #8 0xffffffff806e06f9 at netmap_ioctl+0x279 #9 0xffffffff8098624f at devfs_ioctl_f+0x13f #10 0xffffffff80b41b34 at kern_ioctl+0x2d4 #11 0xffffffff80b417f1 at sys_ioctl+0x171 #12 0xffffffff80fa26ae at amd64_syscall+0x4ce #13 0xffffffff80f844ab at Xfast_syscall+0xfb We were using our own MACs, we can fix the problem by using the mac from the vcxl interface. Should we not be able to capture all traffic on the interface regardless of what destination MAC it has. Thanks Joe Jones On 23/03/17 18:38, Navdeep Parhar wrote: > Your netmap application should be using the 'vcxl' interface, not the > cxl interface. Even though they share a physical port they have > different MAC addresses and are totally autonomous. The peer should > use the vcxl interface's MAC if it wants to reach the netmap > application. > > Do you have the panic message and stack? I know of a couple of panics > that have been fixed in -STABLE -- one was one related to emulated > mode and the second one was an illegal lock acquisition. > > Regards, > Navdeep > > On Thu, Mar 23, 2017 at 6:00 AM, Joe Jones wrote: >> Hello, >> >> We have a T520-SO and have made a new install of 11.0, to begin with the box >> would panic every time we tried to switch the card into netmap mode. So we >> recompiled the kernel with netmap removed, then compiled the netmap kernel >> module from github, as this in our experience generally leads to a more >> stable netmap. >> >> we have >> >> uname -a >> FreeBSD goose2 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 #0: Wed Mar 22 >> 16:52:35 UTC 2017 joe@goose2:/usr/obj/usr/src/sys/GENERIC amd64 >> >> and the following in /boot/loader.conf >> >> t4fw_cfg_load="YES" >> t5fw_cfg_load="YES" >> if_cxgbe_load="YES" >> hw.cxgbe.fl_pktshift=0 >> hw.cxgbe.toecaps_allowed=0 >> hw.cxgbe.nnmtxq10g=8 >> hw.cxgbe.nnmrxq10g=8 >> hw.cxgbe.num_vis=2 >> >> Before I run our application I run >> >> ifconfig cxl1 promisc -vlanhwtag up >> >> Now our application can now start without panicking the kernel. Here is >> where it gets interesting, our application is able to announce it's self via >> ARP, I can see the ethernet switch learning which port it's on, and other >> hosts adding it to their ARP tables. When I try an ICMP ping it goes >> missing. After watching the TX packet graph for the connected port on the >> switch while starting and stopping a flood ping to the application, I'm sure >> the packets are getting sent to the card, however I don't see them in the >> netmap ring. If I kill our application, then use ifconfig to create and >> configure a vlan port I can confirm that the card is working and has >> connectivity. >> >> Here's what I think is happening. ARP requests are received because they are >> sent to the broadcast address. Our application then announces it's self. >> However traffic destined for the application is send to a MAC address which >> is neither the broadcast or the MAC programed into the hardware and is >> dropped. My understanding of promiscuous it that it informs the card that we >> want these dropped packets. It looks to me like, when the card is in netmap >> mode the promisc flag is being ignored. >> >> I have also tried using freebsd-update to update to p8. As with the p0 >> kernel we get a panic when we switch the card into netmap mode. >> >> We did previously have these cards working in netmap mode. We were using a >> pre 11 snapshot of the svn head though . >> >> Many Thanks >> >> Joe Jones >> Stream Technologies >> >> _______________________________________________ >> 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 24 13:50:49 2017 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 4679AD14B17 for ; Fri, 24 Mar 2017 13:50:49 +0000 (UTC) (envelope-from Joe@stream-technologies.com) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0065.outbound.protection.outlook.com [104.47.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 83520803 for ; Fri, 24 Mar 2017 13:50:47 +0000 (UTC) (envelope-from Joe@stream-technologies.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=streamtechnologiesuk.onmicrosoft.com; s=selector1-streamtechnologies-com01e; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4zbSTKNDGHcfGtJrN4MfqGm/xCrIMuhUGFgx3q+mCLk=; b=RMzdzgaKZ3naFpWDK1nIhGwt7dOLdwVDIxRWzIRX2K0ArMLEB+n1n9ywzFMCT+knlxV5mbJbp1jTEu4Avh9MaEhW/dkCsy8L1yH5kw/4Y/WHGC/Edoa5kbVdfhnf79lkWJ1i03UbhWDRmecwhlDoucXKFM0mpEvbB6oJ7KOOWY0= Authentication-Results: freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=stream-technologies.com; Received: from [192.168.6.128] (212.20.240.118) by HE1PR07MB1034.eurprd07.prod.outlook.com (10.162.27.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Fri, 24 Mar 2017 13:50:43 +0000 Subject: Re: cxgbe netmap promiscuous mode? To: Vincenzo Maffione References: <58D3C6F4.6010500@stream-technologies.com> <58D4F2C5.9020204@stream-technologies.com> CC: "freebsd-net@freebsd.org" From: Joe Jones Message-ID: <58D5242F.9040706@stream-technologies.com> Date: Fri, 24 Mar 2017 13:50:39 +0000 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: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [212.20.240.118] X-ClientProxiedBy: HE1PR0901CA0062.eurprd09.prod.outlook.com (10.168.89.158) To HE1PR07MB1034.eurprd07.prod.outlook.com (10.162.27.26) X-MS-Office365-Filtering-Correlation-Id: 654d5e32-07a7-4bea-6942-08d472bcc422 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:HE1PR07MB1034; X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1034; 3:b1u7dHJLfaQ0KkfuO9RRqRm5LrLZyN0UNMkmL4xAzchVia5yCScqcXV0tp8ni5sbhkGtMbUtyXoXErZGjCRi18AELUKwVpg2cKqBORSAjW0/S0eKDcKPTKD4bZuiYrB4ccKeesDHV+L2zIayPFJjILsoKnGjGI4pwSTfcdUTUoyrXnd9CNiX3lC/WYDuDINonvXGVbfsQJ8QW7F/F+Vf0ibjP0yaJKk8ka1qJ41VCM/DQ5jkYRsOFcWIQjt/9aeduZN4EuMk+ZLMUg02is2Yxg==; 25:C0OsuKYVtvhbjXbLba3pKF6nZOLoMMFDj3crnJZ/itMfYmgyYA9Rv2BDHBf1Ijpj2IKbGFVZJwcnBWBHqVMFUV/RBOzO1R9ofMGkvYjBx31TWt8l7ifYvmFArhJjgzeeqa7NRZqJz9GvChGb4iEBvfUiklcXFelAPfgrcq+aVXFbzlkVddyb9L/ziz3sMNTy87iL8v0Yt++I3dXwyqHK5VHHGptBVJ1yxVBnRRsqetP0gI9Q8GizdozFEI1WercZHG432eks/Bl434xcQ0HyLqT81h1NjptNAZAGdRWGm0tR4030/W8gE1l9ct0nuc1KDOgia+2Q2DH+SxrgV7Dvty2wRMeSGzJbAcBsIZohsXcrx9cKeT8q0eiq92Ti1qaAgqUI6aX9a6rpR3OwA6+aNY9bS27vc3CQB0q7nIHQ5DLE6D2NfAT8+o+jJFVSEuae2Yg7ZSLXtuibbGkfBLcQgQ== X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1034; 31:Z2PgTqWqgTelHOaK6OKV9FpSnZ5ss2Wz+t89u0Z1ZjEslElHNVN7oVekXW3mUuhFUnCEN/ZACBzjhHjRatCEhpUVqNvxTDxg5aBv/+HWOB3D1FY7iFtBm5iNv/GVZpj9tCXjAXpKTnHDrz805nXcDQbejBe2Ury/Aw3it9T5PCS5XnDncHNTn35GjECr4PTft0y/nMqwFZsTJQrCj5TajmL++UihCU75CWspMVdlIbC6F+tQ6lvbXwrBfsjkDe+fy9svF92LxS7fJQzZitv5yw== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(75325880899374); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040391)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123558025)(20161123562025)(20161123564025)(20161123555025)(201703131423016)(201702281528016)(201703061421016)(201703061406016)(20161123560025)(6072148); SRVR:HE1PR07MB1034; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1034; X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1034; 4:QSwsGqmdUsHxeQU9NAhikxEk5tQssjYp0ugo67b28661MlFo5/1vbssVjaa6/GOfgz87momPfhozhjKrelijzLO+vIM1oYutV+PvmRaz2AT10IvOOHDQG5Nblib8pYpEixUA4UXTrAdmEVkrZ3SAL2ME29U9s7/CbYhMrrmPjP56zTXJCh0wa2dUESz8X/HhhU367c+4v0phgccV4H4gWpQjusXWKCBSa/K2Klqof2fX19aWT69ZAKVR8GyjOUzjWwATyeQUXTHAYHRL0AbCAdQTDy6O10eZcHyLjRoCBFcBYByFGOSqbeHABM9nV2xrIQD0bM0XseG7A9ZIiEqb29kflynF5EIJzWUsZMupq/HDziQkHAT7sQ1okU507yGEC76a+Dp+LXoHusZvQVyGXK9YUMwRYAfPz3XHLni+iP7c9FUMAfWLCAiSC4UZFBhh7Hkyb10SA/1elJhb6HQ7lYSxYkDs1jOCJ0pB8JM+vhgXmUvnHN0Msbj5rdibPZIfXPYnewzcn8o+pR8K6YoQEz3lhLG/7mBQ0/q+KX/pEMaNo09uCLJu591LersAaxFRDI3zaQMdi9tI7d/z0dr+o/basguAmBiC0gwLJVM9BJHuzcl9G+ffCkGukLagKKM+6UcnTMZlkDXTv0v9xJivQfQNsLuwNsniyhBMbnAOZG9DEBvzc40Y0LntExr+Ju755PQstB6xkJDyIVaHA6t3Fp0AWMxjrPwHVNBRua8MPA3dF/2s471a9ly5sH2UoEL7M76iZVXcBQnBJ5IUQ/jIupAvh82qS40PwaOO4rcO6xc= X-Forefront-PRVS: 0256C18696 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(6049001)(39830400002)(39410400002)(39450400003)(39400400002)(377424004)(24454002)(66654002)(25786009)(66066001)(23676002)(6666003)(2950100002)(47776003)(80316001)(65806001)(6916009)(53936002)(6306002)(64126003)(5660300001)(77096006)(3846002)(50986999)(80792005)(4001350100001)(65816999)(229853002)(189998001)(38730400002)(6246003)(110136004)(36756003)(76176999)(3480700004)(54356999)(6116002)(86362001)(83506001)(65956001)(42186005)(59896002)(93886004)(117156001)(8676002)(4326008)(2906002)(90366009)(6486002)(50466002)(81166006)(33656002)(230700001)(305945005)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB1034; H:[192.168.6.128]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3TUIxMDM0OzIzOitTMkIvU21hdTBZRDNJMkEyM3pIbFhsMmhN?= =?utf-8?B?ZU9JNmc2ajdBQXdlSnhTYWxnZzkrSlh1WlRtTk0wblBBSGVwU0Y5K1UvbUV0?= =?utf-8?B?NVZ6OFlpcUdlL3NNY2JXMWI0WU5lNnExQnNIY3RUS05YbWJ6L3R3UXE0V1l2?= =?utf-8?B?K29vSDRsWXcwZzlEMkZCZW9sTjBFY1p6TW51ZWFaNVhneTJuaWNsU3I4WHJB?= =?utf-8?B?TExheU1QdmtYMnRVcHdqenhwK0pVSkhjOTlETWsxWTUzWlFvazNjci91UlJD?= =?utf-8?B?L3BlK0Z3YlFIc3c1VTF2QmNrb2lsNmdyQkM5Q0JnQ3AyOXRrU0FXcWR0Zk4w?= =?utf-8?B?UzJYUTdnNkRmdlE1c0tpSWFVUW9GZCtNNkRjcURpRTBMd2Q4WnFjVE5OZFFG?= =?utf-8?B?U3lIcnBvVjFEZEx5b2NTK2oxdGZ0bm9KMVFTVFhTR2ZDRk43L2NwNFdKMnh2?= =?utf-8?B?UkQweE9tdy95eDIzMlpJUlJBU1dvQzE3M2tnUW4wTkVONVlkQXA2TS9KVXhH?= =?utf-8?B?RVIxNXBUa3E1K0xrRC9hUWhLY2x2SGpYVjlLakl6OWZCcS8ySHpyY3dOMFY3?= =?utf-8?B?dWtESzJwelkzckpRSWI0VWlNYkptdjkwQUxRdjQ4MXQ2TFJVVi9GdnY4R1Rv?= =?utf-8?B?RDNieDRRaFV0ZGM5ZTlzM1J0aU5xWDhXWnk4NEhSMDFYdUptUmZnVERoazFk?= =?utf-8?B?ZkkrMTNHVHRxdmJEL0JkRnM0UXpSeWZjNnEwMTJWTUFXdVVXTVFrMmdhcDlv?= =?utf-8?B?b1VvRmdvQUlvdTh6RXVkTmNZUkxib2FRcDMzZ2F3Nmt5ZW1MR0lSaGh0NEw5?= =?utf-8?B?VjlIczhKaEZyU0E0VFVuckJPMHlOSzh6Q2RSY3NmTEdLcGliT0NmRWVsS0dl?= =?utf-8?B?TExJVkx1NHhEWnNFazRLQ1ROam5ybTN0Zjgxb3pLaG92VktpWnJ3SnB4blJZ?= =?utf-8?B?QklnTVpwMzUxdzhFRnlNK3NVSjh3ejRwaFhra08wY2l6RVVUd2piZnBSZW5o?= =?utf-8?B?WGtJSU1wU3djUjhNTG96U28rUEVtWVJwbkNRTXoxSkNTU3hDRlNHZXp5N3R6?= =?utf-8?B?aTAwNlJKUDFBTVdSbXlOR1VxNnZiVFIrNkg3UmQ1TTJnN29GVUJ6VEFDbWtt?= =?utf-8?B?YU9OSDRUU0I2YVhZWGNGL2lIMUUzLzZ1N1d1YXZZRkRDV01USDRMVXZJV0xu?= =?utf-8?B?eHI3dDRqMkEwZ003bVhCOTViSWM4L3VNR3dOQnI4b0UxTVZxNVVDV1R4REpC?= =?utf-8?B?REVseVRtcFE5ejNnSTZ4ZUcyRlcwRENISzNZK1FQZmxTbG9BSXV6Z0QyaTE0?= =?utf-8?B?UkNmV3hxMVl3OG9KaGhyc2ZGZ2NFZG9QSExNOGh5ZWExN1lwYnh4bXBSa09m?= =?utf-8?B?bXBIOTkvVituSEdBMTBNdHQzbmhiMU5sY1lPSlBVRFBjTU9FZXlLUGxzcmxF?= =?utf-8?B?QXM0UURubW5NRU1qRkFQN3dhSXVsNk80STBFWXFXVXEvRVYrL1NYQXM4cEtL?= =?utf-8?B?YnlvemJyY2V5d1ptRVZsR0xVQ1ZkaGxsSUF5ZlZFbWRlUkNabS9BQWdINHV6?= =?utf-8?B?dERCNENWait3U0ZERUlwblkyU2pLNzhkV3JFeWU3cVk2N1grZTVzRlZwcmNI?= =?utf-8?B?UjhFSldGeUhlTUJSRE1BM2RiQnRVZnd4NmhsbW9LUmZiQlh4TWZISzJJWXRE?= =?utf-8?B?eG1lVXhXc0VUQ0RHQ1NOR29Mb3g3RnovZjNhaWVMQ3VUREtWRTVqVTdjbGJv?= =?utf-8?B?dGx5YUYwT2ZabkV6VHhsY3E2bEQ0S2xoQ1VQSHB2N3ErNlp4SjE3WEVtd3V1?= =?utf-8?B?cmQwb3ZKWEdDSkxhYmhxUTVKYVNCaExXZFRrK2ZnQW0vcWlFK0FNMmVyUldM?= =?utf-8?Q?i7s1DaTonh4=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1034; 6:zEBfwEDCtn12hWKgHdl6DGNLUycVaRPvuT502B2h+IaUWwzuWufILSOgUruLuwDKTyFO33kLfz/PL2tNOAujRJA7DPsoPx0LSKvIP6RHNn3EGye+mu5t7A16gJ2jbO7R57xRbgFrumb0MhrLCPy7+XIZwXiZEZToOb4o9rpuDl0PlnqGFXZQC6aRBQQ28HETH4MhHPDvWYejhGQA+Th9q9EPih0IgDzslWf5bhwJxOFj2rvXWZVG0Dnn3jwPU8aTiABZrtvCYaw7S4ehkywwJxfxZz7oIYe36Veb14ButN7UpCqAwseVSVd2JFVwYt5HehZr5UvfHAa6JoKEXR1v65b9gfjGor4s0PKjwBH7EVaJ6P5aqQDBoSvkZttAs9VJ2FQ9PSYHqwgXq+7RGBt/Lw==; 5:KTTtflmBWgteo2Tu27c+pOFQ3bKjnknXqPmgFofRfYahtmuBqPXXhNUK+94pGFRpknwYmgxhwkROj2vCwD54t+0U3d/OEeirgtdG/BIPifAbT6f1rLYdrIvdsq+A/I4e2kMUbpzJHeTCicTbJBP2sA==; 24:3f8Gw16SeOQ0QJL4uksH3IG5GPnoQucAz+b2S+et72ZVilO85X7RU8RrWiHHVHeFBq663QoYJnEy1zrriroFxuLVoBu8IZTkaNg5tyDOprA= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1034; 7:3fosPaDSQxwW+6c764lilvu/ffXKNMLdVKphjoXjEvbAA0l1LIsIFCskeIPAd5pNpPLWI950FKI+trTBD7r/W9tRbLFlS2CWCGaw9PTHkri2R0RkOSsBa/tvQ8y34ES54BcVFZgmMaVG/8IUKK3TiCNiAuGGlIRqCaWmAW4MiF/Z6q85/XvNjtExeN8lDm3WTnUz3jHGDz5M9ooKnOZhu/9D3YviK5Ub0GLqSPIqsJwRW5M1oZJUiEIG+O/kK02EAtkYs4CtKGl5UlZoAkE4iq7V9es50mTzl9/b2TbWIDjCmhGRP2oaDIlgU2e3HK1Ju6JhzF8wJMxXzig6Fm3Fig== X-OriginatorOrg: stream-technologies.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Mar 2017 13:50:43.3478 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1034 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 24 Mar 2017 13:50:49 -0000 Hi Vincenzo, we can get rid if the panic if we compile the kernel without netmap, then load an up to date netmap as a module. We can live with that for now. Some time last year before Free BSD 11 was branched from head, we compiled a checkout and it worked without problem on the same hardware setup. I may try and figure out what the regression is, I'm not familiar with the FreeBSD release process either though. Thanks, Joe Jones On 24/03/17 10:29, Vincenzo Maffione wrote: > Hi Joe, > There was a fix for a panic in emulated mode that was applied > stable/11 branch, so I guess it also ended up into FreeBSD-11.0-STABLE. > I don't know whether the same fix ended up into in 11.0-RELEASE-p8 > (I'm not familiar with FreeBSD releasing process, sorry!). > > Or maybe this panic happens with netmap upstream? > If this is a new bug, it would be nice to have the kernel with the > debug symbols enabled, so that we can get more detailed information > from the stack trace. > > Cheers, > Vincenzo > > 2017-03-24 11:19 GMT+01:00 Joe Jones >: > > Hi Vincenzo, > > I just tried with that sysctl set to 2, I get a similar looking > panic to before > > Fatal trap 12: page fault while in kernel mode > cpuid = 7; apic id = 0e > fault virtual address = 0x1 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff806e38aa > stack pointer = 0x28:0xfffffe047ba18440 > frame pointer = 0x28:0xfffffe047ba18490 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 2205 (main) > trap number = 12 > panic: page fault > cpuid = 7 > KDB: stack backtrace: > #0 0xffffffff80b240f7 at kdb_backtrace+0x67 > #1 0xffffffff80ad9462 at vpanic+0x182 > #2 0xffffffff80ad92d3 at panic+0x43 > #3 0xffffffff80fa1d51 at trap_fatal+0x351 > #4 0xffffffff80fa1f43 at trap_pfault+0x1e3 > #5 0xffffffff80fa14ec at trap+0x26c > #6 0xffffffff80f841c1 at calltrap+0x8 > #7 0xffffffff806e5a80 at generic_netmap_txsync+0x330 > #8 0xffffffff806e06f9 at netmap_ioctl+0x279 > #9 0xffffffff8098624f at devfs_ioctl_f+0x13f > #10 0xffffffff80b41b34 at kern_ioctl+0x2d4 > #11 0xffffffff80b417f1 at sys_ioctl+0x171 > #12 0xffffffff80fa26ae at amd64_syscall+0x4ce > #13 0xffffffff80f844ab at Xfast_syscall+0xfb > > This is on 11.0-RELEASE-p8 > > Thanks, > Joe Jones > > On 23/03/17 18:20, Vincenzo Maffione wrote: > > Hi, > You could try to use netmap in emulated mode (sysctl > dev.netmap.admode=2). If this works, at least you know that > the problem is in the cxgbe netmap support and not in the > netmap core itself. > > Cheers, > Vincenzo > > 2017-03-23 14:00 GMT+01:00 Joe Jones > > >>: > > Hello, > > We have a T520-SO and have made a new install of 11.0, to > begin > with the box would panic every time we tried to switch the > card > into netmap mode. So we recompiled the kernel with netmap > removed, > then compiled the netmap kernel module from github, as > this in our > experience generally leads to a more stable netmap. > > we have > > uname -a > FreeBSD goose2 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 #0: > Wed Mar > 22 16:52:35 UTC 2017 > joe@goose2:/usr/obj/usr/src/sys/GENERIC amd64 > > and the following in /boot/loader.conf > > t4fw_cfg_load="YES" > t5fw_cfg_load="YES" > if_cxgbe_load="YES" > hw.cxgbe.fl_pktshift=0 > hw.cxgbe.toecaps_allowed=0 > hw.cxgbe.nnmtxq10g=8 > hw.cxgbe.nnmrxq10g=8 > hw.cxgbe.num_vis=2 > > Before I run our application I run > > ifconfig cxl1 promisc -vlanhwtag up > > Now our application can now start without panicking the > kernel. > Here is where it gets interesting, our application is able to > announce it's self via ARP, I can see the ethernet switch > learning > which port it's on, and other hosts adding it to their ARP > tables. > When I try an ICMP ping it goes missing. After watching the TX > packet graph for the connected port on the switch while > starting > and stopping a flood ping to the application, I'm sure the > packets > are getting sent to the card, however I don't see them in the > netmap ring. If I kill our application, then use ifconfig to > create and configure a vlan port I can confirm that the > card is > working and has connectivity. > > Here's what I think is happening. ARP requests are received > because they are sent to the broadcast address. Our > application > then announces it's self. However traffic destined for the > application is send to a MAC address which is neither the > broadcast or the MAC programed into the hardware and is > dropped. > My understanding of promiscuous it that it informs the > card that > we want these dropped packets. It looks to me like, when > the card > is in netmap mode the promisc flag is being ignored. > > I have also tried using freebsd-update to update to p8. As > with > the p0 kernel we get a panic when we switch the card into > netmap mode. > > We did previously have these cards working in netmap mode. > We were > using a pre 11 snapshot of the svn head though . > > Many Thanks > > Joe Jones > Stream Technologies > > _______________________________________________ > 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 > > >" > > > > > -- > Vincenzo Maffione > > > > > > -- > Vincenzo Maffione From owner-freebsd-net@freebsd.org Fri Mar 24 14:02:57 2017 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 D6069D1B08B for ; Fri, 24 Mar 2017 14:02:57 +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 C535D11C2 for ; Fri, 24 Mar 2017 14:02:57 +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 v2OE2uNm045890 for ; Fri, 24 Mar 2017 14:02:57 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 218041] sys/dev/e1000/if_em.c: PVS-Studio: V646: possible 'else' keyword missing Date: Fri, 24 Mar 2017 14:02:57 +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: CURRENT X-Bugzilla-Keywords: IntelNetworking, patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: sbruno@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.23 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, 24 Mar 2017 14:02:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218041 Sean Bruno changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-net@FreeBSD.org |sbruno@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Mar 24 14:10:25 2017 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 575B5D1B2A4 for ; Fri, 24 Mar 2017 14:10: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 46A5813BD for ; Fri, 24 Mar 2017 14:10: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 v2OEAPVw057576 for ; Fri, 24 Mar 2017 14:10:25 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 218062] Panic (trap 12) at at ixgbe_handle_msf+0xb7 after r315333 Date: Fri, 24 Mar 2017 14:10: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: 10.3-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@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: assigned_to cc keywords 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.23 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, 24 Mar 2017 14:10:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218062 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org CC| |sbruno@FreeBSD.org Keywords| |IntelNetworking --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Mar 24 14:17:55 2017 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 2C8CAD1B6FD for ; Fri, 24 Mar 2017 14:17:55 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E07B51A90 for ; Fri, 24 Mar 2017 14:17:54 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-oi0-x22e.google.com with SMTP id r203so1907474oib.3 for ; Fri, 24 Mar 2017 07:17:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NVMK6deVRcEPfacgnG0unobouDn+EWW1ZgnUS5xmxFE=; b=swQx+4+4D997hUiLbV7doAIKge/BQBakRyjWLxfrz4jy1UNz1dX5QguAjZw5HHKpqC TmD06Vn+copEMPI7czA77qQXHMAfaoNUEnw9azwdT48RcH+W5j9Ti5XKNw678Pl3uYtO APrVSa6ZQQxEVx0GaUdXzq7AXYO5A+iC/mitzvew7IucrWcMOExOb9u/sgWucRcTDRpR xKaMhfZ8hVSMHDPk3ZsBvb/kI0WZizMWNzIdE7ww90Syl8megIzREnA7RE5xnmetvVxw yoI/0H0w6kZv59kBWlmTpAn9eVzPH3h/hV1uhN+sRinSAWnXDDqbPfU0tiiC3jc1Vqry I3gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NVMK6deVRcEPfacgnG0unobouDn+EWW1ZgnUS5xmxFE=; b=P/LNwZ8mMvE5mA7YA/AWgzIpL4GLROlGRj3mdkGkzrhJDiz3RfkfyfHzqCtgEdP00g 70Cj6SUErIUwmr1ZLay0IODfgI/bdf5DQXseioqJm0L/C7k8CRi6LsNcQjvqbHbaDoLH fGeu8EOiaKKjrlwYicPm4PONgge1BPVCu5FwGz9VsaM6oD7Mdy7myek/3uoOeMZQYadl DTXZo/8LN6xb0nPKE/aKJydOKdM9ofh3bogTqJj3i05PlN4FMaXj4FTBewg0Fu+PHzJW qvuR2iQo7sFpsAS3T76EUPlhrygXOT6O1qf+urj5KmDeAOEjzEATd9hKLJ+qIljHuj+P TGQw== X-Gm-Message-State: AFeK/H1V3DBlVffc4IDgO5DcyVBK04tAB8ZGeipEcz4DK2HYU8fHJnJSIDequEyfNPXNLWKaOGeUQEgSMNnaZw== X-Received: by 10.202.105.147 with SMTP id e141mr4148933oic.103.1490365074017; Fri, 24 Mar 2017 07:17:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.50.45 with HTTP; Fri, 24 Mar 2017 07:17:53 -0700 (PDT) In-Reply-To: <58D5242F.9040706@stream-technologies.com> References: <58D3C6F4.6010500@stream-technologies.com> <58D4F2C5.9020204@stream-technologies.com> <58D5242F.9040706@stream-technologies.com> From: Vincenzo Maffione Date: Fri, 24 Mar 2017 15:17:53 +0100 Message-ID: Subject: Re: cxgbe netmap promiscuous mode? To: Joe Jones Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 24 Mar 2017 14:17:55 -0000 Hi Joe, From your description it's pretty clear that you hit the FreeBSD11 bug that is now fixed in 11.0-stable (in addition to the upstream netmap version on github). The fix was committed in r312783. Cheers, Vincenzo 2017-03-24 14:50 GMT+01:00 Joe Jones : > Hi Vincenzo, > > we can get rid if the panic if we compile the kernel without netmap, then > load an up to date netmap as a module. We can live with that for now. > > Some time last year before Free BSD 11 was branched from head, we compiled > a checkout and it worked without problem on the same hardware setup. I may > try and figure out what the regression is, I'm not familiar with the > FreeBSD release process either though. > > Thanks, > Joe Jones > > On 24/03/17 10:29, Vincenzo Maffione wrote: > >> Hi Joe, >> There was a fix for a panic in emulated mode that was applied stable/11 >> branch, so I guess it also ended up into FreeBSD-11.0-STABLE. >> I don't know whether the same fix ended up into in 11.0-RELEASE-p8 (I'm >> not familiar with FreeBSD releasing process, sorry!). >> >> Or maybe this panic happens with netmap upstream? >> If this is a new bug, it would be nice to have the kernel with the debug >> symbols enabled, so that we can get more detailed information from the >> stack trace. >> >> Cheers, >> Vincenzo >> >> 2017-03-24 11:19 GMT+01:00 Joe Jones > >: >> >> >> Hi Vincenzo, >> >> I just tried with that sysctl set to 2, I get a similar looking >> panic to before >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 7; apic id = 0e >> fault virtual address = 0x1 >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0xffffffff806e38aa >> stack pointer = 0x28:0xfffffe047ba18440 >> frame pointer = 0x28:0xfffffe047ba18490 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 2205 (main) >> trap number = 12 >> panic: page fault >> cpuid = 7 >> KDB: stack backtrace: >> #0 0xffffffff80b240f7 at kdb_backtrace+0x67 >> #1 0xffffffff80ad9462 at vpanic+0x182 >> #2 0xffffffff80ad92d3 at panic+0x43 >> #3 0xffffffff80fa1d51 at trap_fatal+0x351 >> #4 0xffffffff80fa1f43 at trap_pfault+0x1e3 >> #5 0xffffffff80fa14ec at trap+0x26c >> #6 0xffffffff80f841c1 at calltrap+0x8 >> #7 0xffffffff806e5a80 at generic_netmap_txsync+0x330 >> #8 0xffffffff806e06f9 at netmap_ioctl+0x279 >> #9 0xffffffff8098624f at devfs_ioctl_f+0x13f >> #10 0xffffffff80b41b34 at kern_ioctl+0x2d4 >> #11 0xffffffff80b417f1 at sys_ioctl+0x171 >> #12 0xffffffff80fa26ae at amd64_syscall+0x4ce >> #13 0xffffffff80f844ab at Xfast_syscall+0xfb >> >> This is on 11.0-RELEASE-p8 >> >> Thanks, >> Joe Jones >> >> On 23/03/17 18:20, Vincenzo Maffione wrote: >> >> Hi, >> You could try to use netmap in emulated mode (sysctl >> dev.netmap.admode=2). If this works, at least you know that >> the problem is in the cxgbe netmap support and not in the >> netmap core itself. >> >> Cheers, >> Vincenzo >> >> 2017-03-23 14:00 GMT+01:00 Joe Jones >> > >> > >> >>: >> >> Hello, >> >> We have a T520-SO and have made a new install of 11.0, to >> begin >> with the box would panic every time we tried to switch the >> card >> into netmap mode. So we recompiled the kernel with netmap >> removed, >> then compiled the netmap kernel module from github, as >> this in our >> experience generally leads to a more stable netmap. >> >> we have >> >> uname -a >> FreeBSD goose2 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 #0: >> Wed Mar >> 22 16:52:35 UTC 2017 joe@goose2:/usr/obj/usr/src/sys/GENERIC >> amd64 >> >> and the following in /boot/loader.conf >> >> t4fw_cfg_load="YES" >> t5fw_cfg_load="YES" >> if_cxgbe_load="YES" >> hw.cxgbe.fl_pktshift=0 >> hw.cxgbe.toecaps_allowed=0 >> hw.cxgbe.nnmtxq10g=8 >> hw.cxgbe.nnmrxq10g=8 >> hw.cxgbe.num_vis=2 >> >> Before I run our application I run >> >> ifconfig cxl1 promisc -vlanhwtag up >> >> Now our application can now start without panicking the >> kernel. >> Here is where it gets interesting, our application is able to >> announce it's self via ARP, I can see the ethernet switch >> learning >> which port it's on, and other hosts adding it to their ARP >> tables. >> When I try an ICMP ping it goes missing. After watching the TX >> packet graph for the connected port on the switch while >> starting >> and stopping a flood ping to the application, I'm sure the >> packets >> are getting sent to the card, however I don't see them in the >> netmap ring. If I kill our application, then use ifconfig to >> create and configure a vlan port I can confirm that the >> card is >> working and has connectivity. >> >> Here's what I think is happening. ARP requests are received >> because they are sent to the broadcast address. Our >> application >> then announces it's self. However traffic destined for the >> application is send to a MAC address which is neither the >> broadcast or the MAC programed into the hardware and is >> dropped. >> My understanding of promiscuous it that it informs the >> card that >> we want these dropped packets. It looks to me like, when >> the card >> is in netmap mode the promisc flag is being ignored. >> >> I have also tried using freebsd-update to update to p8. As >> with >> the p0 kernel we get a panic when we switch the card into >> netmap mode. >> >> We did previously have these cards working in netmap mode. >> We were >> using a pre 11 snapshot of the svn head though . >> >> Many Thanks >> >> Joe Jones >> Stream Technologies >> >> _______________________________________________ >> 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 >> >> > >" >> >> >> >> >> -- Vincenzo Maffione >> >> >> >> >> >> -- >> Vincenzo Maffione >> > > -- Vincenzo Maffione From owner-freebsd-net@freebsd.org Fri Mar 24 14:34:01 2017 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 AF0AED1BDB6 for ; Fri, 24 Mar 2017 14:34:01 +0000 (UTC) (envelope-from elizabeth.walker@onlinedatatech.biz) Received: from mail-io0-x248.google.com (mail-io0-x248.google.com [IPv6:2607:f8b0:4001:c06::248]) (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 7EECBB90 for ; Fri, 24 Mar 2017 14:34:01 +0000 (UTC) (envelope-from elizabeth.walker@onlinedatatech.biz) Received: by mail-io0-x248.google.com with SMTP id f84so4209896ioj.6 for ; Fri, 24 Mar 2017 07:34:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onlinedatatech-biz.20150623.gappssmtp.com; s=20150623; h=mime-version:message-id:date:subject:from:to; bh=5WrT8ishgjllkiiXXcxU3dH0CL55yq3KD9JSdRgrh+k=; b=wMaYyKppo2btJDvW83HLVbUwGFoXXtm/lNfPGeOGd4H/AugpPUzdzeHNu7SAcK+e5S UfqLXYyH15NNPXITI3tZucfukHW+XqRBrW2khHYqWc9OJO89z0Wrmbk95tTUsGcgHSia lTEjXlN7Q0piIZp+F0q9nUvu5g4V3sTtbJlr11hOcU8xqjxt88nomkFYr5dT/BRUv6dN rOtmiq9Sb1i8eeTADixwfrMcGArWuSvNPd5pzgqcw58MkQ/6vEpdwyF2iLX4lvJwdgt/ NWVzKzQKG0wrZ7nq1Y+HmxdwVMe+KEVQMrjFyMxgbRbkLJHZl0ukPHINDlDAY/PM5ggy fhSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:message-id:date:subject:from:to; bh=5WrT8ishgjllkiiXXcxU3dH0CL55yq3KD9JSdRgrh+k=; b=Z9mFyNsOFfda/PbZTqibngVqPHAPqZyVD0CpqOcqX4PAeAx+34Se5DMuFe9+w82uWG 8UoLqYfndvj3BNzlYPQhiwAC+S63oWFUG0aTjnqBCO2iUhLCFV3sHPoUL1JNAelxRVdR 4LkS0X0bQkJOx7C9I59tX15op0gTTwx6mV+wZc9qNhROrQC+CfuxAdDK/G67yoTofKmg ZJ2/ndvNrGCmxzmVJ4zAQntmgfjoR4A5ql7nJWTpsm1GwRlpIaWiQevsCHcdLD+nZv4s wgtZHOcjwa88xp4lrWWWivoh5/NwpIhXNGWXT0YRjZbnn/8RsBk+Bayar9RVlPzPCjmD FaGg== X-Gm-Message-State: AFeK/H1uzIdqtQgTjBqEzWMR9C7khNuz4DBG64OxENVCpTlG9CMZ/XnP0TZd1dy8hx1BVGnscWqOXXQIPkPg3A== MIME-Version: 1.0 X-Received: by 10.107.169.87 with SMTP id s84mr2663854ioe.77.1490366040710; Fri, 24 Mar 2017 07:34:00 -0700 (PDT) Message-ID: <001a114277b871774f054b7ae2e5@google.com> Date: Fri, 24 Mar 2017 14:34:00 +0000 Subject: Re:Follow up: Infor Users List From: elizabeth.walker@onlinedatatech.biz To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 24 Mar 2017 14:34:01 -0000 DQoNCkhpLA0KDQpIb3BlIHlvdSBoYWQgYSBjaGFuY2UgdG8gcmV2aWV3IG15IHByZXZpb3VzIGVt YWlsLiBQbGVhc2UgbGV0IG1lIGtub3cgaWYNCnlvdSB3b3VsZCBiZSBpbnRlcmVzdGVkIGluIHJl dmlld2luZyBhIHNhbXBsZSBvZiB5b3VyIHRhcmdldCBhdWRpZW5jZS4NCg0KVGhhbmsgeW91LCBo b3BlIHRvIGhlYXIgZnJvbSB5b3UuDQoNClRoYW5rcyAmIHJlZ2FyZHMsDQpFbGl6YWJldGggV2Fs a2VyDQpNYXJrZXRpbmcgQW5hbHlzdA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoN Cg0KDQpIaSwNCg0KSSBzZWUgdGhhdCB5b3UgYXJlIGFuIEluZm9yIHBhcnRuZXIgYW5kIHRob3Vn aHQgaWYgeW91IHdvdWxkIGxpa2UgdG8NCmFjcXVpcmUgSW5mb3IgY3VzdG9tZXJzIGRhdGFiYXNl IHRvIGluY3JlYXNlIHlvdXIgY3VzdG9tZXIgYmFzZS4NCg0KKkluZm9yIFVzZXJzIOKAkyAzNyw1 ODQgSVQgZGVjaXNpb24gbWFrZXJzKg0KDQpMaXN0IENvbnRhaW5zOiBOYW1lLCBDb21wYW55J3Mg TmFtZSwgUGhvbmUgTnVtYmVyLCBGYXggTnVtYmVyLCBKb2IgVGl0bGUsDQpFbWFpbCBhZGRyZXNz LCBDb21wbGV0ZSBNYWlsaW5nIEFkZHJlc3MsIFNJQyBjb2RlLCBDb21wYW55IHJldmVudWUsIHNp emUsDQpXZWIgYWRkcmVzcyBldGMuDQoNClNwZWNpYWx0aWVzOiBidXNpbmVzcyBpbnRlbGxpZ2Vu Y2UsIGRhdGEgdmlzdWFsaXphdGlvbiwgZGF0YSBhbmFseXNpcywNCmRhc2hib2FyZHMuDQoNCkxl dCBtZSBrbm93IHlvdXIgdGhvdWdodHMgb3IgcGFzcyBvbiB0aGUgbWVzc2FnZSB0byB0aGUgcmln aHQgcGVyc29uIGluDQp5b3VyIGNvbXBhbnkuDQoNClRoYW5rcyAmIHJlZ2FyZHMsDQpFbGl6YWJl dGggV2Fsa2VyDQoNCklmIHlvdSBkb27igJl0IHdhbnQgdG8gcmVjZWl2ZSBhbnkgbWVzc2FnZSBm cm9tIHVzIHRoZW4gcGxlYXNlIHR5cGUg4oCcT1BUIE9VVOKAnQ0KaW4gdGhlIFN1YmplY3QgTGlu ZS4NCg== From owner-freebsd-net@freebsd.org Fri Mar 24 16:03:24 2017 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 84EB1D1B0A2 for ; Fri, 24 Mar 2017 16:03:24 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id 57233D81 for ; Fri, 24 Mar 2017 16:03:24 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id CDFC31089C; Fri, 24 Mar 2017 16:03:23 +0000 (UTC) Date: Fri, 24 Mar 2017 16:03:23 +0000 To: freebsd-net@freebsd.org From: "wblock (Warren Block)" Reply-to: D9270+325+bbd470fd257eef1b@reviews.freebsd.org Subject: [Differential] D9270: Add support for user-supplied Host-Uniq tag and handle PADM messages in Netgraph PPPoE Message-ID: <42b65bf02038bbb05e8e8f008d47dcf8@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: D9270: Add support for user-supplied Host-Uniq tag in Netgraph PPPoE X-Herald-Rules: <28>, <8> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: NTZkNjQzYWQxOGQ3MGJlZTIzOGZhZmQ4NGNmIFjVQ0s= MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 16:03:24 -0000 d2Jsb2NrIGFjY2VwdGVkIHRoaXMgcmV2aXNpb24uCndibG9jayBhZGRlZCBhIGNvbW1lbnQuClRo aXMgcmV2aXNpb24gaGFzIGEgcG9zaXRpdmUgcmV2aWV3LgoKCiAgT25lIHN1Z2dlc3Rpb24sIGJ1 dCBsb29rcyBnb29kIG90aGVyd2lzZS4gIFRoYW5rIHlvdSEKCklOTElORSBDT01NRU5UUwoKPiBu Z19wcHBvZS40OjExNQo+ICsuUXEgTGkgMHggLAo+ICtlZy4gCj4gKy5RcSBMaSAweDZkNzkyZDc0 NjE2NwoKV291bGQgcHJlZmVyICJsaWtlIiBvciAiZm9yIGV4YW1wbGUiIHRvIGV4ZW1wbGkgZ3Jh dGlhIGhlcmUgKHNlZSBgaWdvciAteSBuZ19wcHBvZS40YCksIGJ1dCBpZiB5b3Ugd2FudCB0byBz dGljayB3aXRoIHRoYXQsIGl0IHNob3VsZCBiZSAiZS5nLiwiLiAgWWVzLCBpdCdzIGNsdW5reS4g IEluIHRoaXMgY2FzZSwgSSBwcmVmZXIgImxpa2UiLgoKUkVQT1NJVE9SWQogIHJTIEZyZWVCU0Qg c3JjIHJlcG9zaXRvcnkKClJFVklTSU9OIERFVEFJTAogIGh0dHBzOi8vcmV2aWV3cy5mcmVlYnNk Lm9yZy9EOTI3MAoKRU1BSUwgUFJFRkVSRU5DRVMKICBodHRwczovL3Jldmlld3MuZnJlZWJzZC5v cmcvc2V0dGluZ3MvcGFuZWwvZW1haWxwcmVmZXJlbmNlcy8KClRvOiBhbGUsIGp1bGlhbiwgI21h bnBhZ2VzLCBtYXYsICNuZXR3b3JrLCBhZHJpYW4sIHdibG9jawpDYzogd2Jsb2NrLCBtYXYsIHBv b2xyb29tX2dtYWlsLmNvbSwgbWFuZHJlZSwgaW1wLCBmcmVlYnNkLW5ldC1saXN0Cg== From owner-freebsd-net@freebsd.org Fri Mar 24 16:44:14 2017 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 A4FE8D1BE2F for ; Fri, 24 Mar 2017 16:44:14 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 81B88910 for ; Fri, 24 Mar 2017 16:44:14 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: by mail-pg0-x22a.google.com with SMTP id w20so3695690pgc.0 for ; Fri, 24 Mar 2017 09:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SsIZXfQBktR+evHWmCC/0fPzGtR3VGwy0rxpC4zH7Gw=; b=uBwekLvEiKU3AoaoUmP5wXU+wbl5TlU2u1uHTHLfj0z8dFWgvi9q/gopUDih5Eagfn VXtLKgPuytuZNbVmA2giiyJBJNSTaXRUOeqHQXrDT4WK4halTcznnWcRuM3rCTK62wTk 7glaR6vhngz3XpxQcrLvVXP1c0mlxoaxDjVCO+wR0533GIhRgEfnJe9Yip7WnDitgv04 oVwyufcEos+2Xxtny8KNXZzgfE7CiPI6Ccr8TAf84ykrrd4RjxYijQBdLlBcFmFNEr35 I2G7y+JSvkLlFEPSOrEnyMohtox+JzEjfxk2jtfD2QpnTF8GEB/XziASgD2H+MFDPtaA aNPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SsIZXfQBktR+evHWmCC/0fPzGtR3VGwy0rxpC4zH7Gw=; b=g+7M7e6xHUY9WLkRtw4Eagh2h3D2m/xGf8ogJXXLLQ1CdGK6bpvKsAjCx+elAijEbW iER5dZb9X+I7vxZopPjZAZ7jvt7wJOavjdm6dmOpY4wPoIli98Q55jw4xAKcbWMgzpZV 7L0lsqP9u6d92sHOQplAn67EZ2Ci2J5UWnwp7oiNTuCXjRhvbJtUs00v4a8+PygFe7Ng rbVP5pIKaqLE6LlHn3gG99f1bmNcxwU4t4sTtkmepdzp2KWeQtXl/EpuRmNAyPSDDMST PA3va/qG1nJWre7/KbkAlttChENhwuaYTiuIgv7/THSEOjR8xl3el4AJfcaMFjCYlabz sEdg== X-Gm-Message-State: AFeK/H0XvyAFLF8yjLkj1ocV5tHDyOeL+yTeAKmeSCKLcsJKKPEx7Js3XxHMiD9UinUGVYQDdVMPxS2Rkg0PQQ== X-Received: by 10.99.250.17 with SMTP id y17mr10134902pgh.5.1490373853983; Fri, 24 Mar 2017 09:44:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.183.176 with HTTP; Fri, 24 Mar 2017 09:44:13 -0700 (PDT) In-Reply-To: <58D521C0.1000804@stream-technologies.com> References: <58D3C6F4.6010500@stream-technologies.com> <58D521C0.1000804@stream-technologies.com> From: Navdeep Parhar Date: Fri, 24 Mar 2017 09:44:13 -0700 Message-ID: Subject: Re: cxgbe netmap promiscuous mode? To: Joe Jones Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 24 Mar 2017 16:44:14 -0000 On Fri, Mar 24, 2017 at 6:40 AM, Joe Jones wrote: > Hello Navdeep, > > ... > > We were using our own MACs, we can fix the problem by using the mac from the > vcxl interface. Should we not be able to capture all traffic on the > interface regardless of what destination MAC it has. You should, but you'll need to put vcxl in promiscous mode for that. The command that you posted had cxl in promiscuous mode. As I said earlier they share the wire but operate as independent network interfaces otherwise. Regards, Navdeep From owner-freebsd-net@freebsd.org Fri Mar 24 18:29:11 2017 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 7A999D1B726 for ; Fri, 24 Mar 2017 18:29:11 +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 6A44916AA for ; Fri, 24 Mar 2017 18:29:11 +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 v2OITAQp025893 for ; Fri, 24 Mar 2017 18:29:11 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 218062] Panic (trap 12) at at ixgbe_handle_msf+0xb7 after r315333 Date: Fri, 24 Mar 2017 18:29:11 +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-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@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: 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.23 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, 24 Mar 2017 18:29:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218062 --- Comment #1 from commit-hook@freebsd.org --- A commit references this bug: Author: erj Date: Fri Mar 24 18:28:48 UTC 2017 New revision: 315916 URL: https://svnweb.freebsd.org/changeset/base/315916 Log: ixgbe(4): Re-add mutex lock call that was dropped in a previous commit. PR: 218062 Reported by: Terry Kennedy Sponsored by: Intel Corporation Changes: stable/10/sys/dev/ixgbe/if_ix.c --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Mar 24 20:01:21 2017 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 853F8D1C86F for ; Fri, 24 Mar 2017 20:01:21 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-yw0-x243.google.com (mail-yw0-x243.google.com [IPv6:2607:f8b0:4002:c05::243]) (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 42DC016F3; Fri, 24 Mar 2017 20:01:21 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: by mail-yw0-x243.google.com with SMTP id d191so61661ywe.1; Fri, 24 Mar 2017 13:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=Xx4BZeIVIuMjl+OmF+fxaFZ1qZzYuWq/1oaf+AEbvQc=; b=LJVWhKkPZTNffQ3t+3PAfiDRbTGvFcksF3tkfZ0chw4NzyVvwC0zFDVrxSF8W56fe2 r+DSBsRdSxVodjfZbTew4QIqmM/nFmNCt2EnuYgtmpIrYwGM6N3eIiYBWH4JSvZ49ooJ yLszKwB09kF74OVohckk6xnaSCMKYcg288VzDcJYOh6Kx7cbmS/JIe4HB4XAV56N1U/H 1GBXUeDyYMunwi215q7qFP8pEVWwG3fNPBL1syab7C7S5V7Pc60VLYl817sXPmzMZkWB wkgznPgAhOj6+5OzMQk6wzTUA4ztp+NY56iK9JIsoEJg41+GoKDsGaPi5u0ac+NEdAY6 vgqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Xx4BZeIVIuMjl+OmF+fxaFZ1qZzYuWq/1oaf+AEbvQc=; b=P79cSC7C1ANa30BQkmPzhOQYquaJDYFTroXR5seA8E1dabZf0/laFxnvsfVi9Ud7xA tHCTIqsTuVf4MXfz+ulII6xH1eoqnMHnNL7296yuXH5i/Ym48IaJ8Bff91F/FbLveNzo yga+Z3TGQ4Sd0B5qVUYXLt6++9l1nP6m4ErC8hy+/esOqjkCY09wMD5/tgVYWWq7Q0q0 t8szq6ROIJ6q8MU3unTcHiGiQKSE/+TkWxm2iVy13USQdLkjb7ctdw+Q9VzF82bsxIah d/92ZIGdOyQPVdfJ5qWA5udCdWaMpvU5ZXPG7JicttYmwI0gVQRtwiUzF1Ehc2DPM3wk /Ndg== X-Gm-Message-State: AFeK/H2XVwfGrlaXM0cfwASSU+n4DWGy2OVhuPYZKwHAl6k3S8TnMKiWBxDM+xNeEObrYA== X-Received: by 10.13.222.71 with SMTP id h68mr7689532ywe.173.1490385680067; Fri, 24 Mar 2017 13:01:20 -0700 (PDT) Received: from [10.192.166.0] (stargate.chelsio.com. [12.32.117.8]) by smtp.googlemail.com with ESMTPSA id l145sm1245548ywe.14.2017.03.24.13.01.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Mar 2017 13:01:19 -0700 (PDT) Sender: Navdeep Parhar Subject: Re: Committing a new 25G/40G/100G Ethernet Driver To: "Somayajulu, David" , "freebsd-net@freebsd.org" References: Cc: "'gnn@freebsd.org'" From: Navdeep Parhar Message-ID: <88d9f919-9ac3-1d51-133f-0598f4324c87@FreeBSD.org> Date: Fri, 24 Mar 2017 13:01:17 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 24 Mar 2017 20:01:21 -0000 On 03/23/2017 19:39, Somayajulu, David wrote: > Hi All, > I have a brand new Cavium 25G/40G/100G Ethernet Driver to commit to HEAD. > The patch generated using "svn diff" is about 22Mb. Per gnn's advice I have tried to submit the patch via Phabricator at https://reviews.freebsd.org/differential/diff/create/ for review. The file uploads fine but I get the following error "413 Request Entry Too Large". I would appreciate if someone can help me circumvent this problem. Also would it be o.k if I break the patch into smaller portions and submit to Phabricator ? Have you tried the command line tool? "arc diff --create" from the workspace where you ran svn diff. Regards, Navdeep From owner-freebsd-net@freebsd.org Fri Mar 24 23:07:56 2017 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 9EDBAD1BD2A for ; Fri, 24 Mar 2017 23:07:56 +0000 (UTC) (envelope-from jordancaraballo87@gmail.com) Received: from mail-yw0-x242.google.com (mail-yw0-x242.google.com [IPv6:2607:f8b0:4002:c05::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 5A4FA1594 for ; Fri, 24 Mar 2017 23:07:56 +0000 (UTC) (envelope-from jordancaraballo87@gmail.com) Received: by mail-yw0-x242.google.com with SMTP id h11so451832ywa.2 for ; Fri, 24 Mar 2017 16:07:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=PxeA5+pvsJVUmvT3Lwgf/4pu4a4kx3Be9f7JN+Gwzj0=; b=bsGJTuqb4U9Iu+4epN1OaiSb5iVXMFOBpldo3EVpPPZMVUAGGa90xA83POqy0IxRu1 uNILXVyoBt4Qh/iSbzQaQELuwDEId82ZNLa1NR6lAWd3igMq483as/1jZFAanBTh89Jj TPeG93fXVIuyfZrWpiwF71siNf2O5HBJw86NY96qV15gV8izTrLHJ1NkBKlrNM7c+jHW hPUqLSF7wW8vBGzWGB9GKPVaUUsnzmx5woK+J9vZKa6UYGkvyF7tQjC0mLzdrs9SP+hY 9YqZ1DaTLiZMUTPL1IlFgtftG82QpXA6/hizZeI9ZWFumAmNF35AZRx0fdub8eZWiQW1 bWNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=PxeA5+pvsJVUmvT3Lwgf/4pu4a4kx3Be9f7JN+Gwzj0=; b=GwegkU2QTEJFLhdtYhrbsly5ke/3p7J172R9RfhMTkk6foq+ESheZmx2UOQuGWFdWx 1sQNSw4FUkNR5zmYSGpE/feAYIMPCAwPN/9eN7DUbhIgVq/7uJ9akaJN59yZ48HhoSQy 5FsBpJ3L8n5HWdNMGjV1JvqpscKjaIzN5muWYHEJ2e2FIZzYjFjvU6bR65ANTrOi0K7a VcQY/Bwag9gQEf0N/7XXQ5wbHcIb/8yr/UsWy+hglGd7dJk6U4MOQZ9OI8PKt5TZjsnq tD+mdnLxXdDz7bLgtiLjbanTVfsBu1b0wZEMtxWGrYGNjZrvYj4lYelyW/kyXbGI5kl3 hrUA== X-Gm-Message-State: AFeK/H3HNUuojb5bYqO9PFieVmmlx78Ce2EcJanF+l2HX5yldjExdGc8ffFbZxRlLTcmjA== X-Received: by 10.129.101.7 with SMTP id z7mr712591ywb.45.1490396875126; Fri, 24 Mar 2017 16:07:55 -0700 (PDT) Received: from [10.0.0.67] (adsl-64-237-185-120.prtc.net. [64.237.185.120]) by smtp.gmail.com with ESMTPSA id n83sm1429097ywb.40.2017.03.24.16.07.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Mar 2017 16:07:54 -0700 (PDT) Subject: Re: bad throughput performance on multiple systems: Re: Fwd: Re: Disappointing packets-per-second performance results on a Dell,PE R530 To: Navdeep Parhar References: <20170312231826.GV15630@zxy.spb.ru> <74654520-b8b6-6118-2e46-902a8ea107ac@gmail.com> <173fffac-7ae2-786a-66c0-e9cd7ab78f44@gmail.com> <20170317100814.GN70430@zxy.spb.ru> <9924b2d5-4a72-579c-96c6-4dbdacc07c95@gmail.com> <9694e9f2-daec-924d-e9f6-7b22a634acb5@gmail.com> <20170318052837.GA21730@ox> Cc: slw@zxy.spb.ru, freebsd-net@freebsd.org, John Jasen From: "Caraballo-vega, Jordan A. (GSFC-6062)[COMPUTER SCIENCE CORP]" Message-ID: Date: Fri, 24 Mar 2017 19:07:51 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170318052837.GA21730@ox> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 24 Mar 2017 23:07:56 -0000 At the time of implementing the vcxl* interfaces we get very bad results. packets errs idrops bytes packets errs bytes colls drops 629k 4.5k 0 66M 629k 0 66M 0 0 701k 5.0k 0 74M 701k 0 74M 0 0 668k 4.8k 0 70M 668k 0 70M 0 0 667k 4.8k 0 70M 667k 0 70M 0 0 645k 4.5k 0 68M 645k 0 68M 0 0 686k 4.9k 0 72M 686k 0 72M 0 0 And by using just the cxl* interfaces we were getting about input (Total) output packets errs idrops bytes packets errs bytes colls drops 2.8M 0 1.2M 294M 1.6M 0 171M 0 0 2.8M 0 1.2M 294M 1.6M 0 171M 0 0 2.8M 0 1.2M 294M 1.6M 0 171M 0 0 2.8M 0 1.2M 295M 1.6M 0 172M 0 0 2.8M 0 1.2M 295M 1.6M 0 171M 0 0 These are our configurations for now. Any advice or suggestion will be appreciated. /etc/rc.conf configurations ifconfig_cxl0="up" ifconfig_cxl1="up" ifconfig_vcxl0="inet 172.16.2.1/24 -tso -lro mtu 9000" ifconfig_vcxl1="inet 172.16.1.1/24 -tso -lro mtu 9000" gateway_enable="YES" /boot/loader.conf configurations # Chelsio Modules t4fw_cfg_load="YES" t5fw_cfg_load="YES" if_cxgbe_load="YES" # rx and tx size dev.cxl.0.qsize_txq=8192 dev.cxl.0.qsize_rxq=8192 dev.cxl.1.qsize_txq=8192 dev.cxl.1.qsize_rxq=8192 # drop toecaps to increase queues dev.t5nex.0.toecaps=0 dev.t5nex.0.rdmacaps=0 dev.t5nex.0.iscsicaps=0 dev.t5nex.0.fcoecaps=0 # Controls the hardware response to congestion. -1 disables # congestion feedback and is not recommended. 0 instructs the # hardware to backpressure its pipeline on congestion. This # usually results in the port emitting PAUSE frames. 1 instructs # the hardware to drop frames destined for congested queues. From cxgbe dev.t5nex.0.cong_drop=1 # Saw these recomendations in Vicenzo email thread hw.cxgbe.num_vis=2 hw.cxgbe.fl_pktshift=0 hw.cxgbe.toecaps_allowed=0 hw.cxgbe.nnmtxq10g=8 hw.cxgbe.nnmrxq10g=8 /etc/sysctl.conf configurations # Turning off pauses dev.cxl.0.pause_settings=0 dev.cxl.1.pause_settings=0 # John Jasen suggestion - March 24, 2017 net.isr.bindthreads=0 net.isr.maxthreads=24 On 3/18/17 1:28 AM, Navdeep Parhar wrote: > On Fri, Mar 17, 2017 at 11:43:32PM -0400, John Jasen wrote: >> On 03/17/2017 03:32 PM, Navdeep Parhar wrote: >> >>> On Fri, Mar 17, 2017 at 12:21 PM, John Jasen wrote: >>>> Yes. >>>> We were hopeful, initially, to be able to achieve higher packet >>>> forwarding rates through either netmap-fwd or due to enhancements based >>>> off https://wiki.freebsd.org/ProjectsRoutingProposal >>> Have you tried netmap-fwd? I'd be interested in how that did in your tests. >> We have. On this particular box, (11-STABLE, netmap-fwd fresh from git) >> it took about 1.7m pps in, dropped 500k, and passed about 800k. >> >> I'm lead to believe that vcxl interfaces may yield better results? > Yes, those are the ones with native netmap support. Any netmap based > application should use the vcxl interfaces. If you used them on the > main cxl interfaces you were running netmap in emulated mode. > > Regards, > Navdeep From owner-freebsd-net@freebsd.org Fri Mar 24 23:19:06 2017 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 D5EFAD1C098 for ; Fri, 24 Mar 2017 23:19:06 +0000 (UTC) (envelope-from jordancaraballo87@gmail.com) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 989E01ABD for ; Fri, 24 Mar 2017 23:19:06 +0000 (UTC) (envelope-from jordancaraballo87@gmail.com) Received: by mail-yw0-x234.google.com with SMTP id p77so2746755ywg.1 for ; Fri, 24 Mar 2017 16:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=DMqf+BtNm3jZB+77yPo6hCWgfMbnBIbzG4d4Tx9kT6M=; b=EWHH2mulfMF5xXLXJfyBhxBTsWW46brB8jomAwz0UHND6c29WRQWpo4BMU3o5eOXwe MgJ13HTzrLxsmiuFIyEXGbRrmA/QChzK90M//ZBvBnR6/3lOznucEe8/iTOphYF4pt/q /W4wlScEZRUwrXpMz7FBowdU4OFmQIkWZcjmBHnMrLgj0ByWV4f7QZ+Q3Wss4IYUZnej wjgeI/S4EwNs9JJxGFBhgmpS4IYvPf3opfCMlYN2AGfNDEA5dR1d/RKeKXGck8fSs5mW fvntxEfMyBNeXzFpO/VZ/F7V6RqGkwmQJ5Dc3aGBHj11vkHLiC8B3t1RGJGXYpYESPaN 6EMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=DMqf+BtNm3jZB+77yPo6hCWgfMbnBIbzG4d4Tx9kT6M=; b=akn6XvYER38BISkVc6atcMU6jiib7JL4juKzkv/+69iOcmHrVCfe2Ip+A6nuPMXI47 iVbepc+uo0T1WpuEqlwD/pPb6TZnwR+51KFree/Ub2d7Fx66WcN0UdNmREZIvMQFP7lu ZzQ4gAyeSys7Fac7R6y5vGe/yhFgL8yHxs5qthaZDRvfQwKcHX9Laz5BiyeQQxYKXz0N uHXX7xuX3L9YZ+FKEIaAE0vAGAbrVkvGcEGY4ScIcWj6sF20NoObox27k/bzdr6osUFn bg5QmfrXFwe63gEU3PdXj2VQfdljejxrF7X4ryEP0NptzQbNvuyiIzV0kUT8uijId4lj IADg== X-Gm-Message-State: AFeK/H1WJKNkNJa4LnnE1Nrt3W0fZBxOQgNguPWD4DIlxltJWWTDTu21m68C4Zi7vP51ig== X-Received: by 10.129.31.87 with SMTP id f84mr7703114ywf.341.1490397545728; Fri, 24 Mar 2017 16:19:05 -0700 (PDT) Received: from [10.0.0.67] (adsl-64-237-185-120.prtc.net. [64.237.185.120]) by smtp.gmail.com with ESMTPSA id p68sm1440082ywf.27.2017.03.24.16.19.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Mar 2017 16:19:05 -0700 (PDT) From: "Caraballo-vega, Jordan A. (GSFC-6062)[COMPUTER SCIENCE CORP]" Subject: Error at the time of compiling netmap-fwd on -CURRENT To: freebsd-net@freebsd.org Message-ID: Date: Fri, 24 Mar 2017 19:19:03 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 24 Mar 2017 23:19:06 -0000 Hello, I am trying to compile netmap-fwd from git (https://github.com/Netgate/netmap-fwd) on a Dell PE 530 with -CURRENT updated from today (03/24/17). With the dependencies installed ( # pkg install libucl libevent2 ) I run make and get the following error followed by 8 warnings: cc -O2 -fPIC -g -Wall -Wshadow -Wcast-qual -Wwrite-strings -Wredundant-decls -Wnested-externs -Winline -I/usr/local/include -c arp.c= In file included from arp.c:51: =2E/util.h:33:5: error: conflicting types for 'dprintf' int dprintf(const char *, ...); ^ /usr/include/stdio.h:364:6: note: previous declaration is here int dprintf(int, const char * __restrict, ...) __printflike(2, 3); ^ arp.c:394:11: warning: incompatible pointer to integer conversion passing 'const char [44]' to parameter of type 'int' [-Wint-conversion] DPRINTF("%s: discarding the packet, too short (%d).\n", ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ =2E/util.h:29:54: note: expanded from macro 'DPRINTF' Any idea or feedback would be greatly appreciated. Cheers, Jordan From owner-freebsd-net@freebsd.org Fri Mar 24 23:39:13 2017 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 982B8D1C60A for ; Fri, 24 Mar 2017 23:39:13 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (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 5FE4F668 for ; Fri, 24 Mar 2017 23:39:13 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: by mail-pg0-x244.google.com with SMTP id 81so747180pgh.3 for ; Fri, 24 Mar 2017 16:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=34QnEgEBfJq/3hpM4LVRhHmp6yVAK6P/n4Q+V1qgPBs=; b=etz7e+C4pdqhIb7Qy26SA4qA8E0SLo75rtngokAqcE+LRE/wjUGW07orkGy5Cc7wBX j3KltSB5Kv+DoAdnsqatRYJuhy6rD/Z3xad/NX8fFrYg5T4prVgTT34c06pcl1xTpsGc 2Ab+PTv8kDFVcJf4TkUEy9h55e3TGrUq+8i20E+Ea8eyi3jt40vk8ET9cDe2cDoagzwW 5T9xV9+tWUc1PKvnPpmrl04xmkqqsCQ5uqf/C8sy4xLYn1wAf0rxDBGYlCNPBHQiVxdH yYyc0+KD7Pr9KOqSfjrKKCRQ8NwO3Zb6T6+b8zqutHZSEZEpyGr6pAGA1R/18dHc0/Km DS2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=34QnEgEBfJq/3hpM4LVRhHmp6yVAK6P/n4Q+V1qgPBs=; b=SZ0QvkmR1z7zelWKIxRpJsY37Sh3LLdSX9LwcKjK24I/Ejm8T0jrk8zbkpgJjsC6oW v4cvIW1zvHgxYec+1y4sZavDpXZXKy2USIvfJrPyAiIILGbhQxLwhrsT/6GrsegiHO6s uHthyTbGN0l4G+WTsgmfQAjEoYv+BXFXFkOYovcATauquXOoboXslNb5IIYemTBXU8Y0 6jSbDVX2ltkeVycNkOA5uhdpFZ88VN81t6ASjkZbZ1+eFsDUMalnxXGlwQU7yvmv5cCO nIAspOKJhgb4Izy0osDv7zLuHI3RvIe5tmuHPRiXWnAtU0fkoF2Y8QwM4OFBaPqPf/DP mLEQ== X-Gm-Message-State: AFeK/H1SUWvD51yH7ZULaxhPLkmhS5I5YkNuZfNdIUhIGkdlmc/MUgwVbS5sboB/j93b2w== X-Received: by 10.84.230.129 with SMTP id e1mr14192529plk.66.1490398752849; Fri, 24 Mar 2017 16:39:12 -0700 (PDT) Received: from [10.192.166.0] (stargate.chelsio.com. [12.32.117.8]) by smtp.googlemail.com with ESMTPSA id u26sm6645420pfi.89.2017.03.24.16.39.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Mar 2017 16:39:12 -0700 (PDT) Sender: Navdeep Parhar Subject: Re: bad throughput performance on multiple systems: Re: Fwd: Re: Disappointing packets-per-second performance results on a Dell,PE R530 To: "Caraballo-vega, Jordan A. (GSFC-6062)[COMPUTER SCIENCE CORP]" Cc: slw@zxy.spb.ru, freebsd-net@freebsd.org, John Jasen References: <20170312231826.GV15630@zxy.spb.ru> <74654520-b8b6-6118-2e46-902a8ea107ac@gmail.com> <173fffac-7ae2-786a-66c0-e9cd7ab78f44@gmail.com> <20170317100814.GN70430@zxy.spb.ru> <9924b2d5-4a72-579c-96c6-4dbdacc07c95@gmail.com> <9694e9f2-daec-924d-e9f6-7b22a634acb5@gmail.com> <20170318052837.GA21730@ox> From: Navdeep Parhar Message-ID: <0a4e3073-bf5f-9bf8-533f-bd9ec3c0f60c@FreeBSD.org> Date: Fri, 24 Mar 2017 16:39:11 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 24 Mar 2017 23:39:13 -0000 On 03/24/2017 16:07, Caraballo-vega, Jordan A. (GSFC-6062)[COMPUTER SCIENCE CORP] wrote: > At the time of implementing the vcxl* interfaces we get very bad results. You're probably not using netmap with the vcxl interfaces, and the number of "normal" tx and rx queues is just 2 for these interfaces. Even if you _are_ using netmap, the hw.cxgbe.nnmtxq10g/rxq10g tunables don't work anymore. Use these to control the number of queues for netmap: hw.cxgbe.nnmtxq_vi hw.cxgbe.nnmrxq_vi You should see a line like this in dmesg for all cxl/vcxl interfaces and that tells you exactly how many queues the driver configured: cxl0: 4 txq, 4 rxq (NIC); 4 txq, 2 rxq (TOE) > > packets errs idrops bytes packets errs bytes colls drops > 629k 4.5k 0 66M 629k 0 66M 0 0 > 701k 5.0k 0 74M 701k 0 74M 0 0 > 668k 4.8k 0 70M 668k 0 70M 0 0 > 667k 4.8k 0 70M 667k 0 70M 0 0 > 645k 4.5k 0 68M 645k 0 68M 0 0 > 686k 4.9k 0 72M 686k 0 72M 0 0 > > And by using just the cxl* interfaces we were getting about > > input (Total) output > packets errs idrops bytes packets errs bytes colls drops > 2.8M 0 1.2M 294M 1.6M 0 171M 0 0 > 2.8M 0 1.2M 294M 1.6M 0 171M 0 0 > 2.8M 0 1.2M 294M 1.6M 0 171M 0 0 > 2.8M 0 1.2M 295M 1.6M 0 172M 0 0 > 2.8M 0 1.2M 295M 1.6M 0 171M 0 0 > > These are our configurations for now. Any advice or suggestion will be > appreciated. What I don't understand is that you have PAUSE disabled and congestion drops enabled but still the number of packets coming in (whether they are dropped eventually or not is irrelevant here) is very low in your experiments. It's almost as if the senders are backing off in the face of packet loss. Are you using TCP or UDP? Always use UDP for pps testing -- the senders need to be relentless. Regards, Navdeep > > /etc/rc.conf configurations > > ifconfig_cxl0="up" > ifconfig_cxl1="up" > ifconfig_vcxl0="inet 172.16.2.1/24 -tso -lro mtu 9000" > ifconfig_vcxl1="inet 172.16.1.1/24 -tso -lro mtu 9000" > gateway_enable="YES" > > /boot/loader.conf configurations > > # Chelsio Modules > t4fw_cfg_load="YES" > t5fw_cfg_load="YES" > if_cxgbe_load="YES" > > # rx and tx size > dev.cxl.0.qsize_txq=8192 > dev.cxl.0.qsize_rxq=8192 > dev.cxl.1.qsize_txq=8192 > dev.cxl.1.qsize_rxq=8192 > > # drop toecaps to increase queues > dev.t5nex.0.toecaps=0 > dev.t5nex.0.rdmacaps=0 > dev.t5nex.0.iscsicaps=0 > dev.t5nex.0.fcoecaps=0 > > # Controls the hardware response to congestion. -1 disables > # congestion feedback and is not recommended. 0 instructs the > # hardware to backpressure its pipeline on congestion. This > # usually results in the port emitting PAUSE frames. 1 instructs > # the hardware to drop frames destined for congested queues. From cxgbe > dev.t5nex.0.cong_drop=1 > > # Saw these recomendations in Vicenzo email thread > hw.cxgbe.num_vis=2 > hw.cxgbe.fl_pktshift=0 > hw.cxgbe.toecaps_allowed=0 > hw.cxgbe.nnmtxq10g=8 > hw.cxgbe.nnmrxq10g=8 > > /etc/sysctl.conf configurations > > # Turning off pauses > dev.cxl.0.pause_settings=0 > dev.cxl.1.pause_settings=0 > # John Jasen suggestion - March 24, 2017 > net.isr.bindthreads=0 > net.isr.maxthreads=24 > > > On 3/18/17 1:28 AM, Navdeep Parhar wrote: >> On Fri, Mar 17, 2017 at 11:43:32PM -0400, John Jasen wrote: >>> On 03/17/2017 03:32 PM, Navdeep Parhar wrote: >>> >>>> On Fri, Mar 17, 2017 at 12:21 PM, John Jasen wrote: >>>>> Yes. >>>>> We were hopeful, initially, to be able to achieve higher packet >>>>> forwarding rates through either netmap-fwd or due to enhancements based >>>>> off https://wiki.freebsd.org/ProjectsRoutingProposal >>>> Have you tried netmap-fwd? I'd be interested in how that did in your tests. >>> We have. On this particular box, (11-STABLE, netmap-fwd fresh from git) >>> it took about 1.7m pps in, dropped 500k, and passed about 800k. >>> >>> I'm lead to believe that vcxl interfaces may yield better results? >> Yes, those are the ones with native netmap support. Any netmap based >> application should use the vcxl interfaces. If you used them on the >> main cxl interfaces you were running netmap in emulated mode. >> >> Regards, >> Navdeep > From owner-freebsd-net@freebsd.org Fri Mar 24 23:53:11 2017 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 A798BD1CA96 for ; Fri, 24 Mar 2017 23:53:11 +0000 (UTC) (envelope-from jordancaraballo87@gmail.com) Received: from mail-yw0-x244.google.com (mail-yw0-x244.google.com [IPv6:2607:f8b0:4002:c05::244]) (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 5C9A2103B; Fri, 24 Mar 2017 23:53:11 +0000 (UTC) (envelope-from jordancaraballo87@gmail.com) Received: by mail-yw0-x244.google.com with SMTP id i203so517486ywc.3; Fri, 24 Mar 2017 16:53:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=iwNUDvblU3hMLYCNfabXW+Pq6/jZT4mmXUqC6yluLXg=; b=P4+Vur9DFGurYTxF3+5c8H268aMQ6uKb9VVHq+X6ubj/zB/bFlvfqEo54IhDaa19Mc 8WcN0hIEfNKLyQY/wV8Fg+uXYQYSTQTP858squeNZHigNZhman07k3bW/Zdxjz+e92vG gvVK+SG3h7rwV7J0vc40vFrrd81XKc4JqqCWT/sM5ivJy1I93IcXNUq7KHVm23/3Q9oy Gb5Qk6225CyRVFO97qZ62nuCSVdrZXIxeKnVjIMJ3oTBGjJl4r5XxSOZ3BhGCLJwSdjS jRDYKytWPyQI51xm6xW8gXTU9QexgQJfTSkV0AHvWE3gx6XjejUyw7yhPnogyqw03r44 asNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=iwNUDvblU3hMLYCNfabXW+Pq6/jZT4mmXUqC6yluLXg=; b=iSaG9WcJBXTRKnVgV3cxPG7I8mXtvCGAU0WNzv2TuWm28ECIWLImQzaZMgYLxCX53g wPBSWi6FYfVPyti2NsayMxr7EtrcLQno6t8Rvm+j1GmIakgtx0SG2+C6aanUIc9jquuB hODZ30gSaJUXqnVYgQ2gfJewHHyIJgJ0mwiUf9HIsB2zu0H5Df6ug1SW3w+Ve5D3mZWY ikRBzghnq51DNTfBGUoBqpvVRWSPfwRLxxF7SJ0lh18oQb6dNivkQFfgHYNF+h/yhQwt v06X26GuCbGP7cVhV39oR2se2ZWP9c09ZvHY4aaBUPjCiz896UcMCOeC50Q4tm1p8q9d s3Jw== X-Gm-Message-State: AFeK/H1MP9Un4BFoJVzY+LWDSE/r3rXqXy+hkaO2DVCRfStsBxyvHHUVzUwqbPQ2iI4+Yw== X-Received: by 10.129.146.211 with SMTP id j202mr8670606ywg.41.1490399590364; Fri, 24 Mar 2017 16:53:10 -0700 (PDT) Received: from [10.0.0.67] (adsl-64-237-185-120.prtc.net. [64.237.185.120]) by smtp.gmail.com with ESMTPSA id 1sm1460227ywb.72.2017.03.24.16.53.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Mar 2017 16:53:09 -0700 (PDT) Subject: Re: bad throughput performance on multiple systems: Re: Fwd: Re: Disappointing packets-per-second performance results on a Dell,PE R530 To: Navdeep Parhar References: <20170312231826.GV15630@zxy.spb.ru> <74654520-b8b6-6118-2e46-902a8ea107ac@gmail.com> <173fffac-7ae2-786a-66c0-e9cd7ab78f44@gmail.com> <20170317100814.GN70430@zxy.spb.ru> <9924b2d5-4a72-579c-96c6-4dbdacc07c95@gmail.com> <9694e9f2-daec-924d-e9f6-7b22a634acb5@gmail.com> <20170318052837.GA21730@ox> <0a4e3073-bf5f-9bf8-533f-bd9ec3c0f60c@FreeBSD.org> Cc: freebsd-net@freebsd.org, slw@zxy.spb.ru, "jjasen@gmail.com >> John Jasen" From: "Caraballo-vega, Jordan A. (GSFC-6062)[COMPUTER SCIENCE CORP]" Message-ID: Date: Fri, 24 Mar 2017 19:53:07 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <0a4e3073-bf5f-9bf8-533f-bd9ec3c0f60c@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 24 Mar 2017 23:53:11 -0000 It looks like netmap is there; however, is there a way of figuring out if netmap is being used? root@router1:~ # dmesg | grep cxl cxl0: on t5nex0 cxl0: Ethernet address: 00:07:43:2c:ac:50 cxl0: 16 txq, 8 rxq (NIC) vcxl0: on cxl0 vcxl0: netmap queues/slots: TX 2/1023, RX 2/1024 vcxl0: 1 txq, 1 rxq (NIC); 2 txq, 2 rxq (netmap) cxl1: on t5nex0 cxl1: 16 txq, 8 rxq (NIC) vcxl1: on cxl1 vcxl1: netmap queues/slots: TX 2/1023, RX 2/1024 vcxl1: 1 txq, 1 rxq (NIC); 2 txq, 2 rxq (netmap) cxl0: link state changed to UP vcxl0: link state changed to UP cxl1: link state changed to UP vcxl1: link state changed to UP And yes, we are using UDP 64 bytes tests. On 3/24/17 7:39 PM, Navdeep Parhar wrote: > On 03/24/2017 16:07, Caraballo-vega, Jordan A. (GSFC-6062)[COMPUTER > SCIENCE CORP] wrote: >> At the time of implementing the vcxl* interfaces we get very bad >> results. > > You're probably not using netmap with the vcxl interfaces, and the > number of "normal" tx and rx queues is just 2 for these interfaces. > > Even if you _are_ using netmap, the hw.cxgbe.nnmtxq10g/rxq10g tunables > don't work anymore. Use these to control the number of queues for > netmap: > hw.cxgbe.nnmtxq_vi > hw.cxgbe.nnmrxq_vi > > You should see a line like this in dmesg for all cxl/vcxl interfaces > and that tells you exactly how many queues the driver configured: > cxl0: 4 txq, 4 rxq (NIC); 4 txq, 2 rxq (TOE) > >> >> packets errs idrops bytes packets errs bytes colls drops >> 629k 4.5k 0 66M 629k 0 66M >> 0 0 >> 701k 5.0k 0 74M 701k 0 74M >> 0 0 >> 668k 4.8k 0 70M 668k 0 70M >> 0 0 >> 667k 4.8k 0 70M 667k 0 70M >> 0 0 >> 645k 4.5k 0 68M 645k 0 68M >> 0 0 >> 686k 4.9k 0 72M 686k 0 72M >> 0 0 >> >> And by using just the cxl* interfaces we were getting about >> >> input (Total) output >> packets errs idrops bytes packets errs bytes colls >> drops >> 2.8M 0 1.2M 294M 1.6M 0 171M >> 0 0 >> 2.8M 0 1.2M 294M 1.6M 0 171M >> 0 0 >> 2.8M 0 1.2M 294M 1.6M 0 171M >> 0 0 >> 2.8M 0 1.2M 295M 1.6M 0 172M >> 0 0 >> 2.8M 0 1.2M 295M 1.6M 0 171M >> 0 0 >> >> These are our configurations for now. Any advice or suggestion will be >> appreciated. > > What I don't understand is that you have PAUSE disabled and congestion > drops enabled but still the number of packets coming in (whether they > are dropped eventually or not is irrelevant here) is very low in your > experiments. It's almost as if the senders are backing off in the > face of packet loss. Are you using TCP or UDP? Always use UDP for > pps testing -- the senders need to be relentless. > > Regards, > Navdeep > >> >> /etc/rc.conf configurations >> >> ifconfig_cxl0="up" >> ifconfig_cxl1="up" >> ifconfig_vcxl0="inet 172.16.2.1/24 -tso -lro mtu 9000" >> ifconfig_vcxl1="inet 172.16.1.1/24 -tso -lro mtu 9000" >> gateway_enable="YES" >> >> /boot/loader.conf configurations >> >> # Chelsio Modules >> t4fw_cfg_load="YES" >> t5fw_cfg_load="YES" >> if_cxgbe_load="YES" >> >> # rx and tx size >> dev.cxl.0.qsize_txq=8192 >> dev.cxl.0.qsize_rxq=8192 >> dev.cxl.1.qsize_txq=8192 >> dev.cxl.1.qsize_rxq=8192 >> >> # drop toecaps to increase queues >> dev.t5nex.0.toecaps=0 >> dev.t5nex.0.rdmacaps=0 >> dev.t5nex.0.iscsicaps=0 >> dev.t5nex.0.fcoecaps=0 >> >> # Controls the hardware response to congestion. -1 disables >> # congestion feedback and is not recommended. 0 instructs the >> # hardware to backpressure its pipeline on congestion. This >> # usually results in the port emitting PAUSE frames. 1 instructs >> # the hardware to drop frames destined for congested queues. From cxgbe >> dev.t5nex.0.cong_drop=1 >> >> # Saw these recomendations in Vicenzo email thread >> hw.cxgbe.num_vis=2 >> hw.cxgbe.fl_pktshift=0 >> hw.cxgbe.toecaps_allowed=0 >> hw.cxgbe.nnmtxq10g=8 >> hw.cxgbe.nnmrxq10g=8 >> >> /etc/sysctl.conf configurations >> >> # Turning off pauses >> dev.cxl.0.pause_settings=0 >> dev.cxl.1.pause_settings=0 >> # John Jasen suggestion - March 24, 2017 >> net.isr.bindthreads=0 >> net.isr.maxthreads=24 >> >> >> On 3/18/17 1:28 AM, Navdeep Parhar wrote: >>> On Fri, Mar 17, 2017 at 11:43:32PM -0400, John Jasen wrote: >>>> On 03/17/2017 03:32 PM, Navdeep Parhar wrote: >>>> >>>>> On Fri, Mar 17, 2017 at 12:21 PM, John Jasen >>>>> wrote: >>>>>> Yes. >>>>>> We were hopeful, initially, to be able to achieve higher packet >>>>>> forwarding rates through either netmap-fwd or due to enhancements >>>>>> based >>>>>> off https://wiki.freebsd.org/ProjectsRoutingProposal >>>>> Have you tried netmap-fwd? I'd be interested in how that did in >>>>> your tests. >>>> We have. On this particular box, (11-STABLE, netmap-fwd fresh from >>>> git) >>>> it took about 1.7m pps in, dropped 500k, and passed about 800k. >>>> >>>> I'm lead to believe that vcxl interfaces may yield better results? >>> Yes, those are the ones with native netmap support. Any netmap based >>> application should use the vcxl interfaces. If you used them on the >>> main cxl interfaces you were running netmap in emulated mode. >>> >>> Regards, >>> Navdeep >> > From owner-freebsd-net@freebsd.org Sat Mar 25 00:41:25 2017 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 3E203D1BD31 for ; Sat, 25 Mar 2017 00:41: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 2D77BC92 for ; Sat, 25 Mar 2017 00:41: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 v2P0fOo3071198 for ; Sat, 25 Mar 2017 00:41:25 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 218062] Panic (trap 12) at at ixgbe_handle_msf+0xb7 after r315333 Date: Sat, 25 Mar 2017 00:41: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: 10.3-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: terry-freebsd@glaver.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 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.23 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, 25 Mar 2017 00:41:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218062 Terry Kennedy changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|New |Closed --- Comment #2 from Terry Kennedy --- (In reply to commit-hook from comment #1) I rebuilt the kernel (r315918) and the problem seems fixed. Thanks for the quick response! --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sat Mar 25 00:48:52 2017 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 5BFA5D1BE30 for ; Sat, 25 Mar 2017 00:48:52 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 023C4F94; Sat, 25 Mar 2017 00:48:52 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: by mail-qt0-x229.google.com with SMTP id x35so4261056qtc.2; Fri, 24 Mar 2017 17:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rmTKB/Ax6dUBwAzR+gcACG8YYlX5bJbTLk2fPGZXxtU=; b=m0ZtxH23VZrPwft11ujde/OjBcosSO/9kLtQ/x4I7pWCbpMPvO4UjOUy1HtZHVitpY /ASAoztnZhwNpVWl1t1NptTWC5OTINRaYXGjZH8qPisr+pwMNJ8LQYWdwybAKqjY75F6 XVFKey7BgcE1gSnDHcKvhVY4L4k1t0UMQRWnWrNuQjMvx7/aRtSARcsMmeL/3l9cie1+ JcDX8VL5kE+29o0i/OPXrDL7AeWSeut4XPxNh/Vc6JMBzCmgqUoCAiHg8JCZQgqk94o+ 3IjFRMH97NsBUbtUIkHBud4sdjceiXw9gh9lGzOnkDlv0SHi0z2ksj/d/0nEyisdo9mq cuYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rmTKB/Ax6dUBwAzR+gcACG8YYlX5bJbTLk2fPGZXxtU=; b=EiNdUyl9ilAhNMcT3jUyF8So5HCLUK0nEGV5VrXlHqMfSB1dDIJ/zvAejCR05SrNRJ offPkw73ZNpuoTlgx+bg1IjZ4uSqXkKoTqv2f2k7HGFiXYTSNtIBbPpB1AfLEZSrL2Oz UjRgbam1Tzs9mmVJbMY8Rw5jiRUcb4giDpJ8yGNUNtz0RpCJtjFN4H3GruU5tZvgkwNU ZxipaB3I0sB436Ud81F0OrWr+B1Hfy6/DQBNgeq9h4z+OozCyC4+FC1D9+1lbOaHNBXn uazj/wY0WXUutWubddkgQpGXw1Wg1RF97veOLL5AVFOMCEgtRyZjqsqt69CTWgktVK5b 5xrw== X-Gm-Message-State: AFeK/H1YONWeS17pvANMfZR3de7xFjqWEo9K9biN3YL0l1rJR1HgVLA1FillD0R7EvM+o8/gkuNWeWR+YnTH8g== X-Received: by 10.200.49.66 with SMTP id h2mr10904471qtb.252.1490402930622; Fri, 24 Mar 2017 17:48:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.179.135 with HTTP; Fri, 24 Mar 2017 17:48:50 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Date: Sat, 25 Mar 2017 03:48:50 +0300 Message-ID: Subject: Re: if_epair altq support problem To: =?UTF-8?Q?Ermal_Lu=C3=A7i?= Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 25 Mar 2017 00:48:52 -0000 Hi again, This patch works perfectly also. Thank you so much. Is it possible to commit this patch to repo? On Thu, Mar 23, 2017 at 10:57 PM, Ermal Lu=C3=A7i wrote: > > > On Thu, Mar 23, 2017 at 12:16 PM, =C3=96zkan KIRIK > wrote: > >> Ermal thank you again, >> It compiles but pf still says that "pfctl: epair0b: driver does not >> support altq" >> :/ >> > > The only way to get that error is by not applying the patch properly :) > > >> >> On Thu, Mar 23, 2017 at 9:46 PM, Ermal Lu=C3=A7i wrote= : >> >>> >>> On Thu, Mar 23, 2017 at 11:06 AM, =C3=96zkan KIRIK >>> wrote: >>> >>>> Thank you, I'm waiting for 10.3 fix :) >>>> have a nice day >>>> >>> >>> >>> This should work for 10.3++ >>> >>> diff --git a/sys/net/if_epair.c b/sys/net/if_epair.c >>> index 540f06c..d028a95 100644 >>> --- a/sys/net/if_epair.c >>> +++ b/sys/net/if_epair.c >>> @@ -829,7 +829,8 @@ epair_clone_create(struct if_clone *ifc, char *name= , >>> size_t len, caddr_t params) >>> ifp->if_start =3D epair_start; >>> ifp->if_ioctl =3D epair_ioctl; >>> ifp->if_init =3D epair_init; >>> - ifp->if_snd.ifq_maxlen =3D ifqmaxlen; >>> + IFQ_SET_MAXLEN(&ifp->if_snd, ifqmaxlen); >>> + IFQ_SET_READY(&ifp->if_snd); >>> /* Assign a hopefully unique, locally administered etheraddr. *= / >>> eaddr[0] =3D 0x02; >>> eaddr[3] =3D (ifp->if_index >> 8) & 0xff; >>> @@ -855,7 +856,8 @@ epair_clone_create(struct if_clone *ifc, char *name= , >>> size_t len, caddr_t params) >>> ifp->if_start =3D epair_start; >>> ifp->if_ioctl =3D epair_ioctl; >>> ifp->if_init =3D epair_init; >>> - ifp->if_snd.ifq_maxlen =3D ifqmaxlen; >>> + IFQ_SET_MAXLEN(&ifp->if_snd, ifqmaxlen); >>> + IFQ_SET_READY(&ifp->if_snd); >>> /* We need to play some tricks here for the second interface. *= / >>> strlcpy(name, epairname, len); >>> error =3D if_clone_create(name, len, (caddr_t)scb); >>> >>> >>> >>> On Wed, Mar 22, 2017 at 11:44 PM, Ermal Lu=C3=A7i wro= te: >>>> >>>>> >>>>> On Wed, Mar 22, 2017 at 10:50 AM, =C3=96zkan KIRIK >>>>> wrote: >>>>> >>>>>> Sorry, I mistested on 10.3RELENG. >>>>>> it works on 11 RELENG, But at 10.3RELENG it throws >>>>>> >>>>>> /usr/src/sys/modules/if_epair/../../net/if_epair.c:830:2: error: >>>>>> implicit declaration of function 'if_setstartfn' is invalid in C99 >>>>>> [-Werror,-Wimplicit-function-declaration] >>>>>> >>>>>> >>>>>> On Wed, Mar 22, 2017 at 8:18 PM, =C3=96zkan KIRIK >>>>>> wrote: >>>>>> >>>>>>> Thank You Ermal ! >>>>>>> >>>>>>> It works perfectly, can you commit this patch to 11.0 RELENG and MF= C >>>>>>> to 10.3 RELENG ? >>>>>>> >>>>>>> >>>>> Thanks, for confirming that it fixes your issues. >>>>> Yeah, on 10.3 its almost the same fix i will deal with it. >>>>> >>>>> >>>>>> Regards >>>>>>> >>>>>>> On Wed, Mar 22, 2017 at 6:59 AM, Ermal Lu=C3=A7i = wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Mar 21, 2017 at 5:26 AM, =C3=96zkan KIRIK >>>>>>> > wrote: >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> I sent this email also to freebsd-pf list. But I think that the >>>>>>>>> main >>>>>>>>> problem is belongs to sys/net/if_epair.c. >>>>>>>>> >>>>>>>>> I'm using FreeBSD 10.3-p17 amd64. epair pseudo device is listed a= s >>>>>>>>> supperted deviced at the Man page of altq(4). >>>>>>>>> From man page of altq : >>>>>>>>> >>>>>>>>> *SUPPORTED DEVICES >>>>>>>> an.cgi?query=3Daltq#end>* >>>>>>>>> >>>>>>>>> The driver modifications described in altq(9) >>>>>>>>> >>>>>>>> ropos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports> >>>>>>>>> are required to use a cer- >>>>>>>>> tain network card with *ALTQ*. They have been applied >>>>>>>>> to the following >>>>>>>>> hardware drivers: ae(4) >>>>>>>>> >>>>>>>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>>>> age(4) >>>>>>>> an.cgi?query=3Dage&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.0= -RE >>>>>>>>> LEASE+and+Ports>, >>>>>>>>> alc(4) >>>>>>>> an.cgi?query=3Dalc&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.0= -RE >>>>>>>>> LEASE+and+Ports>, >>>>>>>>> ale(4) >>>>>>>> an.cgi?query=3Dale&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.0= -RE >>>>>>>>> LEASE+and+Ports>, >>>>>>>>> an(4) >>>>>>>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>>>> ath(4) >>>>>>>> an.cgi?query=3Dath&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.0= -RE >>>>>>>>> LEASE+and+Ports>, >>>>>>>>> aue(4) >>>>>>>> an.cgi?query=3Daue&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.0= -RE >>>>>>>>> LEASE+and+Ports>, >>>>>>>>> axe(4) >>>>>>>> an.cgi?query=3Daxe&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.0= -RE >>>>>>>>> LEASE+and+Ports>, >>>>>>>>> bce(4) >>>>>>>> an.cgi?query=3Dbce&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.0= -RE >>>>>>>>> LEASE+and+Ports>, >>>>>>>>> bfe(4) >>>>>>>> an.cgi?query=3Dbfe&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.0= -RE >>>>>>>>> LEASE+and+Ports>, >>>>>>>>> bge(4) >>>>>>>> an.cgi?query=3Dbge&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.0= -RE >>>>>>>>> LEASE+and+Ports>, >>>>>>>>> bxe(4) >>>>>>>> an.cgi?query=3Dbxe&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.0= -RE >>>>>>>>> LEASE+and+Ports>, >>>>>>>>> cas(4) >>>>>>>> an.cgi?query=3Dcas&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.0= -RE >>>>>>>>> LEASE+and+Ports>, >>>>>>>>> cxgbe(4) >>>>>>>> an.cgi?query=3Dcxgbe&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11= .0- >>>>>>>>> RELEASE+and+Ports>, >>>>>>>>> dc(4) >>>>>>>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>>>> de(4) >>>>>>>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>>>> ed(4) >>>>>>>> an.cgi?query=3Ded&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.0-= REL >>>>>>>>> EASE+and+Ports>, >>>>>>>>> em(4) >>>>>>>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>>>> ep(4) >>>>>>>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>>>> epair(4) >>>>>>>> an.cgi?query=3Depair&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11= .0- >>>>>>>>> RELEASE+and+Ports>, >>>>>>>>> >>>>>>>>> .... >>>>>>>>> >>>>>>>>> But while trying to use it the system says that it's not >>>>>>>>> suppoerted. I >>>>>>>>> tried on FreeBSD 11 also. The output is below: >>>>>>>>> >>>>>>>>> pf.conf : >>>>>>>>> altq on epair0b hfsc bandwidth 1Mb queue { ftp, ssh, icmp, other = } >>>>>>>>> queue ftp bandwidth 30% priority 0 hfsc (upperlimit 99%) >>>>>>>>> queue ssh bandwidth 30% priority 2 hfsc (upperlimit 99%) >>>>>>>>> queue icmp bandwidth 10% priority 2 hfsc (upperlimit 99%) >>>>>>>>> queue other bandwidth 30% priority 1 hfsc (default upperlimit 99%= ) >>>>>>>>> >>>>>>>>> >>>>>>>>> # ifconfig epair0 create >>>>>>>>> # ifconfig epair0a up >>>>>>>>> # ifconfig epair0b up >>>>>>>>> # pfctl -f pf.conf >>>>>>>>> pfctl: epair0b: driver does not support altq >>>>>>>>> >>>>>>>>> # sysctl -a | grep ALTQ >>>>>>>>> options ALTQ_NOPCC >>>>>>>>> options ALTQ_PRIQ >>>>>>>>> options ALTQ_CDNR >>>>>>>>> options ALTQ_HFSC >>>>>>>>> options ALTQ_RIO >>>>>>>>> options ALTQ_RED >>>>>>>>> options ALTQ_CBQ >>>>>>>>> options ALTQ >>>>>>>>> >>>>>>>>> >>>>>>>>> I have a look on /usr/src/sys/net/if_epair.c, and found the ALTQ >>>>>>>>> section: >>>>>>>>> >>>>>>>>> 514 #ifdef ALTQ >>>>>>>>> 515 /* Support ALTQ via the clasic if_start() path. */ >>>>>>>>> 516 IF_LOCK(&ifp->if_snd); >>>>>>>>> 517 if (ALTQ_IS_ENABLED(&ifp->if_snd)) { >>>>>>>>> 518 ALTQ_ENQUEUE(&ifp->if_snd, m, NULL, error); >>>>>>>>> 519 if (error) >>>>>>>>> 520 ifp->if_snd.ifq_drops++; >>>>>>>>> 521 IF_UNLOCK(&ifp->if_snd); >>>>>>>>> 522 if (!error) { >>>>>>>>> 523 ifp->if_obytes +=3D len; >>>>>>>>> 524 if (mflags & (M_BCAST|M_MCAST)) >>>>>>>>> 525 ifp->if_omcasts++; >>>>>>>>> 526 >>>>>>>>> 527 if ((ifp->if_drv_flags & >>>>>>>>> IFF_DRV_OACTIVE) =3D=3D 0) >>>>>>>>> 528 epair_start_locked(ifp); >>>>>>>>> 529 else >>>>>>>>> 530 (void)epair_add_ifp_for_drai= n >>>>>>>>> ing(ifp); >>>>>>>>> 531 } >>>>>>>>> 532 return (error); >>>>>>>>> 533 } >>>>>>>>> 534 IF_UNLOCK(&ifp->if_snd); >>>>>>>>> 535 #endif >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Just apply manually this patch to make it work. >>>>>>>> >>>>>>>> diff --git a/sys/net/if_epair.c b/sys/net/if_epair.c >>>>>>>> index 540f06c..04733a5 100644 >>>>>>>> --- a/sys/net/if_epair.c >>>>>>>> +++ b/sys/net/if_epair.c >>>>>>>> @@ -827,9 +827,11 @@ epair_clone_create(struct if_clone *ifc, char >>>>>>>> *name, size_t len, caddr_t params) >>>>>>>> ifp->if_capabilities =3D IFCAP_VLAN_MTU; >>>>>>>> ifp->if_capenable =3D IFCAP_VLAN_MTU; >>>>>>>> ifp->if_start =3D epair_start; >>>>>>>> + if_setstartfn(ifp, epair_start); >>>>>>>> + if_setsendqlen(ifp, ifqmaxlen); >>>>>>>> + if_setsendqready(ifp); >>>>>>>> ifp->if_ioctl =3D epair_ioctl; >>>>>>>> ifp->if_init =3D epair_init; >>>>>>>> - ifp->if_snd.ifq_maxlen =3D ifqmaxlen; >>>>>>>> /* Assign a hopefully unique, locally administered >>>>>>>> etheraddr. */ >>>>>>>> eaddr[0] =3D 0x02; >>>>>>>> eaddr[3] =3D (ifp->if_index >> 8) & 0xff; >>>>>>>> @@ -852,10 +854,11 @@ epair_clone_create(struct if_clone *ifc, cha= r >>>>>>>> *name, size_t len, caddr_t params) >>>>>>>> ifp->if_flags =3D IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTIC= AST; >>>>>>>> ifp->if_capabilities =3D IFCAP_VLAN_MTU; >>>>>>>> ifp->if_capenable =3D IFCAP_VLAN_MTU; >>>>>>>> - ifp->if_start =3D epair_start; >>>>>>>> + if_setstartfn(ifp, epair_start); >>>>>>>> + if_setsendqlen(ifp, ifqmaxlen); >>>>>>>> + if_setsendqready(ifp); >>>>>>>> ifp->if_ioctl =3D epair_ioctl; >>>>>>>> ifp->if_init =3D epair_init; >>>>>>>> - ifp->if_snd.ifq_maxlen =3D ifqmaxlen; >>>>>>>> /* We need to play some tricks here for the second >>>>>>>> interface. */ >>>>>>>> strlcpy(name, epairname, len); >>>>>>>> error =3D if_clone_create(name, len, (caddr_t)scb); >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> I have no idea that why it says that it doesn't support altq >>>>>>>>> altough the >>>>>>>>> source code contains ALTQ section. >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> =C3=96zkan KIRIK >>>>>>>>> _______________________________________________ >>>>>>>>> freebsd-net@freebsd.org mailing list >>>>>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-net >>>>>>>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freeb >>>>>>>>> sd.org" >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Ermal >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Ermal >>>>> >>>> >>>> >>> >>> >>> -- >>> Ermal >>> >> >> > > > -- > Ermal > From owner-freebsd-net@freebsd.org Sat Mar 25 00:51:21 2017 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 BACBFD1BF59 for ; Sat, 25 Mar 2017 00:51:21 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 45686113A for ; Sat, 25 Mar 2017 00:51:21 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: by mail-wm0-x243.google.com with SMTP id x124so1004758wmf.3 for ; Fri, 24 Mar 2017 17:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Cb9YX4JrRAsq5zqJWuxoikqgJ00f4NWgx8jh4icAktY=; b=EOIlW8zl+lcyTfk1vgqbyQUhfX2aXug52GC90v8Z2B+jBJAWjQbk7RXgHgjMYH0ORJ mRltHI3jucu6ti+dcc8QUPwBqYi1F0cpkXtJXAkJV/MIlx6Yuv+ovqSZtmsA/sO90WzP aOd3h3z6HgCWop/vjFoQf6RbTfK3D9lH+DN7qvnwMY3r4lO0QLwYzGpzxHxgAgNc1YLy nahaG+WahbOCPdm6pB3iscZ+5Tz4fxeQ2Iy8A8BFqO3el6fZAQz355/lQDW+GM2xroMw y+BOkvEgnkQKuuojyjntBNppdSkMRbJmgBBJ6PpGH/IBp+qtz0K+h2ZwkQTh1ZGc6U2P uXsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Cb9YX4JrRAsq5zqJWuxoikqgJ00f4NWgx8jh4icAktY=; b=M6XNgEMKeWKnXC66UbOoIrAgepBkdGddgXjK7D4jJhmaTopFPgkOb4bWX4BCjVvaHE TMUUR9pLmDc3cBijNnnDmXw1BjQyh6du34KcFb74B3+RFB8+y13LR+3m+g76sNLiDqkI z973qAaEmMolcuvxtRclpa4faWEKmkCsdDpeU16DaU/APIFmlJFyvZU2Islr6XoXdL4k yu+9HrIpTluelRxjLnbOmmgfK51rKazwql/3LcD5ksKULiRz+2K3sHbz+Q0pk60JSb0M SDzg6n28hUJa8184t+QAi5WmO8EU4AmzbJn9v9CoFkgowQBjgkBRZ7C5Q65iN8onLzpj idxQ== X-Gm-Message-State: AFeK/H3A81umC8kB7e2rHYf+C2DhG7S0IaoAKLDu6d1pNSwlHQ2W4WBFBRqcs3cNUuM0Jw== X-Received: by 10.28.126.133 with SMTP id z127mr28272wmc.60.1490403079679; Fri, 24 Mar 2017 17:51:19 -0700 (PDT) Received: from [10.192.166.0] (stargate.chelsio.com. [12.32.117.8]) by smtp.googlemail.com with ESMTPSA id h65sm4853511wrh.32.2017.03.24.17.51.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Mar 2017 17:51:18 -0700 (PDT) Sender: Navdeep Parhar Subject: Re: bad throughput performance on multiple systems: Re: Fwd: Re: Disappointing packets-per-second performance results on a Dell,PE R530 To: "Caraballo-vega, Jordan A. (GSFC-6062)[COMPUTER SCIENCE CORP]" Cc: freebsd-net@freebsd.org, slw@zxy.spb.ru, "jjasen@gmail.com >> John Jasen" References: <20170312231826.GV15630@zxy.spb.ru> <74654520-b8b6-6118-2e46-902a8ea107ac@gmail.com> <173fffac-7ae2-786a-66c0-e9cd7ab78f44@gmail.com> <20170317100814.GN70430@zxy.spb.ru> <9924b2d5-4a72-579c-96c6-4dbdacc07c95@gmail.com> <9694e9f2-daec-924d-e9f6-7b22a634acb5@gmail.com> <20170318052837.GA21730@ox> <0a4e3073-bf5f-9bf8-533f-bd9ec3c0f60c@FreeBSD.org> From: Navdeep Parhar Message-ID: Date: Fri, 24 Mar 2017 17:51:15 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 25 Mar 2017 00:51:21 -0000 On 03/24/2017 16:53, Caraballo-vega, Jordan A. (GSFC-6062)[COMPUTER SCIENCE CORP] wrote: > It looks like netmap is there; however, is there a way of figuring out > if netmap is being used? If you're not running netmap-fwd or some other netmap application, it's not being used. You have just 1 txq/rxq and that would explain the difference between cxl and vcxl. > cxl0: 16 txq, 8 rxq (NIC) > vcxl0: 1 txq, 1 rxq (NIC); 2 txq, 2 rxq (netmap) > ... > And yes, we are using UDP 64 bytes tests. That's strange then. The "input packets" counter counts every single frame that the chip saw on the wire that matched any of its MAC addresses, including frames that the chip drops. There's no way to explain why vcxl sees ~640K pps incoming vs. 2.8M pps for cxl. That number shouldn't depend on your router configuration at all -- it's entirely dependent on the traffic generators. Are you sure you aren't getting PAUSE frames out of the chip? There's nothing else that could slow down UDP senders. # sysctl -a | grep tx_pause Regards, Navdeep > > On 3/24/17 7:39 PM, Navdeep Parhar wrote: >> On 03/24/2017 16:07, Caraballo-vega, Jordan A. (GSFC-6062)[COMPUTER >> SCIENCE CORP] wrote: >>> At the time of implementing the vcxl* interfaces we get very bad >>> results. >> >> You're probably not using netmap with the vcxl interfaces, and the >> number of "normal" tx and rx queues is just 2 for these interfaces. >> >> Even if you _are_ using netmap, the hw.cxgbe.nnmtxq10g/rxq10g tunables >> don't work anymore. Use these to control the number of queues for >> netmap: >> hw.cxgbe.nnmtxq_vi >> hw.cxgbe.nnmrxq_vi >> >> You should see a line like this in dmesg for all cxl/vcxl interfaces >> and that tells you exactly how many queues the driver configured: >> cxl0: 4 txq, 4 rxq (NIC); 4 txq, 2 rxq (TOE) >> >>> >>> packets errs idrops bytes packets errs bytes colls drops >>> 629k 4.5k 0 66M 629k 0 66M >>> 0 0 >>> 701k 5.0k 0 74M 701k 0 74M >>> 0 0 >>> 668k 4.8k 0 70M 668k 0 70M >>> 0 0 >>> 667k 4.8k 0 70M 667k 0 70M >>> 0 0 >>> 645k 4.5k 0 68M 645k 0 68M >>> 0 0 >>> 686k 4.9k 0 72M 686k 0 72M >>> 0 0 >>> >>> And by using just the cxl* interfaces we were getting about >>> >>> input (Total) output >>> packets errs idrops bytes packets errs bytes colls >>> drops >>> 2.8M 0 1.2M 294M 1.6M 0 171M >>> 0 0 >>> 2.8M 0 1.2M 294M 1.6M 0 171M >>> 0 0 >>> 2.8M 0 1.2M 294M 1.6M 0 171M >>> 0 0 >>> 2.8M 0 1.2M 295M 1.6M 0 172M >>> 0 0 >>> 2.8M 0 1.2M 295M 1.6M 0 171M >>> 0 0 >>> >>> These are our configurations for now. Any advice or suggestion will be >>> appreciated. >> >> What I don't understand is that you have PAUSE disabled and congestion >> drops enabled but still the number of packets coming in (whether they >> are dropped eventually or not is irrelevant here) is very low in your >> experiments. It's almost as if the senders are backing off in the >> face of packet loss. Are you using TCP or UDP? Always use UDP for >> pps testing -- the senders need to be relentless. >> >> Regards, >> Navdeep >> >>> >>> /etc/rc.conf configurations >>> >>> ifconfig_cxl0="up" >>> ifconfig_cxl1="up" >>> ifconfig_vcxl0="inet 172.16.2.1/24 -tso -lro mtu 9000" >>> ifconfig_vcxl1="inet 172.16.1.1/24 -tso -lro mtu 9000" >>> gateway_enable="YES" >>> >>> /boot/loader.conf configurations >>> >>> # Chelsio Modules >>> t4fw_cfg_load="YES" >>> t5fw_cfg_load="YES" >>> if_cxgbe_load="YES" >>> >>> # rx and tx size >>> dev.cxl.0.qsize_txq=8192 >>> dev.cxl.0.qsize_rxq=8192 >>> dev.cxl.1.qsize_txq=8192 >>> dev.cxl.1.qsize_rxq=8192 >>> >>> # drop toecaps to increase queues >>> dev.t5nex.0.toecaps=0 >>> dev.t5nex.0.rdmacaps=0 >>> dev.t5nex.0.iscsicaps=0 >>> dev.t5nex.0.fcoecaps=0 >>> >>> # Controls the hardware response to congestion. -1 disables >>> # congestion feedback and is not recommended. 0 instructs the >>> # hardware to backpressure its pipeline on congestion. This >>> # usually results in the port emitting PAUSE frames. 1 instructs >>> # the hardware to drop frames destined for congested queues. From cxgbe >>> dev.t5nex.0.cong_drop=1 >>> >>> # Saw these recomendations in Vicenzo email thread >>> hw.cxgbe.num_vis=2 >>> hw.cxgbe.fl_pktshift=0 >>> hw.cxgbe.toecaps_allowed=0 >>> hw.cxgbe.nnmtxq10g=8 >>> hw.cxgbe.nnmrxq10g=8 >>> >>> /etc/sysctl.conf configurations >>> >>> # Turning off pauses >>> dev.cxl.0.pause_settings=0 >>> dev.cxl.1.pause_settings=0 >>> # John Jasen suggestion - March 24, 2017 >>> net.isr.bindthreads=0 >>> net.isr.maxthreads=24 >>> >>> >>> On 3/18/17 1:28 AM, Navdeep Parhar wrote: >>>> On Fri, Mar 17, 2017 at 11:43:32PM -0400, John Jasen wrote: >>>>> On 03/17/2017 03:32 PM, Navdeep Parhar wrote: >>>>> >>>>>> On Fri, Mar 17, 2017 at 12:21 PM, John Jasen >>>>>> wrote: >>>>>>> Yes. >>>>>>> We were hopeful, initially, to be able to achieve higher packet >>>>>>> forwarding rates through either netmap-fwd or due to enhancements >>>>>>> based >>>>>>> off https://wiki.freebsd.org/ProjectsRoutingProposal >>>>>> Have you tried netmap-fwd? I'd be interested in how that did in >>>>>> your tests. >>>>> We have. On this particular box, (11-STABLE, netmap-fwd fresh from >>>>> git) >>>>> it took about 1.7m pps in, dropped 500k, and passed about 800k. >>>>> >>>>> I'm lead to believe that vcxl interfaces may yield better results? >>>> Yes, those are the ones with native netmap support. Any netmap based >>>> application should use the vcxl interfaces. If you used them on the >>>> main cxl interfaces you were running netmap in emulated mode. >>>> >>>> Regards, >>>> Navdeep >>> >> > From owner-freebsd-net@freebsd.org Sat Mar 25 01:16:21 2017 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 854F9D1BCA4 for ; Sat, 25 Mar 2017 01:16:21 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46BD3767 for ; Sat, 25 Mar 2017 01:16:21 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: by mail-it0-x22e.google.com with SMTP id w124so25299217itb.1 for ; Fri, 24 Mar 2017 18:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=PdG3eNwz1rpGClmp0vQcXq5dRugazymcvWnv4ViEj0M=; b=qwB1+FU29xitgjD/ItNbeWCOjw/FCkOulURn8aUDdgVtInmtZunxhaSVUAvhBYXIAW x20Lte/JNFmLJCXpBnQBk0kQXLF6mrpNmWCZ0inw/WyhgauE18RC6cC5ntI1y6r/KK+1 C0yZJMEEkS4O9ts4QBeXBEBBmwuDcVTTfezIOiD3MYH2zIhgFS2qOcpwKRj2qkvXUwO4 bIgkG1uyCas/Ht4PzerOrwl4Thebr9MSqACBlzLSQUhyVlDVEghD2lx2soxOGvNtXNUm p1RFzTi2LSe8bbQEkAcvtCs+9+bbKaRZOoxhmBvpw5uHh6fio2WcXgkSByHzczMHsZGo 1Qtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=PdG3eNwz1rpGClmp0vQcXq5dRugazymcvWnv4ViEj0M=; b=ZHHz8jYT+5MifEAqrjHFfmzfT8XNh0AlaVMxb+CmgdcBa8rVpY58FBKoytSFI2awKe 1o+Hbn9n3PQoxZUuF6JKkeVAwM1KFs+cvzJT1gyXnJrIpxEZFHgKpJirnWIUUPrUD61t dpb19YQ/LJFLevEA+6YX/tzfcgqwKepsaCiqsQLQNmwkeO/cSthap1YIlIaVpLGAQ2Fu 1XySYxEZ3ZbHyMyPUpxcmEVAwLMpJnMT/1Buzp3Vk1KAbIXixrDUDABsY3bU23E7dxFF rrQ9bbicG+lBWDA7+7kji2E6oAPzZZA82Zj+Dv4WD14gGYElquQcv+7NAu4SnJ/YOwMH r8Jg== X-Gm-Message-State: AFeK/H229rBa6Xu4sL/pYcIKOC3xEMF7LSWtOvReLtBxeMB5Zhb256xue94Xp5pjkss28fBberSOwqLCaX4ikQ== X-Received: by 10.107.171.67 with SMTP id u64mr10890615ioe.102.1490404580599; Fri, 24 Mar 2017 18:16:20 -0700 (PDT) MIME-Version: 1.0 Sender: ermal.luci@gmail.com Received: by 10.107.149.135 with HTTP; Fri, 24 Mar 2017 18:16:19 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Ermal_Lu=C3=A7i?= Date: Fri, 24 Mar 2017 18:16:19 -0700 X-Google-Sender-Auth: yDFrEH3pGm2gDrKqJ6XdpD3iYl8 Message-ID: Subject: Re: if_epair altq support problem To: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 25 Mar 2017 01:16:21 -0000 On Fri, Mar 24, 2017 at 5:48 PM, =C3=96zkan KIRIK w= rote: > Hi again, > This patch works perfectly also. > Thank you so much. > Is it possible to commit this patch to repo? > https://svnweb.freebsd.org/changeset/base/315877 > > On Thu, Mar 23, 2017 at 10:57 PM, Ermal Lu=C3=A7i wrote= : > >> >> >> On Thu, Mar 23, 2017 at 12:16 PM, =C3=96zkan KIRIK >> wrote: >> >>> Ermal thank you again, >>> It compiles but pf still says that "pfctl: epair0b: driver does not >>> support altq" >>> :/ >>> >> >> The only way to get that error is by not applying the patch properly :) >> >> >>> >>> On Thu, Mar 23, 2017 at 9:46 PM, Ermal Lu=C3=A7i wrot= e: >>> >>>> >>>> On Thu, Mar 23, 2017 at 11:06 AM, =C3=96zkan KIRIK >>>> wrote: >>>> >>>>> Thank you, I'm waiting for 10.3 fix :) >>>>> have a nice day >>>>> >>>> >>>> >>>> This should work for 10.3++ >>>> >>>> diff --git a/sys/net/if_epair.c b/sys/net/if_epair.c >>>> index 540f06c..d028a95 100644 >>>> --- a/sys/net/if_epair.c >>>> +++ b/sys/net/if_epair.c >>>> @@ -829,7 +829,8 @@ epair_clone_create(struct if_clone *ifc, char >>>> *name, size_t len, caddr_t params) >>>> ifp->if_start =3D epair_start; >>>> ifp->if_ioctl =3D epair_ioctl; >>>> ifp->if_init =3D epair_init; >>>> - ifp->if_snd.ifq_maxlen =3D ifqmaxlen; >>>> + IFQ_SET_MAXLEN(&ifp->if_snd, ifqmaxlen); >>>> + IFQ_SET_READY(&ifp->if_snd); >>>> /* Assign a hopefully unique, locally administered etheraddr. = */ >>>> eaddr[0] =3D 0x02; >>>> eaddr[3] =3D (ifp->if_index >> 8) & 0xff; >>>> @@ -855,7 +856,8 @@ epair_clone_create(struct if_clone *ifc, char >>>> *name, size_t len, caddr_t params) >>>> ifp->if_start =3D epair_start; >>>> ifp->if_ioctl =3D epair_ioctl; >>>> ifp->if_init =3D epair_init; >>>> - ifp->if_snd.ifq_maxlen =3D ifqmaxlen; >>>> + IFQ_SET_MAXLEN(&ifp->if_snd, ifqmaxlen); >>>> + IFQ_SET_READY(&ifp->if_snd); >>>> /* We need to play some tricks here for the second interface. = */ >>>> strlcpy(name, epairname, len); >>>> error =3D if_clone_create(name, len, (caddr_t)scb); >>>> >>>> >>>> >>>> On Wed, Mar 22, 2017 at 11:44 PM, Ermal Lu=C3=A7i wr= ote: >>>>> >>>>>> >>>>>> On Wed, Mar 22, 2017 at 10:50 AM, =C3=96zkan KIRIK >>>>>> wrote: >>>>>> >>>>>>> Sorry, I mistested on 10.3RELENG. >>>>>>> it works on 11 RELENG, But at 10.3RELENG it throws >>>>>>> >>>>>>> /usr/src/sys/modules/if_epair/../../net/if_epair.c:830:2: error: >>>>>>> implicit declaration of function 'if_setstartfn' is invalid in C99 >>>>>>> [-Werror,-Wimplicit-function-declaration] >>>>>>> >>>>>>> >>>>>>> On Wed, Mar 22, 2017 at 8:18 PM, =C3=96zkan KIRIK >>>>>>> wrote: >>>>>>> >>>>>>>> Thank You Ermal ! >>>>>>>> >>>>>>>> It works perfectly, can you commit this patch to 11.0 RELENG and >>>>>>>> MFC to 10.3 RELENG ? >>>>>>>> >>>>>>>> >>>>>> Thanks, for confirming that it fixes your issues. >>>>>> Yeah, on 10.3 its almost the same fix i will deal with it. >>>>>> >>>>>> >>>>>>> Regards >>>>>>>> >>>>>>>> On Wed, Mar 22, 2017 at 6:59 AM, Ermal Lu=C3=A7i >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Mar 21, 2017 at 5:26 AM, =C3=96zkan KIRIK < >>>>>>>>> ozkan.kirik@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> I sent this email also to freebsd-pf list. But I think that the >>>>>>>>>> main >>>>>>>>>> problem is belongs to sys/net/if_epair.c. >>>>>>>>>> >>>>>>>>>> I'm using FreeBSD 10.3-p17 amd64. epair pseudo device is listed = as >>>>>>>>>> supperted deviced at the Man page of altq(4). >>>>>>>>>> From man page of altq : >>>>>>>>>> >>>>>>>>>> *SUPPORTED DEVICES >>>>>>>>> an.cgi?query=3Daltq#end>* >>>>>>>>>> >>>>>>>>>> The driver modifications described in altq(9) >>>>>>>>>> >>>>>>>>> ropos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports> >>>>>>>>>> are required to use a cer- >>>>>>>>>> tain network card with *ALTQ*. They have been applie= d >>>>>>>>>> to the following >>>>>>>>>> hardware drivers: ae(4) >>>>>>>>>> >>>>>>>>> pos=3D0&manpath=3DFreeBSD+11.0-RELEASE+and+Ports>, >>>>>>>>>> age(4) >>>>>>>>> an.cgi?query=3Dage&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.= 0-RE >>>>>>>>>> LEASE+and+Ports>, >>>>>>>>>> alc(4) >>>>>>>>> an.cgi?query=3Dalc&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.= 0-RE >>>>>>>>>> LEASE+and+Ports>, >>>>>>>>>> ale(4) >>>>>>>>> an.cgi?query=3Dale&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.= 0-RE >>>>>>>>>> LEASE+and+Ports>, >>>>>>>>>> an(4) >>>>>>>>> an.cgi?query=3Dan&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.0= -REL >>>>>>>>>> EASE+and+Ports>, >>>>>>>>>> ath(4) >>>>>>>>> an.cgi?query=3Dath&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.= 0-RE >>>>>>>>>> LEASE+and+Ports>, >>>>>>>>>> aue(4) >>>>>>>>> an.cgi?query=3Daue&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.= 0-RE >>>>>>>>>> LEASE+and+Ports>, >>>>>>>>>> axe(4) >>>>>>>>> an.cgi?query=3Daxe&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.= 0-RE >>>>>>>>>> LEASE+and+Ports>, >>>>>>>>>> bce(4) >>>>>>>>> an.cgi?query=3Dbce&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.= 0-RE >>>>>>>>>> LEASE+and+Ports>, >>>>>>>>>> bfe(4) >>>>>>>>> an.cgi?query=3Dbfe&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.= 0-RE >>>>>>>>>> LEASE+and+Ports>, >>>>>>>>>> bge(4) >>>>>>>>> an.cgi?query=3Dbge&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.= 0-RE >>>>>>>>>> LEASE+and+Ports>, >>>>>>>>>> bxe(4) >>>>>>>>> an.cgi?query=3Dbxe&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.= 0-RE >>>>>>>>>> LEASE+and+Ports>, >>>>>>>>>> cas(4) >>>>>>>>> an.cgi?query=3Dcas&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.= 0-RE >>>>>>>>>> LEASE+and+Ports>, >>>>>>>>>> cxgbe(4) >>>>>>>>> an.cgi?query=3Dcxgbe&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+1= 1.0- >>>>>>>>>> RELEASE+and+Ports>, >>>>>>>>>> dc(4) >>>>>>>>> an.cgi?query=3Ddc&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.0= -REL >>>>>>>>>> EASE+and+Ports>, >>>>>>>>>> de(4) >>>>>>>>> an.cgi?query=3Dde&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.0= -REL >>>>>>>>>> EASE+and+Ports>, >>>>>>>>>> ed(4) >>>>>>>>> an.cgi?query=3Ded&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.0= -REL >>>>>>>>>> EASE+and+Ports>, >>>>>>>>>> em(4) >>>>>>>>> an.cgi?query=3Dem&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.0= -REL >>>>>>>>>> EASE+and+Ports>, >>>>>>>>>> ep(4) >>>>>>>>> an.cgi?query=3Dep&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+11.0= -REL >>>>>>>>>> EASE+and+Ports>, >>>>>>>>>> epair(4) >>>>>>>>> an.cgi?query=3Depair&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+1= 1.0- >>>>>>>>>> RELEASE+and+Ports>, >>>>>>>>>> >>>>>>>>>> .... >>>>>>>>>> >>>>>>>>>> But while trying to use it the system says that it's not >>>>>>>>>> suppoerted. I >>>>>>>>>> tried on FreeBSD 11 also. The output is below: >>>>>>>>>> >>>>>>>>>> pf.conf : >>>>>>>>>> altq on epair0b hfsc bandwidth 1Mb queue { ftp, ssh, icmp, other= } >>>>>>>>>> queue ftp bandwidth 30% priority 0 hfsc (upperlimit 99%) >>>>>>>>>> queue ssh bandwidth 30% priority 2 hfsc (upperlimit 99%) >>>>>>>>>> queue icmp bandwidth 10% priority 2 hfsc (upperlimit 99%) >>>>>>>>>> queue other bandwidth 30% priority 1 hfsc (default upperlimit 99= %) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> # ifconfig epair0 create >>>>>>>>>> # ifconfig epair0a up >>>>>>>>>> # ifconfig epair0b up >>>>>>>>>> # pfctl -f pf.conf >>>>>>>>>> pfctl: epair0b: driver does not support altq >>>>>>>>>> >>>>>>>>>> # sysctl -a | grep ALTQ >>>>>>>>>> options ALTQ_NOPCC >>>>>>>>>> options ALTQ_PRIQ >>>>>>>>>> options ALTQ_CDNR >>>>>>>>>> options ALTQ_HFSC >>>>>>>>>> options ALTQ_RIO >>>>>>>>>> options ALTQ_RED >>>>>>>>>> options ALTQ_CBQ >>>>>>>>>> options ALTQ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I have a look on /usr/src/sys/net/if_epair.c, and found the ALTQ >>>>>>>>>> section: >>>>>>>>>> >>>>>>>>>> 514 #ifdef ALTQ >>>>>>>>>> 515 /* Support ALTQ via the clasic if_start() path. */ >>>>>>>>>> 516 IF_LOCK(&ifp->if_snd); >>>>>>>>>> 517 if (ALTQ_IS_ENABLED(&ifp->if_snd)) { >>>>>>>>>> 518 ALTQ_ENQUEUE(&ifp->if_snd, m, NULL, error); >>>>>>>>>> 519 if (error) >>>>>>>>>> 520 ifp->if_snd.ifq_drops++; >>>>>>>>>> 521 IF_UNLOCK(&ifp->if_snd); >>>>>>>>>> 522 if (!error) { >>>>>>>>>> 523 ifp->if_obytes +=3D len; >>>>>>>>>> 524 if (mflags & (M_BCAST|M_MCAST)) >>>>>>>>>> 525 ifp->if_omcasts++; >>>>>>>>>> 526 >>>>>>>>>> 527 if ((ifp->if_drv_flags & >>>>>>>>>> IFF_DRV_OACTIVE) =3D=3D 0) >>>>>>>>>> 528 epair_start_locked(ifp); >>>>>>>>>> 529 else >>>>>>>>>> 530 (void)epair_add_ifp_for_dra= in >>>>>>>>>> ing(ifp); >>>>>>>>>> 531 } >>>>>>>>>> 532 return (error); >>>>>>>>>> 533 } >>>>>>>>>> 534 IF_UNLOCK(&ifp->if_snd); >>>>>>>>>> 535 #endif >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> Just apply manually this patch to make it work. >>>>>>>>> >>>>>>>>> diff --git a/sys/net/if_epair.c b/sys/net/if_epair.c >>>>>>>>> index 540f06c..04733a5 100644 >>>>>>>>> --- a/sys/net/if_epair.c >>>>>>>>> +++ b/sys/net/if_epair.c >>>>>>>>> @@ -827,9 +827,11 @@ epair_clone_create(struct if_clone *ifc, cha= r >>>>>>>>> *name, size_t len, caddr_t params) >>>>>>>>> ifp->if_capabilities =3D IFCAP_VLAN_MTU; >>>>>>>>> ifp->if_capenable =3D IFCAP_VLAN_MTU; >>>>>>>>> ifp->if_start =3D epair_start; >>>>>>>>> + if_setstartfn(ifp, epair_start); >>>>>>>>> + if_setsendqlen(ifp, ifqmaxlen); >>>>>>>>> + if_setsendqready(ifp); >>>>>>>>> ifp->if_ioctl =3D epair_ioctl; >>>>>>>>> ifp->if_init =3D epair_init; >>>>>>>>> - ifp->if_snd.ifq_maxlen =3D ifqmaxlen; >>>>>>>>> /* Assign a hopefully unique, locally administered >>>>>>>>> etheraddr. */ >>>>>>>>> eaddr[0] =3D 0x02; >>>>>>>>> eaddr[3] =3D (ifp->if_index >> 8) & 0xff; >>>>>>>>> @@ -852,10 +854,11 @@ epair_clone_create(struct if_clone *ifc, >>>>>>>>> char *name, size_t len, caddr_t params) >>>>>>>>> ifp->if_flags =3D IFF_BROADCAST | IFF_SIMPLEX | >>>>>>>>> IFF_MULTICAST; >>>>>>>>> ifp->if_capabilities =3D IFCAP_VLAN_MTU; >>>>>>>>> ifp->if_capenable =3D IFCAP_VLAN_MTU; >>>>>>>>> - ifp->if_start =3D epair_start; >>>>>>>>> + if_setstartfn(ifp, epair_start); >>>>>>>>> + if_setsendqlen(ifp, ifqmaxlen); >>>>>>>>> + if_setsendqready(ifp); >>>>>>>>> ifp->if_ioctl =3D epair_ioctl; >>>>>>>>> ifp->if_init =3D epair_init; >>>>>>>>> - ifp->if_snd.ifq_maxlen =3D ifqmaxlen; >>>>>>>>> /* We need to play some tricks here for the second >>>>>>>>> interface. */ >>>>>>>>> strlcpy(name, epairname, len); >>>>>>>>> error =3D if_clone_create(name, len, (caddr_t)scb); >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> I have no idea that why it says that it doesn't support altq >>>>>>>>>> altough the >>>>>>>>>> source code contains ALTQ section. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> =C3=96zkan KIRIK >>>>>>>>>> _______________________________________________ >>>>>>>>>> freebsd-net@freebsd.org mailing list >>>>>>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-net >>>>>>>>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freeb >>>>>>>>>> sd.org" >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Ermal >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Ermal >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Ermal >>>> >>> >>> >> >> >> -- >> Ermal >> > > --=20 Ermal From owner-freebsd-net@freebsd.org Sat Mar 25 01:15:13 2017 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 9F72ED1BBC1 for ; Sat, 25 Mar 2017 01:15:13 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail.karels.net (mail.karels.net [63.231.190.5]) by mx1.freebsd.org (Postfix) with ESMTP id 345976C7; Sat, 25 Mar 2017 01:15:12 +0000 (UTC) (envelope-from mike@karels.net) Received: from [10.0.2.11] (mjk-mac2.karels.net [10.0.2.11]) by mail.karels.net (8.15.2/8.15.2) with ESMTP id v2P1F4SL089930; Fri, 24 Mar 2017 20:15:05 -0500 (CDT) (envelope-from mike@karels.net) From: "Mike Karels" To: "Andrey V. Elsukov" Cc: "Alexander V. Chernikov" , freebsd-net@FreeBSD.org, "George Neville-Neil" , "Olivier =?utf-8?q?Cochard-Labb=C3=A9?=" , "Eugene Grosbein" , karels@FreeBSD.org Subject: Re: LLE reference leak in the L2 cache Date: Fri, 24 Mar 2017 20:14:57 -0500 Message-ID: In-Reply-To: <18768a71-3169-469a-f3c3-b9c9e544ff6b@yandex.ru> References: <201703140840.v2E8ecH2040827@mail.karels.net> <3a4c5d87-d42e-5615-5d2b-2a8801376600@yandex.ru> <70D2287B-664C-48E4-9E8B-68B574BE6CE6@karels.net> <18768a71-3169-469a-f3c3-b9c9e544ff6b@yandex.ru> MIME-Version: 1.0 X-Mailer: MailMate (1.9.6r5347) Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 25 Mar 2017 01:15:13 -0000 On 23 Mar 2017, at 9:02, Andrey V. Elsukov wrote: > On 20.03.2017 03:46, Mike Karels wrote: >> The context has gotten messy here, so I=E2=80=99m going to break down = and=20 >> top-post. >> >> I started review https://reviews.freebsd.org/D10059 with a fix for=20 >> the >> reference-count leak. >> It changes the semantics so only routes within an in_pcb=20 >> automatically >> do L2 caching. >> >> I=E2=80=99ll put the tcp_output change for V6 in a separate review whe= n=20 >> this one >> is done. >> >> Andrey, could you try your iperf test again? Thanks, > > Hi Mike, > > The test with IPv6 works without reference leak now, as supposed, > because it doesn't use LLE cache :) > For IPv4 forwarding the problem seems also fixed, but I did only basic > test. > > --=20 > WBR, Andrey V. Elsukov Thanks, Andrey! Mike From owner-freebsd-net@freebsd.org Sat Mar 25 01:33:42 2017 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 73639D1CA5D for ; Sat, 25 Mar 2017 01:33:42 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::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 0C7651840 for ; Sat, 25 Mar 2017 01:33:42 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by mail-wr0-x231.google.com with SMTP id y90so3376127wrb.0 for ; Fri, 24 Mar 2017 18:33:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=IpV+kBmPWVH6NAMXcRtXqA49GiM84NP25YhiFx54kTc=; b=uuoNG7sC01vkzR1Se3m+8b5nOae0xmJ3Vc50rruqeSSCvl7pMIW0zHHoyVGBaEXWat upaAPpev+PyymX6UkdJSRJU7WZbrnRTUpxZ/QYYKc89aBzy4W9cgiV4TYAI0XolM+5pA e9pyZ7wVkqAL0YbNF+r/y03Yt5gbOkTfff+5NWjAj6UjiWDi7YGPi5yS+l1jZ3Q+V4QW EOxpC2736T6v+X6bIrfZHpztajwSQL5FMPCVnkIewesvFvQVMfIDccrk7604rfGm2KeN NCRdA+M17gkouckUPiQnGu/MATFmHqP8z1xTAuIGuBdCsan8GQB/RmuWg75r9K7Lg1tn 5vmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=IpV+kBmPWVH6NAMXcRtXqA49GiM84NP25YhiFx54kTc=; b=pSynEtrM/xWedNUZ4amiB5u8mgCQ50orbLLppiedTzmLonJgnwqiHh1JAxF2Kkl7yY qzEiPppglH0we6f6d3FuF8K1cQM9gMARLrNcDNFSqG1A3jHD5c6MxbTI5xtCLMVSnRtW QGvxPHt2jIhdfcp/IrtOYR3jsY+GIiZ04mVUTfv4H4azDTPlyC25HPfM633q5Qp3f1mD XfIcYkRukeJkv1aou2SzKf3K8uww8MvKvxCg8VUyZxXf1BUCTi55R5dXQ1/EhHZHf8NB KpLvl6WXAWGdxCamL7o4oq7WkNRW9bwkA1QFYPtYK/jCwh5i9uNiZ/C+tlreLMOS+ye5 u7Sw== X-Gm-Message-State: AFeK/H3CQFj2fS1NphFwPzAD2UfGZf1Svq5UugGWNm/3otENgRZVRM6VmjtH7A1duX06GQdC/ELKYYhJrul4bg== X-Received: by 10.223.164.16 with SMTP id d16mr9951779wra.47.1490405619537; Fri, 24 Mar 2017 18:33:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.178.97 with HTTP; Fri, 24 Mar 2017 18:33:39 -0700 (PDT) From: Ben Woods Date: Sat, 25 Mar 2017 09:33:39 +0800 Message-ID: Subject: interface down, console output: igb3: TX(7) desc avail = 41, pidx = 308 To: freebsd-net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 25 Mar 2017 01:33:42 -0000 Morning! Since my recent update from FreeBSD12-current r313908 to r315466, I have noticed some strange behaviour with one of my network interfaces. The interface seems to work fine for a day or so, but on a number of occasions I have found it to be down, and constantly outputting the following message to the console every few seconds: igb3: TX(7) desc avail = 41, pidx = 308 igb3: TX(7) desc avail = 41, pidx = 308 igb3: TX(7) desc avail = 41, pidx = 308 ... The problem is quickly worked around by issuing the following commands: # service netif stop igb3 # service netif start igb3 Details of this particular network interface card: $ pciconf -lv | grep igb3 -A4 igb3@pci0:0:20:1: class=0x020000 card=0x1f418086 chip=0x1f418086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Ethernet Connection I354' class = network subclass = ethernet Any ideas what this could be, or how to investigate further? Regards, Ben -- From: Benjamin Woods woodsb02@gmail.com From owner-freebsd-net@freebsd.org Sat Mar 25 13:01:26 2017 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 B91F6D1BEDE for ; Sat, 25 Mar 2017 13:01:26 +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 A8B601205 for ; Sat, 25 Mar 2017 13:01:26 +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 v2PD1Q0X011310 for ; Sat, 25 Mar 2017 13:01:26 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 218113] igb(4) panic on guest passthrough of i340 Date: Sat, 25 Mar 2017 13:01:26 +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-RELEASE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@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: keywords 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.23 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, 25 Mar 2017 13:01:26 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218113 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |IntelNetworking CC| |sbruno@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 Sat Mar 25 22:39:35 2017 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 2610BD1D779 for ; Sat, 25 Mar 2017 22:39:35 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 D7A5011E6 for ; Sat, 25 Mar 2017 22:39:34 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cruLK-0007Dt-Nz for freebsd-net@FreeBSD.org; Sun, 26 Mar 2017 01:39:30 +0300 Date: Sun, 26 Mar 2017 01:39:30 +0300 From: Slawa Olhovchenkov To: freebsd-net@FreeBSD.org Subject: TSO and packets accounting Message-ID: <20170325223930.GK86500@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 25 Mar 2017 22:39:35 -0000 How to acoount output packets w/ TSO? I mean as one large packet. What I see: # netstat -nbI lagg0 1 input lagg0 output packets errs idrops bytes packets errs bytes colls 1702715 0 0 122228560 6274492 0 9401968581 0 1623416 0 0 116306353 6035291 0 9045680036 0 1670956 0 0 119911678 6107868 0 9153586152 0 1682365 0 0 120518112 6157620 0 9228163875 0 1575295 0 0 112786199 5831604 0 8736670135 0 1596283 0 0 114404028 5910990 0 8852555094 0 1651946 0 0 118449478 6080815 0 9109251501 0 1661730 0 0 119001512 6152532 0 9219357915 0 1638212 0 0 117502802 6114157 0 9160154253 0 1644270 0 0 117823930 6116968 0 9164984649 0 9401968581/6274492 = 1498.44299442887169192342 TSO not worked? Or this is adapted acounting? cc0: flags=8843 metric 0 mtu 1500 options=ec07bb ether 00:07:43:04:b3:20 nd6 options=9 media: Ethernet 40Gbase-SR4 status: active cc1: flags=8843 metric 0 mtu 1500 options=ec07bb ether 00:07:43:04:b3:20 nd6 options=9 media: Ethernet 40Gbase-SR4 status: active lagg0: flags=8843 metric 0 mtu 1500 options=ec07bb ether 00:07:43:04:b3:20 nd6 options=9 media: Ethernet autoselect status: active groups: lagg laggproto lacp lagghash l2,l3,l4 laggport: cc0 flags=1c laggport: cc1 flags=1c From owner-freebsd-net@freebsd.org Sat Mar 25 23:32:40 2017 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 7193CD1DE7D for ; Sat, 25 Mar 2017 23:32:40 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 41958139D for ; Sat, 25 Mar 2017 23:32:40 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: by mail-pg0-x236.google.com with SMTP id t143so11821447pgb.2 for ; Sat, 25 Mar 2017 16:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=L6MFGP4wQprEU52a1zQjQL+2FbgloeDejBWDQLfiLMc=; b=a9LmqGoir9pF+50macRAEh9JO6CWod4X9GWyG1/zd6awB6A4V1BdWR9+IUaQ8/FF4S oyW4KeKG7jIk/TmhCGWzUgiPEanha/HiA1BaRTb11OA4VuKrGEnae1mdvmwFFw9kIE44 0K/02jehmANRHSAv/dVaTHl/8f7vKVd2DomJ4iDbuXViOOGVOA3asyzHgkiLlDxSnhCt 12Cm6uxH0CMh85mcNjzAfd4Q32wQkhJN5DfGHMJAH5M0mzd3udRrB/G5nm4Gd9xGE57m Vr8Ju/odcJBi1pQMOqNSTd8/hEL67kUQBqj5jDIdjIRBBW9YzFhP+1ikkMZZ4UDpmhyE DasQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=L6MFGP4wQprEU52a1zQjQL+2FbgloeDejBWDQLfiLMc=; b=nTwl3FoLmdSskXpqER3/L8h0PcMX/YIOEh6E/rWUDPA2T+QrVYLR7KB/wgqbZRr1Ig hCMnvn1n5+jkSNIazFhARn655t2zWVpkmAocXrYtGSDthvNDW3duooOsG/t5HLOrm/xQ TvuF8alQ+z3Z8mJvMp/UHC9XbT+dpQVhcTRhFrXN5bUygKpNlA+3ZmkCFxHKWUyryjt1 L+XfEBDUoyVf8WlRfRgu8zckpZTOdn3RL47RWV/NhCGqfYkb2iMUfVw3jc//jVy+tUz5 vcuVtZn/SbBBxkYolQoBOZ3akeCTegGR6d0momeJ76I+/LQbUGy8PEZjm2At4nYCZ/j5 lvSg== X-Gm-Message-State: AFeK/H1yL+Fr5zQNvBYN62rphibXehD2hQZ09PJVohGDXzOerneHBbERCKGHOpu5tuQSng== X-Received: by 10.84.222.4 with SMTP id w4mr20120384pls.159.1490484759808; Sat, 25 Mar 2017 16:32:39 -0700 (PDT) Received: from ox ([2601:641:c000:b800:f1f4:efde:3908:41b4]) by smtp.gmail.com with ESMTPSA id a21sm12222225pfc.36.2017.03.25.16.32.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Mar 2017 16:32:38 -0700 (PDT) Sender: Navdeep Parhar Date: Sat, 25 Mar 2017 16:32:33 -0700 From: Navdeep Parhar To: Slawa Olhovchenkov Cc: freebsd-net@FreeBSD.org Subject: Re: TSO and packets accounting Message-ID: <20170325233233.GA17705@ox> Mail-Followup-To: Slawa Olhovchenkov , freebsd-net@FreeBSD.org References: <20170325223930.GK86500@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170325223930.GK86500@zxy.spb.ru> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 25 Mar 2017 23:32:40 -0000 On Sun, Mar 26, 2017 at 01:39:30AM +0300, Slawa Olhovchenkov wrote: > How to acoount output packets w/ TSO? > I mean as one large packet. What I see: > > # netstat -nbI lagg0 1 > input lagg0 output > packets errs idrops bytes packets errs bytes colls > 1702715 0 0 122228560 6274492 0 9401968581 0 > 1623416 0 0 116306353 6035291 0 9045680036 0 > 1670956 0 0 119911678 6107868 0 9153586152 0 > 1682365 0 0 120518112 6157620 0 9228163875 0 > 1575295 0 0 112786199 5831604 0 8736670135 0 > 1596283 0 0 114404028 5910990 0 8852555094 0 > 1651946 0 0 118449478 6080815 0 9109251501 0 > 1661730 0 0 119001512 6152532 0 9219357915 0 > 1638212 0 0 117502802 6114157 0 9160154253 0 > 1644270 0 0 117823930 6116968 0 9164984649 0 > > 9401968581/6274492 = 1498.44299442887169192342 > > TSO not worked? > Or this is adapted acounting? The interfaces are cc(4), so this is adapter accounting. The numbers you see are coming from hardware MAC statistics that track "on-the-wire" frames. If you want to know if TSO is occurring look for the driver stats for the number of TSO work requests it has sent to the chip: # sysctl dev.cc. | grep tso_wrs Regards, Navdeep > > cc0: flags=8843 metric 0 mtu 1500 > options=ec07bb > ether 00:07:43:04:b3:20 > nd6 options=9 > media: Ethernet 40Gbase-SR4 > status: active > cc1: flags=8843 metric 0 mtu 1500 > options=ec07bb > ether 00:07:43:04:b3:20 > nd6 options=9 > media: Ethernet 40Gbase-SR4 > status: active > lagg0: flags=8843 metric 0 mtu 1500 > options=ec07bb > ether 00:07:43:04:b3:20 > nd6 options=9 > media: Ethernet autoselect > status: active > groups: lagg > laggproto lacp lagghash l2,l3,l4 > laggport: cc0 flags=1c > laggport: cc1 flags=1c > _______________________________________________ > 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 25 23:48:30 2017 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 2984ED1E2F9 for ; Sat, 25 Mar 2017 23:48:30 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 E32521C3B for ; Sat, 25 Mar 2017 23:48:29 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1crvQ2-0008AT-DF for freebsd-net@FreeBSD.org; Sun, 26 Mar 2017 02:48:26 +0300 Date: Sun, 26 Mar 2017 02:48:26 +0300 From: Slawa Olhovchenkov To: freebsd-net@FreeBSD.org Subject: Re: TSO and packets accounting Message-ID: <20170325234826.GC70430@zxy.spb.ru> References: <20170325223930.GK86500@zxy.spb.ru> <20170325233233.GA17705@ox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170325233233.GA17705@ox> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 25 Mar 2017 23:48:30 -0000 On Sat, Mar 25, 2017 at 04:32:33PM -0700, Navdeep Parhar wrote: > On Sun, Mar 26, 2017 at 01:39:30AM +0300, Slawa Olhovchenkov wrote: > > How to acoount output packets w/ TSO? > > I mean as one large packet. What I see: > > > > # netstat -nbI lagg0 1 > > input lagg0 output > > packets errs idrops bytes packets errs bytes colls > > 1702715 0 0 122228560 6274492 0 9401968581 0 > > 1623416 0 0 116306353 6035291 0 9045680036 0 > > 1670956 0 0 119911678 6107868 0 9153586152 0 > > 1682365 0 0 120518112 6157620 0 9228163875 0 > > 1575295 0 0 112786199 5831604 0 8736670135 0 > > 1596283 0 0 114404028 5910990 0 8852555094 0 > > 1651946 0 0 118449478 6080815 0 9109251501 0 > > 1661730 0 0 119001512 6152532 0 9219357915 0 > > 1638212 0 0 117502802 6114157 0 9160154253 0 > > 1644270 0 0 117823930 6116968 0 9164984649 0 > > > > 9401968581/6274492 = 1498.44299442887169192342 > > > > TSO not worked? > > Or this is adapted acounting? > > The interfaces are cc(4), so this is adapter accounting. The numbers > you see are coming from hardware MAC statistics that track "on-the-wire" > frames. > > If you want to know if TSO is occurring look for the driver stats for > the number of TSO work requests it has sent to the chip: > # sysctl dev.cc. | grep tso_wrs Thanks