From owner-freebsd-net@freebsd.org Sun Feb 7 02:38:49 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4036FAA06CB for ; Sun, 7 Feb 2016 02:38: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 316821587 for ; Sun, 7 Feb 2016 02:38: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 u172cmSF065195 for ; Sun, 7 Feb 2016 02:38:49 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 206904] tailq crash/nd inet6 Date: Sun, 07 Feb 2016 02:38: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: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ler@lerctr.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: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 02:38:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206904 --- Comment #5 from Larry Rosenman --- Created attachment 166686 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D166686&action= =3Dedit Another one --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Feb 7 14:20:33 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 928CCAA013F for ; Sun, 7 Feb 2016 14:20: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 82A4C1BB5 for ; Sun, 7 Feb 2016 14:20: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 u17EKXP8086976 for ; Sun, 7 Feb 2016 14:20:33 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194485] Userland cannot add IPv6 prefix routes Date: Sun, 07 Feb 2016 14:20:33 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: easy, feature, needs-qa, patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: venture37@geeklan.co.uk X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 14:20:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D194485 Sevan Janiyan changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |venture37@geeklan.co.uk --- Comment #1 from Sevan Janiyan --- Are there any issues with the proposed change that prevent it from being ad= ded for inclusion in FreeBSD?? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Feb 7 14:53:19 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4CF6EAA109D for ; Sun, 7 Feb 2016 14:53: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 3CC0DD83 for ; Sun, 7 Feb 2016 14:53: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 u17ErIUI058591 for ; Sun, 7 Feb 2016 14:53:19 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194485] Userland cannot add IPv6 prefix routes Date: Sun, 07 Feb 2016 14:53: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: 10.0-RELEASE X-Bugzilla-Keywords: easy, feature, needs-qa, patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: roy@marples.name X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 14:53:19 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D194485 --- Comment #2 from roy@marples.name --- It might be desirable to add a new flag to mark neighbour routes, maybe RTF_CONNECTED. It could even have the same value as the old RTF_CLONING one. I think that's the only point for discussion really, but someone from FreeB= SD needs to lead it. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Feb 7 17:08:05 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AF4D5AA12D4 for ; Sun, 7 Feb 2016 17:08:05 +0000 (UTC) (envelope-from Cheng.Cui@netapp.com) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "mx141.netapp.com", Issuer "Symantec Class 3 Secure Server CA - G4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8A7E19BC; Sun, 7 Feb 2016 17:08:05 +0000 (UTC) (envelope-from Cheng.Cui@netapp.com) X-IronPort-AV: E=Sophos;i="5.22,411,1449561600"; d="scan'208";a="92649102" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx142-out.netapp.com with ESMTP; 07 Feb 2016 09:06:19 -0800 Received: from HIOEXCMBX03-PRD.hq.netapp.com (10.122.105.36) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Sun, 7 Feb 2016 09:06:19 -0800 Received: from HIOEXCMBX03-PRD.hq.netapp.com ([::1]) by hioexcmbx03-prd.hq.netapp.com ([fe80::c11:a689:2b7e:c067%21]) with mapi id 15.00.1156.000; Sun, 7 Feb 2016 09:06:19 -0800 From: "Cui, Cheng" To: "freebsd-net@freebsd.org" CC: "andre@freebsd.org" Subject: critical typos in log of Revision 252781 Thread-Topic: critical typos in log of Revision 252781 Thread-Index: AQHRYcncOGPkRE5sbU+L4TwP2X1I+Q== Date: Sun, 7 Feb 2016 17:06:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.120.60.34] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 17:08:05 -0000 Hello, I sent this notification to Andre directly before. But I have not received any response. Hope this email again can reach someone in the email list to correct these typos. Log Message:=09 MFC r291296, r291297, r291393 <=3D=3D should be "MFC r251296, r251297, r251= 393" "Allow drivers to specify a maximum TSP length in bytes" should be "TSO length". Thanks, --Cheng Cui NetApp Scale Out Networking From owner-freebsd-net@freebsd.org Sun Feb 7 21:00:27 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EADF0AA1BE5 for ; Sun, 7 Feb 2016 21:00: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 E4EC21E5D for ; Sun, 7 Feb 2016 21:00: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 u17L01US017702 for ; Sun, 7 Feb 2016 21:00:27 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201602072100.u17L01US017702@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, 07 Feb 2016 21:00:27 +0000 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 21:00:28 -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 | 193452 | Dell PowerEdge 210 II -- Kernel panic bce (broadc In Progress | 203422 | mpd/ppoe not working with re(4) with revision 285 New | 203175 | Daily kernel crashes in tcp_twclose
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 88DF8AA145F for ; Mon, 8 Feb 2016 13:27:26 +0000 (UTC) (envelope-from free@oneex.me) Received: from mail.oneex.me (mail.oneex.me [91.193.143.132]) (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 42423DBB for ; Mon, 8 Feb 2016 13:27:25 +0000 (UTC) (envelope-from free@oneex.me) Received: from [192.168.0.110] (unknown [85.12.216.123]) by mail.oneex.me (Postfix) with ESMTPSA id 1A2D1C3F5A; Mon, 8 Feb 2016 18:27:13 +0500 (YEKT) Authentication-Results: mail.oneex.me; dmarc=fail header.from=oneex.me Authentication-Results: mail.oneex.me; spf=pass smtp.mailfrom=free@oneex.me DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oneex.me; s=mail; t=1454938033; bh=ellb7+Dd5lTQpB0h/n2RrASHuM+7TCSDJ1tuh0DQ5BM=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=XTpAZtGgXOQILwqk8Qz4w54Xv7AmUmjYvT3ZcXuVczd7SjEzBDM3vT8d4xcYBWpca sl8fbc5iUOzM5R+Ga62TME4CZyr6xkiIrf6HYw7741y8AJmGGGEZFx9RyWtOP4Dy0s 3Lh0O3VoQ8IaKhQyegrt0Oqw+cr1oB5KlZw9zm/U= Subject: Re: Problem with ipfw, in-kernel NAT and port redirection to jails To: freebsd-net@freebsd.org References: <56B5A77B.2010108@oneex.me> <66-1856806937.20160208133039@bf.pstu.ru> Cc: Kiryanov Vassily From: Alexey Roslyakov Message-ID: <56B897B1.7090007@oneex.me> Date: Mon, 8 Feb 2016 18:27:13 +0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <66-1856806937.20160208133039@bf.pstu.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 13:27:26 -0000 08.02.2016 12:30, Kiryanov Vassily пишет: > Hello Alexey, > > Thank you for this information, I have thoughts about using pf nat as > an alternative way and your example will be useful for me. > > But Eugene Grosbein adviced me to turn off tso4 on network card > underlaying my VLANs and it was enough to solve problem with port > redirection. Without turning tso4 off ipfw + in-kernel NAT works > fine but port redirection fails. > Thank you. It's my mistake - was confused by home gateway, where redirect_port worked perfectly (NIC without TSO support), and there is a notice in section BUGS of ipfw(8) about incompatible libalias and TSO. From owner-freebsd-net@freebsd.org Mon Feb 8 15:11:48 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D9BCAA1021 for ; Mon, 8 Feb 2016 15:11:48 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1C5C51CFF for ; Mon, 8 Feb 2016 15:11:47 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-229-231.lns20.per1.internode.on.net [121.45.229.231]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u18F6QYw039853 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 8 Feb 2016 07:06:33 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: Problem with ipfw, in-kernel NAT and port redirection to jails To: Alexey Roslyakov , freebsd-net@freebsd.org References: <56B5A77B.2010108@oneex.me> <66-1856806937.20160208133039@bf.pstu.ru> <56B897B1.7090007@oneex.me> Cc: Kiryanov Vassily From: Julian Elischer Message-ID: <56B8AEEC.3030904@freebsd.org> Date: Mon, 8 Feb 2016 23:06:20 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B897B1.7090007@oneex.me> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 15:11:48 -0000 On 8/02/2016 9:27 PM, Alexey Roslyakov via freebsd-net wrote: > 08.02.2016 12:30, Kiryanov Vassily пишет: >> Hello Alexey, >> >> Thank you for this information, I have thoughts about using pf nat as >> an alternative way and your example will be useful for me. >> >> But Eugene Grosbein adviced me to turn off tso4 on network card >> underlaying my VLANs and it was enough to solve problem with port >> redirection. Without turning tso4 off ipfw + in-kernel NAT works >> fine but port redirection fails. >> > > Thank you. It's my mistake - was confused by home gateway, where > redirect_port worked perfectly (NIC without TSO support), and there > is a notice in section BUGS of ipfw(8) about incompatible libalias > and TSO. so why are you using libalias? I may have misread what you are doing but IP masquerading might work better. (ipfw fwd rule with local destination) > _______________________________________________ > 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 Mon Feb 8 17:48:09 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6E83AA248B for ; Mon, 8 Feb 2016 17:48: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 96DBF1C7 for ; Mon, 8 Feb 2016 17:48: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 u18Hm9IA079639 for ; Mon, 8 Feb 2016 17:48:09 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 206933] MFC of 264915 to 10 STABLE Date: Mon, 08 Feb 2016 17:48: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-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: glebius@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: glebius@FreeBSD.org X-Bugzilla-Flags: mfc-stable10? X-Bugzilla-Changed-Fields: bug_status assigned_to 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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 17:48:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206933 Gleb Smirnoff changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Assignee|freebsd-net@FreeBSD.org |glebius@FreeBSD.org Resolution|--- |FIXED --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Feb 8 23:29:17 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1C1A1AA0CB6 for ; Mon, 8 Feb 2016 23:29:17 +0000 (UTC) (envelope-from torek@ixsystems.com) Received: from elf.torek.net (mail.torek.net [96.90.199.121]) (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 0B5B4EBC for ; Mon, 8 Feb 2016 23:29:16 +0000 (UTC) (envelope-from torek@ixsystems.com) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.9/8.14.9) with ESMTP id u18NPLd6040890 for ; Mon, 8 Feb 2016 15:25:22 -0800 (PST) (envelope-from torek@ixsystems.com) Message-Id: <201602082325.u18NPLd6040890@elf.torek.net> From: Chris Torek To: freebsd-net@freebsd.org Subject: inp_gcmoptions / imo_gc_task refers to free()d memory MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <40888.1454973921.1@elf.torek.net> Date: Mon, 08 Feb 2016 15:25:21 -0800 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.torek.net [127.0.0.1]); Mon, 08 Feb 2016 15:25:22 -0800 (PST) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 23:29:17 -0000 Looking for clues from multicast gurus :-) I turned on all the memory debug options looking for a ZFS issue, and promptly stumbled over an IP multicast bug that occurs when creating and deleting bridge and other virtual interfaces quickly. The actual crash is here (note, clang optimized out several stack frames due to tail calls), along with the relevant info: in_leavegroup_locked() at in_leavegroup_locked+0x6b/frame 0xfffffe0babd1aae0 inp_gcmoptions() at inp_gcmoptions+0x1e2/frame 0xfffffe0babd1ab20 taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame 0xfffffe0babd1ab80 taskqueue_thread_loop() at taskqueue_thread_loop+0x9b/frame 0xfffffe0bab1dabb0 fork_exit() at ... in_leavegroup_locked+0x6b: movq 0x10(%rax),%rax rax 0xdeadc0dedeadc0de That particular movq instruction is part of the CURVNET_SET(inm->inm_ifp->if_vnet) macro call. Here's gdb disassembly in the area (and gdb points to that line, netinet/in_mcast.c line 1243 or so). 0x11c7 : mov 0x18(%r14),%rax 0x11cb : mov 0x10(%rax),%rax 0x11cf : test %rax,%rax Here %r14 holds "inm", so it's the load to get if_vnet into %rax that fails, not a load of ifp->foo (CURVNET_SET expands to an assert that ifp is not NULL and that it has the right vnet magic number, which all starts with the "test %rax" instruction). The conclusion is that inm itself is a valid pointer but inm->inm_ifp is 0xdeadc0dedeadc0de => we've done a free(inm, M_IPMADDR) already. But, "struct in_multi" has a ref count. So I'm a bit at a loss as to where the reference count failed us... (I did find a thread in the middle of deleting a bridge interface, but I think at this point that this is a red herring.) BTW, this is the wrong place for this fix, but I'll attach it anyway, since turning on memory debugging found this bug too, so if you turn on memory debugging you might hang if you have a ZFS root :-) (I need to make a bit of progress with my commit bit, and just commit the fix below...) Chris commit cc2a7f115fe69a5d91e54654ba1f210b7db19df6 Author: Chris Torek Date: Sun Feb 7 13:36:34 2016 -0800 taskqueue_drain_all: reload after sleeping In taskqueue_drain_all(), after we use TQ_SLEEP to wait for pending tasks to run, we must reload the tail of the task queue, since it may be done now. The symptom of this bug was a thread hanging in TQ_SLEEP if a task lived in malloc()ed memory that was reused or (more likely) filled with 0xdeadc0de on free() due to memory checking being turned on. The latter would make the pending value become 49374 (0xc0de) and we would wait forever. diff --git a/sys/kern/subr_taskqueue.c b/sys/kern/subr_taskqueue.c index f104bb5..55a1ca1 100644 --- a/sys/kern/subr_taskqueue.c +++ b/sys/kern/subr_taskqueue.c @@ -440,10 +440,9 @@ taskqueue_drain_all(struct taskqueue *queue) WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, __func__); TQ_LOCK(queue); - task = STAILQ_LAST(&queue->tq_queue, task, ta_link); - if (task != NULL) - while (task->ta_pending != 0) - TQ_SLEEP(queue, task, &queue->tq_mutex, PWAIT, "-", 0); + while ((task = STAILQ_LAST(&queue->tq_queue, task, ta_link)) != NULL && + task->ta_pending != 0) + TQ_SLEEP(queue, task, &queue->tq_mutex, PWAIT, "-", 0); taskqueue_drain_running(queue); KASSERT(STAILQ_EMPTY(&queue->tq_queue), ("taskqueue queue is not empty after draining")); From owner-freebsd-net@freebsd.org Tue Feb 9 00:43:05 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7C300AA13A2 for ; Tue, 9 Feb 2016 00:43:05 +0000 (UTC) (envelope-from kvas@bf.pstu.ru) Received: from serv5.pstu.ru (serv5.pstu.ru [195.19.162.243]) by mx1.freebsd.org (Postfix) with ESMTP id AC3731DB8 for ; Tue, 9 Feb 2016 00:43:03 +0000 (UTC) (envelope-from kvas@bf.pstu.ru) Received: from tms01.bf.pstu.ru (host.bf.pstu.ru [195.19.182.1] (may be forged)) by serv5.pstu.ru (8.14.5/8.14.2) with ESMTP id u188UDNa007595; Mon, 8 Feb 2016 13:30:13 +0500 (GMT-5) (envelope-from kvas@bf.pstu.ru) Received: from k36a2.bf.pstu.ru (tms07.berezniki.ru [195.19.182.7]) by tms01.bf.pstu.ru (Postfix) with ESMTP id DE5E223905; Mon, 8 Feb 2016 13:25:20 +0500 (YEKT) Date: Mon, 8 Feb 2016 13:30:39 +0600 From: Kiryanov Vassily X-Mailer: The Bat! (v1.60c) Reply-To: Kiryanov Vassily Organization: BF PGTU X-Priority: 3 (Normal) Message-ID: <66-1856806937.20160208133039@bf.pstu.ru> To: freebsd-net@freebsd.org CC: Alexey Roslyakov Subject: Re[2]: Problem with ipfw, in-kernel NAT and port redirection to jails In-Reply-To: <56B5A77B.2010108@oneex.me> References: <56B5A77B.2010108@oneex.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 00:43:05 -0000 Hello Alexey, Thank you for this information, I have thoughts about using pf nat as an alternative way and your example will be useful for me. But Eugene Grosbein adviced me to turn off tso4 on network card underlaying my VLANs and it was enough to solve problem with port redirection. Without turning tso4 off ipfw + in-kernel NAT works fine but port redirection fails. Saturday, February 6, 2016, 1:57:47 PM, you wrote: ARvfn> Hello. ARvfn> I have same problem when I'm trying redirect incoming traffic into the ARvfn> jailed web server. ARvfn> I repeated my installation few times on different releases - problem ARvfn> with redirected ports was here all time (except 9.3 - there was random ARvfn> result). ARvfn> As a temporary solution am using pf nat for redirect ports. ARvfn> My test configuration: ARvfn> /etc/rc.conf: ARvfn> ifconfig_vtnet0="inet 192.168.1.18/24" ARvfn> defaultrouter="192.168.1.1" ARvfn> cloned_interfaces="lo1" ARvfn> /etc/jail.conf: ARvfn> exec.start = "/bin/sh /etc/rc"; ARvfn> exec.stop = "/bin/sh /etc/rc.shutdown"; ARvfn> exec.clean; ARvfn> j1 { ARvfn> path = /home/jail1; ARvfn> mount.devfs; ARvfn> host.hostname = j1; ARvfn> interface = "lo1"; ARvfn> ip4.addr = 10.8.0.1; ARvfn> persist; ARvfn> } ARvfn> rc.firewall: ARvfn> ipfw nat 1 config if vtnet0 redirect_port tcp 10.8.0.1:80 80 ARvfn> ipfw add 500 nat 1 ip from any to 192.168.1.18 in via vtnet0 ARvfn> ipfw add 600 nat 1 ip from 10.8.0.1 to any out via vtnet0 ARvfn> ipfw add allow ip from any to any ARvfn> pf.conf: ARvfn> ext_if = "vtnet0" ARvfn> int_if = "lo1" ARvfn> jail_net = $int_if:network ARvfn> nat on $ext_if from $jail_net to any -> ($ext_if) ARvfn> rdr pass on $ext_if inet proto tcp from any to ($ext_if:0) port 80 -> ARvfn> 10.8.0.1 port 80 ARvfn> In jail I'm try nginx, apache24 and nc as source for redirection. Test ARvfn> file was generated: dd if/dev/random of=tmp.raw bs=1M count=2 ARvfn> On 10.1 and 10.2 there is no big differences, when using ipfw nat we can ARvfn> get only part of file (I'm using curl on different machine: curl ARvfn> http://192.168.1.18/tmp.raw > /dev/null): ARvfn> with nginx: Received = 33045 ARvfn> with apache: Received = 33092 ARvfn> with nc: Received = 16384 ARvfn> and result seems to be very stable in numbers. ARvfn> On 9.3: ARvfn> nginx: random bytes received, has no successful downloads ARvfn> apache: random bytes received, sometimes download entire file ARvfn> nc: entire file received ARvfn> My virtual environment is proxmox 3. ARvfn> Maybe it's related to ARvfn> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=137346 or just not ARvfn> properly configured ipfw nat? ARvfn> _______________________________________________ ARvfn> freebsd-net@freebsd.org mailing list ARvfn> https://lists.freebsd.org/mailman/listinfo/freebsd-net ARvfn> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Best regards, Kiryanov mailto:kvas@bf.pstu.ru From owner-freebsd-net@freebsd.org Tue Feb 9 01:17:37 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9158DAA249F for ; Tue, 9 Feb 2016 01:17:37 +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 80587EB2 for ; Tue, 9 Feb 2016 01:17:37 +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 u191HaBg035605 for ; Tue, 9 Feb 2016 01:17:37 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 207034] ixv driver does not check_link or fill in adapter->link_speed field during initialization Date: Tue, 09 Feb 2016 01:17:37 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: IntelNetworking, patch X-Bugzilla-Severity: Affects Only Me 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 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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 01:17:37 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207034 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |IntelNetworking, 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 Tue Feb 9 01:17:56 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5795DAA24FA for ; Tue, 9 Feb 2016 01:17: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 46F73F9A for ; Tue, 9 Feb 2016 01:17: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 u191HuTa036081 for ; Tue, 9 Feb 2016 01:17:56 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 207031] ixv driver accesses offsets beyond the VF's PCI BAR Date: Tue, 09 Feb 2016 01:17: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: 11.0-CURRENT X-Bugzilla-Keywords: IntelNetworking, patch X-Bugzilla-Severity: Affects Only Me 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 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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 01:17:56 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207031 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |IntelNetworking, 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 Tue Feb 9 01:18:17 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6138DAA25AD for ; Tue, 9 Feb 2016 01:18:17 +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 5043910A4 for ; Tue, 9 Feb 2016 01:18:17 +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 u191IGQv036488 for ; Tue, 9 Feb 2016 01:18:17 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 207037] ixv driver uses uninitialized offset variable and writes into arbitrary pci config register Date: Tue, 09 Feb 2016 01:18:17 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: IntelNetworking, patch X-Bugzilla-Severity: Affects Only Me 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 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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 01:18:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207037 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@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 Tue Feb 9 09:59:32 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BBDA3AA3521 for ; Tue, 9 Feb 2016 09:59: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 ABF983CD for ; Tue, 9 Feb 2016 09:59: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 u199xWYu023516 for ; Tue, 9 Feb 2016 09:59:32 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 206934] MFC of commits r272695 and r288529 Date: Tue, 09 Feb 2016 09:59:32 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: mfc-stable10? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 09:59:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206934 --- Comment #3 from Andrey V. Elsukov --- (In reply to mgrooms from comment #2) > Ahh. I see the MFC now. Thanks for checking and sorry to bother you with > that. Is the new if_enc you refer to already in 10 STABLE? No. It isn't in stable. FreeBSD head/ is so far away from stable branch in changes of network stack, there are a lot of changes in ipsec code and I haven't any stable/10 machines to test these changes to be able merge them. Also we are in code freeze now in preparation to 10.3 release. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Feb 9 17:54:57 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F2F5EAA2E0D; Tue, 9 Feb 2016 17:54:57 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) (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 B2703DBF; Tue, 9 Feb 2016 17:54:57 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from amavis-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3q0Bgy5fHQz13c; Tue, 9 Feb 2016 18:54:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:organization:subject:subject:from:from :date:date:content-transfer-encoding:content-type:content-type :mime-version:received:received:received:received; s=jakla4; t= 1455040491; x=1457632492; bh=382RecCx/1Qh0yulE0Jaa2xipwiy5kAHQ24 qARe20GE=; b=TJi+3QRJxQAuOLDJvFQZ+US6qI6LjIet3+g4Fnz9iMkAMpqWktU R4J/0Zy10ghMVM/x2zPraq0iETvx4dph0jWu6gvadDStYaJl9NgzK80Sdt9TRgRh x6M+L+I8IJ+x78sV8ZQDuF0UmtYO9xBaAEVN0WB90+CFL0fP9EWfNK5w= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10026) with LMTP id tzonGcK5m8BJ; Tue, 9 Feb 2016 18:54:51 +0100 (CET) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP id 3q0Bgv4XrTz13b; Tue, 9 Feb 2016 18:54:51 +0100 (CET) Received: from nabiralnik.ijs.si (nabiralnik.ijs.si [IPv6:2001:1470:ff80::80:16]) by mildred.ijs.si (Postfix) with ESMTP id 3q0Bgv3gMbznP; Tue, 9 Feb 2016 18:54:51 +0100 (CET) Received: from neli.ijs.si (2001:1470:ff80:88:21c:c0ff:feb1:8c91) by webmail.ijs.si with HTTP (HTTP/1.1 POST); Tue, 09 Feb 2016 18:54:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 09 Feb 2016 18:54:51 +0100 From: Mark Martinec To: freebsd-hackers@freebsd.org Cc: freebsd-net@FreeBSD.org, soc-admins@FreeBSD.org Subject: Google Summer of Code 2016, unified ping/ping6, traceroute/traceroute6, ... Organization: Jozef Stefan Institute Message-ID: <3c7c36bc8d7f0bdb4e04466d3d506960@mailbox.ijs.si> X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.1.4 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 17:54:58 -0000 There is now a timeline published for Google Summer of Code 2016: https://developers.google.com/open-source/gsoc/timeline Will FreeBSD apply for this year's participation in GSoC 2016? I'm not a committer or a mentor, although last year I have submitted two ideas for GSoC projects, for which I still have great interest as a user: https://wiki.freebsd.org/SummerOfCodeIdeas#Task_name.2A:_Unified_ping_and_ping6 https://wiki.freebsd.org/SummerOfCodeIdeas#Task_name.2A:_Unified_traceroute_and_traceroute6 Last year there were two or three seemingly highly qualified and motivated candidates for these two tasks. This year I have just received a query from a new interested candidate. Unfortunately, despite posting to freebsd-hackers ML and possibly elsewhere, last year these candidates did not receive any reply (apart from mine, suggesting contacts and indicated on a Wiki page). So the problem is finding a mentor that is willing to accept the task of mentoring these two projects. I'm willing to participate with comments, review and technical suggestions, but someone (or preferably two persons) familiar with FreeBSD coding styles and practices is needed, and to fill the GSoC role of a mentor. Finding an interested qualified mentor is also probably a pre-requisite that a student's work won't be in vain and get a chance of being adopted in a FreeBSD project. I'm willing to elaborate more on my two proposed projects, as the submission form (links above) had a word count limit on a project description and on justifying a need. Is there a better mailing list that freebsd-hackers@ to cover GSoC topics? Mark From owner-freebsd-net@freebsd.org Tue Feb 9 18:29:48 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99AD6AA3E74 for ; Tue, 9 Feb 2016 18:29: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 897227C8 for ; Tue, 9 Feb 2016 18:29: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 u19ITm7W016197 for ; Tue, 9 Feb 2016 18:29:48 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 206934] MFC of commits r272695 and r288529 Date: Tue, 09 Feb 2016 18:29: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: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mgrooms@shrew.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: mfc-stable10? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 18:29:48 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206934 --- Comment #4 from mgrooms@shrew.net --- Thanks for the clarification regarding enc. I'm not trying to make more work for developers, I'm just trying to prevent other users from experiencing the same problems I have. Here is some background: While upgrading a pair of firewalls to 10, I went through a week of crashes= and scrambling to apply kernel patches from head ... https://lists.freebsd.org/pipermail/freebsd-net/2014-October/040170.html Before upgrading to 10.2-RELEASE, I went through all patches I had previous= ly applied to see if they had been MFCd. Regardless, when I upgraded I still w= ent through two days of crashes and applying kernel patches from head ... https://groups.google.com/forum/#!topic/mailing.freebsd.stable/8ZYiHDkarhU The other patch that fixed my 10.2 problem was MFCd with RE approval two da= ys ago ... https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206933 The only other patches that looked like they may not have MFCd were the two mentioned in this bugzilla ticket. After all the adventures I've had upgrad= ing 10.x firewalls, I felt I would be remiss if I didn't follow up with a reque= st. I appreciate all the work you and other developers do on FreeBSD. IMO, it's= the best alternative to proprietary firewall systems that support stateful fail-over. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Feb 9 18:30:22 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4EB9FAA3F1A for ; Tue, 9 Feb 2016 18:30: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 3E6778F6 for ; Tue, 9 Feb 2016 18:30: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 u19IUMRU017084 for ; Tue, 9 Feb 2016 18:30:22 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 206934] MFC of commits r272695 and r288529 Date: Tue, 09 Feb 2016 18:30:22 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mgrooms@shrew.net X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not Enough Information X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: mfc-stable10? 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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 18:30:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206934 mgrooms@shrew.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |Not Enough Information --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Feb 9 21:12:19 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EED64AA2EFD for ; Tue, 9 Feb 2016 21:12:19 +0000 (UTC) (envelope-from sunxiaoye07@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 A9357209 for ; Tue, 9 Feb 2016 21:12:19 +0000 (UTC) (envelope-from sunxiaoye07@gmail.com) Received: by mail-io0-x234.google.com with SMTP id d63so1073737ioj.2 for ; Tue, 09 Feb 2016 13:12:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=YgDOKSezaZrJBsWXU2BwL/E5LgZ9b4DPv7uOtVRQCXs=; b=xczb+15GbDjtho54DaqPGKceJQJCT9uPdvxUhJ1zf3qlVl5X4oW3TDEypftyeKYHee oBra7k04nXbYY3j/aLjs55F5RnQ8X9Hl5ATa2/qw1O/AS9obk9ivREIYINpMxNbB6JQu x8nhFYSz0Oa34GqDf0B6BKANjwqZnq+PUQ9Cc5SBhKSEShdjhWp4KtkQL+jugH4jLRXE Hugvj7SHmY3ja5YYcz+93gCmNkrHOtuz42xqqCo8V7qu/Fpy+SNr+GxeWo6V5KpxLY0A oA4tK0Z9UVLu3kY0MkDyMFNSbxbFum4MljS4r1HuVPZrJC/ByzWhCnznTqSG/rj+J26u ZrKg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rice-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=YgDOKSezaZrJBsWXU2BwL/E5LgZ9b4DPv7uOtVRQCXs=; b=iF/vkQwwt9RHwhOIWopE76+f6RzsaYbVM2ZbF9A8LnzG2bJMpzAr1rsGKsfIBkCDJC 1mKt62+284+mWQWG/CUq9sU1B0X8nj3Rb0BiPMNoH/Zl1yIyLrEdbtCnrHqjnRpycUSJ ZKfhXheD1OdYgl0/WOs6pFQJtHSNZjAF5xZiCqNiFLeVTAudAVRBdVkdA1sO2S9sIMXj sw4UNjVBTBGwx/JvlIipsJtfdFcW2ytFPjlI/Ep8o56ssg/VZRP5ba/R/1sC6fVA7WER SUMyDsjQqUWZB3R6mwEOlnW3Yg4i5NXT7rciKAPb0xtZsrUIPpZDG9RFC8tDAgH8nltn +SDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YgDOKSezaZrJBsWXU2BwL/E5LgZ9b4DPv7uOtVRQCXs=; b=ezoG7Tw2cc5UubZv6j1tDMUSX/g5A0iWvpT+W6gGpGLqLsrM+/3Yja6ys6z/y2KD+Q 02U7YqZWb+nNS6XX7qhVnamB5jcRLVyH+FWWYRMl5DbfJ6LfFlU9Ydj0MZCn/InZzIxI EB9EyvVVspfVP5OFdSoIsxAPf9hNbWumOxYUsB0Xp2Pgjnlsl6zNlkv2XbuuxDalbhXa YIWdeoqVq8H62rIWQv9Rv9Sj8AFiVoJNLGnEKgynVEpyqADDFNlyHG7H6/a+3z8zwsD7 A7487YoW/u2fX5Ut1suOCpaBbCRT1HHrnQ3B8NSTAag9vD3ZzKMLDe85GtWmAzqQyvG8 g//w== X-Gm-Message-State: AG10YOTTKBS2VKXuj4gBu0pVkxuWkpnBpRKzUZyW2RyX3KR5H6HDN+1eVw+UzZ/Jof1gMDNH0TUb6ED4uWrH0w== MIME-Version: 1.0 X-Received: by 10.107.39.78 with SMTP id n75mr35927750ion.14.1455052338846; Tue, 09 Feb 2016 13:12:18 -0800 (PST) Sender: sunxiaoye07@gmail.com Received: by 10.36.98.82 with HTTP; Tue, 9 Feb 2016 13:12:18 -0800 (PST) In-Reply-To: References: Date: Tue, 9 Feb 2016 15:12:18 -0600 X-Google-Sender-Auth: QnVwZhL20hiLLFthWWGZjtl9vJo Message-ID: Subject: Re: swaping ring slots between NIC ring and Host ring does not always success From: Xiaoye Sun To: Victor Detoni Cc: Luigi Rizzo , Pavel Odintsov , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 21:12:20 -0000 Hi Luigi, Have you seen the previous email. any comments? On Fri, Feb 5, 2016 at 3:29 PM, Xiaoye Sun wrote: > Hi Victor, > Thanks for the help. The command you provided worked perfectly for me. > > Hi Luigi, > > Thanks for your clarification. > > The experiment I did was NOT running on 3 nodes. They ran on two nodes. > node 1 ran [1. sender]; node 2 ran [2. bridge.c] and [3. receiver (not > using netmap)]; [2. bridge.c ] saw packets inorder. [3. receiver] saw > packets out-of-order. I saw replication packets (even corrupted packets) in > the setup I mentioned in my first email in this threads. I did not see > replication packet in the sender-bridge-receiver setup. Let's solve the > reorder problem first and then solve the replication packet problem. > > I also tried the experiment setup having 3 nodes running sender, bridge, > receiver( both non-netmap based and netmap based XYZ) respectively. In the > 3 nodes experiment, there is NO packet reorder no any node. The difference > between the 2 nodes experiment and the 3 nodes experiment is that in the > bridge of node 2 in the 2-nodes experiment the bridge interact with the > host stack, while netmap does not interact with host stack in the 3-node > experiment. > > This makes me make the conclusion that there might be some problem with > the interaction between netmap and host stack. What is your opinion? > > Thanks! > > Xiaoye > > On Thu, Feb 4, 2016 at 6:26 PM, Victor Detoni > wrote: > >> I'm sorry, I made mistake. To workaround this try `ip link set $IFACE >> promisc on` >> >> >> >> On Thu, Feb 4, 2016 at 10:04 PM, Xiaoye Sun wrote: >> >>> Yes. all the interfaces are up. Are you able to get ARP request when >>> the interfaces are down? >>> >>> >>> On Thursday, February 4, 2016, Victor Detoni >>> wrote: >>> >>>> Both interfaces are up? Like ifconfig... up >>>> >>>> I had this the same problem and I solve with commands above >>>> >>>> Em quinta-feira, 4 de fevereiro de 2016, Xiaoye Sun < >>>> Xiaoye.Sun@rice.edu> escreveu: >>>> >>>>> Hi Luigi, >>>>> >>>>> Thanks for your explanation. >>>>> >>>>> I used three machines to do this experiment. They are directly >>>>> connected. >>>>> >>>>> [(machine1) eth1]---[eth2 (machine2) eth3]---[eth4 (machine3)]. >>>>> >>>>> First, I tried to run bridge.c on machine2 using the command *bridge -i >>>>> netmap:eth2 -i netmap:eth3*. (sender receiver or XYZ were not running >>>>> on >>>>> machine 1or3) >>>>> >>>>> For my understanding, in this setup, machine2 will be transparent to >>>>> machine1&3 since it forwards packet from its eth2 to eth3 and vice >>>>> versa >>>>> without any modification to the packets. >>>>> >>>>> I tried to ping machine 3 from machine 1 using the command like *ping >>>>> 10.11.10.3*. However, it still does not success. >>>>> This is because that before machine1 sends ping message to machine3, it >>>>> will first send a ARP request message to get the mac address of >>>>> machine3. >>>>> machine3 gets that ARP request, and send the reply back (I use tcpdump >>>>> to >>>>> verify that machine3 gets the ARP request and send out the ARP reply). >>>>> However, machine1 does not get the ARP reply. >>>>> >>>>> I checked that the bridge can only forwarding packet in one direction >>>>> at >>>>> the same time. it gets the ARP request but doesn't see the ARP reply >>>>> (*pkt_queued* always returns 0 for one nic...). >>>>> >>>>> This behavior looks very weird to me. Do you think there is a >>>>> compatibility >>>>> issues between netmap and the os I am using? Is there a verified linux >>>>> distribution (also the version) that perfectly works well with netmap? >>>>> >>>>> The OS I use is 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 >>>>> (2015-05-24) >>>>> x86_64 GNU/Linux. >>>>> Linux kernel version is *3.16.0-4-amd64* >>>>> >>>>> >>>>> Thanks! >>>>> Xiaoye >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Feb 3, 2016 at 2:12 AM, Luigi Rizzo >>>>> wrote: >>>>> >>>>> > On Tue, Feb 2, 2016 at 10:48 PM, Xiaoye Sun >>>>> wrote: >>>>> > > >>>>> > > >>>>> > > On Mon, Feb 1, 2016 at 11:34 PM, Luigi Rizzo >>>>> wrote: >>>>> > >> >>>>> > >> On Tue, Feb 2, 2016 at 6:23 AM, Xiaoye Sun >>>>> wrote: >>>>> > >> > Hi Luigi, >>>>> > >> > >>>>> > >> > I have to clarify about the *jumping issue* about the slot >>>>> indexes. >>>>> > >> > In the bridge.c program, the slot index never jumps and it >>>>> increases >>>>> > >> > sequentially. >>>>> > >> > In the receiver.c program, the udp packet seq jumps and I >>>>> showed the >>>>> > >> > slot >>>>> > >> > index that each udp packet uses. So the slot index jumps >>>>> together with >>>>> > >> > the >>>>> > >> > udp seq (at the receiver program only). >>>>> > >> >>>>> > >> So let me understand, is the "slot" some information written >>>>> > >> in the packet by bridge.c (referring to the rx or tx slot, >>>>> > >> I am not sure) and then read and printed by receiver.c >>>>> > >> (which gets the packet through recvfrom so there isn't >>>>> > >> really any slot index) ? >>>>> > >> >>>>> > > It works in the other way: >>>>> > > The bridge.c checks the seq numbers of the udp packets in netmap >>>>> slots >>>>> > (in >>>>> > > nic rx ring) before the swap; then it records the seq number, slot >>>>> > > number(both rx and tx (tx indexes were not shown in the previous >>>>> email >>>>> > since >>>>> > > they all look correct)) and buf_idx (rx and tx). The bridge.c does >>>>> not >>>>> > > change anything in the buffer and it knows the slot and buf_idx >>>>> that a >>>>> > > packet uses. Please refer to the added code in *process_rings* >>>>> function >>>>> > > http://www.owlnet.rice.edu/~xs6/bridge.c >>>>> > > The receiver.c checks the seq numbers only and print out the seq >>>>> numbers >>>>> > it >>>>> > > receive sequentially. >>>>> > > With these information, I manually match the seq number I got from >>>>> > > receiver.c and the seq number I got from bridge.c. So we know what >>>>> is the >>>>> > > seq order the receiver sees and which slot a packet uses when >>>>> bridge.c >>>>> > swaps >>>>> > > the buf_idxs. >>>>> > > >>>>> > >> Do you see any ordering inversion when the receiver >>>>> > >> gets packets through the NETMAP API (e.g. using bridge.c >>>>> > >> instead of receiver.c) ? >>>>> > >> >>>>> > > There is no ordering inversion seen by bridge.c (As I said in the >>>>> > previous >>>>> > > paragraph, the bridge.c checks the seq number and I did not see >>>>> any order >>>>> > > inversion in THIS simple experiment (In my multicast protocol >>>>> (mentioned >>>>> > in >>>>> > > the first email), there is ordering inversion. But let us solve the >>>>> > simple >>>>> > > bridge.c's problem first. I think they are two relatively >>>>> independent >>>>> > > issues.)). >>>>> > >>>>> > Sorry there was a misunderstanding. >>>>> > I wanted you to check the following setup: >>>>> > >>>>> > [1: send.c] ->- [2: bridge.c] ->- [3: XYZ] >>>>> > >>>>> > where in XYZ you replace your receiver.c with some >>>>> > netmap-based receiver (it could be pkt-gen in rx mode, >>>>> > or possibly even another instance of bridge.c where >>>>> > you connect the output port to a vale switch so >>>>> > traffic is dropped), and then in XYZ print the content >>>>> > of the packets. >>>>> > >>>>> > From your previous report we know that node 2: sees packets >>>>> > in order, and node 3: sees packets out of order. >>>>> > However, if the problem were due to bridge.c sending >>>>> > the old buffer and not the new one, you'd see not only >>>>> > reordering but also replication of packets. >>>>> > >>>>> > The fact that you see only the reordering in 3: makes >>>>> > me think that the problem is in that node, and it could >>>>> > be the network stack in 3: that does something strange. >>>>> > So if you can run something netmap based in 3: and make >>>>> > sure there is only one queue to read from, we could >>>>> > at least figure out what is going on. >>>>> > >>>>> > cheers >>>>> > luigi >>>>> > >>>>> > >>>>> > is that >>>>> > > >>>>> > >> >>>>> > >> Are you using native netmap drivers or the emulated mode ? >>>>> > >> You can check that by playing with the "admode" sysctl entry >>>>> > >> (or sysfs on linux) - try setting to 1 and 2 and see if >>>>> > >> the behaviour changes. >>>>> > >> >>>>> > >> dev.netmap.admode: 0 >>>>> > >> Controls the use of native or emulated adapter mode. >>>>> > >> 0 uses the best available option, >>>>> > >> 1 forces native and fails if not available, >>>>> > >> 2 forces emulated hence never fails. >>>>> > >> >>>>> > > I was using admode 0. I changed the admode to 1 and 2 using the >>>>> command >>>>> > like >>>>> > > *echo 1 > /sys/module/netmap/parameters/admode* and restart the >>>>> bridge >>>>> > > program. The behavior keeps the same. >>>>> > > >>>>> > >> >>>>> > >> cheers >>>>> > >> luigi >>>>> > >> >>>>> > >> > >>>>> > >> > There is really one ring (tx and rx) for NIC and one ring (tx >>>>> and rx) >>>>> > >> > for >>>>> > >> > the host. >>>>> > >> > I also doubt that there might be multiple tx rings for the >>>>> host. It >>>>> > >> > seems >>>>> > >> > like that bridge program swap packet to multiple host rings and >>>>> the >>>>> > udp >>>>> > >> > recv >>>>> > >> > program drains packets from these rings. But this is not the >>>>> case >>>>> > here. >>>>> > >> > >>>>> > >> > The bridge program prints a line like this >>>>> > >> > *515.277263 main [277] Ready to go, eth3 0x1/1 <-> eth3 0x0/1.* >>>>> > >> > this is printed by the following line the original program >>>>> > >> > *D("Ready to go, %s 0x%x/%d <-> %s 0x%x/%d.", pa->req.nr_name, >>>>> > >> > pa->first_rx_ring, pa->req.nr_rx_rings, pb->req.nr_name, >>>>> > >> > pb->first_rx_ring, >>>>> > >> > pb->req.nr_rx_rings);* >>>>> > >> > >>>>> > >> > I think this shows that there is really one NIC ring and one >>>>> HOST >>>>> > ring. >>>>> > >> > >>>>> > >> > Is there another way to verify the number of ring that netmap >>>>> has? >>>>> > >> > >>>>> > >> > Thanks! >>>>> > >> > Xiaoye >>>>> > >> > >>>>> > >> > On Mon, Feb 1, 2016 at 10:48 PM, Luigi Rizzo < >>>>> rizzo@iet.unipi.it> >>>>> > wrote: >>>>> > >> >> >>>>> > >> >> Hi, >>>>> > >> >> there must be some wrong with your setting because >>>>> > >> >> slot indexes must be sequential and in your case they >>>>> > >> >> are not (see the jump from 295 to 474 and then >>>>> > >> >> back from 485 to 296, and the numerous interleavings >>>>> > >> >> that you are seeing later). >>>>> > >> >> >>>>> > >> >> I have no idea of the cause but typically this pattern >>>>> > >> >> is what you see when there are multiple input rings and >>>>> > >> >> not just one. >>>>> > >> >> >>>>> > >> >> Cheers >>>>> > >> >> Luigi >>>>> > >> >> >>>>> > >> >> >>>>> > >> >> >>>>> > >> >> >>>>> > >> >> On Tue, Feb 2, 2016 at 12:24 AM, Xiaoye Sun < >>>>> Xiaoye.Sun@rice.edu> >>>>> > >> >> wrote: >>>>> > >> >> > Hi Luigi, >>>>> > >> >> > >>>>> > >> >> > Thanks for the detailed advice. >>>>> > >> >> > >>>>> > >> >> > With more detailed experiments, actually I found that the udp >>>>> > >> >> > sender/receiver packet reorder issue *might* be irrelevant >>>>> to the >>>>> > >> >> > original >>>>> > >> >> > issue I posted. However, I think we should solve the udp >>>>> > >> >> > sender/receiver >>>>> > >> >> > issue first. >>>>> > >> >> > I run the experiment with more detailed log. Here is my >>>>> findings. >>>>> > >> >> > >>>>> > >> >> > 1. I am running a netmap version available since about Oct >>>>> 13rd >>>>> > from >>>>> > >> >> > github >>>>> > >> >> > (https://github.com/luigirizzo/netmap). So I think this is >>>>> not the >>>>> > >> >> > one >>>>> > >> >> > related to the buffer allocation issue. I tried to running >>>>> the >>>>> > newest >>>>> > >> >> > version, however, that version causes problem when I exit the >>>>> > bridge >>>>> > >> >> > program >>>>> > >> >> > (something like kernel error which make the os crash). >>>>> > >> >> > >>>>> > >> >> > 2 & 3. I changed the receiver.c & bridge.c so that I can get >>>>> more >>>>> > >> >> > information (more detailed log). >>>>> > >> >> > The reorder happens multiple times (about 10 times) within a >>>>> > second. >>>>> > >> >> > Here is >>>>> > >> >> > one example trace collected from the above two programs. >>>>> > (remembering >>>>> > >> >> > that >>>>> > >> >> > we have udp sender running on one machine; netmap bridge and >>>>> udp >>>>> > >> >> > receiver >>>>> > >> >> > are running on another machine). >>>>> > >> >> > There is only one pair of rings each with 512 slots (511 slot >>>>> > usable) >>>>> > >> >> > on >>>>> > >> >> > the >>>>> > >> >> > receiver machine. >>>>> > >> >> > >>>>> > >> >> > =================== packet trace collected from receiver.c >>>>> > >> >> > =================== >>>>> > >> >> > ===== together with the slot and buf_idx of the corresponding >>>>> > netmap >>>>> > >> >> > ring >>>>> > >> >> > slots ====== >>>>> > >> >> > [seq] [slot] [buf_idx] >>>>> > >> >> > 8208 294 1833 >>>>> > >> >> > 8209 295 1834 >>>>> > >> >> > 8388 474 2013 >>>>> > >> >> > ... (packet received in order) >>>>> > >> >> > 8398 484 2023 >>>>> > >> >> > 8399 485 2024 >>>>> > >> >> > 8210 296 1835 >>>>> > >> >> > 8211 297 1836 >>>>> > >> >> > ... (packet received in order) >>>>> > >> >> > ... >>>>> > >> >> > 8222 308 1847 >>>>> > >> >> > 8400 486 2025 >>>>> > >> >> > 8223 309 1848 >>>>> > >> >> > 8401 487 2026 >>>>> > >> >> > 8224 310 1849 >>>>> > >> >> > 8402 488 2027 >>>>> > >> >> > 8225 311 1850 >>>>> > >> >> > 8403 489 2028 >>>>> > >> >> > 8226 312 1851 >>>>> > >> >> > 8404 450 2029 >>>>> > >> >> > 8227 313 1852 >>>>> > >> >> > 8228 314 1853 >>>>> > >> >> > >>>>> =================================================================== >>>>> > >> >> > As we can see that the udp receiver got packet 8210 after it >>>>> got >>>>> > >> >> > 8399, >>>>> > >> >> > which >>>>> > >> >> > is the first reorder. Then, the receiver got 8211 to 8222 >>>>> > >> >> > sequentially. >>>>> > >> >> > Then >>>>> > >> >> > it got packet from 8223-8227 and 8400-8404 interleaved. >>>>> > >> >> > >>>>> > >> >> > >>>>> > >> >> > ==================== event order seen by netmap bridge >>>>> > >> >> > ================== >>>>> > >> >> > get 8209 >>>>> > >> >> > poll called >>>>> > >> >> > get 8210 >>>>> > >> >> > ... >>>>> > >> >> > ... >>>>> > >> >> > get 8228 >>>>> > >> >> > poll called >>>>> > >> >> > get 8229 >>>>> > >> >> > ... >>>>> > >> >> > ... >>>>> > >> >> > get 8383 >>>>> > >> >> > poll called >>>>> > >> >> > get 8384 >>>>> > >> >> > ... >>>>> > >> >> > get 8387 >>>>> > >> >> > poll called >>>>> > >> >> > get 8388 >>>>> > >> >> > ... >>>>> > >> >> > get 8393 >>>>> > >> >> > poll called >>>>> > >> >> > get 8394 >>>>> > >> >> > ... >>>>> > >> >> > get 8399 >>>>> > >> >> > poll called >>>>> > >> >> > get 8400 >>>>> > >> >> > ... >>>>> > >> >> > get 8404 >>>>> > >> >> > poll called >>>>> > >> >> > get 8405 >>>>> > >> >> > >>>>> =================================================================== >>>>> > >> >> > As we can see, from the event ordering see by the bridge.c, >>>>> all the >>>>> > >> >> > packets >>>>> > >> >> > are receiver in order, which means the the reorder happens >>>>> when the >>>>> > >> >> > bridge >>>>> > >> >> > code swap the buf_idx between the nic ring(slot) and the host >>>>> > >> >> > ring(slot). >>>>> > >> >> > The reordered seq usually right before or after the poll >>>>> function >>>>> > >> >> > call. >>>>> > >> >> > >>>>> > >> >> > Best, >>>>> > >> >> > Xiaoye >>>>> > >> >> > >>>>> > >> >> > >>>>> > >> >> > >>>>> > >> >> > >>>>> > >> >> > >>>>> > >> >> > >>>>> > >> >> > >>>>> > >> >> > >>>>> > >> >> > On Fri, Jan 29, 2016 at 4:27 PM, Luigi Rizzo < >>>>> rizzo@iet.unipi.it> >>>>> > >> >> > wrote: >>>>> > >> >> >> >>>>> > >> >> >> On Fri, Jan 29, 2016 at 2:12 PM, Xiaoye Sun < >>>>> Xiaoye.Sun@rice.edu> >>>>> > >> >> >> wrote: >>>>> > >> >> >> > Hi Luigi, >>>>> > >> >> >> > >>>>> > >> >> >> > Thanks for your advice. >>>>> > >> >> >> > I forgot to mention that I use the command "ethtool -L >>>>> eth1 >>>>> > >> >> >> > combined >>>>> > >> >> >> > 1" >>>>> > >> >> >> > to >>>>> > >> >> >> > set the number of rings of the nic to 1. The host also >>>>> only has >>>>> > >> >> >> > one >>>>> > >> >> >> > ring. >>>>> > >> >> >> > I understand the situation where the first tx ring is >>>>> full so >>>>> > the >>>>> > >> >> >> > bridge >>>>> > >> >> >> > will swap the packets to the second tx ring and then the >>>>> > host/nic >>>>> > >> >> >> > might >>>>> > >> >> >> > drain either rings. But this is not the case in the >>>>> experiment. >>>>> > >> >> >> >>>>> > >> >> >> ok good to know that. >>>>> > >> >> >> >>>>> > >> >> >> So if we have ruled out multiqueue and iommu, let's look at >>>>> > >> >> >> the internal allocator and at bridge.c >>>>> > >> >> >> >>>>> > >> >> >> 1. are you running the most recent version of netmap ? >>>>> > >> >> >> Some older version (probably 1-2 years ago) had a bug >>>>> > >> >> >> in the buffer allocator and some buffers were allocated >>>>> > >> >> >> twice. >>>>> > >> >> >> >>>>> > >> >> >> 2. can you tweak your receiver.c to report some more info >>>>> > >> >> >> on how often you get out of sequence packets, how much >>>>> > >> >> >> out of sequence they are ? >>>>> > >> >> >> Also it would be useful to report gaps on the increasing >>>>> side >>>>> > >> >> >> (i.e. new_seq != old_seq +1 ) >>>>> > >> >> >> >>>>> > >> >> >> 3. can you tweak bridge.c so that it writes into the packet >>>>> > >> >> >> the netmap buffer indexes and slots on the rx and tx >>>>> side, >>>>> > >> >> >> so when you detect a sequence error we can figure out >>>>> > >> >> >> where it is happening. >>>>> > >> >> >> Ideally you could also add the sequence number detection >>>>> > >> >> >> code in bridge.c so we can check whether the errors >>>>> appear >>>>> > >> >> >> on the input or output sides. >>>>> > >> >> >> >>>>> > >> >> >> cheers >>>>> > >> >> >> luigi >>>>> > >> >> >> >>>>> > >> >> > >>>>> > >> >> >>>>> > >> >> >>>>> > >> >> >>>>> > >> >> -- >>>>> > >> >> >>>>> > >> >> >>>>> > >>>>> -----------------------------------------+------------------------------- >>>>> > >> >> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. >>>>> > >> >> dell'Informazione >>>>> > >> >> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa >>>>> > >> >> TEL +39-050-2217533 . via Diotisalvi 2 >>>>> > >> >> Mobile +39-338-6809875 . 56122 PISA (Italy) >>>>> > >> >> >>>>> > >> >> >>>>> > >>>>> -----------------------------------------+------------------------------- >>>>> > >> >> >>>>> > >> > >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > >> -- >>>>> > >> >>>>> > >>>>> -----------------------------------------+------------------------------- >>>>> > >> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. >>>>> > dell'Informazione >>>>> > >> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa >>>>> > >> TEL +39-050-2217533 . via Diotisalvi 2 >>>>> > >> Mobile +39-338-6809875 . 56122 PISA (Italy) >>>>> > >> >>>>> > >>>>> -----------------------------------------+------------------------------- >>>>> > >> >>>>> > > >>>>> > >>>>> > >>>>> > >>>>> > -- >>>>> > >>>>> -----------------------------------------+------------------------------- >>>>> > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. >>>>> dell'Informazione >>>>> > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa >>>>> > TEL +39-050-2217533 . via Diotisalvi 2 >>>>> > Mobile +39-338-6809875 . 56122 PISA (Italy) >>>>> > >>>>> -----------------------------------------+------------------------------- >>>>> > >>>>> > >>>>> _______________________________________________ >>>>> freebsd-net@freebsd.org mailing list >>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-net >>>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>>>> >>>> >> > From owner-freebsd-net@freebsd.org Tue Feb 9 21:58:03 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85D04AA230E for ; Tue, 9 Feb 2016 21:58:03 +0000 (UTC) (envelope-from jb@jboy.eu) Received: from gacrux.uberspace.de (gacrux.uberspace.de [185.26.156.53]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0CA4415A1 for ; Tue, 9 Feb 2016 21:58:02 +0000 (UTC) (envelope-from jb@jboy.eu) Received: (qmail 9360 invoked from network); 9 Feb 2016 21:51:16 -0000 Received: from localhost (HELO jb-mbp.fritz.box) (127.0.0.1) by gacrux.uberspace.de with SMTP; 9 Feb 2016 21:51:16 -0000 From: Jeremy Boy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: ifconfig with quoted arguments Date: Tue, 9 Feb 2016 22:51:14 +0100 Message-Id: <76A08658-ACD2-426B-865A-45A6A79BBFB4@jboy.eu> Cc: Jeremy Boy To: freebsd-net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 21:58:03 -0000 Hello list, please CC me in replies to this mail, since I am no subscriber to this = list. For safety reasons, we enclose user input to shell commands in quotes. = Until today, the resulting command for ifconfig(8) looked like this: > ifconfig ue0 inet "192.168.2.176 netmask 255.255.255.0" As we figured out, this means that ifconfig sometimes doesn't set the = netmask as we expect it to do: > root@csbuild:~ # ifconfig ue0 > ue0: flags=3D8843 metric 0 mtu = 1500 > options=3D80001 > ether b8:27:eb:fd:58:69 > inet 192.168.2.176 netmask 0xffff0000 broadcast = 192.168.255.255=20 > media: Ethernet autoselect (100baseTX ) > status: active > nd6 options=3D29 > root@csbuild:~ # ifconfig ue0 inet "192.168.2.176 netmask 255.0.0.0" > root@csbuild:~ # echo $? > 0 > root@csbuild:~ # ifconfig ue0 > ue0: flags=3D8843 metric 0 mtu = 1500 > options=3D80001 > ether b8:27:eb:fd:58:69 > inet 192.168.2.176 netmask 0xffffff00 broadcast 192.168.2.255=20= > media: Ethernet autoselect (100baseTX ) > status: active > nd6 options=3D29 > root@csbuild:~ #=20 As you can see, ifconfig sets the netmask to 255.255.255.0, ignoring the = netmask we provided. If provided with a 10.* address, ifconfig sets the = netmask to 255.0.0.0, no matter what actual netmask we entered. Also, it = doesn't exit with a status indicating error, which made it a little = harder to debug this issue. The following works as expected: > root@csbuild:~ # ifconfig ue0 > ue0: flags=3D8843 metric 0 mtu = 1500 > options=3D80001 > ether b8:27:eb:fd:58:69 > inet 192.168.2.176 netmask 0xffffff00 broadcast 192.168.2.255=20= > media: Ethernet autoselect (100baseTX ) > status: active > nd6 options=3D29 > root@csbuild:~ # ifconfig ue0 inet "192.168.2.176" netmask "255.0.0.0" > root@csbuild:~ # ifconfig ue0 > ue0: flags=3D8843 metric 0 mtu = 1500 > options=3D80001 > ether b8:27:eb:fd:58:69 > inet 192.168.2.176 netmask 0xff000000 broadcast = 192.255.255.255=20 > media: Ethernet autoselect (100baseTX ) > status: active > nd6 options=3D29 > root@csbuild:~ #=20 What exactly does ifconfig do? It seems to me that it reads the IP = address from the quoted string but truncates the netmask. Is this a bug = in ifconfig or intended behavior? Best wishes Jeremy= From owner-freebsd-net@freebsd.org Tue Feb 9 22:57:29 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C03FCAA2012 for ; Tue, 9 Feb 2016 22:57:29 +0000 (UTC) (envelope-from pallav_bose@yahoo.com) Received: from nm49.bullet.mail.gq1.yahoo.com (nm49.bullet.mail.gq1.yahoo.com [67.195.87.85]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9D5D01894 for ; Tue, 9 Feb 2016 22:57:29 +0000 (UTC) (envelope-from pallav_bose@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1455058503; bh=UccVnNQPbfgaa5QQUXIMuung1CA0uC5o14iIA4qriP0=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=HYvA9ZELv/U1GFn7DZjz7BeQ7T1pTJaRi+hCurwdvnbT+5lBfWXWeVY9XzPv6GacU1GZYr26yzpL9pwE6NTWAJz9nwOtIyZsDIk6IaVpxJhzQ5YuFWz2s/s9V97sgM4LixGdhY6Vu8qeF+uYq5Lg914+uoP901GHuFYQVnZWNzmfosxkyu5JWHlv1HTLMjs9jFbsj+W9Tirjw8JiNhNQ2JE5O41hDTiX4TbkUXqemjZDhzMPapHgkFwpJJmkmjlGHoFUNBYfU5zHAd6VPjoe8/dzhJOwhR5SWTgboVnon0DQBYB3I0Wn6imz8nHaHoZy7hlQj2/2F4SLtyWtiGLe6g== Received: from [127.0.0.1] by nm49.bullet.mail.gq1.yahoo.com with NNFMP; 09 Feb 2016 22:55:03 -0000 Received: from [98.137.12.63] by nm49.bullet.mail.gq1.yahoo.com with NNFMP; 09 Feb 2016 22:52:06 -0000 Received: from [98.137.12.212] by tm8.bullet.mail.gq1.yahoo.com with NNFMP; 09 Feb 2016 22:52:06 -0000 Received: from [127.0.0.1] by omp1020.mail.gq1.yahoo.com with NNFMP; 09 Feb 2016 22:52:06 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 520743.73898.bm@omp1020.mail.gq1.yahoo.com X-YMail-OSG: ftZ1YDcVM1ljNUX0hh3KSxvh2nDRZbOooemj0yy7A3YubwDhYuQA._JmZW8b6oR AQxQnY37m1cDMzF0hkfnDOTWXy2jYq9ztSv51DgfmWq6829AquUlFA6U6a_kaxyCPiIl8.6DREUF KQbJrYLQW237iokqtLN53r7uoQ4pa5BQJBzMMPisx9GzLRzE41dUmF9f8.5YE51PhGX_0JQtLgR. AnxOAaArejiWYRYM3Qu8GYswaoy8HLlN5oZpLT.Y3jWRhjqvUdLv9FzTfGxmNxw5gZgfNCzt_Bap opTRX.HTBhUBod41I_LaLsmsKlkUd.GrBAXsV46jUGOv3qrMZo3I8.jdxKIeUHokpFUgojUasRSW gnaiP81f.3m8znqZTY_5eXmodP5LbVBpyflXJCXPj4ZgwK7WELB48RV109O4Eg0O0NurmpBgDukn fqg_ChcEsVO54BU6_.YBQ5m1bqjnOiUb7.6cLgveMn.LXmt9WFN70utMq8G99iHT2n0wN0gUjjKR AV3HdK7o__ygoqJwbmIcm Received: by 98.137.12.246; Tue, 09 Feb 2016 22:52:05 +0000 Date: Tue, 9 Feb 2016 22:51:27 +0000 (UTC) From: Pallav Bose Reply-To: Pallav Bose To: "freebsd-net@freebsd.org" Message-ID: <249322925.1631277.1455058288002.JavaMail.yahoo@mail.yahoo.com> Subject: C program API to determine negotiated link speed of a network interface? MIME-Version: 1.0 References: <249322925.1631277.1455058288002.JavaMail.yahoo.ref@mail.yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 22:57:29 -0000 Hi, I'm writing a C program to list all available interfaces and their link spe= ed. I can use getifaddrs(3) to obtain a list of network interfaces in a str= uct ifaddrs, but none of the fields in this struct gives me information abo= ut the negotiated link speed. From the man page of getifaddrs(3): The ifaddrs structure contains at least the following entries: =C2=A0=C2=A0=C2=A0 =C2=A0struct=C2=A0=C2=A0=C2=A0 ifaddrs=C2=A0=C2=A0=C2=A0= *ifa_next;=C2=A0=C2=A0=C2=A0 =C2=A0 /* Pointer to next struct */ =C2=A0=C2=A0=C2=A0 =C2=A0char=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *ifa_name;=C2=A0=C2=A0=C2=A0 = =C2=A0 /* Interface name */ =C2=A0=C2=A0=C2=A0 =C2=A0u_int=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ifa_flags;=C2=A0=C2=A0=C2=A0 = =C2=A0 /* Interface flags=C2=A0=C2=A0=C2=A0 */ =C2=A0=C2=A0=C2=A0 =C2=A0struct=C2=A0=C2=A0=C2=A0 sockaddr=C2=A0 *ifa_addr;= =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 /* Interface address */ =C2=A0=C2=A0=C2=A0 =C2=A0struct=C2=A0=C2=A0=C2=A0 sockaddr=C2=A0 *ifa_netma= sk;=C2=A0=C2=A0=C2=A0 /* Interface netmask */ =C2=A0=C2=A0=C2=A0 =C2=A0struct=C2=A0=C2=A0=C2=A0 sockaddr=C2=A0 *ifa_broad= addr;=C2=A0 /* Interface broadcast address */ =C2=A0=C2=A0=C2=A0 =C2=A0struct=C2=A0=C2=A0=C2=A0 sockaddr=C2=A0 *ifa_dstad= dr;=C2=A0=C2=A0=C2=A0 /* P2P interface destination */ =C2=A0=C2=A0=C2=A0 =C2=A0void=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *ifa_data;=C2=A0=C2=A0=C2=A0 =C2=A0=C2= =A0 /* Address specific data */ Running truss on ifconfig(8) tells me that the ioctl SIOCGIFMEDIA can be us= ed, but it is not clear to me how. Is there an API in C which does this alr= eady? # truss ifconfig em0........ ioctl(3,SIOCGIFMAC,0xffffe210)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ERR#22 'Inv= alid argument' ioctl(3,SIOCGIFMEDIA,0xffffe1f0)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D 0 (0x0) ioctl(3,SIOCGIFMEDIA,0xffffe1f0)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D 0 (0x0) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 media: Ethernet autoselect (1000= baseT ) write(1,"\tmedia: Ethernet autoselect (10"...,54) =3D 54 (0x36) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 status: active write(1,"\tstatus: active\n",16)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D 16 (0x10) Thanks,Pallav From owner-freebsd-net@freebsd.org Wed Feb 10 08:23:51 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0708EAA20CC for ; Wed, 10 Feb 2016 08:23:51 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9818E12F1 for ; Wed, 10 Feb 2016 08:23:49 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221]) by hz.grosbein.net (8.14.9/8.14.9) with ESMTP id u1A8Ni3x027870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Feb 2016 09:23:45 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: jb@jboy.eu Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTP id u1A8Nd3Q086428; Wed, 10 Feb 2016 15:23:39 +0700 (KRAT) (envelope-from eugen@grosbein.net) Subject: Re: ifconfig with quoted arguments To: Jeremy Boy , freebsd-net@freebsd.org References: <76A08658-ACD2-426B-865A-45A6A79BBFB4@jboy.eu> From: Eugene Grosbein X-Enigmail-Draft-Status: N1110 Message-ID: <56BAF38B.3080809@grosbein.net> Date: Wed, 10 Feb 2016 15:23:39 +0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <76A08658-ACD2-426B-865A-45A6A79BBFB4@jboy.eu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=1.4 required=5.0 tests=BAYES_00, DATE_IN_FUTURE_96_Q, LOCAL_FROM autolearn=no version=3.3.2 X-Spam-Report: * 1.1 DATE_IN_FUTURE_96_Q Date: is 4 days to 4 months after Received: date * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hz.grosbein.net X-Spam-Level: * X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 08:23:51 -0000 On 10.02.2016 04:51, Jeremy Boy wrote: > Hello list, > > please CC me in replies to this mail, since I am no subscriber to this list. > > For safety reasons, we enclose user input to shell commands in quotes. Until today, the resulting command for ifconfig(8) looked like this: > >> ifconfig ue0 inet "192.168.2.176 netmask 255.255.255.0" According to ifconfig(8) manual page, this syntax is wrong. > What exactly does ifconfig do? It seems to me that it reads the IP address from the quoted string but truncates the netmask. Is this a bug in ifconfig or intended behavior? The word "inet" is for "address_family". The next argument should be "address" and you supply "192.168.2.176 netmask 255.255.255.0" for "address". It seems, ifconfig passes this argument to inet_aton() function that parses IP address and ignores first space and the rest of string. From owner-freebsd-net@freebsd.org Wed Feb 10 09:16:22 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AEE1EAA3E66; Wed, 10 Feb 2016 09:16:22 +0000 (UTC) (envelope-from 8ohit.dua@gmail.com) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (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 78FDAE21; Wed, 10 Feb 2016 09:16:22 +0000 (UTC) (envelope-from 8ohit.dua@gmail.com) Received: by mail-ig0-x232.google.com with SMTP id ik10so10509488igb.1; Wed, 10 Feb 2016 01:16:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yCtwQvZ9UAun88g1KOMnjbji+YJn+QTo6V4aO7GctrI=; b=ubi8d8Z9Rf2CIYXtfveRGiHew2nrhwtt3sODHBktaOmgcmAf4vbmEZU9hpkCqXY0/0 qw7jZpCg3yaebDj2hZmUOpdakEslO8ekCErH8O+H6jifIaerk+Jw2YrAWAcdbrJwpN32 Oj5HfHzXLNcF3VoyUTF/rQChAoEvVd50PLLrZcLZf28Gf2egWQuG5YbvDsIC6nlElzin MLhkjo+yrRzBDv+f/D18DlLKvxxtBnbYvKkIj9mp/Cyqe3fH5HD5bVcQ3hyZlHLFmLaw aOMD0WKZabERWAzM5O/k/PrYPwchwTeU8VWHwwn0eiyVeYjWYECyyWfXlC4m1V+iWjCE x11Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yCtwQvZ9UAun88g1KOMnjbji+YJn+QTo6V4aO7GctrI=; b=jmLULPGuO1u7gsN628qaDpCoQ67Wn9W/X41q8NvYVJ0E749D34hO0FrMdyOGlZ6I2F 5XcsJK5SSlGoMahb78adeop+ohJ/8hvVlEYCz/BR+wX93HlELBSpMyeuPw5QImvO1kPy F3DQCKvucFYb4xzrCiF96R3onmKMOKG2PD3sDThysuVZil12AH4sPP4ZA7zaMEAiFKDO xuwEAhdcoAyJB73c4yoFM4cxTjRhr6/BYnP6VtkYjwDZUyO0MPCx+56usL5oo2tzNqmz sNwmJlgEQxPenqb+pXa9JAGxpnPEBdev1Yxu6S6VA2c6tu0NG2Fhh4CGyVWQ6GanH7FU /Lug== X-Gm-Message-State: AG10YOTLX8QqMrEg6fHyqsPqTGJQ9hIENa93GdhxJeeDgKrk1Ejonh/qAxVRSwiSX1zoWl3lGZ5rdsQY/ArYGw== MIME-Version: 1.0 X-Received: by 10.50.137.40 with SMTP id qf8mr6205039igb.61.1455095781827; Wed, 10 Feb 2016 01:16:21 -0800 (PST) Received: by 10.79.27.140 with HTTP; Wed, 10 Feb 2016 01:16:21 -0800 (PST) Received: by 10.79.27.140 with HTTP; Wed, 10 Feb 2016 01:16:21 -0800 (PST) In-Reply-To: <3c7c36bc8d7f0bdb4e04466d3d506960@mailbox.ijs.si> References: <3c7c36bc8d7f0bdb4e04466d3d506960@mailbox.ijs.si> Date: Wed, 10 Feb 2016 14:46:21 +0530 Message-ID: Subject: Re: Google Summer of Code 2016, unified ping/ping6, traceroute/traceroute6, ... From: Rohit Dua <8ohit.dua@gmail.com> To: Mark Martinec Cc: freebsd-net@freebsd.org, soc-admins@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 09:16:22 -0000 Hi I'm willing to work on this project for GSOC 2016. I'm looking forward to a more elaborate description on these topics. I'm not sure but can't we just use the freebsd-net mailing list for these GSOC project(s) Thanks Rohit Dua On 9 Feb 2016 23:24, "Mark Martinec" wrote: > There is now a timeline published for Google Summer of Code 2016: > https://developers.google.com/open-source/gsoc/timeline > > Will FreeBSD apply for this year's participation in GSoC 2016? > > I'm not a committer or a mentor, although last year I have > submitted two ideas for GSoC projects, for which I still have > great interest as a user: > > > https://wiki.freebsd.org/SummerOfCodeIdeas#Task_name.2A:_Unified_ping_and_ping6 > > https://wiki.freebsd.org/SummerOfCodeIdeas#Task_name.2A:_Unified_traceroute_and_traceroute6 > > Last year there were two or three seemingly highly qualified and > motivated candidates for these two tasks. This year I have just > received a query from a new interested candidate. Unfortunately, > despite posting to freebsd-hackers ML and possibly elsewhere, > last year these candidates did not receive any reply (apart > from mine, suggesting contacts and indicated on a Wiki page). > > So the problem is finding a mentor that is willing to accept > the task of mentoring these two projects. I'm willing to > participate with comments, review and technical suggestions, > but someone (or preferably two persons) familiar with FreeBSD > coding styles and practices is needed, and to fill the > GSoC role of a mentor. Finding an interested qualified mentor > is also probably a pre-requisite that a student's work won't be > in vain and get a chance of being adopted in a FreeBSD project. > > I'm willing to elaborate more on my two proposed projects, > as the submission form (links above) had a word count limit > on a project description and on justifying a need. > > Is there a better mailing list that freebsd-hackers@ to cover > GSoC topics? > > Mark > From owner-freebsd-net@freebsd.org Wed Feb 10 10:16:08 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50E3DAA3F92 for ; Wed, 10 Feb 2016 10:16: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 40D891551 for ; Wed, 10 Feb 2016 10:16: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 u1AAG7hk067735 for ; Wed, 10 Feb 2016 10:16:08 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 206904] tailq crash/nd inet6 Date: Wed, 10 Feb 2016 10:16: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: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ler@lerctr.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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 10:16:08 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206904 --- Comment #6 from Larry Rosenman --- this seems to be at the root of my tcp6 issues. I've put a bunch more core.txt's at: http://www.lerctr.org/~ler/FreeBSD/ I've also put dmesg, loader.conf, rc.conf, sysctl.conf there.=20 I'd really like to get to the bottom of this. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Wed Feb 10 10:21:48 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1F0DCAA42F4 for ; Wed, 10 Feb 2016 10:21:48 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F2C5E1B32 for ; Wed, 10 Feb 2016 10:21:47 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:Subject:To:From:Date:Content-Transfer-Encoding: Content-Type:MIME-Version; bh=xL53OIrglE1GddcbPWUPfChHUieWenmZK/Oqw7jugE8=; b=VZ8jdbjNCvSqawpFMy5BbHVjoKtMVXR2EMKVl1WeBWvcbkdv9Cfca9xIFUWoQOJr8ruZ36SyB8 sBMcN9L/9lKJETms4Gu+sZRRhq/50bfhivjuv4dxNbuuoEeO2amCEOHoY+cgnnPT0pVHH33FpXYtc MMpTMXvjxZKX40SaaT94=; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]:44182 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aTRu6-0000OV-TN for freebsd-net@freebsd.org; Wed, 10 Feb 2016 04:21:47 -0600 Received: from 2605:6000:ec17:200:8960:77df:23a8:fcf by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Wed, 10 Feb 2016 04:21:46 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 10 Feb 2016 04:21:46 -0600 From: Larry Rosenman To: freebsd-net@freebsd.org Subject: tcp6/long connects Message-ID: X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.1.4 X-Spam-Score: -1.0 (-) X-LERCTR-Spam-Score: -1.0 (-) X-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 X-LERCTR-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1, SHORTCIRCUIT=-0.0001 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 10:21:48 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206904 related to the above captioned bug, I seem to have an issue with tcp6 connects. They take a LONG time (time out, or many seconds) from a FreeBSD -CURRENT (@r295321). a windows 10 box on the same network/subnet/LAN has ZERO issues connecting to the SAME HOSTS via TCP6 I've put a bunch of core.txt's and config info at: http://www.lerctr.org/~ler/FreeBSD/ while it's sitting there, a SIGINFO shows it in connec WHat else do I need to supply to get to the bottom of this? network: Cable Modem -> em0 of pfSense with requesting a /56 from Time Warner em1 of pfSense -> LAN with track Interface set, and radvd running and advertising a /64 out of the /56 LAN-> borg (the problem FreeBSD current) -> lrosenman-w520 (Windows 10), no tcp6 issues. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 From owner-freebsd-net@freebsd.org Wed Feb 10 13:00:10 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD8C8AA280D for ; Wed, 10 Feb 2016 13:00: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 BF33ADB9 for ; Wed, 10 Feb 2016 13:00: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 u1AD0A4M080718 for ; Wed, 10 Feb 2016 13:00:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 207055] ipv6 pmtu discovery not working with pf active Date: Wed, 10 Feb 2016 13:00: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: 10.2-STABLE X-Bugzilla-Keywords: 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 Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 13:00:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207055 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 Wed Feb 10 13:00:29 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7DFAAA28A1 for ; Wed, 10 Feb 2016 13:00: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 D8FF5EA6 for ; Wed, 10 Feb 2016 13:00: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 u1AD0T2M085476 for ; Wed, 10 Feb 2016 13:00:29 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 207056] Changing the MAC address on the lagg interface doesn't get retained after lagg port delete operation. Date: Wed, 10 Feb 2016 13:00: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: 11.0-CURRENT X-Bugzilla-Keywords: 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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 13:00:30 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207056 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 Wed Feb 10 13:21:13 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A441FAA334C for ; Wed, 10 Feb 2016 13:21:13 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::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 0B1CB1C97 for ; Wed, 10 Feb 2016 13:21:13 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mail-lb0-x22e.google.com with SMTP id cw1so10076259lbb.1 for ; Wed, 10 Feb 2016 05:21:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=QlQo2DoMJm0ypzD5w/Qur6YllMpekQJf1lx4EmcDM9A=; b=jIHK2NZc/9l6fMyaTeemNG/8ewTVsiURhxp4amgdFvMSlZy4yJjxw7yocpwFIiYHt9 04xD6r2L+IRCqix+5TNACHVPu0XcpvvwP+BcOAmBfY1c0fWFzGfoSgDpK055LdnL6A7U jp0jQqY3mQmP4ld4vJJ7W6Kmpt2cXX3en793fVRUH+pBikbhTvvrK0Nf4KqQQt1zg1rZ HNgvQyD3z4HkLnXdbrpG9FNgjNhNC27GNimzY8++NAVJRhXI8MePD8MU3K18IV96VyUZ CnvDpy49swLwjLMPBDp5Wf/yJ7fj6HjPrPLrxxySQ4v1sCvgfN17CxMMi8z5UNEapPI4 4mGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QlQo2DoMJm0ypzD5w/Qur6YllMpekQJf1lx4EmcDM9A=; b=jRv9RjCiN5VWOkWHXsD+dR6YFggr2gwjqrKtMmZwBlsBOac57Uvr+dCNfFD929VuVX Wcx606AbFFnlrAIL/Tjr7fise99XUkWrUxpa5F5mrpDiXsGf2mLEcQxq91ktjMPSMTvV y+wU9DxqTy+5Vs47fAZhz24X1SQahn86lFe9INEegDCr4jzCnPNu+L1PQDT9pIUxZEwV DlPWcTe2Do6L1HMoxbRek5tPE2U6h5qIvYDCQCd4YtDprTd90kOAdzukgBcgtws4cQxt bQtg3m+PrdQOgEBfL6Qwxbkn1vtodJYk3P82u5PLeBsYdP2yJmOHgObd30E25XXdnF4H +2UA== X-Gm-Message-State: AG10YOTdXQrN47ZDQVgjHSN018GXrjVBiXk1HT7Y3g8hxeg6GNKvIe8dX/TIeH22wu67AWOGDov/q2UG4azBSw== MIME-Version: 1.0 X-Received: by 10.112.155.201 with SMTP id vy9mr15974262lbb.54.1455110470911; Wed, 10 Feb 2016 05:21:10 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.4.232 with HTTP; Wed, 10 Feb 2016 05:21:10 -0800 (PST) In-Reply-To: References: Date: Wed, 10 Feb 2016 05:21:10 -0800 X-Google-Sender-Auth: N1pP5ULrYntH_nRPR4osko_IomA Message-ID: Subject: Re: swaping ring slots between NIC ring and Host ring does not always success From: Luigi Rizzo To: Xiaoye Sun Cc: Victor Detoni , Pavel Odintsov , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 13:21:13 -0000 On Tue, Feb 9, 2016 at 1:12 PM, Xiaoye Sun wrote: > Hi Luigi, > > Have you seen the previous email. any comments? Hi, to summarize, you are seeing reordering when reinjecting packets into the host stack from bridge.c On Linux, the NIOCTXSYNC towards the host stack calls netif_rx() one packet at a time (on freebsd that would be ifp->if_input()), and the calls are synchronous. In order to get reordering, you should have the following sequence of events: 1. bridge.c calls ioctl(NIOCTXSYNC) 2. netif_rx() queues packet instead of dispatching them to the socket 3. bridge.c builds another batch and calls ioctl(NIOCTXSYNC) 4. netif_rx() passes packets to the socket overtaking those in #2 I don't know whether netif_rx() can defer processing and how to prevent that. If this is the problem, one thing you could try is pin the bridge process to a specific core and see if that makes the problem disappear. cheers luigi > > On Fri, Feb 5, 2016 at 3:29 PM, Xiaoye Sun wrote: >> >> Hi Victor, >> Thanks for the help. The command you provided worked perfectly for me. >> >> Hi Luigi, >> >> Thanks for your clarification. >> >> The experiment I did was NOT running on 3 nodes. They ran on two nodes. >> node 1 ran [1. sender]; node 2 ran [2. bridge.c] and [3. receiver (not using >> netmap)]; [2. bridge.c ] saw packets inorder. [3. receiver] saw packets >> out-of-order. I saw replication packets (even corrupted packets) in the >> setup I mentioned in my first email in this threads. I did not see >> replication packet in the sender-bridge-receiver setup. Let's solve the >> reorder problem first and then solve the replication packet problem. >> >> I also tried the experiment setup having 3 nodes running sender, bridge, >> receiver( both non-netmap based and netmap based XYZ) respectively. In the 3 >> nodes experiment, there is NO packet reorder no any node. The difference >> between the 2 nodes experiment and the 3 nodes experiment is that in the >> bridge of node 2 in the 2-nodes experiment the bridge interact with the host >> stack, while netmap does not interact with host stack in the 3-node >> experiment. >> >> This makes me make the conclusion that there might be some problem with >> the interaction between netmap and host stack. What is your opinion? >> >> Thanks! >> >> Xiaoye >> >> On Thu, Feb 4, 2016 at 6:26 PM, Victor Detoni >> wrote: >>> >>> I'm sorry, I made mistake. To workaround this try `ip link set $IFACE >>> promisc on` >>> >>> >>> >>> On Thu, Feb 4, 2016 at 10:04 PM, Xiaoye Sun wrote: >>>> >>>> Yes. all the interfaces are up. Are you able to get ARP request when the >>>> interfaces are down? >>>> >>>> >>>> On Thursday, February 4, 2016, Victor Detoni >>>> wrote: >>>>> >>>>> Both interfaces are up? Like ifconfig... up >>>>> >>>>> I had this the same problem and I solve with commands above >>>>> >>>>> Em quinta-feira, 4 de fevereiro de 2016, Xiaoye Sun >>>>> escreveu: >>>>>> >>>>>> Hi Luigi, >>>>>> >>>>>> Thanks for your explanation. >>>>>> >>>>>> I used three machines to do this experiment. They are directly >>>>>> connected. >>>>>> >>>>>> [(machine1) eth1]---[eth2 (machine2) eth3]---[eth4 (machine3)]. >>>>>> >>>>>> First, I tried to run bridge.c on machine2 using the command *bridge >>>>>> -i >>>>>> netmap:eth2 -i netmap:eth3*. (sender receiver or XYZ were not running >>>>>> on >>>>>> machine 1or3) >>>>>> >>>>>> For my understanding, in this setup, machine2 will be transparent to >>>>>> machine1&3 since it forwards packet from its eth2 to eth3 and vice >>>>>> versa >>>>>> without any modification to the packets. >>>>>> >>>>>> I tried to ping machine 3 from machine 1 using the command like *ping >>>>>> 10.11.10.3*. However, it still does not success. >>>>>> This is because that before machine1 sends ping message to machine3, >>>>>> it >>>>>> will first send a ARP request message to get the mac address of >>>>>> machine3. >>>>>> machine3 gets that ARP request, and send the reply back (I use tcpdump >>>>>> to >>>>>> verify that machine3 gets the ARP request and send out the ARP reply). >>>>>> However, machine1 does not get the ARP reply. >>>>>> >>>>>> I checked that the bridge can only forwarding packet in one direction >>>>>> at >>>>>> the same time. it gets the ARP request but doesn't see the ARP reply >>>>>> (*pkt_queued* always returns 0 for one nic...). >>>>>> >>>>>> This behavior looks very weird to me. Do you think there is a >>>>>> compatibility >>>>>> issues between netmap and the os I am using? Is there a verified linux >>>>>> distribution (also the version) that perfectly works well with netmap? >>>>>> >>>>>> The OS I use is 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 >>>>>> (2015-05-24) >>>>>> x86_64 GNU/Linux. >>>>>> Linux kernel version is *3.16.0-4-amd64* >>>>>> >>>>>> >>>>>> Thanks! >>>>>> Xiaoye >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Feb 3, 2016 at 2:12 AM, Luigi Rizzo >>>>>> wrote: >>>>>> >>>>>> > On Tue, Feb 2, 2016 at 10:48 PM, Xiaoye Sun >>>>>> > wrote: >>>>>> > > >>>>>> > > >>>>>> > > On Mon, Feb 1, 2016 at 11:34 PM, Luigi Rizzo >>>>>> > > wrote: >>>>>> > >> >>>>>> > >> On Tue, Feb 2, 2016 at 6:23 AM, Xiaoye Sun >>>>>> > >> wrote: >>>>>> > >> > Hi Luigi, >>>>>> > >> > >>>>>> > >> > I have to clarify about the *jumping issue* about the slot >>>>>> > >> > indexes. >>>>>> > >> > In the bridge.c program, the slot index never jumps and it >>>>>> > >> > increases >>>>>> > >> > sequentially. >>>>>> > >> > In the receiver.c program, the udp packet seq jumps and I >>>>>> > >> > showed the >>>>>> > >> > slot >>>>>> > >> > index that each udp packet uses. So the slot index jumps >>>>>> > >> > together with >>>>>> > >> > the >>>>>> > >> > udp seq (at the receiver program only). >>>>>> > >> >>>>>> > >> So let me understand, is the "slot" some information written >>>>>> > >> in the packet by bridge.c (referring to the rx or tx slot, >>>>>> > >> I am not sure) and then read and printed by receiver.c >>>>>> > >> (which gets the packet through recvfrom so there isn't >>>>>> > >> really any slot index) ? >>>>>> > >> >>>>>> > > It works in the other way: >>>>>> > > The bridge.c checks the seq numbers of the udp packets in netmap >>>>>> > > slots >>>>>> > (in >>>>>> > > nic rx ring) before the swap; then it records the seq number, slot >>>>>> > > number(both rx and tx (tx indexes were not shown in the previous >>>>>> > > email >>>>>> > since >>>>>> > > they all look correct)) and buf_idx (rx and tx). The bridge.c does >>>>>> > > not >>>>>> > > change anything in the buffer and it knows the slot and buf_idx >>>>>> > > that a >>>>>> > > packet uses. Please refer to the added code in *process_rings* >>>>>> > > function >>>>>> > > http://www.owlnet.rice.edu/~xs6/bridge.c >>>>>> > > The receiver.c checks the seq numbers only and print out the seq >>>>>> > > numbers >>>>>> > it >>>>>> > > receive sequentially. >>>>>> > > With these information, I manually match the seq number I got from >>>>>> > > receiver.c and the seq number I got from bridge.c. So we know what >>>>>> > > is the >>>>>> > > seq order the receiver sees and which slot a packet uses when >>>>>> > > bridge.c >>>>>> > swaps >>>>>> > > the buf_idxs. >>>>>> > > >>>>>> > >> Do you see any ordering inversion when the receiver >>>>>> > >> gets packets through the NETMAP API (e.g. using bridge.c >>>>>> > >> instead of receiver.c) ? >>>>>> > >> >>>>>> > > There is no ordering inversion seen by bridge.c (As I said in the >>>>>> > previous >>>>>> > > paragraph, the bridge.c checks the seq number and I did not see >>>>>> > > any order >>>>>> > > inversion in THIS simple experiment (In my multicast protocol >>>>>> > > (mentioned >>>>>> > in >>>>>> > > the first email), there is ordering inversion. But let us solve >>>>>> > > the >>>>>> > simple >>>>>> > > bridge.c's problem first. I think they are two relatively >>>>>> > > independent >>>>>> > > issues.)). >>>>>> > >>>>>> > Sorry there was a misunderstanding. >>>>>> > I wanted you to check the following setup: >>>>>> > >>>>>> > [1: send.c] ->- [2: bridge.c] ->- [3: XYZ] >>>>>> > >>>>>> > where in XYZ you replace your receiver.c with some >>>>>> > netmap-based receiver (it could be pkt-gen in rx mode, >>>>>> > or possibly even another instance of bridge.c where >>>>>> > you connect the output port to a vale switch so >>>>>> > traffic is dropped), and then in XYZ print the content >>>>>> > of the packets. >>>>>> > >>>>>> > From your previous report we know that node 2: sees packets >>>>>> > in order, and node 3: sees packets out of order. >>>>>> > However, if the problem were due to bridge.c sending >>>>>> > the old buffer and not the new one, you'd see not only >>>>>> > reordering but also replication of packets. >>>>>> > >>>>>> > The fact that you see only the reordering in 3: makes >>>>>> > me think that the problem is in that node, and it could >>>>>> > be the network stack in 3: that does something strange. >>>>>> > So if you can run something netmap based in 3: and make >>>>>> > sure there is only one queue to read from, we could >>>>>> > at least figure out what is going on. >>>>>> > >>>>>> > cheers >>>>>> > luigi >>>>>> > >>>>>> > >>>>>> > is that >>>>>> > > >>>>>> > >> >>>>>> > >> Are you using native netmap drivers or the emulated mode ? >>>>>> > >> You can check that by playing with the "admode" sysctl entry >>>>>> > >> (or sysfs on linux) - try setting to 1 and 2 and see if >>>>>> > >> the behaviour changes. >>>>>> > >> >>>>>> > >> dev.netmap.admode: 0 >>>>>> > >> Controls the use of native or emulated adapter mode. >>>>>> > >> 0 uses the best available option, >>>>>> > >> 1 forces native and fails if not available, >>>>>> > >> 2 forces emulated hence never fails. >>>>>> > >> >>>>>> > > I was using admode 0. I changed the admode to 1 and 2 using the >>>>>> > > command >>>>>> > like >>>>>> > > *echo 1 > /sys/module/netmap/parameters/admode* and restart the >>>>>> > > bridge >>>>>> > > program. The behavior keeps the same. >>>>>> > > >>>>>> > >> >>>>>> > >> cheers >>>>>> > >> luigi >>>>>> > >> >>>>>> > >> > >>>>>> > >> > There is really one ring (tx and rx) for NIC and one ring (tx >>>>>> > >> > and rx) >>>>>> > >> > for >>>>>> > >> > the host. >>>>>> > >> > I also doubt that there might be multiple tx rings for the >>>>>> > >> > host. It >>>>>> > >> > seems >>>>>> > >> > like that bridge program swap packet to multiple host rings and >>>>>> > >> > the >>>>>> > udp >>>>>> > >> > recv >>>>>> > >> > program drains packets from these rings. But this is not the >>>>>> > >> > case >>>>>> > here. >>>>>> > >> > >>>>>> > >> > The bridge program prints a line like this >>>>>> > >> > *515.277263 main [277] Ready to go, eth3 0x1/1 <-> eth3 0x0/1.* >>>>>> > >> > this is printed by the following line the original program >>>>>> > >> > *D("Ready to go, %s 0x%x/%d <-> %s 0x%x/%d.", pa->req.nr_name, >>>>>> > >> > pa->first_rx_ring, pa->req.nr_rx_rings, pb->req.nr_name, >>>>>> > >> > pb->first_rx_ring, >>>>>> > >> > pb->req.nr_rx_rings);* >>>>>> > >> > >>>>>> > >> > I think this shows that there is really one NIC ring and one >>>>>> > >> > HOST >>>>>> > ring. >>>>>> > >> > >>>>>> > >> > Is there another way to verify the number of ring that netmap >>>>>> > >> > has? >>>>>> > >> > >>>>>> > >> > Thanks! >>>>>> > >> > Xiaoye >>>>>> > >> > >>>>>> > >> > On Mon, Feb 1, 2016 at 10:48 PM, Luigi Rizzo >>>>>> > >> > >>>>>> > wrote: >>>>>> > >> >> >>>>>> > >> >> Hi, >>>>>> > >> >> there must be some wrong with your setting because >>>>>> > >> >> slot indexes must be sequential and in your case they >>>>>> > >> >> are not (see the jump from 295 to 474 and then >>>>>> > >> >> back from 485 to 296, and the numerous interleavings >>>>>> > >> >> that you are seeing later). >>>>>> > >> >> >>>>>> > >> >> I have no idea of the cause but typically this pattern >>>>>> > >> >> is what you see when there are multiple input rings and >>>>>> > >> >> not just one. >>>>>> > >> >> >>>>>> > >> >> Cheers >>>>>> > >> >> Luigi >>>>>> > >> >> >>>>>> > >> >> >>>>>> > >> >> >>>>>> > >> >> >>>>>> > >> >> On Tue, Feb 2, 2016 at 12:24 AM, Xiaoye Sun >>>>>> > >> >> >>>>>> > >> >> wrote: >>>>>> > >> >> > Hi Luigi, >>>>>> > >> >> > >>>>>> > >> >> > Thanks for the detailed advice. >>>>>> > >> >> > >>>>>> > >> >> > With more detailed experiments, actually I found that the >>>>>> > >> >> > udp >>>>>> > >> >> > sender/receiver packet reorder issue *might* be irrelevant >>>>>> > >> >> > to the >>>>>> > >> >> > original >>>>>> > >> >> > issue I posted. However, I think we should solve the udp >>>>>> > >> >> > sender/receiver >>>>>> > >> >> > issue first. >>>>>> > >> >> > I run the experiment with more detailed log. Here is my >>>>>> > >> >> > findings. >>>>>> > >> >> > >>>>>> > >> >> > 1. I am running a netmap version available since about Oct >>>>>> > >> >> > 13rd >>>>>> > from >>>>>> > >> >> > github >>>>>> > >> >> > (https://github.com/luigirizzo/netmap). So I think this is >>>>>> > >> >> > not the >>>>>> > >> >> > one >>>>>> > >> >> > related to the buffer allocation issue. I tried to running >>>>>> > >> >> > the >>>>>> > newest >>>>>> > >> >> > version, however, that version causes problem when I exit >>>>>> > >> >> > the >>>>>> > bridge >>>>>> > >> >> > program >>>>>> > >> >> > (something like kernel error which make the os crash). >>>>>> > >> >> > >>>>>> > >> >> > 2 & 3. I changed the receiver.c & bridge.c so that I can get >>>>>> > >> >> > more >>>>>> > >> >> > information (more detailed log). >>>>>> > >> >> > The reorder happens multiple times (about 10 times) within a >>>>>> > second. >>>>>> > >> >> > Here is >>>>>> > >> >> > one example trace collected from the above two programs. >>>>>> > (remembering >>>>>> > >> >> > that >>>>>> > >> >> > we have udp sender running on one machine; netmap bridge and >>>>>> > >> >> > udp >>>>>> > >> >> > receiver >>>>>> > >> >> > are running on another machine). >>>>>> > >> >> > There is only one pair of rings each with 512 slots (511 >>>>>> > >> >> > slot >>>>>> > usable) >>>>>> > >> >> > on >>>>>> > >> >> > the >>>>>> > >> >> > receiver machine. >>>>>> > >> >> > >>>>>> > >> >> > =================== packet trace collected from receiver.c >>>>>> > >> >> > =================== >>>>>> > >> >> > ===== together with the slot and buf_idx of the >>>>>> > >> >> > corresponding >>>>>> > netmap >>>>>> > >> >> > ring >>>>>> > >> >> > slots ====== >>>>>> > >> >> > [seq] [slot] [buf_idx] >>>>>> > >> >> > 8208 294 1833 >>>>>> > >> >> > 8209 295 1834 >>>>>> > >> >> > 8388 474 2013 >>>>>> > >> >> > ... (packet received in order) >>>>>> > >> >> > 8398 484 2023 >>>>>> > >> >> > 8399 485 2024 >>>>>> > >> >> > 8210 296 1835 >>>>>> > >> >> > 8211 297 1836 >>>>>> > >> >> > ... (packet received in order) >>>>>> > >> >> > ... >>>>>> > >> >> > 8222 308 1847 >>>>>> > >> >> > 8400 486 2025 >>>>>> > >> >> > 8223 309 1848 >>>>>> > >> >> > 8401 487 2026 >>>>>> > >> >> > 8224 310 1849 >>>>>> > >> >> > 8402 488 2027 >>>>>> > >> >> > 8225 311 1850 >>>>>> > >> >> > 8403 489 2028 >>>>>> > >> >> > 8226 312 1851 >>>>>> > >> >> > 8404 450 2029 >>>>>> > >> >> > 8227 313 1852 >>>>>> > >> >> > 8228 314 1853 >>>>>> > >> >> > >>>>>> > >> >> > =================================================================== >>>>>> > >> >> > As we can see that the udp receiver got packet 8210 after it >>>>>> > >> >> > got >>>>>> > >> >> > 8399, >>>>>> > >> >> > which >>>>>> > >> >> > is the first reorder. Then, the receiver got 8211 to 8222 >>>>>> > >> >> > sequentially. >>>>>> > >> >> > Then >>>>>> > >> >> > it got packet from 8223-8227 and 8400-8404 interleaved. >>>>>> > >> >> > >>>>>> > >> >> > >>>>>> > >> >> > ==================== event order seen by netmap bridge >>>>>> > >> >> > ================== >>>>>> > >> >> > get 8209 >>>>>> > >> >> > poll called >>>>>> > >> >> > get 8210 >>>>>> > >> >> > ... >>>>>> > >> >> > ... >>>>>> > >> >> > get 8228 >>>>>> > >> >> > poll called >>>>>> > >> >> > get 8229 >>>>>> > >> >> > ... >>>>>> > >> >> > ... >>>>>> > >> >> > get 8383 >>>>>> > >> >> > poll called >>>>>> > >> >> > get 8384 >>>>>> > >> >> > ... >>>>>> > >> >> > get 8387 >>>>>> > >> >> > poll called >>>>>> > >> >> > get 8388 >>>>>> > >> >> > ... >>>>>> > >> >> > get 8393 >>>>>> > >> >> > poll called >>>>>> > >> >> > get 8394 >>>>>> > >> >> > ... >>>>>> > >> >> > get 8399 >>>>>> > >> >> > poll called >>>>>> > >> >> > get 8400 >>>>>> > >> >> > ... >>>>>> > >> >> > get 8404 >>>>>> > >> >> > poll called >>>>>> > >> >> > get 8405 >>>>>> > >> >> > >>>>>> > >> >> > =================================================================== >>>>>> > >> >> > As we can see, from the event ordering see by the bridge.c, >>>>>> > >> >> > all the >>>>>> > >> >> > packets >>>>>> > >> >> > are receiver in order, which means the the reorder happens >>>>>> > >> >> > when the >>>>>> > >> >> > bridge >>>>>> > >> >> > code swap the buf_idx between the nic ring(slot) and the >>>>>> > >> >> > host >>>>>> > >> >> > ring(slot). >>>>>> > >> >> > The reordered seq usually right before or after the poll >>>>>> > >> >> > function >>>>>> > >> >> > call. >>>>>> > >> >> > >>>>>> > >> >> > Best, >>>>>> > >> >> > Xiaoye >>>>>> > >> >> > >>>>>> > >> >> > >>>>>> > >> >> > >>>>>> > >> >> > >>>>>> > >> >> > >>>>>> > >> >> > >>>>>> > >> >> > >>>>>> > >> >> > >>>>>> > >> >> > On Fri, Jan 29, 2016 at 4:27 PM, Luigi Rizzo >>>>>> > >> >> > >>>>>> > >> >> > wrote: >>>>>> > >> >> >> >>>>>> > >> >> >> On Fri, Jan 29, 2016 at 2:12 PM, Xiaoye Sun >>>>>> > >> >> >> >>>>>> > >> >> >> wrote: >>>>>> > >> >> >> > Hi Luigi, >>>>>> > >> >> >> > >>>>>> > >> >> >> > Thanks for your advice. >>>>>> > >> >> >> > I forgot to mention that I use the command "ethtool -L >>>>>> > >> >> >> > eth1 >>>>>> > >> >> >> > combined >>>>>> > >> >> >> > 1" >>>>>> > >> >> >> > to >>>>>> > >> >> >> > set the number of rings of the nic to 1. The host also >>>>>> > >> >> >> > only has >>>>>> > >> >> >> > one >>>>>> > >> >> >> > ring. >>>>>> > >> >> >> > I understand the situation where the first tx ring is >>>>>> > >> >> >> > full so >>>>>> > the >>>>>> > >> >> >> > bridge >>>>>> > >> >> >> > will swap the packets to the second tx ring and then the >>>>>> > host/nic >>>>>> > >> >> >> > might >>>>>> > >> >> >> > drain either rings. But this is not the case in the >>>>>> > >> >> >> > experiment. >>>>>> > >> >> >> >>>>>> > >> >> >> ok good to know that. >>>>>> > >> >> >> >>>>>> > >> >> >> So if we have ruled out multiqueue and iommu, let's look at >>>>>> > >> >> >> the internal allocator and at bridge.c >>>>>> > >> >> >> >>>>>> > >> >> >> 1. are you running the most recent version of netmap ? >>>>>> > >> >> >> Some older version (probably 1-2 years ago) had a bug >>>>>> > >> >> >> in the buffer allocator and some buffers were allocated >>>>>> > >> >> >> twice. >>>>>> > >> >> >> >>>>>> > >> >> >> 2. can you tweak your receiver.c to report some more info >>>>>> > >> >> >> on how often you get out of sequence packets, how much >>>>>> > >> >> >> out of sequence they are ? >>>>>> > >> >> >> Also it would be useful to report gaps on the increasing >>>>>> > >> >> >> side >>>>>> > >> >> >> (i.e. new_seq != old_seq +1 ) >>>>>> > >> >> >> >>>>>> > >> >> >> 3. can you tweak bridge.c so that it writes into the packet >>>>>> > >> >> >> the netmap buffer indexes and slots on the rx and tx >>>>>> > >> >> >> side, >>>>>> > >> >> >> so when you detect a sequence error we can figure out >>>>>> > >> >> >> where it is happening. >>>>>> > >> >> >> Ideally you could also add the sequence number detection >>>>>> > >> >> >> code in bridge.c so we can check whether the errors >>>>>> > >> >> >> appear >>>>>> > >> >> >> on the input or output sides. >>>>>> > >> >> >> >>>>>> > >> >> >> cheers >>>>>> > >> >> >> luigi >>>>>> > >> >> >> >>>>>> > >> >> > >>>>>> > >> >> >>>>>> > >> >> >>>>>> > >> >> >>>>>> > >> >> -- >>>>>> > >> >> >>>>>> > >> >> >>>>>> > >>>>>> > -----------------------------------------+------------------------------- >>>>>> > >> >> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. >>>>>> > >> >> dell'Informazione >>>>>> > >> >> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa >>>>>> > >> >> TEL +39-050-2217533 . via Diotisalvi 2 >>>>>> > >> >> Mobile +39-338-6809875 . 56122 PISA (Italy) >>>>>> > >> >> >>>>>> > >> >> >>>>>> > >>>>>> > -----------------------------------------+------------------------------- >>>>>> > >> >> >>>>>> > >> > >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> -- >>>>>> > >> >>>>>> > >>>>>> > -----------------------------------------+------------------------------- >>>>>> > >> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. >>>>>> > dell'Informazione >>>>>> > >> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa >>>>>> > >> TEL +39-050-2217533 . via Diotisalvi 2 >>>>>> > >> Mobile +39-338-6809875 . 56122 PISA (Italy) >>>>>> > >> >>>>>> > >>>>>> > -----------------------------------------+------------------------------- >>>>>> > >> >>>>>> > > >>>>>> > >>>>>> > >>>>>> > >>>>>> > -- >>>>>> > >>>>>> > -----------------------------------------+------------------------------- >>>>>> > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. >>>>>> > dell'Informazione >>>>>> > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa >>>>>> > TEL +39-050-2217533 . via Diotisalvi 2 >>>>>> > Mobile +39-338-6809875 . 56122 PISA (Italy) >>>>>> > >>>>>> > -----------------------------------------+------------------------------- >>>>>> > >>>>>> > >>>>>> _______________________________________________ >>>>>> 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" >>> >>> >> > -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2217533 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@freebsd.org Wed Feb 10 14:18:16 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AD332AA4D4F for ; Wed, 10 Feb 2016 14:18:16 +0000 (UTC) (envelope-from voltagex@voltagex.org) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::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 77B7B1BB6 for ; Wed, 10 Feb 2016 14:18:16 +0000 (UTC) (envelope-from voltagex@voltagex.org) Received: by mail-qg0-x235.google.com with SMTP id y9so14274309qgd.3 for ; Wed, 10 Feb 2016 06:18:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voltagex-org.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=pzzY2yYW8KJO2djtE22wc7uHwuWGMAfRWzIuEo1ZUGE=; b=ctwN2A+RNIllRnV/evW6HrPCJowl8ioLWdToj6o/92rRT6o7qtSpcQyti+GdOqOkR9 Wz0kcCacqS+f2jI+OrE3fwwWfAcDhqxNE+L6jJ46WKzMGW1LtaFjzcHnRT7pq9oo8WQN 8WhjxVfiVbnMZxk/XoB4YvYvvSmMJVolX4KjDQZzvdpXS5CvqFjzqZcRE0egLokITlzH Tc9Mav10Gua6/rq2MSLVhuVCywKIrPmPVnQvwwJnyHfmS7IgXXq/KhsESCzBP8xtCwmT 45z1PNyPxvBJcmTpa+si0pWzs+L/ttyg6p7xfu07kkf0b0wYptYNFZ8PhJuA89D1p+KS ob3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=pzzY2yYW8KJO2djtE22wc7uHwuWGMAfRWzIuEo1ZUGE=; b=YQSP0agGwSNzfQdWiIvoL9lbz/nbQH8iEvRfo7/ad3esu3vgSKBKng+1TMpSsvMbsJ 1U22RqNQtHbsRIuWVcphq9vsRsgvyjA37giWDYop5z1tBfd1+oIbRgI3Xj+g+bp/RDJa JgwPhNG8Lt7CL/5U9GFXOvpbbJsiLlgmy6vio+3NoGT81SNp7ZQ4xUVKF3xlQu4hQr+j bITxR4IZXyajJVC6b61X9g2YflevCD1QO6tWLR54cBaG0aaPcMjhRvkDt9KIUsaeum4k ShSjT1nG2RxH7Hd+QZ6l7NqfbnPtBrgvq7BNnvZ2ZFCCSqCHq0QY6YSX7zUW4+ze0C2C 6CHg== X-Gm-Message-State: AG10YOTUzCiIroEXUZqxF1/sHe5IrY1hSjKosAMJ4h3WYApIowHQdTbfQS/BoLTZtjaimZXbKcunmAYbAytDwQ== MIME-Version: 1.0 X-Received: by 10.140.142.134 with SMTP id 128mr52336314qho.62.1455113895036; Wed, 10 Feb 2016 06:18:15 -0800 (PST) Received: by 10.55.119.196 with HTTP; Wed, 10 Feb 2016 06:18:14 -0800 (PST) Date: Thu, 11 Feb 2016 01:18:14 +1100 Message-ID: Subject: Slow performance in high latency situation on FreeNAS / FreeBSD 9 From: Adam Baxter To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 14:18:16 -0000 Hi all, I've got a new FreeNAS 9.3 box which is getting very, very slow transfers once the latency of the remote host goes over 200ms. The system is based on a SuperMicro A1SRi-2758F board - see http://www.supermicro.com/products/motherboard/Atom/X10/A1SRi-2758F.cfm. FreeNAS boots fine on it once you tell it to load the xhci driver on boot. uname -a says FreeBSD freenas.local 9.3-RELEASE-p31 FreeBSD 9.3-RELEASE-p31 #0 r288272+33bb475: Wed Feb 3 02:19:35 PST 2016 root@build3.ixsystems.com:/tank/home/stable-builds/FN/objs/os-base/amd64/tank/home/stable-builds/FN/FreeBSD/src/sys/FREENAS.amd64 amd64 The network card is new to me, apparently it's an Intel i354 / C2000 integrated thing - there are 4 gigabit ports on the back of the machine and a 5th for IPMI. I realise I'm limiting myself by staying on an OS based on FreeBSD 9 but I don't feel confident enough with FreeBSD to jump to 10 yet. Please let me know if I've missed any critical information out. the iperf server was a Linux VM on a Windows host, VirtualBox bridged interface to a Broadcom NIC. 0.5ms latency - standard LAN transfer to FreeNAS [ 3] local 10.1.1.2 port 40116 connected with 10.1.1.111 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 1.01 GBytes 871 Mbits/sec Which looks fine-ish The problem occurs when I crank up the latency (using tc qdisc on the VM). This matches the transfer rates I see from remote hosts once the latency hits 200-300ms (common for Australia->UK) 300ms simulated latency - Linux VM -> FreeNAS [voltagex@freenas ~]$ iperf -c 10.1.1.111 ------------------------------------------------------------ Client connecting to 10.1.1.111, TCP port 5001 TCP window size: 32.5 KByte (default) ------------------------------------------------------------ [ 3] local 10.1.1.2 port 33023 connected with 10.1.1.111 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.3 sec 3.75 MBytes 3.06 Mbits/sec Whereas Linux VM -> Linux VM fares quite a lot better, even with the added latency: voltagex@devbox:~$ iperf -c 10.1.1.111 ------------------------------------------------------------ Client connecting to 10.1.1.111, TCP port 5001 TCP window size: 85.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.1.1.112 port 51790 connected with 10.1.1.111 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 23.5 MBytes 19.6 Mbits/sec Cranking up the window size on FreeNAS/FreeBSD doesn't seem to help, either. [voltagex@freenas ~]$ iperf -w 85k -c 10.1.1.111 ------------------------------------------------------------ Client connecting to 10.1.1.111, TCP port 5001 TCP window size: 86.3 KByte (WARNING: requested 85.0 KByte) ------------------------------------------------------------ [ 3] local 10.1.1.2 port 15033 connected with 10.1.1.111 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.6 sec 2.38 MBytes 1.88 Mbits/sec I also tried booting the machine from a LiveCD of Ubuntu 15.10 - the numbers are what you expect, except when capturing the no-latency test with tshark, the throughput dropped to around 200 megabits. With simulated latency: ubuntu@ubuntu:~$ iperf -c 10.1.1.115 ------------------------------------------------------------ Client connecting to 10.1.1.115, TCP port 5001 TCP window size: 85.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.1.1.2 port 56184 connected with 10.1.1.115 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.4 sec 16.0 MBytes 12.9 Mbits/sec Without simulated latency + tshark running: [ 3] local 10.1.1.2 port 56192 connected with 10.1.1.115 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 250 MBytes 209 Mbits/sec "Normal" throughput in Ubuntu is about 730 megabits. The info I can pull from the card itself: igb0: port 0xe0c0-0xe0df mem 0xdf260000-0xdf27ffff,0xdf30c000-0xdf30ffff irq 20 at device 20.0 on pci0 igb0: Using MSIX interrupts with 9 vectors igb0: Ethernet address: 0c:c4:7a:6b:bf:34 igb0: Bound queue 0 to cpu 0 igb0: Bound queue 1 to cpu 1 igb0: Bound queue 2 to cpu 2 igb0: Bound queue 3 to cpu 3 igb0: Bound queue 4 to cpu 4 igb0: Bound queue 5 to cpu 5 igb0: Bound queue 6 to cpu 6 igb0: Bound queue 7 to cpu 7 igb0: promiscuous mode enabled igb0: link state changed to DOWN igb0: link state changed to UP igb0@pci0:0:20:0: class=0x020000 card=0x1f4115d9 chip=0x1f418086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet I am not running pf (yet) and running 'ifconfig igb0 -tso' seemed to have no impact. I have not yet had a chance to try FreeBSD 10 in live mode. Packet captures are available at http://static.voltagex.org/freebsd-troubleshooting/iperf.tar.xz in pcapng format (unpacks to about 750MB, sorry!) Thanks in advance, Adam From owner-freebsd-net@freebsd.org Wed Feb 10 16:18:55 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 947A0AA4721 for ; Wed, 10 Feb 2016 16:18:55 +0000 (UTC) (envelope-from sunxiaoye07@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 5C67D1E65 for ; Wed, 10 Feb 2016 16:18:55 +0000 (UTC) (envelope-from sunxiaoye07@gmail.com) Received: by mail-io0-x22d.google.com with SMTP id 9so26365694iom.1 for ; Wed, 10 Feb 2016 08:18:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=7YQ4pZditeml0B/hxbVxI8lqM5SH40Xm5RlXLCFDfsY=; b=vr7vnhz+NmGQ/cUGih/U3KkaCLhgbep+DGEV8PlAZ55N9fNKREc7nbuop2fOtPCcBh /QhgAFjFGIh7qjItSpG9F/hTwPdpZchsl4RXbsWU6gvt47Xo08wyvTkmh8EwVetMD6GI otvcsjYoSHx8JqSjSfCewo0mgzv+D3GJ/ZqjGZRtGMPxyKMp04VhybEJNGPHpVH0iBJe yTYIQtey5vTykSLk/LvkLrd5p8oPUq4Sk/VqgSHwRvRjQ368tPKxRaAp+AoY9gB3jVvr /ZwduBRHhxinKJcnpaEYF6d1U5Xj3LpHBC4eesLgFumlnDreRwnoCz1ESvrDWqQW4LNu QkCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rice-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=7YQ4pZditeml0B/hxbVxI8lqM5SH40Xm5RlXLCFDfsY=; b=rDk+y3Z87XEFH1GM9LKAHQl7V/PiuI9XqYeo+ApWLyRRmgtaW6iudrC1ci4whUa7nk kckLPa2JodChfwpeN7Gl+hVy2hKYRB/d515Tm35aoCZPit751VBK4SVUwcZ3Av4ltfnG JhqNMzfmiy+1lWeeCHIygB/WQED60+vXAL0DFOXkM2OjVarGOzWx2qKQJJ3/F6E+B6lT 3iC188c2LIr3TOz299ZHmLuk+p0te6g3BtJhqWdp1IGcKZG4dr0eAkkq4n2hX6kSP1T2 lHH9yAsW+JQiN76RNGh3+6DRBKqy17sJDsYCHQA8Xq6pfxoaABkk6MXk+kFF5/Bob9tL X78g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7YQ4pZditeml0B/hxbVxI8lqM5SH40Xm5RlXLCFDfsY=; b=UHkTTjDek5X3Id/dUhojgQIx/zorqH9P1qvT9sH/zmN5tgw6rk42f86EoiBQxQ8e8x ROTihhytbiSk5pWM9AIOIil3L7UY90rvqyo4UuyEaFaGkcFRvanwuU7Vc8IUgbaKNC1L 3AfPQ6jIxuwp+iXQCKG73Y107BrtWnFh47/bCTQElaBVukQS/9GRkZQpqVVpsisBV8KP 4EW9KQ57EjK5+2M27bx9yY8/0YJOFz0gPffwLaEqcrUr1k6du5F4TBrIRi1R4v5CH0kb MFe+Fy7kW2dqmTB99MKlBdtvFFXo9qCGUXgAcvLFrLeYns4bVOKnX0n1eC1D27FW+Ik3 t/nw== X-Gm-Message-State: AG10YOSP8zWF3Tl1FXj2rvhKNcugP+jwMzjUZ8jHV1ARvJC6NWtjbZxJtpjNgYp7IeyMkVk7gADyEyv8CzKJ1w== MIME-Version: 1.0 X-Received: by 10.107.39.78 with SMTP id n75mr40330253ion.14.1455121134432; Wed, 10 Feb 2016 08:18:54 -0800 (PST) Sender: sunxiaoye07@gmail.com Received: by 10.36.98.82 with HTTP; Wed, 10 Feb 2016 08:18:54 -0800 (PST) In-Reply-To: References: Date: Wed, 10 Feb 2016 10:18:54 -0600 X-Google-Sender-Auth: sz0omxNMn6W1oHmGmUNDAl87Sf4 Message-ID: Subject: Re: swaping ring slots between NIC ring and Host ring does not always success From: Xiaoye Sun To: Luigi Rizzo Cc: Victor Detoni , Pavel Odintsov , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 16:18:55 -0000 Hi Luigi, Thanks Luigi! Pinning the process to one CPU core solves the reorder problem!!! Let me check if the duplicated packet problem is solved also. Thanks! Best, Xiaoye On Wed, Feb 10, 2016 at 7:21 AM, Luigi Rizzo wrote: > On Tue, Feb 9, 2016 at 1:12 PM, Xiaoye Sun wrote: > > Hi Luigi, > > > > Have you seen the previous email. any comments? > > Hi, > to summarize, you are seeing reordering when > reinjecting packets into the host stack from bridge.c > > On Linux, the NIOCTXSYNC towards the host stack calls netif_rx() one > packet at a time (on freebsd that would be ifp->if_input()), and > the calls are synchronous. > > In order to get reordering, you should have the following > sequence of events: > > 1. bridge.c calls ioctl(NIOCTXSYNC) > 2. netif_rx() queues packet instead of dispatching them to the socket > 3. bridge.c builds another batch and calls ioctl(NIOCTXSYNC) > 4. netif_rx() passes packets to the socket overtaking those in #2 > > I don't know whether netif_rx() can defer > processing and how to prevent that. > If this is the problem, > one thing you could try is pin the bridge process > to a specific core and see if that makes the problem > disappear. > > cheers > luigi > > > > > On Fri, Feb 5, 2016 at 3:29 PM, Xiaoye Sun wrote: > >> > >> Hi Victor, > >> Thanks for the help. The command you provided worked perfectly for me. > >> > >> Hi Luigi, > >> > >> Thanks for your clarification. > >> > >> The experiment I did was NOT running on 3 nodes. They ran on two nodes. > >> node 1 ran [1. sender]; node 2 ran [2. bridge.c] and [3. receiver (not > using > >> netmap)]; [2. bridge.c ] saw packets inorder. [3. receiver] saw packets > >> out-of-order. I saw replication packets (even corrupted packets) in the > >> setup I mentioned in my first email in this threads. I did not see > >> replication packet in the sender-bridge-receiver setup. Let's solve the > >> reorder problem first and then solve the replication packet problem. > >> > >> I also tried the experiment setup having 3 nodes running sender, bridge, > >> receiver( both non-netmap based and netmap based XYZ) respectively. In > the 3 > >> nodes experiment, there is NO packet reorder no any node. The difference > >> between the 2 nodes experiment and the 3 nodes experiment is that in the > >> bridge of node 2 in the 2-nodes experiment the bridge interact with the > host > >> stack, while netmap does not interact with host stack in the 3-node > >> experiment. > >> > >> This makes me make the conclusion that there might be some problem with > >> the interaction between netmap and host stack. What is your opinion? > >> > >> Thanks! > >> > >> Xiaoye > >> > >> On Thu, Feb 4, 2016 at 6:26 PM, Victor Detoni > >> wrote: > >>> > >>> I'm sorry, I made mistake. To workaround this try `ip link set $IFACE > >>> promisc on` > >>> > >>> > >>> > >>> On Thu, Feb 4, 2016 at 10:04 PM, Xiaoye Sun > wrote: > >>>> > >>>> Yes. all the interfaces are up. Are you able to get ARP request when > the > >>>> interfaces are down? > >>>> > >>>> > >>>> On Thursday, February 4, 2016, Victor Detoni > >>>> wrote: > >>>>> > >>>>> Both interfaces are up? Like ifconfig... up > >>>>> > >>>>> I had this the same problem and I solve with commands above > >>>>> > >>>>> Em quinta-feira, 4 de fevereiro de 2016, Xiaoye Sun > >>>>> escreveu: > >>>>>> > >>>>>> Hi Luigi, > >>>>>> > >>>>>> Thanks for your explanation. > >>>>>> > >>>>>> I used three machines to do this experiment. They are directly > >>>>>> connected. > >>>>>> > >>>>>> [(machine1) eth1]---[eth2 (machine2) eth3]---[eth4 (machine3)]. > >>>>>> > >>>>>> First, I tried to run bridge.c on machine2 using the command *bridge > >>>>>> -i > >>>>>> netmap:eth2 -i netmap:eth3*. (sender receiver or XYZ were not > running > >>>>>> on > >>>>>> machine 1or3) > >>>>>> > >>>>>> For my understanding, in this setup, machine2 will be transparent to > >>>>>> machine1&3 since it forwards packet from its eth2 to eth3 and vice > >>>>>> versa > >>>>>> without any modification to the packets. > >>>>>> > >>>>>> I tried to ping machine 3 from machine 1 using the command like > *ping > >>>>>> 10.11.10.3*. However, it still does not success. > >>>>>> This is because that before machine1 sends ping message to machine3, > >>>>>> it > >>>>>> will first send a ARP request message to get the mac address of > >>>>>> machine3. > >>>>>> machine3 gets that ARP request, and send the reply back (I use > tcpdump > >>>>>> to > >>>>>> verify that machine3 gets the ARP request and send out the ARP > reply). > >>>>>> However, machine1 does not get the ARP reply. > >>>>>> > >>>>>> I checked that the bridge can only forwarding packet in one > direction > >>>>>> at > >>>>>> the same time. it gets the ARP request but doesn't see the ARP reply > >>>>>> (*pkt_queued* always returns 0 for one nic...). > >>>>>> > >>>>>> This behavior looks very weird to me. Do you think there is a > >>>>>> compatibility > >>>>>> issues between netmap and the os I am using? Is there a verified > linux > >>>>>> distribution (also the version) that perfectly works well with > netmap? > >>>>>> > >>>>>> The OS I use is 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 > >>>>>> (2015-05-24) > >>>>>> x86_64 GNU/Linux. > >>>>>> Linux kernel version is *3.16.0-4-amd64* > >>>>>> > >>>>>> > >>>>>> Thanks! > >>>>>> Xiaoye > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Wed, Feb 3, 2016 at 2:12 AM, Luigi Rizzo > >>>>>> wrote: > >>>>>> > >>>>>> > On Tue, Feb 2, 2016 at 10:48 PM, Xiaoye Sun > >>>>>> > wrote: > >>>>>> > > > >>>>>> > > > >>>>>> > > On Mon, Feb 1, 2016 at 11:34 PM, Luigi Rizzo < > rizzo@iet.unipi.it> > >>>>>> > > wrote: > >>>>>> > >> > >>>>>> > >> On Tue, Feb 2, 2016 at 6:23 AM, Xiaoye Sun < > Xiaoye.Sun@rice.edu> > >>>>>> > >> wrote: > >>>>>> > >> > Hi Luigi, > >>>>>> > >> > > >>>>>> > >> > I have to clarify about the *jumping issue* about the slot > >>>>>> > >> > indexes. > >>>>>> > >> > In the bridge.c program, the slot index never jumps and it > >>>>>> > >> > increases > >>>>>> > >> > sequentially. > >>>>>> > >> > In the receiver.c program, the udp packet seq jumps and I > >>>>>> > >> > showed the > >>>>>> > >> > slot > >>>>>> > >> > index that each udp packet uses. So the slot index jumps > >>>>>> > >> > together with > >>>>>> > >> > the > >>>>>> > >> > udp seq (at the receiver program only). > >>>>>> > >> > >>>>>> > >> So let me understand, is the "slot" some information written > >>>>>> > >> in the packet by bridge.c (referring to the rx or tx slot, > >>>>>> > >> I am not sure) and then read and printed by receiver.c > >>>>>> > >> (which gets the packet through recvfrom so there isn't > >>>>>> > >> really any slot index) ? > >>>>>> > >> > >>>>>> > > It works in the other way: > >>>>>> > > The bridge.c checks the seq numbers of the udp packets in netmap > >>>>>> > > slots > >>>>>> > (in > >>>>>> > > nic rx ring) before the swap; then it records the seq number, > slot > >>>>>> > > number(both rx and tx (tx indexes were not shown in the previous > >>>>>> > > email > >>>>>> > since > >>>>>> > > they all look correct)) and buf_idx (rx and tx). The bridge.c > does > >>>>>> > > not > >>>>>> > > change anything in the buffer and it knows the slot and buf_idx > >>>>>> > > that a > >>>>>> > > packet uses. Please refer to the added code in *process_rings* > >>>>>> > > function > >>>>>> > > http://www.owlnet.rice.edu/~xs6/bridge.c > >>>>>> > > The receiver.c checks the seq numbers only and print out the seq > >>>>>> > > numbers > >>>>>> > it > >>>>>> > > receive sequentially. > >>>>>> > > With these information, I manually match the seq number I got > from > >>>>>> > > receiver.c and the seq number I got from bridge.c. So we know > what > >>>>>> > > is the > >>>>>> > > seq order the receiver sees and which slot a packet uses when > >>>>>> > > bridge.c > >>>>>> > swaps > >>>>>> > > the buf_idxs. > >>>>>> > > > >>>>>> > >> Do you see any ordering inversion when the receiver > >>>>>> > >> gets packets through the NETMAP API (e.g. using bridge.c > >>>>>> > >> instead of receiver.c) ? > >>>>>> > >> > >>>>>> > > There is no ordering inversion seen by bridge.c (As I said in > the > >>>>>> > previous > >>>>>> > > paragraph, the bridge.c checks the seq number and I did not see > >>>>>> > > any order > >>>>>> > > inversion in THIS simple experiment (In my multicast protocol > >>>>>> > > (mentioned > >>>>>> > in > >>>>>> > > the first email), there is ordering inversion. But let us solve > >>>>>> > > the > >>>>>> > simple > >>>>>> > > bridge.c's problem first. I think they are two relatively > >>>>>> > > independent > >>>>>> > > issues.)). > >>>>>> > > >>>>>> > Sorry there was a misunderstanding. > >>>>>> > I wanted you to check the following setup: > >>>>>> > > >>>>>> > [1: send.c] ->- [2: bridge.c] ->- [3: XYZ] > >>>>>> > > >>>>>> > where in XYZ you replace your receiver.c with some > >>>>>> > netmap-based receiver (it could be pkt-gen in rx mode, > >>>>>> > or possibly even another instance of bridge.c where > >>>>>> > you connect the output port to a vale switch so > >>>>>> > traffic is dropped), and then in XYZ print the content > >>>>>> > of the packets. > >>>>>> > > >>>>>> > From your previous report we know that node 2: sees packets > >>>>>> > in order, and node 3: sees packets out of order. > >>>>>> > However, if the problem were due to bridge.c sending > >>>>>> > the old buffer and not the new one, you'd see not only > >>>>>> > reordering but also replication of packets. > >>>>>> > > >>>>>> > The fact that you see only the reordering in 3: makes > >>>>>> > me think that the problem is in that node, and it could > >>>>>> > be the network stack in 3: that does something strange. > >>>>>> > So if you can run something netmap based in 3: and make > >>>>>> > sure there is only one queue to read from, we could > >>>>>> > at least figure out what is going on. > >>>>>> > > >>>>>> > cheers > >>>>>> > luigi > >>>>>> > > >>>>>> > > >>>>>> > is that > >>>>>> > > > >>>>>> > >> > >>>>>> > >> Are you using native netmap drivers or the emulated mode ? > >>>>>> > >> You can check that by playing with the "admode" sysctl entry > >>>>>> > >> (or sysfs on linux) - try setting to 1 and 2 and see if > >>>>>> > >> the behaviour changes. > >>>>>> > >> > >>>>>> > >> dev.netmap.admode: 0 > >>>>>> > >> Controls the use of native or emulated adapter > mode. > >>>>>> > >> 0 uses the best available option, > >>>>>> > >> 1 forces native and fails if not available, > >>>>>> > >> 2 forces emulated hence never fails. > >>>>>> > >> > >>>>>> > > I was using admode 0. I changed the admode to 1 and 2 using the > >>>>>> > > command > >>>>>> > like > >>>>>> > > *echo 1 > /sys/module/netmap/parameters/admode* and restart the > >>>>>> > > bridge > >>>>>> > > program. The behavior keeps the same. > >>>>>> > > > >>>>>> > >> > >>>>>> > >> cheers > >>>>>> > >> luigi > >>>>>> > >> > >>>>>> > >> > > >>>>>> > >> > There is really one ring (tx and rx) for NIC and one ring (tx > >>>>>> > >> > and rx) > >>>>>> > >> > for > >>>>>> > >> > the host. > >>>>>> > >> > I also doubt that there might be multiple tx rings for the > >>>>>> > >> > host. It > >>>>>> > >> > seems > >>>>>> > >> > like that bridge program swap packet to multiple host rings > and > >>>>>> > >> > the > >>>>>> > udp > >>>>>> > >> > recv > >>>>>> > >> > program drains packets from these rings. But this is not the > >>>>>> > >> > case > >>>>>> > here. > >>>>>> > >> > > >>>>>> > >> > The bridge program prints a line like this > >>>>>> > >> > *515.277263 main [277] Ready to go, eth3 0x1/1 <-> eth3 > 0x0/1.* > >>>>>> > >> > this is printed by the following line the original program > >>>>>> > >> > *D("Ready to go, %s 0x%x/%d <-> %s 0x%x/%d.", > pa->req.nr_name, > >>>>>> > >> > pa->first_rx_ring, pa->req.nr_rx_rings, pb->req.nr_name, > >>>>>> > >> > pb->first_rx_ring, > >>>>>> > >> > pb->req.nr_rx_rings);* > >>>>>> > >> > > >>>>>> > >> > I think this shows that there is really one NIC ring and one > >>>>>> > >> > HOST > >>>>>> > ring. > >>>>>> > >> > > >>>>>> > >> > Is there another way to verify the number of ring that netmap > >>>>>> > >> > has? > >>>>>> > >> > > >>>>>> > >> > Thanks! > >>>>>> > >> > Xiaoye > >>>>>> > >> > > >>>>>> > >> > On Mon, Feb 1, 2016 at 10:48 PM, Luigi Rizzo > >>>>>> > >> > > >>>>>> > wrote: > >>>>>> > >> >> > >>>>>> > >> >> Hi, > >>>>>> > >> >> there must be some wrong with your setting because > >>>>>> > >> >> slot indexes must be sequential and in your case they > >>>>>> > >> >> are not (see the jump from 295 to 474 and then > >>>>>> > >> >> back from 485 to 296, and the numerous interleavings > >>>>>> > >> >> that you are seeing later). > >>>>>> > >> >> > >>>>>> > >> >> I have no idea of the cause but typically this pattern > >>>>>> > >> >> is what you see when there are multiple input rings and > >>>>>> > >> >> not just one. > >>>>>> > >> >> > >>>>>> > >> >> Cheers > >>>>>> > >> >> Luigi > >>>>>> > >> >> > >>>>>> > >> >> > >>>>>> > >> >> > >>>>>> > >> >> > >>>>>> > >> >> On Tue, Feb 2, 2016 at 12:24 AM, Xiaoye Sun > >>>>>> > >> >> > >>>>>> > >> >> wrote: > >>>>>> > >> >> > Hi Luigi, > >>>>>> > >> >> > > >>>>>> > >> >> > Thanks for the detailed advice. > >>>>>> > >> >> > > >>>>>> > >> >> > With more detailed experiments, actually I found that the > >>>>>> > >> >> > udp > >>>>>> > >> >> > sender/receiver packet reorder issue *might* be irrelevant > >>>>>> > >> >> > to the > >>>>>> > >> >> > original > >>>>>> > >> >> > issue I posted. However, I think we should solve the udp > >>>>>> > >> >> > sender/receiver > >>>>>> > >> >> > issue first. > >>>>>> > >> >> > I run the experiment with more detailed log. Here is my > >>>>>> > >> >> > findings. > >>>>>> > >> >> > > >>>>>> > >> >> > 1. I am running a netmap version available since about Oct > >>>>>> > >> >> > 13rd > >>>>>> > from > >>>>>> > >> >> > github > >>>>>> > >> >> > (https://github.com/luigirizzo/netmap). So I think this > is > >>>>>> > >> >> > not the > >>>>>> > >> >> > one > >>>>>> > >> >> > related to the buffer allocation issue. I tried to running > >>>>>> > >> >> > the > >>>>>> > newest > >>>>>> > >> >> > version, however, that version causes problem when I exit > >>>>>> > >> >> > the > >>>>>> > bridge > >>>>>> > >> >> > program > >>>>>> > >> >> > (something like kernel error which make the os crash). > >>>>>> > >> >> > > >>>>>> > >> >> > 2 & 3. I changed the receiver.c & bridge.c so that I can > get > >>>>>> > >> >> > more > >>>>>> > >> >> > information (more detailed log). > >>>>>> > >> >> > The reorder happens multiple times (about 10 times) > within a > >>>>>> > second. > >>>>>> > >> >> > Here is > >>>>>> > >> >> > one example trace collected from the above two programs. > >>>>>> > (remembering > >>>>>> > >> >> > that > >>>>>> > >> >> > we have udp sender running on one machine; netmap bridge > and > >>>>>> > >> >> > udp > >>>>>> > >> >> > receiver > >>>>>> > >> >> > are running on another machine). > >>>>>> > >> >> > There is only one pair of rings each with 512 slots (511 > >>>>>> > >> >> > slot > >>>>>> > usable) > >>>>>> > >> >> > on > >>>>>> > >> >> > the > >>>>>> > >> >> > receiver machine. > >>>>>> > >> >> > > >>>>>> > >> >> > =================== packet trace collected from receiver.c > >>>>>> > >> >> > =================== > >>>>>> > >> >> > ===== together with the slot and buf_idx of the > >>>>>> > >> >> > corresponding > >>>>>> > netmap > >>>>>> > >> >> > ring > >>>>>> > >> >> > slots ====== > >>>>>> > >> >> > [seq] [slot] [buf_idx] > >>>>>> > >> >> > 8208 294 1833 > >>>>>> > >> >> > 8209 295 1834 > >>>>>> > >> >> > 8388 474 2013 > >>>>>> > >> >> > ... (packet received in order) > >>>>>> > >> >> > 8398 484 2023 > >>>>>> > >> >> > 8399 485 2024 > >>>>>> > >> >> > 8210 296 1835 > >>>>>> > >> >> > 8211 297 1836 > >>>>>> > >> >> > ... (packet received in order) > >>>>>> > >> >> > ... > >>>>>> > >> >> > 8222 308 1847 > >>>>>> > >> >> > 8400 486 2025 > >>>>>> > >> >> > 8223 309 1848 > >>>>>> > >> >> > 8401 487 2026 > >>>>>> > >> >> > 8224 310 1849 > >>>>>> > >> >> > 8402 488 2027 > >>>>>> > >> >> > 8225 311 1850 > >>>>>> > >> >> > 8403 489 2028 > >>>>>> > >> >> > 8226 312 1851 > >>>>>> > >> >> > 8404 450 2029 > >>>>>> > >> >> > 8227 313 1852 > >>>>>> > >> >> > 8228 314 1853 > >>>>>> > >> >> > > >>>>>> > >> >> > > =================================================================== > >>>>>> > >> >> > As we can see that the udp receiver got packet 8210 after > it > >>>>>> > >> >> > got > >>>>>> > >> >> > 8399, > >>>>>> > >> >> > which > >>>>>> > >> >> > is the first reorder. Then, the receiver got 8211 to 8222 > >>>>>> > >> >> > sequentially. > >>>>>> > >> >> > Then > >>>>>> > >> >> > it got packet from 8223-8227 and 8400-8404 interleaved. > >>>>>> > >> >> > > >>>>>> > >> >> > > >>>>>> > >> >> > ==================== event order seen by netmap bridge > >>>>>> > >> >> > ================== > >>>>>> > >> >> > get 8209 > >>>>>> > >> >> > poll called > >>>>>> > >> >> > get 8210 > >>>>>> > >> >> > ... > >>>>>> > >> >> > ... > >>>>>> > >> >> > get 8228 > >>>>>> > >> >> > poll called > >>>>>> > >> >> > get 8229 > >>>>>> > >> >> > ... > >>>>>> > >> >> > ... > >>>>>> > >> >> > get 8383 > >>>>>> > >> >> > poll called > >>>>>> > >> >> > get 8384 > >>>>>> > >> >> > ... > >>>>>> > >> >> > get 8387 > >>>>>> > >> >> > poll called > >>>>>> > >> >> > get 8388 > >>>>>> > >> >> > ... > >>>>>> > >> >> > get 8393 > >>>>>> > >> >> > poll called > >>>>>> > >> >> > get 8394 > >>>>>> > >> >> > ... > >>>>>> > >> >> > get 8399 > >>>>>> > >> >> > poll called > >>>>>> > >> >> > get 8400 > >>>>>> > >> >> > ... > >>>>>> > >> >> > get 8404 > >>>>>> > >> >> > poll called > >>>>>> > >> >> > get 8405 > >>>>>> > >> >> > > >>>>>> > >> >> > > =================================================================== > >>>>>> > >> >> > As we can see, from the event ordering see by the > bridge.c, > >>>>>> > >> >> > all the > >>>>>> > >> >> > packets > >>>>>> > >> >> > are receiver in order, which means the the reorder happens > >>>>>> > >> >> > when the > >>>>>> > >> >> > bridge > >>>>>> > >> >> > code swap the buf_idx between the nic ring(slot) and the > >>>>>> > >> >> > host > >>>>>> > >> >> > ring(slot). > >>>>>> > >> >> > The reordered seq usually right before or after the poll > >>>>>> > >> >> > function > >>>>>> > >> >> > call. > >>>>>> > >> >> > > >>>>>> > >> >> > Best, > >>>>>> > >> >> > Xiaoye > >>>>>> > >> >> > > >>>>>> > >> >> > > >>>>>> > >> >> > > >>>>>> > >> >> > > >>>>>> > >> >> > > >>>>>> > >> >> > > >>>>>> > >> >> > > >>>>>> > >> >> > > >>>>>> > >> >> > On Fri, Jan 29, 2016 at 4:27 PM, Luigi Rizzo > >>>>>> > >> >> > > >>>>>> > >> >> > wrote: > >>>>>> > >> >> >> > >>>>>> > >> >> >> On Fri, Jan 29, 2016 at 2:12 PM, Xiaoye Sun > >>>>>> > >> >> >> > >>>>>> > >> >> >> wrote: > >>>>>> > >> >> >> > Hi Luigi, > >>>>>> > >> >> >> > > >>>>>> > >> >> >> > Thanks for your advice. > >>>>>> > >> >> >> > I forgot to mention that I use the command "ethtool -L > >>>>>> > >> >> >> > eth1 > >>>>>> > >> >> >> > combined > >>>>>> > >> >> >> > 1" > >>>>>> > >> >> >> > to > >>>>>> > >> >> >> > set the number of rings of the nic to 1. The host also > >>>>>> > >> >> >> > only has > >>>>>> > >> >> >> > one > >>>>>> > >> >> >> > ring. > >>>>>> > >> >> >> > I understand the situation where the first tx ring is > >>>>>> > >> >> >> > full so > >>>>>> > the > >>>>>> > >> >> >> > bridge > >>>>>> > >> >> >> > will swap the packets to the second tx ring and then > the > >>>>>> > host/nic > >>>>>> > >> >> >> > might > >>>>>> > >> >> >> > drain either rings. But this is not the case in the > >>>>>> > >> >> >> > experiment. > >>>>>> > >> >> >> > >>>>>> > >> >> >> ok good to know that. > >>>>>> > >> >> >> > >>>>>> > >> >> >> So if we have ruled out multiqueue and iommu, let's look > at > >>>>>> > >> >> >> the internal allocator and at bridge.c > >>>>>> > >> >> >> > >>>>>> > >> >> >> 1. are you running the most recent version of netmap ? > >>>>>> > >> >> >> Some older version (probably 1-2 years ago) had a bug > >>>>>> > >> >> >> in the buffer allocator and some buffers were > allocated > >>>>>> > >> >> >> twice. > >>>>>> > >> >> >> > >>>>>> > >> >> >> 2. can you tweak your receiver.c to report some more info > >>>>>> > >> >> >> on how often you get out of sequence packets, how much > >>>>>> > >> >> >> out of sequence they are ? > >>>>>> > >> >> >> Also it would be useful to report gaps on the > increasing > >>>>>> > >> >> >> side > >>>>>> > >> >> >> (i.e. new_seq != old_seq +1 ) > >>>>>> > >> >> >> > >>>>>> > >> >> >> 3. can you tweak bridge.c so that it writes into the > packet > >>>>>> > >> >> >> the netmap buffer indexes and slots on the rx and tx > >>>>>> > >> >> >> side, > >>>>>> > >> >> >> so when you detect a sequence error we can figure out > >>>>>> > >> >> >> where it is happening. > >>>>>> > >> >> >> Ideally you could also add the sequence number > detection > >>>>>> > >> >> >> code in bridge.c so we can check whether the errors > >>>>>> > >> >> >> appear > >>>>>> > >> >> >> on the input or output sides. > >>>>>> > >> >> >> > >>>>>> > >> >> >> cheers > >>>>>> > >> >> >> luigi > >>>>>> > >> >> >> > >>>>>> > >> >> > > >>>>>> > >> >> > >>>>>> > >> >> > >>>>>> > >> >> > >>>>>> > >> >> -- > >>>>>> > >> >> > >>>>>> > >> >> > >>>>>> > > >>>>>> > > -----------------------------------------+------------------------------- > >>>>>> > >> >> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. > >>>>>> > >> >> dell'Informazione > >>>>>> > >> >> http://www.iet.unipi.it/~luigi/ . Universita` di > Pisa > >>>>>> > >> >> TEL +39-050-2217533 . via Diotisalvi 2 > >>>>>> > >> >> Mobile +39-338-6809875 . 56122 PISA > (Italy) > >>>>>> > >> >> > >>>>>> > >> >> > >>>>>> > > >>>>>> > > -----------------------------------------+------------------------------- > >>>>>> > >> >> > >>>>>> > >> > > >>>>>> > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> > >> -- > >>>>>> > >> > >>>>>> > > >>>>>> > > -----------------------------------------+------------------------------- > >>>>>> > >> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. > >>>>>> > dell'Informazione > >>>>>> > >> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > >>>>>> > >> TEL +39-050-2217533 . via Diotisalvi 2 > >>>>>> > >> Mobile +39-338-6809875 . 56122 PISA (Italy) > >>>>>> > >> > >>>>>> > > >>>>>> > > -----------------------------------------+------------------------------- > >>>>>> > >> > >>>>>> > > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > -- > >>>>>> > > >>>>>> > > -----------------------------------------+------------------------------- > >>>>>> > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. > >>>>>> > dell'Informazione > >>>>>> > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > >>>>>> > TEL +39-050-2217533 . via Diotisalvi 2 > >>>>>> > Mobile +39-338-6809875 . 56122 PISA (Italy) > >>>>>> > > >>>>>> > > -----------------------------------------+------------------------------- > >>>>>> > > >>>>>> > > >>>>>> _______________________________________________ > >>>>>> 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" > >>> > >>> > >> > > > > > > -- > -----------------------------------------+------------------------------- > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL +39-050-2217533 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > -----------------------------------------+------------------------------- > > From owner-freebsd-net@freebsd.org Wed Feb 10 16:37:29 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 08782AA4D91 for ; Wed, 10 Feb 2016 16:37:29 +0000 (UTC) (envelope-from rpokala@mac.com) Received: from mr11p00im-asmtp004.me.com (mr11p00im-asmtp004.me.com [17.110.69.135]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EAE44CC5 for ; Wed, 10 Feb 2016 16:37:28 +0000 (UTC) (envelope-from rpokala@mac.com) Received: from [192.168.1.4] (c-24-6-178-251.hsd1.ca.comcast.net [24.6.178.251]) by mr11p00im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.36.0 64bit (built Sep 8 2015)) with ESMTPSA id <0O2C005LQ8Q9MF00@mr11p00im-asmtp004.me.com> for freebsd-net@freebsd.org; Wed, 10 Feb 2016 15:37:22 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-02-10_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1602100287 User-Agent: Microsoft-MacOutlook/0.0.0.160109 Date: Wed, 10 Feb 2016 07:37:20 -0800 Subject: Re: C program API to determine negotiated link speed of a network interface? From: Ravi Pokala Sender: "Pokala, Ravi" To: "freebsd-net@freebsd.org" Message-id: Thread-topic: C program API to determine negotiated link speed of a network interface? MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 16:37:29 -0000 >Date: Tue, 9 Feb 2016 22:51:27 +0000 (UTC) >From: Pallav Bose >To: "freebsd-net@freebsd.org" >Subject: C program API to determine negotiated link speed of a network > interface? >Message-ID: > <249322925.1631277.1455058288002.JavaMail.yahoo@mail.yahoo.com> >Content-Type: text/plain; charset=UTF-8 > >Hi, >I'm writing a C program to list all available interfaces and their link speed. ... > >... > >Running truss on ifconfig(8) tells me that the ioctl SIOCGIFMEDIA can be used, but it is not clear to me how. Is there an API in C which does this already? > >... > >Thanks,Pallav Hi Pallav, Take a look at sbin/ifconfig/ifmedia.c::media_status(). Basically, you call ioctl(SIOCGIFMEDIA) once to get the number of media types for the NIC, allocate local memory to hold the list, then call ioctl(SIOCGIFMEDIA) again to copy the list into that local buffer. Then print_media_word() parses it and emits (amongst other things) the speed. Alas, print_media_word () and several of the helper functions it calls are (a) not part of a library, so you have to re-implement them yourself in your own sources and (b) are copy/pasted between ifconfig and etherswitch. That screams for refactoring, and if/when that happens, it should have a public interface. Hope that helps, Ravi (rpokala@) From owner-freebsd-net@freebsd.org Wed Feb 10 18:18:16 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4FDFCAA4288 for ; Wed, 10 Feb 2016 18:18:16 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 07F7B11E5 for ; Wed, 10 Feb 2016 18:18:16 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-vk0-x22e.google.com with SMTP id e185so19576109vkb.1 for ; Wed, 10 Feb 2016 10:18:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=nTHgVI3jiZCbA8rmqb2j/c7joVv+sLNqI9S4tcJPPTo=; b=yzj9M3M5H5IGPjaEF3uW7ZTjU4uHqjIOCXfrKNbmKLcPIFrD59qMVsDl0UOFJ8uVQa Hxdu0wTsOOtkOLYVp7Tizye0/gGVz+vhcBB6ngtklX0/ns1FMyodtC/Y7m+bP6Y5B+FY xH6OMz4D9hPlL/Ff0D8y1FmhtG1s3zRQ8ZqitcTC6ecj0ZO+TFI+hM4/14qtK1vxRmIY ac5sGehpewr1iuxHmX5DwS/QUyMvTpk3lRBNSDCFDNAVTMCbpc4QRb29kGwxo9hXxIW3 1Z97rdHtyDaySeZ9/r5whjaAozvGHBJbpwYSY850jb9P+oE11yzCHh6Z6Nuq9ttIYVai 6VUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nTHgVI3jiZCbA8rmqb2j/c7joVv+sLNqI9S4tcJPPTo=; b=kLbRkHKNiS0jOYRjX8z4cgwhzWlEl6LdAPVRd/rJhODQEj1UlQ14NGjxK3++1O+Czp Ei9J19p1S+tDEhikh/Uqxis472DfeuPW+1nDfp5CjaATofAqhKXcfI+EB2SYAGeNwe5A 06n27ZP/QxBf6lljLMGMB0y+wxwn9dsin8JkLJ1Nalik70mmk7bJFXfqVpb7GqFEKkSN 6yFSSlVJDr96o5apI/PArE12n5nK7LaytJJHQ/bHPtOA4t/JBgL/SpPvXndRsbIX4XI8 ZIB+E/kKRqiU+wV/CJZACnTBQ8nuASlbYua0pH2tMBqlCce6pNGde2C8gctRZkydtLEg xBHw== X-Gm-Message-State: AG10YOQRd/YiqD4opjR+nSjRswKuskuyDaPyYKXlxXDkfdrlSfZHsEKPUlzxTRmNJko6a59PMScUNUZtTnBtMQ== MIME-Version: 1.0 X-Received: by 10.31.133.7 with SMTP id h7mr30863367vkd.32.1455128294934; Wed, 10 Feb 2016 10:18:14 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.159.32.135 with HTTP; Wed, 10 Feb 2016 10:18:14 -0800 (PST) In-Reply-To: <56BAF38B.3080809@grosbein.net> References: <76A08658-ACD2-426B-865A-45A6A79BBFB4@jboy.eu> <56BAF38B.3080809@grosbein.net> Date: Wed, 10 Feb 2016 10:18:14 -0800 X-Google-Sender-Auth: Ux5BN9kGFh7VdRMOe4yAXfVNn-U Message-ID: Subject: Re: ifconfig with quoted arguments From: Kevin Oberman To: Eugene Grosbein Cc: Jeremy Boy , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 18:18:16 -0000 On Wed, Feb 10, 2016 at 12:23 AM, Eugene Grosbein wrote: > On 10.02.2016 04:51, Jeremy Boy wrote: > > Hello list, > > > > please CC me in replies to this mail, since I am no subscriber to this > list. > > > > For safety reasons, we enclose user input to shell commands in quotes. > Until today, the resulting command for ifconfig(8) looked like this: > > > >> ifconfig ue0 inet "192.168.2.176 netmask 255.255.255.0" > > According to ifconfig(8) manual page, this syntax is wrong. > > > What exactly does ifconfig do? It seems to me that it reads the IP > address from the quoted string but truncates the netmask. Is this a bug in > ifconfig or intended behavior? > > The word "inet" is for "address_family". The next argument should be > "address" and > you supply "192.168.2.176 netmask 255.255.255.0" for "address". > It seems, ifconfig passes this argument to inet_aton() function that > parses IP address > and ignores first space and the rest of string. > I'd suggest using CIDR notation and eliminating the old "netmask" al together. ifconfig ue0 inet 192.168.2.176/24 Aside form no longer using a form of addressing that had been obsolete for 20 years, quotation marks won't matter. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 From owner-freebsd-net@freebsd.org Wed Feb 10 18:35:01 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11CABAA4B2B for ; Wed, 10 Feb 2016 18:35:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 015F8102 for ; Wed, 10 Feb 2016 18:35: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 u1AIZ0Ug076897 for ; Wed, 10 Feb 2016 18:35:00 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality Date: Wed, 10 Feb 2016 18:35:01 +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: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: g_amanakis@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc bug_file_loc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 18:35:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207087 g_amanakis@yahoo.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ae@FreeBSD.org, | |freebsd-bugs@FreeBSD.org, | |freebsd-net@FreeBSD.org, | |melifaro@FreeBSD.org URL| |https://reviews.freebsd.org | |/D4042 --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Wed Feb 10 18:40:47 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C94B3AA3121 for ; Wed, 10 Feb 2016 18:40: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 B91728CE for ; Wed, 10 Feb 2016 18:40: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 u1AIel73086159 for ; Wed, 10 Feb 2016 18:40:47 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality Date: Wed, 10 Feb 2016 18:40:47 +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: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: g_amanakis@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 18:40:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207087 --- Comment #2 from g_amanakis@yahoo.com --- Also I just figured out that my Android devices which connect directly to t= he gateway running the OpenVPN server (they connect to the internal interface = and not through OpenVPN) are not able to open regular webpages and some apps (e= Bay, Amazon, YouTube) stop functioning if this commit is applied. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Wed Feb 10 20:00:00 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7696BAA3058 for ; Wed, 10 Feb 2016 20:00: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 4F1FF24F for ; Wed, 10 Feb 2016 20:00: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 u1AJxxfe082028 for ; Wed, 10 Feb 2016 20:00:00 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality Date: Wed, 10 Feb 2016 19:59:59 +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: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mgrooms@shrew.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 20:00:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207087 mgrooms@shrew.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mgrooms@shrew.net --- Comment #3 from mgrooms@shrew.net --- Recently I noticed that after upgrading two separate pairs of firewalls to 10.2-RELEASE that my ISAKMP deamons stopped negotiating SAs with peers. I j= ust haven't gotten around to submitting a bug report yet. It only seems to happ= en when large UDP packets get fragmented due to large payloads ( ie. certifica= te info is transmitted during late in phase1 negotiation ). This may be unique= to the bge driver or related hardware as the isakmp daemon started working aga= in on both sets of firewalls once I disabled hardware checksum offload ( ifcon= fig bgeX -rxcsum ). This work-around wasn't required until the upgrade to 10.2-RELEASE, but I can't say if it was at a specific patch level. I can say that one set of firewalls were upgraded from 9.2-RELEASE-p?? and the other = set were upgraded from a patched 10.0-RELEASE, so I assume the commit that broke UDP re-assembly was committed sometime between 10.0-RELEASE and 10.2-RELEASE-p11. Sorry I can't be more specific. BTW, this isn't an attempt to hijack your problem report. I just thought th= at the issue you describe ( openvpn w/ UDP ) may be related to mine so I thoug= ht it would be worth mentioning. Have you tried disabling hw checksum offload = on your public facing network device? If that improves the situation, it's qui= te possible that we are being bit by the same issue. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Wed Feb 10 20:08:13 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CBAB3AA35B3 for ; Wed, 10 Feb 2016 20:08: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 BCFD4A03 for ; Wed, 10 Feb 2016 20:08: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 u1AK8CNh034730 for ; Wed, 10 Feb 2016 20:08:13 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality Date: Wed, 10 Feb 2016 20:08:13 +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: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: g_amanakis@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 20:08:13 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207087 --- Comment #4 from g_amanakis@yahoo.com --- (In reply to mgrooms from comment #3) This issue concerns only 10.2-STABLE (now 10.3-BETA1) which is about to bec= ome 10.3-RELEASE. The commit has not been applied to 10.2-RELEASE, so you must = be facing another issue. The OpenVPN clients connect with no problems to the server.=20 It has to do with ip_tryforward(). If I comment out this function in ip_inp= ut.c the symptoms resolve. Could it be that some of the traffic entering ip_tryforward() bypasses the NAT? --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Wed Feb 10 20:51:24 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 15155AA43D8 for ; Wed, 10 Feb 2016 20:51: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 076D3CC9 for ; Wed, 10 Feb 2016 20:51: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 u1AKpNKk028138 for ; Wed, 10 Feb 2016 20:51:23 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality Date: Wed, 10 Feb 2016 20:51:24 +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: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mgrooms@shrew.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 20:51:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207087 --- Comment #5 from mgrooms@shrew.net --- I see. They underlying cause is quite possibly unrelated then. As I said, I wasn't trying to hijack your bug report. But the symptom still sounds simil= ar in the respect that some of your UDP traffic ( your OpenVPN control traffic= for example ) appears to be processed correctly, but other traffic ( your OpenV= PN transport traffic being tunneled ) does not. That smacks of a re-assembly problem. In the latter case, you could have a large inner IP packet size du= e to the tunnel overhead which would cause the outer IP packet to be fragmented. This would lead to stalls and resets from the client perspective, just as y= ou describe in your bug report. However, that doesn't necessarily explain your 2nd problem where non-tunnel= ed traffic stalls. You can't NAT fragmented packets if you have a re-assembly problem as the required UDP/TCP port values are only available in the initi= al packet of a fragmented chain. That usually only effects UDP packets but it = can still be a problem for TCP if the TCP MSS is large enough as the DNF bit is typically set in the IP header. In any case, good luck with your problem. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Wed Feb 10 20:55:13 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70C9AAA4671 for ; Wed, 10 Feb 2016 20:55: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 62B6A1088 for ; Wed, 10 Feb 2016 20:55: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 u1AKtDrQ037272 for ; Wed, 10 Feb 2016 20:55:13 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality Date: Wed, 10 Feb 2016 20:55:13 +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: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mgrooms@shrew.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 20:55:13 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207087 --- Comment #6 from mgrooms@shrew.net --- Doah, sorry. I stopped and started writing that last paragraph while in the middle of something else. I was still thinking of things in terms of tunnel= ing. Please disregard and I'll go away and be quiet now :) --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Wed Feb 10 23:29:45 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DD414AA5F6B for ; Wed, 10 Feb 2016 23:29:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CF50E10F6 for ; Wed, 10 Feb 2016 23:29:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1ANTiFg089416 for ; Wed, 10 Feb 2016 23:29:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality Date: Wed, 10 Feb 2016 23:29:45 +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: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gnn@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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 23:29:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207087 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |gnn@FreeBSD.org --- Comment #7 from Mark Linimon --- Assign to committer of 295285. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Wed Feb 10 23:29:54 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AC28AAA5FA3 for ; Wed, 10 Feb 2016 23:29: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 9DD1D11C6 for ; Wed, 10 Feb 2016 23:29: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 u1ANTsRH089676 for ; Wed, 10 Feb 2016 23:29:54 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality Date: Wed, 10 Feb 2016 23:29:54 +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: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gnn@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 23:29:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207087 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Thu Feb 11 08:42:57 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B7F84AA44A3 for ; Thu, 11 Feb 2016 08:42: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 A87341438 for ; Thu, 11 Feb 2016 08:42: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 u1B8gvML094224 for ; Thu, 11 Feb 2016 08:42:57 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 203175] Daily kernel crashes in tcp_twclose
on 10.2-p2 using VIMAGE Date: Thu, 11 Feb 2016 08:42: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: 10.2-RELEASE X-Bugzilla-Keywords: crash, needs-qa, patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: jch@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: jch@freebsd.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? 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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 08:42:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D203175 Julien Charbon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-net@FreeBSD.org |jch@freebsd.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Feb 11 11:30:20 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F2C0DAA4494 for ; Thu, 11 Feb 2016 11:30: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 E211FF6A for ; Thu, 11 Feb 2016 11:30: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 u1BBUKQC092480 for ; Thu, 11 Feb 2016 11:30:20 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 206721] FreeBSDs DHCP client(dhclient) does not support the interface-mtu option(option 26). Date: Thu, 11 Feb 2016 11:30:21 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ae@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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 11:30:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206721 Andrey V. Elsukov changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|ae@FreeBSD.org |freebsd-net@FreeBSD.org --- Comment #1 from Andrey V. Elsukov --- It is easy to add support of "interface-mtu" option to dhclient-script. But= the one problem is exists. When you are changing the MTU of interface, this initiates its reset and it goes down, then up. This by turn initiates resta= rt of dhclient. So, we get an endless loop. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Feb 11 18:18:28 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 62149AA56FD for ; Thu, 11 Feb 2016 18:18: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 531B41993 for ; Thu, 11 Feb 2016 18:18: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 u1BIISZk055617 for ; Thu, 11 Feb 2016 18:18:28 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 206904] tailq crash/nd inet6 Date: Thu, 11 Feb 2016 18:18: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: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markj@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: markj@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status 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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 18:18:28 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206904 Mark Johnston changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress Assignee|freebsd-net@FreeBSD.org |markj@FreeBSD.org --- Comment #7 from Mark Johnston --- I'm working on this. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Feb 11 21:16:28 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2EFA7AA4EBC for ; Thu, 11 Feb 2016 21:16: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 210B4C2 for ; Thu, 11 Feb 2016 21:16: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 u1BLGRIT071885 for ; Thu, 11 Feb 2016 21:16:28 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality Date: Thu, 11 Feb 2016 21:16:26 +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: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: g_amanakis@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gnn@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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 21:16:28 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207087 --- Comment #8 from g_amanakis@yahoo.com --- Kernels before this commit (e.g. r295264) with "net.inet.ip.fastforwarding= =3D1" do not exhibit this symptoms. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Thu Feb 11 23:24:36 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 232F4AA5AC9 for ; Thu, 11 Feb 2016 23:24: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 15F2E84A for ; Thu, 11 Feb 2016 23:24: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 u1BNOZ3l043045 for ; Thu, 11 Feb 2016 23:24:35 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality Date: Thu, 11 Feb 2016 23:24:35 +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: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: gnn@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gnn@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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 23:24:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207087 --- Comment #9 from George V. Neville-Neil --- Can you try this without VIMAGE, and then possibly without IPSEC_NAT_T and = tell me if the problem persists? Also, can you share the output of netstat -s f= or all protocols including tcp, esp, ah ? --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Fri Feb 12 01:00:17 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 845E1AA57C9 for ; Fri, 12 Feb 2016 01:00:17 +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 7542D14AF for ; Fri, 12 Feb 2016 01:00:17 +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 u1C10Gsm013816 for ; Fri, 12 Feb 2016 01:00:17 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality Date: Fri, 12 Feb 2016 01:00:17 +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: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: g_amanakis@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gnn@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 01:00:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207087 --- Comment #10 from g_amanakis@yahoo.com --- Created attachment 166885 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D166885&action= =3Dedit netstat.txt Output of "netstat -s" attached. In the local network the problem concerns primarily smartphones (I have an Android ecosystem) where some pages do not open at all. Commenting out the ip_tryforward() function resolves this. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Fri Feb 12 01:02:34 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B8D92AA5A03 for ; Fri, 12 Feb 2016 01:02:34 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8BCA418F4 for ; Fri, 12 Feb 2016 01:02:34 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-229-231.lns20.per1.internode.on.net [121.45.229.231]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u1C0rFcM055862 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 11 Feb 2016 16:53:18 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: ifconfig with quoted arguments To: Jeremy Boy , freebsd-net@freebsd.org References: <76A08658-ACD2-426B-865A-45A6A79BBFB4@jboy.eu> From: Julian Elischer Message-ID: <56BD2CF5.7020200@freebsd.org> Date: Fri, 12 Feb 2016 08:53:09 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <76A08658-ACD2-426B-865A-45A6A79BBFB4@jboy.eu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 01:02:34 -0000 On 10/02/2016 5:51 AM, Jeremy Boy wrote: > Hello list, > > please CC me in replies to this mail, since I am no subscriber to this list. > > For safety reasons, we enclose user input to shell commands in quotes. Until today, the resulting command for ifconfig(8) looked like this: > >> ifconfig ue0 inet "192.168.2.176 netmask 255.255.255.0" > > As we figured out, this means that ifconfig sometimes doesn't set the netmask as we expect it to do: > >> root@csbuild:~ # ifconfig ue0 >> ue0: flags=8843 metric 0 mtu 1500 >> options=80001 >> ether b8:27:eb:fd:58:69 >> inet 192.168.2.176 netmask 0xffff0000 broadcast 192.168.255.255 >> media: Ethernet autoselect (100baseTX ) >> status: active >> nd6 options=29 >> root@csbuild:~ # ifconfig ue0 inet "192.168.2.176 netmask 255.0.0.0" >> root@csbuild:~ # echo $? >> 0 >> root@csbuild:~ # ifconfig ue0 >> ue0: flags=8843 metric 0 mtu 1500 >> options=80001 >> ether b8:27:eb:fd:58:69 >> inet 192.168.2.176 netmask 0xffffff00 broadcast 192.168.2.255 >> media: Ethernet autoselect (100baseTX ) >> status: active >> nd6 options=29 >> root@csbuild:~ # > > As you can see, ifconfig sets the netmask to 255.255.255.0, ignoring the netmask we provided. If provided with a 10.* address, ifconfig sets the netmask to 255.0.0.0, no matter what actual netmask we entered. Also, it doesn't exit with a status indicating error, which made it a little harder to debug this issue. The following works as expected: > >> root@csbuild:~ # ifconfig ue0 >> ue0: flags=8843 metric 0 mtu 1500 >> options=80001 >> ether b8:27:eb:fd:58:69 >> inet 192.168.2.176 netmask 0xffffff00 broadcast 192.168.2.255 >> media: Ethernet autoselect (100baseTX ) >> status: active >> nd6 options=29 >> root@csbuild:~ # ifconfig ue0 inet "192.168.2.176" netmask "255.0.0.0" >> root@csbuild:~ # ifconfig ue0 >> ue0: flags=8843 metric 0 mtu 1500 >> options=80001 >> ether b8:27:eb:fd:58:69 >> inet 192.168.2.176 netmask 0xff000000 broadcast 192.255.255.255 >> media: Ethernet autoselect (100baseTX ) >> status: active >> nd6 options=29 >> root@csbuild:~ # > What exactly does ifconfig do? It seems to me that it reads the IP address from the quoted string but truncates the netmask. Is this a bug in ifconfig or intended behavior? it's not so much as ifconfig, as the shell you have ifconfig with 3 arguments, the last of which is "192.168.2.176 netmask 255.255.255.0" which ifconfig inspects to see if it has an IP address in it (followed by a space which terminates the test successfully). this is expected behaviour. Though admittedly a less than clear example of it. > > Best wishes > Jeremy > _______________________________________________ > 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 Feb 12 01:49:24 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8241AAA6AED for ; Fri, 12 Feb 2016 01:49: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 728E2AEA for ; Fri, 12 Feb 2016 01:49: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 u1C1nNV1067576 for ; Fri, 12 Feb 2016 01:49:24 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality Date: Fri, 12 Feb 2016 01:49:24 +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: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: g_amanakis@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gnn@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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 01:49:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207087 --- Comment #11 from g_amanakis@yahoo.com --- I tried with IPSEC_NAT_T and VIMAGE disabled and it doesn't resolve it. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Fri Feb 12 02:30:13 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3E019AA4A44 for ; Fri, 12 Feb 2016 02:30: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 2DF7C17DD for ; Fri, 12 Feb 2016 02:30: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 u1C2UCTK054915 for ; Fri, 12 Feb 2016 02:30:13 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality Date: Fri, 12 Feb 2016 02:30:12 +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: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: g_amanakis@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gnn@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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 02:30:13 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207087 --- Comment #12 from g_amanakis@yahoo.com --- I did some thorough testing with a simplified IPFW ruleset (only in-kernel = NAT enabled and allow everything on the local and WAN interfaces). Enabling "net.inet.ip.fastforwarding" in kernels before r295285 also exhibits the symptoms. Please disregard Comment #8 above. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Fri Feb 12 03:03:46 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD1DEAA5D6C for ; Fri, 12 Feb 2016 03:03:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BCA76F6A for ; Fri, 12 Feb 2016 03:03:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1C33k8X060431 for ; Fri, 12 Feb 2016 03:03:46 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality Date: Fri, 12 Feb 2016 03:03:46 +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: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: g_amanakis@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gnn@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 03:03:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207087 --- Comment #13 from g_amanakis@yahoo.com --- Created attachment 166886 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D166886&action= =3Dedit tcpdump.txt I did a tcpdump while an android client tries to access a webpage (www.gutefrage.net) while "net.inet.ip.fastforwarding" was on. I interrupted both dumps as soon as the client gave up trying to open the page. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Fri Feb 12 10:02:18 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9CC6FAA6254 for ; Fri, 12 Feb 2016 10:02: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 8D01BD84 for ; Fri, 12 Feb 2016 10:02: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 u1CA2GJ6061796 for ; Fri, 12 Feb 2016 10:02:18 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality Date: Fri, 12 Feb 2016 10:02:17 +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: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: gnn@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gnn@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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 10:02:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207087 --- Comment #14 from George V. Neville-Neil --- Thanks for all the updates, this does help to track some of this down. A f= ew more questions: If you are not using an Android client does everything just work? In your last test did you also turn off IPSEC and just use IPFW? Can I see= the IPFW ruleset you're using? And, can I get a full pcap file rather than a text dump of the attempted session? --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Fri Feb 12 10:13:46 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 928D9AA689C for ; Fri, 12 Feb 2016 10:13:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8284014D6 for ; Fri, 12 Feb 2016 10:13:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1CADjFU087083 for ; Fri, 12 Feb 2016 10:13:46 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality Date: Fri, 12 Feb 2016 10:13:46 +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: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: gnn@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gnn@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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 10:13:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207087 --- Comment #15 from George V. Neville-Neil --- Have you/can you test this on HEAD? --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Fri Feb 12 16:23:05 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66B36AA6F9D for ; Fri, 12 Feb 2016 16:23: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 58AFA1316 for ; Fri, 12 Feb 2016 16:23: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 u1CGN4jI099882 for ; Fri, 12 Feb 2016 16:23:05 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality Date: Fri, 12 Feb 2016 16:23:05 +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: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: brooks@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gnn@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 16:23:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207087 Brooks Davis changed: What |Removed |Added ---------------------------------------------------------------------------- CC|freebsd-amd64@FreeBSD.org |brooks@FreeBSD.org --- Comment #16 from Brooks Davis --- Remove freebsd-amd64 from cc. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Fri Feb 12 16:49:46 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 23EA4AA6AB0 for ; Fri, 12 Feb 2016 16:49:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 15A431F91 for ; Fri, 12 Feb 2016 16:49:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1CGnj4q052404 for ; Fri, 12 Feb 2016 16:49:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality Date: Fri, 12 Feb 2016 16:49:45 +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: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: g_amanakis@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gnn@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 16:49:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207087 --- Comment #17 from g_amanakis@yahoo.com --- Created attachment 166901 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D166901&action= =3Dedit ipfw.txt This is the simplified IPFW ruleset I am using. IPSEC is turned off in kern= el compilation. I will use only this from now on in order to have a common bas= is. xxx.yyy and aaa.bbb are local networks. All the local clients are on the xxx.yyy network. With this I am getting a mixed behaviour. For example my laptop client (Thinkpad X230 running Archlinux) exhibits the symptoms on some sites (most notably www.gutefrage.net) when the gateway runs the r295545 kernel (commen= ting out ip_tryforward() resolves it). However when the gateway runs the r295264 kernel with net.inet.ip.fastforwarding=3D1 the archlinux client doesn't exh= ibit the symptoms anymore.=20 I will test this on HEAD. Is there any special tcpdump command you 'd like = me to run? I will try and get simultaneous dumps from the interfaces involved. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Fri Feb 12 16:52:25 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DB102AA6D0F for ; Fri, 12 Feb 2016 16:52: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 CD12C134E for ; Fri, 12 Feb 2016 16:52: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 u1CGqPud061143 for ; Fri, 12 Feb 2016 16:52:25 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality Date: Fri, 12 Feb 2016 16:52:25 +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: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: gnn@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gnn@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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 16:52:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207087 --- Comment #18 from George V. Neville-Neil --- With tcpdump just use -w /tmp/capture.pcap so you get a file rather than te= xt based output. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Fri Feb 12 18:08:58 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DF83FAA6293 for ; Fri, 12 Feb 2016 18:08:58 +0000 (UTC) (envelope-from pallav_bose@yahoo.com) Received: from nm49-vm6.bullet.mail.gq1.yahoo.com (nm49-vm6.bullet.mail.gq1.yahoo.com [67.195.87.236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B9511888 for ; Fri, 12 Feb 2016 18:08:58 +0000 (UTC) (envelope-from pallav_bose@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1455300341; bh=F+F8fEkaw7m2yUoCxbEgnC2M+gN21gxfzt1vznp2IGQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=tmY74kI1epgWNFCUrTjG6+mJmSv0RR04OD0DJLh/JMaSz0ZMztOkNvnOnySHnyZxsMsGehpsgdPm9TncxbG5quT73wbZ2UT+vwyDrwdTTQfREsEeIFHMeODC6ef4xxwtaUT8WpgTvjoOLwzt6bDYF/iJDPEIGvflvw2wPq5vbE7RFAdRBQqW7U8kW205++r8ISwMnOo+MG38zlIXqxgO0kqX98kwlz6bkYewh06KP3D5b0yIVuFFPiCaCTqMR8sgQP9qq/AJutphJUDOjIL1+cZRTS0ke+z6wc+hiw6JWEp83fM/b6VQvXdyvvpBALCNgkzPoIstmH+IquM+MP3DCg== Received: from [127.0.0.1] by nm49.bullet.mail.gq1.yahoo.com with NNFMP; 12 Feb 2016 18:05:41 -0000 Received: from [216.39.60.180] by nm49.bullet.mail.gq1.yahoo.com with NNFMP; 12 Feb 2016 18:02:48 -0000 Received: from [98.137.12.207] by tm16.bullet.mail.gq1.yahoo.com with NNFMP; 12 Feb 2016 18:02:48 -0000 Received: from [127.0.0.1] by omp1015.mail.gq1.yahoo.com with NNFMP; 12 Feb 2016 18:02:48 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 237163.74741.bm@omp1015.mail.gq1.yahoo.com X-YMail-OSG: x.CKgzkVM1kMKqdGL2e5lCRJPm8I3QuowRGWc3H.QXVcAGB6y7.DY0Zp36OO9P4 XQI9EC2IwE5DA5vXr1ocHJOq00AOq6_kvCDMubUlGAX60TBEb7bh3.mx9zkHUzpMP9lwa7rjQdEN Hxi2uNgaDuvykALhwKEdgnraXWf5ZjfplWHjm0VKpdVSY_ZmyN5kdpFQ1tte92DB2aGD9gGhNSzs gM4zjkCndVF9r00TSoQeTe4oII6cmkrcksDmDdiTIB_YM1WPZvroCUewVEziMrFXa_AguFwwywtR Re2XR_Yhy02V2TIPqzVCwVDMx2F41_SB49GMqXqZJkoqARy_8aBmgdGXoOvAb8BFPQWx1CWdn8t6 OC4tgR7bi6BCmaPM8TbkYxcOVyn9Bb4Mlf7b8rVFufN84I__KF7ZKjSHEXen.NJJCRfdB59MVXwQ l3hyezOSyx6ldX3F_5KjsAt3z8k1O3TNfTZQx0r3NnpQRP_Hlz1aORsxOWT8sRJd0vFRCcwO6fiZ GHU355k8QKQEvYaGR0FHR37omtuDTuTKMQ1bJ6rAu55xc2A-- Received: by 98.137.12.251; Fri, 12 Feb 2016 18:02:47 +0000 Date: Fri, 12 Feb 2016 18:02:47 +0000 (UTC) From: Pallav Bose Reply-To: Pallav Bose To: "freebsd-net@freebsd.org" Cc: "rpokala@mac.com" Message-ID: <604939402.3154674.1455300167449.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <249322925.1631277.1455058288002.JavaMail.yahoo@mail.yahoo.com> References: <249322925.1631277.1455058288002.JavaMail.yahoo.ref@mail.yahoo.com> <249322925.1631277.1455058288002.JavaMail.yahoo@mail.yahoo.com> Subject: Re: C program API to determine negotiated link speed of a network interface? MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 18:08:59 -0000 Hi Ravi, That information you provided was very useful, thanks!=20 =C2=A0Regards, Pallav=20 On Tuesday, February 9, 2016 2:51 PM, Pallav Bose wrote: =20 Hi, I'm writing a C program to list all available interfaces and their link spe= ed. I can use getifaddrs(3) to obtain a list of network interfaces in a str= uct ifaddrs, but none of the fields in this struct gives me information abo= ut the negotiated link speed. From the man page of getifaddrs(3): The ifaddrs structure contains at least the following entries: =C2=A0=C2=A0=C2=A0 =C2=A0struct=C2=A0=C2=A0=C2=A0 ifaddrs=C2=A0=C2=A0=C2=A0= *ifa_next;=C2=A0=C2=A0=C2=A0 =C2=A0 /* Pointer to next struct */ =C2=A0=C2=A0=C2=A0 =C2=A0char=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *ifa_name;=C2=A0=C2=A0=C2=A0 = =C2=A0 /* Interface name */ =C2=A0=C2=A0=C2=A0 =C2=A0u_int=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ifa_flags;=C2=A0=C2=A0=C2=A0 = =C2=A0 /* Interface flags=C2=A0=C2=A0=C2=A0 */ =C2=A0=C2=A0=C2=A0 =C2=A0struct=C2=A0=C2=A0=C2=A0 sockaddr=C2=A0 *ifa_addr;= =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 /* Interface address */ =C2=A0=C2=A0=C2=A0 =C2=A0struct=C2=A0=C2=A0=C2=A0 sockaddr=C2=A0 *ifa_netma= sk;=C2=A0=C2=A0=C2=A0 /* Interface netmask */ =C2=A0=C2=A0=C2=A0 =C2=A0struct=C2=A0=C2=A0=C2=A0 sockaddr=C2=A0 *ifa_broad= addr;=C2=A0 /* Interface broadcast address */ =C2=A0=C2=A0=C2=A0 =C2=A0struct=C2=A0=C2=A0=C2=A0 sockaddr=C2=A0 *ifa_dstad= dr;=C2=A0=C2=A0=C2=A0 /* P2P interface destination */ =C2=A0=C2=A0=C2=A0 =C2=A0void=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *ifa_data;=C2=A0=C2=A0=C2=A0 =C2=A0=C2= =A0 /* Address specific data */ Running truss on ifconfig(8) tells me that the ioctl SIOCGIFMEDIA can be us= ed, but it is not clear to me how. Is there an API in C which does this alr= eady? # truss ifconfig em0........ ioctl(3,SIOCGIFMAC,0xffffe210)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ERR#22 'Inv= alid argument' ioctl(3,SIOCGIFMEDIA,0xffffe1f0)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D 0 (0x0) ioctl(3,SIOCGIFMEDIA,0xffffe1f0)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D 0 (0x0) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 media: Ethernet autoselect (1000= baseT ) write(1,"\tmedia: Ethernet autoselect (10"...,54) =3D 54 (0x36) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 status: active write(1,"\tstatus: active\n",16)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D 16 (0x10) Thanks,Pallav From owner-freebsd-net@freebsd.org Fri Feb 12 21:02:10 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 94EE2AA748A for ; Fri, 12 Feb 2016 21:02: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 86385F80 for ; Fri, 12 Feb 2016 21:02: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 u1CL29kQ041577 for ; Fri, 12 Feb 2016 21:02:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality Date: Fri, 12 Feb 2016 21:02:09 +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: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: g_amanakis@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gnn@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 21:02:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207087 --- Comment #19 from g_amanakis@yahoo.com --- Created attachment 166908 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D166908&action= =3Dedit wan.pcap --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Fri Feb 12 21:06:20 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3145CAA76CA for ; Fri, 12 Feb 2016 21: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 2269C147C for ; Fri, 12 Feb 2016 21: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 u1CL6Kew080253 for ; Fri, 12 Feb 2016 21:06:20 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality Date: Fri, 12 Feb 2016 21:06:20 +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: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: g_amanakis@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gnn@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 21:06:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207087 --- Comment #20 from g_amanakis@yahoo.com --- Created attachment 166909 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D166909&action= =3Dedit tun0.pcap tun0.pcap and wan.pcap (gateway interfaces) were captured simultaneously. A client (archlinux) was connected over OpenVPN to the gateway running r29554= 5. The simplified IPFW ruleset was used and www.gutefrage.net was accessed. The webpage did not load at all. After the capture, I also tried lowering the MTU of the tun interface on the client from 1500 to 1212 and 1196 but this didn't resolve it. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Sat Feb 13 16:52:21 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 815F8AA6612 for ; Sat, 13 Feb 2016 16:52:21 +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 726611E6C for ; Sat, 13 Feb 2016 16:52:21 +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 u1DGqKh2097144 for ; Sat, 13 Feb 2016 16:52:21 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality Date: Sat, 13 Feb 2016 16:52:21 +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: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: g_amanakis@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gnn@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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2016 16:52:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207087 --- Comment #21 from g_amanakis@yahoo.com --- The problem persists on HEAD (build 20160127). --=20 You are receiving this mail because: You are on the CC list for the bug.=