From owner-freebsd-net@FreeBSD.ORG Sun Dec 14 00:31:53 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CFC0DF4A for ; Sun, 14 Dec 2014 00:31:53 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (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 B1B47C89 for ; Sun, 14 Dec 2014 00:31:53 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id sBE0Vr1s022568 for ; Sun, 14 Dec 2014 00:31:53 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id sBE0Vr5f022566; Sun, 14 Dec 2014 00:31:53 GMT (envelope-from root) Date: Sun, 14 Dec 2014 00:31:53 +0000 To: freebsd-net@freebsd.org From: "rodrigc (Craig Rodrigues)" Subject: [Differential] [Request, 70 lines] D1309: VIMAGE PF fixes #1 Message-ID: X-Priority: 3 Thread-Topic: D1309: VIMAGE PF fixes #1 X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: Thread-Index: NzA2ZjJlODRkOGZmNmYwM2M1MmQ1N2YzYTJk X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 14 Dec 2014 00:31:53 -0000 rodrigc created this revision. rodrigc added reviewers: bz, glebius. rodrigc added subscribers: freebsd-net, freebsd-pf, freebsd-virtualization. REVISION SUMMARY Merge: r258322 from projects/pf branch - Split functions that initialize various pf parts into their vimage parts and global parts. - Since global parts appeared to be only mutex initializations, just abandon them and use MTX_SYSINIT() instead. - Kill my incorrect VNET_FOREACH() iterator and instead use correct approach with VNET_SYSINIT(). Submitted by: glebius, Nikos Vassiliadis Reviewed by: trociny TEST PLAN - compiled CURRENT kernel with this patch - booted - created VNET jail - started PF in the jail Eliminated some crashes such as PR 194515 REVISION DETAIL https://reviews.freebsd.org/D1309 AFFECTED FILES sys/net/pfvar.h sys/netpfil/pf/pf.c sys/netpfil/pf/pf_if.c sys/netpfil/pf/pf_ioctl.c sys/netpfil/pf/pf_norm.c To: rodrigc, bz, glebius Cc: freebsd-virtualization, freebsd-pf, freebsd-net From owner-freebsd-net@FreeBSD.ORG Sun Dec 14 00:33:01 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96FD52A2 for ; Sun, 14 Dec 2014 00:33:01 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (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 62CF3CB5 for ; Sun, 14 Dec 2014 00:33:01 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id sBE0X1aK023599 for ; Sun, 14 Dec 2014 00:33:01 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id sBE0X1gg023598; Sun, 14 Dec 2014 00:33:01 GMT (envelope-from root) Date: Sun, 14 Dec 2014 00:33:01 +0000 To: freebsd-net@freebsd.org From: "rodrigc (Craig Rodrigues)" Subject: [Differential] [Updated] D1309: VIMAGE PF fixes #1 Message-ID: X-Priority: 3 Thread-Topic: D1309: VIMAGE PF fixes #1 X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NzA2ZjJlODRkOGZmNmYwM2M1MmQ1N2YzYTJkIFSM2r0= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 14 Dec 2014 00:33:01 -0000 rodrigc added a reviewer: network. REVISION DETAIL https://reviews.freebsd.org/D1309 To: rodrigc, bz, glebius, np, melifaro, hrs, wollman, bryanv, rpaulo, adrian, gnn, hiren, rwatson Cc: freebsd-virtualization, freebsd-pf, freebsd-net From owner-freebsd-net@FreeBSD.ORG Sun Dec 14 00:53:47 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 988E261A for ; Sun, 14 Dec 2014 00:53:47 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (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 73474EB0 for ; Sun, 14 Dec 2014 00:53:47 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id sBE0rlsl044625 for ; Sun, 14 Dec 2014 00:53:47 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id sBE0rlS1044624; Sun, 14 Dec 2014 00:53:47 GMT (envelope-from root) Date: Sun, 14 Dec 2014 00:53:47 +0000 To: freebsd-net@freebsd.org From: "rodrigc (Craig Rodrigues)" Subject: [Differential] [Updated] D1309: VIMAGE PF fixes #1 Message-ID: X-Priority: 3 Thread-Topic: D1309: VIMAGE PF fixes #1 X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NzA2ZjJlODRkOGZmNmYwM2M1MmQ1N2YzYTJkIFSM35s= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 14 Dec 2014 00:53:47 -0000 rodrigc added a reviewer: trociny. REVISION DETAIL https://reviews.freebsd.org/D1309 To: rodrigc, bz, glebius, np, melifaro, hrs, wollman, bryanv, rpaulo, adrian, gnn, hiren, rwatson, trociny Cc: freebsd-virtualization, freebsd-pf, freebsd-net From owner-freebsd-net@FreeBSD.ORG Sun Dec 14 01:44:01 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B044BE6B for ; Sun, 14 Dec 2014 01:44:01 +0000 (UTC) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7464F3DD for ; Sun, 14 Dec 2014 01:44:01 +0000 (UTC) Received: by mail-ig0-f175.google.com with SMTP id h15so3349997igd.14 for ; Sat, 13 Dec 2014 17:44:00 -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=w45TZo6ColUSqBBJxpdP1H5mJyFsuCAV7MoVDvuTZmM=; b=gUvK0b2G4pHXhSq4ZO6e36UpAZgGKNl+I0fiVfUybOasW183zvXUvxHMyFpUVNkGs0 TAIbzJ98e4hV1uvT68DlUclN3+nVG2NU/s7yN3jO0XEJNFQQcE6YP+NSYpuoacDorQX0 QzvKh92pJpqxEUOzUIfoEE1thH70XrLqyVO49QZ0bt/wiKoFwag33Eeqm0mYOudlmutc jl/HBpf0ANEOOvWUz9oEih23JI7RJ3EKBgxg7Ci6FPjVo77KuOzx43y+oatrJpfemm9a b6hSU79ficKsOdc7LWG07roC8nJCRXGS+UTj1ZtSs1PfntAzwpwknRwgUixMj4gHhDdl sjtg== MIME-Version: 1.0 X-Received: by 10.107.6.196 with SMTP id f65mr22505541ioi.54.1418521440357; Sat, 13 Dec 2014 17:44:00 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.107.52.19 with HTTP; Sat, 13 Dec 2014 17:44:00 -0800 (PST) In-Reply-To: <548C3072.10303@bsdinfo.com.br> References: <548C3072.10303@bsdinfo.com.br> Date: Sat, 13 Dec 2014 17:44:00 -0800 X-Google-Sender-Auth: GxTNwH2wdz2xIHbpzdSfI0vvPug Message-ID: Subject: Re: DNS resolution problem From: Kevin Oberman To: Marcelo Gondim Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net >> FreeBSD Net" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 14 Dec 2014 01:44:01 -0000 On Sat, Dec 13, 2014 at 4:26 AM, Marcelo Gondim wrote: > Dear, > > I'm having trouble resolving domain name freebsd.org. The portsnap server > works correctly but the pkg audit -F does not work and can not even access > the site according to the following tests: > > # host ec2-sa-east-1.portsnap.freebsd.org > ec2-sa-east-1.portsnap.freebsd.org has address 177.71.188.240 > > # host vuxml.freebsd.org > Host vuxml.freebsd.org not found: 3(NXDOMAIN) > > # host -a freebsd.org > Trying "freebsd.org" > Trying "freebsd.org.intnet.com.br" > Host freebsd.org not found: 3(NXDOMAIN) > Received 86 bytes from ::1#53 in 0 ms > > # host www.freebsd.org > ;; connection timed out; no servers could be reached > > Only the first address I'm having name resolution (ec2-sa-east-1.portsnap. > freebsd.org). > > My block IP: 186.193.48.0/20 > > One could check for any restrictions on our IP block? > > I think a bit of DNS debugging is in order. I could resolve all of the nodes you listed, but there are some potential issues I see. First, when looking up hostname with host(1), always terminate the name: > host -a freebsd.org. Trying "freebsd.org" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24171 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;freebsd.org. IN TYPE255 ;; ANSWER SECTION: freebsd.org. 534 IN AAAA 2001:1900:2254:206a::50:0 freebsd.org. 534 IN MX 10 mx1.freebsd.org. freebsd.org. 534 IN A 8.8.178.110 But "ANY" queries are fuzzy things at best as the first resolver you hit will just return whatever is cached and not try getting an authoritative response. www.freebsd.org and vuxml.freebsd.org are CNAME entries pointing to the same place, 8.8.178.110. This is in FreeBSD's own address space from Yahoo nd is probably in the mail FreeBSD cluster. I was a bit surprised to find that is is an Amazon AWS address, so the portsnap files are actually coming from a totally different place. DNS is provided by ISC-SNS. 72.52.71.1, 38.103.2.1 and 63.243.194.1. Try pinging these. Since BIND, the second oldest and most popular DNS server is written and supported by ISA, I would think that it is well run. Try pinging and tracing to these addresses. All of them are in very dispersed locations on different provider backbones. (Cogent, Hurricane Electric, and ISC, itself. You might try directing queries to each system to see if one fails when other succeed. Use "dig @servr-addr host". -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-net@FreeBSD.ORG Sun Dec 14 03:18:59 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 60C9CC3C for ; Sun, 14 Dec 2014 03:18:59 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (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 42BB2F0E for ; Sun, 14 Dec 2014 03:18:59 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id sBE3Iwf5051802 for ; Sun, 14 Dec 2014 03:18:58 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id sBE3Iwpj051801; Sun, 14 Dec 2014 03:18:58 GMT (envelope-from root) Date: Sun, 14 Dec 2014 03:18:58 +0000 To: freebsd-net@freebsd.org From: "rodrigc (Craig Rodrigues)" Subject: [Differential] [Request, 46 lines] D1312: VNET PF fixes #2 Message-ID: X-Priority: 3 Thread-Topic: D1312: VNET PF fixes #2 X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: Thread-Index: OTEzZmU1MDE5NzRjYjllYzQxMmNjNjQyZWM1 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 14 Dec 2014 03:18:59 -0000 rodrigc created this revision. rodrigc added reviewers: bz, glebius, trociny. rodrigc added subscribers: freebsd-net, freebsd-virtualization, freebsd-pf. REVISION SUMMARY Virtualize the pfr_ktables variable. Submitted by: Nikos Vassiliadis REVISION DETAIL https://reviews.freebsd.org/D1312 AFFECTED FILES sys/netpfil/pf/pf_table.c To: rodrigc, bz, glebius, trociny Cc: freebsd-pf, freebsd-virtualization, freebsd-net From owner-freebsd-net@FreeBSD.ORG Sun Dec 14 03:19:55 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A036D54 for ; Sun, 14 Dec 2014 03:19:55 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (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 1B2B8F1E for ; Sun, 14 Dec 2014 03:19:55 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id sBE3Js3l052410 for ; Sun, 14 Dec 2014 03:19:54 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id sBE3JsMi052409; Sun, 14 Dec 2014 03:19:54 GMT (envelope-from root) Date: Sun, 14 Dec 2014 03:19:54 +0000 To: freebsd-net@freebsd.org From: "rodrigc (Craig Rodrigues)" Subject: [Differential] [Updated] D1312: VIMAGE PF fixes #2 Message-ID: <403a74c4bf90944d5a35ea0c4b6eb3f4@localhost.localdomain> X-Priority: 3 Thread-Topic: D1312: VNET PF fixes #2 X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: OTEzZmU1MDE5NzRjYjllYzQxMmNjNjQyZWM1IFSNAdo= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 14 Dec 2014 03:19:55 -0000 rodrigc retitled this revision from "VNET PF fixes #2" to "VIMAGE PF fixes #2". REVISION DETAIL https://reviews.freebsd.org/D1312 To: rodrigc, bz, glebius, trociny Cc: freebsd-pf, freebsd-virtualization, freebsd-net From owner-freebsd-net@FreeBSD.ORG Sun Dec 14 03:22:46 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E7F1BF1E for ; Sun, 14 Dec 2014 03:22:46 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (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 C1F2EFDF for ; Sun, 14 Dec 2014 03:22:46 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id sBE3MkIm057219 for ; Sun, 14 Dec 2014 03:22:46 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id sBE3MkRl057216; Sun, 14 Dec 2014 03:22:46 GMT (envelope-from root) Date: Sun, 14 Dec 2014 03:22:46 +0000 To: freebsd-net@freebsd.org From: "rodrigc (Craig Rodrigues)" Subject: [Differential] [Request, 26 lines] D1313: VIMAGE PF fixes #3 Message-ID: X-Priority: 3 Thread-Topic: D1313: VIMAGE PF fixes #3 X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: Thread-Index: N2E2YTZiYWMwMDJmYzAzMTFiODgwZDc5MmEy X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 14 Dec 2014 03:22:47 -0000 rodrigc created this revision. rodrigc added reviewers: bz, glebius, trociny, network. rodrigc added subscribers: freebsd-net, freebsd-pf, freebsd-virtualization. REVISION SUMMARY Only register attach/detach event handlers if the current vnet is vnet0. Submitted by: Nikos Vassiliadis REVISION DETAIL https://reviews.freebsd.org/D1313 AFFECTED FILES sys/netpfil/pf/pf_if.c To: rodrigc, bz, glebius, trociny, np, melifaro, hrs, wollman, bryanv, rpaulo, adrian, gnn, hiren, rwatson Cc: freebsd-virtualization, freebsd-pf, freebsd-net From owner-freebsd-net@FreeBSD.ORG Sun Dec 14 14:54:21 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 220E81C7 for ; Sun, 14 Dec 2014 14:54:21 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (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 D81112DD for ; Sun, 14 Dec 2014 14:54:20 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id sBEEsK9M024018 for ; Sun, 14 Dec 2014 14:54:20 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id sBEEsKOV024017; Sun, 14 Dec 2014 14:54:20 GMT (envelope-from root) Date: Sun, 14 Dec 2014 14:54:20 +0000 To: freebsd-net@freebsd.org From: "rodrigc (Craig Rodrigues)" Subject: [Differential] [Request, 100 lines] D1315: VIMAGE PF fixes #4 Message-ID: X-Priority: 3 Thread-Topic: D1315: VIMAGE PF fixes #4 X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: Thread-Index: ZGI1YWY1MTBmYjU4M2RhM2FhZDQyNzA4YWQ1 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 14 Dec 2014 14:54:21 -0000 rodrigc created this revision. rodrigc added reviewers: bz, glebius, trociny, network. rodrigc added subscribers: freebsd-net, freebsd-pf, freebsd-virtualization. REVISION SUMMARY Instead of creating a purge thread for every vnet, create a single purge thread and clean up all vnets from this thread. TEST PLAN (1) Boot a kernel with VIMAGE enabled (2) Create a vnet jail jail -c persist name=testjail001 vnet path=/ host.hostname=testjail001 allow.raw_sockets allow.socket_af (3) Start pf inside the jail service start pf (4) Delete the vnet jail jail -r testjail001 Without this patch, the kernel would panic in step (4). With the patch, the kernel does not panic REVISION DETAIL https://reviews.freebsd.org/D1315 AFFECTED FILES sys/net/pfvar.h sys/netpfil/pf/pf.c sys/netpfil/pf/pf_ioctl.c To: rodrigc, bz, glebius, trociny, np, melifaro, hrs, wollman, bryanv, rpaulo, adrian, gnn, hiren, rwatson Cc: freebsd-virtualization, freebsd-pf, freebsd-net From owner-freebsd-net@FreeBSD.ORG Sun Dec 14 15:35:14 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F1BEAB2F for ; Sun, 14 Dec 2014 15:35:14 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (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 CBF1BB5B for ; Sun, 14 Dec 2014 15:35:14 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id sBEFZEQE044762 for ; Sun, 14 Dec 2014 15:35:14 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id sBEFZEGv044761; Sun, 14 Dec 2014 15:35:14 GMT (envelope-from root) Date: Sun, 14 Dec 2014 15:35:14 +0000 To: freebsd-net@freebsd.org From: "zec (Marko Zec)" Subject: [Differential] [Changed Subscribers] D1315: VIMAGE PF fixes #4 Message-ID: <08c6c92022e0bf642aaeaaa712721297@localhost.localdomain> X-Priority: 3 Thread-Topic: D1315: VIMAGE PF fixes #4 X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: ZGI1YWY1MTBmYjU4M2RhM2FhZDQyNzA4YWQ1IFSNrjI= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 14 Dec 2014 15:35:15 -0000 zec added a subscriber: zec. INLINE COMMENTS sys/netpfil/pf/pf.c:1384 *v could be marked as __unused sys/netpfil/pf/pf_ioctl.c:282 Passing curvnet as an argument here is redundant now. REVISION DETAIL https://reviews.freebsd.org/D1315 To: rodrigc, bz, glebius, trociny, np, melifaro, hrs, wollman, bryanv, rpaulo, adrian, gnn, hiren, rwatson Cc: zec, freebsd-virtualization, freebsd-pf, freebsd-net From owner-freebsd-net@FreeBSD.ORG Sun Dec 14 16:36:29 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D188AAE for ; Sun, 14 Dec 2014 16:36:29 +0000 (UTC) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 04ED4111 for ; Sun, 14 Dec 2014 16:36:28 +0000 (UTC) Received: from Toshi.lariat.net (IDENT:ppp1000.lariat.net@localhost [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id JAA27068; Sun, 14 Dec 2014 09:35:11 -0700 (MST) Message-Id: <201412141635.JAA27068@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 14 Dec 2014 09:25:00 -0700 To: eksffa@freebsdbrasil.com.br, "Luigi Rizzo" From: Brett Glass Subject: Re: Can DUMMYNET handle weighting of traffic according to firewall rules? In-Reply-To: <028d142b3a17cd5ffd5f21c6f9b9d6daaa8e2780@webmail.freebsdbr asil.com.br> References: <028d142b3a17cd5ffd5f21c6f9b9d6daaa8e2780@webmail.freebsdbrasil.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: John Nielsen , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 14 Dec 2014 16:36:29 -0000 At 11:02 AM 12/13/2014, eksffa@freebsdbrasil.com.br wrote: >As I understand the problem, there are many ways to do this >without actually using any special feature on dummynet. From >tagging a traffic twice and feeding both tagged flows to the same >pipe, to the easiest and possibily lighter approach of disabling >one pass and feeding the traffic twice to the same pipe. Unfortunately, feeding the traffic to the same pipe more than once would have some undesirable side effects. It would mean incurring X times the delay and computational overhead introduced by the pipe. This would affect not only latency but also jitter, because DUMMYNET pipes are driven by timer interrupts. Even if you set the kernel's HZ setting to a high number, you could have milliseconds of difference in the latency depending upon a packet's precise arrival time and the amount of traffic. If DUMMYNET was in "fast" mode, there would also be a very big jump in latency when the pipe neared capacity. X could only be a whole number unless you fed the pipe multiple times in EACH direction. And turning off the "one_pass" feature would add to the overhead of EVERY pipe used in the system. It would be much more desirable to be able to specify a cost factor for a packet entering the pipe, as Luigi mentioned, so that the pipe could simply adjust its "score" to reflect the higher overhead of upstream vs. downstream traffic. If it's really a one-line patch to the kernel, I'd like to try doing this and then submit a patch to add the feature if it works. --Brett Glass From owner-freebsd-net@FreeBSD.ORG Sun Dec 14 18:59:45 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E7CC82D4 for ; Sun, 14 Dec 2014 18:59:45 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (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 C1A3191 for ; Sun, 14 Dec 2014 18:59:45 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id sBEIxj4k052821 for ; Sun, 14 Dec 2014 18:59:45 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id sBEIxjfP052820; Sun, 14 Dec 2014 18:59:45 GMT (envelope-from root) Date: Sun, 14 Dec 2014 18:59:45 +0000 To: freebsd-net@freebsd.org From: "rodrigc (Craig Rodrigues)" Subject: [Differential] [Updated] D1315: VIMAGE PF fixes #4 Message-ID: <50b304c8c1a78fbb1a539777f73c55ef@localhost.localdomain> X-Priority: 3 Thread-Topic: D1315: VIMAGE PF fixes #4 X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: ZGI1YWY1MTBmYjU4M2RhM2FhZDQyNzA4YWQ1IFSN3iE= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 14 Dec 2014 18:59:46 -0000 rodrigc added a reviewer: zec. REVISION DETAIL https://reviews.freebsd.org/D1315 To: rodrigc, bz, glebius, trociny, np, melifaro, hrs, wollman, bryanv, rpaulo, adrian, gnn, hiren, rwatson, zec Cc: zec, freebsd-virtualization, freebsd-pf, freebsd-net From owner-freebsd-net@FreeBSD.ORG Sun Dec 14 19:00:16 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D5C0A407 for ; Sun, 14 Dec 2014 19:00:16 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (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 B0038B3 for ; Sun, 14 Dec 2014 19:00:16 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id sBEJ0G8b053975 for ; Sun, 14 Dec 2014 19:00:16 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id sBEJ0Gdb053974; Sun, 14 Dec 2014 19:00:16 GMT (envelope-from root) Date: Sun, 14 Dec 2014 19:00:16 +0000 To: freebsd-net@freebsd.org From: "rodrigc (Craig Rodrigues)" Subject: [Differential] [Updated] D1309: VIMAGE PF fixes #1 Message-ID: <9f4ab9f212b44bf9c0bed63396559d5c@localhost.localdomain> X-Priority: 3 Thread-Topic: D1309: VIMAGE PF fixes #1 X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NzA2ZjJlODRkOGZmNmYwM2M1MmQ1N2YzYTJkIFSN3kA= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 14 Dec 2014 19:00:16 -0000 rodrigc added a reviewer: zec. REVISION DETAIL https://reviews.freebsd.org/D1309 To: rodrigc, bz, glebius, np, melifaro, hrs, wollman, bryanv, rpaulo, adrian, gnn, hiren, rwatson, trociny, zec Cc: freebsd-virtualization, freebsd-pf, freebsd-net From owner-freebsd-net@FreeBSD.ORG Sun Dec 14 19:01:06 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0A20563 for ; Sun, 14 Dec 2014 19:01:06 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (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 CAAFEDA for ; Sun, 14 Dec 2014 19:01:06 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id sBEJ16us056203 for ; Sun, 14 Dec 2014 19:01:06 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id sBEJ16ws056202; Sun, 14 Dec 2014 19:01:06 GMT (envelope-from root) Date: Sun, 14 Dec 2014 19:01:06 +0000 To: freebsd-net@freebsd.org From: "rodrigc (Craig Rodrigues)" Subject: [Differential] [Updated] D1312: VIMAGE PF fixes #2 Message-ID: X-Priority: 3 Thread-Topic: D1312: VNET PF fixes #2 X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: OTEzZmU1MDE5NzRjYjllYzQxMmNjNjQyZWM1IFSN3nI= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 14 Dec 2014 19:01:07 -0000 rodrigc added reviewers: zec, network. REVISION DETAIL https://reviews.freebsd.org/D1312 To: rodrigc, bz, glebius, trociny, zec, np, melifaro, hrs, wollman, bryanv, rpaulo, adrian, gnn, hiren, rwatson Cc: freebsd-pf, freebsd-virtualization, freebsd-net From owner-freebsd-net@FreeBSD.ORG Sun Dec 14 19:01:46 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03950691 for ; Sun, 14 Dec 2014 19:01:46 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (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 D1A8C184 for ; Sun, 14 Dec 2014 19:01:45 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id sBEJ1juL056539 for ; Sun, 14 Dec 2014 19:01:45 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id sBEJ1jxI056538; Sun, 14 Dec 2014 19:01:45 GMT (envelope-from root) Date: Sun, 14 Dec 2014 19:01:45 +0000 To: freebsd-net@freebsd.org From: "rodrigc (Craig Rodrigues)" Subject: [Differential] [Updated] D1313: VIMAGE PF fixes #3 Message-ID: X-Priority: 3 Thread-Topic: D1313: VIMAGE PF fixes #3 X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: N2E2YTZiYWMwMDJmYzAzMTFiODgwZDc5MmEyIFSN3pk= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 14 Dec 2014 19:01:46 -0000 rodrigc added a reviewer: zec. REVISION DETAIL https://reviews.freebsd.org/D1313 To: rodrigc, bz, glebius, trociny, np, melifaro, hrs, wollman, bryanv, rpaulo, adrian, gnn, hiren, rwatson, zec Cc: freebsd-virtualization, freebsd-pf, freebsd-net From owner-freebsd-net@FreeBSD.ORG Sun Dec 14 19:36:40 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 37069E20 for ; Sun, 14 Dec 2014 19:36:40 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (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 1104A66A for ; Sun, 14 Dec 2014 19:36:40 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id sBEJadaq091450 for ; Sun, 14 Dec 2014 19:36:39 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id sBEJadC0091449; Sun, 14 Dec 2014 19:36:39 GMT (envelope-from root) Date: Sun, 14 Dec 2014 19:36:39 +0000 To: freebsd-net@freebsd.org From: "zec (Marko Zec)" Subject: [Differential] [Commented On] D1309: VIMAGE PF fixes #1 Message-ID: <12abad9d8a577648a860c2d81cfbad06@localhost.localdomain> X-Priority: 3 Thread-Topic: D1309: VIMAGE PF fixes #1 X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NzA2ZjJlODRkOGZmNmYwM2M1MmQ1N2YzYTJkIFSN5sc= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 14 Dec 2014 19:36:40 -0000 zec added inline comments. INLINE COMMENTS sys/netpfil/pf/pf_ioctl.c:3804 Perhaps SI_ORDER_MIDDLE could work here instead of (SI_ORDER_ANY - 255)? REVISION DETAIL https://reviews.freebsd.org/D1309 To: rodrigc, bz, glebius, np, melifaro, hrs, wollman, bryanv, rpaulo, adrian, gnn, hiren, rwatson, trociny, zec Cc: freebsd-virtualization, freebsd-pf, freebsd-net From owner-freebsd-net@FreeBSD.ORG Mon Dec 15 01:23:45 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 800C44F8 for ; Mon, 15 Dec 2014 01:23:45 +0000 (UTC) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4973ABA5 for ; Mon, 15 Dec 2014 01:23:45 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id z10so10688991pdj.0 for ; Sun, 14 Dec 2014 17:23:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dpdtech.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=RVHXPA2eWDZgphXuD3p41AYvUAME0gVVzHGYYRadJpU=; b=H6XlVtoKFNfELJ+kKQxrVeGafNwDzfmhgJIGik+KX5//GKjhl3r/Yg7PCTCtxxfj2m qmBztyU5XYHJ0xG3WdeAN6Io8kVbfVEFCU6yTH9drvptXKQPe50xbfGINzRbih0+BE7u 8qxTwxqjIcOD/4K3UCzotL73pc5kmD8OrP7AE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=RVHXPA2eWDZgphXuD3p41AYvUAME0gVVzHGYYRadJpU=; b=IGgameqC1d1ZhiYOJgP050nSNhW9zvfrSbXfAWyanrclvwV6tbgVKalqeAGjcUuYlX 7SEytr7uWhPsgPOyV/94xqVrvjJ1CBXSPL+2j0kPgl3sLsp7vovcaVklPnOo++ZhYbUA Ub9Kg60WOgYDEnzCTbi6K2NwLwNLmqdnf1rJZug/CzbOIqtLqfXjnPvFOYD6mvMhQSaa Wn2Ae5oKAe8ESZql6vNItWiaCc1rppc98HAANTZfujVor01g7vHlsQPpfhFcJfuznjXy J4knWrZV3EwDQIWOEMStYy55AG/9xiU1TW8Wm+NmWN9MC6sBoy09EscOB3nVYaX3ZKYM SLYg== X-Gm-Message-State: ALoCoQlmTGWqIWRQMvKTPFiQ1BU5eZMgIn6vJ7jntXCNxjGI2n/Vy4avhF9sVdTEu5FR4QlbC0X7 X-Received: by 10.70.89.174 with SMTP id bp14mr46156518pdb.136.1418606624517; Sun, 14 Dec 2014 17:23:44 -0800 (PST) Received: from 173-13-188-41-sfba.hfc.comcastbusiness.net (173-13-188-41-sfba.hfc.comcastbusiness.net. [173.13.188.41]) by mx.google.com with ESMTPSA id m3sm7496828pda.75.2014.12.14.17.23.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Dec 2014 17:23:43 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_DFDFF179-6950-4CA4-9980-D3FE7162317E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: FreeBSD 10-stable (r274577) LACP / IEEE 802.3ad with TP-Link TL-SG2008 - not working From: "David P. Discher" In-Reply-To: <3D993418-E632-44BA-8FE2-2F3F34188F20@dpdtech.com> Date: Sun, 14 Dec 2014 17:23:50 -0800 Message-Id: <34276C9E-CAEF-4E3F-AA2A-568F2D3099EC@dpdtech.com> References: <1A44709E-7D0C-4932-8A28-383EAC3F340B@dpdtech.com> <9AE69175-92D9-49FA-A651-119C7046A1FA@dpdtech.com> <5480D8EF.9000804@egr.msu.edu> <3D993418-E632-44BA-8FE2-2F3F34188F20@dpdtech.com> To: Adam McDougall X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Dec 2014 01:23:45 -0000 --Apple-Mail=_DFDFF179-6950-4CA4-9980-D3FE7162317E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 So, I think I=92ve identified the issue. In sys/net/ieee8023ad_lacp.c, = lacp_pdu_input() has a sanity check : if (m->m_pkthdr.len !=3D sizeof(*du)) { goto bad; } I added some debugging information in if_lagg, and ran with it. The = lacpdu packet that being sent by the TP-Link switch is 4 bytes longer = than the FreeBSD "struct lacpdu du=94. =20 em1: lacp_pdu_input-sizeof(du) bad m_pkthdr.len=3D128 = sizeof(du)=3D124 My packet captures shows the packet size differing as well. I=92m still poking around. I=92ve been trying to look for the official = LACPDU binary/wire format =85 if someone can point me to the reference = for that, that would be helpful (at least my own understanding).=20 Not exactly sure what these extra 4 bytes are at the end of the packet. = Still trying to figure that out. - David P. Discher http://davidpdischer.com/ AIM: DavidDPD | Y!M: daviddpdz=20 On Dec 4, 2014, at 8:41 PM, David P. Discher wrote: > Thanks Adam - >=20 > On Dec 4, 2014, at 1:58 PM, Adam McDougall = wrote: >=20 >>=20 >> Is the switch side set to "active" for the lacp mode (instead of >> passive)? Also, try: >> sysctl net.link.lagg.0.lacp.lacp_strict_mode=3D0 >>=20 >> If either of those work, I'll explain more, don't have time to dig = for >> old email right this minute. >=20 > Yes, the switch was in active mode. Turn strict mode off (which I = thought I did before, but of course this sysctl clears when destroying = the interface). So, the LACP did finally negotiated, at least in = ifconfig : --Apple-Mail=_DFDFF179-6950-4CA4-9980-D3FE7162317E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUjjgnAAoJEEmwU6XuhYWOL8IH/0q8hySF4LisSyJqae/q8eFc C1DGUrDlDJtIXz8ddtIW+/0SNtNEvxHxSokqxK2bfffr+aCoLbr/wN2SY0l99Pjx 1UKtDDzO2IORExVnJI785d4Impr00ZlQjKy/hSHVmthAVPEw20zZt1wrA1T7s7yP 2BYscWBxhqvj9LsMSdL4A7k46FqxukYekCTq7GF+Gx7mAzYXq5aWeW606zVh9e0b Q4LhqVAIl/242e3exVlnfWBrZyXvVrZiZ7qZckm4uKelKS6OojYuSl9UmqsdDOZE vE4zxUjhnvPe5gB0gwec/1fPRi/LV7zjRgKLBqCIzZEmrw5+ujJsdeeT3uvwWnU= =gOqu -----END PGP SIGNATURE----- --Apple-Mail=_DFDFF179-6950-4CA4-9980-D3FE7162317E-- From owner-freebsd-net@FreeBSD.ORG Mon Dec 15 06:49:57 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 48CC3879 for ; Mon, 15 Dec 2014 06:49:57 +0000 (UTC) Received: from mail-la0-x241.google.com (mail-la0-x241.google.com [IPv6:2a00:1450:4010:c03::241]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A7AF8D31 for ; Mon, 15 Dec 2014 06:49:56 +0000 (UTC) Received: by mail-la0-f65.google.com with SMTP id hs14so1879588lab.8 for ; Sun, 14 Dec 2014 22:49:54 -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 :content-type; bh=eZkTUMJ1Nu3w3ql0iu79bw6TKyJlnMsbClsMno126Zg=; b=ECTgO49PEg3wMNBoU/vyj+zPoKWhiUqbYt008+tphCmO7tEksJgimo0r64ovV8Kckl GzftaFW7/DdTGi9xwMdDrQif2XRbpdtTVgCchgpcWZta6PENrI/Y+2DyFb83Y1i34LUv cKegHtfmiwaSUgK9k8S8IKp15OXI34434v7+5knzOkiRNRLtW4ix5Y2oDzbHoYpCKKZ1 +cu+LOOLY+uEnOHfZkggMPW9Bo95qmwB3hBeIBDDEMQlfAg2CS79I92Wp1A0E7UaNcjo Npnq0f018IwMyTVxZmN6EW/eR3vSly4KokDJTlEZSZojFfohH9g4fvKIbA6uLcZoKCO7 hBCQ== MIME-Version: 1.0 X-Received: by 10.152.238.1 with SMTP id vg1mr29004649lac.83.1418626194612; Sun, 14 Dec 2014 22:49:54 -0800 (PST) Received: by 10.112.160.68 with HTTP; Sun, 14 Dec 2014 22:49:54 -0800 (PST) In-Reply-To: References: <20141117193354.T31139@sola.nimnet.asn.au> Date: Mon, 15 Dec 2014 14:49:54 +0800 Message-ID: Subject: Re: dragonflybsd's ipfw From: Sato Kentney To: FreeBSD Net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Dec 2014 06:49:57 -0000 hi, his ipfw2 is ok for test now. http://www.dragonflydigest.com/2014/12/11/15220.html i meet some problem in testing so asking qesstion in drafonflybsd's email list. and i want to know is it correct that the ipfw2 is faster than ipfw in freebsd? it is what he said. sure i will test it by myself. thanks On 25 November 2014 at 09:17, bycn82 wrote: > > *that ipfw2 means "ipfw too", because it is originally from FreeBSD and > totally not new create things, IMHO* > > *BTW Sato, I think the in-kernel NAT is almost there, I tested the basic > NAT and it works in my lab environment.* > > > On Tue, Nov 18, 2014 at 9:38 AM, Sato Kentney > wrote: > >> i agree, >> i am not good in english as networking administor from Tokyo. >> but when i read the page, i see that the main idea is so call "modular >> design" and there is a long way to catch up the freebsd's ipfw >> >> anyway, i dont think it can compare to freebsd's ipfw, as Smith said the= ir >> ipfw is the version without in-kernel NAT and tables .all these importan= t >> features >> >> On Mon, Nov 17, 2014 at 5:07 PM, Ian Smith wrote: >> >> > On Mon, 17 Nov 2014 15:48:13 +0800, Sato Kentney wrote: >> > >> > > I saw a email in dragonflybsd email list, someone is doing this! >> > > http://www.dragonflybsd.org/docs/ipfw2/ >> > >> > We've had 'ipfw2' for a very long while. I couldn't help wondering wh= y >> > DF wouldn't just import our many years of development and experience >> > rather than using bycn82's 'rewrite'? .. but DF already has ipfw2: >> > >> > http://leaf.dragonflybsd.org/cgi/web-man?command=3Dipfw§ion=3DANY >> > >> > man page dated October 2008. Before tables, in-kernel NAT, later >> > dummynet updates and no doubt more. So why not start from there? >> > >> > cheers, Ian >> > >> >> >> >> -- >> =E3=81=82=E3=82=8A=E3=81=8C=E3=81=A8=E3=81=86 >> =E4=BD=90=E8=97=A4=E6=9F=AF=E5=BE=B7 >> Sato K. >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > --=20 =E3=81=82=E3=82=8A=E3=81=8C=E3=81=A8=E3=81=86 =E4=BD=90=E8=97=A4=E6=9F=AF=E5=BE=B7 Sato K. From owner-freebsd-net@FreeBSD.ORG Mon Dec 15 07:26:20 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6312AC1D for ; Mon, 15 Dec 2014 07:26:20 +0000 (UTC) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D5CA1DC for ; Mon, 15 Dec 2014 07:26:19 +0000 (UTC) Received: by mail-la0-f51.google.com with SMTP id ms9so8880925lab.38 for ; Sun, 14 Dec 2014 23:26:18 -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:content-transfer-encoding; bh=+9pMggi5y+/+73g+aE1G/ZvXyS6JX1WZZGsvzLTWgTM=; b=L1ZKysLQBe43A4ftd7/ofC+g1xjI6mx60qUDWBIxLMtCNrNcj6MFQE5NKIMfWc9wFI 1cS4xUgODdCoCS7hG7IazoKqOKxPgYfSfX9KqqP0erJIoPif2B9wsL4oxoDZFjFzw3kT hJOBDP8QnPK+zETKz+nm4ikBrnKaqObatMgIjXtq5dk/iat/9c/MjrPTPZjx1zXviePT Lf9AlY/iEOlYosaIfoR/bzca+lggeckKnies+5ioLvVpYQzs04sSnyL3b6s1cFO1THo9 o1iTKD93vmpXj+K4mm83GfihWELZXfBx2RL5X7tBR0McaEOjZoyycr+/Rrg+/E2DxcWe ReCA== MIME-Version: 1.0 X-Received: by 10.152.19.71 with SMTP id c7mr28841513lae.79.1418628377886; Sun, 14 Dec 2014 23:26:17 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.174.169 with HTTP; Sun, 14 Dec 2014 23:26:17 -0800 (PST) In-Reply-To: References: <20141117193354.T31139@sola.nimnet.asn.au> Date: Mon, 15 Dec 2014 08:26:17 +0100 X-Google-Sender-Auth: g-CjRYrl_utBHEkgBOJPeyASxrk Message-ID: Subject: Re: dragonflybsd's ipfw From: Luigi Rizzo To: Sato Kentney Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Dec 2014 07:26:20 -0000 On Mon, Dec 15, 2014 at 7:49 AM, Sato Kentney wrote= : > hi, > his ipfw2 is ok for test now. > http://www.dragonflydigest.com/2014/12/11/15220.html > i meet some problem in testing so asking qesstion in drafonflybsd's email > list. > and i want to know is it correct that the ipfw2 is faster than ipfw in > freebsd? it is what he said. i don't think he ever said that, and in any case the code seems to be taken straight from the 2002 freebsd version so i highly doubt there is any speed difference (let alone a measurable one with packets going through the kernel stack; to see an actual performance difference you'd need to run the code through netmap or some high speed framework) see http://code.google.com/p/netmap-ipfw/ cheers luigi > sure i will test it by myself. > thanks > > On 25 November 2014 at 09:17, bycn82 wrote: >> >> *that ipfw2 means "ipfw too", because it is originally from FreeBSD and >> totally not new create things, IMHO* >> >> *BTW Sato, I think the in-kernel NAT is almost there, I tested the basic >> NAT and it works in my lab environment.* >> >> >> On Tue, Nov 18, 2014 at 9:38 AM, Sato Kentney >> wrote: >> >>> i agree, >>> i am not good in english as networking administor from Tokyo. >>> but when i read the page, i see that the main idea is so call "modular >>> design" and there is a long way to catch up the freebsd's ipfw >>> >>> anyway, i dont think it can compare to freebsd's ipfw, as Smith said th= eir >>> ipfw is the version without in-kernel NAT and tables .all these importa= nt >>> features >>> >>> On Mon, Nov 17, 2014 at 5:07 PM, Ian Smith wrote= : >>> >>> > On Mon, 17 Nov 2014 15:48:13 +0800, Sato Kentney wrote: >>> > >>> > > I saw a email in dragonflybsd email list, someone is doing this! >>> > > http://www.dragonflybsd.org/docs/ipfw2/ >>> > >>> > We've had 'ipfw2' for a very long while. I couldn't help wondering w= hy >>> > DF wouldn't just import our many years of development and experience >>> > rather than using bycn82's 'rewrite'? .. but DF already has ipfw2: >>> > >>> > http://leaf.dragonflybsd.org/cgi/web-man?command=3Dipfw§ion=3DANY >>> > >>> > man page dated October 2008. Before tables, in-kernel NAT, later >>> > dummynet updates and no doubt more. So why not start from there? >>> > >>> > cheers, Ian >>> > >>> >>> >>> >>> -- >>> =E3=81=82=E3=82=8A=E3=81=8C=E3=81=A8=E3=81=86 >>> =E4=BD=90=E8=97=A4=E6=9F=AF=E5=BE=B7 >>> Sato K. >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >> >> > > -- > =E3=81=82=E3=82=8A=E3=81=8C=E3=81=A8=E3=81=86 > =E4=BD=90=E8=97=A4=E6=9F=AF=E5=BE=B7 > Sato K. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" --=20 -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Mon Dec 15 08:34:38 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 84137F13 for ; Mon, 15 Dec 2014 08:34:38 +0000 (UTC) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E23E3992 for ; Mon, 15 Dec 2014 08:34:37 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id p9so8768792lbv.0 for ; Mon, 15 Dec 2014 00:34:34 -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=OT2blEnq96JffyB0fp64URBu0JnQBVOJWk9GBjDYW0c=; b=pukx8VS6Zm4gUdYpn0g8aq16lBakd/7Lt3yuYieUtHfg5ugnhx4O8Kh5laBgBDThhs FWI8yjFDrAPTW6Hw70qv1vohwF5oxvh3RQMc55R2CX+uDx4DKU82yJfLkoXm+KmbTV92 dz/iJ1fMqzRm1cC3JhyedLxUFZAWJjnWqM61WD8FTMFj5C543tvot4R+wptgbtlTNTrI L4Mp8V3g4RLAahscG1kI7VzoaUBvG01KPTLbRcMmU1uPY68CPX3cZzSwY21e8nA7PJCA /ww/hQQuoWXJpI3016myIrM9xEuAUqgMw8jXPZ3pF9Q5Q73+86R2LU4RGr1l1XN10DgG npyQ== MIME-Version: 1.0 X-Received: by 10.112.210.100 with SMTP id mt4mr28827930lbc.31.1418632474646; Mon, 15 Dec 2014 00:34:34 -0800 (PST) Received: by 10.112.160.68 with HTTP; Mon, 15 Dec 2014 00:34:34 -0800 (PST) In-Reply-To: References: <20141117193354.T31139@sola.nimnet.asn.au> Date: Mon, 15 Dec 2014 16:34:34 +0800 Message-ID: Subject: Re: dragonflybsd's ipfw From: Sato Kentney To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Dec 2014 08:34:38 -0000 hi ok. i will test it. but he said it is faster 2014-12-15 15:26 GMT+08:00 Luigi Rizzo : > > On Mon, Dec 15, 2014 at 7:49 AM, Sato Kentney > wrote: > > hi, > > his ipfw2 is ok for test now. > > http://www.dragonflydigest.com/2014/12/11/15220.html > > i meet some problem in testing so asking qesstion in drafonflybsd's ema= il > > list. > > and i want to know is it correct that the ipfw2 is faster than ipfw in > > freebsd? it is what he said. > > i don't think he ever said that, and in any case the code seems to be > taken straight from the 2002 freebsd version so i highly doubt there > is any speed difference (let alone a measurable one with packets > going through the kernel stack; to see an actual performance difference > you'd need to run the code through netmap or some high speed framework) > > see http://code.google.com/p/netmap-ipfw/ > > cheers > luigi > > > sure i will test it by myself. > > thanks > > > > On 25 November 2014 at 09:17, bycn82 wrote: > >> > >> *that ipfw2 means "ipfw too", because it is originally from FreeBSD an= d > >> totally not new create things, IMHO* > >> > >> *BTW Sato, I think the in-kernel NAT is almost there, I tested the bas= ic > >> NAT and it works in my lab environment.* > >> > >> > >> On Tue, Nov 18, 2014 at 9:38 AM, Sato Kentney > >> wrote: > >> > >>> i agree, > >>> i am not good in english as networking administor from Tokyo. > >>> but when i read the page, i see that the main idea is so call "modula= r > >>> design" and there is a long way to catch up the freebsd's ipfw > >>> > >>> anyway, i dont think it can compare to freebsd's ipfw, as Smith said > their > >>> ipfw is the version without in-kernel NAT and tables .all these > important > >>> features > >>> > >>> On Mon, Nov 17, 2014 at 5:07 PM, Ian Smith > wrote: > >>> > >>> > On Mon, 17 Nov 2014 15:48:13 +0800, Sato Kentney wrote: > >>> > > >>> > > I saw a email in dragonflybsd email list, someone is doing this! > >>> > > http://www.dragonflybsd.org/docs/ipfw2/ > >>> > > >>> > We've had 'ipfw2' for a very long while. I couldn't help wondering > why > >>> > DF wouldn't just import our many years of development and experienc= e > >>> > rather than using bycn82's 'rewrite'? .. but DF already has ipfw2: > >>> > > >>> > http://leaf.dragonflybsd.org/cgi/web-man?command=3Dipfw§ion=3DA= NY > >>> > > >>> > man page dated October 2008. Before tables, in-kernel NAT, later > >>> > dummynet updates and no doubt more. So why not start from there? > >>> > > >>> > cheers, Ian > >>> > > >>> > >>> > >>> > >>> -- > >>> =E3=81=82=E3=82=8A=E3=81=8C=E3=81=A8=E3=81=86 > >>> =E4=BD=90=E8=97=A4=E6=9F=AF=E5=BE=B7 > >>> Sato K. > >>> _______________________________________________ > >>> freebsd-net@freebsd.org mailing list > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net > >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org= " > >>> > >> > >> > > > > -- > > =E3=81=82=E3=82=8A=E3=81=8C=E3=81=A8=E3=81=86 > > =E4=BD=90=E8=97=A4=E6=9F=AF=E5=BE=B7 > > Sato K. > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > -- > -----------------------------------------+------------------------------- > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL +39-050-2211611 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > -----------------------------------------+------------------------------- > --=20 =E3=81=82=E3=82=8A=E3=81=8C=E3=81=A8=E3=81=86 =E4=BD=90=E8=97=A4=E6=9F=AF=E5=BE=B7 Sato K. From owner-freebsd-net@FreeBSD.ORG Mon Dec 15 08:35:38 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 12D6616D; Mon, 15 Dec 2014 08:35:38 +0000 (UTC) Received: from tweddell.vserver-on.de (tweddell.de [84.38.66.62]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CB1FE9A9; Mon, 15 Dec 2014 08:35:36 +0000 (UTC) Received: from bastian by tweddell.vserver-on.de with local (Exim 4.80) (envelope-from ) id 1Y0R7o-0008LN-6h; Mon, 15 Dec 2014 09:35:28 +0100 Date: Mon, 15 Dec 2014 09:35:28 +0100 From: Bastian To: Adrian Chadd Subject: Re: iwn fails to scan on E6330 Message-ID: <20141215083528.GC3143@tweddell.de> References: <20141124141234.GG30752@tweddell.de> <20141125213150.GH30752@tweddell.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Dec 2014 08:35:38 -0000 On 25Nov14 17:10 -0800, Adrian Chadd wrote: > You can use service to shut down a single interface - I don't recall > why. Try service netif stop wlan0 ? Thanks. That works. Problem was to switch over from wifi to lan and back and forth. Lan and Wifi network are not in the same segment, thus lagg does not work. In addition, my network ops will kill me if I change the MAC. Cheers, -- Bastian From owner-freebsd-net@FreeBSD.ORG Mon Dec 15 09:32:18 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 991A2EC0 for ; Mon, 15 Dec 2014 09:32:18 +0000 (UTC) Received: from umail.aei.mpg.de (umail.aei.mpg.de [194.94.224.6]) (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 48079F99 for ; Mon, 15 Dec 2014 09:32:18 +0000 (UTC) Received: from mailgate.aei.mpg.de (mailgate.aei.mpg.de [194.94.224.5]) by umail.aei.mpg.de (Postfix) with ESMTP id 59FA5200D38 for ; Mon, 15 Dec 2014 10:24:40 +0100 (CET) Received: from mailgate.aei.mpg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4B4B1405889 for ; Mon, 15 Dec 2014 10:24:40 +0100 (CET) Received: from intranet.aei.uni-hannover.de (ahin1.aei.uni-hannover.de [130.75.117.40]) by mailgate.aei.mpg.de (Postfix) with ESMTP id 22C6F406AF1 for ; Mon, 15 Dec 2014 10:24:40 +0100 (CET) Received: from arc.aei.uni-hannover.de ([10.117.15.110]) by intranet.aei.uni-hannover.de (Lotus Domino Release 8.5.3FP6HF1016) with ESMTP id 2014121510242966-68586 ; Mon, 15 Dec 2014 10:24:29 +0100 Date: Mon, 15 Dec 2014 10:24:29 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: freebsd-net@freebsd.org Subject: compiling on nfs directories Message-Id: <20141215102429.bcbae18ae63464a7254fc580@aei.mpg.de> Organization: Max Planck Gesellschaft X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on intranet/aei-hannover(Release 8.5.3FP6HF1016 | October 31, 2014) at 15.12.2014 10:24:29, Serialize by Router on intranet/aei-hannover(Release 8.5.3FP6HF1016 | October 31, 2014) at 15.12.2014 10:24:39, Serialize complete at 15.12.2014 10:24:39 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-PMX-Version: 6.0.2.2308539, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.15.91527 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, MIME_LOWER_CASE 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1100_1199 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, NO_URI_FOUND 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_FROM 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __SUBJ_ALPHA_START 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0' X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Dec 2014 09:32:18 -0000 Hi all, I ran into some weird issue here last week: I have an NFS-Server for storage and diskless booting (pxe / nfs root) running under FreeBSD. The clients are running Gentoo Linux. Some time ago, I replaced the server, going from a HDD-based storage array (ZFS) under FreeBSD 8.3 to an SSD-based array under FreeBSD 10-stable (as of February this year - I know this needs updates). Only now I recognized that this somehow appears to have broken some of my Gentoo ebuilds that do not install cleanly anymore. They complain about "soiled libtool library files found" and "insecure RUNPATHs" in the installation stage of shared libs. I was not able to find any useful solution for this in the Net so far. However, I was able to verify that this is somehow an issue with the nfs server by plugging in a USB-drive into the diskless clients and mounting this as /var/tmp/portage (the directory structure where Gentoo's ebuilds are compiled). This makes the error messages go away, and everything works again (like it did before the server update). Are there any suggestions what might be causing this and how to fix it? cu Gerrit From owner-freebsd-net@FreeBSD.ORG Mon Dec 15 12:10:13 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8579054E for ; Mon, 15 Dec 2014 12:10:13 +0000 (UTC) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C85923E for ; Mon, 15 Dec 2014 12:10:13 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id eu11so11733592pac.11 for ; Mon, 15 Dec 2014 04:10:13 -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=jXNfGR/9dnhM1fOxsaWs23/wsC+SPKdUhqm9tlv1M10=; b=nksKnB+Cdaa8XxSdaonfkmGXE1mMWo5oESXnngSr7BB3GXZxyNx8mJd2G6ztx3ta+E yobW/XLRXiipgug51XBs6PgZ6nl5O24lBkp1Jcl2Qj/Q9+xdNKsr7Ge7jtQ5qMn++UFx oU01zSdbBIcxcfniMNW74znqaKBOJDdtEBuzlIBSM5XLRlFHjItvuLm1XMhbWoLJ6D0G OzfQpt9dwff4OU0xz/DjEGtJmduvtTS0ftSI6U/VVOnmE2oojldRXGLXa+cBfBY63DqT fRPmkoh+JkSCEzeAGRC/lIZqzNZTttoOXI97oRwgsuU9AuIE8EBiSlbSk8oFaiRrl3Wz WrRw== MIME-Version: 1.0 X-Received: by 10.68.221.106 with SMTP id qd10mr50211105pbc.98.1418645412784; Mon, 15 Dec 2014 04:10:12 -0800 (PST) Received: by 10.70.35.9 with HTTP; Mon, 15 Dec 2014 04:10:12 -0800 (PST) In-Reply-To: References: <20141117193354.T31139@sola.nimnet.asn.au> Date: Mon, 15 Dec 2014 20:10:12 +0800 Message-ID: Subject: Re: dragonflybsd's ipfw From: bycn82 To: Sato Kentney Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Luigi Rizzo , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Dec 2014 12:10:13 -0000 *Hi Sato,* *I am also in this email list, If you have any question, You can ask,I just double checked whether I made mistake or not, and I only found "**To be honest, my rewrite version of ipfw2 is nothing special but it runs on this great system". So **please make me a joker in front of all these big bosses. * *Compare to the ipfw in FreeBSD, there are few differences. not a big deal.= * *1. modular* *2. lock-less* *3. old version* *Regards,* *Bycn82* On Mon, Dec 15, 2014 at 4:34 PM, Sato Kentney wrote= : > > hi > ok. i will test it. > but he said it is faster > > 2014-12-15 15:26 GMT+08:00 Luigi Rizzo : > > > > On Mon, Dec 15, 2014 at 7:49 AM, Sato Kentney > > wrote: > > > hi, > > > his ipfw2 is ok for test now. > > > http://www.dragonflydigest.com/2014/12/11/15220.html > > > i meet some problem in testing so asking qesstion in drafonflybsd's > email > > > list. > > > and i want to know is it correct that the ipfw2 is faster than ipfw i= n > > > freebsd? it is what he said. > > > > i don't think he ever said that, and in any case the code seems to be > > taken straight from the 2002 freebsd version so i highly doubt there > > is any speed difference (let alone a measurable one with packets > > going through the kernel stack; to see an actual performance difference > > you'd need to run the code through netmap or some high speed framework) > > > > see http://code.google.com/p/netmap-ipfw/ > > > > cheers > > luigi > > > > > sure i will test it by myself. > > > thanks > > > > > > On 25 November 2014 at 09:17, bycn82 wrote: > > >> > > >> *that ipfw2 means "ipfw too", because it is originally from FreeBSD > and > > >> totally not new create things, IMHO* > > >> > > >> *BTW Sato, I think the in-kernel NAT is almost there, I tested the > basic > > >> NAT and it works in my lab environment.* > > >> > > >> > > >> On Tue, Nov 18, 2014 at 9:38 AM, Sato Kentney > > >> wrote: > > >> > > >>> i agree, > > >>> i am not good in english as networking administor from Tokyo. > > >>> but when i read the page, i see that the main idea is so call > "modular > > >>> design" and there is a long way to catch up the freebsd's ipfw > > >>> > > >>> anyway, i dont think it can compare to freebsd's ipfw, as Smith sai= d > > their > > >>> ipfw is the version without in-kernel NAT and tables .all these > > important > > >>> features > > >>> > > >>> On Mon, Nov 17, 2014 at 5:07 PM, Ian Smith > > wrote: > > >>> > > >>> > On Mon, 17 Nov 2014 15:48:13 +0800, Sato Kentney wrote: > > >>> > > > >>> > > I saw a email in dragonflybsd email list, someone is doing thi= s! > > >>> > > http://www.dragonflybsd.org/docs/ipfw2/ > > >>> > > > >>> > We've had 'ipfw2' for a very long while. I couldn't help wonderi= ng > > why > > >>> > DF wouldn't just import our many years of development and > experience > > >>> > rather than using bycn82's 'rewrite'? .. but DF already has ipfw2= : > > >>> > > > >>> > http://leaf.dragonflybsd.org/cgi/web-man?command=3Dipfw§ion= =3DANY > > >>> > > > >>> > man page dated October 2008. Before tables, in-kernel NAT, later > > >>> > dummynet updates and no doubt more. So why not start from there? > > >>> > > > >>> > cheers, Ian > > >>> > > > >>> > > >>> > > >>> > > >>> -- > > >>> =E3=81=82=E3=82=8A=E3=81=8C=E3=81=A8=E3=81=86 > > >>> =E4=BD=90=E8=97=A4=E6=9F=AF=E5=BE=B7 > > >>> Sato K. > > >>> _______________________________________________ > > >>> freebsd-net@freebsd.org mailing list > > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net > > >>> To unsubscribe, send any mail to " > freebsd-net-unsubscribe@freebsd.org" > > >>> > > >> > > >> > > > > > > -- > > > =E3=81=82=E3=82=8A=E3=81=8C=E3=81=A8=E3=81=86 > > > =E4=BD=90=E8=97=A4=E6=9F=AF=E5=BE=B7 > > > Sato K. > > > _______________________________________________ > > > freebsd-net@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org= " > > > > > > > > -- > > -----------------------------------------+-----------------------------= -- > > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazion= e > > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > > TEL +39-050-2211611 . via Diotisalvi 2 > > Mobile +39-338-6809875 . 56122 PISA (Italy) > > -----------------------------------------+-----------------------------= -- > > > > > -- > =E3=81=82=E3=82=8A=E3=81=8C=E3=81=A8=E3=81=86 > =E4=BD=90=E8=97=A4=E6=9F=AF=E5=BE=B7 > Sato K. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Dec 15 12:11:31 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B27AA5F0 for ; Mon, 15 Dec 2014 12:11:31 +0000 (UTC) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 78761309 for ; Mon, 15 Dec 2014 12:11:31 +0000 (UTC) Received: by mail-pd0-f177.google.com with SMTP id ft15so11526302pdb.36 for ; Mon, 15 Dec 2014 04:11:30 -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=m/0KgyAKLjVAv18FeBHVQlZ6Lf5UnoCJMKu8AoQFEkI=; b=fYDg9e2KBDf95eRK6jqV91o5MLc5LzijK4invRIhSJ6nScJYyJE4R/T93E9NhLt68w 5rbM64b8QRG9qZwiMkN3yxtBGFxlGmD6dJYu9H8nKmKmUzvELIKe7NokMHK4fArI7gJN ZTxjCUOJPh+1GVmb7BjGs/KhnFS5nAGzH+QThoRh6ykIkViyPBSUYQTJBbXau9fEYdMq 7uvl1AUwTiCz2RcIpKQxk3KXjXdwntWgCZUG5JSERcibR7gMBtL85b0Fn0cdeHKANRiC Qgx/Kh6UrVbaohfHglPoqDgRzUMvZxvl/ETt/jRnBC7v7yvkIkPNfO0s9EYmH9Pd1Y8m /qlA== MIME-Version: 1.0 X-Received: by 10.70.42.142 with SMTP id o14mr50881013pdl.17.1418645490614; Mon, 15 Dec 2014 04:11:30 -0800 (PST) Received: by 10.70.35.9 with HTTP; Mon, 15 Dec 2014 04:11:30 -0800 (PST) In-Reply-To: References: <20141117193354.T31139@sola.nimnet.asn.au> Date: Mon, 15 Dec 2014 20:11:30 +0800 Message-ID: Subject: Re: dragonflybsd's ipfw From: bycn82 To: Sato Kentney Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Luigi Rizzo , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Dec 2014 12:11:31 -0000 *So **please DON'T make me a joker in front of all these big bosses. * On Mon, Dec 15, 2014 at 8:10 PM, bycn82 wrote: > > *Hi Sato,* > > *I am also in this email list, If you have any question, You can ask,I > just double checked whether I made mistake or not, and I only found "**To > be honest, my rewrite version of ipfw2 is nothing special but it runs on > this great system". So **please make me a joker in front of all these big > bosses. * > > *Compare to the ipfw in FreeBSD, there are few differences. not a big > deal.* > *1. modular* > *2. lock-less* > *3. old version* > > *Regards,* > *Bycn82* > > On Mon, Dec 15, 2014 at 4:34 PM, Sato Kentney > wrote: >> >> hi >> ok. i will test it. >> but he said it is faster >> >> 2014-12-15 15:26 GMT+08:00 Luigi Rizzo : >> > >> > On Mon, Dec 15, 2014 at 7:49 AM, Sato Kentney >> > wrote: >> > > hi, >> > > his ipfw2 is ok for test now. >> > > http://www.dragonflydigest.com/2014/12/11/15220.html >> > > i meet some problem in testing so asking qesstion in drafonflybsd's >> email >> > > list. >> > > and i want to know is it correct that the ipfw2 is faster than ipfw = in >> > > freebsd? it is what he said. >> > >> > i don't think he ever said that, and in any case the code seems to be >> > taken straight from the 2002 freebsd version so i highly doubt there >> > is any speed difference (let alone a measurable one with packets >> > going through the kernel stack; to see an actual performance differenc= e >> > you'd need to run the code through netmap or some high speed framework= ) >> > >> > see http://code.google.com/p/netmap-ipfw/ >> > >> > cheers >> > luigi >> > >> > > sure i will test it by myself. >> > > thanks >> > > >> > > On 25 November 2014 at 09:17, bycn82 wrote: >> > >> >> > >> *that ipfw2 means "ipfw too", because it is originally from FreeBSD >> and >> > >> totally not new create things, IMHO* >> > >> >> > >> *BTW Sato, I think the in-kernel NAT is almost there, I tested the >> basic >> > >> NAT and it works in my lab environment.* >> > >> >> > >> >> > >> On Tue, Nov 18, 2014 at 9:38 AM, Sato Kentney > > >> > >> wrote: >> > >> >> > >>> i agree, >> > >>> i am not good in english as networking administor from Tokyo. >> > >>> but when i read the page, i see that the main idea is so call >> "modular >> > >>> design" and there is a long way to catch up the freebsd's ipfw >> > >>> >> > >>> anyway, i dont think it can compare to freebsd's ipfw, as Smith sa= id >> > their >> > >>> ipfw is the version without in-kernel NAT and tables .all these >> > important >> > >>> features >> > >>> >> > >>> On Mon, Nov 17, 2014 at 5:07 PM, Ian Smith >> > wrote: >> > >>> >> > >>> > On Mon, 17 Nov 2014 15:48:13 +0800, Sato Kentney wrote: >> > >>> > >> > >>> > > I saw a email in dragonflybsd email list, someone is doing >> this! >> > >>> > > http://www.dragonflybsd.org/docs/ipfw2/ >> > >>> > >> > >>> > We've had 'ipfw2' for a very long while. I couldn't help >> wondering >> > why >> > >>> > DF wouldn't just import our many years of development and >> experience >> > >>> > rather than using bycn82's 'rewrite'? .. but DF already has ipfw= 2: >> > >>> > >> > >>> > http://leaf.dragonflybsd.org/cgi/web-man?command=3Dipfw§ion= =3DANY >> > >>> > >> > >>> > man page dated October 2008. Before tables, in-kernel NAT, late= r >> > >>> > dummynet updates and no doubt more. So why not start from there= ? >> > >>> > >> > >>> > cheers, Ian >> > >>> > >> > >>> >> > >>> >> > >>> >> > >>> -- >> > >>> =E3=81=82=E3=82=8A=E3=81=8C=E3=81=A8=E3=81=86 >> > >>> =E4=BD=90=E8=97=A4=E6=9F=AF=E5=BE=B7 >> > >>> Sato K. >> > >>> _______________________________________________ >> > >>> freebsd-net@freebsd.org mailing list >> > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> > >>> To unsubscribe, send any mail to " >> freebsd-net-unsubscribe@freebsd.org" >> > >>> >> > >> >> > >> >> > > >> > > -- >> > > =E3=81=82=E3=82=8A=E3=81=8C=E3=81=A8=E3=81=86 >> > > =E4=BD=90=E8=97=A4=E6=9F=AF=E5=BE=B7 >> > > Sato K. >> > > _______________________________________________ >> > > freebsd-net@freebsd.org mailing list >> > > http://lists.freebsd.org/mailman/listinfo/freebsd-net >> > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.or= g >> " >> > >> > >> > >> > -- >> > >> -----------------------------------------+------------------------------= - >> > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. >> dell'Informazione >> > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa >> > TEL +39-050-2211611 . via Diotisalvi 2 >> > Mobile +39-338-6809875 . 56122 PISA (Italy) >> > >> -----------------------------------------+------------------------------= - >> > >> >> >> -- >> =E3=81=82=E3=82=8A=E3=81=8C=E3=81=A8=E3=81=86 >> =E4=BD=90=E8=97=A4=E6=9F=AF=E5=BE=B7 >> Sato K. >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > From owner-freebsd-net@FreeBSD.ORG Mon Dec 15 12:26:23 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E11CB02 for ; Mon, 15 Dec 2014 12:26:23 +0000 (UTC) Received: from leviatan.freebsdbrasil.com.br (leviatan.freebsdbrasil.com.br [177.10.156.9]) (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 D8FAB60F for ; Mon, 15 Dec 2014 12:26:22 +0000 (UTC) Received: (qmail 6647 invoked from network); 15 Dec 2014 10:26:01 -0200 Received: from darwin.bh.freebsdbrasil.com.br (eksffa@freebsdbrasil.com.br@[10.69.69.7]) (envelope-sender ) by capeta.freebsdbrasil.com.br (qmail-ldap-1.03) with SMTP for ; 15 Dec 2014 10:26:01 -0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: Can DUMMYNET handle weighting of traffic according to firewall rules? From: Patrick Tracanelli In-Reply-To: <201412141635.JAA27068@mail.lariat.net> Date: Mon, 15 Dec 2014 10:26:01 -0200 Content-Transfer-Encoding: quoted-printable Message-Id: <59E7D981-B28B-4995-B8F4-6A2687CEF265@freebsdbrasil.com.br> References: <028d142b3a17cd5ffd5f21c6f9b9d6daaa8e2780@webmail.freebsdbrasil.com.br> <201412141635.JAA27068@mail.lariat.net> To: Brett Glass X-Mailer: Apple Mail (2.1993) Cc: John Nielsen , Luigi Rizzo , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Dec 2014 12:26:23 -0000 > On 14/12/2014, at 14:25, Brett Glass wrote: >=20 > At 11:02 AM 12/13/2014, eksffa@freebsdbrasil.com.br wrote: > =20 >> As I understand the problem, there are many ways to do this without = actually using any special feature on dummynet. =46rom tagging a traffic = twice and feeding both tagged flows to the same pipe, to the easiest and = possibily lighter approach of disabling one pass and feeding the traffic = twice to the same pipe. >=20 > Unfortunately, feeding the traffic to the same pipe more than once = would have some undesirable side effects. It would mean incurring X = times the delay and computational overhead introduced by the pipe. Yes, it would. But should only be a big deal if you have too much pps = and low CPU to deal with the volume. > This would affect not only latency but also jitter, because DUMMYNET = pipes are driven by timer interrupts. I don=E2=80=99t quite agree, if you have enough CPU to pipe it together. = I run a number of setups where a WF2Qp or QFQ setup does the weighting = and later an extra pipe imposes other individual limits. Proper queue and HZ tuning tend to do the job while you have enough CPU = to deal with interrupts. > Even if you set the kernel's HZ setting to a high number, you could = have milliseconds of difference in the latency depending upon a packet's = precise arrival time and the amount of traffic. If DUMMYNET was in = "fast" mode, there would also be a very big jump in latency when the = pipe neared capacity. This is just theory. And I don=E2=80=99t mean it=E2=80=99s wrong. There = could certainly be a better way to add an extra cost factor to a flow, = but the pure fact is you don=E2=80=99t have it today. Let=E2=80=99s be = practical, how much bw are we talking about and how much CPU?=20 Even if we are talking about a lot of bandwidth, you have many tuning = possibilities and you have netmap-aware dummynet to deal with high pps = rate. > X could only be a whole number unless you fed the pipe multiple times = in EACH direction. As I understand your problem you would need to feed a flow in the = opposite direction to the same pipe anyway. So it=E2=80=99s just a matter of 3 flows instead of 2. I insist, not the = beautiful approach, but not a big deal, unless we are talking about = 10G/40G connections or a server with 10yo computing power. > And turning off the "one_pass" feature would add to the overhead of = EVERY pipe used in the system. That=E2=80=99s not true. Having one_pass disable is a mostly a needed = feature if you have complex environments with a mix of filtering and = queueing, otherwise a single match in a pipe will result in a pass = behavior. If you don=E2=80=99t match a traffic twice to a pipe one_pass = will make not difference to dummynet at all, adding no overhead. = Remember that one_pass is an ipfw feature, not dummynet specific, and if = overhead will be added anywhere, it=E2=80=99s on ipfw that will just = keep the packet injected and keep processing until a filtering match is = found, which can be the next rule.=20 > It would be much more desirable to be able to specify a cost factor = for a packet entering the pipe, as Luigi mentioned, so that the pipe = could simply adjust its "score" to reflect the higher overhead of = upstream vs. downstream traffic. Sure it would be more desirable not just for your needs, but for = dummynet feature set as a whole. But that=E2=80=99s just not something = you have today. > If it's really a one-line patch to the kernel, I'd like to try doing = this and then submit a patch to add the feature if it works. That would be great for sure. But as Luigi mentioned this is not that simple for the UI which seems = many times to be more complex to extend than the kernel features itself, = without breaking other stuff or requiring .h handling somehow that would = make a -STABLE merge not simple. But anyway, after adding a cost factor and handling UI extending, how = would you solve the need to inject both RX and TX traffic to the same = pipe? You will need to match it twice against the same pipe anyway. No 3 = times but twice at least, no matter with or without one_pass. >=20 > --Brett Glass -- Patrick Tracanelli From owner-freebsd-net@FreeBSD.ORG Mon Dec 15 15:04:35 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A2A7E4BE for ; Mon, 15 Dec 2014 15:04:35 +0000 (UTC) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5CB5DA1D for ; Mon, 15 Dec 2014 15:04:35 +0000 (UTC) Received: by mail-yk0-f176.google.com with SMTP id q200so4946076ykb.7 for ; Mon, 15 Dec 2014 07:04:34 -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=SKHPvyiXTZbVjHW8yZEUrW8N0L87a0nBNMp+3Eui3T0=; b=IyFkRg/e6z8gcKQ3WRSh0IJWy+MWbcD4k+LGgeKO9bpot3qsLNg/U3YyARPneJ06fv hUDat5KOFkrSit1CTswtI9yHd11bvti/8+EacweSwXcynFtc0cQS2//C6n8OulGB+qHD TVarPhbJ7Vn7LNA/421MlvxLy9eIigEkcEoEVznYNjiHvGnoU1ugVxqlwqc6g0kBkmzg RCJY+0WoL52dYa0hpRY8cGbUX0QfgHhvGuioQ13BGY3NWJaBZlT992eF+fZVRCbOA/ZH ZKlU/EeLUkKJY9kpOHuipyDHVP2GXe6eoSqWPB7NjpQxlL0hvOFuvBX3pnmaUXz0Ig8+ LlmA== MIME-Version: 1.0 X-Received: by 10.236.26.43 with SMTP id b31mr5365480yha.53.1418655874434; Mon, 15 Dec 2014 07:04:34 -0800 (PST) Received: by 10.170.90.131 with HTTP; Mon, 15 Dec 2014 07:04:34 -0800 (PST) In-Reply-To: <20141215102429.bcbae18ae63464a7254fc580@aei.mpg.de> References: <20141215102429.bcbae18ae63464a7254fc580@aei.mpg.de> Date: Mon, 15 Dec 2014 07:04:34 -0800 Message-ID: Subject: Re: compiling on nfs directories From: Mehmet Erol Sanliturk To: =?UTF-8?B?R2Vycml0IEvDvGhu?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Dec 2014 15:04:35 -0000 On Mon, Dec 15, 2014 at 1:24 AM, Gerrit K=C3=BChn wrote: > > Hi all, > > I ran into some weird issue here last week: > I have an NFS-Server for storage and diskless booting (pxe / nfs root) > running under FreeBSD. The clients are running Gentoo Linux. Some time > ago, I replaced the server, going from a HDD-based storage array (ZFS) > under FreeBSD 8.3 to an SSD-based array under FreeBSD 10-stable (as of > February this year - I know this needs updates). > > Only now I recognized that this somehow appears to have broken some of my > Gentoo ebuilds that do not install cleanly anymore. They complain about > "soiled libtool library files found" and "insecure RUNPATHs" in the > installation stage of shared libs. > > I was not able to find any useful solution for this in the Net so far. > However, I was able to verify that this is somehow an issue with the nfs > server by plugging in a USB-drive into the diskless clients and mounting > this as /var/tmp/portage (the directory structure where Gentoo's ebuilds > are compiled). This makes the error messages go away, and everything work= s > again (like it did before the server update). > > Are there any suggestions what might be causing this and how to fix it? > > > cu > Gerrit > > With respect to information given in your message , may pure guess is the following : When a client generates a file in NFS server , it assumes that everything is written into the file . The next step ( reading the generated file ) starts , BUT the file is NOT completely written into disk yet , therefore it reads an incomplete file which causes errors in the client . In FreeBSD NFS server , there is NOT ( or I could NOT be able to find ) a facility to store written data immediately into disk . NFS server is collecting data up to a point ( number of bytes ) and then writing it to disk , during this phase ( whether the NFS server is busy or not ) is not important ) . With this structure , the tasks which a program writes a small number of bytes to be read by another program can not be processed by a NFS server only . I did not try "locking in NFS server" : If this route is taken , then it is necessary to adjust the clients for such periods to wait that NFS server has removed the lock which themselves can continue ( Each such read requires a waiting loop without generating an error message about unavailable data and termination . ) . In Linux NFS server , there is an option to immediately write the received data into disk . This is improving the above situation considerable but not completely solving the problem ( because during reads of data , data in cache is NOT concatenated to the data in disk ) . Another MAJOR problem is that , the NFS server is NOT concatenating data in cache to data in disk during reads : This defect is making NFS server useless for , let's say "real time" , applications used concurrently or as a single one by the clients without using another "Server" within NFS server . In your case , during software builds , a step is using the previously generated files : In local disk , writing and reading are sequential , in the sense that written data is found during reading . In NFS server this is not the case . With respect to my knowledge obtained from messages in FreeBSD mailing lists about making a possibility to read data immediately after it is written into NFS server is NOT available . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-net@FreeBSD.ORG Mon Dec 15 17:41:54 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB3FA620 for ; Mon, 15 Dec 2014 17:41:54 +0000 (UTC) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (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 86F32DDC for ; Mon, 15 Dec 2014 17:41:54 +0000 (UTC) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 510C520C93 for ; Mon, 15 Dec 2014 12:41:53 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute5.internal (MEProxy); Mon, 15 Dec 2014 12:41:53 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:x-sasl-enc:from:to :mime-version:content-transfer-encoding:content-type:subject :date:in-reply-to:references; s=smtpout; bh=RiRy8s72t03j6Rk4o+Xi n0Tr5kI=; b=ICgINSTCz+1CqdakdjmHBoHgQNscRD1kldVTce9DCLdlGm+qW4AR OfH0RxHp5X6nVQyyqCaObb4ayrF+tED5oNKP4TpnJP+ABHN10Y/CTBfd+KwbdcW+ ZRMnoN2EmMeF5sqMaeRALlTXE4hfpOTcjNF9uBoMxDoU7FKVISmWwJk= Received: by web3.nyi.internal (Postfix, from userid 99) id 3225F100DBA; Mon, 15 Dec 2014 12:41:53 -0500 (EST) Message-Id: <1418665313.312664.203145309.2FC90B3A@webmail.messagingengine.com> X-Sasl-Enc: vArU4ZFqPY2hacmzx3RcykJBqomcq8pXPvDwYDdMe4mi 1418665313 From: Mark Felder To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-54d79604 Subject: Re: dragonflybsd's ipfw Date: Mon, 15 Dec 2014 11:41:53 -0600 In-Reply-To: References: <20141117193354.T31139@sola.nimnet.asn.au> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Dec 2014 17:41:54 -0000 On Mon, Dec 15, 2014, at 06:11, bycn82 wrote: > *So **please DON'T make me a joker in front of all these big bosses. * > Don't worry. Your work is interesting and I encourage you to keep on hacking. Nobody is interested in making a fool out of anyone. If you come to any new conclusions please share your data. Thanks and have fun! From owner-freebsd-net@FreeBSD.ORG Mon Dec 15 17:58:48 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0553EA93 for ; Mon, 15 Dec 2014 17:58:48 +0000 (UTC) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id C8FE7F64 for ; Mon, 15 Dec 2014 17:58:47 +0000 (UTC) Received: from Toshi.lariat.net (IDENT:ppp1000.lariat.net@localhost [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id KAA07133; Mon, 15 Dec 2014 10:57:27 -0700 (MST) Message-Id: <201412151757.KAA07133@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 15 Dec 2014 10:56:38 -0700 To: Patrick Tracanelli From: Brett Glass Subject: Re: Can DUMMYNET handle weighting of traffic according to firewall rules? In-Reply-To: <59E7D981-B28B-4995-B8F4-6A2687CEF265@freebsdbrasil.com.br> References: <028d142b3a17cd5ffd5f21c6f9b9d6daaa8e2780@webmail.freebsdbrasil.com.br> <201412141635.JAA27068@mail.lariat.net> <59E7D981-B28B-4995-B8F4-6A2687CEF265@freebsdbrasil.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Cc: John Nielsen , Luigi Rizzo , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Dec 2014 17:58:48 -0000 At 05:26 AM 12/15/2014, Patrick Tracanelli wrote: >Yes, it would. But should only be a big deal if you have too much >pps and low CPU to deal with the volume. The actual system for which we're prototyping will be power-constrained and will use one of several fairly weak but energy-efficient processors. We have to plan for possible high PPS on these because they may be carrying VoIP. The communications link will be fast, but it will be half duplex and/or shared via arbitration. The purpose of the project is to manage its bandwidth very well and very fairly so that it can accommodate many users. It's critical that it be able to take arbitration overhead and turnaround time into account. >I don’t quite agree, if you have enough CPU to pipe it together. >I run a number of setups where a WF2Qp or QFQ setup does the >weighting and later an extra pipe imposes other individual limits. We have too, and have found an increase in latency and jitter that you can actually measure. >Proper queue and HZ tuning tend to do the job while you have >enough CPU to deal with interrupts. We usually set HZ=1000 when we use DUMMYNET for bandwidth management. It would be nice if it could avoid incurring the full overhead of the systemwide scheduler on every clock tick, but given that there can be an arbitrarily large number of pipes and queues in the system it's hard to avoid this. >This is just theory. And I don’t mean it’s wrong. There could >certainly be a better way to add an extra cost factor to a flow, >but the pure fact is you don’t have it today. True. But if Luigi is correct and it's a one line kernel hack, it could be implemented quickly and easily. It's OK if there's a bit more parsing, etc. to do in the Chapter 8 utility, because that doesn't run in real time. >Let’s be practical, how much bw are we talking about and how much CPU? We're talking about systems where hundreds of flows would need to share the half duplex pipe. That's why the bandwidth metering needs to be very precise and fair. We have had other network gateways, which served only 100 users, where the idle time percentage reported by top(8) dropped to 30% under this sort of load. Needless to say, the system was extremely sluggish! We want to optimize to avoid this. We've looked at other options such as pf and altq, but DUMMYNET is so close to what we need that it seems best to adapt it. >Even if we are talking about a lot of bandwidth, you have many >tuning possibilities and you have netmap-aware dummynet to deal >with high pps rate. We want to do as much as possible in the kernel without ever making a ring transition to userspace, so netmap wouldn't really help in this particular case. It might be possible to cobble something creative together with Netgraph, but it would be much more complicated to write a custom Netgraph node than to add a one line patch to DUMMYNET. > > X could only be a whole number unless you fed the pipe multiple > times in EACH direction. > >As I understand your problem you would need to feed a flow in the >opposite direction to the same pipe anyway. >So it’s just a matter of 3 flows instead of 2. That's assuming that X=2. We'd like to be able to tune the system for cost ratios that are not whole numbers (or the reciprocals of whole numbers), because in real life media arbitration and polling schemes such as DOCSIS they're not. >I insist, not the beautiful approach, but not a big deal, unless >we are talking about 10G/40G connections or a server with 10yo computing power. We're possibly talking more than 1 Gbps... and we ARE talking ARMs, Atoms, or similar processors. >That’s not true. Having one_pass disable is a mostly a needed >feature if you have complex environments with a mix of filtering >and queueing, otherwise a single match in a pipe will result in a >pass behavior. It doesn't just affect queueing and pipes; it also affects in-kernel NAT. It's really not an optimal implementation, by the way. I have long thought that it would have been better to have a "don't come back" option that could be applied individually to an action -- the equivalent of the "quick" option that Luigi implemented in ipfilter. >Sure it would be more desirable not just for your needs, but for >dummynet feature set as a whole. But that’s just not something >you have today. True. But I can patch and build my own kernels (and also the Chapter 8 utility) and then submit my patches to the core developers once I've tested them. It's starting to sound as if this would be the best thing to do. I have not analyzed the IPFW code before, so it'd require a late night reading and coding session.... --Brett Glass From owner-freebsd-net@FreeBSD.ORG Mon Dec 15 18:03:12 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 941F3C98 for ; Mon, 15 Dec 2014 18:03:12 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [67.212.89.78]) (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 5247AB6 for ; Mon, 15 Dec 2014 18:03:12 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) by mail.bsdinfo.com.br (Postfix) with ESMTP id DAEE7139CB for ; Mon, 15 Dec 2014 16:03:29 -0200 (BRST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsdinfo.com.br; h=content-transfer-encoding:content-type:content-type :in-reply-to:references:subject:subject:to:mime-version :user-agent:from:from:date:date:message-id; s=dkim; t= 1418666604; x=1419530605; bh=/ML9R+0MG9PEqbPixiMWFn4/Xo2JH/Rley1 A3OTIQXQ=; b=TWN38PvyUU9wiRsEvrD7UJ6BW5d3a/LczxR7SHb1atPI8jHQAb/ xGmzTssBukJycKq5MIHyV2BWYwzZktS+l/ZONl/OxZZhPzsh9KgKnRU5fj3XiPHp ydFSNE6/2JunZM/54ZZwO+A9PblwBp//pQvx6ZNvupqOfoNwYVW7B5tQ= X-Virus-Scanned: amavisd-new at mail.bsdinfo.com.br Received: from mail.bsdinfo.com.br ([127.0.0.1]) by mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzfP1S0GHubd for ; Mon, 15 Dec 2014 16:03:24 -0200 (BRST) Received: from [192.168.88.15] (unknown [186.193.48.8]) by mail.bsdinfo.com.br (Postfix) with ESMTPSA id 78EF6139C8 for ; Mon, 15 Dec 2014 16:03:24 -0200 (BRST) Message-ID: <548F2250.3010507@bsdinfo.com.br> Date: Mon, 15 Dec 2014 16:02:56 -0200 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: DNS resolution problem References: <548C3072.10303@bsdinfo.com.br> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Dec 2014 18:03:12 -0000 Hi Kevin, On 13/12/2014 23:44, Kevin Oberman wrote: > On Sat, Dec 13, 2014 at 4:26 AM, Marcelo Gondim > wrote: > >> Dear, >> >> I'm having trouble resolving domain name freebsd.org. The portsnap server >> works correctly but the pkg audit -F does not work and can not even access >> the site according to the following tests: >> >> # host ec2-sa-east-1.portsnap.freebsd.org >> ec2-sa-east-1.portsnap.freebsd.org has address 177.71.188.240 >> >> # host vuxml.freebsd.org >> Host vuxml.freebsd.org not found: 3(NXDOMAIN) >> >> # host -a freebsd.org >> Trying "freebsd.org" >> Trying "freebsd.org.intnet.com.br" >> Host freebsd.org not found: 3(NXDOMAIN) >> Received 86 bytes from ::1#53 in 0 ms >> >> # host www.freebsd.org >> ;; connection timed out; no servers could be reached >> >> Only the first address I'm having name resolution (ec2-sa-east-1.portsnap. >> freebsd.org). >> >> My block IP: 186.193.48.0/20 >> >> One could check for any restrictions on our IP block? >> >> I think a bit of DNS debugging is in order. > I could resolve all of the nodes you listed, but there are some potential > issues I see. First, when looking up hostname with host(1), always > terminate the name: >> host -a freebsd.org. > Trying "freebsd.org" > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24171 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;freebsd.org. IN TYPE255 > > ;; ANSWER SECTION: > freebsd.org. 534 IN AAAA 2001:1900:2254:206a::50:0 > freebsd.org. 534 IN MX 10 mx1.freebsd.org. > freebsd.org. 534 IN A 8.8.178.110 > > But "ANY" queries are fuzzy things at best as the first resolver you hit > will just return whatever is cached and not try getting an authoritative > response. > > www.freebsd.org and vuxml.freebsd.org are CNAME entries pointing to the > same place, 8.8.178.110. This is in FreeBSD's own address space from Yahoo > nd is probably in the mail FreeBSD cluster. I was a bit surprised to find > that is is an Amazon AWS address, so the portsnap files are actually coming > from a totally different place. > > DNS is provided by ISC-SNS. 72.52.71.1, 38.103.2.1 and 63.243.194.1. Try > pinging these. Since BIND, the second oldest and most popular DNS server is > written and supported by ISA, I would think that it is well run. Try > pinging and tracing to these addresses. All of them are in very dispersed > locations on different provider backbones. (Cogent, Hurricane Electric, and > ISC, itself. You might try directing queries to each system to see if one > fails when other succeed. Use "dig @servr-addr host". Other tests: # ping -c 5 NS1.ISC-SNS.NET PING ns1.isc-sns.net (72.52.71.1): 56 data bytes 64 bytes from 72.52.71.1: icmp_seq=0 ttl=56 time=144.327 ms 64 bytes from 72.52.71.1: icmp_seq=1 ttl=56 time=145.445 ms 64 bytes from 72.52.71.1: icmp_seq=2 ttl=56 time=144.999 ms 64 bytes from 72.52.71.1: icmp_seq=3 ttl=56 time=146.775 ms 64 bytes from 72.52.71.1: icmp_seq=4 ttl=56 time=145.207 ms --- ns1.isc-sns.net ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 144.327/145.351/146.775/0.804 ms # ping -c 5 NS2.ISC-SNS.COM PING ns2.isc-sns.com (38.103.2.1): 56 data bytes 64 bytes from 38.103.2.1: icmp_seq=0 ttl=54 time=133.839 ms 64 bytes from 38.103.2.1: icmp_seq=1 ttl=54 time=133.831 ms 64 bytes from 38.103.2.1: icmp_seq=2 ttl=54 time=133.972 ms 64 bytes from 38.103.2.1: icmp_seq=3 ttl=54 time=133.957 ms 64 bytes from 38.103.2.1: icmp_seq=4 ttl=54 time=133.851 ms --- ns2.isc-sns.com ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 133.831/133.890/133.972/0.061 ms # ping -c 5 NS3.ISC-SNS.INFO PING ns3.isc-sns.info (63.243.194.1): 56 data bytes 64 bytes from 63.243.194.1: icmp_seq=0 ttl=59 time=185.755 ms 64 bytes from 63.243.194.1: icmp_seq=1 ttl=59 time=185.790 ms 64 bytes from 63.243.194.1: icmp_seq=2 ttl=59 time=185.866 ms 64 bytes from 63.243.194.1: icmp_seq=3 ttl=59 time=185.931 ms 64 bytes from 63.243.194.1: icmp_seq=4 ttl=59 time=185.988 ms --- ns3.isc-sns.info ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 185.755/185.866/185.988/0.086 ms # host -a freebsd.org 72.52.71.1 Trying "freebsd.org" ;; Truncated, retrying in TCP mode. Using domain server: Name: 72.52.71.1 Address: 72.52.71.1#53 Aliases: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15306 ;; flags: qr aa rd; QUERY: 1, ANSWER: 20, AUTHORITY: 0, ADDITIONAL: 7 ;; QUESTION SECTION: ;freebsd.org. IN TYPE255 ;; ANSWER SECTION: freebsd.org. 3600 IN SOA ns0.freebsd.org. hostmaster.freebsd.org. 2014121517 3600 900 604800 600 freebsd.org. 3600 IN RRSIG SOA 8 2 3600 20141229134836 20141215162412 22689 freebsd.org. Li3FZ22mk+j4FbIRp7rQD/QS/m3UCFvMDqdUfdLBOPEpOiCTLue+5xFhtr6mLwJ6mYzbsATM3rHN/O+B1VF3VzytnOOYh0QvoqpjxwGcUWNAkAlOCFDrqaS5wp9PfWOBJ+1q+xbkgC/iwBmasqb06G1WpcvpRq9kYoZUum8RxAGuTQIYNhoDxUjU5r6yiTvWy3sCmpu02F846BcJ6+LBKhsd8OuOJYplYhjFOfszl8uQmUtyCxCDm9udsWHbNyVMPU/DeVPKSlBS5md1l07GcG2QDepH4ChxQZnejmhaXgi/6+680v7Ufgh51xb5QiU2Xg7ATwplvor2VwJphSwMAw== freebsd.org. 3600 IN RRSIG DNSKEY 8 2 3600 20141228141417 20141214022412 32659 freebsd.org. Cf1nX8IQROLxXzL9WTDJVRdHuGN344DnIzKrshoG9sbYkP/DTDMMt9mpDCUUz0HK0FgxhHw45oepm6+KMbydzZDWhK2+G/LPgyK5nzsxnaJc9EgHpg6OKCQw7HHDirfe8lr0es0Ab4mPicqMKg31r7272SEKJ6HGoezzW5wtokTJpegAGQhW+b8ZvpBqRcj3jYIU9HvBOJtn/ZNrXMg2mUP/tbkxDcBy7ssMNmy0s0GKu6Daqq1VSK0BKvEIPc/sUC+mKkUo259FkI2Lnfml3vsw+aV0behgp/VpoxRfotcNjFNJGhYGF0B0iwTQIdBnfMWlNXsQBnoQ8b7W+OLiRw== freebsd.org. 0 IN RRSIG NSEC3PARAM 8 2 0 20141219185954 20141206012400 22689 freebsd.org. ViAARy2wfDAUXV7AEzQFbge0hCJSU1/vusbRoWkaM1EVkOQbaCiSQ1PDanZmR4yQncdo2M3d4gJtIHgvZ5xzeo0/2AhlSVw/GAtWjJkqI/8rJZ2ZPtoXy6SJBcNAcGKTx74EjFN/TIxDIEXKNss2BNz3y57olnknvqgVpNjGu8jzc59aDww4+cgh9v7zuMG1YAncCnHwTIaxtsXN/K0jjKx9CtkVwJLJCRd4bthKyrPkBNMZ3cDOX27MlQFC7461WsPkNxsxFYfUWO4g8f41UUYzPX2c59tKm+qJB7s56KLihZIuBjTZnROyTkvFFcdG3ii9dzFqbEN8PMwJIS7bzw== freebsd.org. 600 IN RRSIG NS 8 2 600 20141221172508 20141207182403 22689 freebsd.org. ny0XoD9xYbSX5nHbDnl5iCIofSBlkwB8dPjeUcmKfyylrpiPVDkXfl+xfacqJj7DRvf5gF8fLhe0lwTu3cLeVXGf9L3UfD5N5sd61SxLLXy8gDHtjCQWS5/VYE4rIn6/leoqRD5YVPGJ1OWRBHSnVIjdib/R7XLLz6v8CMT4l+P42tDf7z56hjc3BNplcD/KjFfrEmoBlRIwvs9XaR3i+Qvl/0uKnGgeaXVvRMgCthC4J4oZKsBt0hpAhwy3ocOOGhp1uLV+/sBUd4ZMi0HG0G+OZbelVt01LE/7Kp5+4TA7i5Ubla8/kEcx7iKjqimnTb+0GF7+WrZbVe3MrTi9Jg== freebsd.org. 600 IN RRSIG TXT 8 2 600 20141221200324 20141207122402 22689 freebsd.org. uf81IQ/nUDeVhLtUw/g4ILoW3Pq1rl9ub8p4MBkuGxhpmZSpm1phmJ47xuDkEg137SwqdP/mIx/EIRZ1Oah5Hx1e0278qJSX1M9DMwscCjXl3uPTqgYfL/M9k15U3OJ3i9yI4Stsp6ORG3Rj4bYYYz3mzlSNV64ZOnkW9JfPu/GjEq21EXgF9SEABJr21dwEUeCpmng15MHpmpTIJIwkgdH4DC7Dh/glQ6yMDEcf6I4x63hmj4CWpChs18W94esshEfZVTeiKV7xFPvgrnsbrO660Jvua7XR3R4mqr9sqv2mXKJICNobBNx/IyAxw9vw5dE7ohFptPEH7DUDN/h4jw== freebsd.org. 600 IN RRSIG MX 8 2 600 20141222062628 20141208062403 22689 freebsd.org. exRPLUyRmbRbxQEYu989+agnNMIjXl7PsfPGW8xaoq2Dv0/GbOGnAPlSALg3MBPz8R+pL3MWiaexyi/1qxUF6n0tItn7hQhUla4jri7rMFzMUcvePPr6t5sF/MWkIC+15O5QlIUx/Bi0zUnUFPSXCKH3MWr0oqGNzzc3jSqsUlqBhQmZq3KCrSE62Tp3VDthFhZUSY29EAmmwnAlTxQR9ZX3eVEM5oJ5UrhFkBcMhv4jVtSN+OncYx4PQWHNk4DR9vY3FCVl48XqJ9ivln9vHOOCqfzl5oaSXeE6rnbHwEKpOZX65l24nPuNtKVPajYEAroK4xMqCdkPW4Ov0tw3zA== freebsd.org. 600 IN RRSIG A 8 2 600 20141221151124 20141207232403 22689 freebsd.org. VPOX9ep1tYDF7dFaY37zXAMHwd+ySWAeSAMa45btmNzCD/F1pkUi9wH57LPE3jtqeHF4coKfZCvzBED5KWfyYMDZsWOaTNA2Hxh4h+WRr4qK1FxeilvIDLYs1/ynGCcaAfTM8T7OwAueWx/x78bshaw8mkI8Pp38SpkHa0sL5T4/L9NP8NOUOP5I6zv2xFtqkcQBSWZLFElGHn3JBo3ZyGa9lUsjnNfNWwNCLcDbXG7aQCW88v+mxbnIq2lHogqOsYXQHnatpK7qV27c2XNB9ZuGmWq6zLFUFOXH1pDLf0ftIg70Evy+88RomIFLo9e9qNYI9WJk7Z51gL7ygA/YSg== freebsd.org. 600 IN RRSIG AAAA 8 2 600 20141222031959 20141208092403 22689 freebsd.org. U88G56Mlmb6l4xv+G+IdvLAQQ8g5quIvKVjBSTcC5QdO52C/kUGcoo2rE+phXqXK7j7vgcfEuSI2qP3FDCG2K1VUn19+oCHA/LVzx4sNGsVlqXDfieE7c48vVYeukalh7cCXQ53dGo/4Tpps3i/4IUtw7Wi/NjykJoi8PbzgqR7mrkcKD83l18XR0JNILvj1EQwuTZYIICcd+yfs2WU5IjXIv5ik3hVkxQA5GkJse+EfAvBuJRPkZ8yknRM93tRw95gBc6ntB9+3pqZ9QNPKRUl5i7HoBbkSlAr3iGJiBAOXAX4V3PGNG+tXHqbEVPn1DzsXojJSFUJGaXHA9VFSpw== freebsd.org. 3600 IN DNSKEY 256 3 8 AwEAAc48eD98O70LmwN5RQ5i1vaP9BURkyvOiVNbztyVOCbPsZMIxDVZULFGLeEKmUR9UbutNoizdVi+XDGXgbfvQTZczkCUJNvBCxVglssyxnMMDjxf4p6TfuTTAW7EK6BDGVGkU3yBbfFYRYDeRep3g2CHH5/juU6MGMDElYYAhULICw3QRJjzMJFezvV0D1Mql53otXJ2J0BVhNBbF/1HSYRhVrFCSnpo1OORbNEuCudBr5WDBsZ3TdFehf74fYQP8XZEKqwirUvGcrlvDCPncPFtoLj3BWNvecsAwBrRbVzwTMVZHV95SXSq5VzjiXsf4U/UMQ5xOE5t4370msqPScM= freebsd.org. 3600 IN DNSKEY 257 3 8 AwEAAd1zS5J5X1kQqoufYTOGrPaUnlgBxllrFE1rGLJ3qDWEEETjszjal7IeJMmn/VhC6a2txXeob5is1/8Z6KWxpAhqIiw+l9JmD9sD/dOI9Yyk/AIyhSPguqV9+zBkfrp9I0BUuwxO/Rs+VgnqwQquyDGWRFQTtckPkptHKMTt44F8VyGcg+WVHOAXAsdGAC2SK1MVbSnMnRvZjYRHS3qc8at/h7soSib9TGNG9i+UD2mZyefcUUxsSll7TvUURA1dW13UP3U4/JlUM0qwA8Lk7pho/Or61Sci+yiqKijAdHu+dY3yGESkZ2rm4PBYYbm44ftefYXX5Hd5w20MXe5Lym8= freebsd.org. 3600 IN DNSKEY 256 3 8 AwEAAdCGUpcdxSMYspciWP5aJa3f0Lr5oW1BkSnSGe4TO4+HVy8f+40q7uHtpaI7MMl5+2HAtjxgaZIVGBM3zqiCvW3KXjv+TRKLIBJTxStYu9ped0JWCqAXfYIhD5Tw2uvNKU0CLTJP9PQuEz8K5Yd7Zsy6N49/zAbovyhL5Ciax+BPcA8FTZ6io+m1Gw43+i2UOAs5yAeWsjaYsCwV4Ye7FdPwuQ5z/MMszr9XwBzFJdlQyJFpyAPNcdAiplnSWAg7oo8t221+sRsY/ZMOgi4WeIZAPM71Fq0LEi+GUxgjUdYs7MtehsmyRgZjum3AJyJfaf2gZRQH5Dw0aIR/G1lUwEc= freebsd.org. 0 IN NSEC3PARAM 1 0 100 10238ec3108d6756 freebsd.org. 600 IN NS ns3.isc-sns.info. freebsd.org. 600 IN NS ns2.isc-sns.com. freebsd.org. 600 IN NS ns1.isc-sns.net. freebsd.org. 600 IN TXT "v=spf1 redirect=_spf.freebsd.org" freebsd.org. 600 IN MX 10 mx1.freebsd.org. freebsd.org. 600 IN A 8.8.178.110 freebsd.org. 600 IN AAAA 2001:1900:2254:206a::50:0 ;; ADDITIONAL SECTION: ns1.isc-sns.net. 3600 IN A 72.52.71.1 ns1.isc-sns.net. 3600 IN AAAA 2001:470:1a::1 ns2.isc-sns.com. 3600 IN A 38.103.2.1 ns3.isc-sns.info. 3600 IN A 63.243.194.1 ns3.isc-sns.info. 3600 IN AAAA 2001:5a0:10::1 mx1.freebsd.org. 600 IN A 8.8.178.115 mx1.freebsd.org. 600 IN AAAA 2001:1900:2254:206a::19:1 Received 3670 bytes from 72.52.71.1#53 in 298 ms From owner-freebsd-net@FreeBSD.ORG Mon Dec 15 19:33:42 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1DED63C3 for ; Mon, 15 Dec 2014 19:33:42 +0000 (UTC) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9EFD6CCF for ; Mon, 15 Dec 2014 19:33:41 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id x12so15439741wgg.25 for ; Mon, 15 Dec 2014 11:33:40 -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:content-transfer-encoding; bh=N7NcDxAVEHuKbHza0xpftwwQwUhlGC+AK0ShwtKjedc=; b=JNoJc3pJffEca+XUbKR2J68Q9HdP6fu/DgFMTyUuYT/u67/6UuhNplAaTEVCqjEtmu KDiqSHtwf5JqCkr8rXdtE8h5V+etfyBgUCFFjBEDmU1Lsz5zov+8/etNIblErv05R310 qk5TdKtLeiLkAusuu5Z78AbR8jVw7HsYvKzK/iit8Ob2msKJz18fxKeVeCxQdps9xjU4 2XggYnWCqTSHFCaHpQimVkrUM/fmEdl1Os1yWeyK6jRonLaezzml6XtWN1rq4mXrLrw5 0ledlzetowks1iRXe+LL/JwmrNFeLm5LAlpZ9ACWIOCTpoqpf9+qa8ydXd4hEfz9vL9O AxOg== MIME-Version: 1.0 X-Received: by 10.180.84.134 with SMTP id z6mr12922865wiy.50.1418672020128; Mon, 15 Dec 2014 11:33:40 -0800 (PST) Sender: asomers@gmail.com Received: by 10.194.17.129 with HTTP; Mon, 15 Dec 2014 11:33:40 -0800 (PST) In-Reply-To: <34276C9E-CAEF-4E3F-AA2A-568F2D3099EC@dpdtech.com> References: <1A44709E-7D0C-4932-8A28-383EAC3F340B@dpdtech.com> <9AE69175-92D9-49FA-A651-119C7046A1FA@dpdtech.com> <5480D8EF.9000804@egr.msu.edu> <3D993418-E632-44BA-8FE2-2F3F34188F20@dpdtech.com> <34276C9E-CAEF-4E3F-AA2A-568F2D3099EC@dpdtech.com> Date: Mon, 15 Dec 2014 12:33:40 -0700 X-Google-Sender-Auth: 0Fvv5Hrt8qGawzr9cGKw8nxNcwQ Message-ID: Subject: Re: FreeBSD 10-stable (r274577) LACP / IEEE 802.3ad with TP-Link TL-SG2008 - not working From: Alan Somers To: "David P. Discher" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Net , Adam McDougall X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Dec 2014 19:33:42 -0000 On Sun, Dec 14, 2014 at 6:23 PM, David P. Discher wrote: > > So, I think I=E2=80=99ve identified the issue. In sys/net/ieee8023ad_lac= p.c, lacp_pdu_input() has a sanity check : > > if (m->m_pkthdr.len !=3D sizeof(*du)) { > goto bad; > } > > I added some debugging information in if_lagg, and ran with it. The lacp= du packet that being sent by the TP-Link switch is 4 bytes longer than the = FreeBSD "struct lacpdu du=E2=80=9D. > > em1: lacp_pdu_input-sizeof(du) bad m_pkthdr.len=3D128 sizeof(du)= =3D124 > > My packet captures shows the packet size differing as well. > > I=E2=80=99m still poking around. I=E2=80=99ve been trying to look for the= official LACPDU binary/wire format =E2=80=A6 if someone can point me to th= e reference for that, that would be helpful (at least my own understanding)= . Try here: http://standards.ieee.org/findstds/standard/802.1AX-2008.html > > Not exactly sure what these extra 4 bytes are at the end of the packet. = Still trying to figure that out. > > > - > David P. Discher > http://davidpdischer.com/ > AIM: DavidDPD | Y!M: daviddpdz > > > > On Dec 4, 2014, at 8:41 PM, David P. Discher wrote: > >> Thanks Adam - >> >> On Dec 4, 2014, at 1:58 PM, Adam McDougall wrote: >> >>> >>> Is the switch side set to "active" for the lacp mode (instead of >>> passive)? Also, try: >>> sysctl net.link.lagg.0.lacp.lacp_strict_mode=3D0 >>> >>> If either of those work, I'll explain more, don't have time to dig for >>> old email right this minute. >> >> Yes, the switch was in active mode. Turn strict mode off (which I thoug= ht I did before, but of course this sysctl clears when destroying the inter= face). So, the LACP did finally negotiated, at least in ifconfig : > From owner-freebsd-net@FreeBSD.ORG Mon Dec 15 20:59:37 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E5DB386 for ; Mon, 15 Dec 2014 20:59:37 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id BDFCA96D for ; Mon, 15 Dec 2014 20:59:36 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAKVKj1SDaFve/2dsb2JhbABag1hYBIMCwk0KhShKAoE7AQEBAQF9hAwBAQEDAQEBASArIAYFBRYYAgINGQIpAQkmBggHBAEaAgSIAwgNvjWWPQEBAQEBAQQBAQEBAQEBAQEZgSGNbxACAQYVNAeCLTsRgTAFiT6IAoMcgyAwhF+FEoJTgzgigX4egW4gMAd9QX4BAQE X-IronPort-AV: E=Sophos;i="5.07,581,1413259200"; d="scan'208";a="176737449" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 15 Dec 2014 15:59:29 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 21EB9B4091; Mon, 15 Dec 2014 15:59:29 -0500 (EST) Date: Mon, 15 Dec 2014 15:59:29 -0500 (EST) From: Rick Macklem To: Mehmet Erol Sanliturk Message-ID: <2048229686.13136235.1418677169130.JavaMail.root@uoguelph.ca> In-Reply-To: Subject: Re: compiling on nfs directories MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-net@freebsd.org, Gerrit =?utf-8?B?S8O8aG4=?= X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Dec 2014 20:59:37 -0000 Mehmet Erol Sanliturk wrote: > On Mon, Dec 15, 2014 at 1:24 AM, Gerrit K=C3=BChn > > wrote: > > > > Hi all, > > > > I ran into some weird issue here last week: > > I have an NFS-Server for storage and diskless booting (pxe / nfs > > root) > > running under FreeBSD. The clients are running Gentoo Linux. Some > > time > > ago, I replaced the server, going from a HDD-based storage array > > (ZFS) > > under FreeBSD 8.3 to an SSD-based array under FreeBSD 10-stable (as > > of > > February this year - I know this needs updates). > > > > Only now I recognized that this somehow appears to have broken some > > of my > > Gentoo ebuilds that do not install cleanly anymore. They complain > > about > > "soiled libtool library files found" and "insecure RUNPATHs" in the > > installation stage of shared libs. > > > > I was not able to find any useful solution for this in the Net so > > far. > > However, I was able to verify that this is somehow an issue with > > the nfs > > server by plugging in a USB-drive into the diskless clients and > > mounting > > this as /var/tmp/portage (the directory structure where Gentoo's > > ebuilds > > are compiled). This makes the error messages go away, and > > everything works > > again (like it did before the server update). > > > > Are there any suggestions what might be causing this and how to fix > > it? > > > > > > cu > > Gerrit > > > > >=20 >=20 > With respect to information given in your message , may pure guess is > the > following : >=20 >=20 > When a client generates a file in NFS server , it assumes that > everything > is written into the file . > The next step ( reading the generated file ) starts , BUT the file is > NOT > completely written into disk yet , > therefore it reads an incomplete file which causes errors in the > client . >=20 Well, not exactly. The NFS client chooses whether or not the written data must be committed to stable storage (disk) right away via a flag argument on the write. It is up to the client to keep track of what has been written and if the FILE_STABLE flag wasn't set, must do a separate Commit RPC to force the data to stable storage on the server. It is also up to the NFS client to keep track of the file's size while it is being grown, since the NFS server's size may be smaller until the data gets written to the server. Also, note that he didn't see the problem with FreeBSD8.3, which would have been following the same rules on the server as 10.1. What I suspect might cause this is one of two things: 1 - The modify time of the file is now changing at a time the Linux client doesn't expect, due to changes in ZFS or maybe TOD clock resolution. (At one time, the TOD clock was only at a resolution of 1sec, so the client wouldn't see the modify time change often. I think it is now at a much higher resolution, but would have to look at the code/test to be sure.) 2 - I think you mention this one later in your message, in that the build might be depending on file locking. If this is the case, trying NFSv4, which does better file locking, might fix the problem. Gerrit, I would suggest that you do "nfsstat -m" on the Linux client, to see what the mount options are. The Linux client might be using NFSv4 already. Also, avoid "soft, intr" especially if you are using NFSv4, since these can cause slow server response to result in a failure of a read/write when it shouldn't fail, due to timeout or interruption by a signal. If you could find out more about what causes the specific build failure on the Linux side, that might help. If you can reproduce a build failure quickly/easily, you can capture packets via "tcpdump -s 0 -w host " on the server and then look at it in wireshark to see what the server is replying when the build failure occurs. (I don't mind looking at a packet trace if it is relatively small, if you email it to me as an attachment.) Good luck with it, rick ps: I am not familiar with the Linux mount options, but if it has stuff like "nocto", you could try those. > In FreeBSD NFS server , there is NOT ( or I could NOT be able to find > ) a > facility to store written data immediately into disk . >=20 > NFS server is collecting data up to a point ( number of bytes ) and > then > writing it to disk , during this phase ( whether the NFS server is > busy or > not ) is not important ) . With this structure , > the tasks which a program writes a small number of bytes to be read > by > another program can not be > processed by a NFS server only . >=20 > I did not try "locking in NFS server" : If this route is taken , then > it is > necessary to adjust the clients for such periods to wait that NFS > server > has removed the lock which themselves can continue ( Each such read > requires a waiting loop without generating an error message about > unavailable data and termination . ) . >=20 > In Linux NFS server , there is an option to immediately write the > received > data into disk . This is improving the above situation considerable > but not > completely solving the problem ( because during reads of data , data > in > cache is NOT concatenated to the data in disk ) . >=20 >=20 > Another MAJOR problem is that , the NFS server is NOT concatenating > data in > cache to data in disk during reads : This defect is making NFS server > useless for , let's say "real time" , applications used concurrently > or as > a single one by the clients without using another "Server" within NFS > server . >=20 >=20 >=20 > In your case , during software builds , a step is using the > previously > generated files : In local disk , writing and reading are sequential > , in > the sense that written data is found during reading . In NFS server > this is > not the case . >=20 >=20 > With respect to my knowledge obtained from messages in FreeBSD > mailing > lists about making a possibility to read data immediately after it is > written into NFS server is NOT available . >=20 >=20 >=20 > Thank you very much . >=20 > Mehmet Erol Sanliturk > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Dec 15 23:06:35 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61C915E7 for ; Mon, 15 Dec 2014 23:06:35 +0000 (UTC) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 18ACBA1A for ; Mon, 15 Dec 2014 23:06:35 +0000 (UTC) Received: by mail-yk0-f178.google.com with SMTP id 20so5391443yks.37 for ; Mon, 15 Dec 2014 15:06:34 -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=mYTzQSPMCtHUyjn/3J34WuNuoAtRWVUgv6rXNE50Ids=; b=YR6RWYJzt4HidCWgaZI6h8v7lnIxXJJyv7iJTwav1NCOf3xdVWS9zH4EWmaTICPOC9 KQrBVnBxGYRXpcOxUubwRCuwSH6YZIIXGyHrhr4krBWH/8eVA22xnfUCgF57t1fWyNRA cT6ZyJyp3yRw8/fYrqMUqJBpN+80txO+do1JwGVOhmVcORC4hWPgXQ9QqiPxKrsaBv7e SWVbq6ZOua04gohgvimM/AfxXJXpAFU30kENNFnbfhq6SrbTUrMHVUL13zDc/3Wfpiga J/6lOF4syzVyDktgUWcB+ZXLBms68aHMWzfjGYvayEbJGsBlA+LbjqtrXuCz6qOROEBO ekUg== MIME-Version: 1.0 X-Received: by 10.236.221.168 with SMTP id r38mr24188840yhp.137.1418684794237; Mon, 15 Dec 2014 15:06:34 -0800 (PST) Received: by 10.170.90.131 with HTTP; Mon, 15 Dec 2014 15:06:34 -0800 (PST) In-Reply-To: <2048229686.13136235.1418677169130.JavaMail.root@uoguelph.ca> References: <2048229686.13136235.1418677169130.JavaMail.root@uoguelph.ca> Date: Mon, 15 Dec 2014 15:06:34 -0800 Message-ID: Subject: Re: compiling on nfs directories From: Mehmet Erol Sanliturk To: Rick Macklem Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-net@freebsd.org, =?UTF-8?B?R2Vycml0IEvDvGhu?= X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Dec 2014 23:06:35 -0000 On Mon, Dec 15, 2014 at 12:59 PM, Rick Macklem wrote= : > > Mehmet Erol Sanliturk wrote: > > On Mon, Dec 15, 2014 at 1:24 AM, Gerrit K=C3=BChn > > > > wrote: > > > > > > Hi all, > > > > > > I ran into some weird issue here last week: > > > I have an NFS-Server for storage and diskless booting (pxe / nfs > > > root) > > > running under FreeBSD. The clients are running Gentoo Linux. Some > > > time > > > ago, I replaced the server, going from a HDD-based storage array > > > (ZFS) > > > under FreeBSD 8.3 to an SSD-based array under FreeBSD 10-stable (as > > > of > > > February this year - I know this needs updates). > > > > > > Only now I recognized that this somehow appears to have broken some > > > of my > > > Gentoo ebuilds that do not install cleanly anymore. They complain > > > about > > > "soiled libtool library files found" and "insecure RUNPATHs" in the > > > installation stage of shared libs. > > > > > > I was not able to find any useful solution for this in the Net so > > > far. > > > However, I was able to verify that this is somehow an issue with > > > the nfs > > > server by plugging in a USB-drive into the diskless clients and > > > mounting > > > this as /var/tmp/portage (the directory structure where Gentoo's > > > ebuilds > > > are compiled). This makes the error messages go away, and > > > everything works > > > again (like it did before the server update). > > > > > > Are there any suggestions what might be causing this and how to fix > > > it? > > > > > > > > > cu > > > Gerrit > > > > > > > > > > > > With respect to information given in your message , may pure guess is > > the > > following : > > > > > > When a client generates a file in NFS server , it assumes that > > everything > > is written into the file . > > The next step ( reading the generated file ) starts , BUT the file is > > NOT > > completely written into disk yet , > > therefore it reads an incomplete file which causes errors in the > > client . > > > Well, not exactly. The NFS client chooses whether or not the written > data must be committed to stable storage (disk) right away via a flag > argument on the write. It is up to the client to keep track of what has > been written and if the FILE_STABLE flag wasn't set, must do a separate > Commit RPC to force the data to stable storage on the server. > It is also up to the NFS client to keep track of the file's size while > it is being grown, since the NFS server's size may be smaller until > the data gets written to the server. > Also, note that he didn't see the problem with FreeBSD8.3, which would > have been following the same rules on the server as 10.1. > > What I suspect might cause this is one of two things: > 1 - The modify time of the file is now changing at a time the Linux > client doesn't expect, due to changes in ZFS or maybe TOD clock > resolution. (At one time, the TOD clock was only at a resolution > of 1sec, so the client wouldn't see the modify time change often. > I think it is now at a much higher resolution, but would have to > look at the code/test to be sure.) > 2 - I think you mention this one later in your message, in that the > build might be depending on file locking. If this is the case, > trying NFSv4, which does better file locking, might fix the > problem. > > Gerrit, I would suggest that you do "nfsstat -m" on the Linux client, > to see what the mount options are. The Linux client might be using NFSv4 > already. > Also, avoid "soft, intr" especially if you are using NFSv4, since these > can cause slow server response to result in a failure of a read/write > when it shouldn't fail, due to timeout or interruption by a signal. > > If you could find out more about what causes the specific build failure > on the Linux side, that might help. > If you can reproduce a build failure quickly/easily, you can capture > packets via "tcpdump -s 0 -w host " on the > server and then look at it in wireshark to see what the server is replyin= g > when the build failure occurs. (I don't mind looking at a packet trace if > it is relatively small, if you email it to me as an attachment.) > > Good luck with it, rick > ps: I am not familiar with the Linux mount options, but if it has > stuff like "nocto", you could try those. > > > In FreeBSD NFS server , there is NOT ( or I could NOT be able to find > > ) a > > facility to store written data immediately into disk . > > > > NFS server is collecting data up to a point ( number of bytes ) and > > then > > writing it to disk , during this phase ( whether the NFS server is > > busy or > > not ) is not important ) . With this structure , > > the tasks which a program writes a small number of bytes to be read > > by > > another program can not be > > processed by a NFS server only . > > > > I did not try "locking in NFS server" : If this route is taken , then > > it is > > necessary to adjust the clients for such periods to wait that NFS > > server > > has removed the lock which themselves can continue ( Each such read > > requires a waiting loop without generating an error message about > > unavailable data and termination . ) . > > > > In Linux NFS server , there is an option to immediately write the > > received > > data into disk . This is improving the above situation considerable > > but not > > completely solving the problem ( because during reads of data , data > > in > > cache is NOT concatenated to the data in disk ) . > > > > > > Another MAJOR problem is that , the NFS server is NOT concatenating > > data in > > cache to data in disk during reads : This defect is making NFS server > > useless for , let's say "real time" , applications used concurrently > > or as > > a single one by the clients without using another "Server" within NFS > > server . > > > > > > > > In your case , during software builds , a step is using the > > previously > > generated files : In local disk , writing and reading are sequential > > , in > > the sense that written data is found during reading . In NFS server > > this is > > not the case . > > > > > > With respect to my knowledge obtained from messages in FreeBSD > > mailing > > lists about making a possibility to read data immediately after it is > > written into NFS server is NOT available . > > > > > > > > Thank you very much . > > > > Mehmet Erol Sanliturk > > _______________________________________________ > > When a C program is written to be used in an NFS environment , some possibilities may be used to synchronize write and reads from the programs with the unsolved "cached data" problem . When ready programs are used , such as "make" , "ld" , there is no choice . I am using Pascal programs , then there is no such facilities . The solution may be to improve the NFS Server and Client modules to use cached data during reads : If end of file is reached : Before sending EOF signal , check whether there is data in cache or not . If there is data in cache : continue reading from the cache up to end , else send an EOF signal . ( For random access files , also there is a need to look at the cached values . ) Since the above modification requires knowledge of internal structure of NFS Server , and perhaps NFS Client ,I am not able to supply any patch . Also I am not able to understand its implementation difficulty . My opinion is that the above modification would be a wonderful improvement for NFS system in FreeBSD , because it will behave just like a local data store usable as "real time" data processing tasks . In the present structure , this is NOT possible with NFS Client and Server only . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-net@FreeBSD.ORG Mon Dec 15 23:42:19 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E1B8F9F for ; Mon, 15 Dec 2014 23:42:19 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 23BE1E1D for ; Mon, 15 Dec 2014 23:42:18 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFACtxj1SDaFve/2dsb2JhbABag1hYBIMCwk8KhShKAoE3AQEBAQF9hAwBAQEDAQEBASArIAYFBRYYAgINGQIpAQkmBggHBAETBwIEiAMIDb4rllEBAQEBAQUBAQEBAQEBAQEZgSGIaYUGEAIBBhUBMweCLTsRgTAFiT6IAoMcgyAwhF+DXoE0glODOCKBfh6BbiAwB31BfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,582,1413259200"; d="scan'208";a="178529553" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 15 Dec 2014 18:42:11 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 1416BAEA32; Mon, 15 Dec 2014 18:42:11 -0500 (EST) Date: Mon, 15 Dec 2014 18:42:11 -0500 (EST) From: Rick Macklem To: Mehmet Erol Sanliturk Message-ID: <306385509.13293746.1418686931068.JavaMail.root@uoguelph.ca> In-Reply-To: Subject: Re: compiling on nfs directories MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-net@freebsd.org, Gerrit =?utf-8?B?S8O8aG4=?= X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Dec 2014 23:42:19 -0000 Mehmet Erol Sanilturk wrote: > On Mon, Dec 15, 2014 at 12:59 PM, Rick Macklem > wrote: > > > > Mehmet Erol Sanliturk wrote: > > > On Mon, Dec 15, 2014 at 1:24 AM, Gerrit K=C3=BChn > > > > > > wrote: > > > > > > > > Hi all, > > > > > > > > I ran into some weird issue here last week: > > > > I have an NFS-Server for storage and diskless booting (pxe / > > > > nfs > > > > root) > > > > running under FreeBSD. The clients are running Gentoo Linux. > > > > Some > > > > time > > > > ago, I replaced the server, going from a HDD-based storage > > > > array > > > > (ZFS) > > > > under FreeBSD 8.3 to an SSD-based array under FreeBSD 10-stable > > > > (as > > > > of > > > > February this year - I know this needs updates). > > > > > > > > Only now I recognized that this somehow appears to have broken > > > > some > > > > of my > > > > Gentoo ebuilds that do not install cleanly anymore. They > > > > complain > > > > about > > > > "soiled libtool library files found" and "insecure RUNPATHs" in > > > > the > > > > installation stage of shared libs. > > > > > > > > I was not able to find any useful solution for this in the Net > > > > so > > > > far. > > > > However, I was able to verify that this is somehow an issue > > > > with > > > > the nfs > > > > server by plugging in a USB-drive into the diskless clients and > > > > mounting > > > > this as /var/tmp/portage (the directory structure where > > > > Gentoo's > > > > ebuilds > > > > are compiled). This makes the error messages go away, and > > > > everything works > > > > again (like it did before the server update). > > > > > > > > Are there any suggestions what might be causing this and how to > > > > fix > > > > it? > > > > > > > > > > > > cu > > > > Gerrit > > > > > > > > > > > > > > > > > With respect to information given in your message , may pure > > > guess is > > > the > > > following : > > > > > > > > > When a client generates a file in NFS server , it assumes that > > > everything > > > is written into the file . > > > The next step ( reading the generated file ) starts , BUT the > > > file is > > > NOT > > > completely written into disk yet , > > > therefore it reads an incomplete file which causes errors in the > > > client . > > > > > Well, not exactly. The NFS client chooses whether or not the > > written > > data must be committed to stable storage (disk) right away via a > > flag > > argument on the write. It is up to the client to keep track of what > > has > > been written and if the FILE_STABLE flag wasn't set, must do a > > separate > > Commit RPC to force the data to stable storage on the server. > > It is also up to the NFS client to keep track of the file's size > > while > > it is being grown, since the NFS server's size may be smaller until > > the data gets written to the server. > > Also, note that he didn't see the problem with FreeBSD8.3, which > > would > > have been following the same rules on the server as 10.1. > > > > What I suspect might cause this is one of two things: > > 1 - The modify time of the file is now changing at a time the Linux > > client doesn't expect, due to changes in ZFS or maybe TOD clock > > resolution. (At one time, the TOD clock was only at a > > resolution > > of 1sec, so the client wouldn't see the modify time change > > often. > > I think it is now at a much higher resolution, but would have > > to > > look at the code/test to be sure.) > > 2 - I think you mention this one later in your message, in that the > > build might be depending on file locking. If this is the case, > > trying NFSv4, which does better file locking, might fix the > > problem. > > > > Gerrit, I would suggest that you do "nfsstat -m" on the Linux > > client, > > to see what the mount options are. The Linux client might be using > > NFSv4 > > already. > > Also, avoid "soft, intr" especially if you are using NFSv4, since > > these > > can cause slow server response to result in a failure of a > > read/write > > when it shouldn't fail, due to timeout or interruption by a signal. > > > > If you could find out more about what causes the specific build > > failure > > on the Linux side, that might help. > > If you can reproduce a build failure quickly/easily, you can > > capture > > packets via "tcpdump -s 0 -w host " on the > > server and then look at it in wireshark to see what the server is > > replying > > when the build failure occurs. (I don't mind looking at a packet > > trace if > > it is relatively small, if you email it to me as an attachment.) > > > > Good luck with it, rick > > ps: I am not familiar with the Linux mount options, but if it has > > stuff like "nocto", you could try those. > > > > > In FreeBSD NFS server , there is NOT ( or I could NOT be able to > > > find > > > ) a > > > facility to store written data immediately into disk . > > > > > > NFS server is collecting data up to a point ( number of bytes ) > > > and > > > then > > > writing it to disk , during this phase ( whether the NFS server > > > is > > > busy or > > > not ) is not important ) . With this structure , > > > the tasks which a program writes a small number of bytes to be > > > read > > > by > > > another program can not be > > > processed by a NFS server only . > > > > > > I did not try "locking in NFS server" : If this route is taken , > > > then > > > it is > > > necessary to adjust the clients for such periods to wait that NFS > > > server > > > has removed the lock which themselves can continue ( Each such > > > read > > > requires a waiting loop without generating an error message about > > > unavailable data and termination . ) . > > > > > > In Linux NFS server , there is an option to immediately write the > > > received > > > data into disk . This is improving the above situation > > > considerable > > > but not > > > completely solving the problem ( because during reads of data , > > > data > > > in > > > cache is NOT concatenated to the data in disk ) . > > > > > > > > > Another MAJOR problem is that , the NFS server is NOT > > > concatenating > > > data in > > > cache to data in disk during reads : This defect is making NFS > > > server > > > useless for , let's say "real time" , applications used > > > concurrently > > > or as > > > a single one by the clients without using another "Server" within > > > NFS > > > server . > > > > > > > > > > > > In your case , during software builds , a step is using the > > > previously > > > generated files : In local disk , writing and reading are > > > sequential > > > , in > > > the sense that written data is found during reading . In NFS > > > server > > > this is > > > not the case . > > > > > > > > > With respect to my knowledge obtained from messages in FreeBSD > > > mailing > > > lists about making a possibility to read data immediately after > > > it is > > > written into NFS server is NOT available . > > > > > > > > > > > > Thank you very much . > > > > > > Mehmet Erol Sanliturk > > > _______________________________________________ > > > >=20 >=20 >=20 >=20 >=20 > When a C program is written to be used in an NFS environment , some > possibilities may be used to synchronize write and reads from the > programs > with the unsolved "cached data" problem . >=20 > When ready programs are used , such as "make" , "ld" , there is no > choice . >=20 > I am using Pascal programs , then there is no such facilities . >=20 > The solution may be to improve the NFS Server and Client modules to > use > cached data during reads : >=20 > If end of file is reached : Before sending EOF signal , check whether > there > is data in cache or not . > If there is data in cache : continue reading from the cache > up to > end , > else send an EOF signal . >=20 > ( For random access files , also there is a need to look at the > cached > values . ) >=20 Well, the FreeBSD NFS client (and most others) do extensive data caching and will read data from the client cache whenever possible. NFS performance without client caching is pretty terrible. The problem (which has existed since NFS was first developed in about 1985) is that NFS does not provide a cache coherency protocol, so when multiple clients write data to a file concurrently, there is no guarantee that the c= lient read will get the most up-to-date data. There has been something called close-to-open (cto) consistency adopted, which says that a client will read= data written by another client after the writing client has closed the file. (Most NFS clients only implement this "approximately", since they depend on seeing th= e modify time change to determine this. This may not happen when multiple mod= ifications occur in the same time of day clock tick or when clients cache the file's attributes and use a stale cached modify time. Turning off client attribute caching improves this, but also results in a performance hit, due to the extra Getattr RPCs done.) The current consensus within the NFS community (driven by the Linux client implementation) is to only provide data consistency among multiple clients when byte range locking is used on the file. I'm not sure if this was what you were referring to. (It is true that NFS is not and cannot be a POSIX compliant file system, due to it's design.) "make" can often be confused when the modify time isn't updated when expect= ed. If an application running on FreeBSD wants to ensure that data is written t= o stable storage on the server, the application can call fsync(2). > Since the above modification requires knowledge of internal structure > of > NFS Server , and perhaps NFS Client ,I am not able to supply any > patch . > Also I am not able to understand its implementation difficulty . >=20 > My opinion is that the above modification would be a wonderful > improvement > for NFS system in FreeBSD , because it will behave just like a local > data > store usable as "real time" data processing tasks . In the present > structure , this is NOT possible with NFS Client and Server only . >=20 Many years ago, I implemented a cache coherency protocol for NFS called NQNFS. No one used it (at least not much) and it never caught on. Most care about NFS performance and data coherency has never been a priority with most users, from what I've seen. rick >=20 > Thank you very much . >=20 >=20 > Mehmet Erol Sanliturk > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Dec 16 00:29:03 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3BB12A9A for ; Tue, 16 Dec 2014 00:29:03 +0000 (UTC) Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E6EC82D2 for ; Tue, 16 Dec 2014 00:29:02 +0000 (UTC) Received: by mail-yh0-f42.google.com with SMTP id v1so5690679yhn.1 for ; Mon, 15 Dec 2014 16:29:02 -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=MAryyGDwCurdPs5uzkd8ElWv6lTlWvl2HjPY18Obmwo=; b=ugyhJrqcEm9oR0I8GXqWoE8foS3kg3u3ILXwiZL+83qIiLbndt5554a4jg9ZZAG3B5 kSsEOiSV+7sluBLh+NRw0TVji0uv9/yCPo6xryNuhtk539NsAWUCZt3sanZ+lmtDlnDR EzMJTzc3jc1NDDD03wAWogVpawVmmt9Lf/JT16pgBapT4pSnOCRe5E5Aa+bQrjvunwsN bibWkxOzUOGTC0CJcTNtKbPyJJK9PKFYL2VzNagK6rkImJKUfCkqsfQ9s+lTHtHHmp4k FTLpekR9xdi7IqIRkN1n3gBfTSgTydTtyq5UD23XCtCpqGP+ZWfM49BX4BZkaS4dxyBT Pg0A== MIME-Version: 1.0 X-Received: by 10.170.124.16 with SMTP id q16mr26845025ykb.107.1418689741997; Mon, 15 Dec 2014 16:29:01 -0800 (PST) Received: by 10.170.90.131 with HTTP; Mon, 15 Dec 2014 16:29:01 -0800 (PST) In-Reply-To: <306385509.13293746.1418686931068.JavaMail.root@uoguelph.ca> References: <306385509.13293746.1418686931068.JavaMail.root@uoguelph.ca> Date: Mon, 15 Dec 2014 16:29:01 -0800 Message-ID: Subject: Re: compiling on nfs directories From: Mehmet Erol Sanliturk To: Rick Macklem Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-net@freebsd.org, =?UTF-8?B?R2Vycml0IEvDvGhu?= X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Dec 2014 00:29:03 -0000 On Mon, Dec 15, 2014 at 3:42 PM, Rick Macklem wrote: > > Mehmet Erol Sanilturk wrote: > > On Mon, Dec 15, 2014 at 12:59 PM, Rick Macklem > > wrote: > > > > > > Mehmet Erol Sanliturk wrote: > > > > On Mon, Dec 15, 2014 at 1:24 AM, Gerrit K=C3=BChn > > > > > > > > wrote: > > > > > > > > > > Hi all, > > > > > > > > > > I ran into some weird issue here last week: > > > > > I have an NFS-Server for storage and diskless booting (pxe / > > > > > nfs > > > > > root) > > > > > running under FreeBSD. The clients are running Gentoo Linux. > > > > > Some > > > > > time > > > > > ago, I replaced the server, going from a HDD-based storage > > > > > array > > > > > (ZFS) > > > > > under FreeBSD 8.3 to an SSD-based array under FreeBSD 10-stable > > > > > (as > > > > > of > > > > > February this year - I know this needs updates). > > > > > > > > > > Only now I recognized that this somehow appears to have broken > > > > > some > > > > > of my > > > > > Gentoo ebuilds that do not install cleanly anymore. They > > > > > complain > > > > > about > > > > > "soiled libtool library files found" and "insecure RUNPATHs" in > > > > > the > > > > > installation stage of shared libs. > > > > > > > > > > I was not able to find any useful solution for this in the Net > > > > > so > > > > > far. > > > > > However, I was able to verify that this is somehow an issue > > > > > with > > > > > the nfs > > > > > server by plugging in a USB-drive into the diskless clients and > > > > > mounting > > > > > this as /var/tmp/portage (the directory structure where > > > > > Gentoo's > > > > > ebuilds > > > > > are compiled). This makes the error messages go away, and > > > > > everything works > > > > > again (like it did before the server update). > > > > > > > > > > Are there any suggestions what might be causing this and how to > > > > > fix > > > > > it? > > > > > > > > > > > > > > > cu > > > > > Gerrit > > > > > > > > > > > > > > > > > > > > > > With respect to information given in your message , may pure > > > > guess is > > > > the > > > > following : > > > > > > > > > > > > When a client generates a file in NFS server , it assumes that > > > > everything > > > > is written into the file . > > > > The next step ( reading the generated file ) starts , BUT the > > > > file is > > > > NOT > > > > completely written into disk yet , > > > > therefore it reads an incomplete file which causes errors in the > > > > client . > > > > > > > Well, not exactly. The NFS client chooses whether or not the > > > written > > > data must be committed to stable storage (disk) right away via a > > > flag > > > argument on the write. It is up to the client to keep track of what > > > has > > > been written and if the FILE_STABLE flag wasn't set, must do a > > > separate > > > Commit RPC to force the data to stable storage on the server. > > > It is also up to the NFS client to keep track of the file's size > > > while > > > it is being grown, since the NFS server's size may be smaller until > > > the data gets written to the server. > > > Also, note that he didn't see the problem with FreeBSD8.3, which > > > would > > > have been following the same rules on the server as 10.1. > > > > > > What I suspect might cause this is one of two things: > > > 1 - The modify time of the file is now changing at a time the Linux > > > client doesn't expect, due to changes in ZFS or maybe TOD clock > > > resolution. (At one time, the TOD clock was only at a > > > resolution > > > of 1sec, so the client wouldn't see the modify time change > > > often. > > > I think it is now at a much higher resolution, but would have > > > to > > > look at the code/test to be sure.) > > > 2 - I think you mention this one later in your message, in that the > > > build might be depending on file locking. If this is the case, > > > trying NFSv4, which does better file locking, might fix the > > > problem. > > > > > > Gerrit, I would suggest that you do "nfsstat -m" on the Linux > > > client, > > > to see what the mount options are. The Linux client might be using > > > NFSv4 > > > already. > > > Also, avoid "soft, intr" especially if you are using NFSv4, since > > > these > > > can cause slow server response to result in a failure of a > > > read/write > > > when it shouldn't fail, due to timeout or interruption by a signal. > > > > > > If you could find out more about what causes the specific build > > > failure > > > on the Linux side, that might help. > > > If you can reproduce a build failure quickly/easily, you can > > > capture > > > packets via "tcpdump -s 0 -w host " on the > > > server and then look at it in wireshark to see what the server is > > > replying > > > when the build failure occurs. (I don't mind looking at a packet > > > trace if > > > it is relatively small, if you email it to me as an attachment.) > > > > > > Good luck with it, rick > > > ps: I am not familiar with the Linux mount options, but if it has > > > stuff like "nocto", you could try those. > > > > > > > In FreeBSD NFS server , there is NOT ( or I could NOT be able to > > > > find > > > > ) a > > > > facility to store written data immediately into disk . > > > > > > > > NFS server is collecting data up to a point ( number of bytes ) > > > > and > > > > then > > > > writing it to disk , during this phase ( whether the NFS server > > > > is > > > > busy or > > > > not ) is not important ) . With this structure , > > > > the tasks which a program writes a small number of bytes to be > > > > read > > > > by > > > > another program can not be > > > > processed by a NFS server only . > > > > > > > > I did not try "locking in NFS server" : If this route is taken , > > > > then > > > > it is > > > > necessary to adjust the clients for such periods to wait that NFS > > > > server > > > > has removed the lock which themselves can continue ( Each such > > > > read > > > > requires a waiting loop without generating an error message about > > > > unavailable data and termination . ) . > > > > > > > > In Linux NFS server , there is an option to immediately write the > > > > received > > > > data into disk . This is improving the above situation > > > > considerable > > > > but not > > > > completely solving the problem ( because during reads of data , > > > > data > > > > in > > > > cache is NOT concatenated to the data in disk ) . > > > > > > > > > > > > Another MAJOR problem is that , the NFS server is NOT > > > > concatenating > > > > data in > > > > cache to data in disk during reads : This defect is making NFS > > > > server > > > > useless for , let's say "real time" , applications used > > > > concurrently > > > > or as > > > > a single one by the clients without using another "Server" within > > > > NFS > > > > server . > > > > > > > > > > > > > > > > In your case , during software builds , a step is using the > > > > previously > > > > generated files : In local disk , writing and reading are > > > > sequential > > > > , in > > > > the sense that written data is found during reading . In NFS > > > > server > > > > this is > > > > not the case . > > > > > > > > > > > > With respect to my knowledge obtained from messages in FreeBSD > > > > mailing > > > > lists about making a possibility to read data immediately after > > > > it is > > > > written into NFS server is NOT available . > > > > > > > > > > > > > > > > Thank you very much . > > > > > > > > Mehmet Erol Sanliturk > > > > _______________________________________________ > > > > > > > > > > > > > > > > When a C program is written to be used in an NFS environment , some > > possibilities may be used to synchronize write and reads from the > > programs > > with the unsolved "cached data" problem . > > > > When ready programs are used , such as "make" , "ld" , there is no > > choice . > > > > I am using Pascal programs , then there is no such facilities . > > > > The solution may be to improve the NFS Server and Client modules to > > use > > cached data during reads : > > > > If end of file is reached : Before sending EOF signal , check whether > > there > > is data in cache or not . > > If there is data in cache : continue reading from the cache > > up to > > end , > > else send an EOF signal . > > > > ( For random access files , also there is a need to look at the > > cached > > values . ) > > > Well, the FreeBSD NFS client (and most others) do extensive data caching > and will read data from the client cache whenever possible. NFS performan= ce > without client caching is pretty terrible. > > The problem (which has existed since NFS was first developed in about 198= 5) > is that NFS does not provide a cache coherency protocol, so when multiple > clients write data to a file concurrently, there is no guarantee that the > client > read will get the most up-to-date data. There has been something called > close-to-open (cto) consistency adopted, which says that a client will > read data written > by another client after the writing client has closed the file. (Most NFS > clients only implement this "approximately", since they depend on seeing > the > modify time change to determine this. This may not happen when multiple > modifications > occur in the same time of day clock tick or when clients cache the file's > attributes and use a stale cached modify time. Turning off client attribu= te > caching improves this, but also results in a performance hit, due to the > extra Getattr RPCs done.) > > The current consensus within the NFS community (driven by the Linux clien= t > implementation) is to only provide data consistency among multiple client= s > when byte range locking is used on the file. > > I'm not sure if this was what you were referring to. (It is true that NFS > is not and cannot be a POSIX compliant file system, due to it's design.) > > "make" can often be confused when the modify time isn't updated when > expected. > > If an application running on FreeBSD wants to ensure that data is written > to > stable storage on the server, the application can call fsync(2). > > > Since the above modification requires knowledge of internal structure > > of > > NFS Server , and perhaps NFS Client ,I am not able to supply any > > patch . > > Also I am not able to understand its implementation difficulty . > > > > My opinion is that the above modification would be a wonderful > > improvement > > for NFS system in FreeBSD , because it will behave just like a local > > data > > store usable as "real time" data processing tasks . In the present > > structure , this is NOT possible with NFS Client and Server only . > > > Many years ago, I implemented a cache coherency protocol for NFS called > NQNFS. No one used it (at least not much) and it never caught on. > Most care about NFS performance and data coherency has never been a > priority with most users, from what I've seen. > > rick > With respect to given information in The Design and Implementation of the FreeBSD Operating System By Marshall Kirk McKusick, George V. Neville-Neil, Robert N.M. Watson Second Edition : p. 559 NQNFS has been removed from FreeBSD Version 5 on . It was available in Version 4.11 : http://svnweb.freebsd.org/base/release/4.11.0/sys/nfs/nqnfs.h?view=3Dmarkup ( 1 ) Is there a newer version of NQNFS other than the above which is available ? A link would be very good , if it is available . (2) Are there other systems which is using NQNFS in their current distributions ? > > > > > Thank you very much . > > > > > > Mehmet Erol Sanliturk > > > From owner-freebsd-net@FreeBSD.ORG Tue Dec 16 01:31:20 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B4F0B542 for ; Tue, 16 Dec 2014 01:31:20 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 5AD48B8C for ; Tue, 16 Dec 2014 01:31:19 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAOSKj1SDaFve/2dsb2JhbABag1hYBIMCwl0MhSZKAoE4AQEBAQF9hAwBAQEDAQEBASArIAYFBRYYAgINGQIpAQkmBggHBAETBwIEiAMIDb1qll4BAQEBAQUBAQEBAQEBAQEZgSGIaYNbgSsQAgEGFQEzB4ItOxGBMAWJPoJehSSDHIMgMIRfRoMYgTSCU4M4IoF+HoFuIDABAQEEfUF+AQEB X-IronPort-AV: E=Sophos;i="5.07,583,1413259200"; d="scan'208";a="178550281" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 15 Dec 2014 20:31:17 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id BC1E3AEA51; Mon, 15 Dec 2014 20:31:17 -0500 (EST) Date: Mon, 15 Dec 2014 20:31:17 -0500 (EST) From: Rick Macklem To: Mehmet Erol Sanliturk Message-ID: <1877801167.13336057.1418693477745.JavaMail.root@uoguelph.ca> In-Reply-To: Subject: Re: compiling on nfs directories MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-net@freebsd.org, Gerrit =?utf-8?B?S8O8aG4=?= X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Dec 2014 01:31:20 -0000 Mehmet Erol Sanliturk wrote: > On Mon, Dec 15, 2014 at 3:42 PM, Rick Macklem > wrote: > > > > Mehmet Erol Sanilturk wrote: > > > On Mon, Dec 15, 2014 at 12:59 PM, Rick Macklem > > > > > > wrote: > > > > > > > > Mehmet Erol Sanliturk wrote: > > > > > On Mon, Dec 15, 2014 at 1:24 AM, Gerrit K=C3=BChn > > > > > > > > > > wrote: > > > > > > > > > > > > Hi all, > > > > > > > > > > > > I ran into some weird issue here last week: > > > > > > I have an NFS-Server for storage and diskless booting (pxe > > > > > > / > > > > > > nfs > > > > > > root) > > > > > > running under FreeBSD. The clients are running Gentoo > > > > > > Linux. > > > > > > Some > > > > > > time > > > > > > ago, I replaced the server, going from a HDD-based storage > > > > > > array > > > > > > (ZFS) > > > > > > under FreeBSD 8.3 to an SSD-based array under FreeBSD > > > > > > 10-stable > > > > > > (as > > > > > > of > > > > > > February this year - I know this needs updates). > > > > > > > > > > > > Only now I recognized that this somehow appears to have > > > > > > broken > > > > > > some > > > > > > of my > > > > > > Gentoo ebuilds that do not install cleanly anymore. They > > > > > > complain > > > > > > about > > > > > > "soiled libtool library files found" and "insecure > > > > > > RUNPATHs" in > > > > > > the > > > > > > installation stage of shared libs. > > > > > > > > > > > > I was not able to find any useful solution for this in the > > > > > > Net > > > > > > so > > > > > > far. > > > > > > However, I was able to verify that this is somehow an issue > > > > > > with > > > > > > the nfs > > > > > > server by plugging in a USB-drive into the diskless clients > > > > > > and > > > > > > mounting > > > > > > this as /var/tmp/portage (the directory structure where > > > > > > Gentoo's > > > > > > ebuilds > > > > > > are compiled). This makes the error messages go away, and > > > > > > everything works > > > > > > again (like it did before the server update). > > > > > > > > > > > > Are there any suggestions what might be causing this and > > > > > > how to > > > > > > fix > > > > > > it? > > > > > > > > > > > > > > > > > > cu > > > > > > Gerrit > > > > > > > > > > > > > > > > > > > > > > > > > > > With respect to information given in your message , may pure > > > > > guess is > > > > > the > > > > > following : > > > > > > > > > > > > > > > When a client generates a file in NFS server , it assumes > > > > > that > > > > > everything > > > > > is written into the file . > > > > > The next step ( reading the generated file ) starts , BUT the > > > > > file is > > > > > NOT > > > > > completely written into disk yet , > > > > > therefore it reads an incomplete file which causes errors in > > > > > the > > > > > client . > > > > > > > > > Well, not exactly. The NFS client chooses whether or not the > > > > written > > > > data must be committed to stable storage (disk) right away via > > > > a > > > > flag > > > > argument on the write. It is up to the client to keep track of > > > > what > > > > has > > > > been written and if the FILE_STABLE flag wasn't set, must do a > > > > separate > > > > Commit RPC to force the data to stable storage on the server. > > > > It is also up to the NFS client to keep track of the file's > > > > size > > > > while > > > > it is being grown, since the NFS server's size may be smaller > > > > until > > > > the data gets written to the server. > > > > Also, note that he didn't see the problem with FreeBSD8.3, > > > > which > > > > would > > > > have been following the same rules on the server as 10.1. > > > > > > > > What I suspect might cause this is one of two things: > > > > 1 - The modify time of the file is now changing at a time the > > > > Linux > > > > client doesn't expect, due to changes in ZFS or maybe TOD > > > > clock > > > > resolution. (At one time, the TOD clock was only at a > > > > resolution > > > > of 1sec, so the client wouldn't see the modify time change > > > > often. > > > > I think it is now at a much higher resolution, but would > > > > have > > > > to > > > > look at the code/test to be sure.) > > > > 2 - I think you mention this one later in your message, in that > > > > the > > > > build might be depending on file locking. If this is the > > > > case, > > > > trying NFSv4, which does better file locking, might fix the > > > > problem. > > > > > > > > Gerrit, I would suggest that you do "nfsstat -m" on the Linux > > > > client, > > > > to see what the mount options are. The Linux client might be > > > > using > > > > NFSv4 > > > > already. > > > > Also, avoid "soft, intr" especially if you are using NFSv4, > > > > since > > > > these > > > > can cause slow server response to result in a failure of a > > > > read/write > > > > when it shouldn't fail, due to timeout or interruption by a > > > > signal. > > > > > > > > If you could find out more about what causes the specific build > > > > failure > > > > on the Linux side, that might help. > > > > If you can reproduce a build failure quickly/easily, you can > > > > capture > > > > packets via "tcpdump -s 0 -w host " on > > > > the > > > > server and then look at it in wireshark to see what the server > > > > is > > > > replying > > > > when the build failure occurs. (I don't mind looking at a > > > > packet > > > > trace if > > > > it is relatively small, if you email it to me as an > > > > attachment.) > > > > > > > > Good luck with it, rick > > > > ps: I am not familiar with the Linux mount options, but if it > > > > has > > > > stuff like "nocto", you could try those. > > > > > > > > > In FreeBSD NFS server , there is NOT ( or I could NOT be able > > > > > to > > > > > find > > > > > ) a > > > > > facility to store written data immediately into disk . > > > > > > > > > > NFS server is collecting data up to a point ( number of bytes > > > > > ) > > > > > and > > > > > then > > > > > writing it to disk , during this phase ( whether the NFS > > > > > server > > > > > is > > > > > busy or > > > > > not ) is not important ) . With this structure , > > > > > the tasks which a program writes a small number of bytes to > > > > > be > > > > > read > > > > > by > > > > > another program can not be > > > > > processed by a NFS server only . > > > > > > > > > > I did not try "locking in NFS server" : If this route is > > > > > taken , > > > > > then > > > > > it is > > > > > necessary to adjust the clients for such periods to wait that > > > > > NFS > > > > > server > > > > > has removed the lock which themselves can continue ( Each > > > > > such > > > > > read > > > > > requires a waiting loop without generating an error message > > > > > about > > > > > unavailable data and termination . ) . > > > > > > > > > > In Linux NFS server , there is an option to immediately write > > > > > the > > > > > received > > > > > data into disk . This is improving the above situation > > > > > considerable > > > > > but not > > > > > completely solving the problem ( because during reads of data > > > > > , > > > > > data > > > > > in > > > > > cache is NOT concatenated to the data in disk ) . > > > > > > > > > > > > > > > Another MAJOR problem is that , the NFS server is NOT > > > > > concatenating > > > > > data in > > > > > cache to data in disk during reads : This defect is making > > > > > NFS > > > > > server > > > > > useless for , let's say "real time" , applications used > > > > > concurrently > > > > > or as > > > > > a single one by the clients without using another "Server" > > > > > within > > > > > NFS > > > > > server . > > > > > > > > > > > > > > > > > > > > In your case , during software builds , a step is using the > > > > > previously > > > > > generated files : In local disk , writing and reading are > > > > > sequential > > > > > , in > > > > > the sense that written data is found during reading . In NFS > > > > > server > > > > > this is > > > > > not the case . > > > > > > > > > > > > > > > With respect to my knowledge obtained from messages in > > > > > FreeBSD > > > > > mailing > > > > > lists about making a possibility to read data immediately > > > > > after > > > > > it is > > > > > written into NFS server is NOT available . > > > > > > > > > > > > > > > > > > > > Thank you very much . > > > > > > > > > > Mehmet Erol Sanliturk > > > > > _______________________________________________ > > > > > > > > > > > > > > > > > > > > > > > When a C program is written to be used in an NFS environment , > > > some > > > possibilities may be used to synchronize write and reads from the > > > programs > > > with the unsolved "cached data" problem . > > > > > > When ready programs are used , such as "make" , "ld" , there is > > > no > > > choice . > > > > > > I am using Pascal programs , then there is no such facilities . > > > > > > The solution may be to improve the NFS Server and Client modules > > > to > > > use > > > cached data during reads : > > > > > > If end of file is reached : Before sending EOF signal , check > > > whether > > > there > > > is data in cache or not . > > > If there is data in cache : continue reading from the > > > cache > > > up to > > > end , > > > else send an EOF signal . > > > > > > ( For random access files , also there is a need to look at the > > > cached > > > values . ) > > > > > Well, the FreeBSD NFS client (and most others) do extensive data > > caching > > and will read data from the client cache whenever possible. NFS > > performance > > without client caching is pretty terrible. > > > > The problem (which has existed since NFS was first developed in > > about 1985) > > is that NFS does not provide a cache coherency protocol, so when > > multiple > > clients write data to a file concurrently, there is no guarantee > > that the > > client > > read will get the most up-to-date data. There has been something > > called > > close-to-open (cto) consistency adopted, which says that a client > > will > > read data written > > by another client after the writing client has closed the file. > > (Most NFS > > clients only implement this "approximately", since they depend on > > seeing > > the > > modify time change to determine this. This may not happen when > > multiple > > modifications > > occur in the same time of day clock tick or when clients cache the > > file's > > attributes and use a stale cached modify time. Turning off client > > attribute > > caching improves this, but also results in a performance hit, due > > to the > > extra Getattr RPCs done.) > > > > The current consensus within the NFS community (driven by the Linux > > client > > implementation) is to only provide data consistency among multiple > > clients > > when byte range locking is used on the file. > > > > I'm not sure if this was what you were referring to. (It is true > > that NFS > > is not and cannot be a POSIX compliant file system, due to it's > > design.) > > > > "make" can often be confused when the modify time isn't updated > > when > > expected. > > > > If an application running on FreeBSD wants to ensure that data is > > written > > to > > stable storage on the server, the application can call fsync(2). > > > > > Since the above modification requires knowledge of internal > > > structure > > > of > > > NFS Server , and perhaps NFS Client ,I am not able to supply any > > > patch . > > > Also I am not able to understand its implementation difficulty . > > > > > > My opinion is that the above modification would be a wonderful > > > improvement > > > for NFS system in FreeBSD , because it will behave just like a > > > local > > > data > > > store usable as "real time" data processing tasks . In the > > > present > > > structure , this is NOT possible with NFS Client and Server only > > > . > > > > > Many years ago, I implemented a cache coherency protocol for NFS > > called > > NQNFS. No one used it (at least not much) and it never caught on. > > Most care about NFS performance and data coherency has never been a > > priority with most users, from what I've seen. > > > > rick > > >=20 >=20 > With respect to given information in >=20 > The Design and Implementation of the FreeBSD Operating System > By Marshall Kirk McKusick, George V. Neville-Neil, Robert N.M. > Watson >=20 > Second Edition : p. 559 >=20 >=20 > NQNFS has been removed from FreeBSD Version 5 on . >=20 > It was available in Version 4.11 : >=20 > http://svnweb.freebsd.org/base/release/4.11.0/sys/nfs/nqnfs.h?view=3Dmark= up >=20 >=20 > ( 1 ) Is there a newer version of NQNFS other than the above which > is > available ? > A link would be very good , if it is available . >=20 >=20 > (2) Are there other systems which is using NQNFS in their current > distributions ? >=20 Not that I know of. It's long gone dead and buried... rick >=20 >=20 >=20 > > > > > > > > Thank you very much . > > > > > > > > > Mehmet Erol Sanliturk > > > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Dec 16 04:26:04 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5A5796E for ; Tue, 16 Dec 2014 04:26:04 +0000 (UTC) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7576FEA2 for ; Tue, 16 Dec 2014 04:26:04 +0000 (UTC) Received: by mail-ig0-f171.google.com with SMTP id z20so6261429igj.4 for ; Mon, 15 Dec 2014 20:26:03 -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=/JcgtGq44qHlw5E/zjhTd9SvBPEdGRTLdvz+q5S9gIg=; b=bI5lzkpmrFIozvW96uJPWXF9ZdCfyB4pDgohuypyvc4+rA9zA3waM9QQg9s6DbtT9r 0y2W9HaxsIhekDfmbo/6Hh15aDEBIndlfwFbnfj57S68ASHK+jngOESTOOIZjgrgig6b uPgUvf/H45swEWIRtXKO/Hg4l6EWVG4hXfGuHLTkXdaTsS8jxznCjr59jLVAUd4UDps0 Uv/cFj54XfpYlpS/OxG/yeV0IwKeV7moOV8hvm7gj6xoY+Pl6fab3WZss23L74/+DM3j qTPMOLn8Ul8ndGunA1vzwLqIvBFiLuyvpK1dRUbK/m9xbcsFD4Wy8CsRjFmPsB2BrAqL +1VQ== MIME-Version: 1.0 X-Received: by 10.42.194.17 with SMTP id dw17mr30276769icb.4.1418703956503; Mon, 15 Dec 2014 20:25:56 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.107.52.19 with HTTP; Mon, 15 Dec 2014 20:25:56 -0800 (PST) In-Reply-To: <548F2250.3010507@bsdinfo.com.br> References: <548C3072.10303@bsdinfo.com.br> <548F2250.3010507@bsdinfo.com.br> Date: Mon, 15 Dec 2014 20:25:56 -0800 X-Google-Sender-Auth: HffAT4otnzm5yBz4wNraQps28N0 Message-ID: Subject: Re: DNS resolution problem From: Kevin Oberman To: Marcelo Gondim Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Dec 2014 04:26:04 -0000 On Mon, Dec 15, 2014 at 10:02 AM, Marcelo Gondim wrote: > Hi Kevin, > > On 13/12/2014 23:44, Kevin Oberman wrote: > >> On Sat, Dec 13, 2014 at 4:26 AM, Marcelo Gondim >> wrote: >> >> Dear, >>> >>> I'm having trouble resolving domain name freebsd.org. The portsnap >>> server >>> works correctly but the pkg audit -F does not work and can not even >>> access >>> the site according to the following tests: >>> >>> # host ec2-sa-east-1.portsnap.freebsd.org >>> ec2-sa-east-1.portsnap.freebsd.org has address 177.71.188.240 >>> >>> # host vuxml.freebsd.org >>> Host vuxml.freebsd.org not found: 3(NXDOMAIN) >>> >>> # host -a freebsd.org >>> Trying "freebsd.org" >>> Trying "freebsd.org.intnet.com.br" >>> Host freebsd.org not found: 3(NXDOMAIN) >>> Received 86 bytes from ::1#53 in 0 ms >>> >>> # host www.freebsd.org >>> ;; connection timed out; no servers could be reached >>> >>> Only the first address I'm having name resolution >>> (ec2-sa-east-1.portsnap. >>> freebsd.org). >>> >>> My block IP: 186.193.48.0/20 >>> >>> One could check for any restrictions on our IP block? >>> >>> I think a bit of DNS debugging is in order. >>> >> I could resolve all of the nodes you listed, but there are some potential >> issues I see. First, when looking up hostname with host(1), always >> terminate the name: >> >>> host -a freebsd.org. >>> >> Trying "freebsd.org" >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24171 >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 >> >> ;; QUESTION SECTION: >> ;freebsd.org. IN TYPE255 >> >> ;; ANSWER SECTION: >> freebsd.org. 534 IN AAAA 2001:1900:2254:206a::50:0 >> freebsd.org. 534 IN MX 10 mx1.freebsd.org. >> freebsd.org. 534 IN A 8.8.178.110 >> >> But "ANY" queries are fuzzy things at best as the first resolver you hit >> will just return whatever is cached and not try getting an authoritative >> response. >> >> www.freebsd.org and vuxml.freebsd.org are CNAME entries pointing to the >> same place, 8.8.178.110. This is in FreeBSD's own address space from Yahoo >> nd is probably in the mail FreeBSD cluster. I was a bit surprised to find >> that is is an Amazon AWS address, so the portsnap files are actually >> coming >> from a totally different place. >> >> DNS is provided by ISC-SNS. 72.52.71.1, 38.103.2.1 and 63.243.194.1. Try >> pinging these. Since BIND, the second oldest and most popular DNS server >> is >> written and supported by ISA, I would think that it is well run. Try >> pinging and tracing to these addresses. All of them are in very dispersed >> locations on different provider backbones. (Cogent, Hurricane Electric, >> and >> ISC, itself. You might try directing queries to each system to see if one >> fails when other succeed. Use "dig @servr-addr host". >> > Other tests: > > # ping -c 5 NS1.ISC-SNS.NET > PING ns1.isc-sns.net (72.52.71.1): 56 data bytes > 64 bytes from 72.52.71.1: icmp_seq=0 ttl=56 time=144.327 ms > 64 bytes from 72.52.71.1: icmp_seq=1 ttl=56 time=145.445 ms > 64 bytes from 72.52.71.1: icmp_seq=2 ttl=56 time=144.999 ms > 64 bytes from 72.52.71.1: icmp_seq=3 ttl=56 time=146.775 ms > 64 bytes from 72.52.71.1: icmp_seq=4 ttl=56 time=145.207 ms > > --- ns1.isc-sns.net ping statistics --- > 5 packets transmitted, 5 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 144.327/145.351/146.775/0.804 ms > > # ping -c 5 NS2.ISC-SNS.COM > PING ns2.isc-sns.com (38.103.2.1): 56 data bytes > 64 bytes from 38.103.2.1: icmp_seq=0 ttl=54 time=133.839 ms > 64 bytes from 38.103.2.1: icmp_seq=1 ttl=54 time=133.831 ms > 64 bytes from 38.103.2.1: icmp_seq=2 ttl=54 time=133.972 ms > 64 bytes from 38.103.2.1: icmp_seq=3 ttl=54 time=133.957 ms > 64 bytes from 38.103.2.1: icmp_seq=4 ttl=54 time=133.851 ms > > --- ns2.isc-sns.com ping statistics --- > 5 packets transmitted, 5 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 133.831/133.890/133.972/0.061 ms > > # ping -c 5 NS3.ISC-SNS.INFO > PING ns3.isc-sns.info (63.243.194.1): 56 data bytes > 64 bytes from 63.243.194.1: icmp_seq=0 ttl=59 time=185.755 ms > 64 bytes from 63.243.194.1: icmp_seq=1 ttl=59 time=185.790 ms > 64 bytes from 63.243.194.1: icmp_seq=2 ttl=59 time=185.866 ms > 64 bytes from 63.243.194.1: icmp_seq=3 ttl=59 time=185.931 ms > 64 bytes from 63.243.194.1: icmp_seq=4 ttl=59 time=185.988 ms > > --- ns3.isc-sns.info ping statistics --- > 5 packets transmitted, 5 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 185.755/185.866/185.988/0.086 ms > > # host -a freebsd.org 72.52.71.1 > Trying "freebsd.org" > ;; Truncated, retrying in TCP mode. > Using domain server: > Name: 72.52.71.1 > Address: 72.52.71.1#53 > Aliases: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15306 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 20, AUTHORITY: 0, ADDITIONAL: 7 > > ;; QUESTION SECTION: > ;freebsd.org. IN TYPE255 > > ;; ANSWER SECTION: > freebsd.org. 3600 IN SOA ns0.freebsd.org. > hostmaster.freebsd.org. 2014121517 3600 900 604800 600 > freebsd.org. 3600 IN RRSIG SOA 8 2 3600 > 20141229134836 20141215162412 22689 freebsd.org. Li3FZ22mk+j4FbIRp7rQD/QS/ > m3UCFvMDqdUfdLBOPEpOiCTLue+5xFhtr6mLwJ6mYzbsATM3rHN/O+ > B1VF3VzytnOOYh0QvoqpjxwGcUWNAkAlOCFDrqaS5wp9PfWOBJ+1q+xbkgC/ > iwBmasqb06G1WpcvpRq9kYoZUum8RxAGuTQIYNhoDxUjU5r6yiTvWy3sCmpu02F846BcJ6+ > LBKhsd8OuOJYplYhjFOfszl8uQmUtyCxCDm9udsWHbNyVMPU/ > DeVPKSlBS5md1l07GcG2QDepH4ChxQZnejmhaXgi/6+680v7Ufgh51xb5QiU2Xg7ATwplvor2 > VwJphSwMAw== > freebsd.org. 3600 IN RRSIG DNSKEY 8 2 3600 > 20141228141417 20141214022412 32659 freebsd.org. > Cf1nX8IQROLxXzL9WTDJVRdHuGN344DnIzKrshoG9sbYkP/ > DTDMMt9mpDCUUz0HK0FgxhHw45oepm6+KMbydzZDWhK2+G/ > LPgyK5nzsxnaJc9EgHpg6OKCQw7HHDirfe8lr0es0Ab4mPicqMKg31r7272S > EKJ6HGoezzW5wtokTJpegAGQhW+b8ZvpBqRcj3jYIU9HvBOJtn/ZNrXMg2mUP/ > tbkxDcBy7ssMNmy0s0GKu6Daqq1VSK0BKvEIPc/sUC+mKkUo259FkI2Lnfml3vsw+aV0behgp/ > VpoxRfotcNjFNJGhYGF0B0iwTQIdBnfMWlNXsQBnoQ8b7W+OLiRw== > freebsd.org. 0 IN RRSIG NSEC3PARAM 8 2 0 > 20141219185954 20141206012400 22689 freebsd.org. > ViAARy2wfDAUXV7AEzQFbge0hCJSU1/vusbRoWkaM1EVkOQbaCiSQ1PDanZmR > 4yQncdo2M3d4gJtIHgvZ5xzeo0/2AhlSVw/GAtWjJkqI/ > 8rJZ2ZPtoXy6SJBcNAcGKTx74EjFN/TIxDIEXKNss2BNz3y57olnknvqgVpN > jGu8jzc59aDww4+cgh9v7zuMG1YAncCnHwTIaxtsXN/K0jjKx9CtkVwJLJCRd4bthKyrPkBNM > Z3cDOX27MlQFC7461WsPkNxsxFYfUWO4g8f41UUYzPX2c59tKm+ > qJB7s56KLihZIuBjTZnROyTkvFFcdG3ii9dzFqbEN8PMwJIS7bzw== > freebsd.org. 600 IN RRSIG NS 8 2 600 20141221172508 > 20141207182403 22689 freebsd.org. ny0XoD9xYbSX5nHbDnl5iCIofSBlkw > B8dPjeUcmKfyylrpiPVDkXfl+xfacqJj7DRvf5gF8fLhe0lwTu3cLeV > XGf9L3UfD5N5sd61SxLLXy8gDHtjCQWS5/VYE4rIn6/leoqRD5YVPGJ1OWRBHSnVIjdib/ > R7XLLz6v8CMT4l+P42tDf7z56hjc3BNplcD/KjFfrEmoBlRIwvs9XaR3i+Qvl/ > 0uKnGgeaXVvRMgCthC4J4oZKsBt0hpAhwy3ocOOGhp1uLV+/sBUd4ZMi0HG0G+OZbelVt01LE/ > 7Kp5+4TA7i5Ubla8/kEcx7iKjqimnTb+0GF7+WrZbVe3MrTi9Jg== > freebsd.org. 600 IN RRSIG TXT 8 2 600 > 20141221200324 20141207122402 22689 freebsd.org. uf81IQ/nUDeVhLtUw/ > g4ILoW3Pq1rl9ub8p4MBkuGxhpmZSpm1phmJ47xuDkEg137SwqdP/mIx/ > EIRZ1Oah5Hx1e0278qJSX1M9DMwscCjXl3uPTqgYfL/M9k15U3OJ3i9yI4Stsp6ORG3Rj4bYY > Yz3mzlSNV64ZOnkW9JfPu/GjEq21EXgF9SEABJr21dwEUeCpmng15MHpmpTIJIwkgdH4DC7Dh/ > glQ6yMDEcf6I4x63hmj4CWpChs18W94esshEfZVTeiKV7xFPvgrnsbrO660J > vua7XR3R4mqr9sqv2mXKJICNobBNx/IyAxw9vw5dE7ohFptPEH7DUDN/h4jw== > freebsd.org. 600 IN RRSIG MX 8 2 600 20141222062628 > 20141208062403 22689 freebsd.org. exRPLUyRmbRbxQEYu989+ > agnNMIjXl7PsfPGW8xaoq2Dv0/GbOGnAPlSALg3MBPz8R+pL3MWiaexyi/ > 1qxUF6n0tItn7hQhUla4jri7rMFzMUcvePPr6t5sF/MWkIC+15O5QlIUx/ > Bi0zUnUFPSXCKH3MWr0oqGNzzc3jSqsUlqBhQmZq3KCrSE62Tp3VDthFhZUS > Y29EAmmwnAlTxQR9ZX3eVEM5oJ5UrhFkBcMhv4jVtSN+OncYx4PQWHNk4DR9vY3FCVl48XqJ9i > vln9vHOOCqfzl5oaSXeE6rnbHwEKpOZX65l24nPuNtKVPajYEAroK4xMqCdkPW4Ov0tw3zA== > freebsd.org. 600 IN RRSIG A 8 2 600 20141221151124 > 20141207232403 22689 freebsd.org. VPOX9ep1tYDF7dFaY37zXAMHwd+ > ySWAeSAMa45btmNzCD/F1pkUi9wH57LPE3jtqeHF4coKfZCvz > BED5KWfyYMDZsWOaTNA2Hxh4h+WRr4qK1FxeilvIDLYs1/ynGCcaAfTM8T7OwAueWx/ > x78bshaw8mkI8Pp38SpkHa0sL5T4/L9NP8NOUOP5I6zv2xFtqkcQBSWZLFE > lGHn3JBo3ZyGa9lUsjnNfNWwNCLcDbXG7aQCW88v+mxbnIq2lHogqOsYXQHnatpK7qV27c2 > XNB9ZuGmWq6zLFUFOXH1pDLf0ftIg70Evy+88RomIFLo9e9qNYI9WJk7Z51gL7ygA/YSg== > freebsd.org. 600 IN RRSIG AAAA 8 2 600 > 20141222031959 20141208092403 22689 freebsd.org. U88G56Mlmb6l4xv+G+ > IdvLAQQ8g5quIvKVjBSTcC5QdO52C/kUGcoo2rE+phXqXK7j7vgcfEuSI2qP3FDCG2K1VU > n19+oCHA/LVzx4sNGsVlqXDfieE7c48vVYeukalh7cCXQ53dGo/4Tpps3i/4IUtw7Wi/ > NjykJoi8PbzgqR7mrkcKD83l18XR0JNILvj1EQwuTZYIICcd+ > yfs2WU5IjXIv5ik3hVkxQA5GkJse+EfAvBuJRPkZ8yknRM93tRw95gBc6ntB9+ > 3pqZ9QNPKRUl5i7HoBbkSlAr3iGJiBAOXAX4V3PGNG+tXHqbEVPn1DzsXojJSFUJGaXHA9VFS > pw== > freebsd.org. 3600 IN DNSKEY 256 3 8 > AwEAAc48eD98O70LmwN5RQ5i1vaP9BURkyvOiVNbztyVOCbPsZMIxDVZULFG > LeEKmUR9UbutNoizdVi+XDGXgbfvQTZczkCUJNvBCxVglssyxn > MMDjxf4p6TfuTTAW7EK6BDGVGkU3yBbfFYRYDeRep3g2CHH5/ > juU6MGMDElYYAhULICw3QRJjzMJFezvV0D1Mql53otXJ2J0BVhNBbF/ > 1HSYRhVrFCSnpo1OORbNEuCudBr5WDBsZ3TdFehf74fYQP8XZEKqwirUvGcr > lvDCPncPFtoLj3BWNvecsAwBrRbVzwTMVZHV95SXSq5VzjiXsf4U/UMQ5xOE5t4370msqPScM= > freebsd.org. 3600 IN DNSKEY 257 3 8 > AwEAAd1zS5J5X1kQqoufYTOGrPaUnlgBxllrFE1rGLJ3qDWEEETjszjal7Ie > JMmn/VhC6a2txXeob5is1/8Z6KWxpAhqIiw+l9JmD9sD/dOI9Yyk/AIyhSPguqV9+ > zBkfrp9I0BUuwxO/Rs+VgnqwQquyDGWRFQTtckPkptHKMTt44F8VyGcg+ > WVHOAXAsdGAC2SK1MVbSnMnRvZjYRHS3qc8at/h7soSib9TGNG9i+ > UD2mZyefcUUxsSll7TvUURA1dW13UP3U4/JlUM0qwA8Lk7pho/Or61Sci+yiqKijAdHu+ > dY3yGESkZ2rm4PBYYbm44ftefYXX5Hd5w20MXe5Lym8= > freebsd.org. 3600 IN DNSKEY 256 3 8 > AwEAAdCGUpcdxSMYspciWP5aJa3f0Lr5oW1BkSnSGe4TO4+HVy8f+40q7uHtpaI7MMl5+ > 2HAtjxgaZIVGBM3zqiCvW3KXjv+TRKLIBJTxStYu9ped0JWCqAXfYIhD5 > Tw2uvNKU0CLTJP9PQuEz8K5Yd7Zsy6N49/zAbovyhL5Ciax+BPcA8FTZ6io+m1Gw43+ > i2UOAs5yAeWsjaYsCwV4Ye7FdPwuQ5z/MMszr9XwBzFJdlQyJFpyAPNcdAipln > SWAg7oo8t221+sRsY/ZMOgi4WeIZAPM71Fq0LEi+GUxgjUdYs7MtehsmyRgZjum3AJyJfa > f2gZRQH5Dw0aIR/G1lUwEc= > freebsd.org. 0 IN NSEC3PARAM 1 0 100 > 10238ec3108d6756 > freebsd.org. 600 IN NS ns3.isc-sns.info. > freebsd.org. 600 IN NS ns2.isc-sns.com. > freebsd.org. 600 IN NS ns1.isc-sns.net. > freebsd.org. 600 IN TXT "v=spf1 redirect=_ > spf.freebsd.org" > freebsd.org. 600 IN MX 10 mx1.freebsd.org. > freebsd.org. 600 IN A 8.8.178.110 > freebsd.org. 600 IN AAAA 2001:1900:2254:206a::50:0 > > ;; ADDITIONAL SECTION: > ns1.isc-sns.net. 3600 IN A 72.52.71.1 > ns1.isc-sns.net. 3600 IN AAAA 2001:470:1a::1 > ns2.isc-sns.com. 3600 IN A 38.103.2.1 > ns3.isc-sns.info. 3600 IN A 63.243.194.1 > ns3.isc-sns.info. 3600 IN AAAA 2001:5a0:10::1 > mx1.freebsd.org. 600 IN A 8.8.178.115 > mx1.freebsd.org. 600 IN AAAA 2001:1900:2254:206a::19:1 > > Received 3670 bytes from 72.52.71.1#53 in 298 ms > So this server did return the requested information. You should really use dig(1) for debugging. It provides more information like whether the AA bit is set, DNSSEC data, etc. I am still unsure why you are issuing ANY queries, though. If you want details, use "host -v". Since you are querying an authoritative resolver, you are not dependent on what is in cache, but the UDP reply is over 2K that is truncated and the query is re-issued via TCP. This means that the behavior is entirely different than a query for just address information. I would do: # dig @72.52.71.1 freebsd.org. # dig @38.103.2.1 freebsd.org. # dig @8.8.178.115 freebsd.org. Once your resolvers have cached the NS records, they should directly query the servers shown and not walk the full tree. From the NXDOMAIN replies, it looks like some system is lying about things. I'm going to guess that system is incorrectly responding with NXDOMAIN when some other error is occurring. That system is probably close to you. Try: # dig freebsd.org. That will do a standard query to what ever recursive resolver you normally use. It will, hopefully, point at the culprit. It is also possible that it is a firewall issue, where some security software is sending a NXDOMAIN server to prevent further queries. This is only a guess, but there are a limited number of places where the problem might be generated and experience tells me it is almost certainly close to your system. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-net@FreeBSD.ORG Tue Dec 16 08:30:03 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5F983B44 for ; Tue, 16 Dec 2014 08:30:03 +0000 (UTC) Received: from umail.aei.mpg.de (umail.aei.mpg.de [194.94.224.6]) (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 D07F8AB3 for ; Tue, 16 Dec 2014 08:30:02 +0000 (UTC) Received: from mailgate.aei.mpg.de (mailgate.aei.mpg.de [194.94.224.5]) by umail.aei.mpg.de (Postfix) with ESMTP id 617A5200129 for ; Tue, 16 Dec 2014 09:29:59 +0100 (CET) Received: from mailgate.aei.mpg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 52758405889 for ; Tue, 16 Dec 2014 09:29:59 +0100 (CET) Received: from intranet.aei.uni-hannover.de (ahin1.aei.uni-hannover.de [130.75.117.40]) by mailgate.aei.mpg.de (Postfix) with ESMTP id 1DC78406AF1 for ; Tue, 16 Dec 2014 09:29:59 +0100 (CET) Received: from arc.aei.uni-hannover.de ([10.117.15.110]) by intranet.aei.uni-hannover.de (Lotus Domino Release 8.5.3FP6HF1016) with ESMTP id 2014121609294857-69982 ; Tue, 16 Dec 2014 09:29:48 +0100 Date: Tue, 16 Dec 2014 09:29:48 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: freebsd-net@freebsd.org Subject: Re: compiling on nfs directories Message-Id: <20141216092948.605dc8e2e0fec3fa4a5f8ec1@aei.mpg.de> In-Reply-To: <2048229686.13136235.1418677169130.JavaMail.root@uoguelph.ca> References: <2048229686.13136235.1418677169130.JavaMail.root@uoguelph.ca> Organization: Max Planck Gesellschaft X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on intranet/aei-hannover(Release 8.5.3FP6HF1016 | October 31, 2014) at 16.12.2014 09:29:48, Serialize by Router on intranet/aei-hannover(Release 8.5.3FP6HF1016 | October 31, 2014) at 16.12.2014 09:29:58, Serialize complete at 16.12.2014 09:29:58 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-PMX-Version: 6.0.2.2308539, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.81822 X-PerlMx-Spam: Gauge=X, Probability=10%, Report=' URI_HOSTNAME_CONTAINS_EQUALS 0.4, HTML_00_01 0.05, HTML_00_10 0.05, MIME_LOWER_CASE 0.05, SUPERLONG_LINE 0.05, BODY_SIZE_4000_4999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, REFERENCES 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_FROM 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __REFERENCES 0, __SANE_MSGID 0, __STOCK_PHRASE_7 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS ' X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Dec 2014 08:30:03 -0000 On Mon, 15 Dec 2014 15:59:29 -0500 (EST) Rick Macklem wrote about Re: compiling on nfs directories: RM> Also, note that he didn't see the problem with FreeBSD8.3, which would RM> have been following the same rules on the server as 10.1. RM> RM> What I suspect might cause this is one of two things: RM> 1 - The modify time of the file is now changing at a time the Linux RM> client doesn't expect, due to changes in ZFS or maybe TOD clock RM> resolution. (At one time, the TOD clock was only at a resolution RM> of 1sec, so the client wouldn't see the modify time change often. RM> I think it is now at a much higher resolution, but would have to RM> look at the code/test to be sure.) RM> 2 - I think you mention this one later in your message, in that the RM> build might be depending on file locking. If this is the case, RM> trying NFSv4, which does better file locking, might fix the RM> problem. Meanwhile I have googled around a bit more, and one of the few reasons other people see the error messages I see appears to be a broken clock that makes "make" recompile stuff on the installation stage. As I was already wondering why compilation took longer than I had actually expected, I may be seeing something similar (still need to look into that), although my clock is fine (but time stamps on the NFS might be messed up somehow like you mention above under "1"). RM> Gerrit, I would suggest that you do "nfsstat -m" on the Linux client, RM> to see what the mount options are. The Linux client might be using RM> NFSv4 already. This is what it says about my nfs-root: --- pt-nds ~ # nfsstat -m / from 192.168.32.253:/tank/diskless/nds Flags: rw,relatime,vers=3,rsize=4096,wsize=4096,namlen=255,hard,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.32.253,mountvers=3,mountproto=tcp,local_lock=all,addr=192.168.32.253 --- This is what I set up for pxe-booting: --- label gentoo-cs2 menu label linux-3.8.13-gentoo-2 kernel bzImage-3.8.13-gentoo-2 append ip=dhcp root=/dev/nfs rw nfsroot=192.168.32.253:/tank/diskless/nds,nolock,tcp,v3 rootdelay=15 --- So I definitely run "nfsv3" and "nolock". I remember trying to use nfsv4 on the diskless machines some years ago, but back then it was not ready for prime time. RM> Also, avoid "soft, intr" especially if you are using NFSv4, since these RM> can cause slow server response to result in a failure of a read/write RM> when it shouldn't fail, due to timeout or interruption by a signal. There is "hard" in there as a default option. However, I might try turning on locking (I regarded it as superfluous up to now as I have only one client using the filesystem). RM> If you could find out more about what causes the specific build failure RM> on the Linux side, that might help. As I said above, I have some hints that indicate something might be wrong with timestamps, but I still need to dig deeper into that. RM> If you can reproduce a build failure quickly/easily, you can capture RM> packets via "tcpdump -s 0 -w host " on the RM> server and then look at it in wireshark to see what the server is RM> replying when the build failure occurs. (I don't mind looking at a RM> packet trace if it is relatively small, if you email it to me as an RM> attachment.) I can reproduce it 100%, but it only happens on the installation stage, after having compiled the whole stuff. So I don't know if I will be able to produce a dump of reasonable size that contains the issue, but I'll try. RM> ps: I am not familiar with the Linux mount options, but if it has RM> stuff like "nocto", you could try those. The manpage has the following: --- cto / nocto Selects whether to use close-to-open cache coherence semantics. If neither option is specified (or if cto is specified), the client uses close-to-open cache coher- ence semantics. If the nocto option is specified, the client uses a non-standard heuristic to determine when files on the server have changed. Using the nocto option may improve performance for read- only mounts, but should be used only if the data on the server changes only occasionally. The DATA AND METADATA COHERENCE section discusses the behavior of this option in more detail. --- So "cto" appears to be the default and is probably what is used right now. I'll put "nocto" on my list of things to try (although the description is not really that incouraging... :-). cu Gerrit From owner-freebsd-net@FreeBSD.ORG Tue Dec 16 12:47:49 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 50021643 for ; Tue, 16 Dec 2014 12:47:49 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [67.212.89.78]) (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 13EDA1C3B for ; Tue, 16 Dec 2014 12:47:48 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) by mail.bsdinfo.com.br (Postfix) with ESMTP id E4740139C8 for ; Tue, 16 Dec 2014 10:48:11 -0200 (BRST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsdinfo.com.br; h=content-type:content-type:in-reply-to:references:subject :subject:to:mime-version:user-agent:from:from:date:date :message-id; s=dkim; t=1418734089; x=1419598090; bh=FpTb/f0bYfT5 a1xJgmtKsyPH/d+M0TB/BOwpbqgrxYI=; b=OG/Gu96uX80GCCsBjubyszAywz9H +W99Hy7jD6e+6ZBUum7z+IyLeUnoj1CsbipmPWoQ8enPW0dWK8JvnOfmtyo+zOjD qpGLw94zwx/K90A7rWMqXOmBYaOBcNdnLRRl/saYQJOKV8mA1DXAwbyNZLempIrW VgtmOhvOO2OG/FE= X-Virus-Scanned: amavisd-new at mail.bsdinfo.com.br Received: from mail.bsdinfo.com.br ([127.0.0.1]) by mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qffR2CfPg4go for ; Tue, 16 Dec 2014 10:48:09 -0200 (BRST) Received: from [192.168.88.15] (unknown [186.193.48.8]) by mail.bsdinfo.com.br (Postfix) with ESMTPSA id 953BC139C4 for ; Tue, 16 Dec 2014 10:48:07 -0200 (BRST) Message-ID: <549029E8.2020508@bsdinfo.com.br> Date: Tue, 16 Dec 2014 10:47:36 -0200 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" Subject: Re: DNS resolution problem References: <548C3072.10303@bsdinfo.com.br> <548F2250.3010507@bsdinfo.com.br> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Dec 2014 12:47:49 -0000 On 16/12/2014 02:25, Kevin Oberman wrote: > On Mon, Dec 15, 2014 at 10:02 AM, Marcelo Gondim > > wrote: > > Hi Kevin, > > On 13/12/2014 23:44, Kevin Oberman wrote: > > On Sat, Dec 13, 2014 at 4:26 AM, Marcelo Gondim > > > wrote: > > Dear, > > I'm having trouble resolving domain name freebsd.org > . The portsnap server > works correctly but the pkg audit -F does not work and can > not even access > the site according to the following tests: > > # host ec2-sa-east-1.portsnap.freebsd.org > > ec2-sa-east-1.portsnap.freebsd.org > has address > 177.71.188.240 > > # host vuxml.freebsd.org > Host vuxml.freebsd.org not > found: 3(NXDOMAIN) > > # host -a freebsd.org > Trying "freebsd.org " > Trying "freebsd.org.intnet.com.br > " > Host freebsd.org not found: 3(NXDOMAIN) > Received 86 bytes from ::1#53 in 0 ms > > # host www.freebsd.org > ;; connection timed out; no servers could be reached > > Only the first address I'm having name resolution > (ec2-sa-east-1.portsnap. > freebsd.org ). > > My block IP: 186.193.48.0/20 > > One could check for any restrictions on our IP block? > > I think a bit of DNS debugging is in order. > > I could resolve all of the nodes you listed, but there are > some potential > issues I see. First, when looking up hostname with host(1), > always > terminate the name: > > host -a freebsd.org . > > Trying "freebsd.org " > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24171 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, > ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;freebsd.org . IN TYPE255 > > ;; ANSWER SECTION: > freebsd.org . 534 IN AAAA > 2001:1900:2254:206a::50:0 > freebsd.org . 534 IN MX 10 > mx1.freebsd.org . > freebsd.org . 534 IN A > 8.8.178.110 > > But "ANY" queries are fuzzy things at best as the first > resolver you hit > will just return whatever is cached and not try getting an > authoritative > response. > > www.freebsd.org and vuxml.freebsd.org > are CNAME entries pointing to the > same place, 8.8.178.110. This is in FreeBSD's own address > space from Yahoo > nd is probably in the mail FreeBSD cluster. I was a bit > surprised to find > that is is an Amazon AWS address, so the portsnap files are > actually coming > from a totally different place. > > DNS is provided by ISC-SNS. 72.52.71.1, 38.103.2.1 and > 63.243.194.1. Try > pinging these. Since BIND, the second oldest and most popular > DNS server is > written and supported by ISA, I would think that it is well > run. Try > pinging and tracing to these addresses. All of them are in > very dispersed > locations on different provider backbones. (Cogent, Hurricane > Electric, and > ISC, itself. You might try directing queries to each system to > see if one > fails when other succeed. Use "dig @servr-addr host". > > Other tests: > > # ping -c 5 NS1.ISC-SNS.NET > PING ns1.isc-sns.net (72.52.71.1): 56 > data bytes > 64 bytes from 72.52.71.1 : icmp_seq=0 ttl=56 > time=144.327 ms > 64 bytes from 72.52.71.1 : icmp_seq=1 ttl=56 > time=145.445 ms > 64 bytes from 72.52.71.1 : icmp_seq=2 ttl=56 > time=144.999 ms > 64 bytes from 72.52.71.1 : icmp_seq=3 ttl=56 > time=146.775 ms > 64 bytes from 72.52.71.1 : icmp_seq=4 ttl=56 > time=145.207 ms > > --- ns1.isc-sns.net ping statistics --- > 5 packets transmitted, 5 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 144.327/145.351/146.775/0.804 ms > > # ping -c 5 NS2.ISC-SNS.COM > PING ns2.isc-sns.com (38.103.2.1): 56 > data bytes > 64 bytes from 38.103.2.1 : icmp_seq=0 ttl=54 > time=133.839 ms > 64 bytes from 38.103.2.1 : icmp_seq=1 ttl=54 > time=133.831 ms > 64 bytes from 38.103.2.1 : icmp_seq=2 ttl=54 > time=133.972 ms > 64 bytes from 38.103.2.1 : icmp_seq=3 ttl=54 > time=133.957 ms > 64 bytes from 38.103.2.1 : icmp_seq=4 ttl=54 > time=133.851 ms > > --- ns2.isc-sns.com ping statistics --- > 5 packets transmitted, 5 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 133.831/133.890/133.972/0.061 ms > > # ping -c 5 NS3.ISC-SNS.INFO > PING ns3.isc-sns.info (63.243.194.1): 56 > data bytes > 64 bytes from 63.243.194.1 : icmp_seq=0 > ttl=59 time=185.755 ms > 64 bytes from 63.243.194.1 : icmp_seq=1 > ttl=59 time=185.790 ms > 64 bytes from 63.243.194.1 : icmp_seq=2 > ttl=59 time=185.866 ms > 64 bytes from 63.243.194.1 : icmp_seq=3 > ttl=59 time=185.931 ms > 64 bytes from 63.243.194.1 : icmp_seq=4 > ttl=59 time=185.988 ms > > --- ns3.isc-sns.info ping statistics --- > 5 packets transmitted, 5 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 185.755/185.866/185.988/0.086 ms > > # host -a freebsd.org 72.52.71.1 > Trying "freebsd.org " > ;; Truncated, retrying in TCP mode. > Using domain server: > Name: 72.52.71.1 > Address: 72.52.71.1#53 > Aliases: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15306 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 20, AUTHORITY: 0, ADDITIONAL: 7 > > ;; QUESTION SECTION: > ;freebsd.org . IN TYPE255 > > ;; ANSWER SECTION: > freebsd.org . 3600 IN SOA > ns0.freebsd.org . hostmaster.freebsd.org > . 2014121517 3600 > 900 604800 600 > freebsd.org . 3600 IN RRSIG > SOA 8 2 3600 20141229134836 20141215162412 22689 freebsd.org > . > Li3FZ22mk+j4FbIRp7rQD/QS/m3UCFvMDqdUfdLBOPEpOiCTLue+5xFhtr6mLwJ6mYzbsATM3rHN/O+B1VF3VzytnOOYh0QvoqpjxwGcUWNAkAlOCFDrqaS5wp9PfWOBJ+1q+xbkgC/iwBmasqb06G1WpcvpRq9kYoZUum8RxAGuTQIYNhoDxUjU5r6yiTvWy3sCmpu02F846BcJ6+LBKhsd8OuOJYplYhjFOfszl8uQmUtyCxCDm9udsWHbNyVMPU/DeVPKSlBS5md1l07GcG2QDepH4ChxQZnejmhaXgi/6+680v7Ufgh51xb5QiU2Xg7ATwplvor2VwJphSwMAw== > freebsd.org . 3600 IN RRSIG > DNSKEY 8 2 3600 20141228141417 20141214022412 32659 freebsd.org > . > Cf1nX8IQROLxXzL9WTDJVRdHuGN344DnIzKrshoG9sbYkP/DTDMMt9mpDCUUz0HK0FgxhHw45oepm6+KMbydzZDWhK2+G/LPgyK5nzsxnaJc9EgHpg6OKCQw7HHDirfe8lr0es0Ab4mPicqMKg31r7272SEKJ6HGoezzW5wtokTJpegAGQhW+b8ZvpBqRcj3jYIU9HvBOJtn/ZNrXMg2mUP/tbkxDcBy7ssMNmy0s0GKu6Daqq1VSK0BKvEIPc/sUC+mKkUo259FkI2Lnfml3vsw+aV0behgp/VpoxRfotcNjFNJGhYGF0B0iwTQIdBnfMWlNXsQBnoQ8b7W+OLiRw== > freebsd.org . 0 IN RRSIG > NSEC3PARAM 8 2 0 20141219185954 20141206012400 22689 freebsd.org > . > ViAARy2wfDAUXV7AEzQFbge0hCJSU1/vusbRoWkaM1EVkOQbaCiSQ1PDanZmR4yQncdo2M3d4gJtIHgvZ5xzeo0/2AhlSVw/GAtWjJkqI/8rJZ2ZPtoXy6SJBcNAcGKTx74EjFN/TIxDIEXKNss2BNz3y57olnknvqgVpNjGu8jzc59aDww4+cgh9v7zuMG1YAncCnHwTIaxtsXN/K0jjKx9CtkVwJLJCRd4bthKyrPkBNMZ3cDOX27MlQFC7461WsPkNxsxFYfUWO4g8f41UUYzPX2c59tKm+qJB7s56KLihZIuBjTZnROyTkvFFcdG3ii9dzFqbEN8PMwJIS7bzw== > freebsd.org . 600 IN RRSIG > NS 8 2 600 20141221172508 20141207182403 22689 freebsd.org > . > ny0XoD9xYbSX5nHbDnl5iCIofSBlkwB8dPjeUcmKfyylrpiPVDkXfl+xfacqJj7DRvf5gF8fLhe0lwTu3cLeVXGf9L3UfD5N5sd61SxLLXy8gDHtjCQWS5/VYE4rIn6/leoqRD5YVPGJ1OWRBHSnVIjdib/R7XLLz6v8CMT4l+P42tDf7z56hjc3BNplcD/KjFfrEmoBlRIwvs9XaR3i+Qvl/0uKnGgeaXVvRMgCthC4J4oZKsBt0hpAhwy3ocOOGhp1uLV+/sBUd4ZMi0HG0G+OZbelVt01LE/7Kp5+4TA7i5Ubla8/kEcx7iKjqimnTb+0GF7+WrZbVe3MrTi9Jg== > freebsd.org . 600 IN RRSIG > TXT 8 2 600 20141221200324 20141207122402 22689 freebsd.org > . > uf81IQ/nUDeVhLtUw/g4ILoW3Pq1rl9ub8p4MBkuGxhpmZSpm1phmJ47xuDkEg137SwqdP/mIx/EIRZ1Oah5Hx1e0278qJSX1M9DMwscCjXl3uPTqgYfL/M9k15U3OJ3i9yI4Stsp6ORG3Rj4bYYYz3mzlSNV64ZOnkW9JfPu/GjEq21EXgF9SEABJr21dwEUeCpmng15MHpmpTIJIwkgdH4DC7Dh/glQ6yMDEcf6I4x63hmj4CWpChs18W94esshEfZVTeiKV7xFPvgrnsbrO660Jvua7XR3R4mqr9sqv2mXKJICNobBNx/IyAxw9vw5dE7ohFptPEH7DUDN/h4jw== > freebsd.org . 600 IN RRSIG > MX 8 2 600 20141222062628 20141208062403 22689 freebsd.org > . > exRPLUyRmbRbxQEYu989+agnNMIjXl7PsfPGW8xaoq2Dv0/GbOGnAPlSALg3MBPz8R+pL3MWiaexyi/1qxUF6n0tItn7hQhUla4jri7rMFzMUcvePPr6t5sF/MWkIC+15O5QlIUx/Bi0zUnUFPSXCKH3MWr0oqGNzzc3jSqsUlqBhQmZq3KCrSE62Tp3VDthFhZUSY29EAmmwnAlTxQR9ZX3eVEM5oJ5UrhFkBcMhv4jVtSN+OncYx4PQWHNk4DR9vY3FCVl48XqJ9ivln9vHOOCqfzl5oaSXeE6rnbHwEKpOZX65l24nPuNtKVPajYEAroK4xMqCdkPW4Ov0tw3zA== > freebsd.org . 600 IN RRSIG > A 8 2 600 20141221151124 20141207232403 22689 freebsd.org > . > VPOX9ep1tYDF7dFaY37zXAMHwd+ySWAeSAMa45btmNzCD/F1pkUi9wH57LPE3jtqeHF4coKfZCvzBED5KWfyYMDZsWOaTNA2Hxh4h+WRr4qK1FxeilvIDLYs1/ynGCcaAfTM8T7OwAueWx/x78bshaw8mkI8Pp38SpkHa0sL5T4/L9NP8NOUOP5I6zv2xFtqkcQBSWZLFElGHn3JBo3ZyGa9lUsjnNfNWwNCLcDbXG7aQCW88v+mxbnIq2lHogqOsYXQHnatpK7qV27c2XNB9ZuGmWq6zLFUFOXH1pDLf0ftIg70Evy+88RomIFLo9e9qNYI9WJk7Z51gL7ygA/YSg== > freebsd.org . 600 IN RRSIG > AAAA 8 2 600 20141222031959 20141208092403 22689 freebsd.org > . > U88G56Mlmb6l4xv+G+IdvLAQQ8g5quIvKVjBSTcC5QdO52C/kUGcoo2rE+phXqXK7j7vgcfEuSI2qP3FDCG2K1VUn19+oCHA/LVzx4sNGsVlqXDfieE7c48vVYeukalh7cCXQ53dGo/4Tpps3i/4IUtw7Wi/NjykJoi8PbzgqR7mrkcKD83l18XR0JNILvj1EQwuTZYIICcd+yfs2WU5IjXIv5ik3hVkxQA5GkJse+EfAvBuJRPkZ8yknRM93tRw95gBc6ntB9+3pqZ9QNPKRUl5i7HoBbkSlAr3iGJiBAOXAX4V3PGNG+tXHqbEVPn1DzsXojJSFUJGaXHA9VFSpw== > freebsd.org . 3600 IN > DNSKEY 256 3 8 > AwEAAc48eD98O70LmwN5RQ5i1vaP9BURkyvOiVNbztyVOCbPsZMIxDVZULFGLeEKmUR9UbutNoizdVi+XDGXgbfvQTZczkCUJNvBCxVglssyxnMMDjxf4p6TfuTTAW7EK6BDGVGkU3yBbfFYRYDeRep3g2CHH5/juU6MGMDElYYAhULICw3QRJjzMJFezvV0D1Mql53otXJ2J0BVhNBbF/1HSYRhVrFCSnpo1OORbNEuCudBr5WDBsZ3TdFehf74fYQP8XZEKqwirUvGcrlvDCPncPFtoLj3BWNvecsAwBrRbVzwTMVZHV95SXSq5VzjiXsf4U/UMQ5xOE5t4370msqPScM= > freebsd.org . 3600 IN > DNSKEY 257 3 8 > AwEAAd1zS5J5X1kQqoufYTOGrPaUnlgBxllrFE1rGLJ3qDWEEETjszjal7IeJMmn/VhC6a2txXeob5is1/8Z6KWxpAhqIiw+l9JmD9sD/dOI9Yyk/AIyhSPguqV9+zBkfrp9I0BUuwxO/Rs+VgnqwQquyDGWRFQTtckPkptHKMTt44F8VyGcg+WVHOAXAsdGAC2SK1MVbSnMnRvZjYRHS3qc8at/h7soSib9TGNG9i+UD2mZyefcUUxsSll7TvUURA1dW13UP3U4/JlUM0qwA8Lk7pho/Or61Sci+yiqKijAdHu+dY3yGESkZ2rm4PBYYbm44ftefYXX5Hd5w20MXe5Lym8= > freebsd.org . 3600 IN > DNSKEY 256 3 8 > AwEAAdCGUpcdxSMYspciWP5aJa3f0Lr5oW1BkSnSGe4TO4+HVy8f+40q7uHtpaI7MMl5+2HAtjxgaZIVGBM3zqiCvW3KXjv+TRKLIBJTxStYu9ped0JWCqAXfYIhD5Tw2uvNKU0CLTJP9PQuEz8K5Yd7Zsy6N49/zAbovyhL5Ciax+BPcA8FTZ6io+m1Gw43+i2UOAs5yAeWsjaYsCwV4Ye7FdPwuQ5z/MMszr9XwBzFJdlQyJFpyAPNcdAiplnSWAg7oo8t221+sRsY/ZMOgi4WeIZAPM71Fq0LEi+GUxgjUdYs7MtehsmyRgZjum3AJyJfaf2gZRQH5Dw0aIR/G1lUwEc= > freebsd.org . 0 IN > NSEC3PARAM 1 0 100 10238ec3108d6756 > freebsd.org . 600 IN NS > ns3.isc-sns.info . > freebsd.org . 600 IN NS > ns2.isc-sns.com . > freebsd.org . 600 IN NS > ns1.isc-sns.net . > freebsd.org . 600 IN TXT > "v=spf1 redirect=_spf.freebsd.org " > freebsd.org . 600 IN MX > 10 mx1.freebsd.org . > freebsd.org . 600 IN A > 8.8.178.110 > freebsd.org . 600 IN AAAA > 2001:1900:2254:206a::50:0 > > ;; ADDITIONAL SECTION: > ns1.isc-sns.net . 3600 IN A > 72.52.71.1 > ns1.isc-sns.net . 3600 IN > AAAA 2001:470:1a::1 > ns2.isc-sns.com . 3600 IN A > 38.103.2.1 > ns3.isc-sns.info . 3600 IN > A 63.243.194.1 > ns3.isc-sns.info . 3600 IN > AAAA 2001:5a0:10::1 > mx1.freebsd.org . 600 IN A > 8.8.178.115 > mx1.freebsd.org . 600 IN > AAAA 2001:1900:2254:206a::19:1 > > Received 3670 bytes from 72.52.71.1#53 in 298 ms > > > So this server did return the requested information. You should really > use dig(1) for debugging. It provides more information like whether > the AA bit is set, DNSSEC data, etc. > Hi Kevin, > I am still unsure why you are issuing ANY queries, though. If you want > details, use "host -v". Since you are querying an authoritative > resolver, you are not dependent on what is in cache, but the UDP reply > is over 2K that is truncated and the query is re-issued via TCP. This > means that the behavior is entirely different than a query for just > address information. > Free access to the service ports 53/tcp and 53/udp. Another thing I noticed was that it started to happen after I updated the bind (ports). # pkg info bind99 bind99-9.9.6P1 Name : bind99 Version : 9.9.6P1 Installed on : Fri Dec 12 09:33:33 BRST 2014 Origin : dns/bind99 Architecture : freebsd:10:x86:64 Prefix : /usr/local Categories : net ipv6 dns Licenses : ISCL Maintainer : mat@FreeBSD.org WWW : https://www.isc.org/software/bind Comment : BIND DNS suite with updated DNSSEC and DNS64 Options : DLZ_BDB : off DLZ_FILESYSTEM : off DLZ_LDAP : off DLZ_MYSQL : off DLZ_POSTGRESQL : off DLZ_STUB : off DOCS : on FILTER_AAAA : off FIXED_RRSET : off GOST : off GSSAPI_BASE : off GSSAPI_HEIMDAL : off GSSAPI_MIT : off GSSAPI_NONE : on IDN : on IPV6 : on LARGE_FILE : off LINKS : on NEWSTATS : off PYTHON : off REPLACE_BASE : off RPZ_NSDNAME : off RPZ_NSIP : off RPZ_PATCH : off RRL : on SIGCHASE : off SSL : on THREADS : on > I would do: > # dig @72.52.71.1 freebsd.org . > # dig @38.103.2.1 freebsd.org . > # dig @8.8.178.115 freebsd.org . # dig @72.52.71.1 freebsd.org. ; <<>> DiG 9.9.6-P1 <<>> @72.52.71.1 freebsd.org. ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42090 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 6 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;freebsd.org. IN A ;; ANSWER SECTION: freebsd.org. 600 IN A 8.8.178.110 ;; AUTHORITY SECTION: freebsd.org. 600 IN NS ns2.isc-sns.com. freebsd.org. 600 IN NS ns3.isc-sns.info. freebsd.org. 600 IN NS ns1.isc-sns.net. ;; ADDITIONAL SECTION: ns1.isc-sns.net. 3600 IN A 72.52.71.1 ns1.isc-sns.net. 3600 IN AAAA 2001:470:1a::1 ns2.isc-sns.com. 3600 IN A 38.103.2.1 ns3.isc-sns.info. 3600 IN A 63.243.194.1 ns3.isc-sns.info. 3600 IN AAAA 2001:5a0:10::1 ;; Query time: 182 msec ;; SERVER: 72.52.71.1#53(72.52.71.1) ;; WHEN: Tue Dec 16 10:27:56 BRST 2014 ;; MSG SIZE rcvd: 248 # dig @38.103.2.1 freebsd.org. ; <<>> DiG 9.9.6-P1 <<>> @38.103.2.1 freebsd.org. ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40912 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 6 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;freebsd.org. IN A ;; ANSWER SECTION: freebsd.org. 600 IN A 8.8.178.110 ;; AUTHORITY SECTION: freebsd.org. 600 IN NS ns2.isc-sns.com. freebsd.org. 600 IN NS ns1.isc-sns.net. freebsd.org. 600 IN NS ns3.isc-sns.info. ;; ADDITIONAL SECTION: ns1.isc-sns.net. 3600 IN A 72.52.71.1 ns1.isc-sns.net. 3600 IN AAAA 2001:470:1a::1 ns2.isc-sns.com. 3600 IN A 38.103.2.1 ns3.isc-sns.info. 3600 IN A 63.243.194.1 ns3.isc-sns.info. 3600 IN AAAA 2001:5a0:10::1 ;; Query time: 136 msec ;; SERVER: 38.103.2.1#53(38.103.2.1) ;; WHEN: Tue Dec 16 10:32:03 BRST 2014 ;; MSG SIZE rcvd: 248 # dig @8.8.178.115 freebsd.org. ; <<>> DiG 9.9.6-P1 <<>> @8.8.178.115 freebsd.org. ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached > > Once your resolvers have cached the NS records, they should directly > query the servers shown and not walk the full tree. From the NXDOMAIN > replies, it looks like some system is lying about things. I'm going to > guess that system is incorrectly responding with NXDOMAIN when some > other error is occurring. That system is probably close to you. Try: > # dig freebsd.org . # dig freebsd.org. ; <<>> DiG 9.9.6-P1 <<>> freebsd.org. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61747 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;freebsd.org. IN A ;; Query time: 2995 msec ;; SERVER: ::1#53(::1) ;; WHEN: Tue Dec 16 10:30:25 BRST 2014 ;; MSG SIZE rcvd: 40 > > That will do a standard query to what ever recursive resolver you > normally use. It will, hopefully, point at the culprit. It is also > possible that it is a firewall issue, where some security software is > sending a NXDOMAIN server to prevent further queries. This is only a > guess, but there are a limited number of places where the problem > might be generated and experience tells me it is almost certainly > close to your system. I am suspicious that it's some recent filter due to last vulnerability of bind. It could not be? > -- > R. Kevin Oberman, Network Engineer, Retired > E-mail: rkoberman@gmail.com > From owner-freebsd-net@FreeBSD.ORG Tue Dec 16 13:27:59 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00E00BE5 for ; Tue, 16 Dec 2014 13:27:58 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 8F9EEA6 for ; Tue, 16 Dec 2014 13:27:58 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEFABAykFSDaFve/2dsb2JhbABag1hYBIMCwmUKhShKAoEuAQEBAQF9hAwBAQEDAQEBASArIAYFBRYYAgINGQIpAQkmBggHBAEcBIgDCA2+IJZRAQEBAQEBAQMBAQEBAQEBARqBIY1vEAIBGzQHgmiBQQWJPogCgxyDIDCEX4dngzgihAogMAeBPn4BAQE X-IronPort-AV: E=Sophos;i="5.07,587,1413259200"; d="scan'208";a="176929507" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 16 Dec 2014 08:27:56 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id BFD183CE1D; Tue, 16 Dec 2014 08:27:56 -0500 (EST) Date: Tue, 16 Dec 2014 08:27:56 -0500 (EST) From: Rick Macklem To: Gerrit =?utf-8?B?S8O8aG4=?= Message-ID: <1305365048.13521399.1418736476769.JavaMail.root@uoguelph.ca> In-Reply-To: <20141216092948.605dc8e2e0fec3fa4a5f8ec1@aei.mpg.de> Subject: Re: compiling on nfs directories MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Dec 2014 13:27:59 -0000 Gerrit Kuhn wrote: > On Mon, 15 Dec 2014 15:59:29 -0500 (EST) Rick Macklem > wrote about Re: compiling on nfs directories: > > > RM> Also, note that he didn't see the problem with FreeBSD8.3, which > would > RM> have been following the same rules on the server as 10.1. > RM> > RM> What I suspect might cause this is one of two things: > RM> 1 - The modify time of the file is now changing at a time the > Linux > RM> client doesn't expect, due to changes in ZFS or maybe TOD > clock > RM> resolution. (At one time, the TOD clock was only at a > resolution > RM> of 1sec, so the client wouldn't see the modify time change > often. > RM> I think it is now at a much higher resolution, but would have > to > RM> look at the code/test to be sure.) > RM> 2 - I think you mention this one later in your message, in that > the > RM> build might be depending on file locking. If this is the > case, > RM> trying NFSv4, which does better file locking, might fix the > RM> problem. > > Meanwhile I have googled around a bit more, and one of the few > reasons > other people see the error messages I see appears to be a broken > clock that > makes "make" recompile stuff on the installation stage. As I was > already > wondering why compilation took longer than I had actually expected, I > may > be seeing something similar (still need to look into that), although > my > clock is fine (but time stamps on the NFS might be messed up somehow > like > you mention above under "1"). > > RM> Gerrit, I would suggest that you do "nfsstat -m" on the Linux > client, > RM> to see what the mount options are. The Linux client might be > using > RM> NFSv4 already. > > This is what it says about my nfs-root: > > --- > pt-nds ~ # nfsstat -m > / from 192.168.32.253:/tank/diskless/nds > Flags: > rw,relatime,vers=3,rsize=4096,wsize=4096,namlen=255,hard,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.32.253,mountvers=3,mountproto=tcp,local_lock=all,addr=192.168.32.253 > --- This looks fine to me, although the rsize, wsize are small. (This should only affect performance, not cause any build issues.) > > This is what I set up for pxe-booting: > > --- > label gentoo-cs2 > menu label linux-3.8.13-gentoo-2 > kernel bzImage-3.8.13-gentoo-2 > append ip=dhcp root=/dev/nfs rw > nfsroot=192.168.32.253:/tank/diskless/nds,nolock,tcp,v3 > rootdelay=15 > --- > > > So I definitely run "nfsv3" and "nolock". I remember trying to use > nfsv4 on the diskless machines some years ago, but back then it was > not ready for prime time. > Yes. You can't use NFSv4 for a root fs (well, maybe Linux can now, but...). With "nolock" you shouldn't have file locking issues. > RM> Also, avoid "soft, intr" especially if you are using NFSv4, since > these > RM> can cause slow server response to result in a failure of a > read/write > RM> when it shouldn't fail, due to timeout or interruption by a > signal. > > There is "hard" in there as a default option. However, I might try > turning on locking (I regarded it as superfluous up to now as I have > only one client using the filesystem). > I think "nolock" (which does the locking locally in the client) will work better that rpc.lockd. > RM> If you could find out more about what causes the specific build > failure > RM> on the Linux side, that might help. > > As I said above, I have some hints that indicate something might be > wrong with timestamps, but I still need to dig deeper into that. > > RM> If you can reproduce a build failure quickly/easily, you can > capture > RM> packets via "tcpdump -s 0 -w host " on > the > RM> server and then look at it in wireshark to see what the server is > RM> replying when the build failure occurs. (I don't mind looking at > a > RM> packet trace if it is relatively small, if you email it to me as > an > RM> attachment.) > > I can reproduce it 100%, but it only happens on the installation > stage, after having compiled the whole stuff. So I don't know if I > will be able to produce a dump of reasonable size that contains the > issue, but I'll try. > > RM> ps: I am not familiar with the Linux mount options, but if it has > RM> stuff like "nocto", you could try those. > > The manpage has the following: > > --- > cto / nocto Selects whether to use close-to-open cache > coherence > semantics. If neither option is specified (or > if cto is > specified), the client uses close-to-open > cache coher- > ence semantics. If the nocto option is > specified, the > client uses a non-standard heuristic to > determine when > files on the server have changed. > > Using the nocto option may improve performance > for read- > only mounts, but should be used only if the > data on the > server changes only occasionally. The DATA AND > METADATA > COHERENCE section discusses the behavior of > this option > in more detail. > --- > > > So "cto" appears to be the default and is probably what is used right > now. I'll put "nocto" on my list of things to try (although the > description is not really that incouraging... :-). > Well, "nocto" is meant to improve performance and not correctness, but it might be worth a try. (For FreeBSD, it would only break the multiple clients modifying the file case. For Linux??) You could also try turning off client side attribute caching. I think the mount options for this will be something like "acregmin=0,acregmax=0". (This could cause a performance hit, but will force the client to acquire attributes, including modify time, from the server more frequently.) I'm not a ZFS guy, but I thought there was a recent ZFS patch related to updating a time attribute, but I can't remember if it was atime or mtime? (You might try a post to freebsd-current@ asking about ZFS time attributes.) Good luck with it, rick > > cu > Gerrit > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Dec 16 14:13:38 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5EE3883E for ; Tue, 16 Dec 2014 14:13:38 +0000 (UTC) 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 461B685E for ; Tue, 16 Dec 2014 14:13:38 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sBGEDcGD092402 for ; Tue, 16 Dec 2014 14:13:38 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 126895] [patch] [ral] Add antenna selection (marked as TBD) Date: Tue, 16 Dec 2014 14:13:38 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dbn@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Dec 2014 14:13:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=126895 David Naylor changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |Overcome By Events Status|In Progress |Closed CC| |dbn@FreeBSD.org --- Comment #3 from David Naylor --- No longer applicable -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Tue Dec 16 17:39:21 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 13D80F6A for ; Tue, 16 Dec 2014 17:39:21 +0000 (UTC) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CED6513C for ; Tue, 16 Dec 2014 17:39:20 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id rl12so12861935iec.5 for ; Tue, 16 Dec 2014 09:39:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=hEwBe3mwIM7FlMpJFmsof+r+1lt8wel54+e1Hq5BkOI=; b=cH3PqOc3buqNVQnk3TwUiglZg3+LUKGR9DFzuNYmimOh+02XzENLxlxxgy/xYZH3Qv Ly6kSWvm1RbTWVfK3kWzJoMoRqwwe07NA2gnuNpopGexiac2GbAHYM3jmKKGSg3pQ9ql jiibdy3TJSemMQ6EnNOE0BTfzTkDXBFBj2TiAqPlpqz8aHrGCvZuItJNe3JBlq9Z5cDR erXd9fRkok3Bl7bhcxtz1V2kUc7J7mS5ka6jpTBmTOV9f5l9elwV3OLGwfNonfJLD+sA PV2I08LuL/Xb1HUW54I9dB6IW4ZdOnQYnWORVUshp549y2vV4Qi6fmeXXXU0/7U9x190 xlNQ== X-Received: by 10.107.32.5 with SMTP id g5mr35752569iog.20.1418751560312; Tue, 16 Dec 2014 09:39:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.252.39 with HTTP; Tue, 16 Dec 2014 09:39:00 -0800 (PST) In-Reply-To: References: From: Alexander Lunev Date: Tue, 16 Dec 2014 20:39:00 +0300 Message-ID: Subject: Fwd: only lo0 interface inside jail, no default gw To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Dec 2014 17:39:21 -0000 Hello everyone. I'm trying to build jail environment on a new server with 10.1-R. I've did that before on 9.2-R, but now i'm stuck with strange network problem: no matter how i configure jail (old way through rc.conf jail_* variables or via /etc/jail.conf), i don't see default gateway in jail's routing table. At first i started with more complex config using separate fib for jail, but it's not working even without fibs (or in fib 0). So, here's what i have in the host system: # netstat -rn Routing tables Internet: Destination Gateway Flags Netif Expire default 10.1.1.1 UGS em0.4 10.1.1.0/24 link#4 U em0.4 10.1.1.205 link#4 UHS lo0 10.1.1.206 link#4 UHS lo0 127.0.0.1 link#3 UH lo0 127.0.0.2 link#3 UH lo0 # ifconfig em0: flags=8843 metric 0 mtu 1500 options=4219b ether 00:30:48:c1:e1:b4 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff000000 inet 127.0.0.2 netmask 0xff000000 nd6 options=21 em0.4: flags=8843 metric 0 mtu 1500 options=103 ether 00:30:48:c1:e1:b4 inet 10.1.1.205 netmask 0xffffff00 broadcast 10.1.1.255 inet 10.1.1.206 netmask 0xffffff00 broadcast 10.1.1.255 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active vlan: 4 parent interface: em0 I can ping internet from a host via gateway 10.1.1.1 And here's what i have in jail: ====== BOF /etc/jail.conf ========= exec.start = "/bin/sh /etc/rc"; exec.stop = "/bin/sh /etc/rc.shutdown"; mount.devfs; allow.raw_sockets; path = "/usr/jails/$name"; template { jid = 1; ip4.addr = "em0.4|10.1.1.206/24"; ip4.addr += "lo0|127.0.0.2/8"; host.hostname = template; } ====== EOF /etc/jail.conf ========= # jexec 1 netstat -rn Routing tables Internet: Destination Gateway Flags Netif Expire 10.1.1.206 link#4 UHS lo0 127.0.0.2 link#3 UH lo0 I can ping gateway from jail # jexec 1 ping 10.1.1.1 PING 10.1.1.1 (10.1.1.1): 56 data bytes 64 bytes from 10.1.1.1: icmp_seq=0 ttl=64 time=0.366 ms ^C But not the Internet or anything via routing. I have no default gateway in jail - why? What have i missed in this new jail implementation since 9.2-R? Crossposted to freebsd-jail@ -- your sweet isn't ready yet From owner-freebsd-net@FreeBSD.ORG Tue Dec 16 18:43:29 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79DF1FCC for ; Tue, 16 Dec 2014 18:43:29 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5067CAC3 for ; Tue, 16 Dec 2014 18:43:29 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E1608B94C; Tue, 16 Dec 2014 13:43:27 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: compiling on nfs directories Date: Tue, 16 Dec 2014 13:37:58 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <2048229686.13136235.1418677169130.JavaMail.root@uoguelph.ca> In-Reply-To: <2048229686.13136235.1418677169130.JavaMail.root@uoguelph.ca> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201412161337.58789.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 16 Dec 2014 13:43:28 -0500 (EST) Cc: Rick Macklem , Gerrit =?utf-8?q?K=C3=BChn?= X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Dec 2014 18:43:29 -0000 On Monday, December 15, 2014 3:59:29 pm Rick Macklem wrote: > Mehmet Erol Sanliturk wrote: > > On Mon, Dec 15, 2014 at 1:24 AM, Gerrit K=C3=BChn > > > > wrote: > > > > > > Hi all, > > > > > > I ran into some weird issue here last week: > > > I have an NFS-Server for storage and diskless booting (pxe / nfs > > > root) > > > running under FreeBSD. The clients are running Gentoo Linux. Some > > > time > > > ago, I replaced the server, going from a HDD-based storage array > > > (ZFS) > > > under FreeBSD 8.3 to an SSD-based array under FreeBSD 10-stable (as > > > of > > > February this year - I know this needs updates). > > > > > > Only now I recognized that this somehow appears to have broken some > > > of my > > > Gentoo ebuilds that do not install cleanly anymore. They complain > > > about > > > "soiled libtool library files found" and "insecure RUNPATHs" in the > > > installation stage of shared libs. > > > > > > I was not able to find any useful solution for this in the Net so > > > far. > > > However, I was able to verify that this is somehow an issue with > > > the nfs > > > server by plugging in a USB-drive into the diskless clients and > > > mounting > > > this as /var/tmp/portage (the directory structure where Gentoo's > > > ebuilds > > > are compiled). This makes the error messages go away, and > > > everything works > > > again (like it did before the server update). > > > > > > Are there any suggestions what might be causing this and how to fix > > > it? > > > > > > > > > cu > > > Gerrit > > > > > > > >=20 > >=20 > > With respect to information given in your message , may pure guess is > > the > > following : > >=20 > >=20 > > When a client generates a file in NFS server , it assumes that > > everything > > is written into the file . > > The next step ( reading the generated file ) starts , BUT the file is > > NOT > > completely written into disk yet , > > therefore it reads an incomplete file which causes errors in the > > client . > >=20 > Well, not exactly. The NFS client chooses whether or not the written > data must be committed to stable storage (disk) right away via a flag > argument on the write. It is up to the client to keep track of what has > been written and if the FILE_STABLE flag wasn't set, must do a separate > Commit RPC to force the data to stable storage on the server. > It is also up to the NFS client to keep track of the file's size while > it is being grown, since the NFS server's size may be smaller until > the data gets written to the server. > Also, note that he didn't see the problem with FreeBSD8.3, which would > have been following the same rules on the server as 10.1. >=20 > What I suspect might cause this is one of two things: > 1 - The modify time of the file is now changing at a time the Linux > client doesn't expect, due to changes in ZFS or maybe TOD clock > resolution. (At one time, the TOD clock was only at a resolution > of 1sec, so the client wouldn't see the modify time change often. > I think it is now at a much higher resolution, but would have to > look at the code/test to be sure.) No, it's still only a second resolution on FreeBSD by default. You can make this precise on the NFS server by setting the vfs.timestamp_precision sysctl to 3. We should probably be using that by default for at least server-class systems. =2D-=20 John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Dec 16 21:47:05 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E3143F5F for ; Tue, 16 Dec 2014 21:47:04 +0000 (UTC) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A6235812 for ; Tue, 16 Dec 2014 21:47:04 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id tr6so13838458ieb.17 for ; Tue, 16 Dec 2014 13:47:04 -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=lCc4IVa7XpGIm1qZWTBPTFGTFu8Td+yNq2MKQPsV+Jg=; b=kSlClOLfjgTSzCE9Y0lHmaXciIKTYoecVZoqt7vh0ikDRd7G+oRpM7oHKL383caSNA 4IXiFy2YKQtfFS5SyWP392BfFm++tiiDGSfK3u9u4SCYkaClKUcpG+7ifF+VbJ2IZzsh YZZdRcZ/RY5L2fJgO8fEwRUKBJHLw95UhNElM2aoQybaca20/A1SxPEQneONXyYInfKD uFWpn9IsDH6LtLeFIop0xLGkrDhfP4XjFyUGdqUQVn82UUpuamRRMbZojjHdkK8NVBpo jL5Ayy9uXJImwuQMxkLXrIBVeW8QyUSN9T8yZp/WIqo9+JZ806+g+LZ7RE7ieVymGX0h AnFw== MIME-Version: 1.0 X-Received: by 10.50.29.107 with SMTP id j11mr5036791igh.32.1418766423196; Tue, 16 Dec 2014 13:47:03 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.107.52.19 with HTTP; Tue, 16 Dec 2014 13:47:03 -0800 (PST) In-Reply-To: References: Date: Tue, 16 Dec 2014 13:47:03 -0800 X-Google-Sender-Auth: BRLx5OQ1HPG6c5mj_SrjqaQMT4E Message-ID: Subject: Re: only lo0 interface inside jail, no default gw From: Kevin Oberman To: Alexander Lunev Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Dec 2014 21:47:05 -0000 On Tue, Dec 16, 2014 at 9:39 AM, Alexander Lunev wrote: > Hello everyone. > > I'm trying to build jail environment on a new server with 10.1-R. I've did > that before on 9.2-R, but now i'm stuck with strange network problem: no > matter how i configure jail (old way through rc.conf jail_* variables or > via /etc/jail.conf), i don't see default gateway in jail's routing table. > At first i started with more complex config using separate fib for jail, > but it's not working even without fibs (or in fib 0). So, here's what i > have in the host system: > > # netstat -rn > Routing tables > > Internet: > Destination Gateway Flags Netif Expire > default 10.1.1.1 UGS em0.4 > 10.1.1.0/24 link#4 U em0.4 > 10.1.1.205 link#4 UHS lo0 > 10.1.1.206 link#4 UHS lo0 > 127.0.0.1 link#3 UH lo0 > 127.0.0.2 link#3 UH lo0 > > # ifconfig > em0: flags=8843 metric 0 mtu 1500 > > > options=4219b > ether 00:30:48:c1:e1:b4 > nd6 options=29 > media: Ethernet autoselect (1000baseT ) > status: active > lo0: flags=8049 metric 0 mtu 16384 > options=600003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > inet 127.0.0.1 netmask 0xff000000 > inet 127.0.0.2 netmask 0xff000000 > nd6 options=21 > em0.4: flags=8843 metric 0 mtu 1500 > options=103 > ether 00:30:48:c1:e1:b4 > inet 10.1.1.205 netmask 0xffffff00 broadcast 10.1.1.255 > inet 10.1.1.206 netmask 0xffffff00 broadcast 10.1.1.255 > nd6 options=29 > media: Ethernet autoselect (1000baseT ) > status: active > vlan: 4 parent interface: em0 > > I can ping internet from a host via gateway 10.1.1.1 > > And here's what i have in jail: > > ====== BOF /etc/jail.conf ========= > exec.start = "/bin/sh /etc/rc"; > exec.stop = "/bin/sh /etc/rc.shutdown"; > mount.devfs; > allow.raw_sockets; > path = "/usr/jails/$name"; > > template { > jid = 1; > ip4.addr = "em0.4|10.1.1.206/24"; > ip4.addr += "lo0|127.0.0.2/8"; > host.hostname = template; > } > ====== EOF /etc/jail.conf ========= > > # jexec 1 netstat -rn > Routing tables > > Internet: > Destination Gateway Flags Netif Expire > 10.1.1.206 link#4 UHS lo0 > 127.0.0.2 link#3 UH lo0 > > I can ping gateway from jail > > # jexec 1 ping 10.1.1.1 > PING 10.1.1.1 (10.1.1.1): 56 data bytes > 64 bytes from 10.1.1.1: icmp_seq=0 ttl=64 time=0.366 ms > ^C > > But not the Internet or anything via routing. > > I have no default gateway in jail - why? What have i missed in this new > jail implementation since 9.2-R? > > Crossposted to freebsd-jail@ > > You lack a default route, so nothing will be reachable other than 10.1.1.206 and 127.0.0.2. I just learned today that the handbook has a very nice tutorial on jailing BIND. It will probably save a lot of time if you check it out at https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails-ezjail.html#jails-ezjail-example-bind As the handbook makes obvious, you really will find it a lot easier if you use ezjail. It massively simplified working with jails. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-net@FreeBSD.ORG Wed Dec 17 03:45:57 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 440DDE74 for ; Wed, 17 Dec 2014 03:45:57 +0000 (UTC) Received: from acipenser.esturion.net (acipenser.esturion.net [65.101.5.252]) (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 17927FC6 for ; Wed, 17 Dec 2014 03:45:56 +0000 (UTC) Received: by acipenser.esturion.net (Postfix, from userid 112) id 3DC93260347; Tue, 16 Dec 2014 20:40:00 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on acipenser.esturion.net X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 Received: from feyerabend.n1.pinyon.org (quine.pinyon.org [65.101.5.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by acipenser.esturion.net (Postfix) with ESMTPSA id 1BE12260133 for ; Tue, 16 Dec 2014 20:39:55 -0700 (MST) Message-ID: <5490FB0A.9060702@pinyon.org> Date: Tue, 16 Dec 2014 20:39:54 -0700 From: "Russell L. Carter" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: compiling on nfs directories References: <2048229686.13136235.1418677169130.JavaMail.root@uoguelph.ca> <201412161337.58789.jhb@freebsd.org> In-Reply-To: <201412161337.58789.jhb@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Dec 2014 03:45:57 -0000 On 12/16/14 11:37, John Baldwin wrote: > On Monday, December 15, 2014 3:59:29 pm Rick Macklem wrote: [...] >> What I suspect might cause this is one of two things: >> 1 - The modify time of the file is now changing at a time the Linux >> client doesn't expect, due to changes in ZFS or maybe TOD clock >> resolution. (At one time, the TOD clock was only at a resolution >> of 1sec, so the client wouldn't see the modify time change often. >> I think it is now at a much higher resolution, but would have to >> look at the code/test to be sure.) > > No, it's still only a second resolution on FreeBSD by default. You can > make this precise on the NFS server by setting the vfs.timestamp_precision > sysctl to 3. We should probably be using that by default for at least > server-class systems. > Hmm, what's this? Let's see: rcarter@feyerabend> uname -a FreeBSD feyerabend.n1.pinyon.org 10.1-STABLE FreeBSD 10.1-STABLE #1 r275516+3a52b5f(stable-jhb-em): Sat Dec 6 10:37:16 MST 2014 toor@feyerabend.n1.pinyon.org:/usr/obj/usr/src/sys/RLCGSV amd64 rcarter@feyerabend> man -k vfs.timestamp_precision vfs.timestamp_precision: nothing appropriate rcarter@feyerabend> sysctl -d vfs.timestamp_precision vfs.timestamp_precision: File timestamp precision (0: seconds, 1: sec + ns accurate to 1/HZ, 2: sec + ns truncated to ms, 3+: sec + ns (max. precision)) rcarter@feyerabend> sysctl vfs.timestamp_precision vfs.timestamp_precision: 0 Ah, that's *VERY* interesting. I am unfortunately leaving the physical vicinity of my server farm soon, so not the right time for experiments. But I have been whining for some time now about what looks to be very similar to gerrit.kuehn's symptoms. I see them on installworlds via NFS v4.1, on -current or stable/10-trunk. About 9 out of 10 installs fail trying to rebuild parts of the tree. I finally resorted to copying /usr/obj* around and then just mounting /usr/src via NFS. ick. Oh, and also buildworld/buildkernel -j1. A pity on a cluster where 8 cores/system are the norm. But now I have something sensible to try. Looking forward to it. Happy holidays, and cheers! Russell From owner-freebsd-net@FreeBSD.ORG Wed Dec 17 06:40:02 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C2F9FF73 for ; Wed, 17 Dec 2014 06:40:02 +0000 (UTC) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 869AF91 for ; Wed, 17 Dec 2014 06:40:02 +0000 (UTC) Received: by mail-ig0-f171.google.com with SMTP id z20so8234575igj.10 for ; Tue, 16 Dec 2014 22:40:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=y0JK3STrwMZ6ziui5iYolkgVJe6eyEhM0bUwmXNfvPI=; b=otZG3/WAUPNWmBo6D3dcq85deil/VPAItyJOFtIn4Tfyw4BWe0JGpfJXJyuQVpH1RI fTTf0YeUwQWAJBPBObxAd6jImdeAS6EWSNiRPF6TRYMvYWg2xxqKaVYXyTnsJWEPuNq+ bN3CIpdkDE2WzUq5jrfz19hdz8TlRqJDEmON9Bc0HYAF1MbQFKwwHlYYiGz/MA1bNhnn SACn+GWYE6v2onA6qknpLrGr0gvodT0XNCRPp+POR/kcdtsRp8Oe5zbFrGWMw/GQoIfO G136mDwNUCuquhXpCx3Gz97keOMkd9ddJdFFOzfIRh+P1BosUWNpuK3QCoysZ7Irq2Mx 8K6w== X-Received: by 10.42.78.208 with SMTP id o16mr35093081ick.41.1418798401818; Tue, 16 Dec 2014 22:40:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.252.39 with HTTP; Tue, 16 Dec 2014 22:39:41 -0800 (PST) In-Reply-To: References: From: Alexander Lunev Date: Wed, 17 Dec 2014 10:39:41 +0400 Message-ID: Subject: Re: only lo0 interface inside jail, no default gw To: Kevin Oberman Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Dec 2014 06:40:02 -0000 On Wed, Dec 17, 2014 at 12:47 AM, Kevin Oberman wrote: > > On Tue, Dec 16, 2014 at 9:39 AM, Alexander Lunev wrote: > >> I have no default gateway in jail - why? What have i missed in this new >> jail implementation since 9.2-R? >> >> Crossposted to freebsd-jail@ >> >> > You lack a default route, so nothing will be reachable other than > 10.1.1.206 and 127.0.0.2. > Yes, I know that. The question is why? > I just learned today that the handbook has a very nice tutorial on jailing > BIND. It will probably save a lot of time if you check it out at > https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails-ezjail.html#jails-ezjail-example-bind > > As the handbook makes obvious, you really will find it a lot easier if you > use ezjail. It massively simplified working with jails. > I know about ezjail, and until now i was able to do jails without it, and from 6.4-R till 9.2-R it just works. Why it's not in 10.1-R? -- your sweet isn't ready yet From owner-freebsd-net@FreeBSD.ORG Wed Dec 17 07:07:10 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF6B970D for ; Wed, 17 Dec 2014 07:07:10 +0000 (UTC) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 933DE351 for ; Wed, 17 Dec 2014 07:07:10 +0000 (UTC) Received: by mail-ig0-f173.google.com with SMTP id r2so8278042igi.6 for ; Tue, 16 Dec 2014 23:07:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=RIQQKJLvdSQ8cX9Uw4+SaGZehSkVQXPLjDMyKMfAaSc=; b=GDMvtvecass8AMJr3ZqBkqYOmUlce+MSesu8VaM7O4YRnWaZcH5pLr0lwitdDSgF03 y0UM9GZ8XWnv0ESsf2RoKBGyKusNhiR7aQ7HDgI5a2MqDYRKfvpDgwugDZA0nUh36Z7K tRBALajcD5E+sbX1vy5sK8IqV4Jf7bNwh2Of0EZFYGw78Ek9LpoTv2GNJTkUaedw0k9M OpFcxbemhMd0dTYfbl6us/O66HMxw9DajmYzIYhP7ykY1c1tL0nQhV7zQ2k8Nl8E6Q1v LGv7FJjcjkv8K0GBrbKy4oqNKOvPqgXVGlp/+ntlZjC1+yAD2Tpiyi5RBAqWt7kx2vsB F/jQ== X-Received: by 10.50.138.76 with SMTP id qo12mr6659558igb.49.1418800029725; Tue, 16 Dec 2014 23:07:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.252.39 with HTTP; Tue, 16 Dec 2014 23:06:49 -0800 (PST) In-Reply-To: References: From: Alexander Lunev Date: Wed, 17 Dec 2014 11:06:49 +0400 Message-ID: Subject: Re: only lo0 interface inside jail, no default gw To: Kevin Oberman Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Dec 2014 07:07:10 -0000 On Wed, Dec 17, 2014 at 12:47 AM, Kevin Oberman wrote: > You lack a default route, so nothing will be reachable other than > 10.1.1.206 and 127.0.0.2. > > I just learned today that the handbook has a very nice tutorial on jailing > BIND. It will probably save a lot of time if you check it out at > https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails-ezjail.html#jails-ezjail-example-bind > > As the handbook makes obvious, you really will find it a lot easier if you > use ezjail. It massively simplified working with jails. > > Now, i've made jail with ezjail and it's all the same - i have no default route in jail: # ezjail-admin console test Last login: Wed Dec 17 07:03:05 on pts/1 FreeBSD 10.1-RELEASE (GENERIC) #0 r274401: Tue Nov 11 21:02:49 UTC 2014 root@test:~ # netstat -rn Routing tables Internet: Destination Gateway Flags Netif Expire 10.1.1.206 link#4 UHS lo0 127.0.1.1 link#5 UH lo1 10.1-R/amd64, if it matters. -- your sweet isn't ready yet From owner-freebsd-net@FreeBSD.ORG Wed Dec 17 12:25:09 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05A849C8 for ; Wed, 17 Dec 2014 12:25:09 +0000 (UTC) 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 E166B29A for ; Wed, 17 Dec 2014 12:25:08 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sBHCP8Wc076100 for ; Wed, 17 Dec 2014 12:25:08 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 196035] Subsequent connect on ready socket returns EINVAL instead of ECONNREFUSED Date: Wed, 17 Dec 2014 12:25:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: harrison.grundy@astrodoggroup.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Dec 2014 12:25:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196035 Harrison Grundy changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Wed Dec 17 15:56:56 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 663EB615 for ; Wed, 17 Dec 2014 15:56:56 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D67451087 for ; Wed, 17 Dec 2014 15:56:55 +0000 (UTC) Received: from portis.head.local ([141.3.208.9]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MLS74-1Y1ovl26CI-000bB0 for ; Wed, 17 Dec 2014 16:56:47 +0100 Message-ID: <5491A7B6.9000703@gmx.com> Date: Wed, 17 Dec 2014 16:56:38 +0100 From: Nikos Vassiliadis User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: OT: github.com version of NDISulator References: <54898CE7.80509@gmx.com> In-Reply-To: <54898CE7.80509@gmx.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:YPVt5a7bBpE7trKPoE1uDkACd1YNnklQTyP9VglWrltOIuLetQf T348O8/f/XuRJqm/aRmfSu8g9fJAADsz495SKJAtWC08zSlS0IDYjJfKaeEz9HKNnYfbONE BW9sAoRIuU5gV6s3s3LLylGWRIDOMFIH0CLccMUM1mpYJ48pX17OeHTG6rRfoASaxCINjno i9APACrx7cgYMDKrmsokg== X-UI-Out-Filterresults: notjunk:1; X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Dec 2014 15:56:56 -0000 Bump On 12/11/14 13:24, Nikos Vassiliadis wrote: > Hi, > > I have to use ndisulator for my wifi card and the one in base panics > the kernel. I read that the fork(?) at github has got some bugs > fixed and I'd like to try it out. It doesn't compile on 10-STABLE. > Would somebody on this list have any ideas about it? Thanks, Nikos From owner-freebsd-net@FreeBSD.ORG Wed Dec 17 16:04:37 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0837B840 for ; Wed, 17 Dec 2014 16:04:37 +0000 (UTC) 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 E42451195 for ; Wed, 17 Dec 2014 16:04:36 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sBHG4aNS055178 for ; Wed, 17 Dec 2014 16:04:36 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 196035] Subsequent connect on ready socket returns EINVAL instead of ECONNREFUSED Date: Wed, 17 Dec 2014 16:04: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: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mnunberg@haskalah.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Dec 2014 16:04:37 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196035 --- Comment #3 from Mark Nunberg --- I can verify the patch fixes the issue -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Wed Dec 17 17:26:55 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EECCDC4B for ; Wed, 17 Dec 2014 17:26:55 +0000 (UTC) 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 D59A31BD5 for ; Wed, 17 Dec 2014 17:26:55 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sBHHQtkB086940 for ; Wed, 17 Dec 2014 17:26:55 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 172675] [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hostcache.list) race condition causing memory corruption Date: Wed, 17 Dec 2014 17:26: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: 8.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: citrin+pr@citrin.ru X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Dec 2014 17:26:56 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=172675 Anton Yuzhaninov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |citrin+pr@citrin.ru --- Comment #4 from Anton Yuzhaninov --- This typo was commited in r238083 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Wed Dec 17 17:31:41 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A2327F40 for ; Wed, 17 Dec 2014 17:31:41 +0000 (UTC) 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 89BC01CBF for ; Wed, 17 Dec 2014 17:31:41 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sBHHVfs7000385 for ; Wed, 17 Dec 2014 17:31:41 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 172675] [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hostcache.list) race condition causing memory corruption Date: Wed, 17 Dec 2014 17:31:41 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 8.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: citrin+pr@citrin.ru X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Dec 2014 17:31:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=172675 --- Comment #5 from Anton Yuzhaninov --- Race in cache_count change is still not fixed after more than two years :( atomic_add_int / atomic_subtract_int is expensive operations. Better to use counter(9) API. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Wed Dec 17 19:04:24 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40180456 for ; Wed, 17 Dec 2014 19:04:24 +0000 (UTC) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C745AC74 for ; Wed, 17 Dec 2014 19:04:23 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id l18so21213949wgh.12 for ; Wed, 17 Dec 2014 11:04:22 -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=3VxsXBCce4QEq20EuwHnnKrz14l08y2DFt29KWNam8c=; b=GaboZgIQapqvmG61tTq5It17aFX7oyRJ4i+HIDpIYXS4wNXTD15ZCxJTYSqkYj/VS6 VA0WBcRHD40P/rGvlkr/ErvIEgVctXRdjORq/e3ZkxTzWo9wGTlpc8jmy4iDvfk4BiZA DL28f3FL0UIfQkTLb4216U94ZN7WSKGuG21OyermBKXuPE9Ly1RM+iR60Ccardi6zByD JAhm1YJuyaADjRNAZElOm4VJ8hwpYLDIuijIwmYzUiG9Ujo1bCJMiViXSEkekncKCdEh eUOgJqUU+MUFbaFuAym1AJB24eNZPdNR8Nb/mAKUjeLOm7KUF3/EX0u8qICgRuzzPj7Y WPtg== MIME-Version: 1.0 X-Received: by 10.180.80.133 with SMTP id r5mr17118351wix.20.1418843060927; Wed, 17 Dec 2014 11:04:20 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.195 with HTTP; Wed, 17 Dec 2014 11:04:20 -0800 (PST) In-Reply-To: <5491A7B6.9000703@gmx.com> References: <54898CE7.80509@gmx.com> <5491A7B6.9000703@gmx.com> Date: Wed, 17 Dec 2014 11:04:20 -0800 X-Google-Sender-Auth: WQADu_-8Sa8VFUbJtCgGcpkkJL0 Message-ID: Subject: Re: OT: github.com version of NDISulator From: Adrian Chadd To: Nikos Vassiliadis Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Dec 2014 19:04:24 -0000 hi, The ndis code is (a) not maintained, and (b) not going to be updated for the newer NDIS API that drivers are slowly being changed over to use. I'm sorry. :( -adrian On 17 December 2014 at 07:56, Nikos Vassiliadis wrote: > Bump > > > On 12/11/14 13:24, Nikos Vassiliadis wrote: >> >> Hi, >> >> I have to use ndisulator for my wifi card and the one in base panics >> the kernel. I read that the fork(?) at github has got some bugs >> fixed and I'd like to try it out. It doesn't compile on 10-STABLE. >> Would somebody on this list have any ideas about it? > > > Thanks, > Nikos > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Dec 17 20:34:56 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 269FE829 for ; Wed, 17 Dec 2014 20:34:56 +0000 (UTC) Received: from acipenser.esturion.net (acipenser.esturion.net [65.101.5.252]) (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 EC5521864 for ; Wed, 17 Dec 2014 20:34:55 +0000 (UTC) Received: by acipenser.esturion.net (Postfix, from userid 112) id 85947260133; Wed, 17 Dec 2014 13:34:54 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on acipenser.esturion.net X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 Received: from feyerabend.n1.pinyon.org (quine.pinyon.org [65.101.5.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by acipenser.esturion.net (Postfix) with ESMTPSA id 61E01260051 for ; Wed, 17 Dec 2014 13:34:51 -0700 (MST) Message-ID: <5491E8EA.30902@pinyon.org> Date: Wed, 17 Dec 2014 13:34:50 -0700 From: "Russell L. Carter" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: compiling on nfs directories References: <2048229686.13136235.1418677169130.JavaMail.root@uoguelph.ca> <201412161337.58789.jhb@freebsd.org> <5490FB0A.9060702@pinyon.org> In-Reply-To: <5490FB0A.9060702@pinyon.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Dec 2014 20:34:56 -0000 On 12/16/14 20:39, Russell L. Carter wrote: > > > On 12/16/14 11:37, John Baldwin wrote: >> On Monday, December 15, 2014 3:59:29 pm Rick Macklem wrote: > > [...] > >>> What I suspect might cause this is one of two things: >>> 1 - The modify time of the file is now changing at a time the Linux >>> client doesn't expect, due to changes in ZFS or maybe TOD clock >>> resolution. (At one time, the TOD clock was only at a resolution >>> of 1sec, so the client wouldn't see the modify time change often. >>> I think it is now at a much higher resolution, but would have to >>> look at the code/test to be sure.) >> >> No, it's still only a second resolution on FreeBSD by default. You can >> make this precise on the NFS server by setting the >> vfs.timestamp_precision >> sysctl to 3. We should probably be using that by default for at least >> server-class systems. >> > > Hmm, what's this? Let's see: > > rcarter@feyerabend> uname -a > FreeBSD feyerabend.n1.pinyon.org 10.1-STABLE FreeBSD 10.1-STABLE #1 > r275516+3a52b5f(stable-jhb-em): Sat Dec 6 10:37:16 MST 2014 > toor@feyerabend.n1.pinyon.org:/usr/obj/usr/src/sys/RLCGSV amd64 > rcarter@feyerabend> man -k vfs.timestamp_precision > vfs.timestamp_precision: nothing appropriate > rcarter@feyerabend> sysctl -d vfs.timestamp_precision > vfs.timestamp_precision: File timestamp precision (0: seconds, 1: sec + > ns accurate to 1/HZ, 2: sec + ns truncated to ms, 3+: sec + ns (max. > precision)) > rcarter@feyerabend> sysctl vfs.timestamp_precision > vfs.timestamp_precision: 0 > > Ah, that's *VERY* interesting. I am unfortunately leaving the > physical vicinity of my server farm soon, so not the right time for > experiments. But I have been whining for some time now about what > looks to be very similar to gerrit.kuehn's symptoms. I see them on > installworlds via NFS v4.1, on -current or stable/10-trunk. About 9 > out of 10 installs fail trying to rebuild parts of the tree. I > finally resorted to copying /usr/obj* around and then just mounting > /usr/src via NFS. ick. Oh, and also buildworld/buildkernel -j1. A > pity on a cluster where 8 cores/system are the norm. But now I have > something sensible to try. Looking forward to it. After figuring out a way to test this reversibly, I tried the following: server & client vfs.timestamp_precision=3, make -j12 buildworld/kernel, and make installworld -j1 on the client => fail, in /usr/src/sys/boot server & client vfs.timestamp_precision=0, make -j1 build/install, succeeds. Worth a shot anyway... Cheers, Russell > Happy holidays, and cheers! > Russell > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Dec 17 22:04:52 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 78E578B2; Wed, 17 Dec 2014 22:04:52 +0000 (UTC) Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 35484676; Wed, 17 Dec 2014 22:04:52 +0000 (UTC) Received: by mail-yh0-f42.google.com with SMTP id v1so7586554yhn.1 for ; Wed, 17 Dec 2014 14:04:51 -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=VgiRf9OeMZCyteisdl4Ntvfq14TmzA5ZFGfINLsXpcs=; b=DMMFwBwlmVydJMxPF2InNc6s4vDPDv6eOqxjerM4hBWnk4Aa+2bXsDu3ykHG/3WSi5 0dRkwU3aZDuUb7xzQ9LyLR/YiI95RDnv9hgKi5Zc67yzx4M5eHq02oLJNLbcswaGSm1u to8JINHeXJnB08f8jDd3gPnjQ9e611lyOl06146gLbf4tPAy9FQA1ObO2KXlA0REp5Bm S0lrE6p5V+izpUSR7VV8uIALMzvUy98MsEH6+p/N+SKBlCrK3K42kjW3Y5PgTUgQmZed L7n7A77FGKvPkcRzmXJZExuXuOjLckTrtiossvUaEh/FbNcXl5FT6pDWnrBhqjfsDzQm cF4A== MIME-Version: 1.0 X-Received: by 10.170.159.70 with SMTP id a67mr36618279ykd.119.1418853891254; Wed, 17 Dec 2014 14:04:51 -0800 (PST) Sender: kmacybsd@gmail.com Received: by 10.170.88.65 with HTTP; Wed, 17 Dec 2014 14:04:51 -0800 (PST) In-Reply-To: References: <54898CE7.80509@gmx.com> <5491A7B6.9000703@gmx.com> Date: Wed, 17 Dec 2014 14:04:51 -0800 X-Google-Sender-Auth: Yace2k6KHG9E2i92gvN5lfM5spY Message-ID: Subject: Re: OT: github.com version of NDISulator From: "K. Macy" To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Net , Nikos Vassiliadis X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Dec 2014 22:04:52 -0000 On Wed, Dec 17, 2014 at 11:04 AM, Adrian Chadd wrote: > hi, > > The ndis code is (a) not maintained, and (b) not going to be updated > for the newer NDIS API that drivers are slowly being changed over to > use. Lack of interest? Too much work? -K > I'm sorry. :( > > > > -adrian > > > On 17 December 2014 at 07:56, Nikos Vassiliadis wrote: >> Bump >> >> >> On 12/11/14 13:24, Nikos Vassiliadis wrote: >>> >>> Hi, >>> >>> I have to use ndisulator for my wifi card and the one in base panics >>> the kernel. I read that the fork(?) at github has got some bugs >>> fixed and I'd like to try it out. It doesn't compile on 10-STABLE. >>> Would somebody on this list have any ideas about it? >> >> >> Thanks, >> Nikos >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Dec 17 23:07:36 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61F22366 for ; Wed, 17 Dec 2014 23:07:36 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 0D80FDC1 for ; Wed, 17 Dec 2014 23:07:35 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFAA4KklSDaFve/2dsb2JhbABag1hYBIMCwnIKhShKAoEwAQEBAQF9hAwBAQEDAQEBASArIAsFFhgCAg0ZAikBCSYGCAcEARwEiAMIDb5YljYBAQEBAQEBAwEBAQEBAQEBGoEhjgABARs0B4ItOxGBMAWJQ4gDgx2DUJAFIoQKIDEBBoEFOX4BAQE X-IronPort-AV: E=Sophos;i="5.07,596,1413259200"; d="scan'208";a="179207407" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 17 Dec 2014 18:07:34 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 0FD21AEA5A; Wed, 17 Dec 2014 18:07:34 -0500 (EST) Date: Wed, 17 Dec 2014 18:07:34 -0500 (EST) From: Rick Macklem To: "Russell L. Carter" Message-ID: <1480362493.14973677.1418857654052.JavaMail.root@uoguelph.ca> In-Reply-To: <5491E8EA.30902@pinyon.org> Subject: Re: compiling on nfs directories MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Dec 2014 23:07:36 -0000 Russell L. Carter wrote: > > > On 12/16/14 20:39, Russell L. Carter wrote: > > > > > > On 12/16/14 11:37, John Baldwin wrote: > >> On Monday, December 15, 2014 3:59:29 pm Rick Macklem wrote: > > > > [...] > > > >>> What I suspect might cause this is one of two things: > >>> 1 - The modify time of the file is now changing at a time the > >>> Linux > >>> client doesn't expect, due to changes in ZFS or maybe TOD > >>> clock > >>> resolution. (At one time, the TOD clock was only at a > >>> resolution > >>> of 1sec, so the client wouldn't see the modify time change > >>> often. > >>> I think it is now at a much higher resolution, but would > >>> have to > >>> look at the code/test to be sure.) > >> > >> No, it's still only a second resolution on FreeBSD by default. > >> You can > >> make this precise on the NFS server by setting the > >> vfs.timestamp_precision > >> sysctl to 3. We should probably be using that by default for at > >> least > >> server-class systems. > >> > > > > Hmm, what's this? Let's see: > > > > rcarter@feyerabend> uname -a > > FreeBSD feyerabend.n1.pinyon.org 10.1-STABLE FreeBSD 10.1-STABLE #1 > > r275516+3a52b5f(stable-jhb-em): Sat Dec 6 10:37:16 MST 2014 > > toor@feyerabend.n1.pinyon.org:/usr/obj/usr/src/sys/RLCGSV amd64 > > rcarter@feyerabend> man -k vfs.timestamp_precision > > vfs.timestamp_precision: nothing appropriate > > rcarter@feyerabend> sysctl -d vfs.timestamp_precision > > vfs.timestamp_precision: File timestamp precision (0: seconds, 1: > > sec + > > ns accurate to 1/HZ, 2: sec + ns truncated to ms, 3+: sec + ns > > (max. > > precision)) > > rcarter@feyerabend> sysctl vfs.timestamp_precision > > vfs.timestamp_precision: 0 > > > > Ah, that's *VERY* interesting. I am unfortunately leaving the > > physical vicinity of my server farm soon, so not the right time for > > experiments. But I have been whining for some time now about what > > looks to be very similar to gerrit.kuehn's symptoms. I see them on > > installworlds via NFS v4.1, on -current or stable/10-trunk. About > > 9 > > out of 10 installs fail trying to rebuild parts of the tree. I > > finally resorted to copying /usr/obj* around and then just mounting > > /usr/src via NFS. ick. Oh, and also buildworld/buildkernel -j1. > > A > > pity on a cluster where 8 cores/system are the norm. But now I > > have > > something sensible to try. Looking forward to it. > > After figuring out a way to test this reversibly, I tried the > following: > > server & client vfs.timestamp_precision=3, make -j12 > buildworld/kernel, > and make installworld -j1 on the client => fail, in /usr/src/sys/boot > > server & client vfs.timestamp_precision=0, make -j1 build/install, > succeeds. > > Worth a shot anyway... > If this is using an exported ZFS volume, it would be nice if you could do the same test using an exported UFS file system, to see if this is ZFS related. rick > Cheers, > Russell > > > Happy holidays, and cheers! > > Russell > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to > > "freebsd-net-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Dec 17 23:54:59 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10ECBC43; Wed, 17 Dec 2014 23:54:59 +0000 (UTC) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 94D9A1316; Wed, 17 Dec 2014 23:54:58 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id a1so151743wgh.23; Wed, 17 Dec 2014 15:54:56 -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=VCEX5eGK0byFW5D+TO+/sNk0GJjJpJLsOg1guVljTy8=; b=xRDH6NGmzv+bVxZxS5aU/fdUowoGt9AttrluSq8AIlPdPC7LWsPJdH+zicxlCOeAFx aITB0LqDMphWR6v9akGWbfMPHQQeYQUNLCY/1aa/bSacfTGnxxP6R7rTTv8uUO5JIQUx gd4qdIZBtSzl5TwQyG3xLC3v0XGi1whoiXko5QUDL9god/zNwukrx1m1Noqjt+WnK6xW kCewdQ0TdsUTpH3w+yeYB0mEN4/gf27MUJzC0TX1iFbvCBwvzpBLBTcocnOfjzmGkPq5 WvmlBJcFq79kZA/dKfY6VTQ4NhJnFLNKHKYVaowEvfwcV644dfqomh4LB/hxWofqucA5 zq6g== MIME-Version: 1.0 X-Received: by 10.180.80.133 with SMTP id r5mr18788804wix.20.1418860496473; Wed, 17 Dec 2014 15:54:56 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.195 with HTTP; Wed, 17 Dec 2014 15:54:56 -0800 (PST) In-Reply-To: References: <54898CE7.80509@gmx.com> <5491A7B6.9000703@gmx.com> Date: Wed, 17 Dec 2014 15:54:56 -0800 X-Google-Sender-Auth: dtgetTbg4aex5_Yafb6B5vuAtYo Message-ID: Subject: Re: OT: github.com version of NDISulator From: Adrian Chadd To: "K. Macy" Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Net , Nikos Vassiliadis X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Dec 2014 23:54:59 -0000 On 17 December 2014 at 14:04, K. Macy wrote: > On Wed, Dec 17, 2014 at 11:04 AM, Adrian Chadd wrote: >> hi, >> >> The ndis code is (a) not maintained, and (b) not going to be updated >> for the newer NDIS API that drivers are slowly being changed over to >> use. > > > Lack of interest? Too much work? .. it's a bit of both. The earlier NDIS stuff had everything pretend to be an ethernet driver. So the wifi device drivers include a complete wifi stack and expose an 802.3 device. So, later versions of the NDIS interface (starting with 6, I think) expose increasingly more wifi specific bits, so the NDIS API needs to grow and the net80211 layer needs to grow these features. The API for drivers is also deserialised (ie, not pretending everything is running in a single driver thread context.) Have a read: http://msdn.microsoft.com/en-us/library/windows/hardware/ff560690%28v=vs.85%29.aspx -adrian From owner-freebsd-net@FreeBSD.ORG Thu Dec 18 00:47:21 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7DEC228E for ; Thu, 18 Dec 2014 00:47:21 +0000 (UTC) Received: from acipenser.esturion.net (acipenser.esturion.net [65.101.5.252]) (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 54391193A for ; Thu, 18 Dec 2014 00:47:20 +0000 (UTC) Received: by acipenser.esturion.net (Postfix, from userid 112) id 58E99260371; Wed, 17 Dec 2014 17:47:19 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on acipenser.esturion.net X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from feyerabend.n1.pinyon.org (quine.pinyon.org [65.101.5.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by acipenser.esturion.net (Postfix) with ESMTPSA id AF27826026D; Wed, 17 Dec 2014 17:47:14 -0700 (MST) Message-ID: <54922412.6090903@pinyon.org> Date: Wed, 17 Dec 2014 17:47:14 -0700 From: "Russell L. Carter" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Rick Macklem Subject: Re: compiling on nfs directories References: <1480362493.14973677.1418857654052.JavaMail.root@uoguelph.ca> In-Reply-To: <1480362493.14973677.1418857654052.JavaMail.root@uoguelph.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Dec 2014 00:47:21 -0000 On 12/17/14 16:07, Rick Macklem wrote: > Russell L. Carter wrote: [...] >> >> After figuring out a way to test this reversibly, I tried the >> following: >> >> server & client vfs.timestamp_precision=3, make -j12 >> buildworld/kernel, >> and make installworld -j1 on the client => fail, in /usr/src/sys/boot >> >> server & client vfs.timestamp_precision=0, make -j1 build/install, >> succeeds. >> >> Worth a shot anyway... >> > If this is using an exported ZFS volume, it would be nice if you > could do the same test using an exported UFS file system, to see if > this is ZFS related. It is indeed using exported ZFS filesystems, but unfortunately I have no USF filesystems available to test. Russell > rick > >> Cheers, >> Russell >> >>> Happy holidays, and cheers! >>> Russell >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to >>> "freebsd-net-unsubscribe@freebsd.org" >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to >> "freebsd-net-unsubscribe@freebsd.org" >> From owner-freebsd-net@FreeBSD.ORG Thu Dec 18 01:09:31 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E16E35C0 for ; Thu, 18 Dec 2014 01:09:31 +0000 (UTC) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A02C01B7C for ; Thu, 18 Dec 2014 01:09:31 +0000 (UTC) Received: by mail-pd0-f176.google.com with SMTP id r10so243135pdi.35 for ; Wed, 17 Dec 2014 17:09:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dpdtech.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=P/lP91mKwcmSTsbwN14NV82UbX9nZJUI5eGQ1T1uug4=; b=UieIA8+rsuxwPhB8lUCxjoAglTbFmBGelnjbh6zM+uIOyC0FihC8Rdr8vIHhxlhTc5 RWxjeIOdv+WLFHyFXVjbscWU/gpFsTWecavOParj1W3DntqTxkPohHGh7pCc8YycGpkE qkgRWcZ5U2jsRtf8RgLB7EsTESg2+yQ8QJ7fo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=P/lP91mKwcmSTsbwN14NV82UbX9nZJUI5eGQ1T1uug4=; b=WxXHLZsgbhyjTyOfHcYfgA6/CPU093UrZIMvY+DpjwWl0LPpFqCpOuFkeEqPoRtRHv fWipgI44bIf2Ohh7kqWmDAALqwz4lqj2vSNNG1lSUcHdz6aMG/juhV2et7nb9e+AJMj7 D3UCSdqYgkWiwwh2NpgZwAqa79WnDQe8G1+IbFb+3ojnqBgwJ1ZprkDLkdjBcRxb3aDR FIMiB+duMu57Zb5Sgz46/90Mg5jzHvnsVW7fOZ6SlHXHp05pgDrj84zp0IasB+lGMgju pENPkpRH82C00+R/AaDyWuHLjEKyYzckRgloa7GTOzO5v+l6Kl2aSAJc7/McwzXaJ4kq EekQ== X-Gm-Message-State: ALoCoQm1Mg8z8AgpeAMve7TM+Q2+9YToFrEZZCMhXXECMatEMQ5yUXfrYvZc7LGuvaXzbQ28YOds X-Received: by 10.68.217.97 with SMTP id ox1mr68455721pbc.53.1418864970926; Wed, 17 Dec 2014 17:09:30 -0800 (PST) Received: from 173-13-188-41-sfba.hfc.comcastbusiness.net (173-13-188-41-sfba.hfc.comcastbusiness.net. [173.13.188.41]) by mx.google.com with ESMTPSA id tm3sm5107019pac.12.2014.12.17.17.09.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Dec 2014 17:09:30 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: FreeBSD 10-stable (r274577) LACP / IEEE 802.3ad with TP-Link TL-SG2008 - not working From: "David P. Discher" In-Reply-To: Date: Wed, 17 Dec 2014 17:09:36 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2BCFC9D3-3B7D-421F-9FDA-0C4E1018F8F5@dpdtech.com> References: <1A44709E-7D0C-4932-8A28-383EAC3F340B@dpdtech.com> <9AE69175-92D9-49FA-A651-119C7046A1FA@dpdtech.com> <5480D8EF.9000804@egr.msu.edu> <3D993418-E632-44BA-8FE2-2F3F34188F20@dpdtech.com> <34276C9E-CAEF-4E3F-AA2A-568F2D3099EC@dpdtech.com> To: Alan Somers X-Mailer: Apple Mail (2.1878.6) Cc: FreeBSD Net , Adam McDougall X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Dec 2014 01:09:32 -0000 On Dec 15, 2014, at 11:33 AM, Alan Somers wrote: > On Sun, Dec 14, 2014 at 6:23 PM, David P. Discher = wrote: >>=20 >> So, I think I=92ve identified the issue. In = sys/net/ieee8023ad_lacp.c, lacp_pdu_input() has a sanity check : >>=20 >> if (m->m_pkthdr.len !=3D sizeof(*du)) { >> goto bad; >> } >>=20 >> I added some debugging information in if_lagg, and ran with it. The = lacpdu packet that being sent by the TP-Link switch is 4 bytes longer = than the FreeBSD "struct lacpdu du=94. >>=20 >> em1: lacp_pdu_input-sizeof(du) bad m_pkthdr.len=3D128 = sizeof(du)=3D124 >>=20 >> My packet captures shows the packet size differing as well. >>=20 >> I=92m still poking around. I=92ve been trying to look for the = official LACPDU binary/wire format =85 if someone can point me to the = reference for that, that would be helpful (at least my own = understanding). >=20 > Try here: > http://standards.ieee.org/findstds/standard/802.1AX-2008.html >=20 Thanks - I hadn=92t seen the =93free=94 version from IEEE, and may = looking into that later. However, I think my time with messing around = with this switch and lagg is just about over.=20 I did get FreeBSD to work with LACP in this Switch. I hacked in the 4 = extra bytes in struct lacpdu in src/sys/net/ieee8023ad_lacp.h Index: ieee8023ad_lacp.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- ieee8023ad_lacp.h (revision 275779) +++ ieee8023ad_lacp.h (working copy) @@ -151,6 +151,7 @@ struct lacp_collectorinfo ldu_collector; struct tlvhdr ldu_tlv_term; uint8_t ldu_resv[50]; + uint8_t tplink[4]; } __packed; /* This work great and without any issue. All the defaults with 10-stable = (r275778) and recent version of -head with this one line made it work. = Of course, this will likely break FreeBSD with all other switches LACP. However, what I have also discovered this this switch is unlike FreeBSD = which lagghash includes L4, the switch only seems to hash over SRC+DST = IP or SRC+DST MAC. Which makes it pretty much just sends all the = traffic down one link from the switch. So for my particular use case = with a small set of hosts, this switch is not useful for me. I would not recommend the TP-Link TL-SG2008 8-Port Gigabit Smart Switch = for use with FreeBSD =85 or for any use with LACP that is expecting = increased throughput for a small set of hosts.=20 - David P. Discher http://davidpdischer.com/ AIM: DavidDPD | Y!M: daviddpdz=20 From owner-freebsd-net@FreeBSD.ORG Thu Dec 18 01:19:24 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D17E19A4 for ; Thu, 18 Dec 2014 01:19:24 +0000 (UTC) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D6551CC5 for ; Thu, 18 Dec 2014 01:19:24 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id n12so274279wgh.22 for ; Wed, 17 Dec 2014 17:19:22 -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:content-transfer-encoding; bh=f6ZBX/wf58dsy4Bg13mtiOl7ZG7FG+5RQP/6gzNHaWU=; b=MLrPaYvDALhUkXvfeZalFToUYe3rEo7pJouRr636fUfS6pNrdv6rChngGHcDkBJAjo YFYB8EzhaLX5pzLWWEX3FJYxsKfdkrmdnt8DjprT/Hv2QnClmY+UO29bhqvWOJ+nbsP2 986m0MoX+iY8MKf1ld9Q/33TXSffBjS29FnVHcB9e0w9wv7z/uhrofyKJxsbtJvE95yo 1D58GqNLMnLaYVCY6jgVRVoUiorB2zA+JnkkK+yYhpY7awYjefQzc4AjVX4eVJriCBjc I9VYNcTo80/Qx3icGfYLtOl0OuyYfpI1StiJWr8M7N21zQLuLqpwpx/8YHQgfEFO1ue/ P7TA== MIME-Version: 1.0 X-Received: by 10.180.78.3 with SMTP id x3mr170677wiw.82.1418865562847; Wed, 17 Dec 2014 17:19:22 -0800 (PST) Sender: asomers@gmail.com Received: by 10.194.17.129 with HTTP; Wed, 17 Dec 2014 17:19:22 -0800 (PST) In-Reply-To: <2BCFC9D3-3B7D-421F-9FDA-0C4E1018F8F5@dpdtech.com> References: <1A44709E-7D0C-4932-8A28-383EAC3F340B@dpdtech.com> <9AE69175-92D9-49FA-A651-119C7046A1FA@dpdtech.com> <5480D8EF.9000804@egr.msu.edu> <3D993418-E632-44BA-8FE2-2F3F34188F20@dpdtech.com> <34276C9E-CAEF-4E3F-AA2A-568F2D3099EC@dpdtech.com> <2BCFC9D3-3B7D-421F-9FDA-0C4E1018F8F5@dpdtech.com> Date: Wed, 17 Dec 2014 18:19:22 -0700 X-Google-Sender-Auth: Cu9LLDDvN5AJ82gihcNT05-kzFE Message-ID: Subject: Re: FreeBSD 10-stable (r274577) LACP / IEEE 802.3ad with TP-Link TL-SG2008 - not working From: Alan Somers To: "David P. Discher" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Net , Adam McDougall X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Dec 2014 01:19:24 -0000 On Wed, Dec 17, 2014 at 6:09 PM, David P. Discher wrote: > > On Dec 15, 2014, at 11:33 AM, Alan Somers wrote: > >> On Sun, Dec 14, 2014 at 6:23 PM, David P. Discher wrot= e: >>> >>> So, I think I=E2=80=99ve identified the issue. In sys/net/ieee8023ad_l= acp.c, lacp_pdu_input() has a sanity check : >>> >>> if (m->m_pkthdr.len !=3D sizeof(*du)) { >>> goto bad; >>> } >>> >>> I added some debugging information in if_lagg, and ran with it. The la= cpdu packet that being sent by the TP-Link switch is 4 bytes longer than th= e FreeBSD "struct lacpdu du=E2=80=9D. >>> >>> em1: lacp_pdu_input-sizeof(du) bad m_pkthdr.len=3D128 sizeof(du)= =3D124 >>> >>> My packet captures shows the packet size differing as well. >>> >>> I=E2=80=99m still poking around. I=E2=80=99ve been trying to look for t= he official LACPDU binary/wire format =E2=80=A6 if someone can point me to = the reference for that, that would be helpful (at least my own understandin= g). >> >> Try here: >> http://standards.ieee.org/findstds/standard/802.1AX-2008.html >> > > Thanks - I hadn=E2=80=99t seen the =E2=80=9Cfree=E2=80=9D version from IE= EE, and may looking into that later. However, I think my time with messing= around with this switch and lagg is just about over. > > I did get FreeBSD to work with LACP in this Switch. I hacked in the 4 ex= tra bytes in struct lacpdu in src/sys/net/ieee8023ad_lacp.h > > Index: ieee8023ad_lacp.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- ieee8023ad_lacp.h (revision 275779) > +++ ieee8023ad_lacp.h (working copy) > @@ -151,6 +151,7 @@ > struct lacp_collectorinfo ldu_collector; > struct tlvhdr ldu_tlv_term; > uint8_t ldu_resv[50]; > + uint8_t tplink[4]; > } __packed; > > /* > > > This work great and without any issue. All the defaults with 10-stable (= r275778) and recent version of -head with this one line made it work. Of c= ourse, this will likely break FreeBSD with all other switches LACP. I'm glad that you got your problem sorted out. Please do let us know if you find a more general solution. > > However, what I have also discovered this this switch is unlike FreeBSD w= hich lagghash includes L4, the switch only seems to hash over SRC+DST IP or= SRC+DST MAC. Which makes it pretty much just sends all the traffic down o= ne link from the switch. So for my particular use case with a small set of = hosts, this switch is not useful for me. Actually, that's a fairly common problem. I've even seen it on some expensive Cisco switches. > > I would not recommend the TP-Link TL-SG2008 8-Port Gigabit Smart Switch f= or use with FreeBSD =E2=80=A6 or for any use with LACP that is expecting in= creased throughput for a small set of hosts. > > > - > David P. Discher > http://davidpdischer.com/ > AIM: DavidDPD | Y!M: daviddpdz From owner-freebsd-net@FreeBSD.ORG Thu Dec 18 01:30:59 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ECF4BD93 for ; Thu, 18 Dec 2014 01:30:59 +0000 (UTC) Received: from mail.egr.msu.edu (gribble.egr.msu.edu [35.9.37.169]) by mx1.freebsd.org (Postfix) with ESMTP id C605C1E9C for ; Thu, 18 Dec 2014 01:30:59 +0000 (UTC) Received: from gribble (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id 1F09A1891D for ; Wed, 17 Dec 2014 20:30:51 -0500 (EST) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by gribble (gribble.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A26Sb89gC2y3 for ; Wed, 17 Dec 2014 20:30:50 -0500 (EST) Received: from EGR authenticated sender Message-ID: <54922E49.4050906@egr.msu.edu> Date: Wed, 17 Dec 2014 20:30:49 -0500 From: Adam McDougall User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: compiling on nfs directories References: <1480362493.14973677.1418857654052.JavaMail.root@uoguelph.ca> <54922412.6090903@pinyon.org> In-Reply-To: <54922412.6090903@pinyon.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Dec 2014 01:31:00 -0000 On 12/17/2014 19:47, Russell L. Carter wrote: > > > On 12/17/14 16:07, Rick Macklem wrote: >> If this is using an exported ZFS volume, it would be nice if you >> could do the same test using an exported UFS file system, to see if >> this is ZFS related. > > It is indeed using exported ZFS filesystems, but unfortunately I have > no USF filesystems available to test. > > Russell Can you create a zvol, newfs it with ufs and export it? From owner-freebsd-net@FreeBSD.ORG Thu Dec 18 01:36:32 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6A529E70 for ; Thu, 18 Dec 2014 01:36:32 +0000 (UTC) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 27DC01ED7 for ; Thu, 18 Dec 2014 01:36:32 +0000 (UTC) Received: by mail-pa0-f45.google.com with SMTP id lf10so308023pab.4 for ; Wed, 17 Dec 2014 17:36:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dpdtech.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/qgKtAeTGGF40efgMz4h2ZFi/pdsD4dV0jJD5L4j9S4=; b=OX1kWhoybI/VYhlHvR2MM98tXjMi4/PxstR7bcUMByG9l1UbZEaA/u0FV4QMrs+GAq vmoxbLryvM1YUV3BntgQkpg6i3Gl0mzHGS+7yTaumJGpz5vUZyJYjzl4dPeap35lep9X Xao30topUXHEGt7TSJzhj9NRwU1N8409hTb9c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=/qgKtAeTGGF40efgMz4h2ZFi/pdsD4dV0jJD5L4j9S4=; b=cvBknF61XD7CXxo0Hlv16mgI0wBdX4VF8DocUxZ9TcpwbVkGKxFdNY1YJPVcp5C94o h3Otj8NTVuD+NlxnoQGa+UjE/S6MV9bHFGM463uMBQYB3T3xOzgAPKLQApIToi31T+kY EmsjOA+cUi8TDzVnlBJRxAT07pKT+3B6Pr+Myb4+sol3V3uozawuPFjReDhpFho+1hnV a6U9tQY5VY54e/F5OhcBxpzi7rR3V69ORsMWAm235TAxhSzcR40JZoAhQozIQu88qE2R Fqx0RMhcctuQbnwrVaSE3cXajfVR+xByUJTKDPOVBlAwi7Q292EhAQ7t5S8U6IidXYpR Si5w== X-Gm-Message-State: ALoCoQmivMKjNKMbuJqziRd/U5GOxUuZMGfJTfWXIZnrAGJ4DqM5K9xyVAZmeMmHEmq47AG39Rgu X-Received: by 10.66.184.48 with SMTP id er16mr21932806pac.61.1418866591636; Wed, 17 Dec 2014 17:36:31 -0800 (PST) Received: from 173-13-188-41-sfba.hfc.comcastbusiness.net (173-13-188-41-sfba.hfc.comcastbusiness.net. [173.13.188.41]) by mx.google.com with ESMTPSA id rb2sm5149482pab.5.2014.12.17.17.36.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Dec 2014 17:36:31 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: FreeBSD 10-stable (r274577) LACP / IEEE 802.3ad with TP-Link TL-SG2008 - not working From: "David P. Discher" In-Reply-To: Date: Wed, 17 Dec 2014 17:36:38 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1A44709E-7D0C-4932-8A28-383EAC3F340B@dpdtech.com> <9AE69175-92D9-49FA-A651-119C7046A1FA@dpdtech.com> <5480D8EF.9000804@egr.msu.edu> <3D993418-E632-44BA-8FE2-2F3F34188F20@dpdtech.com> <34276C9E-CAEF-4E3F-AA2A-568F2D3099EC@dpdtech.com> <2BCFC9D3-3B7D-421F-9FDA-0C4E1018F8F5@dpdtech.com> To: Alan Somers X-Mailer: Apple Mail (2.1878.6) Cc: FreeBSD Net , Adam McDougall X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Dec 2014 01:36:32 -0000 On Dec 17, 2014, at 5:19 PM, Alan Somers wrote: >>=20 >>=20 >> This work great and without any issue. All the defaults with = 10-stable (r275778) and recent version of -head with this one line made = it work. Of course, this will likely break FreeBSD with all other = switches LACP. >=20 >=20 > I'm glad that you got your problem sorted out. Please do let us know > if you find a more general solution. >=20 Yeah, Alan - will do =85 if I decided to look into more. That is why I = was looking for spec on LACP. One side is doing it wrong. FreeBSD is = looking for a LACPDU of exactly sizeof ( struct lacpdu ) which is 124 = bytes. The TP-Link is sending a PDU of 128 bytes. I was hoping someone = would know off hand what the spec says, if the PDU =93should be=94 or = =93must be=94. I=92m assuming this is an error on TP-Link=92s = firmware, and will try to file a bug with them if I can get to the root = of the issue. I=92m assuming the Linux driver isn=92t strict on the PDU = size. If this was really an error on the FreeSBD side =85 someone should have = stumbled over long before I did. >=20 >>=20 >> However, what I have also discovered this this switch is unlike = FreeBSD which lagghash includes L4, the switch only seems to hash over = SRC+DST IP or SRC+DST MAC. Which makes it pretty much just sends all = the traffic down one link from the switch. So for my particular use case = with a small set of hosts, this switch is not useful for me. >=20 >=20 > Actually, that's a fairly common problem. I've even seen it on some > expensive Cisco switches. Yeah, in the end, this research and experiment has proven to me that = LAGG/LACP is not likely the correct solution for this project. 10g = Ethernet would work well, even back-to-back, but even used this looks to = be a bit pricey for home/hobby setup. I=92m now looking towards = Infiniband, as the cards and parts on the use market are a great value = (but this is the wrong list for talking about that.) Thanks ! - David P. Discher http://davidpdischer.com/ AIM: DavidDPD | Y!M: daviddpdz=20 From owner-freebsd-net@FreeBSD.ORG Thu Dec 18 01:54:47 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E33A41C1 for ; Thu, 18 Dec 2014 01:54:47 +0000 (UTC) Received: from acipenser.esturion.net (acipenser.esturion.net [65.101.5.252]) (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 B9CD41CD for ; Thu, 18 Dec 2014 01:54:47 +0000 (UTC) Received: by acipenser.esturion.net (Postfix, from userid 112) id 46328260339; Wed, 17 Dec 2014 18:54:46 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on acipenser.esturion.net X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 Received: from feyerabend.n1.pinyon.org (quine.pinyon.org [65.101.5.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by acipenser.esturion.net (Postfix) with ESMTPSA id 0E3A526026D for ; Wed, 17 Dec 2014 18:54:43 -0700 (MST) Message-ID: <549233E2.7050009@pinyon.org> Date: Wed, 17 Dec 2014 18:54:42 -0700 From: "Russell L. Carter" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: compiling on nfs directories References: <1480362493.14973677.1418857654052.JavaMail.root@uoguelph.ca> <54922412.6090903@pinyon.org> <54922E49.4050906@egr.msu.edu> In-Reply-To: <54922E49.4050906@egr.msu.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Dec 2014 01:54:48 -0000 On 12/17/14 18:30, Adam McDougall wrote: > On 12/17/2014 19:47, Russell L. Carter wrote: >> >> >> On 12/17/14 16:07, Rick Macklem wrote: > >>> If this is using an exported ZFS volume, it would be nice if you >>> could do the same test using an exported UFS file system, to see if >>> this is ZFS related. >> >> It is indeed using exported ZFS filesystems, but unfortunately I have >> no USF filesystems available to test. >> >> Russell > > Can you create a zvol, newfs it with ufs and export it? Maybe. I would love to help if I can, w/o disrupting my existing carefully planned physical disk layouts. I'm a zfs novice here, do I need free space unallocated to existing zpools, or can I shrink an existing pool? (assuming that zfs can transmute lead into gold, with the right incantations). I have plenty of "free" space allocated to existing pools that span my physical drives. If I have to add a physical drive (that's possible, but it will be a slow drive sitting on my shelf) then I need to wait until I get back from holiday travels. Best, Russell From owner-freebsd-net@FreeBSD.ORG Thu Dec 18 05:08:36 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C748EB3F for ; Thu, 18 Dec 2014 05:08:36 +0000 (UTC) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B8141BE8 for ; Thu, 18 Dec 2014 05:08:36 +0000 (UTC) Received: by mail-la0-f48.google.com with SMTP id gf13so364430lab.21 for ; Wed, 17 Dec 2014 21:08:34 -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=eP2/eXsbhek4RpRgHmorbbYbTuGICSgpD9dxzYHSVtE=; b=PRFUQpMgb99gctYOo21bLPj7nAURu/uA2NlTutnNl/h3lXvZ5O740P6JKhdBbB1paj aDta+JLEt+lZsOWHVvKVBWF3TbHk+wXWN3nq+MCmbagT668JuCt3WD1D5NViPaOLXvHI Bg6tjBBix0d2HVn7Az/UCa5A+D/7+XqwHls0pcQx1yvATws3eWBnQVqjDFEqEbYBiIfb pOIc6J2AK0R88ktIMmS5hAXOMK3OXHOrxYmhkFcqmo98hwSgEwDNLH7sAs7zOnXWvHLJ +HhCwpk1PBeYZQvCK0wHHhcHuNNYDelGg3aDeGU5Ahs7kirMNjJZzzikKcDiwd5Bs1xx NW5A== MIME-Version: 1.0 X-Received: by 10.152.23.38 with SMTP id j6mr145777laf.81.1418879314351; Wed, 17 Dec 2014 21:08:34 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.112.130.168 with HTTP; Wed, 17 Dec 2014 21:08:34 -0800 (PST) In-Reply-To: References: <1A44709E-7D0C-4932-8A28-383EAC3F340B@dpdtech.com> <9AE69175-92D9-49FA-A651-119C7046A1FA@dpdtech.com> <5480D8EF.9000804@egr.msu.edu> <3D993418-E632-44BA-8FE2-2F3F34188F20@dpdtech.com> <34276C9E-CAEF-4E3F-AA2A-568F2D3099EC@dpdtech.com> <2BCFC9D3-3B7D-421F-9FDA-0C4E1018F8F5@dpdtech.com> Date: Wed, 17 Dec 2014 21:08:34 -0800 X-Google-Sender-Auth: AgQzyRXgLtqZWpQloOjIunw-ScE Message-ID: Subject: Re: FreeBSD 10-stable (r274577) LACP / IEEE 802.3ad with TP-Link TL-SG2008 - not working From: Craig Rodrigues To: "David P. Discher" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , Adam McDougall X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Dec 2014 05:08:37 -0000 On Wed, Dec 17, 2014 at 5:36 PM, David P. Discher wrote: > > > Yeah, Alan - will do ... if I decided to look into more. That is why I was > looking for spec on LACP. One side is doing it wrong. FreeBSD is looking > for a LACPDU of exactly sizeof ( struct lacpdu ) which is 124 bytes. The > TP-Link is sending a PDU of 128 bytes. I was hoping someone would know off > hand what the spec says, if the PDU "should be" or "must be". > I think you have stumbled across a valid problem in the FreeBSD code. I don't have access to 802.3ad-2000, but this might give you some clues: http://kb.juniper.net/InfoCenter/index?page=content&id=KB17674 I would also look at the source code of wireshark to be sure. wireshark has a sample capture of LACP packets here: http://wiki.wireshark.org/LinkAggregationControlProtocol -- Craig From owner-freebsd-net@FreeBSD.ORG Thu Dec 18 05:12:02 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 345BEBEA for ; Thu, 18 Dec 2014 05:12:02 +0000 (UTC) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9DFDD1C9D for ; Thu, 18 Dec 2014 05:12:01 +0000 (UTC) Received: by mail-la0-f53.google.com with SMTP id gm9so365239lab.26 for ; Wed, 17 Dec 2014 21:11:59 -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=aSANNfVP00/KjZNxAyGMMECuA4p0U5jdbWthQQwDiNw=; b=vRy5WW/ujSabNb4Y0V9ixF60OcR3pw2hUVc3iYX+j791sKdminAoJqFISOE6GSajf7 K77RerVv7bQjqGmreKcXhNPBeU4QiAewJF3OuXjQIDHZYE0Wf7hoopEXRObJck6cKpv8 QrbLWBfze8bp2cVCMNmkdmdJh1yzuXVlc22gUP/jPeG7kys0fZjoyTyjisNBXNRUO3Ov c9JTuSSz8o44yPEo/ut7x0Wv8KWV3+0eoCtaob6ZrASNuKmYU9GFleObXCreIiGTYVlm 96gygti4Mr1GMcMiQs8n7s8c1drhRB69d1Ae95vDhjLBz8F90s3rK9C089RwfpC55vLA 7adw== MIME-Version: 1.0 X-Received: by 10.152.88.44 with SMTP id bd12mr215498lab.88.1418879519618; Wed, 17 Dec 2014 21:11:59 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.112.130.168 with HTTP; Wed, 17 Dec 2014 21:11:59 -0800 (PST) In-Reply-To: References: <1A44709E-7D0C-4932-8A28-383EAC3F340B@dpdtech.com> <9AE69175-92D9-49FA-A651-119C7046A1FA@dpdtech.com> <5480D8EF.9000804@egr.msu.edu> <3D993418-E632-44BA-8FE2-2F3F34188F20@dpdtech.com> <34276C9E-CAEF-4E3F-AA2A-568F2D3099EC@dpdtech.com> <2BCFC9D3-3B7D-421F-9FDA-0C4E1018F8F5@dpdtech.com> Date: Wed, 17 Dec 2014 21:11:59 -0800 X-Google-Sender-Auth: TfYjahQumb5aeJtBrmKmrhMgSUU Message-ID: Subject: Re: FreeBSD 10-stable (r274577) LACP / IEEE 802.3ad with TP-Link TL-SG2008 - not working From: Craig Rodrigues To: "David P. Discher" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , Adam McDougall X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Dec 2014 05:12:02 -0000 On Wed, Dec 17, 2014 at 9:08 PM, Craig Rodrigues wrote: > > > > On Wed, Dec 17, 2014 at 5:36 PM, David P. Discher wrote: >> >> >> Yeah, Alan - will do ... if I decided to look into more. That is why I was >> looking for spec on LACP. One side is doing it wrong. FreeBSD is looking >> for a LACPDU of exactly sizeof ( struct lacpdu ) which is 124 bytes. The >> TP-Link is sending a PDU of 128 bytes. I was hoping someone would know off >> hand what the spec says, if the PDU "should be" or "must be". >> > > > I think you have stumbled across a valid problem in the FreeBSD code. I > don't have access > to 802.3ad-2000, but this might give you some clues: > http://kb.juniper.net/InfoCenter/index?page=content&id=KB17674 > > I would also look at the source code of wireshark to be sure. wireshark > has a sample capture of LACP packets here: > > http://wiki.wireshark.org/LinkAggregationControlProtocol > > And here: http://www-01.ibm.com/support/docview.wss?uid=isg1VM64842 -- Craig From owner-freebsd-net@FreeBSD.ORG Thu Dec 18 10:29:03 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6965CC21; Thu, 18 Dec 2014 10:29:03 +0000 (UTC) Received: from olymp.kibab.com (olymp6.kibab.com [IPv6:2a01:4f8:160:84c1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 27A401B08; Thu, 18 Dec 2014 10:29:02 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 olymp.kibab.com 3153475917 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bakulin.de; s=default; t=1418898541; bh=tTIS78KgNYB0Ry/huntuVgYEZZoPnx05ElBXxBi4J/A=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=SP6PGB7w/GMHU4j/6fAkhoD8wnKsSuaIo3bfwet/Dsm1eoxmQ6m6BSdRf9mCk2R1j g2Eq92da2WElqufhFLGRXC1FBiveShSksIKRB8nhll1PtzjRkMf5fwdm9gkSaLKVDr BQUhBo8+QgqtYzkZcJzmZbWyDIy3YH3UHjtzrnVU= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 18 Dec 2014 11:29:01 +0100 From: Ilya Bakulin To: Kristof Provost Subject: PF IPv6 fragments handling (was: Re: Checksumming outgoing packets in PF vs in =?UTF-8?Q?ip=5B=36=5D=5Foutput=29?= Organization: Deglitch Networks In-Reply-To: <20141109201557.GH2044@vega.codepro.be> References: <1415210423.3394438.187470637.21CD8D3D@webmail.messagingengine.com> <9355b23f1a07008eca61f16ebd828d0b@mail.bakulin.de> <20141107133101.GF2044@vega.codepro.be> <545F6C8F.6010700@bakulin.de> <20141109201557.GH2044@vega.codepro.be> Message-ID: <694672ef2ebe8adb6badcd4b059942c1@mail.bakulin.de> X-Sender: ilya@bakulin.de Cc: freebsd-net@freebsd.org, Jim Thompson , clusteradm@freebsd.org, Mark Felder , freebsd-pf@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Dec 2014 10:29:03 -0000 On 2014-11-09 21:15, Kristof Provost wrote: > On 2014-11-09 14:30:55 (+0100), Ilya Bakulin wrote: >> On 07.11.14, 14:31, Kristof Provost wrote: > You can find the patch series here: > http://www.sigsegv.be/files/pf_inet6_frag.tar > and everything in one big patch here: > http://www.sigsegv.be/files/pf_inet6_frag.patch > > It's not cleaned up yet, or even extensively tested. > Basically the only testing that's been done is setting up a pf config > to > drop all traffic except icmp echo requests, and then sending out > fragmented icmp echo requests. Without the patch those get dropped, > with > the patch they make it through the firewall. > I've done some quick flood ping testing, so I'm reasonably confident it > doesn't leak mbufs. > > I started from the OpenBSD work, and imported and adjusted their inet6 > defragmentation patches. > > Regards, > Kristof Hi Kristof, I have tested your patchset and it works! Apart from testing with fragmented ICMPv6 requests, I've performed an UDP test using Scapy: >>> pkt=IPv6(dst="fdf9:37e3:7c53::100:2")/IPv6ExtHdrFragment()/UDP(dport=8000)/("a" >>> * 10000) >>> pktlist = fragment6(pkt, 1000) >>> send(pktlist) fdf9:37e3:7c53::100:2 in this case is the address of my FreeBSD 11-CURRENT VM running with your patch. sending pktlist on wire results in 11 packets being sent, they all get reassembled by PF and I can receive the data if I start nc on UDP port 8000. What I want to do is to do the test with overlapping fragments (that should be dropped because overlapping IPv6 fragments are forbidden) and maybe some other non-typical packets. At this poing I would like to ask clusteradm@ (CC'ed) to at least look at this patchet. The distinction between CROP and DROP that was dropped upstream is IMHO not important :-) I highly doubt that it makes any difference to anyone, and parcticularly at FreeBSD cluster. On the other hand, clusteradm@ people have complained about missing IPv6 fragment support -- so here is the solution. -- Ilya From owner-freebsd-net@FreeBSD.ORG Thu Dec 18 11:08:56 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2ED178B4; Thu, 18 Dec 2014 11:08:56 +0000 (UTC) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DD29910B7; Thu, 18 Dec 2014 11:08:55 +0000 (UTC) Received: from vega.codepro.be (unknown [172.16.1.3]) by venus.codepro.be (Postfix) with ESMTP id 3B3C521DA3; Thu, 18 Dec 2014 12:08:51 +0100 (CET) Received: by vega.codepro.be (Postfix, from userid 1001) id 3126A10224; Thu, 18 Dec 2014 12:08:51 +0100 (CET) Date: Thu, 18 Dec 2014 12:08:51 +0100 From: Kristof Provost To: Ilya Bakulin Subject: Re: PF IPv6 fragments handling (was: Re: Checksumming outgoing packets in PF vs in ip[6]_output) Message-ID: <20141218110850.GR5741@vega.codepro.be> References: <1415210423.3394438.187470637.21CD8D3D@webmail.messagingengine.com> <9355b23f1a07008eca61f16ebd828d0b@mail.bakulin.de> <20141107133101.GF2044@vega.codepro.be> <545F6C8F.6010700@bakulin.de> <20141109201557.GH2044@vega.codepro.be> <694672ef2ebe8adb6badcd4b059942c1@mail.bakulin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <694672ef2ebe8adb6badcd4b059942c1@mail.bakulin.de> X-PGP-Fingerprint: E114 D9EA 909E D469 8F57 17A5 7D15 91C6 9EFA F286 X-Checked-By-NSA: Probably User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-net@freebsd.org, Jim Thompson , clusteradm@freebsd.org, Mark Felder , freebsd-pf@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Dec 2014 11:08:56 -0000 On 2014-12-18 11:29:01 (+0100), Ilya Bakulin wrote: > On 2014-11-09 21:15, Kristof Provost wrote: > > On 2014-11-09 14:30:55 (+0100), Ilya Bakulin wrote: > >> On 07.11.14, 14:31, Kristof Provost wrote: > > You can find the patch series here: > > http://www.sigsegv.be/files/pf_inet6_frag.tar > > and everything in one big patch here: > > http://www.sigsegv.be/files/pf_inet6_frag.patch > > > > I have tested your patchset and it works! > At this poing I would like to ask clusteradm@ (CC'ed) to at least look > at this patchet. The distinction between CROP and DROP that was dropped > upstream is IMHO not important :-) I highly doubt that it makes any > difference to anyone, and parcticularly at FreeBSD cluster. On the other > hand, Thanks for testing! I still have the CROP/DROP thing on my TODO. If there's a consensus that we can drop it that's fine by me of course. In that case I'll just clean up the current patches and submit those for review. If people feel we should keep CROP/DROP (as was my original plan) I should have some time to work on that over the holidays. Regards, Kristof From owner-freebsd-net@FreeBSD.ORG Thu Dec 18 13:26:41 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7B755492 for ; Thu, 18 Dec 2014 13:26:41 +0000 (UTC) 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 623FC1649 for ; Thu, 18 Dec 2014 13:26:41 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sBIDQfZa014865 for ; Thu, 18 Dec 2014 13:26:41 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 86871] [tcp] [patch] allocation logic for PCBs in TIME_WAIT state causes packet drops on stateful FWs Date: Thu, 18 Dec 2014 13:26:40 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 5.4-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: harrison.grundy@astrodoggroup.com X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Dec 2014 13:26:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=86871 Harrison Grundy changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |harrison.grundy@astrodoggro | |up.com --- Comment #3 from Harrison Grundy --- 9 years on... does this still occur? -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Dec 18 15:11:30 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 73658B79; Thu, 18 Dec 2014 15:11:30 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 08B87288C; Thu, 18 Dec 2014 15:11:30 +0000 (UTC) Received: from moby.local ([109.193.238.174]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MJjOu-1Y2ifF35Km-001DMU; Thu, 18 Dec 2014 16:11:22 +0100 Message-ID: <5492EE98.9060706@gmx.com> Date: Thu, 18 Dec 2014 16:11:20 +0100 From: Nikos Vassiliadis User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: OT: github.com version of NDISulator References: <54898CE7.80509@gmx.com> <5491A7B6.9000703@gmx.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:cpUWbVgDLVMoD92nP47DR8u9XYfg4HUuIbuiIwAq6a6yQUlfg/a RDj98Ep+K0ImG39OVoDO1eViDtLYC5T8ktxIGE+3MkMas2RXVdGB7rkaSa+RaEgAJdsrtpY Z7HfBSLvaED3PYHmkOMRk3GuKXC4E1dXMXB9ep2fE+yu01YP/9TQINKDHrW5UxJQRmIzX5A ctxX6I0rQ9u9rrgaD2dsQ== X-UI-Out-Filterresults: notjunk:1; Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Dec 2014 15:11:30 -0000 Hi, I got it working with the github version:) A person pointed out that I was using the wrong branch of github ndisulator. All I had to do was to use the correct branch. On 12/17/14 20:04, Adrian Chadd wrote: > hi, > > The ndis code is (a) not maintained, and (b) not going to be updated > for the newer NDIS API that drivers are slowly being changed over to > use. > > I'm sorry. :( > > > > -adrian > > > On 17 December 2014 at 07:56, Nikos Vassiliadis wrote: >> Bump >> >> >> On 12/11/14 13:24, Nikos Vassiliadis wrote: >>> >>> Hi, >>> >>> I have to use ndisulator for my wifi card and the one in base panics >>> the kernel. I read that the fork(?) at github has got some bugs >>> fixed and I'd like to try it out. It doesn't compile on 10-STABLE. >>> Would somebody on this list have any ideas about it? >> >> >> Thanks, >> Nikos >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu Dec 18 15:29:12 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E3C5306 for ; Thu, 18 Dec 2014 15:29:12 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 91A622A6E for ; Thu, 18 Dec 2014 15:29:11 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id r20so1960586wiv.2 for ; Thu, 18 Dec 2014 07:29:10 -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=qtrtwHMYX1fpiEVeV+9AZjXhPDu61+A09NTC1PPQtXE=; b=WWf0YcsVqg/1Kvz7Nz1tPDlSLBiS+Kom5loqPp5CwYQLSUs0eokEi/2ofap/LrHbSa o9Kn4SWJP2ZB1DSkGY4cWoEgXVlvOQTI6INfrhyCXvNqJCk5G7Wzd6xaDMAi2GAf7UCq raMaGpMMiihcSxwGTyRl9L3tcyplBjG8iHiQSaqHywHoeyAzc+TVVfOqESqufoEr5S3N crxzRWQtacIjRmrivets0vNzrDQ/7AUxnCy9fimQJzIqfVdbcaBY3oqNGE/oKOWvD7my 1DKNKncw613peiR6iUYMVlRX1ryrJkp0QR4NBD8N73VD9vEgxq8tiB+nBsq8qoj/KPgx ToMg== MIME-Version: 1.0 X-Received: by 10.194.60.45 with SMTP id e13mr5424071wjr.109.1418916543228; Thu, 18 Dec 2014 07:29:03 -0800 (PST) Sender: asomers@gmail.com Received: by 10.194.17.129 with HTTP; Thu, 18 Dec 2014 07:29:03 -0800 (PST) In-Reply-To: <549233E2.7050009@pinyon.org> References: <1480362493.14973677.1418857654052.JavaMail.root@uoguelph.ca> <54922412.6090903@pinyon.org> <54922E49.4050906@egr.msu.edu> <549233E2.7050009@pinyon.org> Date: Thu, 18 Dec 2014 08:29:03 -0700 X-Google-Sender-Auth: uXW4h3CH2JYPdwemGOxtas5Gfzo Message-ID: Subject: Re: compiling on nfs directories From: Alan Somers To: "Russell L. Carter" Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Dec 2014 15:29:12 -0000 On Wed, Dec 17, 2014 at 6:54 PM, Russell L. Carter wrote: > > > On 12/17/14 18:30, Adam McDougall wrote: >> >> On 12/17/2014 19:47, Russell L. Carter wrote: >>> >>> >>> >>> On 12/17/14 16:07, Rick Macklem wrote: >> >> >>>> If this is using an exported ZFS volume, it would be nice if you >>>> could do the same test using an exported UFS file system, to see if >>>> this is ZFS related. >>> >>> >>> It is indeed using exported ZFS filesystems, but unfortunately I have >>> no USF filesystems available to test. >>> >>> Russell >> >> >> Can you create a zvol, newfs it with ufs and export it? > > > Maybe. I would love to help if I can, w/o disrupting my existing > carefully planned physical disk layouts. I'm a zfs novice here, do I > need free space unallocated to existing zpools, or can I shrink an > existing pool? (assuming that zfs can transmute lead into gold, with > the right incantations). I have plenty of "free" space allocated to > existing pools that span my physical drives. > > If I have to add a physical drive (that's possible, but it will be a > slow drive sitting on my shelf) then I need to wait until I get back > from holiday travels. You don't need to screw with your pools at all. A zvol is like a managed like a ZFS filesystem, except it's a block device. You can create one and mount it with a command like this: zfs create -V 8g mypool/myvol newfs [options] /dev/mypool/myvol mount /dev/mypool/myvol /mnt -Alan From owner-freebsd-net@FreeBSD.ORG Thu Dec 18 15:37:31 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 70AC46D7; Thu, 18 Dec 2014 15:37:31 +0000 (UTC) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3CFAF2BC4; Thu, 18 Dec 2014 15:37:31 +0000 (UTC) Received: by mail-pa0-f51.google.com with SMTP id ey11so1605454pad.24; Thu, 18 Dec 2014 07:37:30 -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=lhwPQjw7Nyy2cUny7U0cbAzqvyoH9u8avv8JjXDjfAg=; b=YnOvb8aV4LywS5PAYyl512UzSrWMVTiuKPc2Dle4N+0zRu275jZc7P8sFMD+A2Kdz0 BS0gz+PvGdWjRRU9Ft4TYEtcd8ALHsijPL9iqctpB9RKY3lBGdhClVbCSaX4tX9nbqf8 tDua1ss2xM2YNxumb4VJQmagaGPgt1puIfDE7uWQ+G82jgQRZHEm+fD4h4F1p7hQddHM Kkc47U/hCOSDNyN927LqPwYgu11tHbhOjGf8SBw8/QZyl20anByKFSvZZ8M27FXybIS2 U9qavFNI5TlGu4zI6nvwViKHjebQvY2R4gjWpSHlLtf4sZZapJCVMzYZXYyk3jO5ioMQ EZSg== MIME-Version: 1.0 X-Received: by 10.70.118.202 with SMTP id ko10mr4632575pdb.48.1418917050703; Thu, 18 Dec 2014 07:37:30 -0800 (PST) Received: by 10.70.94.167 with HTTP; Thu, 18 Dec 2014 07:37:30 -0800 (PST) In-Reply-To: References: <1480362493.14973677.1418857654052.JavaMail.root@uoguelph.ca> <54922412.6090903@pinyon.org> <54922E49.4050906@egr.msu.edu> <549233E2.7050009@pinyon.org> Date: Thu, 18 Dec 2014 09:37:30 -0600 Message-ID: Subject: Re: compiling on nfs directories From: Adam Vande More To: Alan Somers Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "Russell L. Carter" , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Dec 2014 15:37:31 -0000 On Thu, Dec 18, 2014 at 9:29 AM, Alan Somers wrote: > > On Wed, Dec 17, 2014 at 6:54 PM, Russell L. Carter > wrote: > > On 12/17/14 18:30, Adam McDougall wrote: > >> > >> On 12/17/2014 19:47, Russell L. Carter wrote: > >>> > >>> > >>> > >>> On 12/17/14 16:07, Rick Macklem wrote: > >> > >> > >>>> If this is using an exported ZFS volume, it would be nice if you > >>>> could do the same test using an exported UFS file system, to see if > >>>> this is ZFS related. > >>> > >>> > >>> It is indeed using exported ZFS filesystems, but unfortunately I have > >>> no USF filesystems available to test. > >>> > >>> Russell > >> > >> > >> Can you create a zvol, newfs it with ufs and export it? > > > > > > Maybe. I would love to help if I can, w/o disrupting my existing > > carefully planned physical disk layouts. I'm a zfs novice here, do I > > need free space unallocated to existing zpools, or can I shrink an > > existing pool? (assuming that zfs can transmute lead into gold, with > > the right incantations). I have plenty of "free" space allocated to > > existing pools that span my physical drives. > > > > If I have to add a physical drive (that's possible, but it will be a > > slow drive sitting on my shelf) then I need to wait until I get back > > from holiday travels. > > > You don't need to screw with your pools at all. A zvol is like a > managed like a ZFS filesystem, except it's a block device. You can > create one and mount it with a command like this: > zfs create -V 8g mypool/myvol > newfs [options] /dev/mypool/myvol > mount /dev/mypool/myvol /mnt Using a flash drive or temporary drive seems like a much more comprehensive test as you can fully eliminate ZFS from the picture. Which is the point of the exercise. -- Adam From owner-freebsd-net@FreeBSD.ORG Thu Dec 18 16:15:38 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7874A26A; Thu, 18 Dec 2014 16:15:38 +0000 (UTC) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0070C1218; Thu, 18 Dec 2014 16:15:38 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id b13so2070424wgh.17; Thu, 18 Dec 2014 08:15:36 -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=hudcimyO+SjkOAFe80ACr/xPof3gHyhzLSihODzrVM0=; b=Wqm6qV8B1AASg/9a8LwSE520cEMF37AsoTT4RVqUj8tIn1qdF1H2NewaoEt1fpKDCS 0KqKXVvgUqF9fSAiK5hge5i/qIp3rGR2BtkXEXq0W95Sji7q2EZcmr4uRya4O66ruwhu f5rtx4FFbKjcA8Fd6wfKOwBh8ZDpEIEPqCNPIsMx3C/i3K01VY4iyzV+6E+DSB4bjKhs Y+JLOsjnNOWQgtq8i3GcmjFOhJYdvHblrQe5KUwXAD8O180FLGWi2QR0JiAbgYbvm31q 0gOFjfRjkc3eMDTZfJ/lebEX2i28263Tag5bAuBysifCKJLKdpSI40O+7cLaAE4OkJln v87Q== MIME-Version: 1.0 X-Received: by 10.180.90.133 with SMTP id bw5mr6760011wib.50.1418919333479; Thu, 18 Dec 2014 08:15:33 -0800 (PST) Sender: asomers@gmail.com Received: by 10.194.17.129 with HTTP; Thu, 18 Dec 2014 08:15:33 -0800 (PST) In-Reply-To: References: <1A44709E-7D0C-4932-8A28-383EAC3F340B@dpdtech.com> <9AE69175-92D9-49FA-A651-119C7046A1FA@dpdtech.com> <5480D8EF.9000804@egr.msu.edu> <3D993418-E632-44BA-8FE2-2F3F34188F20@dpdtech.com> <34276C9E-CAEF-4E3F-AA2A-568F2D3099EC@dpdtech.com> <2BCFC9D3-3B7D-421F-9FDA-0C4E1018F8F5@dpdtech.com> Date: Thu, 18 Dec 2014 09:15:33 -0700 X-Google-Sender-Auth: 59mTmWFuF3RjI8HsPEehU0u36qM Message-ID: Subject: Re: FreeBSD 10-stable (r274577) LACP / IEEE 802.3ad with TP-Link TL-SG2008 - not working From: Alan Somers To: Craig Rodrigues Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Net , Adam McDougall , "David P. Discher" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Dec 2014 16:15:38 -0000 On Wed, Dec 17, 2014 at 10:11 PM, Craig Rodrigues wrote: > On Wed, Dec 17, 2014 at 9:08 PM, Craig Rodrigues > wrote: >> >> >> >> On Wed, Dec 17, 2014 at 5:36 PM, David P. Discher wrote: >>> >>> >>> Yeah, Alan - will do ... if I decided to look into more. That is why I was >>> looking for spec on LACP. One side is doing it wrong. FreeBSD is looking >>> for a LACPDU of exactly sizeof ( struct lacpdu ) which is 124 bytes. The >>> TP-Link is sending a PDU of 128 bytes. I was hoping someone would know off >>> hand what the spec says, if the PDU "should be" or "must be". >>> >> >> >> I think you have stumbled across a valid problem in the FreeBSD code. I >> don't have access >> to 802.3ad-2000, but this might give you some clues: >> http://kb.juniper.net/InfoCenter/index?page=content&id=KB17674 >> >> I would also look at the source code of wireshark to be sure. wireshark >> has a sample capture of LACP packets here: >> >> http://wiki.wireshark.org/LinkAggregationControlProtocol >> >> > And here: > > http://www-01.ibm.com/support/docview.wss?uid=isg1VM64842 Good find, Craig. Also, I found the full LACPDU definition. It's in section 5.4.2.2, page 33, of the 802.1ax-2008 spec that I linked to. You can see the 4-byte FCS field at the end. Does your tp_link[4] field look like an FCS? If so, you need to figure out why it's propagating all the way up to the LACP level. -Alan From owner-freebsd-net@FreeBSD.ORG Thu Dec 18 16:15:53 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 897EE2FE for ; Thu, 18 Dec 2014 16:15:53 +0000 (UTC) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4507F1223 for ; Thu, 18 Dec 2014 16:15:53 +0000 (UTC) Received: by mail-pa0-f51.google.com with SMTP id ey11so1680201pad.38 for ; Thu, 18 Dec 2014 08:15:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dpdtech.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=piVU0wtfimoBsO9GOVnAmFVQTJgbf1PYjysJItECP2M=; b=WSxcDMi2LpTu9MEvETtM7gFeOB5Y/0R3xjf18z5IlKQ0hQnqob+LXOKxgg233EO5Aj 6BCZSg+0H2+WDDOEVze0kGVUYmShYvLcMKqBK7+ZH7k94QqmDP0Cm027eDBtphmIze30 cKJbaEu1y0rKFw9F8S83wQbaTOYFQ/0XxeLVc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=piVU0wtfimoBsO9GOVnAmFVQTJgbf1PYjysJItECP2M=; b=DOiE+qVf/gbGhirep+5zjVIxzi+sGVjHbQNf0bga7FgLlL16EY2fp9r5tC634kaQqG UpD/0RIgv9utwILNndutac3yuZnCBrTUYrIVgTqBChyHqi3w96pSqUXmlUpm6H4AZuwQ M8qYpQeGafnaexNCvGWWfoa2U5naShd/b6KhhgqwiZnfGQieni/m0YEIIfFpw3/Qz+Jk nsruzEei3/RC/yauuoJBIbQcvLFVvcDfvXaAVS0E+Mkgj9HZHvxihTAzbIwTG4d7ulzo EGPdWSY4T2/ci9LqAM5EtHPW3iUoVz7x1ORpLtAjU03zKsOQQJiaTSdUDjPPuq7YvE3S 9IQQ== X-Gm-Message-State: ALoCoQlz3Xzpl31aC5fT2WLvwmwmaJD4IzHaTbURAdQHhqEjbQxFmLtqKN2ft0Yuf6VfoeGJCEnZ X-Received: by 10.70.91.142 with SMTP id ce14mr4797483pdb.138.1418919352527; Thu, 18 Dec 2014 08:15:52 -0800 (PST) Received: from 173-13-188-41-sfba.hfc.comcastbusiness.net (173-13-188-41-sfba.hfc.comcastbusiness.net. [173.13.188.41]) by mx.google.com with ESMTPSA id x16sm7149534pbt.70.2014.12.18.08.15.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Dec 2014 08:15:52 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: FreeBSD 10-stable (r274577) LACP / IEEE 802.3ad with TP-Link TL-SG2008 - not working From: "David P. Discher" In-Reply-To: Date: Thu, 18 Dec 2014 08:16:04 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1A44709E-7D0C-4932-8A28-383EAC3F340B@dpdtech.com> <9AE69175-92D9-49FA-A651-119C7046A1FA@dpdtech.com> <5480D8EF.9000804@egr.msu.edu> <3D993418-E632-44BA-8FE2-2F3F34188F20@dpdtech.com> <34276C9E-CAEF-4E3F-AA2A-568F2D3099EC@dpdtech.com> <2BCFC9D3-3B7D-421F-9FDA-0C4E1018F8F5@dpdtech.com> To: Craig Rodrigues X-Mailer: Apple Mail (2.1878.6) Cc: FreeBSD Net , Adam McDougall X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Dec 2014 16:15:53 -0000 On Dec 17, 2014, at 9:11 PM, Craig Rodrigues = wrote: >=20 >=20 > And here: >=20 > http://www-01.ibm.com/support/docview.wss?uid=3Disg1VM64842 >=20 Ah, wow =85 that IBM article - what I=92m seeing is the four-byte Frame = Check Sequence (FCS). I download the IEEE Std 802.1AX-2008 PDF, Figure = 5=968=97 LACPDU structure, page 33, shows this structure with the FCS = field. (802.3ad has evolved into 802.1AX) - The 802.3ad spec PDF is = $155.=20 It=92s unclear if this was added to a later version spec. And with FCS = field, FreeBSD LACP just does not work. So =85 it would seem that big = iron routers and switches either are not adding in the FCS field. Or - = it is possible, with how the IBM support article is written - it is = possibly this field might be getting stripped by some NIC hardware or = drivers. Ok =85 I=92m going to investigate this further. I=92m working on = getting/borrowing a few different vendors switches with LACP and see = what I can find out. - David P. Discher http://davidpdischer.com/ AIM: DavidDPD | Y!M: daviddpdz=20 From owner-freebsd-net@FreeBSD.ORG Thu Dec 18 16:43:00 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EDA94E1A for ; Thu, 18 Dec 2014 16:43:00 +0000 (UTC) Received: from acipenser.esturion.net (acipenser.esturion.net [65.101.5.252]) (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 BEBFF17F0 for ; Thu, 18 Dec 2014 16:43:00 +0000 (UTC) Received: by acipenser.esturion.net (Postfix, from userid 112) id 28ECD260339; Thu, 18 Dec 2014 09:42:53 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on acipenser.esturion.net X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 Received: from feyerabend.n1.pinyon.org (quine.pinyon.org [65.101.5.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by acipenser.esturion.net (Postfix) with ESMTPSA id DDDF72600CE for ; Thu, 18 Dec 2014 09:42:50 -0700 (MST) Message-ID: <5493040A.6040209@pinyon.org> Date: Thu, 18 Dec 2014 09:42:50 -0700 From: "Russell L. Carter" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: compiling on nfs directories References: <1480362493.14973677.1418857654052.JavaMail.root@uoguelph.ca> <54922412.6090903@pinyon.org> <54922E49.4050906@egr.msu.edu> <549233E2.7050009@pinyon.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Dec 2014 16:43:01 -0000 On 12/18/14 08:37, Adam Vande More wrote: > On Thu, Dec 18, 2014 at 9:29 AM, Alan Somers wrote: >> >> On Wed, Dec 17, 2014 at 6:54 PM, Russell L. Carter >> wrote: >>> On 12/17/14 18:30, Adam McDougall wrote: >>>> >>>> On 12/17/2014 19:47, Russell L. Carter wrote: >>>>> >>>>> >>>>> >>>>> On 12/17/14 16:07, Rick Macklem wrote: >>>> >>>> >>>>>> If this is using an exported ZFS volume, it would be nice if you >>>>>> could do the same test using an exported UFS file system, to see if >>>>>> this is ZFS related. >>>>> >>>>> >>>>> It is indeed using exported ZFS filesystems, but unfortunately I have >>>>> no USF filesystems available to test. >>>>> >>>>> Russell >>>> >>>> >>>> Can you create a zvol, newfs it with ufs and export it? >>> >>> >>> Maybe. I would love to help if I can, w/o disrupting my existing >>> carefully planned physical disk layouts. I'm a zfs novice here, do I >>> need free space unallocated to existing zpools, or can I shrink an >>> existing pool? (assuming that zfs can transmute lead into gold, with >>> the right incantations). I have plenty of "free" space allocated to >>> existing pools that span my physical drives. >>> >>> If I have to add a physical drive (that's possible, but it will be a >>> slow drive sitting on my shelf) then I need to wait until I get back >>> from holiday travels. >> >> >> You don't need to screw with your pools at all. A zvol is like a >> managed like a ZFS filesystem, except it's a block device. You can >> create one and mount it with a command like this: >> zfs create -V 8g mypool/myvol >> newfs [options] /dev/mypool/myvol >> mount /dev/mypool/myvol /mnt > > > Using a flash drive or temporary drive seems like a much more comprehensive > test as you can fully eliminate ZFS from the picture. Which is the point > of the exercise. > Ok, good suggestions, noted, and thanks! Unfortunately I'm going to have to pick this up when I get back. Russell From owner-freebsd-net@FreeBSD.ORG Thu Dec 18 16:46:56 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57416F28; Thu, 18 Dec 2014 16:46:56 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2ABEC186B; Thu, 18 Dec 2014 16:46:56 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sBIGkpR3072513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Dec 2014 08:46:52 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sBIGkpGU072512; Thu, 18 Dec 2014 08:46:51 -0800 (PST) (envelope-from jmg) Date: Thu, 18 Dec 2014 08:46:51 -0800 From: John-Mark Gurney To: Alan Somers Subject: Re: FreeBSD 10-stable (r274577) LACP / IEEE 802.3ad with TP-Link TL-SG2008 - not working Message-ID: <20141218164651.GS25139@funkthat.com> Mail-Followup-To: Alan Somers , Craig Rodrigues , FreeBSD Net , Adam McDougall , "David P. Discher" References: <5480D8EF.9000804@egr.msu.edu> <3D993418-E632-44BA-8FE2-2F3F34188F20@dpdtech.com> <34276C9E-CAEF-4E3F-AA2A-568F2D3099EC@dpdtech.com> <2BCFC9D3-3B7D-421F-9FDA-0C4E1018F8F5@dpdtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 18 Dec 2014 08:46:52 -0800 (PST) Cc: Craig Rodrigues , FreeBSD Net , Adam McDougall , "David P. Discher" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Dec 2014 16:46:56 -0000 Alan Somers wrote this message on Thu, Dec 18, 2014 at 09:15 -0700: > On Wed, Dec 17, 2014 at 10:11 PM, Craig Rodrigues wrote: > > On Wed, Dec 17, 2014 at 9:08 PM, Craig Rodrigues > > wrote: > >> > >> > >> > >> On Wed, Dec 17, 2014 at 5:36 PM, David P. Discher wrote: > >>> > >>> > >>> Yeah, Alan - will do ... if I decided to look into more. That is why I was > >>> looking for spec on LACP. One side is doing it wrong. FreeBSD is looking > >>> for a LACPDU of exactly sizeof ( struct lacpdu ) which is 124 bytes. The > >>> TP-Link is sending a PDU of 128 bytes. I was hoping someone would know off > >>> hand what the spec says, if the PDU "should be" or "must be". > >>> > >> > >> > >> I think you have stumbled across a valid problem in the FreeBSD code. I > >> don't have access > >> to 802.3ad-2000, but this might give you some clues: > >> http://kb.juniper.net/InfoCenter/index?page=content&id=KB17674 > >> > >> I would also look at the source code of wireshark to be sure. wireshark > >> has a sample capture of LACP packets here: > >> > >> http://wiki.wireshark.org/LinkAggregationControlProtocol > >> > >> > > And here: > > > > http://www-01.ibm.com/support/docview.wss?uid=isg1VM64842 > > Good find, Craig. Also, I found the full LACPDU definition. It's in > section 5.4.2.2, page 33, of the 802.1ax-2008 spec that I linked to. > You can see the 4-byte FCS field at the end. Does your tp_link[4] > field look like an FCS? If so, you need to figure out why it's > propagating all the way up to the LACP level. It very well could be that the authors of the TP-Link firmware missed the comment in 1ax that says the FCS is generated by the MAC, and include it in their sending... If you could capture the original frame, and check the ether_type field, to see if it is 124 or 128... If it's 128, they probably added the FCS manually and the the MAC adds it a second time... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Thu Dec 18 23:58:06 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 43807776 for ; Thu, 18 Dec 2014 23:58:06 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 099C81F21 for ; Thu, 18 Dec 2014 23:58:05 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtoEAEFnk1SDaFve/2dsb2JhbABbg1hYBIMCwxIOhSRKAoE3AQEBAQF9hAwBAQEDAQEBASArIAsbGAICDRkCKQEJJgYIBwQBHASIAwgNuSOWLQEBAQEBAQEBAQEBAQEBAQEBAQEBGIEhjESBPAEBGzQHgmiBQQWJQ4gFgxyDIzCJeIJVgzgihAogMQEGfAkXBB5+AQEB X-IronPort-AV: E=Sophos;i="5.07,604,1413259200"; d="scan'208";a="177827528" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 18 Dec 2014 18:57:58 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id E0561AEA32; Thu, 18 Dec 2014 18:57:58 -0500 (EST) Date: Thu, 18 Dec 2014 18:57:58 -0500 (EST) From: Rick Macklem To: "Russell L. Carter" Message-ID: <156986383.574215.1418947078905.JavaMail.root@uoguelph.ca> In-Reply-To: <5493040A.6040209@pinyon.org> Subject: Re: compiling on nfs directories MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.10] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Dec 2014 23:58:06 -0000 Russell L. Carter wrote: > > > On 12/18/14 08:37, Adam Vande More wrote: > > On Thu, Dec 18, 2014 at 9:29 AM, Alan Somers > > wrote: > >> > >> On Wed, Dec 17, 2014 at 6:54 PM, Russell L. Carter > >> > >> wrote: > >>> On 12/17/14 18:30, Adam McDougall wrote: > >>>> > >>>> On 12/17/2014 19:47, Russell L. Carter wrote: > >>>>> > >>>>> > >>>>> > >>>>> On 12/17/14 16:07, Rick Macklem wrote: > >>>> > >>>> > >>>>>> If this is using an exported ZFS volume, it would be nice if > >>>>>> you > >>>>>> could do the same test using an exported UFS file system, to > >>>>>> see if > >>>>>> this is ZFS related. > >>>>> > >>>>> > >>>>> It is indeed using exported ZFS filesystems, but unfortunately > >>>>> I have > >>>>> no USF filesystems available to test. > >>>>> > >>>>> Russell > >>>> > >>>> > >>>> Can you create a zvol, newfs it with ufs and export it? > >>> > >>> > >>> Maybe. I would love to help if I can, w/o disrupting my existing > >>> carefully planned physical disk layouts. I'm a zfs novice here, > >>> do I > >>> need free space unallocated to existing zpools, or can I shrink > >>> an > >>> existing pool? (assuming that zfs can transmute lead into gold, > >>> with > >>> the right incantations). I have plenty of "free" space allocated > >>> to > >>> existing pools that span my physical drives. > >>> > >>> If I have to add a physical drive (that's possible, but it will > >>> be a > >>> slow drive sitting on my shelf) then I need to wait until I get > >>> back > >>> from holiday travels. > >> > >> > >> You don't need to screw with your pools at all. A zvol is like a > >> managed like a ZFS filesystem, except it's a block device. You > >> can > >> create one and mount it with a command like this: > >> zfs create -V 8g mypool/myvol > >> newfs [options] /dev/mypool/myvol > >> mount /dev/mypool/myvol /mnt > > > > > > Using a flash drive or temporary drive seems like a much more > > comprehensive > > test as you can fully eliminate ZFS from the picture. Which is the > > point > > of the exercise. > > Btw, avg@ just MFC'd r275401 which is a 1 line ZFS patch that helps to update time stamps. This one line patch might be worth a try? https://svnweb.freebsd.org/base/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c?r1=274337&r2=275401 rick > > Ok, good suggestions, noted, and thanks! Unfortunately I'm going > to have to pick this up when I get back. > > Russell > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Dec 19 00:05:26 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EECF3A77 for ; Fri, 19 Dec 2014 00:05:26 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 8B003215B for ; Fri, 19 Dec 2014 00:05:25 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtoEAEFnk1SDaFve/2dsb2JhbABbg1hYBIMCwxIOhSRKAoE3AQEBAQF9hAwBAQEDAQEBASArIAYFGxgCAg0ZAikBCSYGCAcEARwEiAMIDbkjli0BAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGMRIErEAIBGy8FB4JogUEFiUOIBYMcgyMwhGKHa4M4IoQKIDEBBoE+fgEBAQ X-IronPort-AV: E=Sophos;i="5.07,604,1413259200"; d="scan'208";a="177829649" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 18 Dec 2014 19:05:24 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id D8644AEA47; Thu, 18 Dec 2014 19:05:24 -0500 (EST) Date: Thu, 18 Dec 2014 19:05:24 -0500 (EST) From: Rick Macklem To: Gerrit =?utf-8?B?S8O8aG4=?= Message-ID: <1694130912.577722.1418947524871.JavaMail.root@uoguelph.ca> In-Reply-To: <20141216092948.605dc8e2e0fec3fa4a5f8ec1@aei.mpg.de> Subject: Re: compiling on nfs directories MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.10] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Dec 2014 00:05:27 -0000 Gerrit Kuhn wrote: > On Mon, 15 Dec 2014 15:59:29 -0500 (EST) Rick Macklem > wrote about Re: compiling on nfs directories: > > > RM> Also, note that he didn't see the problem with FreeBSD8.3, which > would > RM> have been following the same rules on the server as 10.1. > RM> > RM> What I suspect might cause this is one of two things: > RM> 1 - The modify time of the file is now changing at a time the > Linux > RM> client doesn't expect, due to changes in ZFS or maybe TOD > clock > RM> resolution. (At one time, the TOD clock was only at a > resolution > RM> of 1sec, so the client wouldn't see the modify time change > often. > RM> I think it is now at a much higher resolution, but would have > to > RM> look at the code/test to be sure.) > RM> 2 - I think you mention this one later in your message, in that > the > RM> build might be depending on file locking. If this is the > case, > RM> trying NFSv4, which does better file locking, might fix the > RM> problem. > > Meanwhile I have googled around a bit more, and one of the few > reasons > other people see the error messages I see appears to be a broken > clock that > makes "make" recompile stuff on the installation stage. As I was > already > wondering why compilation took longer than I had actually expected, I > may > be seeing something similar (still need to look into that), although > my > clock is fine (but time stamps on the NFS might be messed up somehow > like > you mention above under "1"). avg@ just MFC'd a one line ZFS patch (the one I vaguely remembered before). It is r275401 in head: https://svnweb.freebsd.org/base/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c?r1=274337&r2=275401 and appears to fix a problem with mtime being updated. This patch might be worth a try? (You could email avg@freebsd.org for more information on it.) rick > > RM> Gerrit, I would suggest that you do "nfsstat -m" on the Linux > client, > RM> to see what the mount options are. The Linux client might be > using > RM> NFSv4 already. > > This is what it says about my nfs-root: > > --- > pt-nds ~ # nfsstat -m > / from 192.168.32.253:/tank/diskless/nds > Flags: > rw,relatime,vers=3,rsize=4096,wsize=4096,namlen=255,hard,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.32.253,mountvers=3,mountproto=tcp,local_lock=all,addr=192.168.32.253 > --- > > This is what I set up for pxe-booting: > > --- > label gentoo-cs2 > menu label linux-3.8.13-gentoo-2 > kernel bzImage-3.8.13-gentoo-2 > append ip=dhcp root=/dev/nfs rw > nfsroot=192.168.32.253:/tank/diskless/nds,nolock,tcp,v3 > rootdelay=15 > --- > > > So I definitely run "nfsv3" and "nolock". I remember trying to use > nfsv4 on the diskless machines some years ago, but back then it was > not ready for prime time. > > RM> Also, avoid "soft, intr" especially if you are using NFSv4, since > these > RM> can cause slow server response to result in a failure of a > read/write > RM> when it shouldn't fail, due to timeout or interruption by a > signal. > > There is "hard" in there as a default option. However, I might try > turning on locking (I regarded it as superfluous up to now as I have > only one client using the filesystem). > > RM> If you could find out more about what causes the specific build > failure > RM> on the Linux side, that might help. > > As I said above, I have some hints that indicate something might be > wrong with timestamps, but I still need to dig deeper into that. > > RM> If you can reproduce a build failure quickly/easily, you can > capture > RM> packets via "tcpdump -s 0 -w host " on > the > RM> server and then look at it in wireshark to see what the server is > RM> replying when the build failure occurs. (I don't mind looking at > a > RM> packet trace if it is relatively small, if you email it to me as > an > RM> attachment.) > > I can reproduce it 100%, but it only happens on the installation > stage, after having compiled the whole stuff. So I don't know if I > will be able to produce a dump of reasonable size that contains the > issue, but I'll try. > > RM> ps: I am not familiar with the Linux mount options, but if it has > RM> stuff like "nocto", you could try those. > > The manpage has the following: > > --- > cto / nocto Selects whether to use close-to-open cache > coherence > semantics. If neither option is specified (or > if cto is > specified), the client uses close-to-open > cache coher- > ence semantics. If the nocto option is > specified, the > client uses a non-standard heuristic to > determine when > files on the server have changed. > > Using the nocto option may improve performance > for read- > only mounts, but should be used only if the > data on the > server changes only occasionally. The DATA AND > METADATA > COHERENCE section discusses the behavior of > this option > in more detail. > --- > > > So "cto" appears to be the default and is probably what is used right > now. I'll put "nocto" on my list of things to try (although the > description is not really that incouraging... :-). > > > cu > Gerrit > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Dec 19 03:12:07 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 77A91731 for ; Fri, 19 Dec 2014 03:12:07 +0000 (UTC) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "myname.my.domain", Issuer "www.mirapoint.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0A6BB1434 for ; Fri, 19 Dec 2014 03:12:06 +0000 (UTC) Received: from 172.24.2.119 (EHLO SZXEMA414-HUB.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEF96264; Fri, 19 Dec 2014 11:10:54 +0800 (CST) Received: from SZXEMA502-MBX.china.huawei.com ([169.254.3.12]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0158.001; Fri, 19 Dec 2014 11:10:44 +0800 From: "Yuzhou (C)" To: "freebsd-net@freebsd.org" Subject: [netmap] netmap rings connect to host stack Thread-Topic: [netmap] netmap rings connect to host stack Thread-Index: AdAbOWA2hM3X9j2GTeuP1O6gEmLy6w== Date: Fri, 19 Dec 2014 03:10:44 +0000 Message-ID: <47498F109986134D9A5B42B82F405EBB7EDD8234@SZXEMA502-MBX.china.huawei.com> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.122.221] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Zhangleiqiang \(Trump\)" , "Xiaoding \(B\)" , "Luohao \(brian\)" , Zhuangyuxin , "Liuji \(Jeremy\)" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Dec 2014 03:12:07 -0000 Hi everyone, I am a newbie to netmap. After reading papers about netmap, I think the path that netmap talk to host stack, like this:=20 Application | | Socket API | | Host stack | | Netmap rx/tx ring | | Nic driver=09 My understanding is right or not?? Anybody knows, please tell me, Tha= nks! Yuzhou From owner-freebsd-net@FreeBSD.ORG Fri Dec 19 04:11:26 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 53C2DD62 for ; Fri, 19 Dec 2014 04:11:26 +0000 (UTC) Received: from webmail2.jnielsen.net (webmail2.jnielsen.net [50.114.224.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "webmail2.jnielsen.net", Issuer "freebsdsolutions.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 334771CFF for ; Fri, 19 Dec 2014 04:11:25 +0000 (UTC) Received: from [192.168.2.123] (c-50-160-123-105.hsd1.ut.comcast.net [50.160.123.105]) (authenticated bits=0) by webmail2.jnielsen.net (8.14.9/8.14.9) with ESMTP id sBJ4BI3q060800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 18 Dec 2014 21:11:24 -0700 (MST) (envelope-from lists@jnielsen.net) X-Authentication-Warning: webmail2.jnielsen.net: Host c-50-160-123-105.hsd1.ut.comcast.net [50.160.123.105] claimed to be [192.168.2.123] From: John Nielsen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: IPv6 multicast routing Message-Id: Date: Thu, 18 Dec 2014 21:11:18 -0700 To: "freebsd-net@freebsd.org" X-Mailer: iPhone Mail (12B440) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Dec 2014 04:11:26 -0000 Hi all- Does anyone do IPv6 multicast routing on FreeBSD? If so, what software do yo= u use? Any caveats or other things to be aware of? The only options I have seen are all in net/mcast-tools and I'm having some t= rouble with each of them. I do have "options MROUTING" in my kernel and IPv6= forwarding enabled on each host. I've had the best luck with "mfc": I can get packets to traverse a single ro= uter. However I can't get them to traverse a second one in either direction (= though that may or may not be a problem with mfc itself). The big downer of c= ourse is that each unicast source and multicast destination has to be explic= itly spelled out in each direction in the config file. Not at all scalable a= nd not compatible with the auto-configuration goals of my project. The one I think I'd like to use is pim6sd. However I have had no luck with e= ither it or pim6dd. Both will run but not pass packets, and they each compla= in that they cannot assign the requested ff02::2 address on either interface= . Any advice or suggestions appreciated. JN= From owner-freebsd-net@FreeBSD.ORG Fri Dec 19 07:26:01 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 181BE1C6 for ; Fri, 19 Dec 2014 07:26:01 +0000 (UTC) Received: from umail.aei.mpg.de (umail.aei.mpg.de [194.94.224.6]) (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 B80CA1799 for ; Fri, 19 Dec 2014 07:25:59 +0000 (UTC) Received: from mailgate.aei.mpg.de (mailgate.aei.mpg.de [194.94.224.5]) by umail.aei.mpg.de (Postfix) with ESMTP id B496E18AE027; Fri, 19 Dec 2014 08:25:09 +0100 (CET) Received: from mailgate.aei.mpg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6ED0640588A; Fri, 19 Dec 2014 08:25:13 +0100 (CET) Received: from intranet.aei.uni-hannover.de (ahin1.aei.uni-hannover.de [130.75.117.40]) by mailgate.aei.mpg.de (Postfix) with ESMTP id D33FA406AF1; Fri, 19 Dec 2014 08:25:12 +0100 (CET) Received: from arc.aei.uni-hannover.de ([10.117.15.110]) by intranet.aei.uni-hannover.de (Lotus Domino Release 8.5.3FP6HF1016) with ESMTP id 2014121908245856-74580 ; Fri, 19 Dec 2014 08:24:58 +0100 Date: Fri, 19 Dec 2014 08:24:58 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Rick Macklem Subject: Re: compiling on nfs directories Message-Id: <20141219082458.86c1a35fd69bbfd2ce39b4ce@aei.mpg.de> In-Reply-To: <1694130912.577722.1418947524871.JavaMail.root@uoguelph.ca> References: <20141216092948.605dc8e2e0fec3fa4a5f8ec1@aei.mpg.de> <1694130912.577722.1418947524871.JavaMail.root@uoguelph.ca> Organization: Max Planck Gesellschaft X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on intranet/aei-hannover(Release 8.5.3FP6HF1016 | October 31, 2014) at 19.12.2014 08:24:58, Serialize by Router on intranet/aei-hannover(Release 8.5.3FP6HF1016 | October 31, 2014) at 19.12.2014 08:25:08, Serialize complete at 19.12.2014 08:25:08 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-PMX-Version: 6.0.2.2308539, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.19.71520 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, MIME_LOWER_CASE 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, BODY_SIZE_700_799 0, REFERENCES 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_FROM 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS ' Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Dec 2014 07:26:01 -0000 On Thu, 18 Dec 2014 19:05:24 -0500 (EST) Rick Macklem wrote about Re: compiling on nfs directories: RM> avg@ just MFC'd a one line ZFS patch (the one I vaguely remembered RM> before). It is r275401 in head: RM> https://svnweb.freebsd.org/base/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c?r1=274337&r2=275401 RM> RM> and appears to fix a problem with mtime being updated. RM> This patch might be worth a try? RM> (You could email avg@freebsd.org for more information on it.) Thanks for the pointers. I cannot try this straight away as the server is a production machine, but I'll try to set up some testbed somewhere else in January (will be on vacation until then). cu Gerrit From owner-freebsd-net@FreeBSD.ORG Fri Dec 19 13:03:05 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7407AADB for ; Fri, 19 Dec 2014 13:03:05 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 3A4541258 for ; Fri, 19 Dec 2014 13:03:04 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANsglFSDaFve/2dsb2JhbABag1hYBIMBwxUOhSNKAoExAQEBAQF9hAwBAQEDAQEBASArIAsbGAICDRkCKQEJJgYIBwQBHASIAwgNuUWWOgEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYxEgSsQAgEbNAeCaIFBBYlFiAWDHINTkAsihAogMQEGgT5+AQEB X-IronPort-AV: E=Sophos;i="5.07,606,1413259200"; d="scan'208";a="179730753" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 19 Dec 2014 08:02:54 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 6B343B4034; Fri, 19 Dec 2014 08:02:54 -0500 (EST) Date: Fri, 19 Dec 2014 08:02:54 -0500 (EST) From: Rick Macklem To: Gerrit =?utf-8?B?S8O8aG4=?= Message-ID: <1258917622.750031.1418994174425.JavaMail.root@uoguelph.ca> In-Reply-To: <20141219082458.86c1a35fd69bbfd2ce39b4ce@aei.mpg.de> Subject: Re: compiling on nfs directories MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.11] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Dec 2014 13:03:05 -0000 Gerrit Kuhn wrote: > On Thu, 18 Dec 2014 19:05:24 -0500 (EST) Rick Macklem > wrote about Re: compiling on nfs directories: > > RM> avg@ just MFC'd a one line ZFS patch (the one I vaguely > remembered > RM> before). It is r275401 in head: > RM> > https://svnweb.freebsd.org/base/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c?r1=274337&r2=275401 > RM> > RM> and appears to fix a problem with mtime being updated. > RM> This patch might be worth a try? > RM> (You could email avg@freebsd.org for more information on it.) > > Thanks for the pointers. I cannot try this straight away as the > server is a > production machine, but I'll try to set up some testbed somewhere > else in > January (will be on vacation until then). > avg@ MFC'd this patch to stable/9 and stable/10, so you can set up a test machine with stable/10 on it instead of adding the one line patch to whatever version you are running, if you'd like. Thanks and good luck with it, rick > > cu > Gerrit > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Dec 19 13:50:36 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 78A21A8C for ; Fri, 19 Dec 2014 13:50:36 +0000 (UTC) Received: from umail.aei.mpg.de (umail.aei.mpg.de [194.94.224.6]) (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 243081C02 for ; Fri, 19 Dec 2014 13:50:35 +0000 (UTC) Received: from mailgate.aei.mpg.de (mailgate.aei.mpg.de [194.94.224.5]) by umail.aei.mpg.de (Postfix) with ESMTP id E2F8C8B667C; Fri, 19 Dec 2014 14:50:32 +0100 (CET) Received: from mailgate.aei.mpg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 297BA40588C; Fri, 19 Dec 2014 14:50:36 +0100 (CET) Received: from intranet.aei.uni-hannover.de (ahin1.aei.uni-hannover.de [130.75.117.40]) by mailgate.aei.mpg.de (Postfix) with ESMTP id F1834406AF1; Fri, 19 Dec 2014 14:50:35 +0100 (CET) Received: from arc.aei.uni-hannover.de ([10.117.15.110]) by intranet.aei.uni-hannover.de (Lotus Domino Release 8.5.3FP6HF1016) with ESMTP id 2014121914502249-75015 ; Fri, 19 Dec 2014 14:50:22 +0100 Date: Fri, 19 Dec 2014 14:50:22 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Rick Macklem Subject: Re: compiling on nfs directories Message-Id: <20141219145022.8bcd2795ba269b7becef54b2@aei.mpg.de> In-Reply-To: <1258917622.750031.1418994174425.JavaMail.root@uoguelph.ca> References: <20141219082458.86c1a35fd69bbfd2ce39b4ce@aei.mpg.de> <1258917622.750031.1418994174425.JavaMail.root@uoguelph.ca> Organization: Max Planck Gesellschaft X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on intranet/aei-hannover(Release 8.5.3FP6HF1016 | October 31, 2014) at 19.12.2014 14:50:22, Serialize by Router on intranet/aei-hannover(Release 8.5.3FP6HF1016 | October 31, 2014) at 19.12.2014 14:50:32, Serialize complete at 19.12.2014 14:50:32 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-PMX-Version: 6.0.2.2308539, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.19.133923 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, MIME_LOWER_CASE 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_600_699 0, BODY_SIZE_7000_LESS 0, REFERENCES 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_FROM 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS ' Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Dec 2014 13:50:36 -0000 On Fri, 19 Dec 2014 08:02:54 -0500 (EST) Rick Macklem wrote about Re: compiling on nfs directories: RM> avg@ MFC'd this patch to stable/9 and stable/10, so you can set up a RM> test machine with stable/10 on it instead of adding the one line RM> patch to whatever version you are running, if you'd like. I have a newly installed 36slot storage chassis that I will probably use for testing. It is running 10.1 now and should be easily upgradable to -stable (and needs some testing before being put into production, aynway). RM> Thanks and good luck with it, rick Thanks again for your support. cu Gerrit From owner-freebsd-net@FreeBSD.ORG Fri Dec 19 14:27:58 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB890388; Fri, 19 Dec 2014 14:27:58 +0000 (UTC) Received: from relay1.speechpro.com (relay1.speechpro.com [79.134.214.22]) (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 226B22124; Fri, 19 Dec 2014 14:27:58 +0000 (UTC) Received: from mail.stc ([192.168.8.64] helo=spb2.speechpro.com) by relay1.speechpro.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Y1yED-000MSX-6t; Fri, 19 Dec 2014 17:08:25 +0300 Received: from [192.168.6.123] by mail.stc with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Y1yEC-000FDC-TU; Fri, 19 Dec 2014 17:08:24 +0300 Message-ID: <54943158.90307@speechpro.com> Date: Fri, 19 Dec 2014 17:08:24 +0300 From: Yuriy Tabolin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Jack Vogel , "Alexander V. Chernikov" , FreeBSD Net Subject: Re: problem with 9k jumbo clusters References: <54803C75.2020300@speechpro.com> <5480AF38.3070100@FreeBSD.org> In-Reply-To: X-Archived: Yes Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Dec 2014 14:27:59 -0000 I tried to understand the code ixgbe, but I did not succeed. If anybody could, make patch for me, please. 05.12.2014 00:49, Jack Vogel пишет: > I had wanted to remove the larger cluster sizes from the driver a > while back, but for reasons > I don't remember that code change didn't happen. The new 40G ixl > driver does this, it only > uses standard clusters for anything under 2K, and above that > everything uses 4K. > > I would be curious to see if this change would resolve your problem, > would you like a patch, > or are you able to hack the code yourself to do this? > > Jack > > > On Thu, Dec 4, 2014 at 11:00 AM, Alexander V. Chernikov > > wrote: > > On 04.12.2014 13:50, Yuriy Tabolin wrote: > > Hi All. > I have a server with two Intel 10G NIC. OS FreeBSD > 10.1-Release amd64. Server works like NFS, samba-server and > iSCSI target. Both NICs aggregated into lagg device and set > MTU 9014 to them. There are some tuning sysctl.conf: > kern.maxfiles=6289601 > kern.maxfilesperproc=5660640 > kern.maxvnodes=3339565 > kern.ipc.nmbclusters=12255588 > kern.ipc.nmbjumbop=6127794 > kern.ipc.nmbufs=78435780 > kern.ipc.maxsockbuf=16777216 > kern.ipc.maxsockets=6289600 > net.inet.tcp.sendbuf_max=16777216 > net.inet.tcp.sendspace=65536 > net.inet.tcp.recvbuf_max=16777216 > net.inet.tcp.recvspace=65536 > > After some days of working, the errors are appearing: > ix1: Interface stopped DISTRIBUTING, possible flapping > ix0: Interface stopped DISTRIBUTING, possible flapping > ix0: Could not setup receive structures > ix1: Could not setup receive structures > > Hello. It looks like > https://lists.freebsd.org/pipermail/freebsd-net/2014-May/038630.html > is relevant here. > > > After that errors the NICs stoped working. netstat -m shows: > 32881/33854/66735 mbufs in use (current/cache/total) > 16370/8198/24568/12255588 mbuf clusters in use > (current/cache/total/max) > 16370/4807 mbuf+clusters out of packet secondary zone in use > (current/cache) > 0/873/873/6127794 4k (page size) jumbo clusters in use > (current/cache/total/max) > 16383/21517/37900/1815641 9k jumbo clusters in use > (current/cache/total/max) > 0/0/0/1021298 16k jumbo clusters in use (current/cache/total/max) > 188407K/222004K/410411K bytes allocated to network > (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) > 0/101414306/0 requests for jumbo clusters denied (4k/9k/16k) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > > 9k jumbo clusters max is too big, but looks like system cannot > allocate them. There are huge number of "9k requests for jumbo > clusters denied". ifconfig ix down/up don't helped, reboot is > needed. Thanks for any help! > > > -- > Best regards, > Tabolin Yuriy > System administrator > Speech Technology Center > _______________________________________________ > freebsd-net@freebsd.org > mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org > " > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org > " > > -- Best regards, Tabolin Yuriy System administrator Speech Technology Center From owner-freebsd-net@FreeBSD.ORG Fri Dec 19 14:40:27 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 84D3E650 for ; Fri, 19 Dec 2014 14:40:27 +0000 (UTC) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 33536263C for ; Fri, 19 Dec 2014 14:40:27 +0000 (UTC) Received: by mail-yk0-f172.google.com with SMTP id 131so421423ykp.31 for ; Fri, 19 Dec 2014 06:40:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dpdtech.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=aXJkmVIt1XFpmCNxFnk6MhBdSfw2E25WJ9WmceMgNik=; b=LFtGc81KEjVdpHoNQSLM/izSB07sXjobTpVpG4YW3iS6aG1N0n8Kvph96O44XiRBBH omZtAEt+pScg2wJqvHKmaY971q26RWM35hFr0m5m5La+BxbjwZ91J6MLfL4c+gPjL7m3 6TH16lZVeEoPS8bXo1tnzkGABpJzQ9Vic4Ip0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=aXJkmVIt1XFpmCNxFnk6MhBdSfw2E25WJ9WmceMgNik=; b=jd2pNuN+d0BA41A9Bcj4+vuBJnnElre8Dswi8dMmx94wofi0nyzveAf9QxeH0k45XN nU0a7aLhwClSMu0Kyu6xgJwQO3YFIdO495GDvy8OnALmp4ecE3zWQAxBShQXDwCa/i02 GzKUqEaPkK9Bt/+4pPmSc/OUheoLXGJVtDL9Sep/G9mP01/yfcvi1geiC/kKZnehz6dJ XaBNNHsHmVVUhMNu1zG2uA3V9Kh1nxAqSl0l+KGhLV5pgDhpSd7rhbdnyY6fVJ+zZ8rF tyhJWIaFkL87MXI2pkbh1o/ExA7rYrPTW3SgxSr81IpNxH98et9JLNzuxWxovnzq6SL8 /rGg== X-Gm-Message-State: ALoCoQkWiSvcBJrffm5Z7MO6EYfD2A4i3Uqs7ZSqGXLW4GIyfwFw94hQjezY76dab240GTG56eWC X-Received: by 10.236.70.70 with SMTP id o46mr6431579yhd.191.1419000026233; Fri, 19 Dec 2014 06:40:26 -0800 (PST) Received: from [192.168.0.164] (71-81-146-153.dhcp.stls.mo.charter.com. [71.81.146.153]) by mx.google.com with ESMTPSA id 46sm6012524yhd.13.2014.12.19.06.40.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Dec 2014 06:40:25 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_E5D4F5BA-6658-483D-8BA0-1D8289245142"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: FreeBSD 10-stable (r274577) LACP / IEEE 802.3ad with TP-Link TL-SG2008 - not working From: "David P. Discher" In-Reply-To: <20141218164651.GS25139@funkthat.com> Date: Fri, 19 Dec 2014 08:40:23 -0600 Message-Id: References: <5480D8EF.9000804@egr.msu.edu> <3D993418-E632-44BA-8FE2-2F3F34188F20@dpdtech.com> <34276C9E-CAEF-4E3F-AA2A-568F2D3099EC@dpdtech.com> <2BCFC9D3-3B7D-421F-9FDA-0C4E1018F8F5@dpdtech.com> <20141218164651.GS25139@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1878.6) Cc: Craig Rodrigues , FreeBSD Net , Adam McDougall , Alan Somers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Dec 2014 14:40:27 -0000 --Apple-Mail=_E5D4F5BA-6658-483D-8BA0-1D8289245142 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I=92m going to look into other switches/routers and read the spec a bit = closer, but linux seems to think the LACPDU check is packet size =3D> = sizeof(struct lacpdu) : - = https://github.com/torvalds/linux/blob/70e71ca0af244f48a5dcf56dc435243792e= 3a495/drivers/net/bonding/bond_3ad.c#L2185 - David P. Discher http://davidpdischer.com/ AIM: DavidDPD | Y!M: daviddpdz=20 On Dec 18, 2014, at 10:46 AM, John-Mark Gurney wrote: >>=20 >> Good find, Craig. Also, I found the full LACPDU definition. It's in >> section 5.4.2.2, page 33, of the 802.1ax-2008 spec that I linked to. >> You can see the 4-byte FCS field at the end. Does your tp_link[4] >> field look like an FCS? If so, you need to figure out why it's >> propagating all the way up to the LACP level. >=20 > It very well could be that the authors of the TP-Link firmware missed > the comment in 1ax that says the FCS is generated by the MAC, and > include it in their sending... >=20 > If you could capture the original frame, and check the ether_type > field, to see if it is 124 or 128... If it's 128, they probably added > the FCS manually and the the MAC adds it a second time... >=20 --Apple-Mail=_E5D4F5BA-6658-483D-8BA0-1D8289245142 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUlDjYAAoJEEmwU6XuhYWOv3QH/2GaTMecfaWyK+gjxthjctsH zhdf8h8whc6j+EyPNXEk69WAFrHkyKeIheRImK0jQXQxP56ybnwMGcxJPxVLObux GUznhHgl/8jKOvLNtuMT6c95hQp5B5s+BcSIASDoaz1FCHqSAptvCh+Qk14k8WiB mucIUgEGnhzdttXX3sCks2YjANHpDXboy+5Hy2vBD0jFGF0VSfj5U6Dvx8RwvxIR Bk2nd4JVJ0Auj8ns28HVHCVV5xfPThfedErqA+xrYFidS+KwB7yLSh6T9X1Ki2el p0qIuF/gKs2l9gXkIBOhtjOTABq5sBvSN7qS5FqArEEIyevV7Piku0SGjBvzL3Y= =8Zst -----END PGP SIGNATURE----- --Apple-Mail=_E5D4F5BA-6658-483D-8BA0-1D8289245142-- From owner-freebsd-net@FreeBSD.ORG Fri Dec 19 14:50:52 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8537C833; Fri, 19 Dec 2014 14:50:52 +0000 (UTC) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id 25984307C; Fri, 19 Dec 2014 14:50:50 +0000 (UTC) Message-ID: <54943B2B.9000407@FreeBSD.org> Date: Fri, 19 Dec 2014 17:50:19 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [RFC] add macros for ifnet statistic accounting References: <546E25D1.7020900@FreeBSD.org> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2q53MbB66jEuwLhXAgnSpjUvUk8hRlPPm" Cc: "freebsd-net@freebsd.org" , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Dec 2014 14:50:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2q53MbB66jEuwLhXAgnSpjUvUk8hRlPPm Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 20.11.2014 20:38, Adrian Chadd wrote: > On 20 November 2014 09:33, Andrey V. Elsukov wrote: >> Hi All, >> >> we already did some changes in network stack in head/, that made abili= ty >> for merging changes into stable branches much harder. >> >> What you think about adding the following macro to head/: >> >> --- if_var.h (revision 274736) >> +++ if_var.h (working copy) >> @@ -111,6 +111,10 @@ typedef enum { >> IFCOUNTERS /* Array size. */ >> } ift_counter; >> >> +#define IFSTAT_ADD(ifp, name, value) \ >> + if_inc_counter((ifp), IFCOUNTER_ ## name, (value)) >> +#define IFSTAT_INC(ifp, name) IFSTAT_ADD(ifp, name, 1) >> + >> typedef struct ifnet * if_t; >> >> typedef void (*if_start_fn_t)(if_t); >> >> >> And then make a direct commit to stable/* branches like this: >> >> --- if_var.h (revision 274750) >> +++ if_var.h (working copy) >> @@ -104,6 +104,23 @@ VNET_DECLARE(struct pfil_head, link_pfil_hook); = /* >> #define V_link_pfil_hook VNET(link_pfil_hook) >> #endif /* _KERNEL */ >> >> +#define IFSTAT_ADD(ifp, name, value) \ >> + IFSTAT_ ## name ## _ADD(ifp, value) >> +#define IFSTAT_INC(ifp, name) IFSTAT_ADD(ifp, name, 1) >> + >> +#define IFSTAT_IPACKETS_ADD(ifp, inc) (ifp)->if_ipackets +=3D= (inc) >> +#define IFSTAT_IERRORS_ADD(ifp, inc) (ifp)->if_ierrors +=3D= (inc) >> +#define IFSTAT_OPACKETS_ADD(ifp, inc) (ifp)->if_opackets +=3D= (inc) >> +#define IFSTAT_OERRORS_ADD(ifp, inc) (ifp)->if_oerrors +=3D= (inc) >> +#define IFSTAT_COLLISIONS_ADD(ifp, inc) (ifp)->if_collisions += =3D (inc) >> +#define IFSTAT_IBYTES_ADD(ifp, inc) (ifp)->if_ibytes +=3D = (inc) >> +#define IFSTAT_OBYTES_ADD(ifp, inc) (ifp)->if_obytes +=3D = (inc) >> +#define IFSTAT_IMCASTS_ADD(ifp, inc) (ifp)->if_imcasts +=3D= (inc) >> +#define IFSTAT_OMCASTS_ADD(ifp, inc) (ifp)->if_omcasts +=3D= (inc) >> +#define IFSTAT_IQDROPS_ADD(ifp, inc) (ifp)->if_iqdrops +=3D= (inc) >> +#define IFSTAT_OQDROPS_ADD(ifp, inc) /* NOP */ >> +#define IFSTAT_NOPROTO_ADD(ifp, inc) (ifp)->if_noproto +=3D= (inc) >> + >> /* >> * Structure defining a queue for a network interface. >> */ >> >> This can make merging a little bit easier, at least for generic code i= n >> the network stack. It looks there are not so much people, who wants this feature. We discussed this with glebius@ and probably the better solution will be merging ift_counter enum and adding if_inc_counter() function to stable/10. I looked how other BSDs doing this accounting and only DfBSD has macro IFNET_STAT_INC(). But since we are planning to make opaque ifnet, it doesn't matter how we will do accounting, anyway it will be incompatible with other BSDs. If there is no objections I'll commit this after weekend. Index: if.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- if.c (revision 275939) +++ if.c (working copy) @@ -1450,6 +1450,56 @@ if_rtdel(struct radix_node *rn, void *arg) } /* + * A compatibility function returns ifnet counter values. + */ +uint64_t +if_get_counter_default(struct ifnet *ifp, ift_counter cnt) +{ + + KASSERT(cnt < IFCOUNTERS, ("%s: invalid cnt %d", __func__, cnt)); + + switch (cnt) { + case IFCOUNTER_IPACKETS: return (ifp->if_ipackets); + case IFCOUNTER_IERRORS: return (ifp->if_ierrors); + case IFCOUNTER_OPACKETS: return (ifp->if_opackets); + case IFCOUNTER_OERRORS: return (ifp->if_oerrors); + case IFCOUNTER_COLLISIONS: return (ifp->if_collisions); + case IFCOUNTER_IBYTES: return (ifp->if_ibytes); + case IFCOUNTER_OBYTES: return (ifp->if_obytes); + case IFCOUNTER_IMCASTS: return (ifp->if_imcasts); + case IFCOUNTER_OMCASTS: return (ifp->if_omcasts); + case IFCOUNTER_IQDROPS: return (ifp->if_iqdrops); + case IFCOUNTER_NOPROTO: return (ifp->if_noproto); + }; + return (0); +} + +/* + * Increase an ifnet counter. Usually used for counters shared + * between the stack and a driver, but function supports them all. + */ +void +if_inc_counter(struct ifnet *ifp, ift_counter cnt, int64_t inc) +{ + + KASSERT(cnt < IFCOUNTERS, ("%s: invalid cnt %d", __func__, cnt)); + + switch (cnt) { + case IFCOUNTER_IPACKETS: ifp->if_ipackets +=3D inc; break; + case IFCOUNTER_IERRORS: ifp->if_ierrors +=3D inc; break; + case IFCOUNTER_OPACKETS: ifp->if_opackets +=3D inc; break; + case IFCOUNTER_OERRORS: ifp->if_oerrors +=3D inc; break; + case IFCOUNTER_COLLISIONS: ifp->if_collisions +=3D inc; break; + case IFCOUNTER_IBYTES: ifp->if_ibytes +=3D inc; break; + case IFCOUNTER_OBYTES: ifp->if_obytes +=3D inc; break; + case IFCOUNTER_IMCASTS: ifp->if_imcasts +=3D inc; break; + case IFCOUNTER_OMCASTS: ifp->if_omcasts +=3D inc; break; + case IFCOUNTER_IQDROPS: ifp->if_iqdrops +=3D inc; break; + case IFCOUNTER_NOPROTO: ifp->if_noproto +=3D inc; break; + }; +} + +/* * Wrapper functions for struct ifnet address list locking macros. These are * used by kernel modules to avoid encoding programming interface or bin= ary * interface assumptions that may be violated when kernel-internal locki= ng Index: if_var.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- if_var.h (revision 275939) +++ if_var.h (working copy) @@ -104,6 +104,22 @@ VNET_DECLARE(struct pfil_head, link_pfil_hook); /* #define V_link_pfil_hook VNET(link_pfil_hook) #endif /* _KERNEL */ +typedef enum { + IFCOUNTER_IPACKETS =3D 0, + IFCOUNTER_IERRORS, + IFCOUNTER_OPACKETS, + IFCOUNTER_OERRORS, + IFCOUNTER_COLLISIONS, + IFCOUNTER_IBYTES, + IFCOUNTER_OBYTES, + IFCOUNTER_IMCASTS, + IFCOUNTER_OMCASTS, + IFCOUNTER_IQDROPS, + IFCOUNTER_OQDROPS, + IFCOUNTER_NOPROTO, + IFCOUNTERS /* Array size. */ +} ift_counter; + /* * Structure defining a queue for a network interface. */ @@ -981,6 +997,8 @@ typedef void *if_com_alloc_t(u_char type, struct i typedef void if_com_free_t(void *com, u_char type); void if_register_com_alloc(u_char type, if_com_alloc_t *a, if_com_free_t *f); void if_deregister_com_alloc(u_char type); +uint64_t if_get_counter_default(struct ifnet *, ift_counter); +void if_inc_counter(struct ifnet *, ift_counter, int64_t); #define IF_LLADDR(ifp) \ LLADDR((struct sockaddr_dl *)((ifp)->if_addr->ifa_addr)) --=20 WBR, Andrey V. Elsukov --2q53MbB66jEuwLhXAgnSpjUvUk8hRlPPm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJUlDsyAAoJEAHF6gQQyKF64gYH/3sfTX6mrhxU+4nUsT70GaOe Es7sl+RKJgaf7Orz72IngTbFSP5Glq0huTriznGPC49PoZKIFeq0G/v7GuZLd+hC WUDcJLKHHCPQ4LG5KC5vTi7krnnoh+IufDRTF4c4eytpQT76TVaeUTDCv/nWYzFY sgGFBsUV8UeaWBwcPsOY25BfwMWi8Ige2dXB+4JIEZUTmRJ3ljOVe0coUKBsqffm 5nk7xpk0n9Sk8IS4ROQsElqRkfDXuHcbhm/06zH1TupXtFjzx6ypmw0o3PzsLjMe ozB9HLy3cwh9fKC7eT0jsQbuJTzLarstGko+VeyPadvTnWgA37Rcxz4Vu7y2w/w= =nUTn -----END PGP SIGNATURE----- --2q53MbB66jEuwLhXAgnSpjUvUk8hRlPPm-- From owner-freebsd-net@FreeBSD.ORG Sat Dec 20 04:05:10 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6BD30AA6 for ; Sat, 20 Dec 2014 04:05:10 +0000 (UTC) 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 5278E1DA9 for ; Sat, 20 Dec 2014 04:05:10 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sBK45A9I089960 for ; Sat, 20 Dec 2014 04:05:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 156226] [lagg]: failover does not announce the failover to switch Date: Sat, 20 Dec 2014 04:05: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: unspecified X-Bugzilla-Keywords: feature, needs-patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_severity keywords cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Dec 2014 04:05:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=156226 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Affects Only Me |Affects Some People Keywords| |feature, needs-patch CC| |koobs@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sat Dec 20 04:17:11 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17498DA2 for ; Sat, 20 Dec 2014 04:17:11 +0000 (UTC) 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 F26DD24C4 for ; Sat, 20 Dec 2014 04:17:10 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sBK4HAsc032684 for ; Sat, 20 Dec 2014 04:17:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 156226] [lagg]: failover does not announce the failover to switch Date: Sat, 20 Dec 2014 04:17: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: unspecified X-Bugzilla-Keywords: feature, needs-patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Dec 2014 04:17:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=156226 --- Comment #3 from Kubilay Kocak --- Created attachment 150794 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=150794&action=edit Send gratuitous ARP on primary port status change Add patch posted to freebsd-net [1] by Tushar Mulkar from Sandvine in February 2012. [1] https://lists.freebsd.org/pipermail/freebsd-net/2012-February/031328.html -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sat Dec 20 04:17:42 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 064D8E59 for ; Sat, 20 Dec 2014 04:17:42 +0000 (UTC) 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 E1B3724DA for ; Sat, 20 Dec 2014 04:17:41 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sBK4HfKx033020 for ; Sat, 20 Dec 2014 04:17:41 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 156226] [lagg]: failover does not announce the failover to switch Date: Sat, 20 Dec 2014 04:17:41 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: feature, needs-qa, patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Dec 2014 04:17:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=156226 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|needs-patch |needs-qa, patch -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sat Dec 20 22:40:39 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5DD68FA for ; Sat, 20 Dec 2014 22:40:39 +0000 (UTC) Received: from olymp.kibab.com (olymp6.kibab.com [IPv6:2a01:4f8:160:84c1::2]) by mx1.freebsd.org (Postfix) with ESMTP id AB3532D85 for ; Sat, 20 Dec 2014 22:40:39 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 olymp.kibab.com 8084E75917 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bakulin.de; s=default; t=1419115237; bh=3ql1M/v5illkpJpGdPC2slYHadLn4gSK2mBJnjmg61I=; h=Date:From:To:Subject; b=QwXKusGTslEBK7b0bXv0j1lbeCsdqCFtWwgmLdn/IK4rAMcFROjhhRZ/hVlUv+dTX BAtZbBypSRArGArLe47DHMmlyIbqEtewm8N+PSIaGxjNVDNDWfhyh6Ur+gLpYmIcsl /HsxaCTHHXnJz2jn9jHJ91avL1rc77KgKEV1CGlw= Message-ID: <5495FAE5.8090707@bakulin.de> Date: Sat, 20 Dec 2014 23:40:37 +0100 From: Ilya Bakulin MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: IPv6 fragments handling Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Dec 2014 22:40:40 -0000 Hi list, I've been running OpenBSD IPv6 fragmentation tests (regress/sys/netinet6/frag6) and noticed that FreeBSD doesn't drop the IPv6 packet if it receives a fragment that partially overlaps with already received data. The test that fails is frag6_overhead0.py, but also frag6_overhead.py. There is an RFC-5722 that explicitly tells to discard such packets [1]: ------------------------------------------------ 4. Node Behavior IPv6 nodes transmitting datagrams that need to be fragmented MUST NOT create overlapping fragments. When reassembling an IPv6 datagram, if one or more its constituent fragments is determined to be an overlapping fragment, the entire datagram (and any constituent fragments, including those not yet received) MUST be silently discarded. Nodes MAY also provide mechanisms to track the reception of such packets, for instance, by implementing counters or alarms relating to these events. ------------------------------------------------ But what we do is just silently discarding the overlapping segment, see [2]. When using PF with fragment reassembly, the behavior changes to what RFC says and the packet is completely dropped. There is no security issue with current behavior, because the already received part is never overwritten, but following RFC a bit closer would be nice. Maybe we should fix the stack to drop such packets? [1] https://tools.ietf.org/html/rfc5722#section-4 [2] https://github.com/freebsd/freebsd/blob/master/sys/netinet6/frag6.c#L443