From owner-freebsd-net@FreeBSD.ORG Sun Feb 8 18:03:37 2015 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 E8435B15 for ; Sun, 8 Feb 2015 18:03:37 +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 C342F75F for ; Sun, 8 Feb 2015 18:03:37 +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 t18I3bo4011702 for ; Sun, 8 Feb 2015 18:03:37 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 t18I3bjU011701; Sun, 8 Feb 2015 18:03:37 GMT (envelope-from root) Date: Sun, 8 Feb 2015 18:03:37 +0000 To: freebsd-net@freebsd.org From: "bz (Bjoern A. Zeeb)" Subject: [Differential] [Updated] D1777: Associated fix for arp/nd6 timer usage. Message-ID: <93ad7b2cf495b356782216e452a5e963@localhost.localdomain> X-Priority: 3 Thread-Topic: D1777: Associated fix for arp/nd6 timer usage. X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: N2Y2Y2VmY2ZjNTc1MTM4NTA3YmIzZDk3NmE4IFTXpPk= 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, 08 Feb 2015 18:03:38 -0000 bz added a comment. Hiren, it only took us 4 years to trigger this? Can people actually easily/reliably reproduce it? REVISION DETAIL https://reviews.freebsd.org/D1777 To: rrs, imp, sbruno, gnn, rwatson, lstewart, kostikbel, adrian, jhb, bz Cc: bz, emaste, hiren, julian, hselasky, freebsd-net From owner-freebsd-net@FreeBSD.ORG Sun Feb 8 19:55:04 2015 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 463DC33F for ; Sun, 8 Feb 2015 19:55:04 +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 20A22210 for ; Sun, 8 Feb 2015 19:55:04 +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 t18Jt3vP027373 for ; Sun, 8 Feb 2015 19:55:03 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 t18Jt3TM027372; Sun, 8 Feb 2015 19:55:03 GMT (envelope-from root) Date: Sun, 8 Feb 2015 19:55:03 +0000 To: freebsd-net@freebsd.org From: "hiren (hiren panchasara)" Subject: [Differential] [Commented On] D1777: Associated fix for arp/nd6 timer usage. Message-ID: <209f4916fd920a86d3b64adcc663d613@localhost.localdomain> X-Priority: 3 Thread-Topic: D1777: Associated fix for arp/nd6 timer usage. X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: N2Y2Y2VmY2ZjNTc1MTM4NTA3YmIzZDk3NmE4IFTXvxc= 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, 08 Feb 2015 19:55:04 -0000 hiren added a comment. >>! In D1777#16, @bz wrote: > Hiren, it only took us 4 years to trigger this? Can people actually easily/reliably reproduce it? Heh, I am not sure about "people" but we @llnw can see this very reliably. Do you have any other theories/patches that we can try? It'd be helpful to understand your reservations about this patch. REVISION DETAIL https://reviews.freebsd.org/D1777 To: rrs, imp, sbruno, gnn, rwatson, lstewart, kostikbel, adrian, jhb, bz Cc: bz, emaste, hiren, julian, hselasky, freebsd-net From owner-freebsd-net@FreeBSD.ORG Sun Feb 8 20:48:48 2015 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 0A25F448 for ; Sun, 8 Feb 2015 20:48:48 +0000 (UTC) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9CB41902 for ; Sun, 8 Feb 2015 20:48:46 +0000 (UTC) Received: from charlemagne.a43.boland.org ([62.194.208.247]) by smtp-cloud2.xs4all.net with ESMTP id pwoj1p0095LoPm601wok4i; Sun, 08 Feb 2015 21:48:44 +0100 Message-ID: <54D7CBAB.9060907@xs4all.nl> Date: Sun, 08 Feb 2015 21:48:43 +0100 From: Michiel Boland User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: pcap sees its own frames Content-Type: text/plain; charset=utf-8; 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: Sun, 08 Feb 2015 20:48:48 -0000 Hi. It appears the when I send a frame with pcap_inject, and then do a pcap_next, I get back the same frame I just sent. Is there a way to turn this off? There is a BIOCFEEDBACK ioctl on the underlying bpf fd but that does not appear to have any effect. The reason I don't want this behaviour is that GNS3 does not work when connecting to a host via bpf; the router sees its own packets, which breaks things like IPv6 DAD, bridging, etc. Cheers Michiel From owner-freebsd-net@FreeBSD.ORG Sun Feb 8 22:24:41 2015 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 E9496D3 for ; Sun, 8 Feb 2015 22:24:41 +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 BC9D937C for ; Sun, 8 Feb 2015 22:24:41 +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 t18MOfMo024292 for ; Sun, 8 Feb 2015 22:24:41 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 t18MOfT2024291; Sun, 8 Feb 2015 22:24:41 GMT (envelope-from root) Date: Sun, 8 Feb 2015 22:24:41 +0000 To: freebsd-net@freebsd.org From: "davide (Davide Italiano)" Subject: [Differential] [Request, 15 lines] D1805: [sockbuf] Don't access fields directly, use accessor functions Message-ID: X-Priority: 3 Thread-Topic: D1805: [sockbuf] Don't access fields directly, use accessor functions X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Thread-Index: OWRjZTdmYWI1ODk3ZGNkOWIxYTAyYWM0MjY5 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, 08 Feb 2015 22:24:42 -0000 davide created this revision. davide added reviewers: kmacy, np, lstewart, rrs, rwatson. davide added a subscriber: freebsd-net. davide set the repository for this revision to rS (FreeBSD src repository). REVISION SUMMARY Small step towards a saner sockbuf abstraction REVISION DETAIL https://reviews.freebsd.org/D1805 AFFECTED FILES sys/kern/uipc_socket.c To: davide, kmacy, np, lstewart, rrs, rwatson Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Sun Feb 8 22:26:30 2015 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 E37752B9 for ; Sun, 8 Feb 2015 22:26:30 +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 BFB393C9 for ; Sun, 8 Feb 2015 22:26:30 +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 t18MQUhu025862 for ; Sun, 8 Feb 2015 22:26:30 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 t18MQUW0025861; Sun, 8 Feb 2015 22:26:30 GMT (envelope-from root) Date: Sun, 8 Feb 2015 22:26:30 +0000 To: freebsd-net@freebsd.org From: "davide (Davide Italiano)" Subject: [Differential] [Updated, 15 lines] D1805: [sockbuf] Don't access fields directly, use accessor functions Message-ID: X-Priority: 3 Thread-Topic: D1805: [sockbuf] Don't access fields directly, use accessor functions X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: OWRjZTdmYWI1ODk3ZGNkOWIxYTAyYWM0MjY5IFTX4pY= 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, 08 Feb 2015 22:26:31 -0000 davide updated this revision to Diff 3695. CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D1805?vs=3694&id=3695 REVISION DETAIL https://reviews.freebsd.org/D1805 AFFECTED FILES sys/kern/uipc_socket.c To: davide, kmacy, np, lstewart, rrs, rwatson Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Sun Feb 8 23:10:17 2015 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 0436DD9E; Sun, 8 Feb 2015 23:10:17 +0000 (UTC) Received: from mail.karels.net (mail.karels.net [63.231.190.5]) by mx1.freebsd.org (Postfix) with ESMTP id 706E9A11; Sun, 8 Feb 2015 23:10:16 +0000 (UTC) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.14.7/8.14.7) with ESMTP id t18MfjJc091202; Sun, 8 Feb 2015 16:41:47 -0600 (CST) (envelope-from mike@karels.net) Message-Id: <201502082241.t18MfjJc091202@mail.karels.net> From: Mike Karels To: Eric Joyner Reply-to: mike@karels.net Subject: Re: Fwd: Adding new media types to if_media.h In-reply-to: Your message of January 6, 2015 4:50:28 PM CST Date: Sun, 08 Feb 2015 16:41:45 -0600 Cc: Adrian Chadd , Rui Paulo , "freebsd-net@freebsd.org" , John Baldwin , Jack Vogel , "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: Sun, 08 Feb 2015 23:10:17 -0000 Sorry to reply to a thread after such a long delay, but I think it is unresolved, and needs more discussion. I'd like to elaborate a bit on my goals and proposal. I believe Adrian has newer thoughts than have been circulated here as well. The last message(s) have gone to freebsd-arch and freebsd-net. If someone wants to pick one, we could consolidate, but this seems relevant to both. I'm going to top-post to try to summarize and extend the discussion, but the preceding emails follow for reference. To recap: the existing if_media interface is running out of steam, at least in that the "Media variant" field, with 5 bits, is going to be insufficient to express existing 40 Gb/s variants. The if_media media type is a 32-bit int with a bunch of sub-fields for type (e.g. Ethernet), subtype/variant (e.g. 10baseT, 10base5, 1000baseT, etc), flags, and some MII-related fields. I made a proposal to extend the interface in a small way, specifically to replace the "media word" with a 64-bit int that is mostly the same, but has a new, larger variant/subtype field. The main reason for this proposal is to maintain the driver KPI (glimpse showed me 240 inclusions of if_media.h in the kernel in 8.2). That interface includes an initialization using a scalar value of fields ORed with each other. It would also be easy to preserve a 32-bit user-level API/ABI that can express most of the current state, with a subtype/variant field value reserved for "other" (there is already one for "unknown", but that is not quite the same). fwiw, I found 45 references to this user-level API in our tree, including both base and "ports"-type software, which includes libpcap, snmpd, dhclient, quagga, xorp, atm, devd, and rtsold, which argues for a backward-compatible API/ABI as well as a more-complete current interface for ifconfig at least. More generally, I see two problems with the existing if_media interface: 1. It doesn't have enough bits for all the fields, in particular, variant/ subtype for Ethernet. That is the immediate issue. 2. The interface is not sufficiently generic; it was designed around Ethernet including MII, token ring, FDDI, and a few other interface types. Some of the fields like "instance" are primarily for MII as far as I know, and are basically unused. It is definitely not sufficient for 802.11, which has rolled its own interfaces. To solve the second problem, I think the right approach would be to reduce this interface to a truly generic one, such as media type (e.g. Ethernet), generic flags, and perhaps generic status. Then there should be a separate media-specific interface for each type, such as Ethernet and 802.11. To a small extent, we already have that. Solving the second, more general problem, requires a whole new driver KPI that will require surgery to every driver, which is not an exercise that I would consider. Using a separate int for each existing field, as proposed, would break the driver KPI, but would not really make the interface generic. Trying to make a single interface with the union of all network interface requirements seems like a bad idea to me (we failed last time; the "we" is BSDi, where I was the architect when this interface was first designed). (No, I didn't design this interface.) Solving the first problem only, I think it is preferable to preserve a compatible driver KPI, which means using a scalar value encoding what is necessary. Although that interface is rather Ethernet-centric, that is really what it is used for. An additional, selfish goal is to make it easy to back-port drivers using the new interface to older versions (which I am quite likely to do). Preserving the KPI and general user API will be highly useful there. I'd be likely to do a 11-style version of ifconfig personally, but it might not be difficult to do in a more general way. I am willing to do a prototype for -current for evaluation. Comments, alternatives, ? Mike > From: Eric Joyner > Date: January 6, 2015 4:50:28 PM CST > To: mike@karels.net > Cc: Adrian Chadd , Rui Paulo , "freebsd-net@freebsd.org" , Eric Joyner , John Baldwin , Jack Vogel , "freebsd-arch@freebsd.org" > Subject: Re: Adding new media types to if_media.h > > Then going with what Mike says about leaving backwards compatibility, I > suppose we should do something like what Adrian suggested, and add a > separate struct. We can indicate that the separate struct exists by setting > the media type value in the if_media word to 0xc0, since that's the last > unused value. Then existing programs won't have to support any new features > if they don't want to. > > Adrian -- where can I look for more information on what net80211 does for > media types? Do you mean what it does with MCS values, or something more; > I've looked at it a bit, but I don't know very much about how Wi-Fi works. > > - Eric > > On Fri, Dec 12, 2014 at 5:06 PM, Mike Karels wrote: > >>> On Friday, December 12, 2014 12:26:24 PM Jack Vogel wrote: >>>> I think I'd go along with Mike, keeping it simpler seems like a good >> idea. >>>> >>>> Jack >> >>> If the userland ABI impact isn't too broad I think this is fine. Mike, >> do you >>> know off hand how many user-facing things would be affected? >> >> I didn't know off hand, but I have a glimpse index at $WORK (it's for >> McAfee >> Firewall Enterprise, aka Sidewinder, based on 8.2). I found 45 references >> to >> if_media.h at user level, including "ports" that we use, and excluding our >> own software. The list includes libpcap, snmpd, dhclient, quagga, xorp, >> atm, devd, and rtsold. fwiw, I found about 260 inclusions of if_media.h >> in the kernel. >> >> This suggests that we should preserve a backward-compatible user API, even >> if it has limits. Unfortunately, the media word I mentioned is a plain >> int, >> not a typedef. I would propose a similar API that is not limited, but easy >> to convert (e.g. using a new typedef). I'd be willing to sketch out >> something >> like that. >> >>>> On Fri, Dec 12, 2014 at 6:39 AM, Mike Karels wrote: >>>>>> Any other thoughts, or should I start looking at seeing what I can >> take >>>>>> copy from net80211? >>>>>> >>>>>> Also adding -net, since this is pretty relevant. >>>>> >>>>> I had the same reaction as Adrian initially, as an int with numerous >>>>> fields >>>>> seems really messy. However, I don't think we have the challenges of >>>>> 802.11, >>>>> and the only real problem is that the subtype field has run out of >> bits. >>>>> And both ifconfig and the drivers are cast in the form of a scalar >> "media >>>>> word", with parameters to ifmedia_add like IFM_ETHER | IFM_1000_T | >>>>> IFM_FDX >>>>> (assuming that all the bits are in a scalar). >>>>> >>>>> Instead, I would propose that we simply change the media word from >> 32 bits >>>>> to 64, and move the subtype from its current location to a new field >> (e.g. >>>>> 16 bits) in the new space. I believe this can be KPI compatible, >> and it >>>>> is relatively easy to provide a backward-compatible ABI. There >> should be >>>>> a reserved subtype for "other" that can be encoded in the existing >> field >>>>> for use when the subtype can't fit in the old field. This seems much >>>>> easier, >>>>> can be KPI compatible, and will make it much easier to backport >> drivers. >>>>> A backport could simply define the new subtypes as "other", and the >> KPI >>>>> would still be compatible. >>>>> >>>>> Thoughts? >>>>> >>>>> Mike >> >>> -- >>> John Baldwin >> >> Mike >> > _______________________________________________ > 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 Feb 9 00:04:13 2015 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 B83E58CC for ; Mon, 9 Feb 2015 00:04:13 +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 97807F17 for ; Mon, 9 Feb 2015 00:04:13 +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 t1904DEX041085 for ; Mon, 9 Feb 2015 00:04:13 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 t1904D2W041084; Mon, 9 Feb 2015 00:04:13 GMT (envelope-from root) Date: Mon, 9 Feb 2015 00:04:13 +0000 To: freebsd-net@freebsd.org From: "davide (Davide Italiano)" Subject: [Differential] [Updated, 12 lines] D1805: [sockbuf] Don't access fields directly, use accessor functions Message-ID: <392d01c0d7111c7fadaacd9d2e1db1cd@localhost.localdomain> X-Priority: 3 Thread-Topic: D1805: [sockbuf] Don't access fields directly, use accessor functions X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: OWRjZTdmYWI1ODk3ZGNkOWIxYTAyYWM0MjY5IFTX+X0= 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: Mon, 09 Feb 2015 00:04:13 -0000 davide updated this revision to Diff 3698. davide added a comment. Updated removing the last place where this was used. I was not certain about it before so I previously left it as-is, but it looks like in this case order doesn't matter considering we're holding the socket buffer lock across the two calls. CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D1805?vs=3695&id=3698 REVISION DETAIL https://reviews.freebsd.org/D1805 AFFECTED FILES sys/kern/uipc_socket.c To: davide, kmacy, np, lstewart, rrs, rwatson Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Mon Feb 9 00:53:59 2015 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 633C4B7F; Mon, 9 Feb 2015 00:53:59 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 4E7913C4; Mon, 9 Feb 2015 00:53:59 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 608FB341F90F; Sun, 8 Feb 2015 16:53:53 -0800 (PST) Message-ID: <54D805D1.4050008@freebsd.org> Date: Sun, 08 Feb 2015 16:56:49 -0800 From: Alfred Perlstein Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: mike@karels.net, Eric Joyner Subject: Re: Fwd: Adding new media types to if_media.h References: <201502082241.t18MfjJc091202@mail.karels.net> In-Reply-To: <201502082241.t18MfjJc091202@mail.karels.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , Rui Paulo , "freebsd-net@freebsd.org" , John Baldwin , Jack Vogel , "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: Mon, 09 Feb 2015 00:53:59 -0000 On 2/8/15 2:41 PM, Mike Karels wrote: > > To solve the second problem, I think the right approach would be to reduce > this interface to a truly generic one, such as media type (e.g. Ethernet), > generic flags, and perhaps generic status. Then there should be a separate > media-specific interface for each type, such as Ethernet and 802.11. To a > small extent, we already have that. Solving the second, more general problem, > requires a whole new driver KPI that will require surgery to every driver, > which is not an exercise that I would consider. > > > I am willing to do a prototype for -current for evaluation. > > Comments, alternatives, ? Mike, I think we have enough people to chip in that your concern about breaking the KPI is not as bad as you think. Would like to hear the first correct + long term + less hackish proposal first. Norse has a kernel team that is heavily invested in networking that can help with the transition. If done right, likely renaming ALL of the macros it will be quite trivial to catch all bad cases and move us forward in one great leap. -Alfred From owner-freebsd-net@FreeBSD.ORG Mon Feb 9 01:53:39 2015 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 C2ED7A6C for ; Mon, 9 Feb 2015 01:53:39 +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 A2A69ED1 for ; Mon, 9 Feb 2015 01:53:39 +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 t191rdJp001178 for ; Mon, 9 Feb 2015 01:53: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 t191rdG5001177; Mon, 9 Feb 2015 01:53:39 GMT (envelope-from root) Date: Mon, 9 Feb 2015 01:53:39 +0000 To: freebsd-net@freebsd.org From: "emaste (Ed Maste)" Subject: [Differential] [Changed Subscribers] D1805: [sockbuf] Don't access fields directly, use accessor functions Message-ID: <906bf595785b1eef54465148ad885a95@localhost.localdomain> X-Priority: 3 Thread-Topic: D1805: [sockbuf] Don't access fields directly, use accessor functions X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: OWRjZTdmYWI1ODk3ZGNkOWIxYTAyYWM0MjY5IFTYEyM= 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: Mon, 09 Feb 2015 01:53:39 -0000 emaste added a subscriber: emaste. REVISION DETAIL https://reviews.freebsd.org/D1805 To: davide, kmacy, np, lstewart, rrs, rwatson Cc: emaste, freebsd-net From owner-freebsd-net@FreeBSD.ORG Mon Feb 9 02:34:32 2015 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 CAADE91E for ; Mon, 9 Feb 2015 02:34:32 +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 AB7CE2D5 for ; Mon, 9 Feb 2015 02:34:32 +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 t192YWkS043901 for ; Mon, 9 Feb 2015 02:34:32 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 t192YWQY043900; Mon, 9 Feb 2015 02:34:32 GMT (envelope-from root) Date: Mon, 9 Feb 2015 02:34:32 +0000 To: freebsd-net@freebsd.org From: "davide (Davide Italiano)" Subject: [Differential] [Request, 14 lines] D1809: [sockbuf] Don't expose lock details when isn't needed Message-ID: X-Priority: 3 Thread-Topic: D1809: [sockbuf] Don't expose lock details when isn't needed X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Thread-Index: ZDUyNzQ5ZWQxMTRmZDFiNGM0NTM4Yzk5MDEw 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: Mon, 09 Feb 2015 02:34:32 -0000 davide created this revision. davide added reviewers: kmacy, np, rrs, lstewart, rwatson. davide added a subscriber: freebsd-net. davide set the repository for this revision to rS (FreeBSD src repository). REVISION DETAIL https://reviews.freebsd.org/D1809 AFFECTED FILES sys/dev/cxgbe/tom/t4_ddp.c sys/dev/iscsi/icl_soft.c sys/kern/uipc_sockbuf.c To: davide, kmacy, np, rrs, lstewart, rwatson Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Mon Feb 9 02:49:26 2015 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 8B45ABA5; Mon, 9 Feb 2015 02:49:26 +0000 (UTC) Received: from mail.karels.net (mail.karels.net [63.231.190.5]) by mx1.freebsd.org (Postfix) with ESMTP id 0DD563D2; Mon, 9 Feb 2015 02:49:25 +0000 (UTC) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.14.7/8.14.7) with ESMTP id t192nI96091798; Sun, 8 Feb 2015 20:49:18 -0600 (CST) (envelope-from mike@karels.net) Message-Id: <201502090249.t192nI96091798@mail.karels.net> To: Alfred Perlstein From: Mike Karels Reply-to: mike@karels.net Subject: Re: Fwd: Adding new media types to if_media.h In-reply-to: Your message of Sun, 08 Feb 2015 16:56:49 -0800. <54D805D1.4050008@freebsd.org> Date: Sun, 08 Feb 2015 20:49:18 -0600 Cc: Adrian Chadd , Rui Paulo , "freebsd-net@freebsd.org" , Eric Joyner , John Baldwin , Jack Vogel , "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: Mon, 09 Feb 2015 02:49:26 -0000 Alfred wrote: > On 2/8/15 2:41 PM, Mike Karels wrote: > > > > To solve the second problem, I think the right approach would be to reduce > > this interface to a truly generic one, such as media type (e.g. Ethernet), > > generic flags, and perhaps generic status. Then there should be a separate > > media-specific interface for each type, such as Ethernet and 802.11. To a > > small extent, we already have that. Solving the second, more general problem, > > requires a whole new driver KPI that will require surgery to every driver, > > which is not an exercise that I would consider. > > > > > > I am willing to do a prototype for -current for evaluation. > > > > Comments, alternatives, ? > Mike, > I think we have enough people to chip in that your concern about > breaking the KPI is not as bad as you think. > Would like to hear the first correct + long term + less hackish proposal > first. > Norse has a kernel team that is heavily invested in networking that can > help with the transition. > If done right, likely renaming ALL of the macros it will be quite > trivial to catch all bad cases and move us forward in one great leap. Don't forget that the KPI is not the only part. Breaking the user-level interface (API/ABI are almost the same) gets into ports and other important software that is harder to change. A new KPI could still provide a compatible API, but would be much constrained. And fwiw, I don't see the advantage to be gained unless the 802.11 software would be much improved. I'm not the one to weigh in on that. Mike From owner-freebsd-net@FreeBSD.ORG Mon Feb 9 03:45:57 2015 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 A55076FF; Mon, 9 Feb 2015 03:45:57 +0000 (UTC) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1B5E0C53; Mon, 9 Feb 2015 03:45:57 +0000 (UTC) Received: by iecrd18 with SMTP id rd18so1602163iec.8; Sun, 08 Feb 2015 19:45: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=ktt/HK4RMTZXQp75yruCb+atLFWMJmcGH8YZYBHyAP0=; b=LRa2zKbEa1YI4SbLWaYIq/XsYMVgI6JduUYniaMGNJS+Q0T7+Y6a2a07BtXshGdEMA rBFRysFk7a3vdTmjUk37EQCNPRxjP2gMRMa0XEuY2ndJksKxbTNEAD06Dr4dqmVtJp5g P8HExi78DPtBvAkUMT/QVUx+eBoND1/fYhr5zonyWs6CUXFIMW/rVuW4CUeOjN/VtuhD OtjTNLtVuGE25t6Wl0uqLxK588Ux3ixri2pg7SUKJjyawrLmUNIyZ2ORZ0lzQA+pJnPX vW3V/iyFk4cOb7uNohEMFNMJe6pEt41ylcGbnoCicCIHlSFhcOIs2yGDL2+Q+YZkC5IK d6pg== MIME-Version: 1.0 X-Received: by 10.50.93.70 with SMTP id cs6mr14523191igb.6.1423453556085; Sun, 08 Feb 2015 19:45:56 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.17.7 with HTTP; Sun, 8 Feb 2015 19:45:55 -0800 (PST) In-Reply-To: <201502090249.t192nI96091798@mail.karels.net> References: <54D805D1.4050008@freebsd.org> <201502090249.t192nI96091798@mail.karels.net> Date: Sun, 8 Feb 2015 19:45:55 -0800 X-Google-Sender-Auth: 8Byr6a0ac5s-R62D_nu5_aTw7d0 Message-ID: Subject: Re: Fwd: Adding new media types to if_media.h From: Adrian Chadd To: mike@karels.net Content-Type: text/plain; charset=UTF-8 Cc: Rui Paulo , "freebsd-net@freebsd.org" , Alfred Perlstein , Eric Joyner , John Baldwin , Jack Vogel , "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: Mon, 09 Feb 2015 03:45:57 -0000 Hey, don't worry about the wifi side of things - I have absolutely no requirement for backwards compatible API/ABI in the net80211 stack outside of "it makes my life as the maintainer painful." I'm happy to go churn it as part of this in order to get things looking better. (And I likely have to at some point in the future when 11ac support turns up.) -a On 8 February 2015 at 18:49, Mike Karels wrote: > Alfred wrote: >> On 2/8/15 2:41 PM, Mike Karels wrote: >> > >> > To solve the second problem, I think the right approach would be to reduce >> > this interface to a truly generic one, such as media type (e.g. Ethernet), >> > generic flags, and perhaps generic status. Then there should be a separate >> > media-specific interface for each type, such as Ethernet and 802.11. To a >> > small extent, we already have that. Solving the second, more general problem, >> > requires a whole new driver KPI that will require surgery to every driver, >> > which is not an exercise that I would consider. >> > >> > >> > I am willing to do a prototype for -current for evaluation. >> > >> > Comments, alternatives, ? >> Mike, > >> I think we have enough people to chip in that your concern about >> breaking the KPI is not as bad as you think. > >> Would like to hear the first correct + long term + less hackish proposal >> first. > >> Norse has a kernel team that is heavily invested in networking that can >> help with the transition. > >> If done right, likely renaming ALL of the macros it will be quite >> trivial to catch all bad cases and move us forward in one great leap. > > Don't forget that the KPI is not the only part. Breaking the user-level > interface (API/ABI are almost the same) gets into ports and other important > software that is harder to change. A new KPI could still provide a compatible > API, but would be much constrained. And fwiw, I don't see the advantage to > be gained unless the 802.11 software would be much improved. I'm not the > one to weigh in on that. > > Mike From owner-freebsd-net@FreeBSD.ORG Mon Feb 9 04:46:42 2015 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 618E61DD for ; Mon, 9 Feb 2015 04:46:42 +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 3BA2D274 for ; Mon, 9 Feb 2015 04:46:42 +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 t194T0A4015607 for ; Mon, 9 Feb 2015 04:29:00 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 t194T0Us015606; Mon, 9 Feb 2015 04:29:00 GMT (envelope-from root) Date: Mon, 9 Feb 2015 04:29:00 +0000 To: freebsd-net@freebsd.org From: "ae (Andrey V. Elsukov)" Subject: [Differential] [Changed Subscribers] D1777: Associated fix for arp/nd6 timer usage. Message-ID: X-Priority: 3 Thread-Topic: D1777: Associated fix for arp/nd6 timer usage. X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: N2Y2Y2VmY2ZjNTc1MTM4NTA3YmIzZDk3NmE4IFTYN4w= 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: Mon, 09 Feb 2015 04:46:42 -0000 ae added a subscriber: ae. ae added a comment. You said about some panics, do you have traces? REVISION DETAIL https://reviews.freebsd.org/D1777 To: rrs, imp, sbruno, gnn, rwatson, lstewart, kostikbel, adrian, jhb, bz Cc: ae, bz, emaste, hiren, julian, hselasky, freebsd-net From owner-freebsd-net@FreeBSD.ORG Mon Feb 9 07:46:26 2015 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 6C6259F2 for ; Mon, 9 Feb 2015 07:46:26 +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 2D6E47B2 for ; Mon, 9 Feb 2015 07:46:26 +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 t197kP2d048457 for ; Mon, 9 Feb 2015 07:46:25 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 t197kPhu048456; Mon, 9 Feb 2015 07:46:25 GMT (envelope-from root) Date: Mon, 9 Feb 2015 07:46:25 +0000 To: freebsd-net@freebsd.org From: "hiren (hiren panchasara)" Subject: [Differential] [Commented On] D1777: Associated fix for arp/nd6 timer usage. Message-ID: <05e25fc4a465625b549d81fbd67b628c@localhost.localdomain> X-Priority: 3 Thread-Topic: D1777: Associated fix for arp/nd6 timer usage. X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: N2Y2Y2VmY2ZjNTc1MTM4NTA3YmIzZDk3NmE4IFTYZdE= 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: Mon, 09 Feb 2015 07:46:26 -0000 hiren added a comment. It all started with: https://lists.freebsd.org/pipermail/freebsd-net/2014-September/039730.html Last (conclusive) email in that thread: https://lists.freebsd.org/pipermail/freebsd-net/2015-January/040895.html That issue was fixed by: https://reviews.freebsd.org/D1438 i.e. https://svnweb.freebsd.org/base?view=revision&revision=277213 That got reverted as it was not entirely correct/complete. And rrs@ started working on a better approach with https://reviews.freebsd.org/D1711 After applying D1711, we started seeing a bunch of other panics: panic #1 https://reviews.freebsd.org/D1711#54 panic #2 https://reviews.freebsd.org/D1711#55 panic #3 https://reviews.freebsd.org/D1711#56 And finally. after applying patch from this review D1777, we do not see any of the panics and machines seem happy. REVISION DETAIL https://reviews.freebsd.org/D1777 To: rrs, imp, sbruno, gnn, rwatson, lstewart, kostikbel, adrian, jhb, bz Cc: ae, bz, emaste, hiren, julian, hselasky, freebsd-net From owner-freebsd-net@FreeBSD.ORG Mon Feb 9 15:56:51 2015 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 CB1238ED for ; Mon, 9 Feb 2015 15:56:51 +0000 (UTC) Received: from mail.premiumlistz.com (MAIL.PREMIUMLISTZ.COM [125.99.254.10]) by mx1.freebsd.org (Postfix) with ESMTP id DF34836A for ; Mon, 9 Feb 2015 15:56:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.premiumlistz.com (Postfix) with ESMTP id DB39E9836D7 for ; Mon, 9 Feb 2015 21:18:36 +0530 (IST) Received: from mail.premiumlistz.com ([127.0.0.1]) by localhost (mail.localdomain [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Su3C41NaHvDy for ; Mon, 9 Feb 2015 21:18:36 +0530 (IST) Received: from WSC45 (unknown [125.99.254.3]) by mail.premiumlistz.com (Postfix) with ESMTPA id 7C43F9836C5 for ; Mon, 9 Feb 2015 21:18:36 +0530 (IST) From: "Adriana Parker" To: Subject: Label & Package 2015 Date: Mon, 9 Feb 2015 07:49:31 -0800 Message-ID: <086c01d04480$0140a1e0$03c1e5a0$@com> MIME-Version: 1.0 X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdBEf/kexit2BTIpQieaew5vAIXLMg== Content-Language: en-us Importance: High Content-Type: text/plain; charset="us-ascii" 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: Mon, 09 Feb 2015 15:56:51 -0000 Hello , Would you be interested in acquiring contacts from Label & Package Printing Industry Lists 2015? Which includes complete verified email addresses of - All Key Decision makers List, All C-level executives List of - Manufacturers, Packaging Professionals, Food & Beverages Manufacturers, Web printing Companies, Overprinting & Inspection Professionals, Pre-press, Radio frequency Professionals, Security Managers, Industrial Production Managers, Food Batch makers, Book/Magazines Publishers, Equipment Manufacturers, Foil Manufacturers, Rubber & Plastic Manufacturers, Graphic Designers, Supply & logistics Managers, Product development managers, Buyers, Suppliers, Importers/Exporters and many more! across US/UK/Global. Our List Includes : Label printers/converters Flexible packaging printers/converters Folding carton printers/converters Packaging printers/converters General printers/converters Brand owners Label designers Industry suppliers and many more.. If your target audience is not mentioned above, kindly let me know. Kindly, confirm your exact target audience (Target Industry/Geography/ Job Titles) so that we can send you few sample records for your internal review. Looking forward to connect with you! Thanks, Adriana Parker | Inside Sales Global E-mail lists We are expertise in:- B2B and B2C Email List, Email Appending, Reverse Appending, Email Campaign, Data Appending, Fax Appending, Phone Appending Services. From owner-freebsd-net@FreeBSD.ORG Mon Feb 9 16:37:49 2015 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 05A75B58 for ; Mon, 9 Feb 2015 16:37:49 +0000 (UTC) Received: from a0i241.smtpcorp.com (a0i241.smtpcorp.com [216.22.15.73]) (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 D640BA85 for ; Mon, 9 Feb 2015 16:37:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smtpcorp.com; s=a0_1; h=Feedback-ID:X-Smtpcorp-Track:Message-ID:Date:Subject:To:From; bh=2uY1JXDe/hLUYh2F5Pd/ly/5ihwoNlpdQ6DZFQPpiHA=; b=kc+ZHVmWxzb4cjXb4U/dL/hVXa0liMkjRmM37BRHmnLHZ/5C8UDJIk6WQSkwG6xs4Lw+CUOveDwTsOEE+g5WFSdyL4/olCZfWNnGI7wDw52hmEvF0BveJJufLW9gHZ5lI3sRZ+5H3Cr/11Ij/Ns7IrmwHRjDAMEYYXJ1WUHJGzQ=; From: Daniel Corbe To: freebsd-net@freebsd.org Subject: ifconfig greX create disables IPv6 forwarding Date: Mon, 09 Feb 2015 11:34:02 -0500 Message-ID: <87h9uvjb7p.fsf@corbe.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Smtpcorp-Track: 1YKrHfmkf1sC8j.2OF6pL6gn Feedback-ID: 10661m:10661aegzayD:10661spkeXnS2L1:SMTPCORP 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, 09 Feb 2015 16:37:49 -0000 For some reason, every time I create a GRE interface on a FreeBSD IPv6 gateway, net.inet6.ip6.forwarding is disabled. As long as I manually re-enable it with sysctl, both the GRE tunnel and the IPv6 network behind this machine will continue to work; however, it's certainly far from ideal. There's nothing in the log to indicate exactly what's going on here: Feb 9 11:23:08 router rtadvd[27251]: interface added (idx=8) Feb 9 11:23:08 router devd: Executing '/etc/pccard_ether gre0 start' Feb 9 11:23:21 router rtadvd[27251]: non-zero lifetime RA but net.inet6.ip6.forwarding=0. Ignored. Feb 9 11:23:53 router last message repeated 2 times Nor is there anything about it in dmesg. # uname -a FreeBSD router.corbe.net 10.1-RELEASE FreeBSD 10.1-RELEASE #0 r274401: Tue Nov 11 21:02:49 UTC 2014 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 -DAniel From owner-freebsd-net@FreeBSD.ORG Mon Feb 9 17:00:31 2015 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 B0F1D677 for ; Mon, 9 Feb 2015 17:00:31 +0000 (UTC) Received: from smtp2.mail.clearhost.co.uk (smtp2.mail.clearhost.co.uk [IPv6:2001:1420::25:102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.mail.clearhost.co.uk", Issuer "RapidSSL CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7AB3ECF9 for ; Mon, 9 Feb 2015 17:00:31 +0000 (UTC) Received: from [2001:1420:a:105:c62c:3ff:fe2f:bf] (port=52738 helo=parsnip.heronsbrook.org.uk) by smtp2.mail.clearhost.co.uk with esmtpa (Exim 4.76 (FreeBSD)) (envelope-from ) id 1YKrhE-000Cwj-1Q for freebsd-net@freebsd.org; Mon, 09 Feb 2015 17:00:28 +0000 Message-ID: <54D8E7AC.3080006@prt.org> Date: Mon, 09 Feb 2015 17:00:28 +0000 From: Paul Thornton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: ifconfig greX create disables IPv6 forwarding References: <87h9uvjb7p.fsf@corbe.net> In-Reply-To: <87h9uvjb7p.fsf@corbe.net> 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, 09 Feb 2015 17:00:31 -0000 On 09/02/2015 16:34, Daniel Corbe wrote: > > For some reason, every time I create a GRE interface on a FreeBSD IPv6 > gateway, net.inet6.ip6.forwarding is disabled. As long as I manually > re-enable it with sysctl, both the GRE tunnel and the IPv6 network > behind this machine will continue to work; however, it's certainly far > from ideal. I stumbled acro I discovered this in January. See this thread: http://lists.freebsd.org/pipermail/freebsd-net/2015-January/040797.html Are you enabling forwarding using ipv6_gateway_enable in rc.conf, or are you just setting net.inet6.ip6.forwarding to 1 in sysctl.conf? devd gets involved running /etc/rc.d/netif start and that seems to check (and set) the forwarding sysctls based on the rc.conf entries - so if you've set them "manually" they get reset when a new interface is brought up. Adding ipv6_gateway_enable="YES" in /etc/rc.conf should fix this. Paul. From owner-freebsd-net@FreeBSD.ORG Mon Feb 9 19:43:34 2015 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 5A062857 for ; Mon, 9 Feb 2015 19:43:34 +0000 (UTC) Received: from a0i241.smtpcorp.com (a0i241.smtpcorp.com [216.22.15.73]) (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 32EF7380 for ; Mon, 9 Feb 2015 19:43:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smtpcorp.com; s=a0_1; h=Feedback-ID:X-Smtpcorp-Track:Message-ID:Date:Subject:To:From; bh=OEREhS696AB9sbB8MI4yxQ/45ot0acGGgCPs7jCmY8w=; b=J57vR/d8aUL4sDxQK30VsXoGK27jw88iKFviJmX/PgTJ8nfKud3Hdl7X4d+5Lpsxjz4sYdhXfpu3e6VtQ0u5M0bpDzSEOD0URNDz6ZAMsnW4BH+LwCmoFju5UUk5l1j7SvdGc2KKG81H7O/hGRlCMwD+3+G+RSnGBqbTpVlXBTM=; From: Daniel Corbe To: Paul Thornton Subject: Re: ifconfig greX create disables IPv6 forwarding References: <87h9uvjb7p.fsf@corbe.net> <54D8E7AC.3080006@prt.org> Date: Mon, 09 Feb 2015 14:43:33 -0500 In-Reply-To: <54D8E7AC.3080006@prt.org> (Paul Thornton's message of "Mon, 09 Feb 2015 17:00:28 +0000") Message-ID: <87lhk6j2fu.fsf@corbe.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Smtpcorp-Track: 1YKIF24gfNYZTr.2Q3_gHw4W Feedback-ID: 10661m:10661aegzayD:10661sGXnLjBGZ4:SMTPCORP 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, 09 Feb 2015 19:43:34 -0000 Paul Thornton writes: > On 09/02/2015 16:34, Daniel Corbe wrote: >> >> For some reason, every time I create a GRE interface on a FreeBSD IPv6 >> gateway, net.inet6.ip6.forwarding is disabled. As long as I manually >> re-enable it with sysctl, both the GRE tunnel and the IPv6 network >> behind this machine will continue to work; however, it's certainly far >> from ideal. > I stumbled acro > > I discovered this in January. See this thread: > > http://lists.freebsd.org/pipermail/freebsd-net/2015-January/040797.html > > Are you enabling forwarding using ipv6_gateway_enable in rc.conf, or > are you just setting net.inet6.ip6.forwarding to 1 in sysctl.conf? > > devd gets involved running /etc/rc.d/netif start and that seems to > check (and set) the forwarding sysctls based on the rc.conf entries - > so if you've set them "manually" they get reset when a new interface > is brought up. > > Adding ipv6_gateway_enable="YES" in /etc/rc.conf should fix this. > Embarrassingly enough, the problem wound up being I had ipv6_enable_gateway instead of ipv6_gateway_enable. I'm also setting net.inet6.ip6.forwarding=1 manually in sysctl.conf so that's sort of why it ever worked to begin with. Thanks though. Some times all you need is a second set of eyes on a problem. -Daniel From owner-freebsd-net@FreeBSD.ORG Mon Feb 9 21:04:00 2015 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 B30A0927 for ; Mon, 9 Feb 2015 21:04:00 +0000 (UTC) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) (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 87395E82 for ; Mon, 9 Feb 2015 21:04:00 +0000 (UTC) Received: from global-1-26.nat.csx.cam.ac.uk ([131.111.184.26]:30923 helo=[172.16.19.1]) by vps.hungerhost.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1YKvUs-0006z8-Bb; Mon, 09 Feb 2015 16:03:58 -0500 From: "George Neville-Neil" To: "Olivier =?utf-8?q?Cochard-Labb=C3=A9?=" Subject: Re: IEE1588/PTP support for NIC drivers ? Date: Mon, 09 Feb 2015 21:03:57 +0000 Message-ID: <06B0AFC5-A68A-4F1C-A0CD-2BAFD09E3F6B@neville-neil.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9r5054) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com 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, 09 Feb 2015 21:04:00 -0000 On 5 Feb 2015, at 20:50, Olivier Cochard-Labbé wrote: > Hi, > > Some network cards support IEE1588 hardware timestamp (like some Intel > card), but their drivers didn't support this feature. > I beleive there is a kernel feature missing for this suppport. > > Searching on the archive's mailing-list, I've found this post about > some > legal issue: > https://lists.freebsd.org/pipermail/freebsd-net/2007-October/015512.html > > Is still a legal problem or just a missing feature ? > Missing feature. We need an API and the like to get this going. I've taken various stabs at it in the past and will likely do so again but if anyone has working code I'd be more than happy to review. Best, George From owner-freebsd-net@FreeBSD.ORG Mon Feb 9 21:08:48 2015 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 B996CA01; Mon, 9 Feb 2015 21:08:48 +0000 (UTC) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) (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 8B7E5EB8; Mon, 9 Feb 2015 21:08:48 +0000 (UTC) Received: from global-1-26.nat.csx.cam.ac.uk ([131.111.184.26]:45145 helo=[172.16.19.1]) by vps.hungerhost.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1YKvZT-0007mC-Ce; Mon, 09 Feb 2015 16:08:43 -0500 From: "George Neville-Neil" To: "Mike Karels" Subject: Re: Adding new media types to if_media.h Date: Mon, 09 Feb 2015 21:08:41 +0000 Message-ID: In-Reply-To: <201502082241.t18MfjJc091202@mail.karels.net> References: <201502082241.t18MfjJc091202@mail.karels.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9r5054) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com Cc: Adrian Chadd , Rui Paulo , "freebsd-net@freebsd.org" , Eric Joyner , John Baldwin , Jack Vogel , "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: Mon, 09 Feb 2015 21:08:48 -0000 On 8 Feb 2015, at 22:41, Mike Karels wrote: > Sorry to reply to a thread after such a long delay, but I think it is > unresolved, and needs more discussion. I'd like to elaborate a bit on > my goals and proposal. I believe Adrian has newer thoughts than have > been > circulated here as well. > > The last message(s) have gone to freebsd-arch and freebsd-net. If > someone > wants to pick one, we could consolidate, but this seems relevant to > both. > > I'm going to top-post to try to summarize and extend the discussion, > but the > preceding emails follow for reference. > > To recap: the existing if_media interface is running out of steam, at > least > in that the "Media variant" field, with 5 bits, is going to be > insufficient > to express existing 40 Gb/s variants. The if_media media type is a > 32-bit > int with a bunch of sub-fields for type (e.g. Ethernet), > subtype/variant > (e.g. 10baseT, 10base5, 1000baseT, etc), flags, and some MII-related > fields. > > I made a proposal to extend the interface in a small way, specifically > to > replace the "media word" with a 64-bit int that is mostly the same, > but > has a new, larger variant/subtype field. The main reason for this > proposal > is to maintain the driver KPI (glimpse showed me 240 inclusions of > if_media.h > in the kernel in 8.2). That interface includes an initialization > using a > scalar value of fields ORed with each other. It would also be easy to > preserve a 32-bit user-level API/ABI that can express most of the > current > state, with a subtype/variant field value reserved for "other" (there > is > already one for "unknown", but that is not quite the same). fwiw, I > found 45 references to this user-level API in our tree, including both > base and "ports"-type software, which includes libpcap, snmpd, > dhclient, > quagga, xorp, atm, devd, and rtsold, which argues for a > backward-compatible > API/ABI as well as a more-complete current interface for ifconfig at > least. > > More generally, I see two problems with the existing if_media > interface: > > 1. It doesn't have enough bits for all the fields, in particular, > variant/ > subtype for Ethernet. That is the immediate issue. > > 2. The interface is not sufficiently generic; it was designed around > Ethernet > including MII, token ring, FDDI, and a few other interface types. > Some of > the fields like "instance" are primarily for MII as far as I know, and > are > basically unused. It is definitely not sufficient for 802.11, which > has > rolled its own interfaces. > > To solve the second problem, I think the right approach would be to > reduce > this interface to a truly generic one, such as media type (e.g. > Ethernet), > generic flags, and perhaps generic status. Then there should be a > separate > media-specific interface for each type, such as Ethernet and 802.11. > To a > small extent, we already have that. Solving the second, more general > problem, > requires a whole new driver KPI that will require surgery to every > driver, > which is not an exercise that I would consider. > > Using a separate int for each existing field, as proposed, would break > the > driver KPI, but would not really make the interface generic. Trying > to > make a single interface with the union of all network interface > requirements > seems like a bad idea to me (we failed last time; the "we" is BSDi, > where > I was the architect when this interface was first designed). (No, I > didn't > design this interface.) > > Solving the first problem only, I think it is preferable to preserve a > compatible driver KPI, which means using a scalar value encoding what > is > necessary. Although that interface is rather Ethernet-centric, that > is > really what it is used for. > > An additional, selfish goal is to make it easy to back-port drivers > using > the new interface to older versions (which I am quite likely to do). > Preserving the KPI and general user API will be highly useful there. > I'd be likely to do a 11-style version of ifconfig personally, but it > might not be difficult to do in a more general way. > > I am willing to do a prototype for -current for evaluation. > > Comments, alternatives, ? I agree with your statements above and I'd like to see the prototype. Best, George > > Mike > >> From: Eric Joyner >> Date: January 6, 2015 4:50:28 PM CST >> To: mike@karels.net >> Cc: Adrian Chadd , Rui Paulo , >> "freebsd-net@freebsd.org" , Eric Joyner >> , John Baldwin , Jack Vogel >> , "freebsd-arch@freebsd.org" >> >> Subject: Re: Adding new media types to if_media.h >> >> Then going with what Mike says about leaving backwards compatibility, >> I >> suppose we should do something like what Adrian suggested, and add a >> separate struct. We can indicate that the separate struct exists by >> setting >> the media type value in the if_media word to 0xc0, since that's the >> last >> unused value. Then existing programs won't have to support any new >> features >> if they don't want to. >> >> Adrian -- where can I look for more information on what net80211 does >> for >> media types? Do you mean what it does with MCS values, or something >> more; >> I've looked at it a bit, but I don't know very much about how Wi-Fi >> works. >> >> - Eric >> >> On Fri, Dec 12, 2014 at 5:06 PM, Mike Karels wrote: >> >>>> On Friday, December 12, 2014 12:26:24 PM Jack Vogel wrote: >>>>> I think I'd go along with Mike, keeping it simpler seems like a >>>>> good >>> idea. >>>>> >>>>> Jack >>> >>>> If the userland ABI impact isn't too broad I think this is fine. >>>> Mike, >>> do you >>>> know off hand how many user-facing things would be affected? >>> >>> I didn't know off hand, but I have a glimpse index at $WORK (it's >>> for >>> McAfee >>> Firewall Enterprise, aka Sidewinder, based on 8.2). I found 45 >>> references >>> to >>> if_media.h at user level, including "ports" that we use, and >>> excluding our >>> own software. The list includes libpcap, snmpd, dhclient, quagga, >>> xorp, >>> atm, devd, and rtsold. fwiw, I found about 260 inclusions of >>> if_media.h >>> in the kernel. >>> >>> This suggests that we should preserve a backward-compatible user >>> API, even >>> if it has limits. Unfortunately, the media word I mentioned is a >>> plain >>> int, >>> not a typedef. I would propose a similar API that is not limited, >>> but easy >>> to convert (e.g. using a new typedef). I'd be willing to sketch out >>> something >>> like that. >>> >>>>> On Fri, Dec 12, 2014 at 6:39 AM, Mike Karels >>>>> wrote: >>>>>>> Any other thoughts, or should I start looking at seeing what I >>>>>>> can >>> take >>>>>>> copy from net80211? >>>>>>> >>>>>>> Also adding -net, since this is pretty relevant. >>>>>> >>>>>> I had the same reaction as Adrian initially, as an int with >>>>>> numerous >>>>>> fields >>>>>> seems really messy. However, I don't think we have the >>>>>> challenges of >>>>>> 802.11, >>>>>> and the only real problem is that the subtype field has run out >>>>>> of >>> bits. >>>>>> And both ifconfig and the drivers are cast in the form of a >>>>>> scalar >>> "media >>>>>> word", with parameters to ifmedia_add like IFM_ETHER | IFM_1000_T >>>>>> | >>>>>> IFM_FDX >>>>>> (assuming that all the bits are in a scalar). >>>>>> >>>>>> Instead, I would propose that we simply change the media word >>>>>> from >>> 32 bits >>>>>> to 64, and move the subtype from its current location to a new >>>>>> field >>> (e.g. >>>>>> 16 bits) in the new space. I believe this can be KPI compatible, >>> and it >>>>>> is relatively easy to provide a backward-compatible ABI. There >>> should be >>>>>> a reserved subtype for "other" that can be encoded in the >>>>>> existing >>> field >>>>>> for use when the subtype can't fit in the old field. This seems >>>>>> much >>>>>> easier, >>>>>> can be KPI compatible, and will make it much easier to backport >>> drivers. >>>>>> A backport could simply define the new subtypes as "other", and >>>>>> the >>> KPI >>>>>> would still be compatible. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> Mike >>> >>>> -- >>>> John Baldwin >>> >>> Mike >>> >> _______________________________________________ >> 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-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to > "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Feb 9 21:22:22 2015 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 6CF2AE47; Mon, 9 Feb 2015 21:22:22 +0000 (UTC) Received: from mail.myota.org (mail.myota.org [85.10.206.105]) by mx1.freebsd.org (Postfix) with ESMTP id D1D9DEC; Mon, 9 Feb 2015 21:22:21 +0000 (UTC) Received: from mobile.client (224.136.167.190.d.dyn.codetel.net.do [190.167.136.224] (may be forged)) (authenticated bits=128) by mail.myota.org (8.14.9/8.14.9) with ESMTP id t19LLuQF011215; Mon, 9 Feb 2015 22:22:00 +0100 (CET) (envelope-from andre@fbsd.ata.myota.org) Received: from submit.client ([127.0.0.1]) by schlappy.local (8.14.9/8.14.9) with ESMTP id t19LLVPE032673; Mon, 9 Feb 2015 22:21:33 +0100 (CET) (envelope-from andre@fbsd.ata.myota.org) Received: (from user@localhost) by schlappy.local (8.14.9/8.14.9/Submit) id t19LLVWE032672; Mon, 9 Feb 2015 22:21:31 +0100 (CET) (envelope-from andre@fbsd.ata.myota.org) Date: Mon, 9 Feb 2015 22:21:31 +0100 From: Andre Albsmeier To: Freddie Cash Subject: Re: Problems with IP fragments (was: Problems with DNSSEC -- answer in fragmented UDP doesn't work) Message-ID: <20150209212131.GA32613@schlappy> References: <54C918D2.7090805@FreeBSD.org> <54C91E80.7020407@infracaninophile.co.uk> <54C92222.6000201@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Echelon: Secret, anarchy, UHF, S/Key, Compsec X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Not delayed on 85.10.206.105, ACL: AUTH(59), Origin: DO, OS: FreeBSD 9.x or newer X-Virus-Scanned: clamav-milter 0.98.6 at colo X-Virus-Status: Clean Cc: freebsd-net , lev@freebsd.org, Matthew Seaman 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, 09 Feb 2015 21:22:22 -0000 On Wed, 28-Jan-2015 at 10:04:57 -0800, Freddie Cash wrote: > On Wed, Jan 28, 2015 at 9:53 AM, Lev Serebryakov wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > On 28.01.2015 20:38, Matthew Seaman wrote: > > > > > What do you get if you run the reply size test at DNS-OARC ? > > > > > > https://www.dns-oarc.net/oarc/services/replysizetest > > 0 lines (empty answer) at CURRENT, only "rst.x1013.rs.dns-oarc.net." > > on 9.3. > > > > Looks like "IP Fragments Filtered", but I don't understand — why and > > where?! > > > > I'm using ipfw on both hosts, but I don't have any special rules > > about IP fragments at all! And as these systems are in completely > > different networks, with different uplinks and FreeBSD versions! > > > > ​IPFW doesn't deal with IP fragment reassembly by default. > > You can add something like the following to the start of the IPFW ruleset > to work around it (one for each NIC): > > ​$IPFW add reass ip from any to any in recv $NIC0 > ​$IPFW add reass ip from any to any in recv $NIC1 The ipfw man page says: Usually a simple rule like: # reassemble incoming fragments ipfw add reass all from any to any in is all you need at the beginning of your ruleset. However, I could never make this work. It eats all fragments but the resulting final packet never makes it. I am back to ipfw -q add 1 pass udp from any to $myip frag in recv $ifc as I need it only for UDP. Frag reassembly in pf works well on the other hand... -Andre > ... > > -- > Freddie Cash > fjwcash@gmail.com > _______________________________________________ > 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" -- A fool with a tool is still a fool. From owner-freebsd-net@FreeBSD.ORG Mon Feb 9 23:20:10 2015 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 9B9ED84B for ; Mon, 9 Feb 2015 23:20:10 +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 7E606F36 for ; Mon, 9 Feb 2015 23:20:10 +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 t19NKAVA046268 for ; Mon, 9 Feb 2015 23:20:10 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 t19NKAp9046267; Mon, 9 Feb 2015 23:20:10 GMT (envelope-from root) Date: Mon, 9 Feb 2015 23:20:10 +0000 To: freebsd-net@freebsd.org From: "kristof (Kristof Provost)" Subject: [Differential] [Updated] D1767: Refragment packets after defragmenting them in PF Message-ID: <3f30da505dc192f15755ee668ed3d443@localhost.localdomain> X-Priority: 3 Thread-Topic: D1767: Refragment packets after defragmenting them in PF X-Herald-Rules: none X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NWYyMjc0NjgyNTdhMmMwM2FiOGUzN2QzYjU1IFTZQKo= 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: Mon, 09 Feb 2015 23:20:10 -0000 kristof added a revision: D1815: Evaluate packet size after the firewall had its chance. REVISION DETAIL https://reviews.freebsd.org/D1767 To: kristof Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Mon Feb 9 23:21:29 2015 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 268C08F5 for ; Mon, 9 Feb 2015 23:21:29 +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 09887FE4 for ; Mon, 9 Feb 2015 23:21:29 +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 t19NLS3v048383 for ; Mon, 9 Feb 2015 23:21:28 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 t19NLSrG048382; Mon, 9 Feb 2015 23:21:28 GMT (envelope-from root) Date: Mon, 9 Feb 2015 23:21:28 +0000 To: freebsd-net@freebsd.org From: "kristof (Kristof Provost)" Subject: [Differential] [Updated, 98 lines] D1767: Refragment packets after defragmenting them in PF Message-ID: <106a5cb00d14512e754ff754bb15706b@localhost.localdomain> X-Priority: 3 Thread-Topic: D1767: Refragment packets after defragmenting them in PF X-Herald-Rules: none X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NWYyMjc0NjgyNTdhMmMwM2FiOGUzN2QzYjU1IFTZQPg= 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: Mon, 09 Feb 2015 23:21:29 -0000 kristof updated this revision to Diff 3714. CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D1767?vs=3621&id=3714 REVISION DETAIL https://reviews.freebsd.org/D1767 AFFECTED FILES sys/net/pfvar.h sys/netpfil/pf/pf.c sys/netpfil/pf/pf.h sys/netpfil/pf/pf_mtag.h sys/netpfil/pf/pf_norm.c To: kristof Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Mon Feb 9 23:22:19 2015 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 E3B56ACC for ; Mon, 9 Feb 2015 23:22:19 +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 C63BAFFD for ; Mon, 9 Feb 2015 23:22:19 +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 t19NMJZG049768 for ; Mon, 9 Feb 2015 23:22:19 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 t19NMJdn049767; Mon, 9 Feb 2015 23:22:19 GMT (envelope-from root) Date: Mon, 9 Feb 2015 23:22:19 +0000 To: freebsd-net@freebsd.org From: "kristof (Kristof Provost)" Subject: [Differential] [Changed Subscribers] D1815: Evaluate packet size after the firewall had its chance Message-ID: X-Priority: 3 Thread-Topic: D1815: Evaluate packet size after the firewall had its chance X-Herald-Rules: none X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: MjRmMGVhNTZkOThiOTc4ZWRjYjYzYzAwNzU4IFTZQSs= 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: Mon, 09 Feb 2015 23:22:20 -0000 kristof added a subscriber: freebsd-net. REVISION DETAIL https://reviews.freebsd.org/D1815 To: kristof Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Feb 10 00:39:46 2015 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 7C42F1D9 for ; Tue, 10 Feb 2015 00:39: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 5C7B21F5 for ; Tue, 10 Feb 2015 00:39: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 t1A0dkvK029898 for ; Tue, 10 Feb 2015 00:39: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 t1A0dkDJ029897; Tue, 10 Feb 2015 00:39:46 GMT (envelope-from root) Date: Tue, 10 Feb 2015 00:39:46 +0000 To: freebsd-net@freebsd.org From: "ae (Andrey V. Elsukov)" Subject: [Differential] [Changed Subscribers] D1815: Evaluate packet size after the firewall had its chance Message-ID: X-Priority: 3 Thread-Topic: D1815: Evaluate packet size after the firewall had its chance X-Herald-Rules: none X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: MjRmMGVhNTZkOThiOTc4ZWRjYjYzYzAwNzU4IFTZU1I= 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: Tue, 10 Feb 2015 00:39:46 -0000 ae added a subscriber: ae. ae added a comment. Since you are in ip6_forward(), this means ip6_input() has already checked this packet and PFIL had a chance to handle this packet. IPv6 router should not do reassembling fragmented packets and do new fragmentation of them, but if you want, I think your packet filter should track these fragments on input. How do you tested this patch? REVISION DETAIL https://reviews.freebsd.org/D1815 To: kristof Cc: ae, freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Feb 10 08:48:20 2015 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 01E7AEDE for ; Tue, 10 Feb 2015 08:48:20 +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 D4AC4953 for ; Tue, 10 Feb 2015 08:48:19 +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 t1A8mISl010947 for ; Tue, 10 Feb 2015 08:48:18 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 t1A8mIUb010946; Tue, 10 Feb 2015 08:48:18 GMT (envelope-from root) Date: Tue, 10 Feb 2015 08:48:18 +0000 To: freebsd-net@freebsd.org From: "kristof (Kristof Provost)" Subject: [Differential] [Commented On] D1815: Evaluate packet size after the firewall had its chance Message-ID: X-Priority: 3 Thread-Topic: D1815: Evaluate packet size after the firewall had its chance X-Herald-Rules: none X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: MjRmMGVhNTZkOThiOTc4ZWRjYjYzYzAwNzU4IFTZxdI= 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: Tue, 10 Feb 2015 08:48:20 -0000 kristof added a comment. >>! In D1815#3, @ae wrote: > Since you are in ip6_forward(), this means ip6_input() has already checked this packet and PFIL had a chance to handle this packet. > IPv6 router should not do reassembling fragmented packets and do new fragmentation of them, but if you want, I think your packet filter should track these fragments on input. The defragmentation is done on the input side. When fragmented packets arrive we queue them up inside pf (telling the network stack we dropped them) on the input side. Once we've got a complete packet we can perform the actual filtering (which has to be done on the full packet or the firewall could be bypassed by fragmenting packets). At that point we have an oversized packet which somehow has to be sent out again. As netpfil doesn't have a way to tell the network stack 'Here are a bunch of packets' the only way I can see is to call ip6_forward(). > How do you tested this patch? The actual defragmentation was tested by generating packets with scapy. The forwarding path mostly by having a VM forward packets. The patch set is also running on my (dual stack, VIMAGE enabled) gateway. REVISION DETAIL https://reviews.freebsd.org/D1815 To: kristof Cc: ae, freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Feb 10 10:49:31 2015 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 D5D8D61E for ; Tue, 10 Feb 2015 10:49:31 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9553F937 for ; Tue, 10 Feb 2015 10:49:31 +0000 (UTC) Received: from [IPv6:2001:470:923f:2:943d:72c8:c2e8:4132] (unknown [IPv6:2001:470:923f:2:943d:72c8:c2e8:4132]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 4901456401; Tue, 10 Feb 2015 13:49:20 +0300 (MSK) Message-ID: <54D9E233.1010702@FreeBSD.org> Date: Tue, 10 Feb 2015 13:49:23 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Andre Albsmeier , Freddie Cash Subject: Re: Problems with IP fragments References: <54C918D2.7090805@FreeBSD.org> <54C91E80.7020407@infracaninophile.co.uk> <54C92222.6000201@FreeBSD.org> <20150209212131.GA32613@schlappy> In-Reply-To: <20150209212131.GA32613@schlappy> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: freebsd-net , Matthew Seaman 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, 10 Feb 2015 10:49:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10.02.2015 00:21, Andre Albsmeier wrote: > The ipfw man page says: > > Usually a simple rule like: > > # reassemble incoming fragments ipfw add reass all from any to any > in > > is all you need at the beginning of your ruleset. > > However, I could never make this work. It eats all fragments but > the resulting final packet never makes it. I am back to > > ipfw -q add 1 pass udp from any to $myip frag in recv $ifc > > as I need it only for UDP. Frag reassembly in pf works well on the > other hand... reass works for me, but kills all IPv6 packets, so it should be "reass ip4 from any to any in [recv $iface]" - -- // Lev Serebryakov AKA Black Lion -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU2eIyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePBe8P/3DNcYMcf/2jwKEQjV+FFdd9 p9p/SVbsHlXAW1TyMXQWua+gBVFCdz+Ks1ff4F7cg/g1b24GOkmNzmzvgZRQ4cbt 4hHn8exNNPvJg/9/UzXfB73f6VPihRqeMA6qknLtf9B2zMOYvahMSDqOslUQmR89 HoMkuirVNNN8GMKIrWLYN1y/cuN0WPRuQXj/XRaKPY+WRMsO/i0hD52X7Ac5WaJn +gT6lQR6ujPtTtk3nlYwgWup1YIdfaizRXE6VYBlapAof/jghCKSDu3NYLbcr0wy qlnKrUVlJ7dpTzmYCvmRY9Sifs8+WYCX69TFlDf+1YaDb0878uG51mmy6kNWwbmU nGdj1gxgZuqtZ9DW7Q0x0wsg4gEGOIXCodz4/7q//TvU0w97Wu/SQIhtjleY7b62 VKoFXbmiOe3HP/LigJC/mQ6CJyAPeKi5qDot6FNflpTWW+RYY0GCJQW7j0BcCTRo UxdoqQ2/sdvc01PLDIfI9pwO1HEJxzEBv52aKPN2KTtWDSV5sqzJECIGRwVRrs99 xfc0IlKNEFrmfODcRHqXlIzXi50ccTL7f/OCofQdj5lml8wWnPkSULmyTtbjq4gQ Nm1qkDqnG8P7D4Yj84YX7zjfDTdjXX7ag1jxjw3djVQ+LohfB2VxWxNBtFM2lDx+ weZoCcbAaaJO7rPL3GdF =vz5c -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Tue Feb 10 13:27:33 2015 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 C0DC3D9C; Tue, 10 Feb 2015 13:27:33 +0000 (UTC) Received: from mail.myota.org (mail.myota.org [85.10.206.105]) by mx1.freebsd.org (Postfix) with ESMTP id 30542D34; Tue, 10 Feb 2015 13:27:32 +0000 (UTC) Received: from mobile.client (184.220.166.190.f.sta.codetel.net.do [190.166.220.184] (may be forged)) (authenticated bits=128) by mail.myota.org (8.14.9/8.14.9) with ESMTP id t1ADRDAs073940; Tue, 10 Feb 2015 14:27:20 +0100 (CET) (envelope-from andre@fbsd.ata.myota.org) Received: from submit.client ([127.0.0.1]) by schlappy.local (8.14.9/8.14.9) with ESMTP id t1ADQqhi006422; Tue, 10 Feb 2015 14:26:54 +0100 (CET) (envelope-from andre@fbsd.ata.myota.org) Received: (from user@localhost) by schlappy.local (8.14.9/8.14.9/Submit) id t1ADQqZp006421; Tue, 10 Feb 2015 14:26:52 +0100 (CET) (envelope-from andre@fbsd.ata.myota.org) Date: Tue, 10 Feb 2015 14:26:52 +0100 From: Andre Albsmeier To: Lev Serebryakov Subject: Re: Problems with IP fragments Message-ID: <20150210132652.GA3398@schlappy> References: <54C918D2.7090805@FreeBSD.org> <54C91E80.7020407@infracaninophile.co.uk> <54C92222.6000201@FreeBSD.org> <20150209212131.GA32613@schlappy> <54D9E233.1010702@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54D9E233.1010702@FreeBSD.org> X-Echelon: 767, BND, assault, secure, DES X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Not delayed on 85.10.206.105, ACL: AUTH(59), Origin: DO, OS: FreeBSD 9.x or newer X-Virus-Scanned: clamav-milter 0.98.6 at colo X-Virus-Status: Clean Cc: Andre Albsmeier , Matthew Seaman , Freddie Cash , 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: Tue, 10 Feb 2015 13:27:33 -0000 On Tue, 10-Feb-2015 at 13:49:23 +0300, Lev Serebryakov wrote: > On 10.02.2015 00:21, Andre Albsmeier wrote: > > > The ipfw man page says: > > > > Usually a simple rule like: > > > > # reassemble incoming fragments ipfw add reass all from any to any > > in > > > > is all you need at the beginning of your ruleset. > > > > However, I could never make this work. It eats all fragments but > > the resulting final packet never makes it. I am back to > > > > ipfw -q add 1 pass udp from any to $myip frag in recv $ifc > > > > as I need it only for UDP. Frag reassembly in pf works well on the > > other hand... > reass works for me, but kills all IPv6 packets, so it should be "reass > ip4 from any to any in [recv $iface]" Hmm, I tried again with ipv4 but this doesn't help (I don't use v6 anyway here). But it seems to work as soon as I switch off layer2 filtering. Normally I use net.link.ether.ipfw=1 (and, yes, I have the appropriate arp rules installed). As soon as I switch this to off, reassembly works. However, I have no idea why the reass code messes around with layer2... -Andre > > > -- > // Lev Serebryakov AKA Black Lion -- "FreeBSD has always been the operating system that GNU/Linux-based operating systems should have been." - Frank Pohlmann, IBM From owner-freebsd-net@FreeBSD.ORG Tue Feb 10 13:48:04 2015 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 8C1ACF5D for ; Tue, 10 Feb 2015 13:48:04 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4ADE5F6E for ; Tue, 10 Feb 2015 13:48:04 +0000 (UTC) Received: from [127.0.0.1] (nat.in.devexperts.com [89.113.128.63]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 41BE856402; Tue, 10 Feb 2015 16:47:53 +0300 (MSK) Message-ID: <54DA0C08.7060006@FreeBSD.org> Date: Tue, 10 Feb 2015 16:47:52 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Andre Albsmeier Subject: Re: Problems with IP fragments References: <54C918D2.7090805@FreeBSD.org> <54C91E80.7020407@infracaninophile.co.uk> <54C92222.6000201@FreeBSD.org> <20150209212131.GA32613@schlappy> <54D9E233.1010702@FreeBSD.org> <20150210132652.GA3398@schlappy> In-Reply-To: <20150210132652.GA3398@schlappy> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: freebsd-net , Matthew Seaman , Freddie Cash 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, 10 Feb 2015 13:48:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10.02.2015 16:26, Andre Albsmeier wrote: >> reass works for me, but kills all IPv6 packets, so it should be >> "reass ip4 from any to any in [recv $iface]" > > Hmm, I tried again with ipv4 but this doesn't help (I don't use v6 > anyway here). But it seems to work as soon as I switch off layer2 > filtering. Normally I use net.link.ether.ipfw=1 (and, yes, I have > the appropriate arp rules installed). As soon as I switch this to > off, reassembly works. However, I have no idea why the reass code > messes around with layer2... Looks like, reass messes around with anything but ip4 in one way or other. - -- // Lev Serebryakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU2gwHXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePx+cP/2ImVQjlp+Cx9mz6NWCMqTxP /mkArWXRH0R3zpfQAJ+rNCb9bK+7xSDduoKZ1nNolLMIrThKHnkTga6IN5ZG5EV+ S7RfUUFfJSBZMQO47ue2cgLMwAnIDDDqxxfpgZyDjVdPOEsf7Vgm45jr8Vzt1pZe PQq4Cz+JlAdSJKm59QJEeS7mlbOl5rVLV3CEsW1+iWBmqW06cg8Z8oDLY7OqveSt niplV7w1wAFOjjC55emydCfyOzPQBp8eVJYHZ1tCiq0Z8BhojX9/xZIrX54yRWc5 7YkDW7Sm8l1OWlOmzjQhRYXP5eBXGEIQeNHV2ZnO6gnF20up7BxDe7DIxxZef1DL L+oG8RKE0/NyAv0cachvx4Uhlk3VHFmI3xhQJiXdttPbpxfECAlpJtvolGaksSp4 1OQzhkvoXFt3dKlCVVmGo4MIcoKxBgZEEGy5pOUoHXDGkyzogPc1HFjmT+szdqKG Phsk3Dlt5cWYVAxGjpSXlQTpKuozVvkmIdWGBN9bY8xjDOLOFFUsESNI8Zk4PTXH /qP81DcUv06FS/BdC8ZlRtuEBRGbF+jIILA4INlVtxcvmIr7NSNOJnJuJzV/oWhV Hy2cAAhk40LIqm/WzCwDCuxPEL7Xkz83gXEtapnTUwqX3fv+4/mxNFvojOgVKMKe WgOZ7lGwdmOfe+obz+ye =ht4X -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Tue Feb 10 17:34:04 2015 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 37CFB94D; Tue, 10 Feb 2015 17:34:04 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 82A13C55; Tue, 10 Feb 2015 17:34:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t1AHXGTM027018; Wed, 11 Feb 2015 04:33:16 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 11 Feb 2015 04:33:15 +1100 (EST) From: Ian Smith To: Andre Albsmeier Subject: Re: Problems with IP fragments In-Reply-To: <20150210132652.GA3398@schlappy> Message-ID: <20150211035919.B38620@sola.nimnet.asn.au> References: <54C918D2.7090805@FreeBSD.org> <54C91E80.7020407@infracaninophile.co.uk> <54C92222.6000201@FreeBSD.org> <20150209212131.GA32613@schlappy> <54D9E233.1010702@FreeBSD.org> <20150210132652.GA3398@schlappy> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Freddie Cash , Lev Serebryakov , Matthew Seaman , 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: Tue, 10 Feb 2015 17:34:04 -0000 On Tue, 10 Feb 2015 14:26:52 +0100, Andre Albsmeier wrote: > On Tue, 10-Feb-2015 at 13:49:23 +0300, Lev Serebryakov wrote: > > On 10.02.2015 00:21, Andre Albsmeier wrote: > > > > > The ipfw man page says: > > > > > > Usually a simple rule like: > > > > > > # reassemble incoming fragments ipfw add reass all from any to any > > > in > > > > > > is all you need at the beginning of your ruleset. > > > > > > However, I could never make this work. It eats all fragments but > > > the resulting final packet never makes it. I am back to > > > > > > ipfw -q add 1 pass udp from any to $myip frag in recv $ifc This has worked fine for me for spamhaus.org DNS packets - often with 2 or 3 frags - for years before reass came along. > > > as I need it only for UDP. Frag reassembly in pf works well on the > > > other hand... > > reass works for me, but kills all IPv6 packets, so it should be "reass > > ip4 from any to any in [recv $iface]" Some enterprising young developer could add code to catch with a warning attempts to send ip6 to reass (as yet, anyway) and also to divert (natd) sockets for sure, maybe kernel nat too?, netgraph?, tee? or any others that can't (as yet) deal with ip6? Otherwise it relies on thickening ipfw(8) with don't-do-thats and/or relying on folklore (such as this :) passed down through the lists .. > Hmm, I tried again with ipv4 but this doesn't help (I don't use v6 > anyway here). But it seems to work as soon as I switch off layer2 > filtering. Normally I use net.link.ether.ipfw=1 (and, yes, I have > the appropriate arp rules installed). As soon as I switch this to > off, reassembly works. However, I have no idea why the reass code > messes around with layer2... Perhaps you asked it to? :) reass is clearly only useful for ip layer3, so did you have rules such as those examples in ipfw(8) /PACKET FLOW to distinguish layer2 from layer3 processing paths? cheers, Ian From owner-freebsd-net@FreeBSD.ORG Tue Feb 10 18:35:17 2015 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 E5D5BC51; Tue, 10 Feb 2015 18:35:16 +0000 (UTC) Received: from mail.myota.org (mail.myota.org [85.10.206.105]) by mx1.freebsd.org (Postfix) with ESMTP id 8C59E314; Tue, 10 Feb 2015 18:35:16 +0000 (UTC) Received: from mobile.client (184.220.166.190.f.sta.codetel.net.do [190.166.220.184] (may be forged)) (authenticated bits=128) by mail.myota.org (8.14.9/8.14.9) with ESMTP id t1AIYjxR075141; Tue, 10 Feb 2015 19:34:49 +0100 (CET) (envelope-from andre@fbsd.ata.myota.org) Received: from submit.client ([127.0.0.1]) by schlappy.local (8.14.9/8.14.9) with ESMTP id t1AIYKtJ016497; Tue, 10 Feb 2015 19:34:26 +0100 (CET) (envelope-from andre@fbsd.ata.myota.org) Received: (from user@localhost) by schlappy.local (8.14.9/8.14.9/Submit) id t1AIYK0M016496; Tue, 10 Feb 2015 19:34:20 +0100 (CET) (envelope-from andre@fbsd.ata.myota.org) Date: Tue, 10 Feb 2015 19:34:20 +0100 From: Andre Albsmeier To: Ian Smith Subject: Re: Problems with IP fragments Message-ID: <20150210183420.GA12325@schlappy> References: <54C918D2.7090805@FreeBSD.org> <54C91E80.7020407@infracaninophile.co.uk> <54C92222.6000201@FreeBSD.org> <20150209212131.GA32613@schlappy> <54D9E233.1010702@FreeBSD.org> <20150210132652.GA3398@schlappy> <20150211035919.B38620@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150211035919.B38620@sola.nimnet.asn.au> X-Echelon: Secret, Fax, PGP, plutonium, SHF X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Not delayed on 85.10.206.105, ACL: AUTH(59), Origin: DO, OS: FreeBSD 9.x or newer X-Virus-Scanned: clamav-milter 0.98.6 at colo X-Virus-Status: Clean Cc: Andre Albsmeier , Freddie Cash , Lev Serebryakov , Matthew Seaman , 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: Tue, 10 Feb 2015 18:35:17 -0000 On Wed, 11-Feb-2015 at 04:33:15 +1100, Ian Smith wrote: > On Tue, 10 Feb 2015 14:26:52 +0100, Andre Albsmeier wrote: > > On Tue, 10-Feb-2015 at 13:49:23 +0300, Lev Serebryakov wrote: > > > On 10.02.2015 00:21, Andre Albsmeier wrote: > > > > > > > The ipfw man page says: > > > > > > > > Usually a simple rule like: > > > > > > > > # reassemble incoming fragments ipfw add reass all from any to any > > > > in > > > > > > > > is all you need at the beginning of your ruleset. > > > > > > > > However, I could never make this work. It eats all fragments but > > > > the resulting final packet never makes it. I am back to > > > > > > > > ipfw -q add 1 pass udp from any to $myip frag in recv $ifc > > This has worked fine for me for spamhaus.org DNS packets - often with 2 > or 3 frags - for years before reass came along. Yes, it works here as well. > > > > > as I need it only for UDP. Frag reassembly in pf works well on the > > > > other hand... > > ... > > > Hmm, I tried again with ipv4 but this doesn't help (I don't use v6 > > anyway here). But it seems to work as soon as I switch off layer2 > > filtering. Normally I use net.link.ether.ipfw=1 (and, yes, I have > > the appropriate arp rules installed). As soon as I switch this to > > off, reassembly works. However, I have no idea why the reass code > > messes around with layer2... > > Perhaps you asked it to? :) reass is clearly only useful for ip layer3, > so did you have rules such as those examples in ipfw(8) /PACKET FLOW to > distinguish layer2 from layer3 processing paths? Well, I thought so ;-) But after reading this part again, it might be that I explicitly have to enable passing of ip(v4) packets in layer2 (so they can be processed in ip_input() later on). Currently I have these rules (with 10.0.0.217 being my IP): # loopback 00100 allow ip from any to any via lo0 # arp traffic 00200 allow ip from any to any layer2 mac-type 0x0806 # dynamic rules for return stuff 00300 check-state # reassemble 00400 reass ip4 from any to any in # let all out and create state 00500 allow ip4 from 10.0.0.217 to any out keep-state # log remaining layer2 stuff 00600 deny log ip from any to any layer2 # log remaining ip stuff 00700 deny log ip from any to any # default deny rule 65535 deny ip from any to any These work for all of my ssh/http/... and (udp based) openvpn stuff as well as DNS (but not things like dig +dnssec www.freebsd.org @72.52.71.1). Now when I add a rule 00350 allow ip4 from any to any layer2 the above dig command works. But why is this needed just for the fragments and not for the "normal" v4 packets coming back from traffic which passwd through 500 (including all state processing)? And if the fragments are really getting stopped at ether_demux(), why don't they get logged with rule 600? OK, these questions may sound dumb but I am far from an experienced ipfw user as I use pf on all other machines ;-). -Andre From owner-freebsd-net@FreeBSD.ORG Tue Feb 10 21:42:37 2015 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 EB6B5772 for ; Tue, 10 Feb 2015 21:42: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 CF5C5D11 for ; Tue, 10 Feb 2015 21:42:37 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t1ALgbjO022165 for ; Tue, 10 Feb 2015 21:42:37 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: Tue, 10 Feb 2015 21:42: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: 8.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.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, 10 Feb 2015 21:42:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=172675 --- Comment #8 from commit-hook@freebsd.org --- A commit references this bug: Author: jhb Date: Tue Feb 10 21:41:57 UTC 2015 New revision: 278534 URL: https://svnweb.freebsd.org/changeset/base/278534 Log: MFC 277709: Use an sbuf to generate the output of the net.inet.tcp.hostcache.list sysctl to avoid a possible buffer overflow if the cache grows while the text is being generated. PR: 172675 Changes: _U stable/10/ stable/10/sys/netinet/tcp_hostcache.c _U stable/9/sys/ stable/9/sys/netinet/tcp_hostcache.c -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Wed Feb 11 02:49:33 2015 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 B65BA893; Wed, 11 Feb 2015 02:49:33 +0000 (UTC) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6953392; Wed, 11 Feb 2015 02:49:33 +0000 (UTC) Received: by labgd6 with SMTP id gd6so750486lab.7; Tue, 10 Feb 2015 18:49:31 -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=OnYKG5dBYACjjjIphUAp3YVQHKJvWGKy2PpKNcerNlk=; b=T3UYKsKmxOqPtqoh2n1fVpzXqqRV8bDJwXa9fpimOZCe6UV+p8ref4bYrzrdpvwar6 XhTrow+bTHKdi5wmyCENkzBwNjOfLoeDn6vvkhMsIRMgEaXl30DIRHzabSmn02nZvpG6 vCp6JuB++ytzyPybCDI3+ikt5Aji9mWEfej649MdsAy/t8duOsthNcgdkLfgvIQM20em Hm4ZH4Nim7/SLVOEesWNB+iVdHHQmKwPdJOq8bceWTxp+sKs5Si0IsENIgOklMruclx5 S+V3Ow/SWNIoIIbpDJxCvStYvldc+dZ7GGFRPLR6H16BLCIwkpe+EBlMw0gKDQhaiaxl sGhA== MIME-Version: 1.0 X-Received: by 10.112.27.231 with SMTP id w7mr12481140lbg.49.1423622971215; Tue, 10 Feb 2015 18:49:31 -0800 (PST) Received: by 10.25.83.203 with HTTP; Tue, 10 Feb 2015 18:49:31 -0800 (PST) In-Reply-To: <54CBF396.3090903@ignoranthack.me> References: <54CBF396.3090903@ignoranthack.me> Date: Wed, 11 Feb 2015 10:49:31 +0800 Message-ID: Subject: Re: Intel 82574L (em) From: Sepherosa Ziehau To: Sean Bruno Content-Type: text/plain; charset=UTF-8 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, 11 Feb 2015 02:49:33 -0000 On Sat, Jan 31, 2015 at 5:11 AM, Sean Bruno wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > http://www.intel.com/content/dam/doc/datasheet/82574l-gbe-controller-datasheet.pdf > > According to 7.1.11, this device does indeed have 2 queues for stuff and > or things. So, basic RSS would be possible in something like an Atom box. > > I note that the em(4) driver intentionally disables this on > initialization. I'm up for some science on my new shiny, soon to be > router box. Any reason not to default to 1 queue and allow loader.conf > to raise it to 2? You could actually enable 2 RX rings w/o MSI-X on 82574; you still get the benefit of hardware calculated RSS hash at least. And as far as I have tested, 2 RX rings work for 82574L, but 2 TX rings don't work (gave me TX watchdog timeout). And you could also use 2 RX rings on 82571/82572/82573 and i217/i218; 2 TX rings work on 82571 at least (you need to setup TX context for each TX descriptor though). Best Regards, sephe From owner-freebsd-net@FreeBSD.ORG Wed Feb 11 03:09:41 2015 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 8C266E1F; Wed, 11 Feb 2015 03:09:41 +0000 (UTC) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 522853CE; Wed, 11 Feb 2015 03:09:41 +0000 (UTC) Received: by mail-ig0-f169.google.com with SMTP id hl2so25527576igb.0; Tue, 10 Feb 2015 19:09: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; bh=A0WeFpgUs1O6NobhfNBX63PTMek23zi5aTXKnf9EmpY=; b=f1kuZjABx+Z4i/dDpXNTVyriqjz6gQTGLOrQbirY+ghVIMXZUGW8nSKsssK8qvrOSU GPpVRuBRAw7AgG9MKnLSJg4dcgBILky7Nwy9vuXph7WPmp4RTqZ7DOiFmQ6L/6UATLtn sxdJyZ+Rfot9uMbsovli5QRVOXGAqMjVHeVJSepF4hlWdC4bnBWHjjFcyo6oLxUkJMxK RLmJ3gof1oLSZKrnJXket/+KIHVlh48wrb2Q5Tk05hkwZhIG+vyiXskE8K/3aVC3rIik vKlzQcNkqo/0gnWFdGRVC/ebYFBTZW4xUN3PWFR093uwo5HdIMu68yJm2pbgl3RrxRYE FDBA== MIME-Version: 1.0 X-Received: by 10.50.79.135 with SMTP id j7mr27296593igx.32.1423624180675; Tue, 10 Feb 2015 19:09:40 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.17.7 with HTTP; Tue, 10 Feb 2015 19:09:40 -0800 (PST) In-Reply-To: References: <54CBF396.3090903@ignoranthack.me> Date: Tue, 10 Feb 2015 19:09:40 -0800 X-Google-Sender-Auth: zmnBXCrJM6OK96tIrRHPDxEJ9ps Message-ID: Subject: Re: Intel 82574L (em) From: Adrian Chadd To: Sepherosa Ziehau Content-Type: text/plain; charset=UTF-8 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, 11 Feb 2015 03:09:41 -0000 ... you can still use 1 TX/1 RX ring on -HEAD. If we turn on RSS in the driver and have it hardware hash things, then the netisr input routine will throw it into the right per-CPU queue and it'll distribute the work. (Someone could twist my arm to do this.) -adrian From owner-freebsd-net@FreeBSD.ORG Wed Feb 11 05:50:45 2015 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 6433E6AB for ; Wed, 11 Feb 2015 05:50: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 42B4A83C for ; Wed, 11 Feb 2015 05:50: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 t1B5ojlr080578 for ; Wed, 11 Feb 2015 05:50: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 t1B5oiPe080577; Wed, 11 Feb 2015 05:50:44 GMT (envelope-from root) Date: Wed, 11 Feb 2015 05:50:44 +0000 To: freebsd-net@freebsd.org From: "davide (Davide Italiano)" Subject: [Differential] [Commented On] D1809: [sockbuf] Don't expose lock details when isn't needed Message-ID: <3ee6f2bb869e2ee2eb1770b6d7a72ddf@localhost.localdomain> X-Priority: 3 Thread-Topic: D1809: [sockbuf] Don't expose lock details when isn't needed X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: ZDUyNzQ5ZWQxMTRmZDFiNGM0NTM4Yzk5MDEwIFTa7bQ= 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: Wed, 11 Feb 2015 05:50:45 -0000 davide added a comment. I plan to commit this in two days or such, so if there are objections, please raise them. REVISION DETAIL https://reviews.freebsd.org/D1809 To: davide, kmacy, np, rrs, lstewart, rwatson Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 11 05:50:52 2015 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 C2BD3740 for ; Wed, 11 Feb 2015 05:50:52 +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 A09A4844 for ; Wed, 11 Feb 2015 05:50:52 +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 t1B5oqvR081315 for ; Wed, 11 Feb 2015 05:50:52 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 t1B5oqxG081314; Wed, 11 Feb 2015 05:50:52 GMT (envelope-from root) Date: Wed, 11 Feb 2015 05:50:52 +0000 To: freebsd-net@freebsd.org From: "davide (Davide Italiano)" Subject: [Differential] [Commented On] D1805: [sockbuf] Don't access fields directly, use accessor functions Message-ID: X-Priority: 3 Thread-Topic: D1805: [sockbuf] Don't access fields directly, use accessor functions X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: OWRjZTdmYWI1ODk3ZGNkOWIxYTAyYWM0MjY5IFTa7bw= 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: Wed, 11 Feb 2015 05:50:52 -0000 davide added a comment. I plan to commit this in two days or such, so if there are objections, please raise them. REVISION DETAIL https://reviews.freebsd.org/D1805 To: davide, kmacy, np, lstewart, rrs, rwatson Cc: emaste, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 11 08:01:59 2015 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 7FC82867 for ; Wed, 11 Feb 2015 08:01: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 5CFB7934 for ; Wed, 11 Feb 2015 08:01: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 t1B81xG6019267 for ; Wed, 11 Feb 2015 08:01:59 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 t1B81xQr019241; Wed, 11 Feb 2015 08:01:59 GMT (envelope-from root) Date: Wed, 11 Feb 2015 08:01:59 +0000 To: freebsd-net@freebsd.org From: "julian (JulianElischer)" Subject: [Differential] [Accepted] D1805: [sockbuf] Don't access fields directly, use accessor functions Message-ID: X-Priority: 3 Thread-Topic: D1805: [sockbuf] Don't access fields directly, use accessor functions 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-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: OWRjZTdmYWI1ODk3ZGNkOWIxYTAyYWM0MjY5IFTbDHc= 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: Wed, 11 Feb 2015 08:01:59 -0000 julian accepted this revision. julian added a reviewer: julian. This revision is now accepted and ready to land. REVISION DETAIL https://reviews.freebsd.org/D1805 To: davide, kmacy, np, lstewart, rrs, rwatson, julian Cc: emaste, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 11 08:04:14 2015 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 73D07914 for ; Wed, 11 Feb 2015 08:04: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 51BDF94B for ; Wed, 11 Feb 2015 08:04: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 t1B84Eu7021307 for ; Wed, 11 Feb 2015 08:04: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 t1B84ERr021306; Wed, 11 Feb 2015 08:04:14 GMT (envelope-from root) Date: Wed, 11 Feb 2015 08:04:14 +0000 To: freebsd-net@freebsd.org From: "julian (JulianElischer)" Subject: [Differential] [Changed Subscribers] D1809: [sockbuf] Don't expose lock details when isn't needed Message-ID: <152c5623cdc6f65478de286fefcd3741@localhost.localdomain> X-Priority: 3 Thread-Topic: D1809: [sockbuf] Don't expose lock details when isn't needed X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: ZDUyNzQ5ZWQxMTRmZDFiNGM0NTM4Yzk5MDEwIFTbDP4= 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: Wed, 11 Feb 2015 08:04:14 -0000 julian added a subscriber: julian. julian added a comment. Is the reason here to just make the lines shorter or is there a deeper reason? (e.g. to prepare for some upcoming change) REVISION DETAIL https://reviews.freebsd.org/D1809 To: davide, kmacy, np, rrs, lstewart, rwatson Cc: julian, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 11 08:22:37 2015 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 83252EF4 for ; Wed, 11 Feb 2015 08:22:37 +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 60E94B2C for ; Wed, 11 Feb 2015 08:22:37 +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 t1B8MbCP041744 for ; Wed, 11 Feb 2015 08:22:37 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 t1B8MbYq041743; Wed, 11 Feb 2015 08:22:37 GMT (envelope-from root) Date: Wed, 11 Feb 2015 08:22:37 +0000 To: freebsd-net@freebsd.org From: "davide (Davide Italiano)" Subject: [Differential] [Commented On] D1809: [sockbuf] Don't expose lock details when isn't needed Message-ID: <7bbb73028b4e3cb354349ee38c0da279@localhost.localdomain> X-Priority: 3 Thread-Topic: D1809: [sockbuf] Don't expose lock details when isn't needed X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: ZDUyNzQ5ZWQxMTRmZDFiNGM0NTM4Yzk5MDEwIFTbEU0= 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: Wed, 11 Feb 2015 08:22:37 -0000 davide added a comment. Mainly for consistency at this point with whatever else it's used in the stack. REVISION DETAIL https://reviews.freebsd.org/D1809 To: davide, kmacy, np, rrs, lstewart, rwatson Cc: julian, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 11 08:38:26 2015 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 879A07BF for ; Wed, 11 Feb 2015 08:38:26 +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 650D0CC1 for ; Wed, 11 Feb 2015 08:38:26 +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 t1B8cQDm056803 for ; Wed, 11 Feb 2015 08:38:26 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 t1B8cQNQ056802; Wed, 11 Feb 2015 08:38:26 GMT (envelope-from root) Date: Wed, 11 Feb 2015 08:38:26 +0000 To: freebsd-net@freebsd.org From: "rwatson (Robert Watson)" Subject: [Differential] [Updated] D1809: [sockbuf] Don't expose lock details when isn't needed Message-ID: X-Priority: 3 Thread-Topic: D1809: [sockbuf] Don't expose lock details when isn't needed X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: ZDUyNzQ5ZWQxMTRmZDFiNGM0NTM4Yzk5MDEwIFTbFQI= 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: Wed, 11 Feb 2015 08:38:26 -0000 rwatson added a comment. Seems reasonable. I'm slightly surprised that any code other than sbwait() actually implements the sleep on sb_acc, and wonder if either a use of abstraction improvement, or an actual abstraction improvement, is needed to fix t4_ddp.c. REVISION DETAIL https://reviews.freebsd.org/D1809 To: davide, kmacy, np, rrs, lstewart, rwatson Cc: julian, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 11 08:46:11 2015 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 7238392B for ; Wed, 11 Feb 2015 08:46:11 +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 4F2B6D99 for ; Wed, 11 Feb 2015 08:46:11 +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 t1B8kBGD065609 for ; Wed, 11 Feb 2015 08:46:11 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 t1B8kBsF065608; Wed, 11 Feb 2015 08:46:11 GMT (envelope-from root) Date: Wed, 11 Feb 2015 08:46:11 +0000 To: freebsd-net@freebsd.org From: "rwatson (Robert Watson)" Subject: [Differential] [Requested Changes To] D1809: [sockbuf] Don't expose lock details when isn't needed Message-ID: <8914a3555c3a83cf0ab62988d4166e08@localhost.localdomain> X-Priority: 3 Thread-Topic: D1809: [sockbuf] Don't expose lock details when isn't needed X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: ZDUyNzQ5ZWQxMTRmZDFiNGM0NTM4Yzk5MDEwIFTbFtM= 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: Wed, 11 Feb 2015 08:46:11 -0000 rwatson requested changes to this revision. rwatson added a comment. This revision now requires changes to proceed. Looks like some serious transcription errors are in this patch. INLINE COMMENTS sys/kern/uipc_sockbuf.c:225 Should this be so->so_rcv? sys/kern/uipc_sockbuf.c:234 Should this be so->so_rcv? REVISION DETAIL https://reviews.freebsd.org/D1809 To: davide, kmacy, np, rrs, lstewart, rwatson Cc: julian, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 11 08:54:59 2015 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 49FD7BE9 for ; Wed, 11 Feb 2015 08:54: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 27AB1E91 for ; Wed, 11 Feb 2015 08:54: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 t1B8swa9074930 for ; Wed, 11 Feb 2015 08:54: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 t1B8sw9W074929; Wed, 11 Feb 2015 08:54:58 GMT (envelope-from root) Date: Wed, 11 Feb 2015 08:54:58 +0000 To: freebsd-net@freebsd.org From: "davide (Davide Italiano)" Subject: [Differential] [Commented On] D1809: [sockbuf] Don't expose lock details when isn't needed Message-ID: <2985078bfa16e89f498437d6492a2d65@localhost.localdomain> X-Priority: 3 Thread-Topic: D1809: [sockbuf] Don't expose lock details when isn't needed X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: ZDUyNzQ5ZWQxMTRmZDFiNGM0NTM4Yzk5MDEwIFTbGOI= 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: Wed, 11 Feb 2015 08:54:59 -0000 davide added a comment. Robert, an added (somewhat related) note. SCTP has already its own sockbuf(s) and this makes integration very hackish in the tree. IIRC glebius experienced this himself while working on sendfile(), and I'm pretty sure rrs@ is kind of familiar with the problem. Introducing a better abstraction for sockbuf might help with this. REVISION DETAIL https://reviews.freebsd.org/D1809 To: davide, kmacy, np, rrs, lstewart, rwatson Cc: julian, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 11 08:55:44 2015 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 99869C93 for ; Wed, 11 Feb 2015 08:55:44 +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 7720EEA7 for ; Wed, 11 Feb 2015 08:55:44 +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 t1B8tiuu075643 for ; Wed, 11 Feb 2015 08:55:44 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 t1B8tinH075642; Wed, 11 Feb 2015 08:55:44 GMT (envelope-from root) Date: Wed, 11 Feb 2015 08:55:44 +0000 To: freebsd-net@freebsd.org From: "davide (Davide Italiano)" Subject: [Differential] [Commented On] D1809: [sockbuf] Don't expose lock details when isn't needed Message-ID: X-Priority: 3 Thread-Topic: D1809: [sockbuf] Don't expose lock details when isn't needed X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: ZDUyNzQ5ZWQxMTRmZDFiNGM0NTM4Yzk5MDEwIFTbGRA= 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: Wed, 11 Feb 2015 08:55:44 -0000 davide added inline comments. INLINE COMMENTS sys/kern/uipc_sockbuf.c:234 Thanks for spotting i'll fix up and upload a new patch. REVISION DETAIL https://reviews.freebsd.org/D1809 To: davide, kmacy, np, rrs, lstewart, rwatson Cc: julian, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 11 09:06:19 2015 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 35BB030D for ; Wed, 11 Feb 2015 09:06:19 +0000 (UTC) Received: from smtp-outbound.userve.net (smtp-outbound.userve.net [217.196.1.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.userve.net", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A4B5AFB2 for ; Wed, 11 Feb 2015 09:06:17 +0000 (UTC) Received: from owa.usd-group.com (owa.usd-group.com [217.196.1.2]) by smtp-outbound.userve.net (8.14.7/8.14.7) with ESMTP id t1B8xenh003696 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 11 Feb 2015 08:59:43 GMT (envelope-from matt.churchyard@userve.net) Received: from SERVER.ad.usd-group.com (192.168.0.1) by SERVER.ad.usd-group.com (192.168.0.1) with Microsoft SMTP Server (TLS) id 15.0.516.32; Wed, 11 Feb 2015 08:59:40 +0000 Received: from SERVER.ad.usd-group.com ([fe80::b19d:892a:6fc7:1c9]) by SERVER.ad.usd-group.com ([fe80::b19d:892a:6fc7:1c9%12]) with mapi id 15.00.0516.029; Wed, 11 Feb 2015 08:59:40 +0000 From: Matt Churchyard To: "freebsd-net@freebsd.org" Subject: Invalid subnet masks Thread-Topic: Invalid subnet masks Thread-Index: AdBF2FIuD1FE1aNwSWOzQAqD5/Kpzw== Date: Wed, 11 Feb 2015 08:59:39 +0000 Message-ID: <7e069c1946454793b1c7e0be988877c4@SERVER.ad.usd-group.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.0.10] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: Wed, 11 Feb 2015 09:06:19 -0000 Hello, Just been helping someone on the forums who appears to have configured thei= r network interface incorrectly. It looks like they've assigned 250.250.250= .0 as the netmask. I've tried assigning this netmask on a 10.1 machine and ifconfig happily ac= cepts it. Is there any reason why FreeBSD accepts this value as a netmask? I'm fairly= well versed in IPv4, although not a real expert, but I see no reason why s= uch a mask would be used. Testing on my Win8.1 workstation, it gets rejected telling me the mask must= be contiguous (i.e. all 1's then 0's), as I would expect. Regards, Matt Churchyard From owner-freebsd-net@FreeBSD.ORG Wed Feb 11 09:11:07 2015 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 39DFA50D; Wed, 11 Feb 2015 09:11:07 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 92F3FC4; Wed, 11 Feb 2015 09:11:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t1B9AQU4058884; Wed, 11 Feb 2015 20:10:27 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 11 Feb 2015 20:10:26 +1100 (EST) From: Ian Smith To: Andre Albsmeier Subject: Re: Problems with IP fragments In-Reply-To: <20150210183420.GA12325@schlappy> Message-ID: <20150211193348.H38620@sola.nimnet.asn.au> References: <54C918D2.7090805@FreeBSD.org> <54C91E80.7020407@infracaninophile.co.uk> <54C92222.6000201@FreeBSD.org> <20150209212131.GA32613@schlappy> <54D9E233.1010702@FreeBSD.org> <20150210132652.GA3398@schlappy> <20150211035919.B38620@sola.nimnet.asn.au> <20150210183420.GA12325@schlappy> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net , Lev Serebryakov , Freddie Cash , Matthew Seaman 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, 11 Feb 2015 09:11:07 -0000 On Tue, 10 Feb 2015 19:34:20 +0100, Andre Albsmeier wrote: > On Wed, 11-Feb-2015 at 04:33:15 +1100, Ian Smith wrote: > > On Tue, 10 Feb 2015 14:26:52 +0100, Andre Albsmeier wrote: > > > On Tue, 10-Feb-2015 at 13:49:23 +0300, Lev Serebryakov wrote: > > > > On 10.02.2015 00:21, Andre Albsmeier wrote: > > > > > > > > > The ipfw man page says: > > > > > > > > > > Usually a simple rule like: > > > > > > > > > > # reassemble incoming fragments ipfw add reass all from any to any > > > > > in > > > > > > > > > > is all you need at the beginning of your ruleset. I think 'usually' here most likely refers only to layer 3 processing. > > > > > However, I could never make this work. It eats all fragments but > > > > > the resulting final packet never makes it. I am back to > > > > > > > > > > ipfw -q add 1 pass udp from any to $myip frag in recv $ifc > > > > This has worked fine for me for spamhaus.org DNS packets - often with 2 > > or 3 frags - for years before reass came along. > > Yes, it works here as well. > > ... > > > > > Hmm, I tried again with ipv4 but this doesn't help (I don't use v6 > > > anyway here). But it seems to work as soon as I switch off layer2 > > > filtering. Normally I use net.link.ether.ipfw=1 (and, yes, I have > > > the appropriate arp rules installed). As soon as I switch this to > > > off, reassembly works. However, I have no idea why the reass code > > > messes around with layer2... > > > > Perhaps you asked it to? :) reass is clearly only useful for ip layer3, > > so did you have rules such as those examples in ipfw(8) /PACKET FLOW to > > distinguish layer2 from layer3 processing paths? > > Well, I thought so ;-) But after reading this part again, it might be that > I explicitly have to enable passing of ip(v4) packets in layer2 (so they > can be processed in ip_input() later on). I would think so. It's been nearly 10 years since I last admin'd a filtering bridge, on FreeBSD 4.10 IIRC. There I found it clearest to separate layer2 processing using those example rules. However yours is a simple ruleset, not so hard to follow through all 4 ipfw passes .. > Currently I have these rules (with 10.0.0.217 being my IP): > > # loopback > 00100 allow ip from any to any via lo0 > > # arp traffic > 00200 allow ip from any to any layer2 mac-type 0x0806 > > # dynamic rules for return stuff > 00300 check-state > > # reassemble > 00400 reass ip4 from any to any in > > # let all out and create state > 00500 allow ip4 from 10.0.0.217 to any out keep-state > > # log remaining layer2 stuff > 00600 deny log ip from any to any layer2 > > # log remaining ip stuff > 00700 deny log ip from any to any > > # default deny rule > 65535 deny ip from any to any > > These work for all of my ssh/http/... and (udp based) openvpn stuff as well > as DNS (but not things like dig +dnssec www.freebsd.org @72.52.71.1). > > Now when I add a rule > > 00350 allow ip4 from any to any layer2 > > the above dig command works. But why is this needed just for the fragments > and not for the "normal" v4 packets coming back from traffic which passwd > through 500 (including all state processing)? I'm not sure, but think it may be to do with the stateful processing at check-state passing these at either layer? Someone may know for sure, but if you moved 600 to before the check-state or allow .. keep-state it might provide better clues? > And if the fragments are really getting stopped at ether_demux(), why don't > they get logged with rule 600? Again, I don't know. It may be helpful to add 'log' to some rules, including 'reass'? And 'ipfw -ted show' might reveal dynamic states? > OK, these questions may sound dumb but I am far from an experienced ipfw > user as I use pf on all other machines ;-). Rather than your rule 350, you could just add ',ipv4' to rule 200, going only on my reading of ipfw(8) 'mac-type'. I used to just pass all of layer2 and filter only on layer3, and then only on the inbound pass and statelessly, wherras it looks like you're only allowing arp through layer2 otherwise, unless the stateful rules are (double?) applying? cheers, Ian From owner-freebsd-net@FreeBSD.ORG Wed Feb 11 09:48:25 2015 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 69ABD314 for ; Wed, 11 Feb 2015 09:48:25 +0000 (UTC) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx142.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 388C663F for ; Wed, 11 Feb 2015 09:48:24 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.09,557,1418112000"; d="asc'?scan'208";a="22264838" Received: from hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) by mx142-out.netapp.com with ESMTP; 11 Feb 2015 01:27:40 -0800 Received: from HIOEXCMBX01-PRD.hq.netapp.com (10.122.105.34) by hioexcmbx01-prd.hq.netapp.com (10.122.105.34) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 11 Feb 2015 01:27:39 -0800 Received: from HIOEXCMBX01-PRD.hq.netapp.com ([10.122.105.34]) by hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) with mapi id 15.00.0995.031; Wed, 11 Feb 2015 01:27:39 -0800 From: "Eggert, Lars" To: Matt Churchyard Subject: Re: Invalid subnet masks Thread-Topic: Invalid subnet masks Thread-Index: AdBF2FIuD1FE1aNwSWOzQAqD5/KpzwAR7UuA Date: Wed, 11 Feb 2015 09:27:38 +0000 Message-ID: References: <7e069c1946454793b1c7e0be988877c4@SERVER.ad.usd-group.com> In-Reply-To: <7e069c1946454793b1c7e0be988877c4@SERVER.ad.usd-group.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2070.6) x-originating-ip: [10.120.60.37] Content-Type: multipart/signed; boundary="Apple-Mail=_E3FE2A56-2EEA-4271-91B2-3C73AE7383AB"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 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, 11 Feb 2015 09:48:25 -0000 --Apple-Mail=_E3FE2A56-2EEA-4271-91B2-3C73AE7383AB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2015-2-11, at 09:59, Matt Churchyard = wrote: > Just been helping someone on the forums who appears to have configured = their network interface incorrectly. It looks like they've assigned = 250.250.250.0 as the netmask. that's not invalid. The netmask is a mask and not a prefix like in IPv6. We could warn when people configure netmasks that are not contiguous = prefixes (which is the usual practice), but such configurations need to = remain allowed. Lars --Apple-Mail=_E3FE2A56-2EEA-4271-91B2-3C73AE7383AB 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----- iQCVAwUBVNsgidZcnpRveo1xAQI9QQQAq5KZVt3emJNuXgPWOmysaY9Ls7//EIQl RRELprhpTPp3lAivrw+iD0VrNkuv6MkOOnWWq4ICWCKYVFKu9YwkHqkV6MmyoIrx LHVOqNpNizmcJIvwIvMefr8Iypz2MK6pl8puLVijmrFPnv94MRFqtaPYEpSHgv4x 6lLeqnO7zMQ= =LITf -----END PGP SIGNATURE----- --Apple-Mail=_E3FE2A56-2EEA-4271-91B2-3C73AE7383AB-- From owner-freebsd-net@FreeBSD.ORG Wed Feb 11 09:55:20 2015 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 20E6542E for ; Wed, 11 Feb 2015 09:55:20 +0000 (UTC) Received: from smtp-outbound.userve.net (smtp-outbound.userve.net [217.196.1.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.userve.net", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A2EE676C for ; Wed, 11 Feb 2015 09:55:19 +0000 (UTC) Received: from owa.usd-group.com (owa.usd-group.com [217.196.1.2]) by smtp-outbound.userve.net (8.14.7/8.14.7) with ESMTP id t1B9t5a3008931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 11 Feb 2015 09:55:08 GMT (envelope-from matt.churchyard@userve.net) Received: from SERVER.ad.usd-group.com (192.168.0.1) by SERVER.ad.usd-group.com (192.168.0.1) with Microsoft SMTP Server (TLS) id 15.0.516.32; Wed, 11 Feb 2015 09:55:04 +0000 Received: from SERVER.ad.usd-group.com ([fe80::b19d:892a:6fc7:1c9]) by SERVER.ad.usd-group.com ([fe80::b19d:892a:6fc7:1c9%12]) with mapi id 15.00.0516.029; Wed, 11 Feb 2015 09:55:04 +0000 From: Matt Churchyard To: "freebsd-net@freebsd.org" Subject: RE: Invalid subnet masks Thread-Topic: Invalid subnet masks Thread-Index: AdBF2FIuD1FE1aNwSWOzQAqD5/KpzwAR7UuAABB1eoA= Date: Wed, 11 Feb 2015 09:55:03 +0000 Message-ID: References: <7e069c1946454793b1c7e0be988877c4@SERVER.ad.usd-group.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.0.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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, 11 Feb 2015 09:55:20 -0000 On 2015-2-11, at 09:59, Matt Churchyard wrote: >> Just been helping someone on the forums who appears to have configured t= heir network interface incorrectly. It looks like they've assigned 250.250.= 250.0 as the netmask. > that's not invalid. The netmask is a mask and not a prefix like in IPv6. > We could warn when people configure netmasks that are not contiguous pref= ixes (which is the usual practice), but such configurations need to remain = allowed. >Lars I appreciate that it might be 'valid' as a binary mask, but I'm struggling = to find any documentation anywhere that actually suggests that it's valid a= s a network configuration. The entire modern CIDR notation, and all the rou= ting system & hardware built around it (that shows networks in CIDR form an= d will collapse routes) has no way of dealing with these subnets. Are there actually valid use cases for these types of network? I'm learning towards the opinion that they should be rejected unless the us= er specifically overrides it (with something like an ifconfig flag or sysct= l). Although having said that, it's not really doing any damage letting peo= ple get their netmasks wrong. However, as I mentioned in my first email, Wi= ndows 8.1 (and I've now tested Server 2012 which is fairly common in enterp= rise globally...) will not allow them. From owner-freebsd-net@FreeBSD.ORG Wed Feb 11 10:23:06 2015 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 7B161D81; Wed, 11 Feb 2015 10:23:06 +0000 (UTC) Received: from mail.myota.org (mail.myota.org [85.10.206.105]) by mx1.freebsd.org (Postfix) with ESMTP id 1FD4CA30; Wed, 11 Feb 2015 10:23:05 +0000 (UTC) Received: from mobile.client (236.5.167.190.d.dyn.codetel.net.do [190.167.5.236] (may be forged)) (authenticated bits=128) by mail.myota.org (8.14.9/8.14.9) with ESMTP id t1BAMfH7013823; Wed, 11 Feb 2015 11:22:42 +0100 (CET) (envelope-from andre@fbsd.ata.myota.org) Received: from submit.client ([127.0.0.1]) by schlappy.local (8.14.9/8.14.9) with ESMTP id t1BAMIDL002612; Wed, 11 Feb 2015 11:22:19 +0100 (CET) (envelope-from andre@fbsd.ata.myota.org) Received: (from user@localhost) by schlappy.local (8.14.9/8.14.9/Submit) id t1BAMI8t002611; Wed, 11 Feb 2015 11:22:18 +0100 (CET) (envelope-from andre@fbsd.ata.myota.org) Date: Wed, 11 Feb 2015 11:22:18 +0100 From: Andre Albsmeier To: Ian Smith Subject: Re: Problems with IP fragments Message-ID: <20150211102218.GA2570@schlappy> References: <54C918D2.7090805@FreeBSD.org> <54C91E80.7020407@infracaninophile.co.uk> <54C92222.6000201@FreeBSD.org> <20150209212131.GA32613@schlappy> <54D9E233.1010702@FreeBSD.org> <20150210132652.GA3398@schlappy> <20150211035919.B38620@sola.nimnet.asn.au> <20150210183420.GA12325@schlappy> <20150211193348.H38620@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150211193348.H38620@sola.nimnet.asn.au> X-Echelon: United, DES, Satellite, Pretoria, top X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Not delayed on 85.10.206.105, ACL: AUTH(59), Origin: DO, OS: FreeBSD 9.x or newer X-Virus-Scanned: clamav-milter 0.98.6 at colo X-Virus-Status: Clean Cc: Andre Albsmeier , Lev Serebryakov , Freddie Cash , Matthew Seaman , 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, 11 Feb 2015 10:23:06 -0000 On Wed, 11-Feb-2015 at 20:10:26 +1100, Ian Smith wrote: > On Tue, 10 Feb 2015 19:34:20 +0100, Andre Albsmeier wrote: > > On Wed, 11-Feb-2015 at 04:33:15 +1100, Ian Smith wrote: > > > On Tue, 10 Feb 2015 14:26:52 +0100, Andre Albsmeier wrote: > > > > On Tue, 10-Feb-2015 at 13:49:23 +0300, Lev Serebryakov wrote: > > > > > On 10.02.2015 00:21, Andre Albsmeier wrote: > > > > > > ... > > > ... > > > > > > > Hmm, I tried again with ipv4 but this doesn't help (I don't use v6 > > > > anyway here). But it seems to work as soon as I switch off layer2 > > > > filtering. Normally I use net.link.ether.ipfw=1 (and, yes, I have > > > > the appropriate arp rules installed). As soon as I switch this to > > > > off, reassembly works. However, I have no idea why the reass code > > > > messes around with layer2... > > > > > > Perhaps you asked it to? :) reass is clearly only useful for ip layer3, > > > so did you have rules such as those examples in ipfw(8) /PACKET FLOW to > > > distinguish layer2 from layer3 processing paths? > > > > Well, I thought so ;-) But after reading this part again, it might be that > > I explicitly have to enable passing of ip(v4) packets in layer2 (so they > > can be processed in ip_input() later on). > > I would think so. It's been nearly 10 years since I last admin'd a > filtering bridge, on FreeBSD 4.10 IIRC. There I found it clearest to > separate layer2 processing using those example rules. However yours is > a simple ruleset, not so hard to follow through all 4 ipfw passes .. > > > Currently I have these rules (with 10.0.0.217 being my IP): > > > > # loopback > > 00100 allow ip from any to any via lo0 > > > > # arp traffic > > 00200 allow ip from any to any layer2 mac-type 0x0806 > > > > # dynamic rules for return stuff > > 00300 check-state > > > > # reassemble > > 00400 reass ip4 from any to any in > > > > # let all out and create state > > 00500 allow ip4 from 10.0.0.217 to any out keep-state > > > > # log remaining layer2 stuff > > 00600 deny log ip from any to any layer2 > > > > # log remaining ip stuff > > 00700 deny log ip from any to any > > > > # default deny rule > > 65535 deny ip from any to any > > > > These work for all of my ssh/http/... and (udp based) openvpn stuff as well > > as DNS (but not things like dig +dnssec www.freebsd.org @72.52.71.1). > > > > Now when I add a rule > > > > 00350 allow ip4 from any to any layer2 > > > > the above dig command works. But why is this needed just for the fragments > > and not for the "normal" v4 packets coming back from traffic which passwd > > through 500 (including all state processing)? > > I'm not sure, but think it may be to do with the stateful processing at > check-state passing these at either layer? Someone may know for sure, > but if you moved 600 to before the check-state or allow .. keep-state it > might provide better clues? > > > And if the fragments are really getting stopped at ether_demux(), why don't > > they get logged with rule 600? > > Again, I don't know. It may be helpful to add 'log' to some rules, If have tried several combinations with "log" on pass or deny rules in various places but did not discover a completely consistent behaviour w.r.t. logging... > including 'reass'? And 'ipfw -ted show' might reveal dynamic states? > > > OK, these questions may sound dumb but I am far from an experienced ipfw > > user as I use pf on all other machines ;-). > > Rather than your rule 350, you could just add ',ipv4' to rule 200, going Well, in fact my layer2 rules are slightly more complex, I just trimmed them down to what we see in 200 for the sake of simplicity. But I did it now in a similiar way to what is shown in ipfw(8) and let all layer2 processeing being skip(ped)to its own rule block which lets ipv4 pass and filters on the rest. Anyway, thanks for pointing me into the correct direction ;-) -Andre > only on my reading of ipfw(8) 'mac-type'. I used to just pass all of > layer2 and filter only on layer3, and then only on the inbound pass and > statelessly, wherras it looks like you're only allowing arp through > layer2 otherwise, unless the stateful rules are (double?) applying? > > cheers, Ian From owner-freebsd-net@FreeBSD.ORG Wed Feb 11 10:51:58 2015 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 9E4C559C for ; Wed, 11 Feb 2015 10:51:58 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D348D4C for ; Wed, 11 Feb 2015 10:51:58 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-230-68.lns20.per1.internode.on.net [121.45.230.68]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t1BAplXx077208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 11 Feb 2015 02:51:50 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54DB343E.7090008@freebsd.org> Date: Wed, 11 Feb 2015 18:51:42 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Matt Churchyard , "freebsd-net@freebsd.org" Subject: Re: Invalid subnet masks References: <7e069c1946454793b1c7e0be988877c4@SERVER.ad.usd-group.com> 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: Wed, 11 Feb 2015 10:51:58 -0000 On 2/11/15 5:55 PM, Matt Churchyard wrote: > > I appreciate that it might be 'valid' as a binary mask, but I'm struggling to find any documentation anywhere that actually suggests that it's valid as a network configuration. The entire modern CIDR notation, and all the routing system & hardware built around it (that shows networks in CIDR form and will collapse routes) has no way of dealing with these subnets. most can deal with it, just not optimally > > Are there actually valid use cases for these types of network? yes. I've had networks that were the first and last quarter of a /24, and the middle two quarters were separate nets. Sure, it made my skin crawl, but I was in a pinch to get more machines onto that /26. all four were served by the same router so only one router needed to know.. I have however at times though we could think about making ifconfig at give a warning. (but not an error). > I'm learning towards the opinion that they should be rejected unless the user specifically overrides it (with something like an ifconfig flag or sysctl). Although having said that, it's not really doing any damage letting people get their netmasks wrong. However, as I mentioned in my first email, Windows 8.1 (and I've now tested Server 2012 which is fairly common in enterprise globally...) will not allow them. > _______________________________________________ > 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 Feb 11 14:40:53 2015 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 65AB2F10; Wed, 11 Feb 2015 14:40:53 +0000 (UTC) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id 428FB9C8; Wed, 11 Feb 2015 14:40:53 +0000 (UTC) Received: from marvin.lab.vangyzen.net (c-24-125-214-90.hsd1.va.comcast.net [24.125.214.90]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 29C8D56467; Wed, 11 Feb 2015 08:40:46 -0600 (CST) Message-ID: <54DB69E7.60602@vangyzen.net> Date: Wed, 11 Feb 2015 09:40:39 -0500 From: Eric van Gyzen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Julian Elischer , Matt Churchyard , "freebsd-net@freebsd.org" Subject: Re: Invalid subnet masks References: <7e069c1946454793b1c7e0be988877c4@SERVER.ad.usd-group.com> <54DB343E.7090008@freebsd.org> In-Reply-To: <54DB343E.7090008@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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, 11 Feb 2015 14:40:53 -0000 On 02/11/2015 05:51, Julian Elischer wrote: > On 2/11/15 5:55 PM, Matt Churchyard wrote: > >> >> Are there actually valid use cases for these types of network? > yes. > I've had networks that were the first and last quarter of a /24, and > the middle two quarters were separate nets. > > Sure, it made my skin crawl, but I was in a pinch to get more machines > onto that /26. > all four were served by the same router so only one router needed to > know.. > > I have however at times though we could think about making ifconfig at > give a warning. > (but not an error). > >> I'm learning towards the opinion that they should be rejected unless >> the user specifically overrides it (with something like an ifconfig >> flag or sysctl). These valid use cases are so rare, I would favor making this an error in ifconfig, but also providing a flag to silence the message and accept the mask. The error message could even mention the name of the flag, to be helpful. For example: # ifconfig igb0 netmask 250.250.250.0 ifconfig: netmask should be contiguous and left-justified; specify "incontiguous" to override # ifconfig igb0 incontiguous netmask 250.250.250.0 # If it's just a warning, that warning will get very annoying to people who are forced to use such a mask. (They're already forced to use such a network!) Eric From owner-freebsd-net@FreeBSD.ORG Wed Feb 11 14:56:10 2015 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 77F6A389 for ; Wed, 11 Feb 2015 14:56:10 +0000 (UTC) Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 38237B2D for ; Wed, 11 Feb 2015 14:56:09 +0000 (UTC) Received: by mail-oi0-f48.google.com with SMTP id a3so15905080oib.7 for ; Wed, 11 Feb 2015 06:56:03 -0800 (PST) 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=/TuT1tb/dLERFHtKst+jNFwSMCDlL5Qwkpg/7WYxhgk=; b=FTCkESFHlHKhLE1xeDofn9Y9Auo6FSrgJGW7bPvZcqduW3oscm5QV0kQEmrVqTO5nZ WtBLxzvgHlV0H6wvl7h2jyIttHsbwLYO/PyxX0JVT4kRC9OZILuWOS5x1WTfloyRUUyn xif4qzmjN11JHdO4ebMF3Z4A4fSb/0fHfhc0yEJ8sbTMNx/BNV0Q5M170y7U9uIPr3Q/ Py5ZjpalOtnHcZow84soe2DZmXKYa7yr5tiPUa7NiQnPannYHGa8EE0+JV1GG3gj9946 ipHa1p2twggaZbg+mk1cP8QAAHydCAFJeVq5SmA+HJI2Glk8bj8+JCoShEzsheTaU/Y8 3AoA== X-Gm-Message-State: ALoCoQmhZ8BXlICFbxa2RLc0UaNv2yy/gempKk2yO4jUnbrFrZaPjRE9BacacP9nJAaYVGqafFwY X-Received: by 10.202.227.11 with SMTP id a11mr18663289oih.9.1423665031386; Wed, 11 Feb 2015 06:30:31 -0800 (PST) Received: from [172.21.0.96] (65-36-83-120.static.grandenetworks.net. [65.36.83.120]) by mx.google.com with ESMTPSA id km8sm405049oeb.11.2015.02.11.06.30.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Feb 2015 06:30:30 -0800 (PST) Mime-Version: 1.0 (1.0) Subject: Re: Invalid subnet masks From: Jim Thompson X-Mailer: iPad Mail (12B466) In-Reply-To: <54DB343E.7090008@freebsd.org> Date: Wed, 11 Feb 2015 08:30:28 -0600 Message-Id: <580B0DA4-05B3-45B8-ACB9-27B9174D76A8@netgate.com> References: <7e069c1946454793b1c7e0be988877c4@SERVER.ad.usd-group.com> <54DB343E.7090008@freebsd.org> To: Julian Elischer Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , Matt Churchyard 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, 11 Feb 2015 14:56:10 -0000 > On Feb 11, 2015, at 4:51 AM, Julian Elischer wrote: >=20 >> On 2/11/15 5:55 PM, Matt Churchyard wrote: >>=20 >> I appreciate that it might be 'valid' as a binary mask, but I'm strugglin= g to find any documentation anywhere that actually suggests that it's valid a= s a network configuration. The entire modern CIDR notation, and all the rout= ing system & hardware built around it (that shows networks in CIDR form and w= ill collapse routes) has no way of dealing with these subnets. > most can deal with it, just not optimally >>=20 >> Are there actually valid use cases for these types of network? > yes. > I've had networks that were the first and last quarter of a /24, and the m= iddle two quarters were separate nets. >=20 > Sure, it made my skin crawl, but I was in a pinch to get more machines ont= o that /26. > all four were served by the same router so only one router needed to know.= . >=20 > I have however at times though we could think about making ifconfig at giv= e a warning. > (but not an error). https://lists.freebsd.org/pipermail/freebsd-hackers/2011-April/034997.html Subject came up on -hackers in 2011 Quoting RFC-1219: "While RFC-950 allows the "ones" in the subnet mask to be non-contiguous, RFC= -950 recommends that 1) they be contiguous, and 2) that they occupy the most= significant bits of the "host" part of the internet address." Jim From owner-freebsd-net@FreeBSD.ORG Wed Feb 11 16:14:58 2015 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 6F2F6D75 for ; Wed, 11 Feb 2015 16:14:58 +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 4BC6A69F for ; Wed, 11 Feb 2015 16:14:58 +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 t1BGEwBw035250 for ; Wed, 11 Feb 2015 16:14: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 t1BGEw58035249; Wed, 11 Feb 2015 16:14:58 GMT (envelope-from root) Date: Wed, 11 Feb 2015 16:14:58 +0000 To: freebsd-net@freebsd.org From: "adrian (Adrian Chadd)" Subject: [Differential] [Accepted] D1805: [sockbuf] Don't access fields directly, use accessor functions Message-ID: <6a20d560e506ae4e66b63a42bb8a78aa@localhost.localdomain> X-Priority: 3 Thread-Topic: D1805: [sockbuf] Don't access fields directly, use accessor functions 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-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: OWRjZTdmYWI1ODk3ZGNkOWIxYTAyYWM0MjY5IFTbgAI= 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: Wed, 11 Feb 2015 16:14:58 -0000 adrian accepted this revision. adrian added a reviewer: adrian. REVISION DETAIL https://reviews.freebsd.org/D1805 To: davide, kmacy, np, lstewart, rrs, rwatson, julian, adrian Cc: emaste, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 11 17:33:24 2015 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 0184DAEF for ; Wed, 11 Feb 2015 17:33:23 +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 B5D64F8B for ; Wed, 11 Feb 2015 17:33:23 +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 t1BHXN6f029575 for ; Wed, 11 Feb 2015 17:33:23 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 t1BHXNWN029574; Wed, 11 Feb 2015 17:33:23 GMT (envelope-from root) Date: Wed, 11 Feb 2015 17:33:23 +0000 To: freebsd-net@freebsd.org From: "hselasky (Hans Petter Selasky)" Subject: [Differential] [Updated, 2, 464 lines] D1438: FreeBSD callout rewrite and cleanup Message-ID: X-Priority: 3 Thread-Topic: D1438: FreeBSD callout rewrite / cleanup 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: In-Reply-To: References: Thread-Index: YzU3ODk0MGM0Y2E4NmE3NjY4YjJlZmFkM2UyIFTbkmM= 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: Wed, 11 Feb 2015 17:33:24 -0000 hselasky updated this revision to Diff 3734. hselasky added a comment. Integrate changes after r278469. CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D1438?vs=3607&id=3734 REVISION DETAIL https://reviews.freebsd.org/D1438 AFFECTED FILES share/man/man9/Makefile share/man/man9/timeout.9 sys/kern/init_main.c sys/kern/kern_condvar.c sys/kern/kern_lock.c sys/kern/kern_switch.c sys/kern/kern_synch.c sys/kern/kern_thread.c sys/kern/kern_timeout.c sys/kern/subr_sleepqueue.c sys/ofed/include/linux/completion.h sys/sys/_callout.h sys/sys/callout.h sys/sys/proc.h To: hselasky, jhb, adrian, markj, emaste, sbruno, imp, lstewart, rwatson, gnn, rrs, kostikbel, delphij, neel, erj Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Feb 11 17:38:13 2015 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 6BB5CBE8 for ; Wed, 11 Feb 2015 17:38:13 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 17CEEFB9 for ; Wed, 11 Feb 2015 17:38:12 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id t1BHcBYY013091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 11 Feb 2015 10:38:11 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id t1BHcBYa013088; Wed, 11 Feb 2015 10:38:11 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Wed, 11 Feb 2015 10:38:11 -0700 (MST) From: Warren Block To: Matt Churchyard Subject: Re: Invalid subnet masks In-Reply-To: <7e069c1946454793b1c7e0be988877c4@SERVER.ad.usd-group.com> Message-ID: References: <7e069c1946454793b1c7e0be988877c4@SERVER.ad.usd-group.com> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Wed, 11 Feb 2015 10:38:11 -0700 (MST) 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, 11 Feb 2015 17:38:13 -0000 On Wed, 11 Feb 2015, Matt Churchyard wrote: > Just been helping someone on the forums who appears to have configured their network interface incorrectly. It looks like they've assigned 250.250.250.0 as the netmask. > I've tried assigning this netmask on a 10.1 machine and ifconfig happily accepts it. As a tangent to that question, ifconfig(8) and the rc.conf settings do accept CIDR notation, which is both shorter and clearer than a dotted quad IP address and a separate netmask: ifconfig em0 inet 192.168.1.1/24 From owner-freebsd-net@FreeBSD.ORG Wed Feb 11 17:49:53 2015 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 792C6265 for ; Wed, 11 Feb 2015 17:49:53 +0000 (UTC) Received: from smtp-outbound.userve.net (smtp-outbound.userve.net [217.196.1.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.userve.net", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B4E413B for ; Wed, 11 Feb 2015 17:49:52 +0000 (UTC) Received: from owa.usd-group.com (owa.usd-group.com [217.196.1.2]) by smtp-outbound.userve.net (8.14.7/8.14.7) with ESMTP id t1BHnaVc032054 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Feb 2015 17:49:36 GMT (envelope-from matt.churchyard@userve.net) Received: from SERVER.ad.usd-group.com (192.168.0.1) by SERVER.ad.usd-group.com (192.168.0.1) with Microsoft SMTP Server (TLS) id 15.0.516.32; Wed, 11 Feb 2015 17:49:36 +0000 Received: from SERVER.ad.usd-group.com ([fe80::b19d:892a:6fc7:1c9]) by SERVER.ad.usd-group.com ([fe80::b19d:892a:6fc7:1c9%12]) with mapi id 15.00.0516.029; Wed, 11 Feb 2015 17:49:35 +0000 From: Matt Churchyard To: Warren Block , "freebsd-net@freebsd.org" Subject: Re: Invalid subnet masks Thread-Topic: Invalid subnet masks Thread-Index: AdBF2FIuD1FE1aNwSWOzQAqD5/KpzwASS8SAAABl7w0= Date: Wed, 11 Feb 2015 17:49:35 +0000 Message-ID: References: <7e069c1946454793b1c7e0be988877c4@SERVER.ad.usd-group.com>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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, 11 Feb 2015 17:49:53 -0000 > On 11 Feb 2015, at 17:38, Warren Block wrote: >=20 >> On Wed, 11 Feb 2015, Matt Churchyard wrote: >>=20 >> Just been helping someone on the forums who appears to have configured t= heir network interface incorrectly. It looks like they've assigned 250.250.= 250.0 as the netmask. >> I've tried assigning this netmask on a 10.1 machine and ifconfig happily= accepts it. >=20 > As a tangent to that question, ifconfig(8) and the rc.conf settings do ac= cept CIDR notation, which is both shorter and clearer than a dotted quad IP= address and a separate netmask: >=20 > ifconfig em0 inet 192.168.1.1/24 Yeah I've been using that format in rc.conf for years. Quicker to type and = looks tidy.= From owner-freebsd-net@FreeBSD.ORG Wed Feb 11 20:29:16 2015 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 722F01DE for ; Wed, 11 Feb 2015 20:29:16 +0000 (UTC) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 34E0D676 for ; Wed, 11 Feb 2015 20:29:16 +0000 (UTC) Received: by mail-ig0-f179.google.com with SMTP id l13so7144845iga.0 for ; Wed, 11 Feb 2015 12:29:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=pPZaU47Ay3as3x1l4tKu3ReE9iHjjdPBUcvw3t9osyQ=; b=kJ7sCVXvsoEkTIVr+hrMDpDZfvvEfUyOZQR+ynLCX6I9xe6wLP1+27frmqHpV9gV/O 1C+2pmR6jkicMGvbzt0+vUfEivb59Cm5I+e8REGfVSUAkL14sjYfZxc18/TwyvPwDzUu oA/Z9ERI74aJOm7DfTGXTZCVaYod/S5AYCWd6aPDWnTwsY7TGvygjEnlUJvVf1gSy5E9 0rwoFLVkAasaI1B7YMnsYSX1BpOtqTNBeFVBEaLV/D+uglTt+X+5Sog+DYFz+KAO+D3o +8VsJzEKqJAnhQAHEmEjKxMHJu1En8c3maMSejYUToQr4epWTMaaE2gM3ICsP20FN2JE IngQ== X-Received: by 10.42.71.194 with SMTP id l2mr4837539icj.71.1423686555467; Wed, 11 Feb 2015 12:29:15 -0800 (PST) Received: from [10.1.69.81] (gs-sv-1-49-ac1.gsfc.nasa.gov. [198.119.56.43]) by mx.google.com with ESMTPSA id n17sm93851igi.2.2015.02.11.12.29.11 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Feb 2015 12:29:12 -0800 (PST) Message-ID: <54DBBB95.2050901@gmail.com> Date: Wed, 11 Feb 2015 15:29:09 -0500 From: John Jasen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: FreeBSD Net Subject: FreeBSD 10.1: Intel dual port 10GbE card (82599EB): second port not present? 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: Wed, 11 Feb 2015 20:29:16 -0000 I have several servers that have two Intel 10GbE ports on board. They're technically Dell daughterboards which have two Intel 1GbE and two 10GbE ports. However, the second ix interface is not accessible, and does not seem to be available. From a brief look, it looks like ix0 and both igb interfaces come up before SMP is started. The second ix interface is attempted afterwards, but doesn't show up. Am I missing the obvious? IE, from dmesg: ix0: port 0xfcc0-0xfcdf mem 0xd8d00000-0xd8dfffff,0xd8ff8000-0xd8ffbfff irq 36 at device 0.0 on pci1 ix0: Using MSIX interrupts with 9 vectors ix0: Unsupported SFP+ Module device_attach: ix0 attach returned 5 ix0: port 0xfce0-0xfcff mem 0xd8e00000-0xd8efffff,0xd8ffc000-0xd8ffffff irq 34 at device 0.1 on pci1 ix0: Using MSIX interrupts with 9 vectors ix0: Ethernet address: ec:f4:bb:c8:0b:12 ix0: PCI Express Bus: Speed 5.0GT/s Width x8 SMP: AP CPU #21 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #18 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #17 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #16 Launched! SMP: AP CPU #9 Launched! SMP: AP CPU #23 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #10 Launched! SMP: AP CPU #12 Launched! SMP: AP CPU #11 Launched! SMP: AP CPU #14 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #13 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #8 Launched! SMP: AP CPU #19 Launched! SMP: AP CPU #15 Launched! SMP: AP CPU #22 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #20 Launched! ix1: port 0xfcc0-0xfcdf mem 0xd8d00000-0xd8dfffff,0xd8ff8000-0xd8ffbfff irq 36 at device 0.0 on pci1 ix1: Using MSIX interrupts with 9 vectors ix1: Unsupported SFP+ Module device_attach: ix1 attach returned 5 ix1: port 0xfcc0-0xfcdf mem 0xd8d00000-0xd8dfffff,0xd8ff8000-0xd8ffbfff irq 36 at device 0.0 on pci1 ix1: Using MSIX interrupts with 9 vectors ix1: Unsupported SFP+ Module device_attach: ix1 attach returned 5 From owner-freebsd-net@FreeBSD.ORG Wed Feb 11 20:47:23 2015 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 BCCC0954 for ; Wed, 11 Feb 2015 20:47:23 +0000 (UTC) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 53777A41 for ; Wed, 11 Feb 2015 20:47:22 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id b13so6026282wgh.0 for ; Wed, 11 Feb 2015 12:47:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Lb9t0/uOrOCMq1XPKV9Ay6CL+ijN8e0vVzGIDFXIArM=; b=HtmSET7qJ++tICyArPeOny6ZC3zWKYz9SmHf9AZywnJPZHmg4+Jztz12U1UG5iXeMr jguE1f1jhYgQc4uOnz7BsbYM1N6eyFJa8A8hnJu5T6n9KQ4b9Xd/Y4kZ+Z42ENIUq6Ia JstW8S3gVw+WGIptIc61xGe6K7Qpe3ct9kBNmpJ7PTGu10QQ6vcELeTF6FcmmQs9UP5y Vl5PdONpQ+lWU8MdNgtRqILYRaDLKdCZvGcRq/kF6t/W+eZJFWqGOUkpEFnacpWLUt/A G+Vztc5i0G5F2q1ASxPVclDsLedfESKfRWJ9jyuT3AWFTXC6Phl7/NHRBvi1Aowo5A65 8tuQ== X-Gm-Message-State: ALoCoQnWIr+BjaDwCCsncyvusp7kKb6QglO2rZvbylnMrm9pdWAJl86I8i9x8ftIU50nzYhKbSsu X-Received: by 10.194.9.98 with SMTP id y2mr673472wja.85.1423687640608; Wed, 11 Feb 2015 12:47:20 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id bi9sm24784367wib.18.2015.02.11.12.47.17 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Feb 2015 12:47:19 -0800 (PST) Message-ID: <54DBBFD3.7010801@multiplay.co.uk> Date: Wed, 11 Feb 2015 20:47:15 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: FreeBSD 10.1: Intel dual port 10GbE card (82599EB): second port not present? References: <54DBBB95.2050901@gmail.com> In-Reply-To: <54DBBB95.2050901@gmail.com> 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, 11 Feb 2015 20:47:23 -0000 On 11/02/2015 20:29, John Jasen wrote: > I have several servers that have two Intel 10GbE ports on board. They're > technically Dell daughterboards which have two Intel 1GbE and two 10GbE > ports. > > However, the second ix interface is not accessible, and does not seem to > be available. From a brief look, it looks like ix0 and both igb > interfaces come up before SMP is started. The second ix interface is > attempted afterwards, but doesn't show up. > > Am I missing the obvious? > > IE, from dmesg: > > ix0: > port 0xfcc0-0xfcdf mem 0xd8d00000-0xd8dfffff,0xd8ff8000-0xd8ffbfff > irq 36 at device 0.0 on pci1 > ix0: Using MSIX interrupts with 9 vectors > ix0: Unsupported SFP+ Module > device_attach: ix0 attach returned 5 > > ix0: > port 0xfce0-0xfcff mem 0xd8e00000-0xd8efffff,0xd8ffc000-0xd8ffffff > irq 34 at device 0.1 on pci1 > ix0: Using MSIX interrupts with 9 vectors > ix0: Ethernet address: ec:f4:bb:c8:0b:12 > ix0: PCI Express Bus: Speed 5.0GT/s Width x8 > > > > SMP: AP CPU #21 Launched! > SMP: AP CPU #1 Launched! > SMP: AP CPU #18 Launched! > SMP: AP CPU #5 Launched! > SMP: AP CPU #17 Launched! > SMP: AP CPU #2 Launched! > SMP: AP CPU #16 Launched! > SMP: AP CPU #9 Launched! > SMP: AP CPU #23 Launched! > SMP: AP CPU #3 Launched! > SMP: AP CPU #10 Launched! > SMP: AP CPU #12 Launched! > SMP: AP CPU #11 Launched! > SMP: AP CPU #14 Launched! > SMP: AP CPU #7 Launched! > SMP: AP CPU #13 Launched! > SMP: AP CPU #4 Launched! > SMP: AP CPU #8 Launched! > SMP: AP CPU #19 Launched! > SMP: AP CPU #15 Launched! > SMP: AP CPU #22 Launched! > SMP: AP CPU #6 Launched! > SMP: AP CPU #20 Launched! > > > > ix1: > port 0xfcc0-0xfcdf mem 0xd8d00000-0xd8dfffff,0xd8ff8000-0xd8ffbfff irq > 36 at device 0.0 on pci1 > ix1: Using MSIX interrupts with 9 vectors > ix1: Unsupported SFP+ Module > device_attach: ix1 attach returned 5 > > > > ix1: > port 0xfcc0-0xfcdf mem 0xd8d00000-0xd8dfffff,0xd8ff8000-0xd8ffbfff irq > 36 at device 0.0 on pci1 > ix1: Using MSIX interrupts with 9 vectors > ix1: Unsupported SFP+ Module > device_attach: ix1 attach returned 5 Your problem looks like its the SFP's which are "unsupported" to which the attach will fail with error EIO (5). You can set hw.ix.unsupported_sfp=1 in /boot/loader.conf to enable unsupported SFP's but be aware you "doing so your on your own". Regards Steve From owner-freebsd-net@FreeBSD.ORG Wed Feb 11 21:30:00 2015 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 BDAFB70C for ; Wed, 11 Feb 2015 21:30:00 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 9BDE9FA0 for ; Wed, 11 Feb 2015 21:30:00 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 39CD81941DD; Wed, 11 Feb 2015 21:29:59 +0000 (UTC) Message-ID: <54DBC9D6.7020602@ignoranthack.me> Date: Wed, 11 Feb 2015 13:29:58 -0800 From: Sean Bruno Reply-To: sbruno@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Sepherosa Ziehau Subject: Re: Intel 82574L (em) References: <54CBF396.3090903@ignoranthack.me> In-Reply-To: Content-Type: text/plain; charset=utf-8 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: Wed, 11 Feb 2015 21:30:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/10/15 18:49, Sepherosa Ziehau wrote: > On Sat, Jan 31, 2015 at 5:11 AM, Sean Bruno > wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >> >> http://www.intel.com/content/dam/doc/datasheet/82574l-gbe-controller-datasheet.pdf >> >> >> According to 7.1.11, this device does indeed have 2 queues for stuff and >> or things. So, basic RSS would be possible in something like an >> Atom box. >> >> I note that the em(4) driver intentionally disables this on >> initialization. I'm up for some science on my new shiny, soon to >> be router box. Any reason not to default to 1 queue and allow >> loader.conf to raise it to 2? > > You could actually enable 2 RX rings w/o MSI-X on 82574; you still > get the benefit of hardware calculated RSS hash at least. And as > far as I have tested, 2 RX rings work for 82574L, but 2 TX rings > don't work (gave me TX watchdog timeout). And you could also use 2 > RX rings on 82571/82572/82573 and i217/i218; 2 TX rings work on > 82571 at least (you need to setup TX context for each TX descriptor > though). > > Best Regards, sephe > > I'm interested in doing this a bit as I now have 5 em(4) interfaces on my soon to be router box. I tried modifying the driver to allow num_queues to be raised and I compiled with EM_MULTIQUEUE set, and all I got for my trouble was kernel panics. I'm not sure if the code even works. sean -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJU28nOXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5k+vMIAKaDtSR6Rr4jHnojPH0K8bbv 35khkxhHiPjynRRUxOtJXqlGu8rQ2s1L3hW8V+sKYq/sI+pjmVTMrRko6+nIdDf/ bJe20S1EQxbhm74HbO28hNnG5uBjNfEP0hwEuaZHRdenua1TtnmMSnWqOh7xT1i1 3573Bx2WulgYaEEtYmnXX5x5E8C8ks6Lr4ZQptkGPJXDBtw3v59/oc2GK/P3tixL QvNPkYbFkLn+9tD6kjy05E92BOpUG84u37rlldajxXzpRkN7xaczKMERQ2VZD4lD 8b48F4im/iElJ6fsvUSJhzqW+H/ywBOgaJEjDXJgzrz0ffaMwY8vfpp4cmDkzCE= =rlKy -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Wed Feb 11 21:30:33 2015 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 A3A2C7A1; Wed, 11 Feb 2015 21:30:33 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 806438F; Wed, 11 Feb 2015 21:30:33 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 793E91941DD; Wed, 11 Feb 2015 21:30:32 +0000 (UTC) Message-ID: <54DBC9F7.2060605@ignoranthack.me> Date: Wed, 11 Feb 2015 13:30:31 -0800 From: Sean Bruno Reply-To: sbruno@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Adrian Chadd , Sepherosa Ziehau Subject: Re: Intel 82574L (em) References: <54CBF396.3090903@ignoranthack.me> In-Reply-To: Content-Type: text/plain; charset=utf-8 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: Wed, 11 Feb 2015 21:30:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/10/15 19:09, Adrian Chadd wrote: > ... you can still use 1 TX/1 RX ring on -HEAD. If we turn on RSS > in the driver and have it hardware hash things, then the netisr > input routine will throw it into the right per-CPU queue and it'll > distribute the work. > > (Someone could twist my arm to do this.) > > > -adrian > > That was kind of where I was going with all this. I'm interested in doing some science, but have to get the driver to not panic the box first. sean -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJU28n3XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kT8cIAJM27xGH1kXdA2e0hrg4RFoe EN1SlsnN/rp31N5EMkCbPiZQxcok0586mbscxwJZN6AsouWWQHjdtFWIeX+tdxgK dpPojJG1OXrC5cmGYdAxiXOyIM3HGKfFQV4CFJRX53MQ4KeWQ4SIBeRaKJ3vTbgo Aaad0NyvrpVo13N9UAVSd18FtIJPrWwnukXTRvKidyFtkoBGRlBo4ZKcqLZVdpWE U6UR93N/MgXFWR06fmx5oeIlGsET3NepI5xU6IKPhvIXKy9VHINtMAJjMzlq4QwF 460L6BFElx3gE+H2lohlZMy6OA/qIrsSEqHmG1613XpQ5k/ymP9Z/HtTjHSplcE= =BXLu -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Wed Feb 11 22:07:59 2015 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 2D0D0FF6; Wed, 11 Feb 2015 22:07:59 +0000 (UTC) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DBB593EF; Wed, 11 Feb 2015 22:07:58 +0000 (UTC) Received: by mail-yh0-f49.google.com with SMTP id f10so2506054yha.8; Wed, 11 Feb 2015 14:07:58 -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=3WiBamgK1SNW0BNsCg84Bg+36I/zb162Q22y9MriHfc=; b=02Yc114EuePmE2sQaHr+yjyKIypOgsdxEthCu+M92B/6smi+I51UqlSe4cEZxYNuFf pUjQ8aTXdDd1qSnRiiSR5cliUdl4NaNk6yJCVhNl67E/iiCE1VYXtJ5KV+O0ihSvcmju ThLGMqWR53OUyak2SPx+1mV7Zssnj2swHsHgzogZRQ9UhpOTIn97HPXknOAhFzXp4z/z txbqVJyDh7qL0QFH6S9lGJHzuRwb2gHsJcyNTPZQj2w9bzqEN0TPsk5niQyXmikDh57U rSVIGMuXbPVebQeTgON2OdjUpkEiM8o8mjpEScujsWGRW2vCqctbwRLRbL3OPOeVw4iC x/Gg== MIME-Version: 1.0 X-Received: by 10.236.228.66 with SMTP id e62mr624275yhq.117.1423692477959; Wed, 11 Feb 2015 14:07:57 -0800 (PST) Sender: kmacybsd@gmail.com Received: by 10.170.40.148 with HTTP; Wed, 11 Feb 2015 14:07:57 -0800 (PST) In-Reply-To: <54DBC9D6.7020602@ignoranthack.me> References: <54CBF396.3090903@ignoranthack.me> <54DBC9D6.7020602@ignoranthack.me> Date: Wed, 11 Feb 2015 14:07:57 -0800 X-Google-Sender-Auth: 3aEg8T6HqLyWZorwr8eRJsqqRHg Message-ID: Subject: Re: Intel 82574L (em) From: "K. Macy" To: Sean Bruno Content-Type: text/plain; charset=UTF-8 Cc: Sepherosa Ziehau , "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, 11 Feb 2015 22:07:59 -0000 > > I'm interested in doing this a bit as I now have 5 em(4) interfaces on > my soon to be router box. > > I tried modifying the driver to allow num_queues to be raised and I > compiled with EM_MULTIQUEUE set, and all I got for my trouble was > kernel panics. > > I'm not sure if the code even works. > IIRC that was really just enabling buf_ring usage. In any event I don't think it's been maintained in upwards of 7 years. -K From owner-freebsd-net@FreeBSD.ORG Thu Feb 12 00:04:42 2015 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 B0A12C0B for ; Thu, 12 Feb 2015 00:04:42 +0000 (UTC) Received: from thyme.infocus-llc.com (thyme.infocus-llc.com [199.15.120.10]) (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 85D191CB for ; Thu, 12 Feb 2015 00:04:42 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id E3A6B37B403; Wed, 11 Feb 2015 18:04:34 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3kjJ422KNYz1lV; Wed, 11 Feb 2015 18:04:34 -0600 (CST) Date: Wed, 11 Feb 2015 18:04:34 -0600 From: "Matthew D. Fuller" To: Matt Churchyard Subject: Re: Invalid subnet masks Message-ID: <20150212000434.GA15127@over-yonder.net> References: <7e069c1946454793b1c7e0be988877c4@SERVER.ad.usd-group.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.23-fullermd.4 (2014-03-12) X-Virus-Scanned: clamav-milter 0.98.6 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: Warren Block , "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, 12 Feb 2015 00:04:42 -0000 On Wed, Feb 11, 2015 at 05:49:35PM +0000 I heard the voice of Matt Churchyard, and lo! it spake thus: > > On 11 Feb 2015, at 17:38, Warren Block wrote: > > ifconfig em0 inet 192.168.1.1/24 > > Yeah I've been using that format in rc.conf for years. Quicker to > type and looks tidy. Ditto. Though in the grand tradition of being given the inch and lusting after the mile, it makes me grumpy seeing the dotted-quad netmask in 'ifconfig' output, making me have to work to see if the match and back-convert to add things. 8-} -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-net@FreeBSD.ORG Thu Feb 12 09:53:39 2015 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 594B18C1 for ; Thu, 12 Feb 2015 09:53:39 +0000 (UTC) Received: from smtp-outbound.userve.net (smtp-outbound.userve.net [217.196.1.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.userve.net", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DBD18867 for ; Thu, 12 Feb 2015 09:53:38 +0000 (UTC) Received: from owa.usd-group.com (owa.usd-group.com [217.196.1.2]) by smtp-outbound.userve.net (8.14.7/8.14.7) with ESMTP id t1C9rGYg056917 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Feb 2015 09:53:16 GMT (envelope-from matt.churchyard@userve.net) Received: from SERVER.ad.usd-group.com (192.168.0.1) by SERVER.ad.usd-group.com (192.168.0.1) with Microsoft SMTP Server (TLS) id 15.0.516.32; Thu, 12 Feb 2015 09:53:15 +0000 Received: from SERVER.ad.usd-group.com ([fe80::b19d:892a:6fc7:1c9]) by SERVER.ad.usd-group.com ([fe80::b19d:892a:6fc7:1c9%12]) with mapi id 15.00.0516.029; Thu, 12 Feb 2015 09:53:15 +0000 From: Matt Churchyard To: "Matthew D. Fuller" Subject: RE: Invalid subnet masks Thread-Topic: Invalid subnet masks Thread-Index: AdBF2FIuD1FE1aNwSWOzQAqD5/KpzwASS8SAAABl7w0ADRiaAAATMrmw Date: Thu, 12 Feb 2015 09:53:15 +0000 Message-ID: References: <7e069c1946454793b1c7e0be988877c4@SERVER.ad.usd-group.com> <20150212000434.GA15127@over-yonder.net> In-Reply-To: <20150212000434.GA15127@over-yonder.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.0.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Warren Block , "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, 12 Feb 2015 09:53:39 -0000 > On Wed, Feb 11, 2015 at 05:49:35PM +0000 I heard the voice of Matt Church= yard, and lo! it spake thus: > > > On 11 Feb 2015, at 17:38, Warren Block wrote: > > > ifconfig em0 inet 192.168.1.1/24 > >=20 > > Yeah I've been using that format in rc.conf for years. Quicker to type= =20 > > and looks tidy. > Ditto. Though in the grand tradition of being given the inch and lusting= after the mile, it makes me grumpy seeing the dotted-quad netmask in 'ifco= nfig' output, making me have to work > to see if the > match and back-convert to add things. 8-} It's actually hex format in ifconfig unless I'm missing something ;)=20 The discussion on -hackers linked earlier in this thread was actually a con= versation about changing the output to dotted quad, then it moved on to pro= viding a switch to allow users to specify dotted quad or CIDR notation. Obv= iously it was never implemented although you don't really want to mess with= the output of established core commands unless there's good reason. From owner-freebsd-net@FreeBSD.ORG Thu Feb 12 14:30:18 2015 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 E7C9C822 for ; Thu, 12 Feb 2015 14:30:17 +0000 (UTC) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A610A9FF for ; Thu, 12 Feb 2015 14:30:17 +0000 (UTC) Received: by mail-ig0-f176.google.com with SMTP id hl2so3957494igb.3 for ; Thu, 12 Feb 2015 06:30:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=EzooeoPtLhZf8axTSdwkOOFZBMbf+RRJzuG3UfIu1fs=; b=ufRLp80vydkvDel0hnSXPMSU0fSpgofopLuNp0H/2Smdpx4Jk89yWK5KFjjo8aCduK mJ8PzNHg9WtkZ5uOCny8SYPeUIAu3czY6JYejmA4Cy1U2Q4MNpf/aCDeFlt+mfLbsfR5 DZLtDDgpqrpPyLGdvLm0UtHfIGWtIga8yJ1aFhF1CalGoIJs7ejvxzPbDWx8UvV/FF1k NbWoYJsz2o1uwX3uzj8McaOdeH+yVlGl17HlvOLImC7WGFAZCRRb1PuHwHKmH8haJTpu qCGbVROYJhxSAya9mDZFpVTd2N2mtbMgKN4z87ts/qjM/FyDFZfv2vTVNYhyfEqz9tdl eMGw== X-Received: by 10.107.40.131 with SMTP id o125mr4974617ioo.5.1423751416926; Thu, 12 Feb 2015 06:30:16 -0800 (PST) Received: from [10.1.69.81] (gs-sv-1-49-ac1.gsfc.nasa.gov. [198.119.56.43]) by mx.google.com with ESMTPSA id ie15sm1277131igb.12.2015.02.12.06.30.12 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Feb 2015 06:30:12 -0800 (PST) Message-ID: <54DCB8F2.5090809@gmail.com> Date: Thu, 12 Feb 2015 09:30:10 -0500 From: John Jasen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: FreeBSD 10.1: Intel dual port 10GbE card (82599EB) second port not present? (Steven Hartland) References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 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: Thu, 12 Feb 2015 14:30:18 -0000 > Date: Wed, 11 Feb 2015 20:47:15 +0000 > From: Steven Hartland > To: freebsd-net@freebsd.org > Subject: Re: FreeBSD 10.1: Intel dual port 10GbE card (82599EB): > second port not present? > Message-ID: <54DBBFD3.7010801@multiplay.co.uk> > Content-Type: text/plain; charset=windows-1252; format=flowed > Your problem looks like its the SFP's which are "unsupported" to which > the attach will fail with error EIO (5). > > You can set hw.ix.unsupported_sfp=1 in /boot/loader.conf to enable > unsupported SFP's but be aware you "doing so your on your own". Thanks! hw.ix.unsupported_sfp=1 corrected the immediate problem. The network port that didn't come up does not yet have an SFP module installed It seems the default behavior in FreeBSD is to not have the interface available until a SFP is inserted. While a corner case, this does make configuration prior to installation a bit more annoying. From owner-freebsd-net@FreeBSD.ORG Thu Feb 12 16:11:41 2015 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 86823D0B for ; Thu, 12 Feb 2015 16:11:41 +0000 (UTC) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 170DC7E6 for ; Thu, 12 Feb 2015 16:11:41 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id b13so11169109wgh.0 for ; Thu, 12 Feb 2015 08:11:39 -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=DXaAZzv3cbhnAy6rRk745QMak39bY5nLfdTvAunzw00=; b=jlKecthms1LJu2mBpUG8cEM19i2hlKPJ9w0yVBQXfQgl+GfIhrfi9T2R36xyMhfq43 AIOtYaTnw/VefbBdhzB/o2BRy+9umYQMgvax55Fy9oZOBDUlvBUeckYQX3mwIza2pkZZ ssZcV8RkUEKJEio+8zMEkdpfU9f00xbo8bkMD7hJaWVOsQObIdJxoipqKhIuwvvnC30D C8LF5lu3dHWvY/cgZK5r09Zfot19i71boH1hSwy3Bgh2NtPGAlVlAppYgEs9HhW/6plU 0AntdzvukKye3oS9YOPb3j7AFI2s/I81ukirP+jzFm8c7a0E+hvJvS4PtyuUzfFRsq78 B4Dw== MIME-Version: 1.0 X-Received: by 10.180.95.162 with SMTP id dl2mr7502727wib.31.1423757498945; Thu, 12 Feb 2015 08:11:38 -0800 (PST) Received: by 10.194.101.106 with HTTP; Thu, 12 Feb 2015 08:11:38 -0800 (PST) In-Reply-To: <54DCB8F2.5090809@gmail.com> References: <54DCB8F2.5090809@gmail.com> Date: Thu, 12 Feb 2015 08:11:38 -0800 Message-ID: Subject: Re: FreeBSD 10.1: Intel dual port 10GbE card (82599EB) second port not present? (Steven Hartland) From: Jack Vogel To: John Jasen Content-Type: text/plain; charset=ISO-8859-1 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: Thu, 12 Feb 2015 16:11:41 -0000 On Thu, Feb 12, 2015 at 6:30 AM, John Jasen wrote: > > > Date: Wed, 11 Feb 2015 20:47:15 +0000 > > From: Steven Hartland > > To: freebsd-net@freebsd.org > > Subject: Re: FreeBSD 10.1: Intel dual port 10GbE card (82599EB): > > second port not present? > > Message-ID: <54DBBFD3.7010801@multiplay.co.uk> > > Content-Type: text/plain; charset=windows-1252; format=flowed > > > > > Your problem looks like its the SFP's which are "unsupported" to which > > the attach will fail with error EIO (5). > > > > You can set hw.ix.unsupported_sfp=1 in /boot/loader.conf to enable > > unsupported SFP's but be aware you "doing so your on your own". > > Thanks! hw.ix.unsupported_sfp=1 corrected the immediate problem. > > The network port that didn't come up does not yet have an SFP module > installed > > It seems the default behavior in FreeBSD is to not have the interface > available until a SFP is inserted. While a corner case, this does make > configuration prior to installation a bit more annoying. > > > Well, exactly what use would there be in having it "available" with no media, its like saying you want your car available with no wheels :) The media can make operation quite different, it could be copper it could be fiber, the driver won't know until there is something actually present, hence it cannot really do "init" until then. Jack > > > _______________________________________________ > 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 Feb 12 18:53:56 2015 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 58A333C6 for ; Thu, 12 Feb 2015 18:53:56 +0000 (UTC) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CD8B7C2E for ; Thu, 12 Feb 2015 18:53:55 +0000 (UTC) Received: by mail-lb0-f176.google.com with SMTP id u10so11414782lbd.7 for ; Thu, 12 Feb 2015 10:53:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=SJIAKqGGpVJVjxt2oYGNU0QX+uJF/brWRDghinFYN8E=; b=gDR7GgLM/oAIyN4n17Ewn21j+oxqGjc4O7l+lswQlTOO6m39TIjePFc+VXrK4neznK 8eJ2/9msQF2IyAUcMLQG1noQ5x1mexupZVyHmMN2rKqLYAIYcXvLw87fRWpxJTXE6d18 spIYbWEkQGQqW88cPsFURaJELGLYcxr5Ku1djow9uTtIXXhR8+lJbSy9tIgCcr1LYhZC oTm1ee9EKIGz8z7EA9MVLy4JbjnhMl4Ki1ZOuYMR4dpT//mAOWgkRdweOybDT9aWw+H1 ofP86ZRAqTov+gIL7o9k/ik0I2EqLm6se8zXDzkct+HfuAVgNgt2k+pu0caLI4cGwu0W mSuA== MIME-Version: 1.0 X-Received: by 10.152.45.1 with SMTP id i1mr4568805lam.41.1423767233463; Thu, 12 Feb 2015 10:53:53 -0800 (PST) Received: by 10.25.198.131 with HTTP; Thu, 12 Feb 2015 10:53:53 -0800 (PST) Date: Thu, 12 Feb 2015 19:53:53 +0100 Message-ID: Subject: Was Re: FreeBSD 10.1: Intel dual port 10GbE card (82599EB) second port not present?: SFP+ on intel xl710 From: Andreas Nilsson To: FreeBSD Net 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: Thu, 12 Feb 2015 18:53:56 -0000 Hello, the discussion about unsupported sfps on intel card got an interesting turn today: a colleague wanted to do some pps (on linux) testing on an intel xl710 card, but the sfps we had was not supported. Reading the previous thread, I suggested there might be a sysctl to accept "other" sfps. Long story short, just for fun we booted a FreeBSD 10.1 system, and the card was recognized ( yay! ) but still "no carrier" from ifconfig. sysctl hw.ixl didn't show any tunables for "unsupported_sfp". Is this chip more picky about the tranceivers? Best regards Andreas Nilsson From owner-freebsd-net@FreeBSD.ORG Thu Feb 12 19:12:59 2015 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 8C0556CD; Thu, 12 Feb 2015 19:12:59 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0115.outbound.protection.outlook.com [65.55.169.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E42B9DEE; Thu, 12 Feb 2015 19:12:58 +0000 (UTC) Received: from CO2PR05MB761.namprd05.prod.outlook.com (10.141.227.13) by CO2PR05MB761.namprd05.prod.outlook.com (10.141.227.13) with Microsoft SMTP Server (TLS) id 15.1.81.19; Thu, 12 Feb 2015 18:56:51 +0000 Received: from CO2PR05MB761.namprd05.prod.outlook.com ([10.141.227.13]) by CO2PR05MB761.namprd05.prod.outlook.com ([10.141.227.13]) with mapi id 15.01.0081.018; Thu, 12 Feb 2015 18:56:51 +0000 From: Sreekanth Rupavatharam To: Jack Vogel Subject: Re: Double cleanup in igb_attach Thread-Topic: Double cleanup in igb_attach Thread-Index: AQHQOcQ8M6DG1/D37kKlfeofCj44QJzUW0EA//+AdgCAAIzTgIAAAX8YgAAA4YCAAAQUE4AAAPkAgBiB44A= Date: Thu, 12 Feb 2015 18:56:51 +0000 Message-ID: References: <20150127192814.GA63990@strugglingcoder.info> <26266AD2-4743-4A7B-A87D-F68E2E2425A0@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [66.129.239.14] authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB761; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB761; x-forefront-prvs: 0485417665 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(164054003)(479174004)(377454003)(35774003)(66066001)(102836002)(2950100001)(92566002)(77096005)(83506001)(16236675004)(87936001)(2656002)(36756003)(99286002)(86362001)(106116001)(19580395003)(19580405001)(2900100001)(93886004)(110136001)(62966003)(40100003)(50986999)(46102003)(77156002)(122556002)(54356999)(76176999)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB761; H:CO2PR05MB761.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2015 18:56:51.4183 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB761 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "jfv@freebsd.org" , "freebsd-net@freebsd.org" , hiren panchasara 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, 12 Feb 2015 19:12:59 -0000 Hi Jack, Actually, looking at the code again, it seems to me that igb_detach is not = supposed to be called from igb_attach at all. It causes more problems than = previously mentioned. E.g., in case of branching to err_late *before* igb_= setup_interface(where the ifp is initialized), calling igb_detach there cau= ses a NULL pointer access. The best way to deal with it is to take out the = igb_detach call from the err_late: label. Thoughts? Comments? -- Thanks, Sreekanth From: Jack Vogel > Date: Tuesday, January 27, 2015 at 12:42 PM To: Sreekanth Rupavatharam > Cc: hiren panchasara >, "freebsd-net@freebsd.org" >, "jfv@freebsd.org" > Subject: Re: Double cleanup in igb_attach Yes, I will look them over. Jack On Tue, Jan 27, 2015 at 12:38 PM, Sreekanth Rupavatharam > wrote: Thanks jack, Now, can you please review these changes? And commit if you deem it fi= t? Thanks, -Sreekanth On Jan 27, 2015, at 12:24 PM, "Jack Vogel" > wrote: Errrr, I am one of those people :) (jack.vogel@intel.com) Jack On Tue, Jan 27, 2015 at 12:21 PM, Sreekanth Rupavatharam > wrote: Definitely, but I didn't have the contact info of those people. Thanks, -Sreekanth On Jan 27, 2015, at 12:15 PM, "Jack Vogel" > wrote: If you want something committed to an Intel driver, asking Intel might be t= he courteous thing to do, don't you think? Jack On Tue, Jan 27, 2015 at 11:51 AM, Sreekanth Rupavatharam > wrote: Hiren, Can you help commit this? Index: if_igb.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_igb.c(revision 298053) +++ if_igb.c(working copy) @@ -723,7 +723,8 @@ igb_attach(device_t dev) return (0); err_late: -igb_detach(dev); +if(igb_detach(dev) =3D=3D 0) /* igb_detach did the cleanup */ +return(error); igb_free_transmit_structures(adapter); igb_free_receive_structures(adapter); igb_release_hw_control(adapter); -- Thanks, Sreekanth On 1/27/15, 11:28 AM, "hiren panchasara" > wrote: + Jack On Tue, Jan 27, 2015 at 12:00:19AM +0000, Sreekanth Rupavatharam wrote: Apologies if this is not the right forum. In igb_attach function, we have t= his code. err_late: igb_detach(dev); igb_free_transmit_structures(adapter); igb_free_receive_structures(adapter); igb_release_hw_control(adapter); err_pci: igb_free_pci_resources(adapter); if (adapter->ifp !=3D NULL) if_free(adapter->ifp); free(adapter->mta, M_DEVBUF); IGB_CORE_LOCK_DESTROY(adapter); The problem is that igb_detach also does the same cleanup in it?s body. Onl= y exception is this case where it just returns EBUSY /* Make sure VLANS are not using driver */ if (if_vlantrunkinuse(ifp)) { device_printf(dev,"Vlan in use, detach first\n"); return (EBUSY); } I think the code in igb_attach should be changed to free up resources only = if the igb_detach returns an error. Here?s the patch for it. Index: if_igb.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_igb.c (revision 298025) +++ if_igb.c (working copy) @@ -723,7 +723,8 @@ igb_attach(device_t dev) return (0); err_late: - igb_detach(dev); + if(igb_detach(dev) =3D=3D 0) /* igb_detach did the cleanup */ + return; igb_free_transmit_structures(adapter); Can anyone comment on it and tell me if my understanding is incorrect? Seems reasonable to me at the first glance. We need to call IGB_CORE_LOCK_DESTROY(adapter) before returning though. cheers, Hiren From owner-freebsd-net@FreeBSD.ORG Thu Feb 12 20:00:14 2015 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 A2ECA2A4; Thu, 12 Feb 2015 20:00:14 +0000 (UTC) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 24785257; Thu, 12 Feb 2015 20:00:14 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id n12so12475579wgh.2; Thu, 12 Feb 2015 12:00:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UCKNYlxN5ys/T1JV5k1pCgT0PozS0yxTbefLZCnx0ZM=; b=ACqqyJeg/fdj4NmDUaVOhs1zZHAFcFymqsNnHXVZ9GQ6BaH9or4UpUJYeNIiZDLeg+ Y0ei6aD48QdQ7CRzHpiYKucc7WowiB+X81kCHwJh9E4cAmih1DXNvuuGFsosCBjQjC0d OC3RIsFQZ1VucQMl4ElPc8wWTYFdF0vNs5u9J1zkORfQ0CApK692VGDgcO8SZzzYL/pI kihSAL3DOWArNKQl8Cb0zt7Z7wtvDiC0LfWjDG71V3RL5z8SPhh07HK++53cvi744cgy 6p+iAQ2S9XahNHOMalv8I7ccfYJVLWsIwxfuThJmzoQs8VsCe3+K/zc6CeQBBJ8DTUf1 NkVw== MIME-Version: 1.0 X-Received: by 10.194.5.168 with SMTP id t8mr11386248wjt.150.1423771212550; Thu, 12 Feb 2015 12:00:12 -0800 (PST) Received: by 10.194.101.106 with HTTP; Thu, 12 Feb 2015 12:00:12 -0800 (PST) In-Reply-To: References: <20150127192814.GA63990@strugglingcoder.info> <26266AD2-4743-4A7B-A87D-F68E2E2425A0@juniper.net> Date: Thu, 12 Feb 2015 12:00:12 -0800 Message-ID: Subject: Re: Double cleanup in igb_attach From: Jack Vogel To: Sreekanth Rupavatharam Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "jfv@freebsd.org" , "freebsd-net@freebsd.org" , hiren panchasara 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, 12 Feb 2015 20:00:14 -0000 I do not recall if I put that call in myself and, yes, it seems odd. It was probably trying to clean up some bad state a failed attach left things in. If it is removed it should be thoroughly regression tested. Jack On Thu, Feb 12, 2015 at 10:56 AM, Sreekanth Rupavatharam < rupavath@juniper.net> wrote: > Hi Jack, > Actually, looking at the code again, it seems to me that igb_detach is not > supposed to be called from igb_attach at all. It causes more problems than > previously mentioned. E.g., in case of branching to err_late *before* > igb_setup_interface(where the ifp is initialized), calling igb_detach there > causes a NULL pointer access. The best way to deal with it is to take out > the igb_detach call from the err_late: label. Thoughts? Comments? > -- Thanks, > > Sreekanth > > > > From: Jack Vogel > Date: Tuesday, January 27, 2015 at 12:42 PM > To: Sreekanth Rupavatharam > Cc: hiren panchasara , " > freebsd-net@freebsd.org" , "jfv@freebsd.org" < > jfv@freebsd.org> > Subject: Re: Double cleanup in igb_attach > > Yes, I will look them over. > > Jack > > > On Tue, Jan 27, 2015 at 12:38 PM, Sreekanth Rupavatharam < > rupavath@juniper.net> wrote: > >> Thanks jack, >> Now, can you please review these changes? And commit if you deem it >> fit? >> >> Thanks, >> >> -Sreekanth >> >> On Jan 27, 2015, at 12:24 PM, "Jack Vogel" wrote: >> >> Errrr, I am one of those people :) (jack.vogel@intel.com) >> >> Jack >> >> >> On Tue, Jan 27, 2015 at 12:21 PM, Sreekanth Rupavatharam < >> rupavath@juniper.net> wrote: >> >>> Definitely, but I didn't have the contact info of those people. >>> >>> Thanks, >>> >>> -Sreekanth >>> >>> On Jan 27, 2015, at 12:15 PM, "Jack Vogel" wrote: >>> >>> If you want something committed to an Intel driver, asking Intel >>> might be the >>> courteous thing to do, don't you think? >>> >>> Jack >>> >>> >>> On Tue, Jan 27, 2015 at 11:51 AM, Sreekanth Rupavatharam < >>> rupavath@juniper.net> wrote: >>> >>>> Hiren, >>>> Can you help commit this? >>>> >>>> Index: if_igb.c >>>> >>>> =================================================================== >>>> >>>> --- if_igb.c(revision 298053) >>>> >>>> +++ if_igb.c(working copy) >>>> >>>> @@ -723,7 +723,8 @@ igb_attach(device_t dev) >>>> >>>> return (0); >>>> >>>> >>>> >>>> err_late: >>>> >>>> -igb_detach(dev); >>>> >>>> +if(igb_detach(dev) == 0) /* igb_detach did the cleanup */ >>>> >>>> +return(error); >>>> >>>> igb_free_transmit_structures(adapter); >>>> >>>> igb_free_receive_structures(adapter); >>>> >>>> igb_release_hw_control(adapter); >>>> >>>> -- Thanks, >>>> >>>> Sreekanth >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 1/27/15, 11:28 AM, "hiren panchasara" >>>> wrote: >>>> >>>> + Jack >>>> On Tue, Jan 27, 2015 at 12:00:19AM +0000, Sreekanth Rupavatharam wrote: >>>> >>>> Apologies if this is not the right forum. In igb_attach function, we >>>> have this code. >>>> err_late: >>>> igb_detach(dev); >>>> igb_free_transmit_structures(adapter); >>>> igb_free_receive_structures(adapter); >>>> igb_release_hw_control(adapter); >>>> err_pci: >>>> igb_free_pci_resources(adapter); >>>> if (adapter->ifp != NULL) >>>> if_free(adapter->ifp); >>>> free(adapter->mta, M_DEVBUF); >>>> IGB_CORE_LOCK_DESTROY(adapter); >>>> The problem is that igb_detach also does the same cleanup in it?s >>>> body. Only exception is this case where it just returns EBUSY >>>> /* Make sure VLANS are not using driver */ >>>> if (if_vlantrunkinuse(ifp)) { >>>> device_printf(dev,"Vlan in use, detach first\n"); >>>> return (EBUSY); >>>> } >>>> I think the code in igb_attach should be changed to free up resources >>>> only if the igb_detach returns an error. Here?s the patch for it. >>>> Index: if_igb.c >>>> =================================================================== >>>> --- if_igb.c (revision 298025) >>>> +++ if_igb.c (working copy) >>>> @@ -723,7 +723,8 @@ igb_attach(device_t dev) >>>> return (0); >>>> err_late: >>>> - igb_detach(dev); >>>> + if(igb_detach(dev) == 0) /* igb_detach did the cleanup */ >>>> + return; >>>> igb_free_transmit_structures(adapter); >>>> Can anyone comment on it and tell me if my understanding is >>>> incorrect? >>>> >>>> >>>> Seems reasonable to me at the first glance. >>>> >>>> We need to call IGB_CORE_LOCK_DESTROY(adapter) before returning >>>> though. >>>> >>>> cheers, >>>> Hiren >>>> >>>> >>> >> > From owner-freebsd-net@FreeBSD.ORG Thu Feb 12 20:10:00 2015 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 B2CE5512 for ; Thu, 12 Feb 2015 20:10:00 +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 9304536C for ; Thu, 12 Feb 2015 20:10:00 +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 t1CJvaVJ096849 for ; Thu, 12 Feb 2015 19:57:36 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 t1CJvacv096848; Thu, 12 Feb 2015 19:57:36 GMT (envelope-from root) Date: Thu, 12 Feb 2015 19:57:36 +0000 To: freebsd-net@freebsd.org From: "glebius (Gleb Smirnoff)" Subject: [Differential] [Accepted] D1764: Factor out ip6_deletefraghdr() Message-ID: <720c91516a1387525d27956bbda1b04b@localhost.localdomain> X-Priority: 3 Thread-Topic: D1764: Factor out ip6_deletefraghdr() X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: ZDE3NDlmNTBjMTFkOWUxZjE5ZTU2MDhhM2Q4IFTdBbA= 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: Thu, 12 Feb 2015 20:10:00 -0000 glebius added a subscriber: glebius. glebius accepted this revision. glebius added a reviewer: glebius. glebius added a comment. This revision is now accepted and ready to land. Thanks. Patch looks good to me, but see comments. We probably need a nod from a IPv6 expert. I'll send link to ae@. INLINE COMMENTS sys/netinet6/ip6_output.c:1215 Comment should end in dot. sys/netinet6/ip6_output.c:1217 Comment should end in dot. sys/netinet6/ip6_output.c:1218 Can you please use bcopy() here. And you don't need first caddr_t cast. The second cast should be changed to char *. sys/netinet6/ip6_output.c:1223 Please capitalize comment and end it in dot. sys/netinet6/ip6_output.c:1224 Let's add third argument 'wait' to ip6_deletefraghdr(). The argument will be passed directly to m_split(). sys/netinet6/ip6_var.h:391 Need single whitespace between 'mbuf' and '*'. REVISION DETAIL https://reviews.freebsd.org/D1764 To: kristof, glebius Cc: glebius, freebsd-net From owner-freebsd-net@FreeBSD.ORG Thu Feb 12 20:20:40 2015 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 C5CA9834 for ; Thu, 12 Feb 2015 20:20: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 A5EE8672 for ; Thu, 12 Feb 2015 20:20: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 t1CKKeFa022720 for ; Thu, 12 Feb 2015 20:20:40 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 t1CKKeob022719; Thu, 12 Feb 2015 20:20:40 GMT (envelope-from root) Date: Thu, 12 Feb 2015 20:20:40 +0000 To: freebsd-net@freebsd.org From: "kristof (Kristof Provost)" Subject: [Differential] [Commented On] D1764: Factor out ip6_deletefraghdr() Message-ID: <4bc8381cf8994c9997d801d1cda7aaec@localhost.localdomain> X-Priority: 3 Thread-Topic: D1764: Factor out ip6_deletefraghdr() X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: ZDE3NDlmNTBjMTFkOWUxZjE5ZTU2MDhhM2Q4IFTdCxg= 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: Thu, 12 Feb 2015 20:20:40 -0000 kristof added a comment. Most of the remarks apply to the previous code as well. I have a minor preference for the patch to be a straight move of the existing code. If you feel strongly we should to take the opportunity to do style cleanups I will of course do so. I could also do the cleanups in a separate patch. REVISION DETAIL https://reviews.freebsd.org/D1764 To: kristof, glebius Cc: glebius, freebsd-net From owner-freebsd-net@FreeBSD.ORG Thu Feb 12 20:25:24 2015 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 9C5B89E2 for ; Thu, 12 Feb 2015 20:25:24 +0000 (UTC) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mx1.freebsd.org (Postfix) with ESMTP id 4676B78B for ; Thu, 12 Feb 2015 20:25:23 +0000 (UTC) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga101.fm.intel.com with ESMTP; 12 Feb 2015 12:24:14 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,566,1418112000"; d="scan'208";a="684958853" Received: from orsmsx110.amr.corp.intel.com ([10.22.240.8]) by orsmga002.jf.intel.com with ESMTP; 12 Feb 2015 12:24:14 -0800 Received: from orsmsx154.amr.corp.intel.com (10.22.226.12) by ORSMSX110.amr.corp.intel.com (10.22.240.8) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 12 Feb 2015 12:24:12 -0800 Received: from orsmsx111.amr.corp.intel.com ([169.254.11.110]) by ORSMSX154.amr.corp.intel.com ([169.254.11.247]) with mapi id 14.03.0195.001; Thu, 12 Feb 2015 12:24:12 -0800 From: "Pieper, Jeffrey E" To: Andreas Nilsson , FreeBSD Net Subject: RE: Was Re: FreeBSD 10.1: Intel dual port 10GbE card (82599EB) second port not present?: SFP+ on intel xl710 Thread-Topic: Was Re: FreeBSD 10.1: Intel dual port 10GbE card (82599EB) second port not present?: SFP+ on intel xl710 Thread-Index: AQHQRvVMx5nHRZkRdE6Xlo9EgE6zRpztdIIg Date: Thu, 12 Feb 2015 20:24:12 +0000 Message-ID: <2A35EA60C3C77D438915767F458D6568806C73CA@ORSMSX111.amr.corp.intel.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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, 12 Feb 2015 20:25:24 -0000 The check for supported modules in X710/XL710 is done in the FW, so unfortu= nately there is nothing we can do in the driver to add that functionality. = There is a possibility that it could happen at some point, but not in the f= oreseeable future. Jeff -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] = On Behalf Of Andreas Nilsson Sent: Thursday, February 12, 2015 10:54 AM To: FreeBSD Net Subject: Was Re: FreeBSD 10.1: Intel dual port 10GbE card (82599EB) second = port not present?: SFP+ on intel xl710 Hello, the discussion about unsupported sfps on intel card got an interesting turn today: a colleague wanted to do some pps (on linux) testing on an intel xl710 card, but the sfps we had was not supported. Reading the previous thread, I suggested there might be a sysctl to accept "other" sfps. Long story short, just for fun we booted a FreeBSD 10.1 system, and the card was recognized ( yay! ) but still "no carrier" from ifconfig. sysctl hw.ixl didn't show any tunables for "unsupported_sfp". Is this chip more picky about the tranceivers? Best regards Andreas Nilsson _______________________________________________ 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 Feb 12 20:29:53 2015 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 9B983AAF for ; Thu, 12 Feb 2015 20:29:53 +0000 (UTC) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 284DB7B8 for ; Thu, 12 Feb 2015 20:29:53 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id r20so7382236wiv.2 for ; Thu, 12 Feb 2015 12:29:51 -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=MULyDK2BZe5QI3BiXJQ50o67CNYuoxbqb14QGE7DT98=; b=usLD8vD3u4UObfhvGQfB9eBlPoKta0a168pF3Zr9UP/7fjTHppNcmudvXEfXJTyKrZ fr6TCV5H7SSMo2uNMKzJWhmi12mGpvBCqwY9w/g6OtVYMCn+cQJ9KweXPUk3YCVwrGri SG/VLXoQFFEREw9hU6Pm8rD1CW8a0NPxwot4kkUkdjt72rPcZz/H7hiEseVe0zegomcv qyyNDAoyVZ48ixYKl5Fc2LobvdxC3wefzTLkUoethOn88lz1pEgFX7vnsoiY5t8v7c0j f9HuISQKQsOWxsj90Utq4DH/AUmWzr2riMWLttz6t0Kxe9cf4U9YJpa1+qID46iG/kuP EpQQ== MIME-Version: 1.0 X-Received: by 10.180.38.76 with SMTP id e12mr9519180wik.76.1423772991324; Thu, 12 Feb 2015 12:29:51 -0800 (PST) Received: by 10.194.101.106 with HTTP; Thu, 12 Feb 2015 12:29:51 -0800 (PST) In-Reply-To: <2A35EA60C3C77D438915767F458D6568806C73CA@ORSMSX111.amr.corp.intel.com> References: <2A35EA60C3C77D438915767F458D6568806C73CA@ORSMSX111.amr.corp.intel.com> Date: Thu, 12 Feb 2015 12:29:51 -0800 Message-ID: Subject: Re: Was Re: FreeBSD 10.1: Intel dual port 10GbE card (82599EB) second port not present?: SFP+ on intel xl710 From: Jack Vogel To: "Pieper, Jeffrey E" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , Andreas Nilsson 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, 12 Feb 2015 20:29:53 -0000 I should add, that this possibility Jeff mentions involves a tool, not the driver, and it is not something that there is any commitment or specifics on yet. Cheers, Jack On Thu, Feb 12, 2015 at 12:24 PM, Pieper, Jeffrey E < jeffrey.e.pieper@intel.com> wrote: > The check for supported modules in X710/XL710 is done in the FW, so > unfortunately there is nothing we can do in the driver to add that > functionality. There is a possibility that it could happen at some point, > but not in the foreseeable future. > > Jeff > > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] > On Behalf Of Andreas Nilsson > Sent: Thursday, February 12, 2015 10:54 AM > To: FreeBSD Net > Subject: Was Re: FreeBSD 10.1: Intel dual port 10GbE card (82599EB) second > port not present?: SFP+ on intel xl710 > > Hello, > > the discussion about unsupported sfps on intel card got an interesting turn > today: a colleague wanted to do some pps (on linux) testing on an intel > xl710 card, but the sfps we had was not supported. > > Reading the previous thread, I suggested there might be a sysctl to accept > "other" sfps. Long story short, just for fun we booted a FreeBSD 10.1 > system, and the card was recognized ( yay! ) but still "no carrier" from > ifconfig. > > sysctl hw.ixl didn't show any tunables for "unsupported_sfp". Is this chip > more picky about the tranceivers? > > Best regards > Andreas Nilsson > _______________________________________________ > 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 Feb 12 20:50:46 2015 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 C56E3401 for ; Thu, 12 Feb 2015 20:50: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 A105F9E0 for ; Thu, 12 Feb 2015 20:50: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 t1CKokHa052553 for ; Thu, 12 Feb 2015 20:50: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 t1CKok61052552; Thu, 12 Feb 2015 20:50:46 GMT (envelope-from root) Date: Thu, 12 Feb 2015 20:50:46 +0000 To: freebsd-net@freebsd.org From: "rwatson (Robert Watson)" Subject: [Differential] [Accepted] D1805: [sockbuf] Don't access fields directly, use accessor functions Message-ID: <9399ad7dfa3e7af76c5ce9144ea51098@localhost.localdomain> X-Priority: 3 Thread-Topic: D1805: [sockbuf] Don't access fields directly, use accessor functions 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-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: OWRjZTdmYWI1ODk3ZGNkOWIxYTAyYWM0MjY5IFTdEiY= 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: Thu, 12 Feb 2015 20:50:46 -0000 rwatson accepted this revision. rwatson added a comment. Seems sensible. REVISION DETAIL https://reviews.freebsd.org/D1805 To: davide, kmacy, np, lstewart, rrs, julian, adrian, rwatson Cc: emaste, freebsd-net From owner-freebsd-net@FreeBSD.ORG Thu Feb 12 20:59:14 2015 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 467297FF for ; Thu, 12 Feb 2015 20:59: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 0D723AD9 for ; Thu, 12 Feb 2015 20:59: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 t1CKxDKa061444 for ; Thu, 12 Feb 2015 20:59:13 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 t1CKxDCF061443; Thu, 12 Feb 2015 20:59:13 GMT (envelope-from root) Date: Thu, 12 Feb 2015 20:59:13 +0000 To: freebsd-net@freebsd.org From: "glebius (Gleb Smirnoff)" Subject: [Differential] [Changed Subscribers] D1765: PF: Handle fragmented IPv6 packets Message-ID: <7639ebd9d955942a3d48076026732098@localhost.localdomain> X-Priority: 3 Thread-Topic: D1765: PF: Handle fragmented IPv6 packets X-Herald-Rules: none X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: MzdiMDI4N2YyYWVmNTFkOWE2N2EwODM4MzY0IFTdFCE= 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: Thu, 12 Feb 2015 20:59:14 -0000 glebius added a subscriber: glebius. glebius added a comment. Kristof, big thanks for working on this. See my comments. INLINE COMMENTS sys/netpfil/pf/pf.c:366 This function can also be used not only for fragment rbtree, but can also substitute the PF_ANEQ, PF_AEQ and could be considered to substitute even pf_match_addr(). So, lots of code can be generalized using this function. That's good. I'd suggest not to inline it, and rename it to pf_addr_cmp. "cmp" is a widely used abbreviation clear to anyone. sys/netpfil/pf/pf.c:396 Please add a panic() for default switch case. sys/netpfil/pf/pf_norm.c:64 Please use C99 types in new code instead of 80-ish BSD types: uint32_t, uint16_t, uint8_t. sys/netpfil/pf/pf_norm.c:72 When hacking pf, I strongly dislike this struct foo and struct foo_cmp, that must be kept synchronized. I skipped fixing that in 2012 and now I regret that. Let's now do it better in the new code. You can just embed pf_fragment_cmp into pf_fragment. Alternatively, you can do this trick: #define fr_cmp_offset fr_entry and in code you do: bcmp(a, b, offsetof(struct pf_fragment, fr_cmp_offset)) I prefer the trick over embedding, but that's up to you. sys/netpfil/pf/pf_norm.c:340 Empty line here is style(9) requirement, shouldn't be removed. sys/netpfil/pf/pf_norm.c:403 Let's put PF_FRAG_ASSERT() at the beginning of this function. Kinda documenting its locking requirements. sys/netpfil/pf/pf_norm.c:459 Dots in end of comments throught the function, please. Thanks :) sys/netpfil/pf/pf_norm.c:735 Please use KASSERT: m = m_getptr(m, hdrlen + offsetof(struct ip6_frag, ip6f_nxt), &off); KASSERT(m, ("%s: short mbuf chain", __func__)); sys/netpfil/pf/pf_norm.c:757 Same here. REVISION DETAIL https://reviews.freebsd.org/D1765 To: kristof Cc: glebius, freebsd-net From owner-freebsd-net@FreeBSD.ORG Thu Feb 12 20:59:20 2015 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 E47A588E for ; Thu, 12 Feb 2015 20:59:20 +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 C508EADE for ; Thu, 12 Feb 2015 20:59: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 t1CKxKFU061529 for ; Thu, 12 Feb 2015 20:59: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 t1CKxKaQ061528; Thu, 12 Feb 2015 20:59:20 GMT (envelope-from root) Date: Thu, 12 Feb 2015 20:59:20 +0000 To: freebsd-net@freebsd.org From: "glebius (Gleb Smirnoff)" Subject: [Differential] [Accepted] D1765: PF: Handle fragmented IPv6 packets Message-ID: <30aa9c59e4c397e4aeeffdc1832aab6c@localhost.localdomain> X-Priority: 3 Thread-Topic: D1765: PF: Handle fragmented IPv6 packets X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: MzdiMDI4N2YyYWVmNTFkOWE2N2EwODM4MzY0IFTdFCg= 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: Thu, 12 Feb 2015 20:59:21 -0000 glebius accepted this revision. glebius added a reviewer: glebius. This revision is now accepted and ready to land. REVISION DETAIL https://reviews.freebsd.org/D1765 To: kristof, glebius Cc: glebius, freebsd-net From owner-freebsd-net@FreeBSD.ORG Thu Feb 12 21:01:48 2015 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 7D612A2C for ; Thu, 12 Feb 2015 21:01:48 +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 5B666BDF for ; Thu, 12 Feb 2015 21:01:48 +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 t1CL1mdg066073 for ; Thu, 12 Feb 2015 21:01:48 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 t1CL1mOE066072; Thu, 12 Feb 2015 21:01:48 GMT (envelope-from root) Date: Thu, 12 Feb 2015 21:01:48 +0000 To: freebsd-net@freebsd.org From: "glebius (Gleb Smirnoff)" Subject: [Differential] [Accepted] D1766: Factor out ip6_fragment() Message-ID: X-Priority: 3 Thread-Topic: D1766: Factor out ip6_fragment() X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: YzZhYWI5M2ViMzc5NTk2YmY1MjY3NGQ3NjcxIFTdFLw= 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: Thu, 12 Feb 2015 21:01:48 -0000 glebius added a subscriber: glebius. glebius accepted this revision. glebius added a reviewer: glebius. glebius added a comment. This revision is now accepted and ready to land. Thanks. We also need someone working in netinet6 look into this. INLINE COMMENTS sys/netinet6/ip6_output.c:225 uint32_t in new code, please. REVISION DETAIL https://reviews.freebsd.org/D1766 To: kristof, glebius Cc: glebius, freebsd-net From owner-freebsd-net@FreeBSD.ORG Fri Feb 13 02:11:51 2015 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 6804B2C5; Fri, 13 Feb 2015 02:11:51 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0104.outbound.protection.outlook.com [65.55.169.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 817E089; Fri, 13 Feb 2015 02:11:49 +0000 (UTC) Received: from CO2PR05MB761.namprd05.prod.outlook.com (10.141.227.13) by CO2PR05MB764.namprd05.prod.outlook.com (10.141.227.19) with Microsoft SMTP Server (TLS) id 15.1.81.19; Thu, 12 Feb 2015 21:36:40 +0000 Received: from CO2PR05MB761.namprd05.prod.outlook.com ([10.141.227.13]) by CO2PR05MB761.namprd05.prod.outlook.com ([10.141.227.13]) with mapi id 15.01.0081.018; Thu, 12 Feb 2015 21:36:40 +0000 From: Sreekanth Rupavatharam To: Jack Vogel Subject: Re: Double cleanup in igb_attach Thread-Topic: Double cleanup in igb_attach Thread-Index: AQHQOcQ8M6DG1/D37kKlfeofCj44QJzUW0EA//+AdgCAAIzTgIAAAX8YgAAA4YCAAAQUE4AAAPkAgBiB44CAAJeiAP//lQSA Date: Thu, 12 Feb 2015 21:36:39 +0000 Message-ID: References: <20150127192814.GA63990@strugglingcoder.info> <26266AD2-4743-4A7B-A87D-F68E2E2425A0@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [66.129.239.14] authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB764; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB764; x-forefront-prvs: 0485417665 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(279900001)(377454003)(479174004)(164054003)(35774003)(24454002)(1411001)(92566002)(66066001)(40100003)(122556002)(102836002)(16236675004)(77096005)(86362001)(19625305001)(54356999)(46102003)(50986999)(19580395003)(87936001)(2656002)(62966003)(106116001)(77156002)(2950100001)(83506001)(15975445007)(19617315012)(76176999)(110136001)(93886004)(19580405001)(2900100001)(36756003)(99286002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB764; H:CO2PR05MB761.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2015 21:36:39.6138 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB764 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "jfv@freebsd.org" , "freebsd-net@freebsd.org" , hiren panchasara 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, 13 Feb 2015 02:11:51 -0000 Looking at the em driver, the em_detach is missing from the same place. return (0); 759 760err_late: 761 em_free_transmit_structures(adapter); 762 em_free_receive_structures(adapter); 763 em_release_hw_control(adapter); 764 if (adapter->ifp !=3D NULL) 765 if_free(adapter-= >ifp); 766err_pci: -- Thanks, Sreekanth From: Jack Vogel > Date: Thursday, February 12, 2015 at 12:00 PM To: Sreekanth Rupavatharam > Cc: hiren panchasara >, "freebsd-net@freebsd.org" >, "jfv@freebsd.org" > Subject: Re: Double cleanup in igb_attach I do not recall if I put that call in myself and, yes, it seems odd. It was= probably trying to clean up some bad state a failed attach left things in. If it is removed it should be thoroughly regression tested. Jack On Thu, Feb 12, 2015 at 10:56 AM, Sreekanth Rupavatharam > wrote: Hi Jack, Actually, looking at the code again, it seems to me that igb_detach is not = supposed to be called from igb_attach at all. It causes more problems than = previously mentioned. E.g., in case of branching to err_late *before* igb_= setup_interface(where the ifp is initialized), calling igb_detach there cau= ses a NULL pointer access. The best way to deal with it is to take out the = igb_detach call from the err_late: label. Thoughts? Comments? -- Thanks, Sreekanth From: Jack Vogel > Date: Tuesday, January 27, 2015 at 12:42 PM To: Sreekanth Rupavatharam > Cc: hiren panchasara >, "freebsd-net@freebsd.org" >, "jfv@freebsd.org" > Subject: Re: Double cleanup in igb_attach Yes, I will look them over. Jack On Tue, Jan 27, 2015 at 12:38 PM, Sreekanth Rupavatharam > wrote: Thanks jack, Now, can you please review these changes? And commit if you deem it fi= t? Thanks, -Sreekanth On Jan 27, 2015, at 12:24 PM, "Jack Vogel" > wrote: Errrr, I am one of those people :) (jack.vogel@intel.com) Jack On Tue, Jan 27, 2015 at 12:21 PM, Sreekanth Rupavatharam > wrote: Definitely, but I didn't have the contact info of those people. Thanks, -Sreekanth On Jan 27, 2015, at 12:15 PM, "Jack Vogel" > wrote: If you want something committed to an Intel driver, asking Intel might be t= he courteous thing to do, don't you think? Jack On Tue, Jan 27, 2015 at 11:51 AM, Sreekanth Rupavatharam > wrote: Hiren, Can you help commit this? Index: if_igb.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_igb.c(revision 298053) +++ if_igb.c(working copy) @@ -723,7 +723,8 @@ igb_attach(device_t dev) return (0); err_late: -igb_detach(dev); +if(igb_detach(dev) =3D=3D 0) /* igb_detach did the cleanup */ +return(error); igb_free_transmit_structures(adapter); igb_free_receive_structures(adapter); igb_release_hw_control(adapter); -- Thanks, Sreekanth On 1/27/15, 11:28 AM, "hiren panchasara" > wrote: + Jack On Tue, Jan 27, 2015 at 12:00:19AM +0000, Sreekanth Rupavatharam wrote: Apologies if this is not the right forum. In igb_attach function, we have t= his code. err_late: igb_detach(dev); igb_free_transmit_structures(adapter); igb_free_receive_structures(adapter); igb_release_hw_control(adapter); err_pci: igb_free_pci_resources(adapter); if (adapter->ifp !=3D NULL) if_free(adapter->ifp); free(adapter->mta, M_DEVBUF); IGB_CORE_LOCK_DESTROY(adapter); The problem is that igb_detach also does the same cleanup in it?s body. Onl= y exception is this case where it just returns EBUSY /* Make sure VLANS are not using driver */ if (if_vlantrunkinuse(ifp)) { device_printf(dev,"Vlan in use, detach first\n"); return (EBUSY); } I think the code in igb_attach should be changed to free up resources only = if the igb_detach returns an error. Here?s the patch for it. Index: if_igb.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_igb.c (revision 298025) +++ if_igb.c (working copy) @@ -723,7 +723,8 @@ igb_attach(device_t dev) return (0); err_late: - igb_detach(dev); + if(igb_detach(dev) =3D=3D 0) /* igb_detach did the cleanup */ + return; igb_free_transmit_structures(adapter); Can anyone comment on it and tell me if my understanding is incorrect? Seems reasonable to me at the first glance. We need to call IGB_CORE_LOCK_DESTROY(adapter) before returning though. cheers, Hiren From owner-freebsd-net@FreeBSD.ORG Fri Feb 13 02:20:43 2015 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 2D4EF83D for ; Fri, 13 Feb 2015 02:20:43 +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 0C6F8F2 for ; Fri, 13 Feb 2015 02:20:43 +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 t1D2Kg9A009969 for ; Fri, 13 Feb 2015 02:20:42 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 t1D2KgAx009968; Fri, 13 Feb 2015 02:20:42 GMT (envelope-from root) Date: Fri, 13 Feb 2015 02:20:42 +0000 To: freebsd-net@freebsd.org From: "ae (Andrey V. Elsukov)" Subject: [Differential] [Accepted] D1764: Factor out ip6_deletefraghdr() Message-ID: <17a393a91567d0593533d8c679a3d7ab@localhost.localdomain> X-Priority: 3 Thread-Topic: D1764: Factor out ip6_deletefraghdr() X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: ZDE3NDlmNTBjMTFkOWUxZjE5ZTU2MDhhM2Q4IFTdX3o= 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: Fri, 13 Feb 2015 02:20:43 -0000 ae added a subscriber: ae. ae accepted this revision. ae added a reviewer: ae. ae added a comment. I have no objections against it, the code looks similar to previous implementation. REVISION DETAIL https://reviews.freebsd.org/D1764 To: kristof, glebius, ae Cc: ae, glebius, freebsd-net From owner-freebsd-net@FreeBSD.ORG Fri Feb 13 14:25:04 2015 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 D4AF53E5 for ; Fri, 13 Feb 2015 14:25:04 +0000 (UTC) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9CB5F78A for ; Fri, 13 Feb 2015 14:25:04 +0000 (UTC) Received: by mail-ig0-f181.google.com with SMTP id hn18so10840424igb.2 for ; Fri, 13 Feb 2015 06:25:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=B+XhtPqJGgvQyIszfKN+qpFssTXAY/nq/aR0u6rS0SM=; b=fYpqzLWAsADuvdux3XAo0BQt3sfoIKo6tL+W7UnaFzx8qqEPxR5ROpTkPHzT8ufzFh 4xZhvpXFbcwHiLBNiHbDfTP5rnuEfnoi3f7mo+S0f+cAwzY6m41GZsK/wuCEN3YEHYa9 V0Cy9sGfXeN8H2mqtJlOpsxEe+MP4F0nrurrcJ40VekwsLpqnCkhW6/Vf5Y5nsvWiRZ7 iObBu1VfUty3kTy6/mEQGZxHRlpb3IcIhuKLCHN4Nw/KPeJFy6P7X8IoB+YnNx8dC40C osZy7TrrAK1+Qr3F9w+Y96DIMjtH9V/ZmjXhg/GEU8B4l5UJVKvKTZIjDOD3HGcMuEKv +Ktw== MIME-Version: 1.0 X-Received: by 10.50.43.169 with SMTP id x9mr3927089igl.28.1423837504026; Fri, 13 Feb 2015 06:25:04 -0800 (PST) Received: by 10.43.171.72 with HTTP; Fri, 13 Feb 2015 06:25:03 -0800 (PST) Date: Fri, 13 Feb 2015 19:55:03 +0530 Message-ID: Subject: Configuration if two eth port in freebsd From: vinay saini 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: Fri, 13 Feb 2015 14:25:05 -0000 Hello, I have installed freebsd on a physical machine with two ethernet cards.Now my plan is to connect em0 port in our LAN network without static IP and em1 port with my laptop with the static IP. em1 ---> LAN Network(without static IP) em2 ---> Laptop (with static IP ex:192.168.12.111) Now I would like to access the that server using this static IP ie. 192.168.12.111 on my laptop. Is there any way I can do this.Please help me how may I configure my ethernet settings. Thanks, Vinay Saini From owner-freebsd-net@FreeBSD.ORG Fri Feb 13 16:10:03 2015 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 273E9D30 for ; Fri, 13 Feb 2015 16:10:03 +0000 (UTC) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EC2022B6 for ; Fri, 13 Feb 2015 16:10:02 +0000 (UTC) Received: by iecar1 with SMTP id ar1so20590337iec.11 for ; Fri, 13 Feb 2015 08:09:56 -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=ms6Kw84DFNv5/NjGGEqnzy0RFjmQ99Xk+eKUMSi0gAo=; b=p56Lh0RLxx/O7m2C8Md1IHc9crexAExnFTvS3IgEhgxHkOTc8vxFtclBVoJkhxfXe0 R99uq/b+w2ELEjIsvP99SMA9dW9xlCRl0g9gJGdsTnyDnDehVHsLajgfcaX3DiK2oly7 OiO+aJ49LS1u/ZADcOcvvq+cyo2LkTGOTdVz35FaVOTxpWzh0hlv1AgYH+ctv9Zku0PR crgbZ09BKxjH+qaSsH9e84WswRPp9JaSaI8IX4xRF4DIkhHVfx9fDa2+tHBljjfjY+aL Avuwpm5MRdRKtQdycVw7z6ruF3H87vOcs47UovwR2DFFgE78K8ePbCp+NyAHH0uTiFy7 0hXw== X-Received: by 10.42.159.129 with SMTP id l1mr13166019icx.15.1423843796496; Fri, 13 Feb 2015 08:09:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.107.138 with HTTP; Fri, 13 Feb 2015 08:09:36 -0800 (PST) In-Reply-To: References: From: Luca Pizzamiglio Date: Fri, 13 Feb 2015 17:09:36 +0100 Message-ID: Subject: Fwd: pcie Realtek 8168G issues (re driver) To: freebsd-net@freebsd.org 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: Fri, 13 Feb 2015 16:10:03 -0000 Hi, I'm Luca, I've some issues using a PCIe Realtek Ethernet board: re0@pci0:3:0:0: class=0x020000 card=0x012310ec chip=0x816810ec rev=0x0c hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class = network subclass = ethernet bar [10] = type I/O Port, range 32, base 0x1000, size 256, enabled bar [18] = type Memory, range 64, base 0x90500000, size 4096, enabled bar [20] = type Prefetchable Memory, range 64, base 0x90400000, size 16384, enabled cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 2 endpoint IRQ 1 max data 128(128) link x1(x1) speed 2.5(2.5) ASPM disabled(L0s/L1) cap 11[b0] = MSI-X supports 4 messages Table in map 0x20[0x0], PBA in map 0x20[0x800] cap 03[d0] = VPD ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0002[140] = VC 1 max VC0 ecap 0003[160] = Serial 1 01000000684ce000 ecap 0018[170] = LTR 1 Rx and Tx don't work. After some minutes the interface is activated I get kernel panic. I've already tried to disable MSIx and MSI. It seems a DMA problem, rx fill the 256 descriptors and the nothing else until the panic. netstat -s shows now new packets. I filled a bug report with more infos: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197535 could someone kindly pointing some ideas? Best regards, Luca From owner-freebsd-net@FreeBSD.ORG Fri Feb 13 20:27:03 2015 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 E0F6D1D5 for ; Fri, 13 Feb 2015 20:27:03 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B4DA96A1 for ; Fri, 13 Feb 2015 20:27:03 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t1DKR31Q090385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Feb 2015 12:27:03 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t1DKR2qZ090384; Fri, 13 Feb 2015 12:27:02 -0800 (PST) (envelope-from jmg) Date: Fri, 13 Feb 2015 12:27:02 -0800 From: John-Mark Gurney To: vinay saini Subject: Re: Configuration if two eth port in freebsd Message-ID: <20150213202702.GN1953@funkthat.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 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? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Fri, 13 Feb 2015 12:27:03 -0800 (PST) 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, 13 Feb 2015 20:27:04 -0000 vinay saini wrote this message on Fri, Feb 13, 2015 at 19:55 +0530: > I have installed freebsd on a physical machine with two ethernet cards.Now > my plan is to connect em0 port in our LAN network without static IP and em1 > port with my laptop with the static IP. > > em1 ---> LAN Network(without static IP) > em2 ---> Laptop (with static IP ex:192.168.12.111) > > Now I would like to access the that server using this static IP ie. > 192.168.12.111 on my laptop. > > Is there any way I can do this.Please help me how may I configure my > ethernet settings. If the network knows that your static ip/network is located off of your box, just need to turn on forwarding, and every thing will just work... I assume though, that you don't control the LAN Network, and so it won't know that the static is located at your box... If your network admin lets you, you could run routed or similar routing protocol to announce the route, but your lan admin will probably not like you for that... The other way is to use nat... Look at the handbook for configuring either ipfw or pf for nat: https://www.freebsd.org/doc/handbook/firewalls.html -- 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 Sat Feb 14 13:36:50 2015 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 11D83F1 for ; Sat, 14 Feb 2015 13:36:50 +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 E34B1C1 for ; Sat, 14 Feb 2015 13:36:49 +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 t1EDanaL056400 for ; Sat, 14 Feb 2015 13:36:49 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 t1EDangF056399; Sat, 14 Feb 2015 13:36:49 GMT (envelope-from root) Date: Sat, 14 Feb 2015 13:36:49 +0000 To: freebsd-net@freebsd.org From: "kristof (Kristof Provost)" Subject: [Differential] [Updated, 52 lines] D1764: Factor out ip6_deletefraghdr() Message-ID: X-Priority: 3 Thread-Topic: D1764: Factor out ip6_deletefraghdr() X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: ZDE3NDlmNTBjMTFkOWUxZjE5ZTU2MDhhM2Q4IFTfT3E= 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: Sat, 14 Feb 2015 13:36:50 -0000 kristof updated this revision to Diff 3762. This revision now requires review to proceed. CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D1764?vs=3618&id=3762 REVISION DETAIL https://reviews.freebsd.org/D1764 AFFECTED FILES sys/netinet6/frag6.c sys/netinet6/ip6_output.c sys/netinet6/ip6_var.h To: kristof, ae, glebius Cc: ae, glebius, freebsd-net From owner-freebsd-net@FreeBSD.ORG Sat Feb 14 14:10:00 2015 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 AF56282E for ; Sat, 14 Feb 2015 14:10:00 +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 8F3C6398 for ; Sat, 14 Feb 2015 14:10:00 +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 t1EEA0Y5046239 for ; Sat, 14 Feb 2015 14:10:00 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 t1EEA0pA046231; Sat, 14 Feb 2015 14:10:00 GMT (envelope-from root) Date: Sat, 14 Feb 2015 14:10:00 +0000 To: freebsd-net@freebsd.org From: "kristof (Kristof Provost)" Subject: [Differential] [Updated, 838 lines] D1765: PF: Handle fragmented IPv6 packets Message-ID: X-Priority: 3 Thread-Topic: D1765: PF: Handle fragmented IPv6 packets X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: MzdiMDI4N2YyYWVmNTFkOWE2N2EwODM4MzY0IFTfVzg= 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: Sat, 14 Feb 2015 14:10:00 -0000 kristof updated this revision to Diff 3763. This revision now requires review to proceed. CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D1765?vs=3619&id=3763 REVISION DETAIL https://reviews.freebsd.org/D1765 AFFECTED FILES sys/net/pfvar.h sys/netpfil/pf/pf.c sys/netpfil/pf/pf_norm.c To: kristof, glebius Cc: glebius, freebsd-net From owner-freebsd-net@FreeBSD.ORG Sat Feb 14 14:10:39 2015 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 BF422945 for ; Sat, 14 Feb 2015 14:10:39 +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 9F964628 for ; Sat, 14 Feb 2015 14:10:39 +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 t1EEAdFO056618 for ; Sat, 14 Feb 2015 14:10: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 t1EEAd0W056611; Sat, 14 Feb 2015 14:10:39 GMT (envelope-from root) Date: Sat, 14 Feb 2015 14:10:39 +0000 To: freebsd-net@freebsd.org From: "kristof (Kristof Provost)" Subject: [Differential] [Updated, 112 lines] D1766: Factor out ip6_fragment() Message-ID: X-Priority: 3 Thread-Topic: D1766: Factor out ip6_fragment() X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: YzZhYWI5M2ViMzc5NTk2YmY1MjY3NGQ3NjcxIFTfV18= 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: Sat, 14 Feb 2015 14:10:39 -0000 kristof updated this revision to Diff 3764. This revision now requires review to proceed. CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D1766?vs=3620&id=3764 REVISION DETAIL https://reviews.freebsd.org/D1766 AFFECTED FILES sys/netinet6/ip6_output.c sys/netinet6/ip6_var.h To: kristof, glebius Cc: glebius, freebsd-net From owner-freebsd-net@FreeBSD.ORG Sat Feb 14 20:02:08 2015 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 BB81FB56 for ; Sat, 14 Feb 2015 20:02:08 +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 95682F0E for ; Sat, 14 Feb 2015 20:02:08 +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 t1EK27iO001758 for ; Sat, 14 Feb 2015 20:02:07 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 t1EK27jB001757; Sat, 14 Feb 2015 20:02:07 GMT (envelope-from root) Date: Sat, 14 Feb 2015 20:02:07 +0000 To: freebsd-net@freebsd.org From: "davide (Davide Italiano)" Subject: [Differential] [Closed] D1805: [sockbuf] Don't access fields directly, use accessor functions Message-ID: X-Priority: 3 Thread-Topic: D1805: [sockbuf] Don't access fields directly, use accessor functions 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-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: OWRjZTdmYWI1ODk3ZGNkOWIxYTAyYWM0MjY5IFTfqb8= 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: Sat, 14 Feb 2015 20:02:08 -0000 davide closed this revision. davide added a comment. In HEAD now. REVISION DETAIL https://reviews.freebsd.org/D1805 To: davide, kmacy, np, lstewart, rrs, julian, adrian, rwatson Cc: emaste, freebsd-net