From owner-freebsd-net@FreeBSD.ORG Sun Nov 9 02:13:20 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5ACE06C4 for ; Sun, 9 Nov 2014 02:13:20 +0000 (UTC) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D2D09DDF for ; Sun, 9 Nov 2014 02:13:19 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id l18so6610052wgh.10 for ; Sat, 08 Nov 2014 18:13:17 -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=b6r/6jPUguzyZBr3Kbr/jv+2fQ28CfuWor3tc1FiyCU=; b=gPlZnCDKvpbYNFQNrmgul8TjVP4wtinH0S+jInNECA7AIu6esEYjuYlI/FqbQKSS/S 1/IzPG4Dc1XAH+fdrwJ6Mrc92fwGMTp2/k5WwGzRG02PZCC37kEYj0dF1xgWeHU0Q2SL HzznydI/FbkEVblkHjO1yifxRsCUc/gsdbL675vkloqd9SuXsidDx+mn9Qf9agyzffz0 XUngYHKXFmZcP1rBXfw8u4SYXb+tQ2ga5ikNdPZ8B7rzfRPmiZZWw5M5nE94wgIkXyIf Qtq2BRAQVYFO/DF/LX+27dPo+eRfS67y3T15pCJLF5KefB5MPA6+7FVGl6Pa6ob43kvb fyCA== MIME-Version: 1.0 X-Received: by 10.180.14.165 with SMTP id q5mr18658852wic.0.1415499197089; Sat, 08 Nov 2014 18:13:17 -0800 (PST) Received: by 10.217.92.7 with HTTP; Sat, 8 Nov 2014 18:13:17 -0800 (PST) In-Reply-To: References: Date: Sun, 9 Nov 2014 00:13:17 -0200 Message-ID: Subject: Re: netmap-ipfw on em0 em1 From: Evandro Nunes To: Mahnaz Talebi Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 02:13:20 -0000 On Sat, Nov 8, 2014 at 5:26 AM, Mahnaz Talebi wrote: > Hi Evandro. > I've tested netmap-ipfw on real NICs. > Use " > > ./kipfw -i netmap:em0 -i netmap:em1 > " to run netmap-ipfw on em0 and em1. ipfw works as a bridge and copy > incoming packets to em0 to em1 if they pass defined rules (and vice versa, > from em1 to em0). > If you still have problem with ipfw-netmap, please send your scenario for > testing it. > dear mahaza, thank you for your suggestion still didn't work, in fact the syntax you mentioned returns an error that later turns out working just like if I had used ./kipfw netmap:em1 netmap:em2, see the output: *** Global Sysctl Table entries = 41, total size = 2144 *** [ 706.224574] session.c:do_server [541] +++ listening tcp 127.0.0.1:5555 [ 706.224645] netmap_io.c:netmap_add_port [310] opening netmap device -i [ 706.224666] netmap_io.c:netmap_add_port [320] error opening -i [ 706.224681] netmap_io.c:netmap_add_port [310] opening netmap device netmap:em1 [ 706.240897] netmap_io.c:netmap_add_port [326] --- mem_id 1 [ 706.240938] netmap_io.c:netmap_add_port [329] create sess 0x801449070 my_netmap_port 0x801429580 [ 706.240953] netmap_io.c:netmap_add_port [310] opening netmap device -i [ 706.240964] netmap_io.c:netmap_add_port [320] error opening -i [ 706.240976] netmap_io.c:netmap_add_port [310] opening netmap device netmap:em2 [ 706.257132] netmap_io.c:netmap_add_port [326] --- mem_id 1 [ 706.257175] netmap_io.c:netmap_add_port [329] create sess 0x8014490a0 my_netmap_port 0x801429800 [ 706.257187] netmap_io.c:netmap_add_port [342] 0x801429800 em2 1 <-> 0x801429580 em1 1 SWAP [ 706.257455] missing.c:callout_run [378] running 0x61e9d0 due at 1 now 168 [ 706.257480] session.c:mainloop [624] callouts 1 skipped 0 [ 707.000201] session.c:mainloop [624] callouts 3213 skipped 0 [ 708.000200] session.c:mainloop [624] callouts 7563 skipped 0 [ 709.000079] session.c:mainloop [624] callouts 11896 skipped 0 [ 710.000044] session.c:mainloop [624] callouts 16232 skipped 0 [ 711.000065] session.c:mainloop [624] callouts 20567 skipped 0 so -i opt is considered a netmap port which is unable to be open and in the end em2 and em1 and bridged, as it seems to be like on the line: [ 706.257187] netmap_io.c:netmap_add_port [342] 0x801429800 em2 1 <-> 0x801429580 em1 1 SWAP so it's the same as ./kipfw netmap:em1 netmap:em2. and therefore still have the same problem, packets count but I am completely out of communication on both NICs. my scenario is: (Machine-A)<-->Machine-B<--->(MachineC) Machine-A: em0 172.16.251.3/24 Machine-B: em1: 172.16.251.1/24 em2: 172.16.252.1/24 10.0-STABLE w/ latest netmap-ipfw and netmap code from google code repository Machine-C: em0 172.16.252.3/24 without kipfw hooked, Machine-A and Machine-C reach each other. but if ./kipfw netmap:em1 netmap:em2 is used, it turns I am completely out of communication on both em1 and em2 NICs. > _______________________________________________ > 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 Sun Nov 9 02:54:45 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E96CCDC for ; Sun, 9 Nov 2014 02:54:44 +0000 (UTC) Received: from leviatan.freebsdbrasil.com.br (leviatan.freebsdbrasil.com.br [177.10.156.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5460431D for ; Sun, 9 Nov 2014 02:54:43 +0000 (UTC) Received: (qmail 97591 invoked from network); 9 Nov 2014 00:54:26 -0200 Received: from c950c072.virtua.com.br ([201.80.192.114]) (envelope-sender ) by capeta.freebsdbrasil.com.br (qmail-ldap-1.03) with SMTP for ; 9 Nov 2014 00:54:26 -0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: netmap-ipfw on em0 em1 From: Patrick Tracanelli X-Mailer: iPad Mail (11D257) In-Reply-To: Date: Sun, 9 Nov 2014 00:54:00 -0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9C799778-79DC-4D5F-BA5C-EA94A573ED10@freebsdbrasil.com.br> References: To: Evandro Nunes Cc: "freebsd-net@freebsd.org" , Mahnaz Talebi 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, 09 Nov 2014 02:54:45 -0000 Dear Evandro Nunes, You are just not reading. Ealy I mentioned the netmap:port syntax because yo= ur previous syntax were turning out on errors opening the port that you just= didnt pay attention on ./kipfw's output. Now you just didnt read what Mahanaz Tabeli wrote ;-) Please fo *read* below= !! :-D Enviada do meu iPad > Em 09/11/2014, =C3=A0s 00:13, Evandro Nunes esc= reveu: >=20 >> On Sat, Nov 8, 2014 at 5:26 AM, Mahnaz Talebi wro= te: >>=20 >> Hi Evandro. >> I've tested netmap-ipfw on real NICs. >> Use " >>=20 >> ./kipfw -i netmap:em0 -i netmap:em1 >> " to run netmap-ipfw on em0 and em1. ipfw works as a bridge and copy >> incoming packets to em0 to em1 if they pass defined rules (and vice versa= , >> from em1 to em0). >> If you still have problem with ipfw-netmap, please send your scenario for= >> testing it. >=20 > dear mahaza, thank you for your suggestion >=20 > still didn't work, in fact the syntax you mentioned returns an error that > later turns out working just like if I had used ./kipfw netmap:em1 > netmap:em2, see the output: Yes you are right and yes so does Mahaza since the wrong syntax just works f= or him.=20 > (Machine-A)<-->Machine-B<--->(MachineC) >=20 > Machine-A: > em0 172.16.251.3/24 >=20 > Machine-B: > em1: 172.16.251.1/24 > em2: 172.16.252.1/24 > 10.0-STABLE w/ latest netmap-ipfw and netmap code from google code > repository >=20 > Machine-C: > em0 172.16.252.3/24 Now, your scenario is a typical routing topology. kipfw has no packet forwar= ding capabilities whats why when you start it, you are out of forwarding cap= abilities and therefore, out of communication between machine A and C becaus= e they just need it in your topology. So for your testing purposes read again what Mahaza said: >> ipfw works as a bridge and copy >> incoming packets to em0 to em1 if they pass defined rules (and vice versa= , >> from em1 to em0). Got it? kipfw will work as a BRIDGE and COPY between the NIC ports. Therefore on your topology do a simple change: Machine-C: ifconfig em0 172.16.251.4/24 So machine C will be in the same network of machine A.=20 WITHOUT kipfw you will be OUT of communication. If you want to have communic= ation without kipfw please configure if_bridge(4) properly. Now WHEN you ./kipfw netmap:em1 netmap:em2 you will BRIDGE em1 and em2 ports= and therefore you will HAVE communication between the NICS. And you are done, just as a miracle! Thanks to Luigi. Now its time to have some fun: ipfw/ipfw add pipe 1 all from 172.16.251.0/24 to 172.16.251.0/24 ipfw/ipfw pipe 1 config bw 128Kbit/s delay 300 and now ping machine-A and machine-C and see dummynet working as expected...= I believe you can keep on with your testings now!!! :-) BTW Luigi, I see netmap was commited to GENERIC on -CURRENT. I believe it ma= y be a good idea to add netmap-ipfw to the base system now, to both promote m= ore testing and also to be a good companion to netmap on GENERIC. I dont mea= n a new ipfw-netmap binary under /sbin/ but just the code on /usr/src/tools/= tools. I've been using netmap-ipfw for a while and sure it lacks more flexbility li= ke the ability to kipfw several ports, etc. But as it is right now, it's ver= y stable and reliable for a preliminary code. Thats why I believe it should b= e on the base system. Thank you very much for the incredible technology.=20 From owner-freebsd-net@FreeBSD.ORG Sun Nov 9 13:30:58 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 73B0476E; Sun, 9 Nov 2014 13:30:58 +0000 (UTC) Received: from olymp.kibab.com (olymp6.kibab.com [IPv6:2a01:4f8:160:84c1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 37706A57; Sun, 9 Nov 2014 13:30:57 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 olymp.kibab.com 70D397590E DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bakulin.de; s=default; t=1415539855; bh=oDNrXQvjDG5gV569jUq/U+BApNzj5+wCnJxhCGL1Mik=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=FjjXgUy+BqcGLlZybNMm0CWQ0dUmqmoBjkrnlUSTUD173BDOMal95BtGZNi+hxVpk m7OMfY7VLO7rvEKf3+uX2RWiwFbzIFnIcUxzp2cPv+ATC78L6ZGrsLPGesNh2yU93S 8H65y5R+qaCmtoWHM29SvXFsV989Jjw2ctqdMOug= Message-ID: <545F6C8F.6010700@bakulin.de> Date: Sun, 09 Nov 2014 14:30:55 +0100 From: Ilya Bakulin MIME-Version: 1.0 To: Kristof Provost Subject: Re: Checksumming outgoing packets in PF vs in ip[6]_output References: <1415210423.3394438.187470637.21CD8D3D@webmail.messagingengine.com> <9355b23f1a07008eca61f16ebd828d0b@mail.bakulin.de> <20141107133101.GF2044@vega.codepro.be> In-Reply-To: <20141107133101.GF2044@vega.codepro.be> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Mark Felder 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, 09 Nov 2014 13:30:58 -0000 On 07.11.14, 14:31, Kristof Provost wrote: > On 2014-11-05 19:11:55 (+0100), Ilya Bakulin wrote: >> On 2014-11-05 19:00, Mark Felder wrote: >>> Now if we could only stamp out the bug with ipv6 fragment and pf I'd be >>> a happy, happy daemon. :-) >> This is somewhat more complex problem, I'll take a look as the time >> allows. >> > I've been playing with it too. I have a patch which seems to be working, > but it currently drops the distinction between PFRULE_FRAGCROP and > PFRULE_FRAGDROP. OpenBSD dropped that a while ago, but I figured FreeBSD > wouldn't want user-visible changes. > > I've been meaning to look at that some more but ... ENOTIME. > It's tentatively planned as a project for Chaos Congress (end of > December), but no promises. > > If you like I can probably dig up the (non-clean) patches for you. > > Regards, > Kristof > Yes, please do it, would be interesting to look at your code! -- Regards, Ilya Bakulin From owner-freebsd-net@FreeBSD.ORG Sun Nov 9 19:16:18 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8840B93F; Sun, 9 Nov 2014 19:16:18 +0000 (UTC) Received: from snorky.mixmin.net (snorky.mixmin.net [IPv6:2a01:4f8:100:5243::3]) (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 191D2C05; Sun, 9 Nov 2014 19:16:17 +0000 (UTC) Received: by snorky.mixmin.net (Postfix, from userid 1011) id 3BA2DEAB3B; Sun, 9 Nov 2014 19:15:42 +0000 (GMT) Authentication-Results: snorky.mixmin.net; dkim=fail reason="verification failed; unprotected key" header.d=gmail.com header.i=@gmail.com header.b=m/Qoe9HI; dkim-adsp=none (unprotected policy); dkim-atps=neutral X-Old-Original-To: nymserv@mixmin.net Delivered-To: nymserv@mixmin.net Received: by snorky.mixmin.net (Postfix, from userid 110) id 6ED13EADBA; Fri, 7 Nov 2014 21:07:04 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on snorky.mixmin.net X-Spam-Level: X-Spam-Status: No, score=-2.8 required=6.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD, T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.0 Received: from eugeni.torproject.org (eugeni.torproject.org [IPv6:2620:0:6b0:b:1a1a:0:26e5:480d]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by snorky.mixmin.net (Postfix) with ESMTPS id 149B3EAEEF for ; Fri, 7 Nov 2014 21:07:02 +0000 (GMT) Received: from eugeni.torproject.org (localhost [127.0.0.1]) by eugeni.torproject.org (Postfix) with ESMTP id 4069431286; Fri, 7 Nov 2014 21:06:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by eugeni.torproject.org (Postfix) with ESMTP id A46BE27DEB for ; Fri, 7 Nov 2014 21:06:52 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at Received: from eugeni.torproject.org ([127.0.0.1]) by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zKFqRiO0NOv for ; Fri, 7 Nov 2014 21:06:52 +0000 (UTC) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (not verified)) by eugeni.torproject.org (Postfix) with ESMTPS id 7C9BF2697B for ; Fri, 7 Nov 2014 21:06:52 +0000 (UTC) Received: by mail-vc0-f179.google.com with SMTP id ij19so2185863vcb.24 for ; Fri, 07 Nov 2014 13:06:50 -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=Q8Bwf9rQwuFMx01aXD8aOzVraH2Q+lTxJLoP6htJ2dw=; b=m/Qoe9HIldtUqe1tl2UGTbANmZfpK9CC/Oa3Xz/9U9z78Y/oH/li1mrR/N7308HUlp Mj61xFBS6cpeQp2XxVg3Qo4bWok6upA93kzIPurOQ7A+xNQVhKR8XMwwoDds/nrw7TZ6 dcXL5B4qTV4z4mq7FeWYC8ZISwq3BQ8nPs+gFi7DK/2Ikgc7qD1aFKkAg9hcv0hZTgz6 r2dJr/TbPtocVfRKyUkYdS/2fv2BIOp1JFwlNgJhwjdYuCWvGtTW3SkYGM5u0VEEmqCp pTH6kuk4Z4oTwLIwh9nvUr8aR+q4J9tjWVqeFp97lAQUibpdQGQ6AOFarCc1/ucWG0Yw RQsg== MIME-Version: 1.0 X-Received: by 10.221.38.66 with SMTP id th2mr9320080vcb.21.1415394410134; Fri, 07 Nov 2014 13:06:50 -0800 (PST) Received: by 10.221.64.74 with HTTP; Fri, 7 Nov 2014 13:06:50 -0800 (PST) In-Reply-To: References: <20141106135228.GE3824@nymity.ch> Date: Fri, 7 Nov 2014 16:06:50 -0500 Message-ID: From: grarpamp To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] FreeBSD's global IP ID (was: Platform diversity in Tor network) X-BeenThere: tor-relays@lists.torproject.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tor-relays@lists.torproject.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: tor-relays-bounces@lists.torproject.org Sender: "tor-relays" Cc: FreeBSD Net , freebsd-security@freebsd.org X-BeenThere: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 19:16:18 -0000 On Fri, Nov 7, 2014 at 11:31 AM, Adrian Chadd wrote: > ... that's .. odd. > > Let's poke the freebsd crypto and network stack people and ask. I > can't imagine why this is a problem anymore and we should default to > it being on. I don't think there's a crypto@ list, though security@ might represent. > The other thing you could do is have the tor port require > it be turned on before tor runs. That would not cover people who compile and use upstream Tor. Ideally, the Tor client could check for any system parameters it feels are critical before running, or simply delegate them and/or any parameters of lesser importance to platform specific guides on the Tor wiki. > On 7 November 2014 00:20, grarpamp wrote: >> On Thu, Nov 6, 2014 at 8:52 AM, Philipp Winter wrote: >>> >>> FreeBSD still seems to use globally incrementing IP IDs by default. >>> That's an issue as it leaks fine-grained information about how many >>> packets a relay's networking stack processes. (However, nobody >>> investigated the exact impact on Tor relays so far, which makes this a >>> FUD-heavy topic.) It looks like approximately 50 out of the 131 FreeBSD >>> relays I tested (38%) use global IP IDs. >>> >>> There's a sysctl variable called "net.inet.ip.random_id" which makes a >>> FreeBSD's IP ID behaviour random. FreeBSD relay operators should set >>> this to "1". >>> >>> Note that this issue was already discussed earlier this year in a thread >>> called "Lots of tor relays send out sequential IP IDs; please fix >>> that!". >> >> It's been default off since before it was a sysctl over a decade ago. >> Anyone know what the deal is with that? Some objection, or >> forgotten flag day, or oversight that really should be set to 1? >> https://svnweb.freebsd.org/base?view=revision&revision=133720 _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays From owner-freebsd-net@FreeBSD.ORG Sun Nov 9 19:16:53 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 545C8A4F for ; Sun, 9 Nov 2014 19:16:53 +0000 (UTC) Received: from snorky.mixmin.net (snorky.mixmin.net [IPv6:2a01:4f8:100:5243::3]) (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 DA16BC17 for ; Sun, 9 Nov 2014 19:16:52 +0000 (UTC) Received: by snorky.mixmin.net (Postfix, from userid 1011) id 365A6EAC08; Sun, 9 Nov 2014 19:15:38 +0000 (GMT) Authentication-Results: snorky.mixmin.net; dkim=fail reason="verification failed; unprotected key" header.d=gmail.com header.i=@gmail.com header.b=wT4A760S; dkim-adsp=none (unprotected policy); dkim-atps=neutral X-Old-Original-To: nymserv@mixmin.net Delivered-To: nymserv@mixmin.net Received: by snorky.mixmin.net (Postfix, from userid 110) id 83A8CEAB58; Fri, 7 Nov 2014 08:20:30 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on snorky.mixmin.net X-Spam-Level: X-Spam-Status: No, score=-2.8 required=6.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD, T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.0 Received: from eugeni.torproject.org (eugeni.torproject.org [IPv6:2620:0:6b0:b:1a1a:0:26e5:480d]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by snorky.mixmin.net (Postfix) with ESMTPS id E2725EAB59 for ; Fri, 7 Nov 2014 08:20:28 +0000 (GMT) Received: from eugeni.torproject.org (localhost [127.0.0.1]) by eugeni.torproject.org (Postfix) with ESMTP id D136C31748; Fri, 7 Nov 2014 08:20:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by eugeni.torproject.org (Postfix) with ESMTP id 1465331379 for ; Fri, 7 Nov 2014 08:20:20 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at Received: from eugeni.torproject.org ([127.0.0.1]) by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d22fHB0uY24j for ; Fri, 7 Nov 2014 08:20:20 +0000 (UTC) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (not verified)) by eugeni.torproject.org (Postfix) with ESMTPS id E06973125E for ; Fri, 7 Nov 2014 08:20:19 +0000 (UTC) Received: by mail-vc0-f177.google.com with SMTP id hq12so1440336vcb.8 for ; Fri, 07 Nov 2014 00:20:17 -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=mRiyEnXoWexPNnZSBo8Ad1/oQlwYp5fAuNVNW+NKSog=; b=wT4A760SFIHrAMVNK86Ri78BIH2KzSuOWQ3IvGc5TgoAULS/9CnrgOeyoWWbyl4arg NtPan8/f/qz9ZYuodA57DkahDORKCu2Z1QzaMxgPrK6LzuXVdHANJM4k0vohgUTcdhoB BkA3q9Djcuf3hg1RSp0IDh7pgXoy61c7sB5ejujc+Wt2c9Jcyo2eqdNBqTsdVVQrwSq6 zE5roZbUubl1vRsngH+XapG+OOS3HslJ5hcBdhNIlXIcabpOT9ao+HyXl2Tz2j24gFEL LsLCDeG7m+OuiUf3ShaQuMUYeF9S1hO9clDOa9S4gFxnvxQ/rmzlzi5dmf7asvwuGIuV Cdgg== MIME-Version: 1.0 X-Received: by 10.220.128.71 with SMTP id j7mr6754716vcs.22.1415348417420; Fri, 07 Nov 2014 00:20:17 -0800 (PST) Received: by 10.221.64.74 with HTTP; Fri, 7 Nov 2014 00:20:17 -0800 (PST) In-Reply-To: <20141106135228.GE3824@nymity.ch> References: <20141106135228.GE3824@nymity.ch> Date: Fri, 7 Nov 2014 03:20:17 -0500 Message-ID: From: grarpamp To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] FreeBSD's global IP ID (was: Platform diversity in Tor network) X-BeenThere: tor-relays@lists.torproject.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tor-relays@lists.torproject.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: tor-relays-bounces@lists.torproject.org Sender: "tor-relays" Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 19:16:53 -0000 On Thu, Nov 6, 2014 at 8:52 AM, Philipp Winter wrote: > On Wed, Nov 05, 2014 at 04:04:41AM -0500, grarpamp wrote: >> 173 FreeBSD > > FreeBSD still seems to use globally incrementing IP IDs by default. > That's an issue as it leaks fine-grained information about how many > packets a relay's networking stack processes. (However, nobody > investigated the exact impact on Tor relays so far, which makes this a > FUD-heavy topic.) It looks like approximately 50 out of the 131 FreeBSD > relays I tested (38%) use global IP IDs. > > There's a sysctl variable called "net.inet.ip.random_id" which makes a > FreeBSD's IP ID behaviour random. FreeBSD relay operators should set > this to "1". > > Note that this issue was already discussed earlier this year in a thread > called "Lots of tor relays send out sequential IP IDs; please fix > that!". It's been default off since before it was a sysctl over a decade ago. Anyone know what the deal is with that? Some objection, or forgotten flag day, or oversight that really should be set to 1? https://svnweb.freebsd.org/base?view=revision&revision=133720 _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays From owner-freebsd-net@FreeBSD.ORG Sun Nov 9 19:31:19 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 67434D4B for ; Sun, 9 Nov 2014 19:31:19 +0000 (UTC) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DFDE0D0A for ; Sun, 9 Nov 2014 19:31:18 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id r20so8244071wiv.5 for ; Sun, 09 Nov 2014 11:31:16 -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=R7sj18n4m5d/zYYJfnLPUDXGUxg8AooYaZJAE/WXSnU=; b=IdLY1IjI+Xn7S3VPdkDzRJZrRrwSu5KXXPcrQQh8wq3w75F+D6taYJSq9VcbcwiyeD yAewWWL8Ao4/ru+HGk6PXNSXqBQ499T8zSNXCj7xJSb21fJMSHznSP7L+8/UxqhTpchx HC0SxTy6bouT+YOsLo3RzvmOrEN7zzOWbcr67Sg6W4GuOif1+LzBToVEm3N6cJMoVKl/ uNTLagzTv38fkcJCTH9BsAq9PUtKZLjiBuXOykfIeeFljkwqQ7fSnFC18lT4tNOKmIJL qZUo5CeeTdicSb59mEeITZZsD5xBLFglKPVrs4pKuH2GIyeNVbPIthp+BoGYJj5SZaD/ 3hHA== MIME-Version: 1.0 X-Received: by 10.180.101.102 with SMTP id ff6mr24577061wib.0.1415561476522; Sun, 09 Nov 2014 11:31:16 -0800 (PST) Received: by 10.217.92.7 with HTTP; Sun, 9 Nov 2014 11:31:16 -0800 (PST) In-Reply-To: <9C799778-79DC-4D5F-BA5C-EA94A573ED10@freebsdbrasil.com.br> References: <9C799778-79DC-4D5F-BA5C-EA94A573ED10@freebsdbrasil.com.br> Date: Sun, 9 Nov 2014 17:31:16 -0200 Message-ID: Subject: Re: netmap-ipfw on em0 em1 From: Evandro Nunes To: Patrick Tracanelli , Luigi Rizzo Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , Mahnaz Talebi 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, 09 Nov 2014 19:31:19 -0000 hello again patrick On Sun, Nov 9, 2014 at 12:54 AM, Patrick Tracanelli < eksffa@freebsdbrasil.com.br> wrote: > > (Machine-A)<-->Machine-B<--->(MachineC) > > > > Machine-A: > > em0 172.16.251.3/24 > > > > Machine-B: > > em1: 172.16.251.1/24 > > em2: 172.16.252.1/24 > > 10.0-STABLE w/ latest netmap-ipfw and netmap code from google code > > repository > > > > Machine-C: > > em0 172.16.252.3/24 > > Now, your scenario is a typical routing topology. kipfw has no packet > forwarding capabilities whats why when you start it, you are out of > forwarding capabilities and therefore, out of communication between machine > A and C because they just need it in your topology. > > So for your testing purposes read again what Mahaza said: > > >> ipfw works as a bridge and copy > >> incoming packets to em0 to em1 if they pass defined rules (and vice > versa, > >> from em1 to em0). > > Got it? kipfw will work as a BRIDGE and COPY between the NIC ports. > > Therefore on your topology do a simple change: > > Machine-C: > ifconfig em0 172.16.251.4/24 > > So machine C will be in the same network of machine A. > > WITHOUT kipfw you will be OUT of communication. If you want to have > communication without kipfw please configure if_bridge(4) properly. > > Now WHEN you ./kipfw netmap:em1 netmap:em2 you will BRIDGE em1 and em2 > ports and therefore you will HAVE communication between the NICS. > > And you are done, just as a miracle! Thanks to Luigi. > YES IT WORKED YES thank you VERY MUCH for the kind help and for making it clear all the stuff I missed reading, yes I assume I should have read more or at least understood now I can see how the things works and it does work THANK YOU again very much > Now its time to have some fun: > > ipfw/ipfw add pipe 1 all from 172.16.251.0/24 to 172.16.251.0/24 > ipfw/ipfw pipe 1 config bw 128Kbit/s delay 300 > > and now ping machine-A and machine-C and see dummynet working as > expected... > > I believe you can keep on with your testings now!!! :-) > yes it worked as well now let me ask you all, other than click, does netmap offers something that can do packet forwarding? simple packet forwarding like the scenario I was trying before? I know this is not kipfw and not bridge but is there something? thank you > BTW Luigi, I see netmap was commited to GENERIC on -CURRENT. I believe it > may be a good idea to add netmap-ipfw to the base system now, to both > promote more testing and also to be a good companion to netmap on GENERIC. > I dont mean a new ipfw-netmap binary under /sbin/ but just the code on > /usr/src/tools/tools. > yes and some handbook or a better README that at least mentions the correct syntax for the tools I think adrian chadd mentioned something about that in an earlier message > > I've been using netmap-ipfw for a while and sure it lacks more flexbility > like the ability to kipfw several ports, etc. But as it is right now, it's > very stable and reliable for a preliminary code. Thats why I believe it > should be on the base system. Thank you very much for the incredible > technology. > > > > > > > > > > > > > > > > > > From owner-freebsd-net@FreeBSD.ORG Sun Nov 9 20:16:01 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16DE7CE1; Sun, 9 Nov 2014 20:16:01 +0000 (UTC) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CB9DB69BD6; Sun, 9 Nov 2014 20:16:00 +0000 (UTC) Received: from vega.codepro.be (unknown [172.16.1.3]) by venus.codepro.be (Postfix) with ESMTP id 8C3BEE3E6; Sun, 9 Nov 2014 21:15:57 +0100 (CET) Received: by vega.codepro.be (Postfix, from userid 1001) id 87E082071C; Sun, 9 Nov 2014 21:15:57 +0100 (CET) Date: Sun, 9 Nov 2014 21:15:57 +0100 From: Kristof Provost To: Ilya Bakulin , Jim Thompson Subject: Re: Checksumming outgoing packets in PF vs in ip[6]_output Message-ID: <20141109201557.GH2044@vega.codepro.be> References: <1415210423.3394438.187470637.21CD8D3D@webmail.messagingengine.com> <9355b23f1a07008eca61f16ebd828d0b@mail.bakulin.de> <20141107133101.GF2044@vega.codepro.be> <545F6C8F.6010700@bakulin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <545F6C8F.6010700@bakulin.de> X-PGP-Fingerprint: E114 D9EA 909E D469 8F57 17A5 7D15 91C6 9EFA F286 X-Checked-By-NSA: Probably User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-net@freebsd.org, Mark Felder 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, 09 Nov 2014 20:16:01 -0000 On 2014-11-09 14:30:55 (+0100), Ilya Bakulin wrote: > On 07.11.14, 14:31, Kristof Provost wrote: > > I've been playing with it too. I have a patch which seems to be working, > > but it currently drops the distinction between PFRULE_FRAGCROP and > > PFRULE_FRAGDROP. OpenBSD dropped that a while ago, but I figured FreeBSD > > wouldn't want user-visible changes. > > > > I've been meaning to look at that some more but ... ENOTIME. > > It's tentatively planned as a project for Chaos Congress (end of > > December), but no promises. > > > > If you like I can probably dig up the (non-clean) patches for you. > > > Yes, please do it, would be interesting to look at your code! > You can find the patch series here: http://www.sigsegv.be/files/pf_inet6_frag.tar and everything in one big patch here: http://www.sigsegv.be/files/pf_inet6_frag.patch It's not cleaned up yet, or even extensively tested. Basically the only testing that's been done is setting up a pf config to drop all traffic except icmp echo requests, and then sending out fragmented icmp echo requests. Without the patch those get dropped, with the patch they make it through the firewall. I've done some quick flood ping testing, so I'm reasonably confident it doesn't leak mbufs. I started from the OpenBSD work, and imported and adjusted their inet6 defragmentation patches. Regards, Kristof From owner-freebsd-net@FreeBSD.ORG Sun Nov 9 21:17:23 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1169347F for ; Sun, 9 Nov 2014 21:17:23 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8B1A62F2 for ; Sun, 9 Nov 2014 21:17:22 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id n3so8542832wiv.4 for ; Sun, 09 Nov 2014 13:17:21 -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=i+5MSaKXt3tUSYV9PNxnmsiCVIR5LfZ9LjOmkXgqlYk=; b=IXpOxT1Ls2Rh/Kou9Xl/J+MZEcYBSq9djKbOZjAHdPCVjp1Tmt0iyCDltFpnYgZUq4 y2OkTu8ZBVyxGjgDtbkyhOmWsaCDAJZm8lvk2Cy1IgJb3xfCzlzDhhRFy03IPyNmGEJ0 YQSsKtP2+oWP6JRCUcH5X0j9U0T2QA3eYhOU7l5NA83IzkC+qihEomRZRmBM9iT3EoWK uSkuFU9LsZG2iyPG3GQLdPU8OPt2MHMpmNIoEQI+FHyG2roIXsb6WpwEhdYUMm/fCSfd 4e4Ll1HsUNvtXqO5nfxMvRRAqEe+sohjZI/H4yrj+w1MRTypvmWx+92ADKuQDdcZ2BYm g4cw== MIME-Version: 1.0 X-Received: by 10.180.107.136 with SMTP id hc8mr24426331wib.78.1415567841093; Sun, 09 Nov 2014 13:17:21 -0800 (PST) Received: by 10.217.92.7 with HTTP; Sun, 9 Nov 2014 13:17:20 -0800 (PST) In-Reply-To: References: <9C799778-79DC-4D5F-BA5C-EA94A573ED10@freebsdbrasil.com.br> Date: Sun, 9 Nov 2014 19:17:20 -0200 Message-ID: Subject: Re: netmap-ipfw on em0 em1 From: Evandro Nunes To: Patrick Tracanelli , Luigi Rizzo Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , Mahnaz Talebi 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, 09 Nov 2014 21:17:23 -0000 professor luigi where can I find the code for netmap-fwd you mentioned on usenix paper? ** https://www.usenix.org/system/files/conference/atc12/atc12-final186.pdf On Sun, Nov 9, 2014 at 5:31 PM, Evandro Nunes wrote: > hello again patrick > > On Sun, Nov 9, 2014 at 12:54 AM, Patrick Tracanelli < > eksffa@freebsdbrasil.com.br> wrote: > >> > (Machine-A)<-->Machine-B<--->(MachineC) >> > >> > Machine-A: >> > em0 172.16.251.3/24 >> > >> > Machine-B: >> > em1: 172.16.251.1/24 >> > em2: 172.16.252.1/24 >> > 10.0-STABLE w/ latest netmap-ipfw and netmap code from google code >> > repository >> > >> > Machine-C: >> > em0 172.16.252.3/24 >> >> Now, your scenario is a typical routing topology. kipfw has no packet >> forwarding capabilities whats why when you start it, you are out of >> forwarding capabilities and therefore, out of communication between machine >> A and C because they just need it in your topology. >> >> So for your testing purposes read again what Mahaza said: >> >> >> ipfw works as a bridge and copy >> >> incoming packets to em0 to em1 if they pass defined rules (and vice >> versa, >> >> from em1 to em0). >> >> Got it? kipfw will work as a BRIDGE and COPY between the NIC ports. >> >> Therefore on your topology do a simple change: >> >> Machine-C: >> ifconfig em0 172.16.251.4/24 >> >> So machine C will be in the same network of machine A. >> >> WITHOUT kipfw you will be OUT of communication. If you want to have >> communication without kipfw please configure if_bridge(4) properly. >> >> Now WHEN you ./kipfw netmap:em1 netmap:em2 you will BRIDGE em1 and em2 >> ports and therefore you will HAVE communication between the NICS. >> >> And you are done, just as a miracle! Thanks to Luigi. >> > > YES IT WORKED YES > thank you VERY MUCH for the kind help and for making it clear all the > stuff I missed reading, yes I assume I should have read more or at least > understood > now I can see how the things works and it does work > > THANK YOU again very much > > > >> Now its time to have some fun: >> >> ipfw/ipfw add pipe 1 all from 172.16.251.0/24 to 172.16.251.0/24 >> ipfw/ipfw pipe 1 config bw 128Kbit/s >> delay 300 >> >> and now ping machine-A and machine-C and see dummynet working as >> expected... >> >> I believe you can keep on with your testings now!!! :-) >> > > yes it worked as well > > now let me ask you all, other than click, does netmap offers something > that can do packet forwarding? simple packet forwarding like the scenario I > was trying before? I know this is not kipfw and not bridge but is there > something? > > thank you > > > >> BTW Luigi, I see netmap was commited to GENERIC on -CURRENT. I believe it >> may be a good idea to add netmap-ipfw to the base system now, to both >> promote more testing and also to be a good companion to netmap on GENERIC. >> I dont mean a new ipfw-netmap binary under /sbin/ but just the code on >> /usr/src/tools/tools. >> > > yes and some handbook or a better README that at least mentions the > correct syntax for the tools > I think adrian chadd mentioned something about that in an earlier message > > >> >> I've been using netmap-ipfw for a while and sure it lacks more flexbility >> like the ability to kipfw several ports, etc. But as it is right now, it's >> very stable and reliable for a preliminary code. Thats why I believe it >> should be on the base system. Thank you very much for the incredible >> technology. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > From owner-freebsd-net@FreeBSD.ORG Sun Nov 9 23:23:07 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F078726 for ; Sun, 9 Nov 2014 23:23:07 +0000 (UTC) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 02B5C159 for ; Sun, 9 Nov 2014 23:23:07 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id m15so7470490wgh.35 for ; Sun, 09 Nov 2014 15:23:05 -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=HvD9QeOebbOMmTysIaVbO5gCkEcLcWcBtd34WJXyHgU=; b=D0fB2CRZHfE60SGCKad6OuVwdw/x4czROymF7Ic1/TE9hun8rOAiDhJ79rOqVgcJ5+ x6loKrssNM6oHuLbTXgjKGez89M5yjjalfROlZD1btFHaRpceqlhi+Z1aNwMtvKf05ji BX8c/XS7qTnRGipZNwCoSl23/Jpw6t48OSaRQqwV9ovjPkPsq/exTqUvtMScDt/uizeW CA0O6grPz3g7nRmNUhtS+OoZaP+4kSVbasi8Zw8ff9VqKlhEllaM2D6D1+lo7qCGqQg7 XMM/Pt4fXTIA5TN01t7ML20WcBWehMdDxd5WAFoabxI/+ffWhZ/1u6ZORsJ9Dg5k7IIw h/TQ== MIME-Version: 1.0 X-Received: by 10.194.185.229 with SMTP id ff5mr37257698wjc.122.1415575385428; Sun, 09 Nov 2014 15:23:05 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.194.19.9 with HTTP; Sun, 9 Nov 2014 15:23:05 -0800 (PST) In-Reply-To: References: <9C799778-79DC-4D5F-BA5C-EA94A573ED10@freebsdbrasil.com.br> Date: Sun, 9 Nov 2014 15:23:05 -0800 X-Google-Sender-Auth: 5jCvzhqUZAxS48E0J_OHRYBe6JU Message-ID: Subject: Re: netmap-ipfw on em0 em1 From: Luigi Rizzo To: Evandro Nunes Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Patrick Tracanelli , "freebsd-net@freebsd.org" , Mahnaz Talebi 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, 09 Nov 2014 23:23:07 -0000 On Sun, Nov 9, 2014 at 1:17 PM, Evandro Nunes wrote: > professor luigi > > where can I find the code for netmap-fwd you mentioned on usenix paper? > > =E2=80=8Bthat has been renamed to bridge.c cheers luigi =E2=80=8B > > ** https://www.usenix.org/system/files/conference/atc12/atc12-final186.pd= f > > On Sun, Nov 9, 2014 at 5:31 PM, Evandro Nunes > wrote: > >> hello again patrick >> >> On Sun, Nov 9, 2014 at 12:54 AM, Patrick Tracanelli < >> eksffa@freebsdbrasil.com.br> wrote: >> >>> > (Machine-A)<-->Machine-B<--->(MachineC) >>> > >>> > Machine-A: >>> > em0 172.16.251.3/24 >>> > >>> > Machine-B: >>> > em1: 172.16.251.1/24 >>> > em2: 172.16.252.1/24 >>> > 10.0-STABLE w/ latest netmap-ipfw and netmap code from google code >>> > repository >>> > >>> > Machine-C: >>> > em0 172.16.252.3/24 >>> >>> Now, your scenario is a typical routing topology. kipfw has no packet >>> forwarding capabilities whats why when you start it, you are out of >>> forwarding capabilities and therefore, out of communication between mac= hine >>> A and C because they just need it in your topology. >>> >>> So for your testing purposes read again what Mahaza said: >>> >>> >> ipfw works as a bridge and copy >>> >> incoming packets to em0 to em1 if they pass defined rules (and vice >>> versa, >>> >> from em1 to em0). >>> >>> Got it? kipfw will work as a BRIDGE and COPY between the NIC ports. >>> >>> Therefore on your topology do a simple change: >>> >>> Machine-C: >>> ifconfig em0 172.16.251.4/24 >>> >>> So machine C will be in the same network of machine A. >>> >>> WITHOUT kipfw you will be OUT of communication. If you want to have >>> communication without kipfw please configure if_bridge(4) properly. >>> >>> Now WHEN you ./kipfw netmap:em1 netmap:em2 you will BRIDGE em1 and em2 >>> ports and therefore you will HAVE communication between the NICS. >>> >>> And you are done, just as a miracle! Thanks to Luigi. >>> >> >> YES IT WORKED YES >> thank you VERY MUCH for the kind help and for making it clear all the >> stuff I missed reading, yes I assume I should have read more or at least >> understood >> now I can see how the things works and it does work >> >> THANK YOU again very much >> >> >> >>> Now its time to have some fun: >>> >>> ipfw/ipfw add pipe 1 all from 172.16.251.0/24 to 172.16.251.0/24 >>> ipfw/ipfw pipe 1 config bw 128Kbit/s >>> delay 300 >>> >>> and now ping machine-A and machine-C and see dummynet working as >>> expected... >>> >>> I believe you can keep on with your testings now!!! :-) >>> >> >> yes it worked as well >> >> now let me ask you all, other than click, does netmap offers something >> that can do packet forwarding? simple packet forwarding like the scenari= o I >> was trying before? I know this is not kipfw and not bridge but is there >> something? >> >> thank you >> >> >> >>> BTW Luigi, I see netmap was commited to GENERIC on -CURRENT. I believe >>> it may be a good idea to add netmap-ipfw to the base system now, to bot= h >>> promote more testing and also to be a good companion to netmap on GENER= IC. >>> I dont mean a new ipfw-netmap binary under /sbin/ but just the code on >>> /usr/src/tools/tools. >>> >> >> yes and some handbook or a better README that at least mentions the >> correct syntax for the tools >> I think adrian chadd mentioned something about that in an earlier messag= e >> >> >>> >>> I've been using netmap-ipfw for a while and sure it lacks more >>> flexbility like the ability to kipfw several ports, etc. But as it is r= ight >>> now, it's very stable and reliable for a preliminary code. Thats why I >>> believe it should be on the base system. Thank you very much for the >>> incredible technology. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> > --=20 -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 01:33:50 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07A437CE; Mon, 10 Nov 2014 01:33:50 +0000 (UTC) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 773EBF2B; Mon, 10 Nov 2014 01:33:49 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id pn19so6829428lab.4 for ; Sun, 09 Nov 2014 17:33:47 -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=NU2X8LRXWxqU+NH7LLOpMPR++tS3nvPhyI0SvzKZvMo=; b=v3Zf5bIJC8J/j1YjD8wKzQntmXvVQuiTimGfa5Sg6LaL/qb/1PMEV8PzIXgorTXbWn g2OqVzJYGoDKhf7IhW0CfUOfBbhC6RkcuqHZkktZsWEfvdLstFnPpljVJs1Y/rSmmCh+ as08q5S8pkd5AfwYampA6/a37ElIbQ3x0xo3jxy8H2kbmAwL4IrybtT73OgHW2uRNxJf r11n0C6kElU1ONpndN6qFMIkjrauIaCuZBm7Zaj7Ur2p3BTAKSkEJ9cBg6EKlWHbsLQF Xa1RUdr42HNxNecvfhDJFCUrgvFrGUASwQm0IGDgEZyy0hu2HY2quQy0ewAFyqr0vP2W kR9Q== MIME-Version: 1.0 X-Received: by 10.152.37.104 with SMTP id x8mr6484542laj.74.1415583227074; Sun, 09 Nov 2014 17:33:47 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.112.130.168 with HTTP; Sun, 9 Nov 2014 17:33:46 -0800 (PST) In-Reply-To: <7EAA2A23-06F9-44C9-A3E1-62AA37EE5CDA@lists.zabbadoz.net> References: <20141012182551.002b3cc0a45a56d3f34e6174@yamagi.org> <3B4471A7-CDF4-440D-BDD8-3D5B2256B8DD@lists.zabbadoz.net> <7EAA2A23-06F9-44C9-A3E1-62AA37EE5CDA@lists.zabbadoz.net> Date: Sun, 9 Nov 2014 17:33:46 -0800 X-Google-Sender-Auth: hIDLToTb1ol9m0GH421ObSESjlQ Message-ID: Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: Craig Rodrigues To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch 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, 10 Nov 2014 01:33:50 -0000 On Sun, Oct 12, 2014 at 6:07 PM, Bjoern A. Zeeb < bzeeb-lists@lists.zabbadoz.net> wrote: > > > > Can you provide a pointer to your Perforce branch? > > //depot/user/bz/vimage/src/... > > Hi, Since I am more familiar with git than Perforce, I converted your Perforce branch to git and put it on github: https://github.com/rodrigc/bz-vimage I took a look at the history of that branch, and it looks like you merged quite a lot of changes in this branch back to FreeBSD. There were a few places where it looks like the code in your branch diverged from FreeBSD (in carp area, for example). Offhand, can you remember any VIMAGE related memory leaks you might have fixed in this branch which you did not merge back? This one looks pretty simple by removing UMA_ZONE_NOFREE in a few places: https://github.com/rodrigc/bz-vimage/commit/ebe7e4c5e7e5b3dbfc442a25f10ca8681c605c89 In this one, you added dom_pr_register() and dom_pr_unregister() hooks: https://github.com/rodrigc/bz-vimage/commit/a1d5c8bc2f4484e58594ca8fad793aa339a5ef29 but I'm not sure if you wanted to merge this back to FreeBSD or not. Can you think of anything else in this branch that we need for VIMAGE? Thanks. -- Craig From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 05:54:59 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D8725727 for ; Mon, 10 Nov 2014 05:54:59 +0000 (UTC) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A0E5D58 for ; Mon, 10 Nov 2014 05:54:59 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id x12so7907684wgg.17 for ; Sun, 09 Nov 2014 21:54:58 -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=GChSsljsnHRumxPpBhZicEqV5thyh3j3WrPEKi/Vqyg=; b=RFZ5GNOSP/n+kYDOt3ieHE+8vnBIidL4mor0SU5YpPHXeYPshH8UatPd/vZY+qrRSN u7oqSVYRLGyMcfuFLbbNMJ0fIpX5YFx1+4YTN+X7WSIXHHBFDXK5slD5YF6mbrA6TI/O zTGBx4TRZfarNpjJYGtMCO7m7UZ+tfnbPZtOLduNtn91Ltzo35pI2luDcFz2AelTpV3E HfEPxU5uyY7Doq5bN3y9FTfkinuMRugrFSg8lznfTgWev7P5hWKvL/4eajudjH8UBd5g jjhCWpup+dgxa7ISc8wMS73rLNkL6awejqH03SfidDxO/y08miqfZPxVD8zRL6fPEuzq DxpA== X-Received: by 10.180.106.103 with SMTP id gt7mr36419166wib.0.1415598897915; Sun, 09 Nov 2014 21:54:57 -0800 (PST) Received: from [10.151.220.212] (101-236.197-178.cust.bluewin.ch. [178.197.236.101]) by mx.google.com with ESMTPSA id t16sm16236480wjr.28.2014.11.09.21.54.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Nov 2014 21:54:57 -0800 (PST) Message-ID: <54605338.3040103@gmail.com> Date: Mon, 10 Nov 2014 06:55:04 +0100 From: Chris Ernst User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: kldload ip_mroute.ko vs. kernel options MROUTING Content-Type: text/plain; charset=ISO-8859-1; 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, 10 Nov 2014 05:54:59 -0000 Dear Mailinglist I just found out that there are two possibilities to get multicast working in FreeBSD There is: - kldload ip_mroute.ko or - to compile the kernel with: options MROUTING Is there a difference between these two approaches? I notice that, with a custom kernel, patching is much more complex and time consuming. As binary updates are not possible any more. thank you for any replay best regards From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 06:47:42 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D295DEA for ; Mon, 10 Nov 2014 06:47:42 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 15BD2263 for ; Mon, 10 Nov 2014 06:47:42 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sAA6lf50033811 for ; Mon, 10 Nov 2014 06:47:41 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 191975] [ng_iface] [regression] in 10.0: cannot contact local services Date: Mon, 10 Nov 2014 06:47:42 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dgilbert@eicat.ca X-Bugzilla-Status: Needs Triage 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: Mon, 10 Nov 2014 06:47:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191975 --- Comment #11 from dgilbert@eicat.ca --- Additional Information from a new test. I set up a 10.1 RC3 host in VMWare and duplicated it. I configured one as a pppoe server and the other as a pppoe client. They do _not_ replicate this problem. Remaining possible culprits: - l2tp in conjuction with this setup - quagga I still have the suspicion that something is marking the mbufs of the packet in some way so as to convince the ip_input layer to ignore the packets. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 08:17:28 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DEAAA10D for ; Mon, 10 Nov 2014 08:17:28 +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 C65C9DA6 for ; Mon, 10 Nov 2014 08:17:28 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sAA8HSOe035911 for ; Mon, 10 Nov 2014 08:17:28 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194197] [igb] [patch] IGB cards need a kernel option to enable legacy mode (to support ALTQ) Date: Mon, 10 Nov 2014 08:17:29 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-BETA3 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: skeletor@lissyara.su X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 08:17:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194197 skeletor@lissyara.su changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |skeletor@lissyara.su --- Comment #1 from skeletor@lissyara.su --- I have tested this patch (with rebuilding kernel with option IGB_LEGACY_TX, but nothing changed. So, this patch doesn't work for me or I do something wrong. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 09:30:30 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8AE9B184; Mon, 10 Nov 2014 09:30:30 +0000 (UTC) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3F9F8750; Mon, 10 Nov 2014 09:30:30 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id im17so465395vcb.41 for ; Mon, 10 Nov 2014 01:30:29 -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=RTfCTeIcpIkN67rd52RVDCU/QbfGdmyV22ZFj+9h4jQ=; b=E8V6GfwXbQElZGTLKhpsedNtn6LxAZtT7hUuMqSsXlLitRYtibq9JB/r8YQYoBaSPN fxTDP1x/so5HrQaIrKuTuul+fOeYarJpGyzfYgAWOULsF70k5TLTjfksbsitMfAoD/03 ch+y0rUg5b4Z/DPfRwZ3neG62f7XNGuYhprjq/YFjt5NTeFnUgz0cMwxVNmYybB0gdtS K0tfsQjRnV3q72E6oOP/lC79Wn55dhl8B1yZGSi3K7EB4+w4W6t/ACr6K5Ja0nukK/To bilHIG87Y/7IgfLmh77nrktEV7DZqF37os4UBbV+bDCW2mDtKHkZCbPPkCrAkSqrumM2 LnVg== MIME-Version: 1.0 X-Received: by 10.52.9.37 with SMTP id w5mr1487067vda.38.1415611829334; Mon, 10 Nov 2014 01:30:29 -0800 (PST) Received: by 10.220.168.199 with HTTP; Mon, 10 Nov 2014 01:30:29 -0800 (PST) In-Reply-To: References: <20141012182551.002b3cc0a45a56d3f34e6174@yamagi.org> <3B4471A7-CDF4-440D-BDD8-3D5B2256B8DD@lists.zabbadoz.net> <7EAA2A23-06F9-44C9-A3E1-62AA37EE5CDA@lists.zabbadoz.net> Date: Mon, 10 Nov 2014 10:30:29 +0100 Message-ID: Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: Nikolay Denev To: Craig Rodrigues Content-Type: text/plain; charset=UTF-8 Cc: "Bjoern A. Zeeb" , freebsd-arch , "freebsd-virtualization@freebsd.org" , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 09:30:30 -0000 On Mon, Nov 10, 2014 at 2:33 AM, Craig Rodrigues wrote: > On Sun, Oct 12, 2014 at 6:07 PM, Bjoern A. Zeeb < > bzeeb-lists@lists.zabbadoz.net> wrote: > >> >> >> > Can you provide a pointer to your Perforce branch? >> >> //depot/user/bz/vimage/src/... >> >> > Hi, > > Since I am more familiar with git than Perforce, I converted > your Perforce branch to git and put it on github: > > https://github.com/rodrigc/bz-vimage > > I took a look at the history of that branch, and it looks like you > merged quite a lot of changes in this branch back to FreeBSD. > There were a few places where it looks like the code in your branch > diverged from FreeBSD (in carp area, for example). > > Offhand, can you remember any VIMAGE related memory leaks > you might have fixed in this branch which you did not merge back? > > This one looks pretty simple by removing UMA_ZONE_NOFREE in a few > places: > > https://github.com/rodrigc/bz-vimage/commit/ebe7e4c5e7e5b3dbfc442a25f10ca8681c605c89 > > > In this one, you added dom_pr_register() and dom_pr_unregister() hooks: > > https://github.com/rodrigc/bz-vimage/commit/a1d5c8bc2f4484e58594ca8fad793aa339a5ef29 > > but I'm not sure if you wanted to merge this back to FreeBSD or not. > > Can you think of anything else in this branch that we need for VIMAGE? > > Thanks. > > -- > Craig > _______________________________________________ > freebsd-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to "freebsd-virtualization-unsubscribe@freebsd.org" I haven't checked if this is fixed in CURRENT, but at least on 10.0-STABLE r270295M, gif(4) does not seem to play well with VIMAGE. I've just noticed that gif(4) interface unit numbers seem to be unique per machine, regardless of the vnet (I guess unit numbering not properly virtualized), so that if I create gif0 in one vnet jail and try the same in another vnet jail I get "ifconfig: SIOCIFCREATE2: File exists" What's even worse is that once the jail is destroyed, the gif(4) tunnel interface disappears from the system (no longer shows in ifconfig), but you can't reuse the unit number, so I continue to get SIOCIFCREATE2: File exists for gif0 on the host or other vnet jails. --Nikolay From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 14:14:34 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4E422F2; Mon, 10 Nov 2014 14:14:33 +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 AB13098F; Mon, 10 Nov 2014 14:14:33 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id sAAEEP7R053048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 10 Nov 2014 06:14:28 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <5460C839.7060404@freebsd.org> Date: Mon, 10 Nov 2014 22:14:17 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Nikolay Denev , Craig Rodrigues Subject: Re: Enabling VIMAGE by default for FreeBSD 11? References: <20141012182551.002b3cc0a45a56d3f34e6174@yamagi.org> <3B4471A7-CDF4-440D-BDD8-3D5B2256B8DD@lists.zabbadoz.net> <7EAA2A23-06F9-44C9-A3E1-62AA37EE5CDA@lists.zabbadoz.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch 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, 10 Nov 2014 14:14:34 -0000 On 11/10/14, 5:30 PM, Nikolay Denev wrote: > On Mon, Nov 10, 2014 at 2:33 AM, Craig Rodrigues wrote: >> On Sun, Oct 12, 2014 at 6:07 PM, Bjoern A. Zeeb < >> bzeeb-lists@lists.zabbadoz.net> wrote: >> >>> >>>> Can you provide a pointer to your Perforce branch? >>> //depot/user/bz/vimage/src/... >>> >>> >> Hi, >> >> Since I am more familiar with git than Perforce, I converted >> your Perforce branch to git and put it on github: >> >> https://github.com/rodrigc/bz-vimage >> >> I took a look at the history of that branch, and it looks like you >> merged quite a lot of changes in this branch back to FreeBSD. >> There were a few places where it looks like the code in your branch >> diverged from FreeBSD (in carp area, for example). >> >> Offhand, can you remember any VIMAGE related memory leaks >> you might have fixed in this branch which you did not merge back? >> >> This one looks pretty simple by removing UMA_ZONE_NOFREE in a few >> places: >> >> https://github.com/rodrigc/bz-vimage/commit/ebe7e4c5e7e5b3dbfc442a25f10ca8681c605c89 >> >> >> In this one, you added dom_pr_register() and dom_pr_unregister() hooks: >> >> https://github.com/rodrigc/bz-vimage/commit/a1d5c8bc2f4484e58594ca8fad793aa339a5ef29 >> >> but I'm not sure if you wanted to merge this back to FreeBSD or not. >> >> Can you think of anything else in this branch that we need for VIMAGE? >> >> Thanks. >> >> -- >> Craig >> _______________________________________________ >> freebsd-virtualization@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization >> To unsubscribe, send any mail to "freebsd-virtualization-unsubscribe@freebsd.org" > I haven't checked if this is fixed in CURRENT, but at least on > 10.0-STABLE r270295M, > gif(4) does not seem to play well with VIMAGE. > > I've just noticed that gif(4) interface unit numbers seem to be unique > per machine, regardless of the vnet (I guess unit numbering not > properly virtualized), > so that if I create gif0 in one vnet jail and try the same in another > vnet jail I get "ifconfig: SIOCIFCREATE2: File exists" > > What's even worse is that once the jail is destroyed, the gif(4) > tunnel interface disappears from the system (no longer shows in > ifconfig), but you can't reuse the unit number, so > I continue to get SIOCIFCREATE2: File exists for gif0 on the host or > other vnet jails. yes there are some parts of the system where the design is not compatible with virtualization. for example.. if a single /dev entry controls stuff.. which kind of complicates things.. > > --Nikolay > _______________________________________________ > freebsd-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to "freebsd-virtualization-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 14:15:08 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9FB18460 for ; Mon, 10 Nov 2014 14:15:08 +0000 (UTC) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 20D6299C for ; Mon, 10 Nov 2014 14:15:08 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id bs8so10600516wib.5 for ; Mon, 10 Nov 2014 06:15:06 -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=r/GVtFM/UKbHrMy/3Mo6x3jLPWg2aLOcK4AqXNlPJF0=; b=R14eMzVBSM+dRqQX+yZBnm7LI2oCMhNGYqK8/oxIDdtP/Qxi3Rl+HQy6dewMyND6zl tjQV0C1wuhmSRU1Ek2XP8R+LF7FiPiWlk+v/oOwOFOCrZTOiKPwk6Xz6D5Tz4AYTho4e meDvYkqyhBUMVCReJJhAwWugxSseYg5QRxUS0t3x0zYRHWYW6jffENlKxdk2MLGT44jL 4Xvq1IFTaQqKzAUSk2VCK1NEgmuTCZMS1kPKmDvKuSlCYEhlrgRZvg1Aj9djI6mSJCNn op20sI2t53uAIrveRPQ1LQutmomnbI9mGpv/Ts/L0BM+JlWFG/M81GLeb7hc4zox4CGx Mttw== MIME-Version: 1.0 X-Received: by 10.194.248.162 with SMTP id yn2mr43486235wjc.16.1415628544230; Mon, 10 Nov 2014 06:09:04 -0800 (PST) Received: by 10.217.92.7 with HTTP; Mon, 10 Nov 2014 06:09:04 -0800 (PST) In-Reply-To: References: <9C799778-79DC-4D5F-BA5C-EA94A573ED10@freebsdbrasil.com.br> Date: Mon, 10 Nov 2014 12:09:04 -0200 Message-ID: Subject: Re: netmap-ipfw on em0 em1 From: Evandro Nunes To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Patrick Tracanelli , "freebsd-net@freebsd.org" , Mahnaz Talebi 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, 10 Nov 2014 14:15:08 -0000 On Sun, Nov 9, 2014 at 9:23 PM, Luigi Rizzo wrote: > > > On Sun, Nov 9, 2014 at 1:17 PM, Evandro Nunes > wrote: > >> professor luigi >> >> where can I find the code for netmap-fwd you mentioned on usenix paper? >> >> > =E2=80=8Bthat has been renamed to bridge.c > > cheers > luigi > so it does not actually forwards ip packets, does bridging in fact other than OVS and click is there something to forward l3 packets? > =E2=80=8B > > >> >> ** >> https://www.usenix.org/system/files/conference/atc12/atc12-final186.pdf >> >> On Sun, Nov 9, 2014 at 5:31 PM, Evandro Nunes >> wrote: >> >>> hello again patrick >>> >>> On Sun, Nov 9, 2014 at 12:54 AM, Patrick Tracanelli < >>> eksffa@freebsdbrasil.com.br> wrote: >>> >>>> > (Machine-A)<-->Machine-B<--->(MachineC) >>>> > >>>> > Machine-A: >>>> > em0 172.16.251.3/24 >>>> > >>>> > Machine-B: >>>> > em1: 172.16.251.1/24 >>>> > em2: 172.16.252.1/24 >>>> > 10.0-STABLE w/ latest netmap-ipfw and netmap code from google code >>>> > repository >>>> > >>>> > Machine-C: >>>> > em0 172.16.252.3/24 >>>> >>>> Now, your scenario is a typical routing topology. kipfw has no packet >>>> forwarding capabilities whats why when you start it, you are out of >>>> forwarding capabilities and therefore, out of communication between ma= chine >>>> A and C because they just need it in your topology. >>>> >>>> So for your testing purposes read again what Mahaza said: >>>> >>>> >> ipfw works as a bridge and copy >>>> >> incoming packets to em0 to em1 if they pass defined rules (and vice >>>> versa, >>>> >> from em1 to em0). >>>> >>>> Got it? kipfw will work as a BRIDGE and COPY between the NIC ports. >>>> >>>> Therefore on your topology do a simple change: >>>> >>>> Machine-C: >>>> ifconfig em0 172.16.251.4/24 >>>> >>>> So machine C will be in the same network of machine A. >>>> >>>> WITHOUT kipfw you will be OUT of communication. If you want to have >>>> communication without kipfw please configure if_bridge(4) properly. >>>> >>>> Now WHEN you ./kipfw netmap:em1 netmap:em2 you will BRIDGE em1 and em2 >>>> ports and therefore you will HAVE communication between the NICS. >>>> >>>> And you are done, just as a miracle! Thanks to Luigi. >>>> >>> >>> YES IT WORKED YES >>> thank you VERY MUCH for the kind help and for making it clear all the >>> stuff I missed reading, yes I assume I should have read more or at leas= t >>> understood >>> now I can see how the things works and it does work >>> >>> THANK YOU again very much >>> >>> >>> >>>> Now its time to have some fun: >>>> >>>> ipfw/ipfw add pipe 1 all from 172.16.251.0/24 to 172.16.251.0/24 >>>> ipfw/ipfw pipe 1 config bw 128Kbit/s >>>> delay 300 >>>> >>>> and now ping machine-A and machine-C and see dummynet working as >>>> expected... >>>> >>>> I believe you can keep on with your testings now!!! :-) >>>> >>> >>> yes it worked as well >>> >>> now let me ask you all, other than click, does netmap offers something >>> that can do packet forwarding? simple packet forwarding like the scenar= io I >>> was trying before? I know this is not kipfw and not bridge but is there >>> something? >>> >>> thank you >>> >>> >>> >>>> BTW Luigi, I see netmap was commited to GENERIC on -CURRENT. I believe >>>> it may be a good idea to add netmap-ipfw to the base system now, to bo= th >>>> promote more testing and also to be a good companion to netmap on GENE= RIC. >>>> I dont mean a new ipfw-netmap binary under /sbin/ but just the code on >>>> /usr/src/tools/tools. >>>> >>> >>> yes and some handbook or a better README that at least mentions the >>> correct syntax for the tools >>> I think adrian chadd mentioned something about that in an earlier messa= ge >>> >>> >>>> >>>> I've been using netmap-ipfw for a while and sure it lacks more >>>> flexbility like the ability to kipfw several ports, etc. But as it is = right >>>> now, it's very stable and reliable for a preliminary code. Thats why I >>>> believe it should be on the base system. Thank you very much for the >>>> incredible technology. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >> > > > -- > -----------------------------------------+------------------------------- > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL +39-050-2211611 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > -----------------------------------------+------------------------------- > From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 17:09:07 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5A0EF0 for ; Mon, 10 Nov 2014 17:09:07 +0000 (UTC) Received: from mail.grupofundar.com.ar (mail.grupofundar.com.ar [200.70.55.46]) by mx1.freebsd.org (Postfix) with ESMTP id 41366E4C for ; Mon, 10 Nov 2014 17:09:07 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.grupofundar.com.ar (Postfix) with ESMTP id 68CEA2C89B36 for ; Mon, 10 Nov 2014 13:57:15 -0300 (ART) X-Virus-Scanned: amavisd-new at mail.grupofundar.com.ar Received: from mail.grupofundar.com.ar ([127.0.0.1]) by localhost (mail.grupofundar.com.ar [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrYJS54ryJed for ; Mon, 10 Nov 2014 13:57:15 -0300 (ART) Received: from HP-Server (75-139-242-82.static.ftwo.tx.charter.com [75.139.242.82]) by mail.grupofundar.com.ar (Postfix) with ESMTPA id E204D2C888BE for ; Mon, 10 Nov 2014 12:55:07 -0300 (ART) From: "iftd@reaalsns.nl" Subject: con respecto a mi =?ISO-8859-1?Q?=FAltimo?= correo =?ISO-8859-1?Q?electr=F3nico?= To: freebsd-net@freebsd.org MIME-Version: 1.0 Reply-To: david.boucher@reaalsns.nl Date: Mon, 10 Nov 2014 09:54:53 -0600 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Message-Id: <20141110155507.E204D2C888BE@mail.grupofundar.com.ar> 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, 10 Nov 2014 17:09:07 -0000 A la atenci=F3n de : Tengo algo de informaci=F3n vital para usted en relaci=F3n con una herencia que se quiso dar a usted. E-mail o tel=E9fono me llaman para que yo pueda darle una amplia desglose en este proyecto . Saludos, David Boucher www.snsbank.nl From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 20:29:15 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F48E87E for ; Mon, 10 Nov 2014 20:29:15 +0000 (UTC) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 222037B0 for ; Mon, 10 Nov 2014 20:29:15 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id x12so10031291wgg.18 for ; Mon, 10 Nov 2014 12:29:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aW1ntwD85KgwgIxZUaJnWJZ/asMF4SGB4v53qlBXHaY=; b=M6Y/C1xttaN8wYKqFk8ko4yRIRMWMipgtMuYi5ZUECQn4pBpdiwdDYezzNJpnNS/0n lEYnjdzyA0ge0dgSLBCzsba9YBdW+5W62qgvMhah7tSUuybwGnkxBmCIl24FqLBmNUPS YiXmVNA2rZwrNpuKRyarytQycSo2tPOEXzTY8kiSCeNQEsb3p9imk9FnD1qWOn0I4sV6 Yo9OY7eQ79DAcCAjaDpKmpxLPUPXxji6Zvb9plyjLpFT2YGEZ3ph7XAxas8YEj6XzDvf GX6AbpYAaMbp/TuzxWrjFf2HYEybmFsP0AQ0EkfwVks7KIjs+0BnI7fc2ILxkARTuesW uT7g== MIME-Version: 1.0 X-Received: by 10.180.104.232 with SMTP id gh8mr1105135wib.78.1415651352932; Mon, 10 Nov 2014 12:29:12 -0800 (PST) Received: by 10.217.92.7 with HTTP; Mon, 10 Nov 2014 12:29:12 -0800 (PST) In-Reply-To: References: <9C799778-79DC-4D5F-BA5C-EA94A573ED10@freebsdbrasil.com.br> Date: Mon, 10 Nov 2014 18:29:12 -0200 Message-ID: Subject: Re: netmap-ipfw on em0 em1 From: Evandro Nunes To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Patrick Tracanelli , "freebsd-net@freebsd.org" , Mahnaz Talebi 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, 10 Nov 2014 20:29:15 -0000 On Mon, Nov 10, 2014 at 12:09 PM, Evandro Nunes wrote: > On Sun, Nov 9, 2014 at 9:23 PM, Luigi Rizzo wrote: > >> >> >> On Sun, Nov 9, 2014 at 1:17 PM, Evandro Nunes >> wrote: >> >>> professor luigi >>> >>> where can I find the code for netmap-fwd you mentioned on usenix paper? >>> >>> >> =E2=80=8Bthat has been renamed to bridge.c >> >> cheers >> luigi >> > > so it does not actually forwards ip packets, does bridging in fact > other than OVS and click is there something to forward l3 packets? > > dear professor luigi, i have some numbers, I am filtering 773Kpps with kipfw using 60% of CPU and system using the rest, this system is a 8core at 2.4Ghz, but only one core is in use in this next round of tests, my NIC is now an avoton with igb(4) driver, currently with 4 queues per NIC (total 8 queues for kipfw bridge) i have read in your papers we should expect something similar to 1.48Mpps how can I benefit from the other CPUs which are completely idle? I tried CPU Affinity (cpuset) kipfw but system CPU usage follows userland kipfw so I could not set one CPU to userland while other for system can you please enlighten? > > >> =E2=80=8B >> >> >>> >>> ** >>> https://www.usenix.org/system/files/conference/atc12/atc12-final186.pdf >>> >>> On Sun, Nov 9, 2014 at 5:31 PM, Evandro Nunes >>> wrote: >>> >>>> hello again patrick >>>> >>>> On Sun, Nov 9, 2014 at 12:54 AM, Patrick Tracanelli < >>>> eksffa@freebsdbrasil.com.br> wrote: >>>> >>>>> > (Machine-A)<-->Machine-B<--->(MachineC) >>>>> > >>>>> > Machine-A: >>>>> > em0 172.16.251.3/24 >>>>> > >>>>> > Machine-B: >>>>> > em1: 172.16.251.1/24 >>>>> > em2: 172.16.252.1/24 >>>>> > 10.0-STABLE w/ latest netmap-ipfw and netmap code from google code >>>>> > repository >>>>> > >>>>> > Machine-C: >>>>> > em0 172.16.252.3/24 >>>>> >>>>> Now, your scenario is a typical routing topology. kipfw has no packet >>>>> forwarding capabilities whats why when you start it, you are out of >>>>> forwarding capabilities and therefore, out of communication between m= achine >>>>> A and C because they just need it in your topology. >>>>> >>>>> So for your testing purposes read again what Mahaza said: >>>>> >>>>> >> ipfw works as a bridge and copy >>>>> >> incoming packets to em0 to em1 if they pass defined rules (and vic= e >>>>> versa, >>>>> >> from em1 to em0). >>>>> >>>>> Got it? kipfw will work as a BRIDGE and COPY between the NIC ports. >>>>> >>>>> Therefore on your topology do a simple change: >>>>> >>>>> Machine-C: >>>>> ifconfig em0 172.16.251.4/24 >>>>> >>>>> So machine C will be in the same network of machine A. >>>>> >>>>> WITHOUT kipfw you will be OUT of communication. If you want to have >>>>> communication without kipfw please configure if_bridge(4) properly. >>>>> >>>>> Now WHEN you ./kipfw netmap:em1 netmap:em2 you will BRIDGE em1 and em= 2 >>>>> ports and therefore you will HAVE communication between the NICS. >>>>> >>>>> And you are done, just as a miracle! Thanks to Luigi. >>>>> >>>> >>>> YES IT WORKED YES >>>> thank you VERY MUCH for the kind help and for making it clear all the >>>> stuff I missed reading, yes I assume I should have read more or at lea= st >>>> understood >>>> now I can see how the things works and it does work >>>> >>>> THANK YOU again very much >>>> >>>> >>>> >>>>> Now its time to have some fun: >>>>> >>>>> ipfw/ipfw add pipe 1 all from 172.16.251.0/24 to 172.16.251.0/24 >>>>> ipfw/ipfw pipe 1 config bw >>>>> 128Kbit/s delay 300 >>>>> >>>>> and now ping machine-A and machine-C and see dummynet working as >>>>> expected... >>>>> >>>>> I believe you can keep on with your testings now!!! :-) >>>>> >>>> >>>> yes it worked as well >>>> >>>> now let me ask you all, other than click, does netmap offers something >>>> that can do packet forwarding? simple packet forwarding like the scena= rio I >>>> was trying before? I know this is not kipfw and not bridge but is ther= e >>>> something? >>>> >>>> thank you >>>> >>>> >>>> >>>>> BTW Luigi, I see netmap was commited to GENERIC on -CURRENT. I believ= e >>>>> it may be a good idea to add netmap-ipfw to the base system now, to b= oth >>>>> promote more testing and also to be a good companion to netmap on GEN= ERIC. >>>>> I dont mean a new ipfw-netmap binary under /sbin/ but just the code o= n >>>>> /usr/src/tools/tools. >>>>> >>>> >>>> yes and some handbook or a better README that at least mentions the >>>> correct syntax for the tools >>>> I think adrian chadd mentioned something about that in an earlier >>>> message >>>> >>>> >>>>> >>>>> I've been using netmap-ipfw for a while and sure it lacks more >>>>> flexbility like the ability to kipfw several ports, etc. But as it is= right >>>>> now, it's very stable and reliable for a preliminary code. Thats why = I >>>>> believe it should be on the base system. Thank you very much for the >>>>> incredible technology. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >> >> >> -- >> -----------------------------------------+------------------------------= - >> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione >> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa >> TEL +39-050-2211611 . via Diotisalvi 2 >> Mobile +39-338-6809875 . 56122 PISA (Italy) >> -----------------------------------------+------------------------------= - >> > > From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 20:43:14 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6C6FCA1 for ; Mon, 10 Nov 2014 20:43:14 +0000 (UTC) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (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 9D1D3975 for ; Mon, 10 Nov 2014 20:43:14 +0000 (UTC) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.14.7/8.14.7) with ESMTP id sAAKIecY078772 for ; Mon, 10 Nov 2014 14:18:40 -0600 (CST) (envelope-from mgrooms@shrew.net) Received: from [10.16.32.30] (72-48-144-84.static.grandenetworks.net [72.48.144.84]) by mail.shrew.net (Postfix) with ESMTPSA id E49AB188003 for ; Mon, 10 Nov 2014 14:18:28 -0600 (CST) Message-ID: <54611DD9.2060107@shrew.net> Date: Mon, 10 Nov 2014 14:19:37 -0600 From: Matthew Grooms User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: SSL certificate check error ... Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx2.shrew.net [10.24.10.11]); Mon, 10 Nov 2014 14:18:40 -0600 (CST) 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, 10 Nov 2014 20:43:14 -0000 All, I am seeing a problem with certificate checking on several stock FreeBSD 10.0-RELEASE-p12 hosts using the base openssl. The ca_root_nss-3.17.2 package is installed with the option to create the symlink in /etc/ssl enabled ... # ls -la /etc/ssl total 20 drwxr-xr-x 2 root wheel 512 Nov 10 13:25 . drwxr-xr-x 21 root wheel 2048 Oct 28 23:45 .. lrwxr-xr-x 1 root wheel 38 Nov 10 13:24 cert.pem -> /usr/local/share/certs/ca-root-nss.crt -rw-r--r-- 1 root wheel 10929 Jan 16 2014 openssl.cnf When I try to run s_client as a test to www.google.com, I see "Verify return code: 20 (unable to get local issuer certificate)" ... # openssl s_client -connect www.google.com:443 CONNECTED(00000003) depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify error:num=20:unable to get local issuer certificate verify return:0 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com i:/C=US/O=Google Inc/CN=Google Internet Authority G2 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority --- Server certificate -----BEGIN CERTIFICATE----- MIIEdjCCA16gAwIBAgIIG6nRQAWDXAAwDQYJKoZIhvcNAQEFBQAwSTELMAkGA1UE BhMCVVMxEzARBgNVBAoTCkdvb2dsZSBJbmMxJTAjBgNVBAMTHEdvb2dsZSBJbnRl cm5ldCBBdXRob3JpdHkgRzIwHhcNMTQxMDIyMTI1NzUxWhcNMTUwMTIwMDAwMDAw WjBoMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwN TW91bnRhaW4gVmlldzETMBEGA1UECgwKR29vZ2xlIEluYzEXMBUGA1UEAwwOd3d3 Lmdvb2dsZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBUjaR OXkELfB431tzr0Y6Y2+YzjKiqrrDeBgFZqh8OCuzqCpoCNQQPWJqN8pPv4q+pZOd 1smHSo0xhZP1SB9ZdW52gXy9OLc6XHA0OLuagk/QVLFo7TyeXNBEX3RO0qTqpjJ6 lIE6mMlBvWDzsZxdyM37NN6Sk8U9QaI0tEmaTxnGrxkwhPYcZjbX6JrqhhECMebu A/TIU4QbD7RhIubXPn7wjQWGZccpexoynxbw7rhW52FOsWsjy0trvFtWdoXwJji1 Ls68cbBqFQN3bAlFp14yJ/cf4pVvxIUzplKQZshAQzpnBelFI4Q9EMRai8nNWPym pqq9efL//ubLJUq5AgMBAAGjggFBMIIBPTAdBgNVHSUEFjAUBggrBgEFBQcDAQYI KwYBBQUHAwIwGQYDVR0RBBIwEIIOd3d3Lmdvb2dsZS5jb20waAYIKwYBBQUHAQEE XDBaMCsGCCsGAQUFBzAChh9odHRwOi8vcGtpLmdvb2dsZS5jb20vR0lBRzIuY3J0 MCsGCCsGAQUFBzABhh9odHRwOi8vY2xpZW50czEuZ29vZ2xlLmNvbS9vY3NwMB0G A1UdDgQWBBSA1gUvlcoovYeMXdLiILdTYRyBoDAMBgNVHRMBAf8EAjAAMB8GA1Ud IwQYMBaAFErdBhYbvPZotXb1gba7Yhq6WoEvMBcGA1UdIAQQMA4wDAYKKwYBBAHW eQIFATAwBgNVHR8EKTAnMCWgI6Ahhh9odHRwOi8vcGtpLmdvb2dsZS5jb20vR0lB RzIuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQBjkgHIXprUI8Y1r8XepqstPieJHrew mfjAcg6S15hQF0pd2p7MrOf26pTbe7z84ZOVjODw6PZmRK6wap+6ow14Q0hZDes8 ugePDxkCTDjX58Mg00uakMRRmizgr0a37O4f3D2VqOdx4doeRenMdx0RluxnDT4K gRAXW41WB04Hr8ijwI0q4/0Gw5PzMJgQZ987f+zrUhIW5xDzo1clMSQOYM9mD8DH 6uVTlWv04KUAy+GkNqweDP5QT/1gdYh9FIFeMfVuaVNJwHibIfqXJX0clGJRW6GG TAhXz7Hr629+6VEKKgGiVmGV1azv6Eran390kzGhRWdxvrhPVrASw9S2 -----END CERTIFICATE----- subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2 --- No client certificate CA names sent --- SSL handshake has read 3719 bytes and written 435 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES128-GCM-SHA256 Session-ID: 9890FB78A01C235769387820574E847C0F76E80DBDC867D6EC5D4422B944E956 Session-ID-ctx: Master-Key: 86B4E5CBDC553D8740C462194E9244870D2468C8A736097CD467EF7461EE0ACF3D96C581EF6F68AF62218B451BBA03D7 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 100800 (seconds) TLS session ticket: 0000 - be 92 f9 6b be 9e 07 5c-dc a4 44 5e a5 06 a8 02 ...k...\..D^.... 0010 - 3b b3 56 cf 98 b5 72 4f-82 fe 6a 7a 44 2f b7 24 ;.V...rO..jzD/.$ 0020 - 7c 23 57 f9 36 94 d6 83-54 21 dc 10 a2 df ac 43 |#W.6...T!.....C 0030 - 1b 8b b0 9e b3 b0 d8 e8-7a 0a d0 b2 55 8e 96 0d ........z...U... 0040 - 3c ff d2 af 65 ea c7 69-1b a4 bb 04 f2 73 c2 a8 <...e..i.....s.. 0050 - 6c b9 0d 54 cb 50 f2 5e-fc a8 0a 5a ec 4d 10 c6 l..T.P.^...Z.M.. 0060 - 34 f1 3b cb 14 96 f8 0f-1d 75 bd c6 56 61 73 64 4.;......u..Vasd 0070 - 98 55 c5 24 18 43 e7 58-cc 2f 50 35 03 14 de c5 .U.$.C.X./P5.... 0080 - d7 12 5b 58 6d 6e 6f 7c-61 78 40 1a 02 66 31 94 ..[Xmno|ax@..f1. 0090 - 6d a0 fb 7c 36 aa 4c d2-38 9c dd 89 f9 5c 4a 62 m..|6.L.8....\Jb 00a0 - f6 f7 e0 24 ...$ Start Time: 1415648696 Timeout : 300 (sec) Verify return code: 20 (unable to get local issuer certificate) --- ... but when I explicitly specify the path to /etc/ssl/cert.pem, it works fine ... # openssl s_client -CApath /etc/ssl/cert.pem -connect www.google.com:443 CONNECTED(00000003) depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority verify return:1 depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify return:1 depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2 verify return:1 depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = www.google.com verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com i:/C=US/O=Google Inc/CN=Google Internet Authority G2 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority --- Server certificate -----BEGIN CERTIFICATE----- MIIEdjCCA16gAwIBAgIIG6nRQAWDXAAwDQYJKoZIhvcNAQEFBQAwSTELMAkGA1UE BhMCVVMxEzARBgNVBAoTCkdvb2dsZSBJbmMxJTAjBgNVBAMTHEdvb2dsZSBJbnRl cm5ldCBBdXRob3JpdHkgRzIwHhcNMTQxMDIyMTI1NzUxWhcNMTUwMTIwMDAwMDAw WjBoMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwN TW91bnRhaW4gVmlldzETMBEGA1UECgwKR29vZ2xlIEluYzEXMBUGA1UEAwwOd3d3 Lmdvb2dsZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBUjaR OXkELfB431tzr0Y6Y2+YzjKiqrrDeBgFZqh8OCuzqCpoCNQQPWJqN8pPv4q+pZOd 1smHSo0xhZP1SB9ZdW52gXy9OLc6XHA0OLuagk/QVLFo7TyeXNBEX3RO0qTqpjJ6 lIE6mMlBvWDzsZxdyM37NN6Sk8U9QaI0tEmaTxnGrxkwhPYcZjbX6JrqhhECMebu A/TIU4QbD7RhIubXPn7wjQWGZccpexoynxbw7rhW52FOsWsjy0trvFtWdoXwJji1 Ls68cbBqFQN3bAlFp14yJ/cf4pVvxIUzplKQZshAQzpnBelFI4Q9EMRai8nNWPym pqq9efL//ubLJUq5AgMBAAGjggFBMIIBPTAdBgNVHSUEFjAUBggrBgEFBQcDAQYI KwYBBQUHAwIwGQYDVR0RBBIwEIIOd3d3Lmdvb2dsZS5jb20waAYIKwYBBQUHAQEE XDBaMCsGCCsGAQUFBzAChh9odHRwOi8vcGtpLmdvb2dsZS5jb20vR0lBRzIuY3J0 MCsGCCsGAQUFBzABhh9odHRwOi8vY2xpZW50czEuZ29vZ2xlLmNvbS9vY3NwMB0G A1UdDgQWBBSA1gUvlcoovYeMXdLiILdTYRyBoDAMBgNVHRMBAf8EAjAAMB8GA1Ud IwQYMBaAFErdBhYbvPZotXb1gba7Yhq6WoEvMBcGA1UdIAQQMA4wDAYKKwYBBAHW eQIFATAwBgNVHR8EKTAnMCWgI6Ahhh9odHRwOi8vcGtpLmdvb2dsZS5jb20vR0lB RzIuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQBjkgHIXprUI8Y1r8XepqstPieJHrew mfjAcg6S15hQF0pd2p7MrOf26pTbe7z84ZOVjODw6PZmRK6wap+6ow14Q0hZDes8 ugePDxkCTDjX58Mg00uakMRRmizgr0a37O4f3D2VqOdx4doeRenMdx0RluxnDT4K gRAXW41WB04Hr8ijwI0q4/0Gw5PzMJgQZ987f+zrUhIW5xDzo1clMSQOYM9mD8DH 6uVTlWv04KUAy+GkNqweDP5QT/1gdYh9FIFeMfVuaVNJwHibIfqXJX0clGJRW6GG TAhXz7Hr629+6VEKKgGiVmGV1azv6Eran390kzGhRWdxvrhPVrASw9S2 -----END CERTIFICATE----- subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2 --- No client certificate CA names sent --- SSL handshake has read 3719 bytes and written 435 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES128-GCM-SHA256 Session-ID: 9DD76F7AC8D34085E2B230CA02B955D3A35482C5AD983CD43A0AF65EDDF0905B Session-ID-ctx: Master-Key: FCF5D6AB32816ABD660AB744386531308C3F3203BBB61EB8273A5783DDE92B04C87ADA3DB12C87092BB7BE21CFAD3CCA Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 100800 (seconds) TLS session ticket: 0000 - be 92 f9 6b be 9e 07 5c-dc a4 44 5e a5 06 a8 02 ...k...\..D^.... 0010 - 63 64 66 84 cd c8 07 dc-69 64 6f ff 69 05 99 a0 cdf.....ido.i... 0020 - f4 d7 00 1a 3c 36 41 61-70 5b b4 79 2c 45 c1 3b ....<6Aap[.y,E.; 0030 - 6d 5e 13 77 09 3f f8 35-f5 e4 92 ae ce c8 f9 7b m^.w.?.5.......{ 0040 - ca 6e 49 94 cd 19 51 89-a3 f4 32 64 a6 a5 27 66 .nI...Q...2d..'f 0050 - 96 d1 f0 c6 7b a6 07 20-7b 35 d9 0b f7 f1 8c a5 ....{.. {5...... 0060 - e7 58 1d 0c b3 86 12 d6-86 49 4c 7d 31 c5 1a b6 .X.......IL}1... 0070 - 3f 7a 8a b5 e5 da 63 a3-f2 2b ee f3 ae 20 3d 1a ?z....c..+... =. 0080 - fd d7 d7 af f8 db 11 73-eb 3a 9b cb 41 a9 be 5c .......s.:..A..\ 0090 - ec cc 65 1f 3c 13 a7 57-92 a5 cc d9 39 05 41 9d ..e.<..W....9.A. 00a0 - 9c 3f 94 d8 .?.. Start Time: 1415648909 Timeout : 300 (sec) Verify return code: 0 (ok) --- Also, if I run the commands under truss I see that the file /etc/ssl/cert.pem is not being opened when I do not specify the option on the command line ... # truss openssl s_client -connect www.google.com:443 ... open("/dev/crypto",O_RDWR,00) ERR#2 'No such file or directory' open("/dev/crypto",O_RDWR,00) ERR#2 'No such file or directory' open("/etc/ssl/openssl.cnf",O_RDONLY,0666) = 3 (0x3) fstat(3,{ mode=-rw-r--r-- ,inode=1123703,size=10929,blksize=32768 }) = 0 (0x0) read(3,"# $FreeBSD: release/10.0.0/crypt"...,32768) = 10929 (0x2ab1) read(3,0x80186e000,32768) = 0 (0x0) close(3) = 0 (0x0) sigaction(SIGPIPE,{ SIG_IGN SA_RESTART ss_t },{ SIG_IGN SA_RESTART ss_t }) = 0 (0x0) issetugid(0x7fffffffd2c0,0xc8,0x1,0x7fffffffd538,0x0,0x800c82648) = 0 (0x0) issetugid(0x7fffffffdf5a,0x800c642bf,0x8,0x52,0x0,0x800c82648) = 0 (0x0) stat("/root/.rnd",0x7fffffffce08) ERR#2 'No such file or directory' getpid() = 16324 (0x3fc4) __sysctl(0x7fffffffd1c8,0x2,0x7fffffffd128,0x7fffffffd1c0,0x0,0x0) = 0 (0x0) getpid() = 16324 (0x3fc4) getpid() = 16324 (0x3fc4) getpid() = 16324 (0x3fc4) getpid() = 16324 (0x3fc4) getpid() = 16324 (0x3fc4) getpid() = 16324 (0x3fc4) getpid() = 16324 (0x3fc4) getpid() = 16324 (0x3fc4) getpid() = 16324 (0x3fc4) getpid() = 16324 (0x3fc4) getpid() = 16324 (0x3fc4) issetugid(0x0,0x80,0x10,0x2,0x368,0x1) = 0 (0x0) open("/etc/resolv.conf",O_CLOEXEC,0666) = 3 (0x3) fstat(3,{ mode=-rw-r--r-- ,inode=1123958,size=35,blksize=32768 }) = 0 (0x0) read(3,"search cn.bf\nnameserver 10.16.6"...,32768) = 35 (0x23) read(3,0x8018b3000,32768) = 0 (0x0) close(3) = 0 (0x0) issetugid(0x0,0x8018009c0,0x14,0x3,0x7fffffffc2b0,0x801801068) = 0 (0x0) stat("/etc/nsswitch.conf",{ mode=-rw-r--r-- ,inode=1123624,size=324,blksize=32768 }) = 0 (0x0) open("/etc/nsswitch.conf",O_CLOEXEC,0666) = 3 (0x3) ioctl(3,TIOCGETA,0xffffca80) ERR#25 'Inappropriate ioctl for device' fstat(3,{ mode=-rw-r--r-- ,inode=1123624,size=324,blksize=32768 }) = 0 (0x0) read(3,"#\n# nsswitch.conf(5) - name ser"...,32768) = 324 (0x144) read(3,0x8018b3000,32768) = 0 (0x0) ... and it is being opened when I do specify the option on the command line ... # truss openssl s_client -CApath /etc/ssl/cert.pem -connect www.google.com:443 ... open("/dev/crypto",O_RDWR,00) ERR#2 'No such file or directory' open("/dev/crypto",O_RDWR,00) ERR#2 'No such file or directory' open("/etc/ssl/openssl.cnf",O_RDONLY,0666) = 3 (0x3) fstat(3,{ mode=-rw-r--r-- ,inode=1123703,size=10929,blksize=32768 }) = 0 (0x0) read(3,"# $FreeBSD: release/10.0.0/crypt"...,32768) = 10929 (0x2ab1) read(3,0x80186e000,32768) = 0 (0x0) close(3) = 0 (0x0) sigaction(SIGPIPE,{ SIG_IGN SA_RESTART ss_t },{ SIG_IGN SA_RESTART ss_t }) = 0 (0x0) issetugid(0x7fffffffd290,0xc8,0x1,0x7fffffffd508,0x0,0x800c82648) = 0 (0x0) issetugid(0x7fffffffdf5c,0x800c642bf,0x8,0x52,0x0,0x800c82648) = 0 (0x0) stat("/root/.rnd",0x7fffffffcdd8) ERR#2 'No such file or directory' getpid() = 16371 (0x3ff3) __sysctl(0x7fffffffd198,0x2,0x7fffffffd0f8,0x7fffffffd190,0x0,0x0) = 0 (0x0) getpid() = 16371 (0x3ff3) getpid() = 16371 (0x3ff3) getpid() = 16371 (0x3ff3) getpid() = 16371 (0x3ff3) getpid() = 16371 (0x3ff3) getpid() = 16371 (0x3ff3) getpid() = 16371 (0x3ff3) getpid() = 16371 (0x3ff3) getpid() = 16371 (0x3ff3) getpid() = 16371 (0x3ff3) open("/etc/ssl/cert.pem",O_RDONLY,0666) = 3 (0x3) fstat(3,{ mode=-rw-r--r-- ,inode=1052618,size=908574,blksize=32768 }) = 0 (0x0) read(3,"##\n## ca-root-nss.crt -- Bundl"...,32768) = 32768 (0x8000) madvise(0x80186a000,0x2000,0x5,0xaaaaaaaaaaaaaaab,0x8018017a0,0x80127cb10) = 0 (0x0) madvise(0x8018a1000,0x4000,0x5,0xaaaaaaaaaaaaaaab,0x8018017a0,0x80127cb10) = 0 (0x0) madvise(0x8018ac000,0x3000,0x5,0xaaaaaaaaaaaaaaab,0x8018017a0,0x80127cb10) = 0 (0x0) madvise(0x8018bc000,0x2000,0x5,0xaaaaaaaaaaaaaaab,0x8018017a0,0x80127cb10) = 0 (0x0) madvise(0x8018cd000,0x3000,0x5,0xaaaaaaaaaaaaaaab,0x8018017a0,0x80127cb10) = 0 (0x0) madvise(0x8018df000,0x2000,0x5,0xaaaaaaaaaaaaaaab,0x8018017a0,0x80127cb10) = 0 (0x0) madvise(0x801900000,0x2000,0x5,0xaaaaaaaaaaaaaaab,0x8018017a0,0x80127cb10) = 0 (0x0) madvise(0x801875000,0x1000,0x5,0xaaaaaaaaaaaaaaab,0x801800c48,0x80127cb10) = 0 (0x0) madvise(0x801887000,0x2000,0x5,0xaaaaaaaaaaaaaaab,0x801800c48,0x80127cb10) = 0 (0x0) read(3," 42:68:ac:a0:bd:4e:5a:da:18:bf:6"...,32768) = 32768 (0x8000) read(3,":9a:9b:bb:\n "...,32768) = 32768 (0x8000) read(3," 17:7d:a0:f9:b4:dd:c5:c5:eb"...,32768) = 32768 (0x8000) madvise(0x8018ba000,0x6000,0x5,0xaaaaaaaaaaaaaaab,0x7fffffffc770,0x80127cb10) = 0 (0x0) madvise(0x8018f1000,0xc000,0x5,0xaaaaaaaaaaaaaaab,0x7fffffffc770,0x80127cb10) = 0 (0x0) madvise(0x80190e000,0x3000,0x5,0xaaaaaaaaaaaaaaab,0x7fffffffc770,0x80127cb10) = 0 (0x0) madvise(0x801921000,0x5000,0x5,0xaaaaaaaaaaaaaaab,0x7fffffffc770,0x80127cb10) = 0 (0x0) madvise(0x801936000,0x2000,0x5,0xaaaaaaaaaaaaaaab,0x7fffffffc770,0x80127cb10) = 0 (0x0) read(3,"c Constraints: critical\n "...,32768) = 32768 (0x8000) read(3,"DYu5Def131TN3ubY1gkIl2PlwS6w\nt0"...,32768) = 32768 (0x8000) read(3,"\nxvbxrN8y8NmBGuScvfaAFPDRLLmF9d"...,32768) = 32768 (0x8000) read(3,"f:1f:31:9c:\n "...,32768) = 32768 (0x8000) read(3,"igiCert Inc, OU=www.digicert.com"...,32768) = 32768 (0x8000) read(3,"93:36:85:23:88:8a:3c:03:68:d3:c9"...,32768) = 32768 (0x8000) read(3,"orzAzu8T2bgmmkTPiab+ci2hC6X5L8GC"...,32768) = 32768 (0x8000) read(3,"2zsmWLIodz2uFHdh\n1voqZiegDfqnc1"...,32768) = 32768 (0x8000) read(3,"hUNfBvitbtaSeodlyWL0AG0y/YckUHUW"...,32768) = 32768 (0x8000) read(3," CA:TRUE\n Signatu"...,32768) = 32768 (0x8000) read(3,":22:d7:8b:0b:\n "...,32768) = 32768 (0x8000) read(3," 6b:53:7f:db:df:df:f3:71:3d:26:"...,32768) = 32768 (0x8000) read(3,"f:f2:89:4d:d4:ec:c5:e2:e6:7a:d0:"...,32768) = 32768 (0x8000) read(3,":57:d2:b0:0a:\n "...,32768) = 32768 (0x8000) read(3," X509v3 CRL Distribution Po"...,32768) = 32768 (0x8000) read(3,"60:45:f2:31:eb:a9:31:\n "...,32768) = 32768 (0x8000) read(3,"4QgEBBAQDAgAHMDgGCWCGSAGG+EIBDQQ"...,32768) = 32768 (0x8000) read(3,"9:28:a7:\n 2e"...,32768) = 32768 (0x8000) read(3,"A1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/"...,32768) = 32768 (0x8000) read(3,"4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3G"...,32768) = 32768 (0x8000) read(3,"QUFADCBvjE/MD0GA1UEAww2VMOc\nUkt"...,32768) = 32768 (0x8000) read(3,"dq6hw2v+vPhwvCkxWeM\n1tZUOt4KpLo"...,32768) = 32768 (0x8000) read(3," Exponent: 65537 (0x10001"...,32768) = 32768 (0x8000) read(3,":35:88:67:74:57:e3:df:8c:b8:a7:7"...,32768) = 23838 (0x5d1e) read(3,0x801899000,32768) = 0 (0x0) close(3) = 0 (0x0) getpid() = 16371 (0x3ff3) issetugid(0x0,0x80,0x10,0x2,0x368,0x1) = 0 (0x0) open("/etc/resolv.conf",O_CLOEXEC,0666) = 3 (0x3) fstat(3,{ mode=-rw-r--r-- ,inode=1123958,size=35,blksize=32768 }) = 0 (0x0) read(3,"search cn.bf\nnameserver 10.16.6"...,32768) = 35 (0x23) read(3,0x801931000,32768) = 0 (0x0) close(3) = 0 (0x0) issetugid(0x0,0x801801cf8,0x33,0x3,0x7fffffffc280,0x801801c38) = 0 (0x0) stat("/etc/nsswitch.conf",{ mode=-rw-r--r-- ,inode=1123624,size=324,blksize=32768 }) = 0 (0x0) open("/etc/nsswitch.conf",O_CLOEXEC,0666) = 3 (0x3) ioctl(3,TIOCGETA,0xffffca50) ERR#25 'Inappropriate ioctl for device' fstat(3,{ mode=-rw-r--r-- ,inode=1123624,size=324,blksize=32768 }) = 0 (0x0) read(3,"#\n# nsswitch.conf(5) - name ser"...,32768) = 324 (0x144) read(3,0x801931000,32768) = 0 (0x0) This is the only copy of openssl on my system ... # whereis openssl openssl: /usr/bin/openssl /usr/share/openssl/man/man1/openssl.1.gz Did something change with the FreeBSD 10 configuration of OpenSSL? At first I thought it was a problem with this particular host, but I've been able to reproduce the problem on 3 different 10.x hosts I've tested so far. I don't see how an unmodified program will pickup the default system CA file unless that problem has an option to explicitly hand in the path. Was this intended? Thanks in advance, -Matthew From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 23:28:58 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD4F3C94 for ; Mon, 10 Nov 2014 23:28:57 +0000 (UTC) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (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 A360FC7E for ; Mon, 10 Nov 2014 23:28:56 +0000 (UTC) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.14.7/8.14.7) with ESMTP id sAANRqQ7080667 for ; Mon, 10 Nov 2014 17:27:52 -0600 (CST) (envelope-from mgrooms@shrew.net) Received: from [10.16.32.30] (72-48-144-84.static.grandenetworks.net [72.48.144.84]) by mail.shrew.net (Postfix) with ESMTPSA id 1F60A188003 for ; Mon, 10 Nov 2014 17:27:41 -0600 (CST) Message-ID: <54614A31.8030209@shrew.net> Date: Mon, 10 Nov 2014 17:28:49 -0600 From: Matthew Grooms User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: SSL certificate check error ... References: <54611DD9.2060107@shrew.net> In-Reply-To: <54611DD9.2060107@shrew.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx2.shrew.net [10.24.10.11]); Mon, 10 Nov 2014 17:27:52 -0600 (CST) 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, 10 Nov 2014 23:28:58 -0000 Ok, I feel a little silly. These commands do not work without the CAfile specified on freebsd 8.x or 9.x either. Sorry for the noise. -Matthew On 11/10/2014 2:19 PM, Matthew Grooms wrote: > All, > > I am seeing a problem with certificate checking on several stock FreeBSD > 10.0-RELEASE-p12 hosts using the base openssl. The ca_root_nss-3.17.2 > package is installed with the option to create the symlink in /etc/ssl > enabled ... > > # ls -la /etc/ssl > total 20 > drwxr-xr-x 2 root wheel 512 Nov 10 13:25 . > drwxr-xr-x 21 root wheel 2048 Oct 28 23:45 .. > lrwxr-xr-x 1 root wheel 38 Nov 10 13:24 cert.pem -> > /usr/local/share/certs/ca-root-nss.crt > -rw-r--r-- 1 root wheel 10929 Jan 16 2014 openssl.cnf > > When I try to run s_client as a test to www.google.com, I see "Verify > return code: 20 (unable to get local issuer certificate)" ... > > # openssl s_client -connect www.google.com:443 > CONNECTED(00000003) > depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA > verify error:num=20:unable to get local issuer certificate > verify return:0 > --- > Certificate chain > 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com > i:/C=US/O=Google Inc/CN=Google Internet Authority G2 > 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 > i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA > 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA > i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority > --- > Server certificate > -----BEGIN CERTIFICATE----- > MIIEdjCCA16gAwIBAgIIG6nRQAWDXAAwDQYJKoZIhvcNAQEFBQAwSTELMAkGA1UE > BhMCVVMxEzARBgNVBAoTCkdvb2dsZSBJbmMxJTAjBgNVBAMTHEdvb2dsZSBJbnRl > cm5ldCBBdXRob3JpdHkgRzIwHhcNMTQxMDIyMTI1NzUxWhcNMTUwMTIwMDAwMDAw > WjBoMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwN > TW91bnRhaW4gVmlldzETMBEGA1UECgwKR29vZ2xlIEluYzEXMBUGA1UEAwwOd3d3 > Lmdvb2dsZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBUjaR > OXkELfB431tzr0Y6Y2+YzjKiqrrDeBgFZqh8OCuzqCpoCNQQPWJqN8pPv4q+pZOd > 1smHSo0xhZP1SB9ZdW52gXy9OLc6XHA0OLuagk/QVLFo7TyeXNBEX3RO0qTqpjJ6 > lIE6mMlBvWDzsZxdyM37NN6Sk8U9QaI0tEmaTxnGrxkwhPYcZjbX6JrqhhECMebu > A/TIU4QbD7RhIubXPn7wjQWGZccpexoynxbw7rhW52FOsWsjy0trvFtWdoXwJji1 > Ls68cbBqFQN3bAlFp14yJ/cf4pVvxIUzplKQZshAQzpnBelFI4Q9EMRai8nNWPym > pqq9efL//ubLJUq5AgMBAAGjggFBMIIBPTAdBgNVHSUEFjAUBggrBgEFBQcDAQYI > KwYBBQUHAwIwGQYDVR0RBBIwEIIOd3d3Lmdvb2dsZS5jb20waAYIKwYBBQUHAQEE > XDBaMCsGCCsGAQUFBzAChh9odHRwOi8vcGtpLmdvb2dsZS5jb20vR0lBRzIuY3J0 > MCsGCCsGAQUFBzABhh9odHRwOi8vY2xpZW50czEuZ29vZ2xlLmNvbS9vY3NwMB0G > A1UdDgQWBBSA1gUvlcoovYeMXdLiILdTYRyBoDAMBgNVHRMBAf8EAjAAMB8GA1Ud > IwQYMBaAFErdBhYbvPZotXb1gba7Yhq6WoEvMBcGA1UdIAQQMA4wDAYKKwYBBAHW > eQIFATAwBgNVHR8EKTAnMCWgI6Ahhh9odHRwOi8vcGtpLmdvb2dsZS5jb20vR0lB > RzIuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQBjkgHIXprUI8Y1r8XepqstPieJHrew > mfjAcg6S15hQF0pd2p7MrOf26pTbe7z84ZOVjODw6PZmRK6wap+6ow14Q0hZDes8 > ugePDxkCTDjX58Mg00uakMRRmizgr0a37O4f3D2VqOdx4doeRenMdx0RluxnDT4K > gRAXW41WB04Hr8ijwI0q4/0Gw5PzMJgQZ987f+zrUhIW5xDzo1clMSQOYM9mD8DH > 6uVTlWv04KUAy+GkNqweDP5QT/1gdYh9FIFeMfVuaVNJwHibIfqXJX0clGJRW6GG > TAhXz7Hr629+6VEKKgGiVmGV1azv6Eran390kzGhRWdxvrhPVrASw9S2 > -----END CERTIFICATE----- > subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com > issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2 > --- > No client certificate CA names sent > --- > SSL handshake has read 3719 bytes and written 435 bytes > --- > New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256 > Server public key is 2048 bit > Secure Renegotiation IS supported > Compression: NONE > Expansion: NONE > SSL-Session: > Protocol : TLSv1.2 > Cipher : ECDHE-RSA-AES128-GCM-SHA256 > Session-ID: > 9890FB78A01C235769387820574E847C0F76E80DBDC867D6EC5D4422B944E956 > Session-ID-ctx: > Master-Key: > 86B4E5CBDC553D8740C462194E9244870D2468C8A736097CD467EF7461EE0ACF3D96C581EF6F68AF62218B451BBA03D7 > > Key-Arg : None > PSK identity: None > PSK identity hint: None > SRP username: None > TLS session ticket lifetime hint: 100800 (seconds) > TLS session ticket: > 0000 - be 92 f9 6b be 9e 07 5c-dc a4 44 5e a5 06 a8 02 > ...k...\..D^.... > 0010 - 3b b3 56 cf 98 b5 72 4f-82 fe 6a 7a 44 2f b7 24 > ;.V...rO..jzD/.$ > 0020 - 7c 23 57 f9 36 94 d6 83-54 21 dc 10 a2 df ac 43 > |#W.6...T!.....C > 0030 - 1b 8b b0 9e b3 b0 d8 e8-7a 0a d0 b2 55 8e 96 0d > ........z...U... > 0040 - 3c ff d2 af 65 ea c7 69-1b a4 bb 04 f2 73 c2 a8 > <...e..i.....s.. > 0050 - 6c b9 0d 54 cb 50 f2 5e-fc a8 0a 5a ec 4d 10 c6 > l..T.P.^...Z.M.. > 0060 - 34 f1 3b cb 14 96 f8 0f-1d 75 bd c6 56 61 73 64 > 4.;......u..Vasd > 0070 - 98 55 c5 24 18 43 e7 58-cc 2f 50 35 03 14 de c5 > .U.$.C.X./P5.... > 0080 - d7 12 5b 58 6d 6e 6f 7c-61 78 40 1a 02 66 31 94 > ..[Xmno|ax@..f1. > 0090 - 6d a0 fb 7c 36 aa 4c d2-38 9c dd 89 f9 5c 4a 62 > m..|6.L.8....\Jb > 00a0 - f6 f7 e0 24 ...$ > > Start Time: 1415648696 > Timeout : 300 (sec) > Verify return code: 20 (unable to get local issuer certificate) > --- > > ... but when I explicitly specify the path to /etc/ssl/cert.pem, it > works fine ... > > # openssl s_client -CApath /etc/ssl/cert.pem -connect www.google.com:443 > CONNECTED(00000003) > depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority > verify return:1 > depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA > verify return:1 > depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2 > verify return:1 > depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = > www.google.com > verify return:1 > --- > Certificate chain > 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com > i:/C=US/O=Google Inc/CN=Google Internet Authority G2 > 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 > i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA > 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA > i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority > --- > Server certificate > -----BEGIN CERTIFICATE----- > MIIEdjCCA16gAwIBAgIIG6nRQAWDXAAwDQYJKoZIhvcNAQEFBQAwSTELMAkGA1UE > BhMCVVMxEzARBgNVBAoTCkdvb2dsZSBJbmMxJTAjBgNVBAMTHEdvb2dsZSBJbnRl > cm5ldCBBdXRob3JpdHkgRzIwHhcNMTQxMDIyMTI1NzUxWhcNMTUwMTIwMDAwMDAw > WjBoMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwN > TW91bnRhaW4gVmlldzETMBEGA1UECgwKR29vZ2xlIEluYzEXMBUGA1UEAwwOd3d3 > Lmdvb2dsZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBUjaR > OXkELfB431tzr0Y6Y2+YzjKiqrrDeBgFZqh8OCuzqCpoCNQQPWJqN8pPv4q+pZOd > 1smHSo0xhZP1SB9ZdW52gXy9OLc6XHA0OLuagk/QVLFo7TyeXNBEX3RO0qTqpjJ6 > lIE6mMlBvWDzsZxdyM37NN6Sk8U9QaI0tEmaTxnGrxkwhPYcZjbX6JrqhhECMebu > A/TIU4QbD7RhIubXPn7wjQWGZccpexoynxbw7rhW52FOsWsjy0trvFtWdoXwJji1 > Ls68cbBqFQN3bAlFp14yJ/cf4pVvxIUzplKQZshAQzpnBelFI4Q9EMRai8nNWPym > pqq9efL//ubLJUq5AgMBAAGjggFBMIIBPTAdBgNVHSUEFjAUBggrBgEFBQcDAQYI > KwYBBQUHAwIwGQYDVR0RBBIwEIIOd3d3Lmdvb2dsZS5jb20waAYIKwYBBQUHAQEE > XDBaMCsGCCsGAQUFBzAChh9odHRwOi8vcGtpLmdvb2dsZS5jb20vR0lBRzIuY3J0 > MCsGCCsGAQUFBzABhh9odHRwOi8vY2xpZW50czEuZ29vZ2xlLmNvbS9vY3NwMB0G > A1UdDgQWBBSA1gUvlcoovYeMXdLiILdTYRyBoDAMBgNVHRMBAf8EAjAAMB8GA1Ud > IwQYMBaAFErdBhYbvPZotXb1gba7Yhq6WoEvMBcGA1UdIAQQMA4wDAYKKwYBBAHW > eQIFATAwBgNVHR8EKTAnMCWgI6Ahhh9odHRwOi8vcGtpLmdvb2dsZS5jb20vR0lB > RzIuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQBjkgHIXprUI8Y1r8XepqstPieJHrew > mfjAcg6S15hQF0pd2p7MrOf26pTbe7z84ZOVjODw6PZmRK6wap+6ow14Q0hZDes8 > ugePDxkCTDjX58Mg00uakMRRmizgr0a37O4f3D2VqOdx4doeRenMdx0RluxnDT4K > gRAXW41WB04Hr8ijwI0q4/0Gw5PzMJgQZ987f+zrUhIW5xDzo1clMSQOYM9mD8DH > 6uVTlWv04KUAy+GkNqweDP5QT/1gdYh9FIFeMfVuaVNJwHibIfqXJX0clGJRW6GG > TAhXz7Hr629+6VEKKgGiVmGV1azv6Eran390kzGhRWdxvrhPVrASw9S2 > -----END CERTIFICATE----- > subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com > issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2 > --- > No client certificate CA names sent > --- > SSL handshake has read 3719 bytes and written 435 bytes > --- > New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256 > Server public key is 2048 bit > Secure Renegotiation IS supported > Compression: NONE > Expansion: NONE > SSL-Session: > Protocol : TLSv1.2 > Cipher : ECDHE-RSA-AES128-GCM-SHA256 > Session-ID: > 9DD76F7AC8D34085E2B230CA02B955D3A35482C5AD983CD43A0AF65EDDF0905B > Session-ID-ctx: > Master-Key: > FCF5D6AB32816ABD660AB744386531308C3F3203BBB61EB8273A5783DDE92B04C87ADA3DB12C87092BB7BE21CFAD3CCA > > Key-Arg : None > PSK identity: None > PSK identity hint: None > SRP username: None > TLS session ticket lifetime hint: 100800 (seconds) > TLS session ticket: > 0000 - be 92 f9 6b be 9e 07 5c-dc a4 44 5e a5 06 a8 02 > ...k...\..D^.... > 0010 - 63 64 66 84 cd c8 07 dc-69 64 6f ff 69 05 99 a0 > cdf.....ido.i... > 0020 - f4 d7 00 1a 3c 36 41 61-70 5b b4 79 2c 45 c1 3b > ....<6Aap[.y,E.; > 0030 - 6d 5e 13 77 09 3f f8 35-f5 e4 92 ae ce c8 f9 7b > m^.w.?.5.......{ > 0040 - ca 6e 49 94 cd 19 51 89-a3 f4 32 64 a6 a5 27 66 > .nI...Q...2d..'f > 0050 - 96 d1 f0 c6 7b a6 07 20-7b 35 d9 0b f7 f1 8c a5 ....{.. > {5...... > 0060 - e7 58 1d 0c b3 86 12 d6-86 49 4c 7d 31 c5 1a b6 > .X.......IL}1... > 0070 - 3f 7a 8a b5 e5 da 63 a3-f2 2b ee f3 ae 20 3d 1a > ?z....c..+... =. > 0080 - fd d7 d7 af f8 db 11 73-eb 3a 9b cb 41 a9 be 5c > .......s.:..A..\ > 0090 - ec cc 65 1f 3c 13 a7 57-92 a5 cc d9 39 05 41 9d > ..e.<..W....9.A. > 00a0 - 9c 3f 94 d8 .?.. > > Start Time: 1415648909 > Timeout : 300 (sec) > Verify return code: 0 (ok) > --- > > Also, if I run the commands under truss I see that the file > /etc/ssl/cert.pem is not being opened when I do not specify the option > on the command line ... > > # truss openssl s_client -connect www.google.com:443 > ... > open("/dev/crypto",O_RDWR,00) ERR#2 'No such file or > directory' > open("/dev/crypto",O_RDWR,00) ERR#2 'No such file or > directory' > open("/etc/ssl/openssl.cnf",O_RDONLY,0666) = 3 (0x3) > fstat(3,{ mode=-rw-r--r-- ,inode=1123703,size=10929,blksize=32768 }) = 0 > (0x0) > read(3,"# $FreeBSD: release/10.0.0/crypt"...,32768) = 10929 (0x2ab1) > read(3,0x80186e000,32768) = 0 (0x0) > close(3) = 0 (0x0) > sigaction(SIGPIPE,{ SIG_IGN SA_RESTART ss_t },{ SIG_IGN SA_RESTART ss_t > }) = 0 (0x0) > issetugid(0x7fffffffd2c0,0xc8,0x1,0x7fffffffd538,0x0,0x800c82648) = 0 (0x0) > issetugid(0x7fffffffdf5a,0x800c642bf,0x8,0x52,0x0,0x800c82648) = 0 (0x0) > stat("/root/.rnd",0x7fffffffce08) ERR#2 'No such file or > directory' > getpid() = 16324 (0x3fc4) > __sysctl(0x7fffffffd1c8,0x2,0x7fffffffd128,0x7fffffffd1c0,0x0,0x0) = 0 > (0x0) > getpid() = 16324 (0x3fc4) > getpid() = 16324 (0x3fc4) > getpid() = 16324 (0x3fc4) > getpid() = 16324 (0x3fc4) > getpid() = 16324 (0x3fc4) > getpid() = 16324 (0x3fc4) > getpid() = 16324 (0x3fc4) > getpid() = 16324 (0x3fc4) > getpid() = 16324 (0x3fc4) > getpid() = 16324 (0x3fc4) > getpid() = 16324 (0x3fc4) > issetugid(0x0,0x80,0x10,0x2,0x368,0x1) = 0 (0x0) > open("/etc/resolv.conf",O_CLOEXEC,0666) = 3 (0x3) > fstat(3,{ mode=-rw-r--r-- ,inode=1123958,size=35,blksize=32768 }) = 0 (0x0) > read(3,"search cn.bf\nnameserver 10.16.6"...,32768) = 35 (0x23) > read(3,0x8018b3000,32768) = 0 (0x0) > close(3) = 0 (0x0) > issetugid(0x0,0x8018009c0,0x14,0x3,0x7fffffffc2b0,0x801801068) = 0 (0x0) > stat("/etc/nsswitch.conf",{ mode=-rw-r--r-- > ,inode=1123624,size=324,blksize=32768 }) = 0 (0x0) > open("/etc/nsswitch.conf",O_CLOEXEC,0666) = 3 (0x3) > ioctl(3,TIOCGETA,0xffffca80) ERR#25 'Inappropriate > ioctl for device' > fstat(3,{ mode=-rw-r--r-- ,inode=1123624,size=324,blksize=32768 }) = 0 > (0x0) > read(3,"#\n# nsswitch.conf(5) - name ser"...,32768) = 324 (0x144) > read(3,0x8018b3000,32768) = 0 (0x0) > > ... and it is being opened when I do specify the option on the command > line ... > > # truss openssl s_client -CApath /etc/ssl/cert.pem -connect > www.google.com:443 > ... > open("/dev/crypto",O_RDWR,00) ERR#2 'No such file or > directory' > open("/dev/crypto",O_RDWR,00) ERR#2 'No such file or > directory' > open("/etc/ssl/openssl.cnf",O_RDONLY,0666) = 3 (0x3) > fstat(3,{ mode=-rw-r--r-- ,inode=1123703,size=10929,blksize=32768 }) = 0 > (0x0) > read(3,"# $FreeBSD: release/10.0.0/crypt"...,32768) = 10929 (0x2ab1) > read(3,0x80186e000,32768) = 0 (0x0) > close(3) = 0 (0x0) > sigaction(SIGPIPE,{ SIG_IGN SA_RESTART ss_t },{ SIG_IGN SA_RESTART ss_t > }) = 0 (0x0) > issetugid(0x7fffffffd290,0xc8,0x1,0x7fffffffd508,0x0,0x800c82648) = 0 (0x0) > issetugid(0x7fffffffdf5c,0x800c642bf,0x8,0x52,0x0,0x800c82648) = 0 (0x0) > stat("/root/.rnd",0x7fffffffcdd8) ERR#2 'No such file or > directory' > getpid() = 16371 (0x3ff3) > __sysctl(0x7fffffffd198,0x2,0x7fffffffd0f8,0x7fffffffd190,0x0,0x0) = 0 > (0x0) > getpid() = 16371 (0x3ff3) > getpid() = 16371 (0x3ff3) > getpid() = 16371 (0x3ff3) > getpid() = 16371 (0x3ff3) > getpid() = 16371 (0x3ff3) > getpid() = 16371 (0x3ff3) > getpid() = 16371 (0x3ff3) > getpid() = 16371 (0x3ff3) > getpid() = 16371 (0x3ff3) > getpid() = 16371 (0x3ff3) > open("/etc/ssl/cert.pem",O_RDONLY,0666) = 3 (0x3) > fstat(3,{ mode=-rw-r--r-- ,inode=1052618,size=908574,blksize=32768 }) = > 0 (0x0) > read(3,"##\n## ca-root-nss.crt -- Bundl"...,32768) = 32768 (0x8000) > madvise(0x80186a000,0x2000,0x5,0xaaaaaaaaaaaaaaab,0x8018017a0,0x80127cb10) > = 0 (0x0) > madvise(0x8018a1000,0x4000,0x5,0xaaaaaaaaaaaaaaab,0x8018017a0,0x80127cb10) > = 0 (0x0) > madvise(0x8018ac000,0x3000,0x5,0xaaaaaaaaaaaaaaab,0x8018017a0,0x80127cb10) > = 0 (0x0) > madvise(0x8018bc000,0x2000,0x5,0xaaaaaaaaaaaaaaab,0x8018017a0,0x80127cb10) > = 0 (0x0) > madvise(0x8018cd000,0x3000,0x5,0xaaaaaaaaaaaaaaab,0x8018017a0,0x80127cb10) > = 0 (0x0) > madvise(0x8018df000,0x2000,0x5,0xaaaaaaaaaaaaaaab,0x8018017a0,0x80127cb10) > = 0 (0x0) > madvise(0x801900000,0x2000,0x5,0xaaaaaaaaaaaaaaab,0x8018017a0,0x80127cb10) > = 0 (0x0) > madvise(0x801875000,0x1000,0x5,0xaaaaaaaaaaaaaaab,0x801800c48,0x80127cb10) > = 0 (0x0) > madvise(0x801887000,0x2000,0x5,0xaaaaaaaaaaaaaaab,0x801800c48,0x80127cb10) > = 0 (0x0) > read(3," 42:68:ac:a0:bd:4e:5a:da:18:bf:6"...,32768) = 32768 (0x8000) > read(3,":9a:9b:bb:\n "...,32768) = 32768 (0x8000) > read(3," 17:7d:a0:f9:b4:dd:c5:c5:eb"...,32768) = 32768 (0x8000) > madvise(0x8018ba000,0x6000,0x5,0xaaaaaaaaaaaaaaab,0x7fffffffc770,0x80127cb10) > = 0 (0x0) > madvise(0x8018f1000,0xc000,0x5,0xaaaaaaaaaaaaaaab,0x7fffffffc770,0x80127cb10) > = 0 (0x0) > madvise(0x80190e000,0x3000,0x5,0xaaaaaaaaaaaaaaab,0x7fffffffc770,0x80127cb10) > = 0 (0x0) > madvise(0x801921000,0x5000,0x5,0xaaaaaaaaaaaaaaab,0x7fffffffc770,0x80127cb10) > = 0 (0x0) > madvise(0x801936000,0x2000,0x5,0xaaaaaaaaaaaaaaab,0x7fffffffc770,0x80127cb10) > = 0 (0x0) > read(3,"c Constraints: critical\n "...,32768) = 32768 (0x8000) > read(3,"DYu5Def131TN3ubY1gkIl2PlwS6w\nt0"...,32768) = 32768 (0x8000) > read(3,"\nxvbxrN8y8NmBGuScvfaAFPDRLLmF9d"...,32768) = 32768 (0x8000) > read(3,"f:1f:31:9c:\n "...,32768) = 32768 (0x8000) > read(3,"igiCert Inc, OU=www.digicert.com"...,32768) = 32768 (0x8000) > read(3,"93:36:85:23:88:8a:3c:03:68:d3:c9"...,32768) = 32768 (0x8000) > read(3,"orzAzu8T2bgmmkTPiab+ci2hC6X5L8GC"...,32768) = 32768 (0x8000) > read(3,"2zsmWLIodz2uFHdh\n1voqZiegDfqnc1"...,32768) = 32768 (0x8000) > read(3,"hUNfBvitbtaSeodlyWL0AG0y/YckUHUW"...,32768) = 32768 (0x8000) > read(3," CA:TRUE\n Signatu"...,32768) = 32768 (0x8000) > read(3,":22:d7:8b:0b:\n "...,32768) = 32768 (0x8000) > read(3," 6b:53:7f:db:df:df:f3:71:3d:26:"...,32768) = 32768 (0x8000) > read(3,"f:f2:89:4d:d4:ec:c5:e2:e6:7a:d0:"...,32768) = 32768 (0x8000) > read(3,":57:d2:b0:0a:\n "...,32768) = 32768 (0x8000) > read(3," X509v3 CRL Distribution Po"...,32768) = 32768 (0x8000) > read(3,"60:45:f2:31:eb:a9:31:\n "...,32768) = 32768 (0x8000) > read(3,"4QgEBBAQDAgAHMDgGCWCGSAGG+EIBDQQ"...,32768) = 32768 (0x8000) > read(3,"9:28:a7:\n 2e"...,32768) = 32768 (0x8000) > read(3,"A1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/"...,32768) = 32768 (0x8000) > read(3,"4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3G"...,32768) = 32768 (0x8000) > read(3,"QUFADCBvjE/MD0GA1UEAww2VMOc\nUkt"...,32768) = 32768 (0x8000) > read(3,"dq6hw2v+vPhwvCkxWeM\n1tZUOt4KpLo"...,32768) = 32768 (0x8000) > read(3," Exponent: 65537 (0x10001"...,32768) = 32768 (0x8000) > read(3,":35:88:67:74:57:e3:df:8c:b8:a7:7"...,32768) = 23838 (0x5d1e) > read(3,0x801899000,32768) = 0 (0x0) > close(3) = 0 (0x0) > getpid() = 16371 (0x3ff3) > issetugid(0x0,0x80,0x10,0x2,0x368,0x1) = 0 (0x0) > open("/etc/resolv.conf",O_CLOEXEC,0666) = 3 (0x3) > fstat(3,{ mode=-rw-r--r-- ,inode=1123958,size=35,blksize=32768 }) = 0 (0x0) > read(3,"search cn.bf\nnameserver 10.16.6"...,32768) = 35 (0x23) > read(3,0x801931000,32768) = 0 (0x0) > close(3) = 0 (0x0) > issetugid(0x0,0x801801cf8,0x33,0x3,0x7fffffffc280,0x801801c38) = 0 (0x0) > stat("/etc/nsswitch.conf",{ mode=-rw-r--r-- > ,inode=1123624,size=324,blksize=32768 }) = 0 (0x0) > open("/etc/nsswitch.conf",O_CLOEXEC,0666) = 3 (0x3) > ioctl(3,TIOCGETA,0xffffca50) ERR#25 'Inappropriate > ioctl for device' > fstat(3,{ mode=-rw-r--r-- ,inode=1123624,size=324,blksize=32768 }) = 0 > (0x0) > read(3,"#\n# nsswitch.conf(5) - name ser"...,32768) = 324 (0x144) > read(3,0x801931000,32768) = 0 (0x0) > > This is the only copy of openssl on my system ... > > # whereis openssl > openssl: /usr/bin/openssl /usr/share/openssl/man/man1/openssl.1.gz > > Did something change with the FreeBSD 10 configuration of OpenSSL? At > first I thought it was a problem with this particular host, but I've > been able to reproduce the problem on 3 different 10.x hosts I've tested > so far. I don't see how an unmodified program will pickup the default > system CA file unless that problem has an option to explicitly hand in > the path. Was this intended? > > Thanks in advance, > > -Matthew > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Nov 11 02:53:04 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CBD94AF6 for ; Tue, 11 Nov 2014 02:53:04 +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 B372F1E9 for ; Tue, 11 Nov 2014 02:53:04 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sAB2r4n9073963 for ; Tue, 11 Nov 2014 02:53:04 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 165463] FreeBSD doesn't work with NIC based on RLT8111E Date: Tue, 11 Nov 2014 02:53:04 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: component assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 02:53:04 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=165463 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Component|wireless |kern Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org --- Comment #3 from Mark Linimon --- Fix Component and assign. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Tue Nov 11 02:53:40 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB1DABD3 for ; Tue, 11 Nov 2014 02:53:40 +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 915EF1F9 for ; Tue, 11 Nov 2014 02:53:40 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sAB2reLa074852 for ; Tue, 11 Nov 2014 02:53:40 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 154851] [new driver] [request]: Port brcm80211 driver from Linux to FreeBSD Date: Tue, 11 Nov 2014 02:53:40 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 02:53:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=154851 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-net@FreeBSD.org |freebsd-wireless@FreeBSD.or | |g --- Comment #3 from Mark Linimon --- reassign. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Tue Nov 11 10:32:10 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EC05FF8D for ; Tue, 11 Nov 2014 10:32:10 +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 3DB2C63F for ; Tue, 11 Nov 2014 10:32:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id sABAVcFZ078587; Tue, 11 Nov 2014 21:31:38 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 11 Nov 2014 21:31:38 +1100 (EST) From: Ian Smith To: freebsd-net@freebsd.org Subject: Whither ep(4) on 9.3-RELEASE? Message-ID: <20141111203429.I31139@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Gary Aitken 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, 11 Nov 2014 10:32:11 -0000 In a conversation on questions@ re natd(8), Gary said he was about to upgrade to 9.3 from some (embarrassingly :) old version, and I said: >> Strangely, there's no man page for ep nor if_ep on 8.x or 9.x? To which Gary replied: > ugh. That will be interesting when my upgrade starts in a few days. > Dang. > man ep > ep -- Ethernet driver for 3Com Etherlink III (3c5x9) interfaces Firstly, I was wrong about 8.x, maybe I'd been looking for 'man if_ep'. On 8.2-R (i386) there is an ep(4) and: smithi on t23% ll /boot/kernel/*ep.ko* | grep -v wlan -r-xr-xr-x 1 root wheel 28687 Jul 8 2011 /boot/kernel/if_ep.ko -r-xr-xr-x 1 root wheel 104779 Jul 8 2011 /boot/kernel/if_ep.ko.symbols But on 9.3-R (well, 9.3-PRERELEASE of June 25th, amd64): smithi@x200:/sys/dev/acpica % ll /boot/kernel/*ep* -r-xr-xr-x 1 root wheel 24488 Jun 25 15:45 /boot/kernel/if_epair.ko* -r-xr-xr-x 1 root wheel 73912 Jun 25 15:45 /boot/kernel/if_epair.ko.symbols* -r-xr-xr-x 1 root wheel 16584 Jun 25 15:45 /boot/kernel/uep.ko* -r-xr-xr-x 1 root wheel 51056 Jun 25 15:45 /boot/kernel/uep.ko.symbols* -r-xr-xr-x 1 root wheel 24472 Jun 25 15:46 /boot/kernel/wlan_wep.ko* -r-xr-xr-x 1 root wheel 113632 Jun 25 15:46 /boot/kernel/wlan_wep.ko.symbols* Moreover, a) http://www.freebsd.org/releases/9.3R/hardware.html does list ep(4) for the 3C5x9, as does 8.2R/hardware.html, for [i386,pc98,amd64] b) But in these and any other versions back to 7.4-stable, there is no ep(All sections), nor if_ep, at http://www.freebsd.org/cgi/man.cgi Ah, hang on .. finally found it, under 9.3-R and older releases, but only if not leaving 'Default' as architecture, but only specifically when choosing 'i386' (which seems weird) though the hardware list (and ep(4) under i386) for 9.3R says: [i386,pc98,amd64] The ep(4) driver supports Ethernet adapters based on the 3Com 3C5x9 Etherlink III Parallel Tasking chipset, including: Further, hardware.html for 10.0R, 10.0-stable and even 10.1-stable all show ep(4) for i386 only .. but NOT for 10.1R, even when choosing i386? So maybe this is only a doc error? My 9.3 above is amd64, so apparently ep(4) was not (ever?) supported under amd64, and pc98 is gone now, eh? So can anyone confirm that ep(4) is present on 9.3-R, even if only i386? cheers, Ian From owner-freebsd-net@FreeBSD.ORG Tue Nov 11 17:28:26 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C37B614E for ; Tue, 11 Nov 2014 17:28:26 +0000 (UTC) Received: from mario.brtsvcs.net (mario.brtsvcs.net [199.48.128.182]) (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 9AF24C96 for ; Tue, 11 Nov 2014 17:28:26 +0000 (UTC) Received: from chombo.houseloki.net (unknown [IPv6:2601:7:2580:674:21c:c0ff:fe7f:96ee]) by mario.brtsvcs.net (Postfix) with ESMTPSA id 3ED542C1614; Tue, 11 Nov 2014 17:28:24 +0000 (UTC) Received: from [IPv6:2601:7:2580:674:baca:3aff:fe83:bd29] (ivy.libssl.so [IPv6:2601:7:2580:674:baca:3aff:fe83:bd29]) by chombo.houseloki.net (Postfix) with ESMTPSA id 03D8317F; Tue, 11 Nov 2014 09:28:21 -0800 (PST) Message-ID: <54624735.80206@bluerosetech.com> Date: Tue, 11 Nov 2014 09:28:21 -0800 From: Darren Pilgrim Reply-To: freebsd-net@freebsd.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ian Smith , freebsd-net@freebsd.org Subject: Re: Whither ep(4) on 9.3-RELEASE? References: <20141111203429.I31139@sola.nimnet.asn.au> In-Reply-To: <20141111203429.I31139@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1; 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: Tue, 11 Nov 2014 17:28:26 -0000 On 11/11/2014 2:31 AM, Ian Smith wrote: > In a conversation on questions@ re natd(8), Gary said he was about to > upgrade to 9.3 from some (embarrassingly :) old version, and I said: > > >> Strangely, there's no man page for ep nor if_ep on 8.x or 9.x? > > To which Gary replied: > > > ugh. That will be interesting when my upgrade starts in a few days. > > Dang. > > man ep > > ep -- Ethernet driver for 3Com Etherlink III (3c5x9) interfaces I'm amazed people still use tech this old. > So can anyone confirm that ep(4) is present on 9.3-R, even if only i386? It's available in i386, all releases (even head, presently). It's not in amd64 due to no ISA support. From owner-freebsd-net@FreeBSD.ORG Tue Nov 11 21:15:39 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46912544 for ; Tue, 11 Nov 2014 21:15:39 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 22EBDDB6 for ; Tue, 11 Nov 2014 21:15:38 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sABLFUkb018739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Nov 2014 13:15:31 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sABLFUtw018738; Tue, 11 Nov 2014 13:15:30 -0800 (PST) (envelope-from jmg) Date: Tue, 11 Nov 2014 13:15:30 -0800 From: John-Mark Gurney To: Ian Smith Subject: Re: Whither ep(4) on 9.3-RELEASE? Message-ID: <20141111211530.GQ24601@funkthat.com> Mail-Followup-To: Ian Smith , freebsd-net@freebsd.org, Gary Aitken References: <20141111203429.I31139@sola.nimnet.asn.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141111203429.I31139@sola.nimnet.asn.au> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 11 Nov 2014 13:15:31 -0800 (PST) Cc: Gary Aitken , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 21:15:39 -0000 Ian Smith wrote this message on Tue, Nov 11, 2014 at 21:31 +1100: > In a conversation on questions@ re natd(8), Gary said he was about to > upgrade to 9.3 from some (embarrassingly :) old version, and I said: > > >> Strangely, there's no man page for ep nor if_ep on 8.x or 9.x? > > To which Gary replied: > > > ugh. That will be interesting when my upgrade starts in a few days. > > Dang. > > man ep > > ep -- Ethernet driver for 3Com Etherlink III (3c5x9) interfaces > > Firstly, I was wrong about 8.x, maybe I'd been looking for 'man if_ep'. > On 8.2-R (i386) there is an ep(4) and: > > smithi on t23% ll /boot/kernel/*ep.ko* | grep -v wlan > -r-xr-xr-x 1 root wheel 28687 Jul 8 2011 /boot/kernel/if_ep.ko > -r-xr-xr-x 1 root wheel 104779 Jul 8 2011 /boot/kernel/if_ep.ko.symbols > > But on 9.3-R (well, 9.3-PRERELEASE of June 25th, amd64): > > smithi@x200:/sys/dev/acpica % ll /boot/kernel/*ep* > -r-xr-xr-x 1 root wheel 24488 Jun 25 15:45 /boot/kernel/if_epair.ko* > -r-xr-xr-x 1 root wheel 73912 Jun 25 15:45 /boot/kernel/if_epair.ko.symbols* > -r-xr-xr-x 1 root wheel 16584 Jun 25 15:45 /boot/kernel/uep.ko* > -r-xr-xr-x 1 root wheel 51056 Jun 25 15:45 /boot/kernel/uep.ko.symbols* > -r-xr-xr-x 1 root wheel 24472 Jun 25 15:46 /boot/kernel/wlan_wep.ko* > -r-xr-xr-x 1 root wheel 113632 Jun 25 15:46 /boot/kernel/wlan_wep.ko.symbols* > > Moreover, > > a) http://www.freebsd.org/releases/9.3R/hardware.html does list ep(4) > for the 3C5x9, as does 8.2R/hardware.html, for [i386,pc98,amd64] > > b) But in these and any other versions back to 7.4-stable, there is no > ep(All sections), nor if_ep, at http://www.freebsd.org/cgi/man.cgi > > Ah, hang on .. finally found it, under 9.3-R and older releases, but > only if not leaving 'Default' as architecture, but only specifically > when choosing 'i386' (which seems weird) though the hardware list (and > ep(4) under i386) for 9.3R says: > > [i386,pc98,amd64] The ep(4) driver supports Ethernet adapters based on > the 3Com 3C5x9 Etherlink III Parallel Tasking chipset, including: > > Further, hardware.html for 10.0R, 10.0-stable and even 10.1-stable all > show ep(4) for i386 only .. but NOT for 10.1R, even when choosing i386? > > So maybe this is only a doc error? My 9.3 above is amd64, so apparently > ep(4) was not (ever?) supported under amd64, and pc98 is gone now, eh? > > So can anyone confirm that ep(4) is present on 9.3-R, even if only i386? Yeh, it looks like ep is in GENERIC on i386.. We also compile ep on amd64 too, though not sure anyone would ever want to use ep on there... On HEAD we only compile the ep modules on i386... so not sure why you weren't able to find it... I'd just try booting a memstick or other image to confirm that there is support... -- 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 Tue Nov 11 21:20:29 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 337547E1 for ; Tue, 11 Nov 2014 21:20:29 +0000 (UTC) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (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 B7BC5E73 for ; Tue, 11 Nov 2014 21:20:27 +0000 (UTC) Received: from mart.js.berklix.net (p5DCBF7A6.dip0.t-ipconnect.de [93.203.247.166]) (authenticated bits=128) by land.berklix.org (8.14.5/8.14.5) with ESMTP id sABLGUv3076254; Tue, 11 Nov 2014 21:16:34 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id sABLKBJu025463; Tue, 11 Nov 2014 22:20:11 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id sABLJmn7070875; Tue, 11 Nov 2014 22:20:05 +0100 (CET) (envelope-from jhs@berklix.com) Message-Id: <201411112120.sABLJmn7070875@fire.js.berklix.net> To: freebsd-net@freebsd.org Subject: Re: Whither ep(4) on 9.3-RELEASE? From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultants, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Tue, 11 Nov 2014 09:28:21 -0800." <54624735.80206@bluerosetech.com> Date: Tue, 11 Nov 2014 22:19:48 +0100 Cc: Ian Smith 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, 11 Nov 2014 21:20:29 -0000 > I'm amazed people still use tech this old. Some think Green :-) Junking old PCs can feel sinful (except when power bill dictates or more CPU needed). I use old x86 + ep0, eg libretto eg, for mini X monitors for hardware eg PBX, UPS etc, though none run new releases (unlike my main AMD64s). So my ep0 host count is now down to ~ 3. > It's available in i386, all releases (even head, presently). It's not > in amd64 due to no ISA support. Good to know, thanks. Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Indent previous with "> ". Interleave reply paragraphs like a play script. Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. From owner-freebsd-net@FreeBSD.ORG Wed Nov 12 18:11:23 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 301262C5 for ; Wed, 12 Nov 2014 18:11:23 +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 F2CD335F for ; Wed, 12 Nov 2014 18:11:22 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sACIBMlR022335 for ; Wed, 12 Nov 2014 18:11:22 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 165463] FreeBSD doesn't work with NIC based on RLT8111E Date: Wed, 12 Nov 2014 18:11:23 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: john@jnielsen.net X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 18:11:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=165463 john@jnielsen.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |john@jnielsen.net --- Comment #4 from john@jnielsen.net --- Can the reporter provide any additional details? The version of FreeBSD tried and the relevant output from "dmesg" and "pciconf -lv" would be a good start. I have a FreeBSD box with an onboard RTL8111E and it works fine with the re(4) driver: re0: port 0xe000-0xe0ff mem 0xfea00000-0xfea00fff,0xfc800000-0xfc803fff irq 32 at device 0.0 on pci1 re0: Using 1 MSI-X message re0: ASPM disabled re0: Chip rev. 0x4c000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Using defaults for TSO: 65518/35/2048 re0: Ethernet address: 74:27:ea:d5:89:83 re0@pci0:1:0:0: class=0x020000 card=0x81161019 chip=0x816810ec rev=0x0c hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class = network subclass = ethernet The board is this one: http://www.ecs.com.tw/ECSWebSite/Product/Product_Detail.aspx?DetailID=1499&CategoryID=1&DetailName=Feature&MenuID=106&LanID=0 It is worth noting that while the NIC was identified and the driver attached in FreeBSD 10.0, It was not fully functional until 10.0-STABLE (and upcoming 10.1). -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Nov 13 12:15:39 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 689FE806 for ; Thu, 13 Nov 2014 12:15:39 +0000 (UTC) Received: from forward7l.mail.yandex.net (forward7l.mail.yandex.net [IPv6:2a02:6b8:0:1819::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 22F55164 for ; Thu, 13 Nov 2014 12:15:38 +0000 (UTC) Received: from smtp17.mail.yandex.net (smtp17.mail.yandex.net [95.108.252.17]) by forward7l.mail.yandex.net (Yandex) with ESMTP id 70F33BC1102; Thu, 13 Nov 2014 15:15:26 +0300 (MSK) Received: from smtp17.mail.yandex.net (localhost [127.0.0.1]) by smtp17.mail.yandex.net (Yandex) with ESMTP id 0199219016E8; Thu, 13 Nov 2014 15:15:25 +0300 (MSK) Received: from 84.201.167.97-vpn.dhcp.yndx.net (84.201.167.97-vpn.dhcp.yndx.net [84.201.167.97]) by smtp17.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 1oAV61tww6-FPd8bEW6; Thu, 13 Nov 2014 15:15:25 +0300 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 5e66467a-04dd-4598-84b9-4c5d9a2c884f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1415880925; bh=W3eXx3MUwSLgOUlbA0A0mBvYlr8mjdlTD4lomiZ/fas=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=d2Y9txT9EI2Hq9Xn6pCaowHDKYhfkqqDhUTBKub67dIQNaQVz08mXcRSc1qKuKXrH D38XT65PLjzXUakM3BdN6r13sF7UhiX6JerrQ70G8YFPthWsiUBNJzadGdACekZ1pk CPbt71pIYqBy0x29SnCDS9NVKWX1SB7HVg5sSK5k= Authentication-Results: smtp17.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <5464A0CF.4000804@yandex.ru> Date: Thu, 13 Nov 2014 15:15:11 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Chris Ernst , freebsd-net@freebsd.org Subject: Re: kldload ip_mroute.ko vs. kernel options MROUTING References: <54605338.3040103@gmail.com> In-Reply-To: <54605338.3040103@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 12:15:39 -0000 On 10.11.2014 08:55, Chris Ernst wrote: > Dear Mailinglist > > I just found out that there are two possibilities to get multicast > working in FreeBSD > > There is: > - kldload ip_mroute.ko or > - to compile the kernel with: options MROUTING > > Is there a difference between these two approaches? > I notice that, with a custom kernel, patching is much more complex and > time consuming. As binary updates are not possible any more. You don't need rebuild the kernel. Just load the module. -- WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Thu Nov 13 16:20:51 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25D0ECDE for ; Thu, 13 Nov 2014 16:20:51 +0000 (UTC) Received: from mail.ismobile.com (mail.ismobile.com [IPv6:2a00:f680:101:11::4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.ismobile.com", Issuer "GlobalSign Domain Validation CA - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 72FF9137 for ; Thu, 13 Nov 2014 16:20:50 +0000 (UTC) Received: from mail.ismobile.com (localhost [127.0.0.1]) by dkim.mail.ismobile.com (Postfix) with ESMTP id 8B0042B54A3 for ; Thu, 13 Nov 2014 16:20:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=ismobile.com; h=date:from :to:subject:message-id:mime-version:content-type; s=selector1; bh=CidSAR4tHMvWiJ/sbHWNdMqNJc8=; b=PRNezs3XS81Mm/5ZPPhY7SCzYG81 RnEFKZrUa5eCGnQQY5amCpUKcNkDSskgAyHFRoVMHqcZ9S9rztcC5Jwb96SDhvxQ zcqc00NycvoiXldPef2tbNaw3ZYttpydg60XZEfi3x3PKlkwZseLN1dA4oIV3bnl 6LU2LIxKczAecyM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=ismobile.com; h=date:from:to :subject:message-id:mime-version:content-type; q=dns; s= selector1; b=gY/KOZXExGr7Qzdnx5fCMdzAxpY1gZwq3qp1hAIt9/3oPK05e8h usQciYtb/zk7yHnFATjjngk+5S2YGFV429RUCDjGR1DTCb0kew8wGEBWXXtKJ7Rw PwLASenEt9xx+ErafCSvbL8vy+aMnrL2lnpgu0tEp6hf5CMaUuFbm5Ns= Received: from [172.16.2.31] (glz-macbookpro.hq.ismobile.com [172.16.2.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ismobile.com (Postfix) with ESMTPSA id 825C52B54A0 for ; Thu, 13 Nov 2014 16:20:47 +0000 (UTC) Date: Thu, 13 Nov 2014 17:20:47 +0100 From: =?UTF-8?Q?G=C3=B6ran_L=C3=B6wkrantz?= To: freebsd-net@freebsd.org Subject: Unexpected traffic flow Message-ID: <15969A88725905DA6D022093@[172.16.2.31]> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========D6490C6FE1812265AB51==========" 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, 13 Nov 2014 16:20:51 -0000 --==========D6490C6FE1812265AB51========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=10146 One of our gateways is behaving oddly after updating to 10.1-PRERELEASE r274192 and I just can not understand what is happening. Internet | | | +------+-------+ | FW | +------+-------+ | DMZ | +------+-------+ | GW | OpenVPN +--+--+--+--+--+ | | | | 2 3 4 9 Net 2 - em2 - 192.168.2.0/24 - servers, server-net switches. Net 3 - em1 - 192.168.3.0/24 - workstations, ws-net switches Net 4 - em0 - 192.168.4.0/24 - WiFi access points + VLAN switch Net 9 - em4 - 192.168.9.0/24 - monitor net w. a few switches. DMZ - em5 - XXX.XXX.XXX.128/27 - DMZ and transfer net to outside. At the bottom of the mail I have included netstat -rn and ifconfig -au output. After the upgrade a few hosts got intermittent internet connection and a few hosts lost all connectivity. Specifically, I have one host on the 2-net, 192.168.2.22, that refuses to connect to internet or lookup names via the gw, which is also the local DNS. 1: tcpdump on em0, em1, em2, em4 and em5 while sending ping to 192.168.2.1 i.e. from the problem host to the gw. - incoming traffic on em2: 16:54:36.220053 IP 192.168.2.22 > 192.168.2.1: ICMP echo request, id 9814, seq 1, length 64 16:54:37.219705 IP 192.168.2.22 > 192.168.2.1: ICMP echo request, id 9814, seq 2, length 64 16:54:38.219732 IP 192.168.2.22 > 192.168.2.1: ICMP echo request, id 9814, seq 3, length 64 16:54:39.219759 IP 192.168.2.22 > 192.168.2.1: ICMP echo request, id 9814, seq 4, length 64 16:54:40.219783 IP 192.168.2.22 > 192.168.2.1: ICMP echo request, id 9814, seq 5, length 64 16:54:41.230678 ARP, Request who-has 192.168.2.1 tell 192.168.2.22, length 46 16:54:41.230682 ARP, Reply 192.168.2.1 is-at 00:1b:21:24:62:4a, length 28 - outgoing traffic on em5: 16:54:36.220066 IP 192.168.2.1 > 192.168.2.22: ICMP echo reply, id 9814, seq 1, length 64 ...... + 62 repeates ......... 16:54:36.224436 IP 192.168.2.1 > 192.168.2.22: ICMP echo reply, id 9814, seq 1, length 64 16:54:37.219712 IP 192.168.2.1 > 192.168.2.22: ICMP echo reply, id 9814, seq 2, length 64 ...... + 62 repeates ......... 16:54:37.223711 IP 192.168.2.1 > 192.168.2.22: ICMP echo reply, id 9814, seq 2, length 64 16:54:38.219738 IP 192.168.2.1 > 192.168.2.22: ICMP echo reply, id 9814, seq 3, length 64 ...... + 62 repeates ......... 16:54:38.224984 IP 192.168.2.1 > 192.168.2.22: ICMP echo reply, id 9814, seq 3, length 64 16:54:39.219766 IP 192.168.2.1 > 192.168.2.22: ICMP echo reply, id 9814, seq 4, length 64 ...... + 62 repeates ......... 16:54:39.225757 IP 192.168.2.1 > 192.168.2.22: ICMP echo reply, id 9814, seq 4, length 64 16:54:40.219789 IP 192.168.2.1 > 192.168.2.22: ICMP echo reply, id 9814, seq 5, length 64 ...... + 62 repeates ......... 16:54:40.224282 IP 192.168.2.1 > 192.168.2.22: ICMP echo reply, id 9814, seq 5, length 64 Checking on em2, I see root@gw01:/usr/local/etc # arp 192.168.2.22 dbserver-2.lulea.arcticgroup.se (192.168.2.22) at 00:19:99:21:87:62 on em2 expires in 1116 seconds [ethernet] So we have route and arp at em2 but the ping replies are sent out via the port connecting to the default gateway. If I try to ping 192.168.2.22 from the GW, I get this response and only traffic going out via em5. root@gw01:/usr/local/etc # ping 192.168.2.22 PING 192.168.2.22 (192.168.2.22): 56 data bytes 36 bytes from dmz.xxx.com (XXX.XXX.XXX.129): Redirect Host(New addr: XXX.XXX.XXX.158) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 0054 39e4 0 0000 40 01 0c2f XXX.XXX.XXX.158 192.168.2.22 For some hosts, 192.168.6 for example, this happens intermittently like 3-10 pings go correct, returning on em2, then 1, 2 or more are sent via em5. None of the hosts are using RIP or other active routing, only static routes. GW host is built with nanobsd and attached kernel configuration. I have never seen anything like this. Can anyone help? Any more info needed? Routing tables (only IPv4 as that's what's on the inside). Internet: Destination Gateway Flags Netif Expire default XXX.XXX.XXX.129 UGS em5 FW DMZ IF 10.191.251.0/24 10.191.251.2 UGS tun0 OpenVPN net 1 10.191.251.1 link#14 UHS lo0 OpenVPN local endpoint 1 10.191.251.2 link#14 UH tun0 OpenVPN remote endpoint 1 10.191.252.0/24 10.191.252.2 UGS tun1 OpenVPN net 2 10.191.252.1 link#15 UHS lo0 OpenVPN local endpoint 2 10.191.252.2 link#15 UH tun1 OpenVPN remote endpoint 2 10.191.253.0/24 10.191.253.2 UGS tun2 OpenVPN net 3 10.191.253.1 link#16 UHS lo0 OpenVPN local endpoint 3 10.191.253.2 link#16 UH tun2 OpenVPN remote endpoint 3 127.0.0.1 link#11 UH lo0 localhost XXX.XXX.XXX.128/27 link#6 U em5 DMZ network XXX.XXX.XXX.157 link#13 UHS lo0 XXX.XXX.XXX.157/32 link#13 U tap0 OpenVPN Server XXX.XXX.XXX.158 link#6 UHS lo0 GW extern IP, em5 192.168.2.0/24 link#3 U em2 server net 192.168.2.1 link#3 UHS lo0 GW em2 192.168.3.0/24 link#2 U em1 ws net 192.168.3.1 link#2 UHS lo0 GW em1 192.168.4.0/24 link#1 U em0 wifi net 192.168.4.254 link#1 UHS lo0 server em0 192.168.9.0/24 link#5 U em4 monitor net 192.168.9.254 link#5 UHS lo0 server em4 em0: flags=8843 metric 0 mtu 1500 options=209b ether 00:1b:21:24:62:48 inet 192.168.4.254 netmask 0xffffff00 broadcast 192.168.4.255 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active em1: flags=8843 metric 0 mtu 1500 options=9b ether 00:1b:21:24:62:49 inet 192.168.3.1 netmask 0xffffff00 broadcast 192.168.3.255 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active em2: flags=8943 metric 0 mtu 1500 options=9b ether 00:1b:21:24:62:4a inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active em4: flags=8843 metric 0 mtu 1500 options=4219b ether 00:30:48:b9:99:c8 inet 192.168.9.254 netmask 0xffffff00 broadcast 192.168.9.255 nd6 options=29 media: Ethernet autoselect (100baseTX ) status: active em5: flags=8943 metric 0 mtu 1500 options=42098 ether 00:30:48:b9:99:c9 inet XXX.XXX.XXX.158 netmask 0xffffffe0 broadcast XXX.XXX.XXX.159 inet6 fe80::230:48ff:feb9:99c9%em5 prefixlen 64 scopeid 0x6 inet6 xxxx:xxxx:101:1::fffe prefixlen 64 nd6 options=21 media: Ethernet autoselect (1000baseT ) status: active lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0xb inet 127.0.0.1 netmask 0xff000000 nd6 options=21 bridge0: flags=8843 metric 0 mtu 1500 ether 02:33:00:4d:00:00 nd6 options=9 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: em5 flags=143 ifmaxaddr 0 port 6 priority 128 path cost 2000000 member: tap0 flags=143 ifmaxaddr 0 port 13 priority 128 path cost 2000000 tap0: flags=8943 metric 0 mtu 1500 options=80000 ether 00:bd:50:63:00:00 inet XXX.XXX.XXX.157 netmask 0xffffffff broadcast XXX.XXX.XXX.157 inet6 fe80::2bd:50ff:fe63:0%tap0 prefixlen 64 scopeid 0xd inet6 xxxx:xxxx:101:1::fffd prefixlen 64 nd6 options=21 media: Ethernet autoselect status: no carrier tun0: flags=8051 metric 0 mtu 1500 options=80000 inet6 fe80::21b:21ff:fe24:6248%tun0 prefixlen 64 scopeid 0xe inet 10.191.251.1 --> 10.191.251.2 netmask 0xffffffff nd6 options=21 Opened by PID 1565 tun1: flags=8051 metric 0 mtu 1500 options=80000 inet6 fe80::21b:21ff:fe24:6248%tun1 prefixlen 64 scopeid 0xf inet 10.191.252.1 --> 10.191.252.2 netmask 0xffffffff nd6 options=21 Opened by PID 1580 tun2: flags=8051 metric 0 mtu 1500 options=80000 inet6 fe80::21b:21ff:fe24:6248%tun2 prefixlen 64 scopeid 0x10 inet 10.191.253.1 --> 10.191.253.2 netmask 0xffffffff nd6 options=21 Opened by PID 1595 root@gw01:/usr/local/etc # route get 192.168.2.22 route to: dbserver-2.lulea.arcticgroup.se destination: 192.168.2.0 mask: 255.255.255.0 fib: 0 interface: em2 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1500 1 0 --==========D6490C6FE1812265AB51========== Content-Type: application/octet-stream; name=ROUTER Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=ROUTER; size=2438 IwojIFJPVVRFUiAtLSBCYXNpYyByb3V0ZXIgc2V0dXAKIwoKaW5jbHVkZSBHRU5FUklDCgppZGVu dAkJUk9VVEVSCgojIFJlbW92ZSBrZXJuZWwgZGVidWdnZXIKbm9vcHRpb25zICAgICAgIEtEQgpu b29wdGlvbnMgICAgICAgS0RCX1RSQUNFCgojIEFkZCBudWxsZnMgdG8gYWxsb3cgbWFwcGluZyBv ZiBkYXRhCm9wdGlvbnMgCU5VTExGUwoKIyBSb3V0ZXIgY29uZmlnCm9wdGlvbnMgICBERVZJQ0Vf UE9MTElORwpvcHRpb25zICAgRkxPV1RBQkxFICAgICAgICAgICAgICAgIyBwZXItY3B1IHJvdXRp bmcgY2FjaGUKCiMgSVBTRUMgZXRjCm9wdGlvbnMgSVBTRUMKb3B0aW9ucyAgIElQU0VDX05BVF9U CmRldmljZSBjcnlwdG8KZGV2aWNlIGNyeXB0b2RldgpkZXZpY2UgaGlmbgoKIyBmaXJld2FsbCBh bmQgc3R1ZmYKZGV2aWNlIHBmCmRldmljZSBwZmxvZwpkZXZpY2UgcGZzeW5jCgpvcHRpb25zIEFM VFEKCm9wdGlvbnMgQUxUUV9DQlEKb3B0aW9ucyBBTFRRX1JFRApvcHRpb25zIEFMVFFfUklPCm9w dGlvbnMgQUxUUV9IRlNDCm9wdGlvbnMgQUxUUV9DRE5SCm9wdGlvbnMgQUxUUV9QUklRCm9wdGlv bnMgQUxUUV9OT1BDQwoKIyBSZW1vdmUgdW51c2VkIHN0dWZmCiMgU0NTSSBDb250cm9sbGVycwpu b2RldmljZSBhaGMgICAgICAgICAgICAgIyBBSEEyOTQwIGFuZCBvbmJvYXJkIEFJQzd4eHggZGV2 aWNlcwpub2RldmljZSBhaGQgICAgICAgICAgICAgIyBBSEEzOTMyMC8yOTMyMCBhbmQgb25ib2Fy ZCBBSUM3OXh4IGRldmljZXMKbm9kZXZpY2UgZXNwICAgICAgICAgICAgICMgQU1EIEFtNTNDOTc0 IChUZWtyYW0gREMtMzkwKFQpKQpub2RldmljZSBocHRpb3AgICAgICAgICAgIyBIaWdocG9pbnQg Um9ja2V0UmFpZCAzeHh4IHNlcmllcwpub2RldmljZSBpc3AgICAgICAgICAgICAgIyBRbG9naWMg ZmFtaWx5Cm5vZGV2aWNlIG1wdCAgICAgICAgICAgICAjIExTSS1Mb2dpYyBNUFQtRnVzaW9uCm5v ZGV2aWNlIG1wcyAgICAgICAgICAgICAjIExTSS1Mb2dpYyBNUFQtRnVzaW9uIDIKbm9kZXZpY2Ug c3ltICAgICAgICAgICAgICMgTkNSL1N5bWJpb3MgTG9naWMgKG5ld2VyIGNoaXBzZXRzICsgdGhv c2Ugb2YgYG5jcicpCm5vZGV2aWNlIHRybSAgICAgICAgICAgICAjIFRla3JhbSBEQzM5NVUvVVcv RiBEQzMxNVUgYWRhcHRlcnMKbm9kZXZpY2UgYWR2ICAgICAgICAgICAgICMgQWR2YW5zeXMgU0NT SSBhZGFwdGVycwpub2RldmljZSBhZHcgICAgICAgICAgICAgIyBBZHZhbnN5cyB3aWRlIFNDU0kg YWRhcHRlcnMKbm9kZXZpY2UgYWljICAgICAgICAgICAgICMgQWRhcHRlYyAxNVswMTJdeCBTQ1NJ IGFkYXB0ZXJzLCBBSUMtNlsyM102MC4Kbm9kZXZpY2UgYnQgICAgICAgICAgICAgICMgQnVzbG9n aWMvTXlsZXggTXVsdGlNYXN0ZXIgU0NTSSBhZGFwdGVycwpub2RldmljZSBpc2NpICAgICAgICAg ICAgIyBJbnRlbCBDNjAwIFNBUyBjb250cm9sbGVyCiMgUkFJRCBjb250cm9sbGVycyBpbnRlcmZh Y2VkIHRvIHRoZSBTQ1NJIHN1YnN5c3RlbQpub2RldmljZSBhbXIgICAgICAgICAgICAgIyBBTUkg TWVnYVJBSUQKbm9kZXZpY2UgYXJjbXNyICAgICAgICAgICMgQXJlY2EgU0FUQSBJSSBSQUlECm5v ZGV2aWNlIGNpc3MgICAgICAgICAgICAjIENvbXBhcSBTbWFydCBSQUlEIDUqCm5vZGV2aWNlIGRw dCAgICAgICAgICAgICAjIERQVCBTbWFydGNhY2hlIElJSSwgSVYgLSBTZWUgTk9URVMgZm9yIG9w dGlvbnMKbm9kZXZpY2UgaHB0bXYgICAgICAgICAgICMgSGlnaHBvaW50IFJvY2tldFJBSUQgMTgy eApub2RldmljZSBocHRyciAgICAgICAgICAgIyBIaWdocG9pbnQgUm9ja2V0UkFJRCAxN3h4LCAy Mnh4LCAyM3h4LCAyNXh4Cm5vZGV2aWNlIGlpciAgICAgICAgICAgICAjIEludGVsIEludGVncmF0 ZWQgUkFJRApub2RldmljZSBpcHMgICAgICAgICAgICAgIyBJQk0gKEFkYXB0ZWMpIFNlcnZlUkFJ RApub2RldmljZSBtbHkgICAgICAgICAgICAgIyBNeWxleCBBY2NlbGVSQUlEL2VYdHJlbWVSQUlE Cm5vZGV2aWNlIHR3YSAgICAgICAgICAgICAjIDN3YXJlIDkwMDAgc2VyaWVzIFBBVEEvU0FUQSBS QUlECiMgUkFJRCBjb250cm9sbGVycwpub2RldmljZSBhYWMgICAgICAgICAgICAgIyBBZGFwdGVj IEZTQSBSQUlECm5vZGV2aWNlIGFhY3AgICAgICAgICAgICAjIFNDU0kgcGFzc3Rocm91Z2ggZm9y IGFhYyAocmVxdWlyZXMgQ0FNKQpub2RldmljZSBpZGEgICAgICAgICAgICAgIyBDb21wYXEgU21h cnQgUkFJRApub2RldmljZSBtZmkgICAgICAgICAgICAgIyBMU0kgTWVnYVJBSUQgU0FTCm5vZGV2 aWNlIG1seCAgICAgICAgICAgICAjIE15bGV4IERBQzk2MCBmYW1pbHkKbm9kZXZpY2UgdHdlICAg ICAgICAgICAgICMgM3dhcmUgQVRBIFJBSUQKbm9kZXZpY2UgdHdzICAgICAgICAgICAgICMgTFNJ IDN3YXJlIDk3NTAgU0FUQStTQVMgNkdiL3MgUkFJRCBjb250cm9sbGVyCgo= --==========D6490C6FE1812265AB51==========-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 13 20:30:52 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B8796EE; Thu, 13 Nov 2014 20:30:52 +0000 (UTC) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D6904FB; Thu, 13 Nov 2014 20:30:51 +0000 (UTC) Received: by mail-ig0-f181.google.com with SMTP id l13so386778iga.14 for ; Thu, 13 Nov 2014 12:30:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=EYYrKEUZZxKeJpOyX7WRnVg3E+AF5z2QG2xMyV8AuHw=; b=lR9TrNwGL+gR69DoO/oPioVjg/1gE4yDi0PX4hJGr8IDIIPMeQCCp3jSWeOXBj5La/ 60XO0RktZh/Bg69j7aL+iKlREd22glEPJCirRo9VFtOQbV5e5wzoBYa7GxtxBCpGl9fx ut6bZQX0p0JgJkQQE3n6KOoKz+09Nff1Q6lokBCdrEjNmKdLh8KBZbz1+rrbmcFvUUIg 5a3PpOSCcbp7GIOHwRdAQN7N5ZEwNGSk+oHowFWDg2VTfIVHKicmqhqHf8pHgQrTxEXN b9qLn2jXyvwtDnGd2pWDLHp7A6Scch6uE56WMm2Uf6N9RXTd9vgrnI/9Ml4DXEYl0DMo E8kw== MIME-Version: 1.0 X-Received: by 10.50.66.227 with SMTP id i3mr1238079igt.25.1415910651227; Thu, 13 Nov 2014 12:30:51 -0800 (PST) Sender: jdavidlists@gmail.com Received: by 10.43.96.202 with HTTP; Thu, 13 Nov 2014 12:30:51 -0800 (PST) In-Reply-To: References: Date: Thu, 13 Nov 2014 15:30:51 -0500 X-Google-Sender-Auth: 06wtB3AUom5IvkrEtwySWyqkan0 Message-ID: Subject: Re: Checksumming outgoing packets in PF vs in ip[6]_output From: J David To: Ilya Bakulin Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , freebsd-net@freebsd.org, freebsd-pf@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 20:30:52 -0000 On Wed, Nov 5, 2014 at 9:28 AM, Ilya Bakulin wrote: > Of course it was interesting what does the upstream PF do (@ OpenBSD). Seems > they have made the decision to > leave the task of recalculating the checksums for outgoing packets to > ip[6]_output, because currently > the code there overwrites the checksum anyway. > This seems a correct way to me. pf should not longer do any checksum updates > in inbound and outbound path. Is there any chance this change would help with bug 179392 as well? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=179392 Or is that a separate issue? Thanks! From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 03:32:03 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1967BA5 for ; Fri, 14 Nov 2014 03:32:02 +0000 (UTC) Received: from us7.cn4e.com (us7.cn4e.com [96.126.118.192]) by mx1.freebsd.org (Postfix) with ESMTP id C12E7314 for ; Fri, 14 Nov 2014 03:32:02 +0000 (UTC) Received: from mail.mail72.cn4e.com (unknown [218.107.207.72]) by us7.cn4e.com (Postfix) with ESMTP id 7D0FE5153 for ; Fri, 14 Nov 2014 02:38:05 +0000 (UTC) Received: by mail.mail72.cn4e.com (Postfix, from userid 12346) id 2E7C26003A9; Fri, 14 Nov 2014 10:37:54 +0800 (CST) Received: from mail72.cn4e.com (localhost.localdomain [127.0.0.1]) by mail.mail72.cn4e.com (Postfix) with SMTP id 0D6586002C0 for ; Fri, 14 Nov 2014 10:37:54 +0800 (CST) Received: from mail72.cn4e.com (localhost.localdomain [127.0.0.1]) by mail.mail72.cn4e.com (Postfix) with SMTP for ; Fri, 14 Nov 2014 10:37:53 +0800 (CST) From: =?UTF-8?B?546L5Z2kIA==?= To: Subject: SFP NIC Cards for servers/ data collection Industry Date: Fri, 14 Nov 2014 10:37:53 +0800 (CST) Message-Id: <1415932673935@mail72.cn4e.com> Sender: C35-RECALL: ff80808149aacbb60149ac29e6721727 MIME-Version: 1.0 X-Mailer: 35 Intelli-AntiSpam Mail System V3.0 (x64) ~ www.35.com X-Priority: 3 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: base64 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, 14 Nov 2014 03:32:03 -0000 SGVsbG/vvIwNCg0KDQoNCg0KDQpUaGlzIGlzIEplYW4gYW5kIGZyb20gRmVtcmljZSwgR2xhZCBm b25kIHlvdXIgY29tcGFueSBmcm9tIEdvb2dsZSB3ZWJzaXRlIC4NCndlIGFyZSB0aGUgbWFudWZh Y3R1cmVyIG9mIFBDSWUgIFNlcnZlciBOSUMgQ2FyZHMNCkludGVsIGNoaXBzZXRzIGNvbnRyb2xs ZXIsIENFLEZDLFJPSFMsUkVBQ0guIA0KQ29tcGV0aXRpdmUgcHJpY2UgaW4gdGhlIG1hcmtldCAs IHF1aWNrIHNoaXBwaW5nIHRpbWUgLg0KVGhpcyBmb2xsb3dpbmcgb25lcyBpcyBvdXIgcHJvZHVj c3RzOg0KDQoxLiBQQ0lleDQgMlhTRlAgR2lnYWJpdCBFdGhlcm5ldCBOSUMgQ2FyZHMgKEludGVs ODI1NzFFQi9JbnRlbDgyNTc2RUIvSW50ZWw4MjU4MERCKQ0KMi4gUENJZXg4IDJYU0ZQIDEwRyBF dGhlcm5ldCBOSUMgQ2FyZFMgKEludGVsODI1OTlFUyApDQozLiBQQ0lleDQgNFhTRlAgR2lnYWJp dCBFdGhlcm5ldCBOSUMgQ2FyZHMgKEludGVsODI1ODBFQikNCjQuIFBDSWV4NCAxWFNGUCBHaWdh Yml0IEV0aGVybmV0IE5JQyBDYXJkcyhJbnRlbDgyNTcyRUkpDQo1LiBQQ0lleDEgMVhTRlAgR2ln YWJpdCBFdGhlcm5ldCBOSUMgQ2FyZHMoSW50ZWwgSTIxMC9JbnRlbDgyNTgzVikNCjYuIFBDSWV4 OCAxeFNGUCAxMEcgRXRoZXJuZXQgTklDIENhcmRzIChJbnRlbDgyNTk5RU4pDQpJIHRoaW5rIHlv dXIgcHJvZHVjdHMgbWF5YmUgdXNlIG91ciBOSUMgQ2FyZHMgaW4gc29tZSB0aW1lcyAuDQpCVFcs IFdlIGFsc28gc3VwcGx5ICB0aGUgU0ZQLFhGUCxTRlArLFdETSxEV0RNIE1vZHVsZXMNCkhvcGUg bXkgaW5mb3JtYXRpb25zIGNvdWxkIGhlbHAgeW91IC4NClBseiBmZWVsIGZyZWUgdG8gcmVwbHkg dG8gbWUgaW4gYW55IHRpbWUgd2hlbiBoYXZlIGFueSBoZWxwLg0KV2FpdGluZyBmb3IgeW91ciBl YXJseSByZXBseSENCg0KQmVzdCBSZWdhcmRzDQpKZWFuIEhlbmcNCg0KRmVtcmljZSAoQ2hpbmEp IFRlY2hub2xvZ3kgQ28uLCBMdGQuDQpUZWw6MDA4Ni0xMC01MTI2NjgwNy04MTMNCk1vYmlsZTow MDg2LTE1MzMwMDEwNjU3DQpGYXg6IDAwODYtMTAtNjI5NzkzNDMNCkVtYWlsOiBKZWFuQGZlbXJp Y2UuY29tIA0KV2Vic2l0ZXM6IHd3dy5mZW1yaWNlLmNvbSANClNreXBlOiBEcmVhbS1mbHk5OQ0K TVNOOiBEcmVhbS1mbHk5OUBIb3RtYWlsLmNvbQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg== From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 07:28:18 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4F8B4E25 for ; Fri, 14 Nov 2014 07:28:18 +0000 (UTC) Received: from mail.ismobile.com (mail.ismobile.com [176.57.193.164]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.ismobile.com", Issuer "GlobalSign Domain Validation CA - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA919C4D for ; Fri, 14 Nov 2014 07:28:17 +0000 (UTC) Received: from mail.ismobile.com (localhost [127.0.0.1]) by dkim.mail.ismobile.com (Postfix) with ESMTP id C844C2B54A1 for ; Fri, 14 Nov 2014 07:28:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=ismobile.com; h=date:from :to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=selector1; bh=p+gUcs6 PN3jc1XHxUWtTZEg3h2I=; b=MPIzMi7axY66ZEQQ7Fdcot2WNmvsrpS3v8rQDk5 FfypQA/1h0ax7HZ6PvTq1MHaSeY9Uo6r6HirM7nKekjibDmLYySSLEIPy4oXilQ3 qpd9RWygNemlaAdOuo6l+Ij3JxQPL7ewGQddLwckMRg/5EjX1NqwzbRpQEFts8hQ YYP0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=ismobile.com; h=date:from:to :subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=selector1; b=I hext5S3qxMeHTjpuwEMUOaDpXIIq3+uc3T9lVF7cqhd7LUSddGTy0QiDtcOxXJUc 94Ph3LwBNECj6yvsEeIaszk/zk4z9UqlgudLIPltXnwy3LJZ1Q6njc2NrSWPFxbK CLibJFKAJILdtjDM4eGjIjLECoXklSURuMV3SsZsfY= Received: from [172.16.2.31] (glz-macbookpro.hq.ismobile.com [172.16.2.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ismobile.com (Postfix) with ESMTPSA id C05492B54A0 for ; Fri, 14 Nov 2014 07:28:06 +0000 (UTC) Date: Fri, 14 Nov 2014 08:28:06 +0100 From: =?UTF-8?Q?G=C3=B6ran_L=C3=B6wkrantz?= To: freebsd-net@freebsd.org Subject: Re: Unexpected traffic flow Message-ID: <69AF2F05DAD895C2D6810B2D@[172.16.2.31]> In-Reply-To: <15969A88725905DA6D022093@[172.16.2.31]> References: <15969A88725905DA6D022093@[172.16.2.31]> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=11116 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, 14 Nov 2014 07:28:18 -0000 Sorry for top posting but I found the problem. If I remove the bridge=20 interface everything returns to normal. Anyone hava any idea? Could there be bad RSTP messages tricking the=20 forwarding? Bug in if_bridge? Will do some more network snooping but as this was not a problem with the=20 previous FBSD version used here, 8.2, regression? /glz --On 13 Nov 2014 17:20:47 +0100 G=C3=B6ran L=C3=B6wkrantz=20 wrote: > > One of our gateways is behaving oddly after updating to 10.1-PRERELEASE > r274192 and I just can not understand what is happening. > > Internet > | > | > | > +------+-------+ >| FW | > +------+-------+ > | > DMZ > | > +------+-------+ >| GW | OpenVPN > +--+--+--+--+--+ > | | | | > 2 3 4 9 > > Net 2 - em2 - 192.168.2.0/24 - servers, server-net switches. > Net 3 - em1 - 192.168.3.0/24 - workstations, ws-net switches > Net 4 - em0 - 192.168.4.0/24 - WiFi access points + VLAN switch > Net 9 - em4 - 192.168.9.0/24 - monitor net w. a few switches. > DMZ - em5 - XXX.XXX.XXX.128/27 - DMZ and transfer net to outside. > > At the bottom of the mail I have included netstat -rn and ifconfig -au > output. > > > After the upgrade a few hosts got intermittent internet connection and a > few hosts lost all connectivity. > > Specifically, I have one host on the 2-net, 192.168.2.22, that refuses to > connect to internet or > lookup names via the gw, which is also the local DNS. > > 1: tcpdump on em0, em1, em2, em4 and em5 while sending ping to > 192.168.2.1 i.e. from the problem host to the gw. > - incoming traffic on em2: > 16:54:36.220053 IP 192.168.2.22 > 192.168.2.1: ICMP echo request, id > 9814, seq 1, length 64 > 16:54:37.219705 IP 192.168.2.22 > 192.168.2.1: ICMP echo request, id > 9814, seq 2, length 64 > 16:54:38.219732 IP 192.168.2.22 > 192.168.2.1: ICMP echo request, id > 9814, seq 3, length 64 > 16:54:39.219759 IP 192.168.2.22 > 192.168.2.1: ICMP echo request, id > 9814, seq 4, length 64 > 16:54:40.219783 IP 192.168.2.22 > 192.168.2.1: ICMP echo request, id > 9814, seq 5, length 64 > 16:54:41.230678 ARP, Request who-has 192.168.2.1 tell 192.168.2.22, > length 46 > 16:54:41.230682 ARP, Reply 192.168.2.1 is-at 00:1b:21:24:62:4a, length 28 > > - outgoing traffic on em5: > 16:54:36.220066 IP 192.168.2.1 > 192.168.2.22: ICMP echo reply, id 9814, > seq 1, length 64 > ...... + 62 repeates ......... > 16:54:36.224436 IP 192.168.2.1 > 192.168.2.22: ICMP echo reply, id 9814, > seq 1, length 64 > 16:54:37.219712 IP 192.168.2.1 > 192.168.2.22: ICMP echo reply, id 9814, > seq 2, length 64 > ...... + 62 repeates ......... > 16:54:37.223711 IP 192.168.2.1 > 192.168.2.22: ICMP echo reply, id 9814, > seq 2, length 64 > 16:54:38.219738 IP 192.168.2.1 > 192.168.2.22: ICMP echo reply, id 9814, > seq 3, length 64 > ...... + 62 repeates ......... > 16:54:38.224984 IP 192.168.2.1 > 192.168.2.22: ICMP echo reply, id 9814, > seq 3, length 64 > 16:54:39.219766 IP 192.168.2.1 > 192.168.2.22: ICMP echo reply, id 9814, > seq 4, length 64 > ...... + 62 repeates ......... > 16:54:39.225757 IP 192.168.2.1 > 192.168.2.22: ICMP echo reply, id 9814, > seq 4, length 64 > 16:54:40.219789 IP 192.168.2.1 > 192.168.2.22: ICMP echo reply, id 9814, > seq 5, length 64 > ...... + 62 repeates ......... > 16:54:40.224282 IP 192.168.2.1 > 192.168.2.22: ICMP echo reply, id 9814, > seq 5, length 64 > > Checking on em2, I see > root@gw01:/usr/local/etc # arp 192.168.2.22 > dbserver-2.lulea.arcticgroup.se (192.168.2.22) at 00:19:99:21:87:62 on > em2 expires in 1116 seconds [ethernet] > > So we have route and arp at em2 but the ping replies are sent out via the > port connecting to the default gateway. > > If I try to ping 192.168.2.22 from the GW, I get this response and only > traffic going out via em5. > root@gw01:/usr/local/etc # ping 192.168.2.22 > PING 192.168.2.22 (192.168.2.22): 56 data bytes > 36 bytes from dmz.xxx.com (XXX.XXX.XXX.129): Redirect Host(New addr: > XXX.XXX.XXX.158) > Vr HL TOS Len ID Flg off TTL Pro cks Src Dst > 4 5 00 0054 39e4 0 0000 40 01 0c2f XXX.XXX.XXX.158 192.168.2.22 > > For some hosts, 192.168.6 for example, this happens intermittently like > 3-10 pings go correct, returning on em2, then 1, 2 or more are sent via > em5. > > None of the hosts are using RIP or other active routing, only static > routes. > GW host is built with nanobsd and attached kernel configuration. > > I have never seen anything like this. Can anyone help? Any more info > needed? > > Routing tables (only IPv4 as that's what's on the inside). > > Internet: > Destination Gateway Flags Netif Expire > default XXX.XXX.XXX.129 UGS em5 FW DMZ IF > 10.191.251.0/24 10.191.251.2 UGS tun0 OpenVPN > net 1 > 10.191.251.1 link#14 UHS lo0 OpenVPN > local endpoint 1 > 10.191.251.2 link#14 UH tun0 OpenVPN > remote endpoint 1 > 10.191.252.0/24 10.191.252.2 UGS tun1 OpenVPN > net 2 > 10.191.252.1 link#15 UHS lo0 OpenVPN > local endpoint 2 > 10.191.252.2 link#15 UH tun1 OpenVPN > remote endpoint 2 > 10.191.253.0/24 10.191.253.2 UGS tun2 OpenVPN > net 3 > 10.191.253.1 link#16 UHS lo0 OpenVPN > local endpoint 3 > 10.191.253.2 link#16 UH tun2 OpenVPN > remote endpoint 3 > 127.0.0.1 link#11 UH lo0 localhost > XXX.XXX.XXX.128/27 link#6 U em5 DMZ = network > XXX.XXX.XXX.157 link#13 UHS lo0 > XXX.XXX.XXX.157/32 link#13 U tap0 OpenVPN > Server > XXX.XXX.XXX.158 link#6 UHS lo0 GW extern > IP, em5 > 192.168.2.0/24 link#3 U em2 server net > 192.168.2.1 link#3 UHS lo0 GW em2 > 192.168.3.0/24 link#2 U em1 ws net > 192.168.3.1 link#2 UHS lo0 GW em1 > 192.168.4.0/24 link#1 U em0 wifi net > 192.168.4.254 link#1 UHS lo0 server em0 > 192.168.9.0/24 link#5 U em4 monitor = net > 192.168.9.254 link#5 UHS lo0 server em4 > > > em0: flags=3D8843 metric 0 mtu = 1500 > = options=3D209b= > ether 00:1b:21:24:62:48 > inet 192.168.4.254 netmask 0xffffff00 broadcast 192.168.4.255 > nd6 options=3D29 > media: Ethernet autoselect (1000baseT ) > status: active > em1: flags=3D8843 metric 0 mtu = 1500 > options=3D9b > ether 00:1b:21:24:62:49 > inet 192.168.3.1 netmask 0xffffff00 broadcast 192.168.3.255 > nd6 options=3D29 > media: Ethernet autoselect (1000baseT ) > status: active > em2: flags=3D8943 metric = 0 > mtu 1500 > options=3D9b > ether 00:1b:21:24:62:4a > inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255 > nd6 options=3D29 > media: Ethernet autoselect (1000baseT ) > status: active > em4: flags=3D8843 metric 0 mtu = 1500 > = options=3D4219b _MAGIC,VLAN_HWTSO> > ether 00:30:48:b9:99:c8 > inet 192.168.9.254 netmask 0xffffff00 broadcast 192.168.9.255 > nd6 options=3D29 > media: Ethernet autoselect (100baseTX ) > status: active > em5: flags=3D8943 metric = 0 > mtu 1500 > = options=3D42098 > ether 00:30:48:b9:99:c9 > inet XXX.XXX.XXX.158 netmask 0xffffffe0 broadcast XXX.XXX.XXX.159 > inet6 fe80::230:48ff:feb9:99c9%em5 prefixlen 64 scopeid 0x6 > inet6 xxxx:xxxx:101:1::fffe prefixlen 64 > nd6 options=3D21 > media: Ethernet autoselect (1000baseT ) > status: active > lo0: flags=3D8049 metric 0 mtu 16384 > options=3D600003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0xb > inet 127.0.0.1 netmask 0xff000000 > nd6 options=3D21 > bridge0: flags=3D8843 metric 0 = mtu > 1500 > ether 02:33:00:4d:00:00 > nd6 options=3D9 > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: em5 flags=3D143 > ifmaxaddr 0 port 6 priority 128 path cost 2000000 > member: tap0 flags=3D143 > ifmaxaddr 0 port 13 priority 128 path cost 2000000 > tap0: flags=3D8943 metric = 0 > mtu 1500 > options=3D80000 > ether 00:bd:50:63:00:00 > inet XXX.XXX.XXX.157 netmask 0xffffffff broadcast XXX.XXX.XXX.157 > inet6 fe80::2bd:50ff:fe63:0%tap0 prefixlen 64 scopeid 0xd > inet6 xxxx:xxxx:101:1::fffd prefixlen 64 > nd6 options=3D21 > media: Ethernet autoselect > status: no carrier > tun0: flags=3D8051 metric 0 mtu 1500 > options=3D80000 > inet6 fe80::21b:21ff:fe24:6248%tun0 prefixlen 64 scopeid 0xe > inet 10.191.251.1 --> 10.191.251.2 netmask 0xffffffff > nd6 options=3D21 > Opened by PID 1565 > tun1: flags=3D8051 metric 0 mtu 1500 > options=3D80000 > inet6 fe80::21b:21ff:fe24:6248%tun1 prefixlen 64 scopeid 0xf > inet 10.191.252.1 --> 10.191.252.2 netmask 0xffffffff > nd6 options=3D21 > Opened by PID 1580 > tun2: flags=3D8051 metric 0 mtu 1500 > options=3D80000 > inet6 fe80::21b:21ff:fe24:6248%tun2 prefixlen 64 scopeid 0x10 > inet 10.191.253.1 --> 10.191.253.2 netmask 0xffffffff > nd6 options=3D21 > Opened by PID 1595 > > root@gw01:/usr/local/etc # route get 192.168.2.22 > route to: dbserver-2.lulea.arcticgroup.se > destination: 192.168.2.0 > mask: 255.255.255.0 > fib: 0 > interface: em2 > flags: > recvpipe sendpipe ssthresh rtt,msec mtu weight expire > 0 0 0 0 1500 1 0 > > "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 08:17:50 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BAE5B8EC; Fri, 14 Nov 2014 08:17:50 +0000 (UTC) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 85C56111; Fri, 14 Nov 2014 08:17:50 +0000 (UTC) Received: by mail-pa0-f51.google.com with SMTP id ey11so235425pad.24 for ; Fri, 14 Nov 2014 00:17:50 -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=ze6ZEe9QWhS4n4LP42H1dgc2Zhq5Uv/mRTV2Uo23h8U=; b=zT0xhxOkl9CKxrCXTEKqOjx0FlQWmrn3osV4pU7gTkjXgN7uvfa5BuPVvatOt6L4Lc ApvO0p9PrNTqg4ASOZULKUGQqFpZtj1eZvJrtsFtc37fsKahfOCzw3drVvt4EP/Z0z0v bouWPhcd0Km9IU7/batqTyadgDma9YsgYarf+aUl/cpGLE2k4YfUdM0UMKRXVaji9Zhg 6BRTac9SPDmz0NdSPQL28OqJU9/sGRSEjdoFk3UCohJ/3cXTd9RKjsRGRzhWuaojygtf bjji3ymgZeZPyYgRKNVzGL1+TrFpuDuSSmWaXVMxIQfzcw5R1udmyDwYNtb7C5pl+u80 59cA== MIME-Version: 1.0 X-Received: by 10.70.53.102 with SMTP id a6mr8544073pdp.70.1415953070139; Fri, 14 Nov 2014 00:17:50 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.70.73.2 with HTTP; Fri, 14 Nov 2014 00:17:50 -0800 (PST) In-Reply-To: References: Date: Fri, 14 Nov 2014 09:17:50 +0100 X-Google-Sender-Auth: guUO7D1MGPk71ej7uaY04b7D5CY Message-ID: Subject: Re: Checksumming outgoing packets in PF vs in ip[6]_output From: =?UTF-8?Q?Ermal_Lu=C3=A7i?= To: J David Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-hackers@freebsd.org" , Ilya Bakulin , "freebsd-pf@freebsd.org" , 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: Fri, 14 Nov 2014 08:17:50 -0000 Yes confirmed it will solve that issue as well. On Thu, Nov 13, 2014 at 9:30 PM, J David wrote: > On Wed, Nov 5, 2014 at 9:28 AM, Ilya Bakulin wrote: > > Of course it was interesting what does the upstream PF do (@ OpenBSD). > Seems > > they have made the decision to > > leave the task of recalculating the checksums for outgoing packets to > > ip[6]_output, because currently > > the code there overwrites the checksum anyway. > > This seems a correct way to me. pf should not longer do any checksum > updates > > in inbound and outbound path. > > Is there any chance this change would help with bug 179392 as well? > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=179392 > > Or is that a separate issue? > > Thanks! > _______________________________________________ > 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" > -- Ermal From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 10:34:53 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1F2EC0B; Fri, 14 Nov 2014 10:34:53 +0000 (UTC) Received: from olymp.kibab.com (olymp.kibab.com [5.9.14.202]) by mx1.freebsd.org (Postfix) with ESMTP id 9D74312A; Fri, 14 Nov 2014 10:34:53 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 olymp.kibab.com AEC4E75918 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bakulin.de; s=default; t=1415961291; bh=CvZtRqwKdnunq6RdTxnUtVo2X0hUlxmaO4TuhJTgee8=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=GL2gScTGZ4laPADEyB4Q+42PfeET7vuONMay1nI7isYwEAiNZNMfCiZCFIL9es3Gl 0ygjGOLCQOtK0uOBBZyrylvNLSDw67e9c6aZAjLYLTMhuPtdY9X5cylxm4xz7ry4ur DsOosdJ2ev7wasKjT0PGcFEZoPsysbXKgeB5bE5U= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 14 Nov 2014 11:34:51 +0100 From: Ilya Bakulin To: =?UTF-8?Q?Ermal_Lu=C3=A7i?= Subject: Re: Checksumming outgoing packets in PF vs in =?UTF-8?Q?ip=5B=36=5D=5Foutput?= Organization: Deglitch Networks In-Reply-To: References: Message-ID: <9734b7d34828a102d9a2f5061c11ae3d@mail.bakulin.de> X-Sender: ilya@bakulin.de Cc: freebsd-hackers@freebsd.org, freebsd-net , J David , owner-freebsd-net@freebsd.org, freebsd-pf@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 10:34:54 -0000 Hi all, actually with _my_ checksumming patch the rdr-to is broken completely :-( So I'm waiting for Ermal to send an updated version of his patch that may really solve the problem! On 2014-11-14 09:17, Ermal Luçi wrote: > Yes confirmed it will solve that issue as well. > > On Thu, Nov 13, 2014 at 9:30 PM, J David > wrote: > >> On Wed, Nov 5, 2014 at 9:28 AM, Ilya Bakulin wrote: >> > Of course it was interesting what does the upstream PF do (@ OpenBSD). >> Seems >> > they have made the decision to >> > leave the task of recalculating the checksums for outgoing packets to >> > ip[6]_output, because currently >> > the code there overwrites the checksum anyway. >> > This seems a correct way to me. pf should not longer do any checksum >> updates >> > in inbound and outbound path. >> >> Is there any chance this change would help with bug 179392 as well? >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=179392 >> >> Or is that a separate issue? >> >> Thanks! >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 11:57:20 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A58D71AF; Fri, 14 Nov 2014 11:57:20 +0000 (UTC) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6B50AAF7; Fri, 14 Nov 2014 11:57:20 +0000 (UTC) Received: by mail-pd0-f171.google.com with SMTP id r10so16610539pdi.30 for ; Fri, 14 Nov 2014 03:57:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Z5hSeA4uiIDAQTvbBSZV1BFvEAkIXKm57wtpl+scDa0=; b=DEgkEGMX52pKynf+QiY988IEnrLAHbOnUx8dIUYW5Y0gqqgj25J5N3v2nzYXd2aq2n 0UifkBYFmfAQxTUQV7kwff1i3dJXfJOrdbbhKypOkkFXXHzXKRoJEA/mD42wlqOv7AR4 7a8OG9G3XPzF2kyHk4ySx4h7ReQEcImOVd5iHiH09OdjIGLnqxiIrFgpTy+np6jSFast WFcvzTBbA/MG2C3Bcdz5tVCUPNTN8NydlawKJ7b7xQ9jQ9GSc9cAlSEFCOgQEZSUzK6J dZW1ya3hdJEl7j9wRotitlqvtSuAY2V3V8Ptd9wcouxLX0I2gkOF7c/VX3zEd0ly7b1H E74g== MIME-Version: 1.0 X-Received: by 10.68.68.240 with SMTP id z16mr9624677pbt.70.1415966240025; Fri, 14 Nov 2014 03:57:20 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.70.73.2 with HTTP; Fri, 14 Nov 2014 03:57:19 -0800 (PST) In-Reply-To: <9734b7d34828a102d9a2f5061c11ae3d@mail.bakulin.de> References: <9734b7d34828a102d9a2f5061c11ae3d@mail.bakulin.de> Date: Fri, 14 Nov 2014 12:57:19 +0100 X-Google-Sender-Auth: bHDfgzl280RyWYloSRkyZ4_5K3c Message-ID: Subject: Re: Checksumming outgoing packets in PF vs in ip[6]_output From: =?UTF-8?Q?Ermal_Lu=C3=A7i?= To: Ilya Bakulin Content-Type: multipart/mixed; boundary=001a113817fcc0512c0507d054a5 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Freebsd hackers list , freebsd-net , J David , owner-freebsd-net@freebsd.org, "freebsd-pf@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 11:57:20 -0000 --001a113817fcc0512c0507d054a5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Here is a direct patch. Give it a try. For the reply-to issues there is another patch complementary to this i will send. On Fri, Nov 14, 2014 at 11:34 AM, Ilya Bakulin wrote: > Hi all, > > actually with _my_ checksumming patch the rdr-to is broken completely :-( > So I'm waiting for Ermal to send an updated version of his patch that may > really solve the problem! > > > On 2014-11-14 09:17, Ermal Lu=C3=A7i wrote: > >> Yes confirmed it will solve that issue as well. >> >> On Thu, Nov 13, 2014 at 9:30 PM, J David wrote= : >> >> On Wed, Nov 5, 2014 at 9:28 AM, Ilya Bakulin wrote: >>> > Of course it was interesting what does the upstream PF do (@ OpenBSD)= . >>> Seems >>> > they have made the decision to >>> > leave the task of recalculating the checksums for outgoing packets to >>> > ip[6]_output, because currently >>> > the code there overwrites the checksum anyway. >>> > This seems a correct way to me. pf should not longer do any checksum >>> updates >>> > in inbound and outbound path. >>> >>> Is there any chance this change would help with bug 179392 as well? >>> >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D179392 >>> >>> Or is that a separate issue? >>> >>> Thanks! >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >>> > --=20 Ermal --001a113817fcc0512c0507d054a5 Content-Type: application/octet-stream; name="pf_ipv6_checksum.patch" Content-Disposition: attachment; filename="pf_ipv6_checksum.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i2hhqx000 ZGlmZiAtLWdpdCBhL3N5cy9uZXRwZmlsL3BmL3BmX2lvY3RsLmMgYi9zeXMvbmV0cGZpbC9wZi9w Zl9pb2N0bC5jCmluZGV4IGRiYTU2NzQuLmNhN2Y4NTEgMTAwNjQ0Ci0tLSBhL3N5cy9uZXRwZmls L3BmL3BmX2lvY3RsLmMKKysrIGIvc3lzL25ldHBmaWwvcGYvcGZfaW9jdGwuYwpAQCAtNzYsNiAr NzYsNyBAQCBfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CiAjaW5jbHVkZSA8bmV0aW5ldC9pbi5oPgog I2luY2x1ZGUgPG5ldGluZXQvaXAuaD4KICNpbmNsdWRlIDxuZXRpbmV0L2lwX3Zhci5oPgorI2lu Y2x1ZGUgPG5ldGluZXQ2L2lwNl92YXIuaD4KICNpbmNsdWRlIDxuZXRpbmV0L2lwX2ljbXAuaD4K IAogI2lmZGVmIElORVQ2CkBAIC0zNjE5LDEyICszNjIwLDkgQEAgcGZfY2hlY2s2X291dCh2b2lk ICphcmcsIHN0cnVjdCBtYnVmICoqbSwgc3RydWN0IGlmbmV0ICppZnAsIGludCBkaXIsCiAJaW50 IGNoazsKIAogCS8qIFdlIG5lZWQgYSBwcm9wZXIgQ1NVTSBiZWZvcmUgd2Ugc3RhcnQgKHMuIE9w ZW5CU0QgaXBfb3V0cHV0KSAqLwotCWlmICgoKm0pLT5tX3BrdGhkci5jc3VtX2ZsYWdzICYgQ1NV TV9ERUxBWV9EQVRBKSB7Ci0jaWZkZWYgSU5FVAotCQkvKiBYWFgtQlogY29weSZwYXN0ZSBlcnJv ciBmcm9tIHIxMjYyNjE/ICovCi0JCWluX2RlbGF5ZWRfY2tzdW0oKm0pOwotI2VuZGlmCi0JCSgq bSktPm1fcGt0aGRyLmNzdW1fZmxhZ3MgJj0gfkNTVU1fREVMQVlfREFUQTsKKwlpZiAoKCptKS0+ bV9wa3RoZHIuY3N1bV9mbGFncyAmIENTVU1fREVMQVlfREFUQV9JUFY2KSB7CisJCWluNl9kZWxh eWVkX2Nrc3VtKCptLCAoKm0pLT5tX3BrdGhkci5sZW4gLSBzaXplb2Yoc3RydWN0IGlwNl9oZHIp LCBzaXplb2Yoc3RydWN0IGlwNl9oZHIpKTsKKwkJKCptKS0+bV9wa3RoZHIuY3N1bV9mbGFncyAm PSB+Q1NVTV9ERUxBWV9EQVRBX0lQVjY7CiAJfQogCUNVUlZORVRfU0VUKGlmcC0+aWZfdm5ldCk7 CiAJY2hrID0gcGZfdGVzdDYoUEZfT1VULCBpZnAsIG0sIGlucCk7Cg== --001a113817fcc0512c0507d054a5-- From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 12:34:34 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C6E7EAB; Fri, 14 Nov 2014 12:34:34 +0000 (UTC) Received: from olymp.kibab.com (olymp.kibab.com [5.9.14.202]) by mx1.freebsd.org (Postfix) with ESMTP id 5BE83EFD; Fri, 14 Nov 2014 12:34:32 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 olymp.kibab.com 3743A75918 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bakulin.de; s=default; t=1415968470; bh=07v+EQ6VSe0WWql2imxQcrebpY21wPv/AqBSYQZikXU=; h=In-Reply-To:References:Subject:From:Date:To:CC; b=bx9zwWEQ1iyauD09xBLVU4mPAEUkrNDUKir+HMErpjP4JLEmmA7il4pb4NMjIX+5U jwZXmNQ/tmeqQRFEm7Dz8+Kiy99l23IkDzNQgvNsO6OtbRO9wR055nu7P9me4U+WHu uc47QURrHWXXpB3mNSpe7jI38N9xNEyIZUrCuMzc= In-Reply-To: References: <9734b7d34828a102d9a2f5061c11ae3d@mail.bakulin.de> MIME-Version: 1.0 Subject: Re: Checksumming outgoing packets in PF vs in ip[6]_output From: Ilya Bakulin Date: Fri, 14 Nov 2014 13:34:29 +0100 To: =?ISO-8859-1?Q?Ermal_Lu=E7i?= Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Freebsd hackers list , freebsd-pf@freebsd.org, freebsd-net , J David , owner-freebsd-net@freebsd.org, ermal.luci@gmail.com 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, 14 Nov 2014 12:34:34 -0000 Hi Ermal, yes, this patch works for both #179392 and #172648. What do you need to merge this into -CURRENT and MFC to stable/9? On 2014-11-14 12:57, Ermal Luçi wrote: > Here is a direct patch. > Give it a try. > > For the reply-to issues there is another patch complementary to this i > will send. > > On Fri, Nov 14, 2014 at 11:34 AM, Ilya Bakulin > wrote: > >> Hi all, >> >> actually with _my_ checksumming patch the rdr-to is broken >> completely :-( >> So I'm waiting for Ermal to send an updated version of his patch >> that may really solve the problem! >> >> On 2014-11-14 09:17, Ermal Luçi wrote: >> Yes confirmed it will solve that issue as well. >> >> On Thu, Nov 13, 2014 at 9:30 PM, J David >> wrote: >> >> On Wed, Nov 5, 2014 at 9:28 AM, Ilya Bakulin >> wrote: >>> Of course it was interesting what does the upstream PF do (@ >> OpenBSD). >> Seems >>> they have made the decision to >>> leave the task of recalculating the checksums for outgoing >> packets to >>> ip[6]_output, because currently >>> the code there overwrites the checksum anyway. >>> This seems a correct way to me. pf should not longer do any >> checksum >> updates >>> in inbound and outbound path. >> >> Is there any chance this change would help with bug 179392 as well? >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=179392 [1] >> >> Or is that a separate issue? >> >> Thanks! >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net [2] >> To unsubscribe, send any mail to >> "freebsd-net-unsubscribe@freebsd.org" > > -- > > Ermal > > Links: > ------ > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=179392 > [2] http://lists.freebsd.org/mailman/listinfo/freebsd-net -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 13:08:35 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 91B3B70E; Fri, 14 Nov 2014 13:08:35 +0000 (UTC) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 58C85243; Fri, 14 Nov 2014 13:08:35 +0000 (UTC) Received: by mail-pa0-f47.google.com with SMTP id kx10so17530494pab.34 for ; Fri, 14 Nov 2014 05:08:35 -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=k91e6+X4iCJo8otmRKo8iS0pLtFK6YhROZ6Rlf3HI98=; b=nM0e38ZwQkwXNODNyGE6/RbEA0SilHtfzn4RDjwrm7T4Uqe2XWxDBynCucl/WBC29o J7LPVvHuTMl4cFdYy/ds4PFbUnl8DIjmGT/Xv2hyQaTb8XbYQdie0prnXEp05Al4JssP w8YBsptGtr10JQ0QnpJKi2/IcfAuU4JyqVHgjdsOSYChlwOOwSVfaIbb3bDjSPeN+Tjx B5LuHe3bnNW7Wnmmk9Jt6QD9EOxV/YP4ka0OpnRNaE0SLeiVmA3+E9OMxBXE5pQ3SHh1 pRKwNi4EzGZ/fcahqMjgxekyCmmlB5X+RCt2oiFkZ9Qq/DpMpP2I9Sl2XMo4QeWA/xpY SSHg== MIME-Version: 1.0 X-Received: by 10.70.131.199 with SMTP id oo7mr10079581pdb.138.1415970513950; Fri, 14 Nov 2014 05:08:33 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.70.73.2 with HTTP; Fri, 14 Nov 2014 05:08:33 -0800 (PST) In-Reply-To: References: <9734b7d34828a102d9a2f5061c11ae3d@mail.bakulin.de> Date: Fri, 14 Nov 2014 14:08:33 +0100 X-Google-Sender-Auth: vE7hR9KrsnB7cD3PU_p5tm3KvRU Message-ID: Subject: Re: Checksumming outgoing packets in PF vs in ip[6]_output From: =?UTF-8?Q?Ermal_Lu=C3=A7i?= To: Ilya Bakulin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Freebsd hackers list , freebsd-net , J David , owner-freebsd-net@freebsd.org, "freebsd-pf@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 13:08:35 -0000 Hello Ilya, just approval from some people. I will follow-up. On Fri, Nov 14, 2014 at 1:34 PM, Ilya Bakulin wrote: > Hi Ermal, > yes, this patch works for both #179392 and #172648. > > What do you need to merge this into -CURRENT and MFC to stable/9? > > > On 2014-11-14 12:57, Ermal Lu=C3=A7i wrote: > > Here is a direct patch. > > Give it a try. > > > > For the reply-to issues there is another patch complementary to this i > > will send. > > > > On Fri, Nov 14, 2014 at 11:34 AM, Ilya Bakulin > > wrote: > > > >> Hi all, > >> > >> actually with _my_ checksumming patch the rdr-to is broken > >> completely :-( > >> So I'm waiting for Ermal to send an updated version of his patch > >> that may really solve the problem! > >> > >> On 2014-11-14 09:17, Ermal Lu=C3=A7i wrote: > >> Yes confirmed it will solve that issue as well. > >> > >> On Thu, Nov 13, 2014 at 9:30 PM, J David > >> wrote: > >> > >> On Wed, Nov 5, 2014 at 9:28 AM, Ilya Bakulin > >> wrote: > >>> Of course it was interesting what does the upstream PF do (@ > >> OpenBSD). > >> Seems > >>> they have made the decision to > >>> leave the task of recalculating the checksums for outgoing > >> packets to > >>> ip[6]_output, because currently > >>> the code there overwrites the checksum anyway. > >>> This seems a correct way to me. pf should not longer do any > >> checksum > >> updates > >>> in inbound and outbound path. > >> > >> Is there any chance this change would help with bug 179392 as well? > >> > >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D179392 [1] > >> > >> Or is that a separate issue? > >> > >> Thanks! > >> _______________________________________________ > >> freebsd-net@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-net [2] > >> To unsubscribe, send any mail to > >> "freebsd-net-unsubscribe@freebsd.org" > > > > -- > > > > Ermal > > > > Links: > > ------ > > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D179392 > > [2] http://lists.freebsd.org/mailman/listinfo/freebsd-net > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. --=20 Ermal