From owner-freebsd-net@freebsd.org Sun Nov 29 05:22:12 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 62D68A3BA03 for ; Sun, 29 Nov 2015 05:22:12 +0000 (UTC) (envelope-from noname.esst@yahoo.com) Received: from nm9.bullet.mail.ne1.yahoo.com (nm9.bullet.mail.ne1.yahoo.com [98.138.90.72]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2ECB11C6F for ; Sun, 29 Nov 2015 05:22:12 +0000 (UTC) (envelope-from noname.esst@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1448774389; bh=LHhQBSs00ITD+AG1FqMmwm6ee1lNxyoxLangTZSqbqQ=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=KK3e0pStBUSPVXFh3w2T/YCm0gi7zP2Ss8Ymn7W37xXbydmsbSC2GujzXc2j5ogjYzgXekFZJ/t5RqFTz9uwVbEpzvx9y4c+sfsj+0BGCeel9jvt6WWv9RpSiA5vFI+LAngcw8uS45pNDjdN0gMDF2h8jsrwX9h70VRg6VTJatFYFcGVkavS/OzVBPcEBP5nj1PFco8LIt5V6HydZzQJjfVkmltutQEl2DNSei1URSEZI+Kv+fApVRJaPuCBIHulBSC25rD7vcXiGo4Bwu4ksweG2beRf1cdh7Ca4NAfO3d2KnCx0K75qW4aHDOjxF9PI7xKBc+ZVWL9UAO2GAFABw== Received: from [98.138.100.118] by nm9.bullet.mail.ne1.yahoo.com with NNFMP; 29 Nov 2015 05:19:49 -0000 Received: from [98.138.226.163] by tm109.bullet.mail.ne1.yahoo.com with NNFMP; 29 Nov 2015 05:19:48 -0000 Received: from [127.0.0.1] by omp1064.mail.ne1.yahoo.com with NNFMP; 29 Nov 2015 05:19:48 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 923982.24407.bm@omp1064.mail.ne1.yahoo.com X-YMail-OSG: Vun7F7MVM1ndRImnkPuh.RU4xZhvsKeeyE.9n9Xg4D_uTM0A2lHYbAvQgiID2eb 3uMKpKlKC1ZloNl_RxTOH_570gko1tpZE6ZoNv9vovqZZiWodq8IAOD.ioVET8bWgxwgra3BFP3q GaOSryDx8.qxIzS.RW5M_GnpJmFSx.36A05MQ7TJydZ9yncnvmuQlJI7IiQBMPDrH_v2.6ADHuDt XA9taN4pREbePMTkdE.EHq1B4f2hx_ITyMe8Xt_EgqAGOEvbCkx2QX9CqL.OoZO33nJW32v3ODcp TvKWL7ot5gr4v2CbPvtVyzy8p21e6NjAOdvQ7BplvQvl9YfEgLeEE9PZcUIvAoEWb.R4pYMoaRs3 HJAW_hZEnWxxfNYYeU9J8N7wAo3zjEpiBN.p24FSc1CriAWaliZ4Y7f1Mr0etMXHCTuZIVisrZPz e9R7MWJsn6opIxNbdLCQaGgKa2WvBbMMJ_dCg4s0Ouo4YsZzGmnT_v.s.8lSD4kYP983mU_6tyTZ VpS7Z0JOs.Wtmko4- Received: by 98.138.101.172; Sun, 29 Nov 2015 05:19:48 +0000 Date: Sun, 29 Nov 2015 05:19:48 +0000 (UTC) From: Nomad Esst Reply-To: Nomad Esst To: FreeBSD Net Message-ID: <63933653.9768704.1448774388191.JavaMail.yahoo@mail.yahoo.com> Subject: kernel panic in igb driver MIME-Version: 1.0 References: <63933653.9768704.1448774388191.JavaMail.yahoo.ref@mail.yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2015 05:22:12 -0000 During some performance tests and while a voice call was going through an i= gb interface, we attempt to disconnect and connect the cable. After the int= erface comes up this kernel panic occurs: Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address=C2=A0=C2=A0 =3D 0xc fault code=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 =3D supervisor read data, page not present instruction pointer=C2=A0=C2=A0=C2=A0=C2=A0 =3D 0x20:0xffffffff80e189b9 stack pointer=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =3D 0x28:0xffffff80ba3fe640 frame pointer=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =3D 0x28:0xffffff80ba3feb20 code segment=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 =3D base 0x0, limit 0xfffff, type 0x1b =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D DPL 0, = pres 1, long 1, def32 0, gran 1 processor eflags=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D interrupt en= abled, resume, IOPL =3D 0 current process=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D 12 (irq= 268: +) [ thread pid 12 tid 100114 ] Stopped at=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 igb_start_locked+0x639:=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 movzbl=C2=A0 0xc(%rbx),%esi Thanks in advance. From owner-freebsd-net@freebsd.org Sun Nov 29 06:08:16 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AFEF4A3C225 for ; Sun, 29 Nov 2015 06:08:16 +0000 (UTC) (envelope-from noname.esst@yahoo.com) Received: from nm15-vm6.bullet.mail.ne1.yahoo.com (nm15-vm6.bullet.mail.ne1.yahoo.com [98.138.91.108]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7D387121B for ; Sun, 29 Nov 2015 06:08:16 +0000 (UTC) (envelope-from noname.esst@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1448777178; bh=Jwieh4jnrDCaxd/zMy/J99FkqZb7Jq3kxxfZCmPNCgY=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=QeTNYR4kkVynn4oOJObDjbwmYGdaYZ3AUwKyRhNuEvsQYf0VKses/vti4Fkkdc7rEE1qyKPwMl9lQA4+YzbwAHeyJrhcTYofBJ28LYLbFMFoNorRvtVZOoT3G2xyGVvPjCO3cqMG4I2L+dXpQqBWiBFaFDosjL00d/F0WuwYimK/TwqOzD2Ug6HECtZN2S9IH5Mdtlp3aXHgJJxIN4Hp5ngnlq8gRJU2VYPJMXPzN9oe1X1cYPjnHrxP70NolJqoJMzDfYZWiUh7AnJH8gTed+PFwWoeGp5A3RHfLsy0FuwTVIctbIf0VTxerZ6eItRh+2+us6Kw0mqx59Y4IdQZAQ== Received: from [98.138.101.132] by nm15.bullet.mail.ne1.yahoo.com with NNFMP; 29 Nov 2015 06:06:18 -0000 Received: from [98.138.89.197] by tm20.bullet.mail.ne1.yahoo.com with NNFMP; 29 Nov 2015 06:06:18 -0000 Received: from [127.0.0.1] by omp1055.mail.ne1.yahoo.com with NNFMP; 29 Nov 2015 06:06:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 342626.70959.bm@omp1055.mail.ne1.yahoo.com X-YMail-OSG: W6HgScMVM1mjZ4WLjMf6Jtw8gIY_vj0pUiDaGsftMBiqufxaRDv_CS5WEyzhhje kaWIa0252XBFmxveu97jagcO3j6gqLYIdx.FJIINrA6OcVSBFHRgZ19noEr_XnYHAyxaFquSkm_z QDP2h7M5JLrnZXOoDWPQsSvBx8WB51KiVnMvuRqhJeSNVpDOUViKJ4fcrRmBcRQ.7JFiIjZVL_tv 2kRCcVx0SNADIWWU6OUSz.kuDG_havsFOSC0ZlSdoxz20Vp4QZnvT18iKamrEeCpsMEW0jy1bOiL jCOMf.u7XrEQo4lblCzxhfdtyxn7NjStY1XDW.IeH8h86ZeTi_OmINsNu3wT491eb09zVlTopN08 VWV_cpLuhnW0klOsdakDyW_H8Uk0Y2BNTDYRr533rQqyZA93OQLjCb2hhahCeBBiV8IRS7TXSPjh DoxbVlHVuE.3kFfihL8mOcM4odeTtOdzTRUSHawDYrUG5eivTVnWpeaeHmQiHIGMxnIjJQeY0B6u 5oyZuAfhs4OwBLw-- Received: by 98.138.101.175; Sun, 29 Nov 2015 06:06:17 +0000 Date: Sun, 29 Nov 2015 06:06:17 +0000 (UTC) From: Nomad Esst Reply-To: Nomad Esst To: FreeBSD Net Message-ID: <501993020.9649716.1448777177610.JavaMail.yahoo@mail.yahoo.com> Subject: kernel panic in igb driver - more info MIME-Version: 1.0 References: <501993020.9649716.1448777177610.JavaMail.yahoo.ref@mail.yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2015 06:08:16 -0000 Any help would be appreciated=C2=A0 db> trace Tracing pid 12 tid 100125 td 0xfffffe0004ecf000 igb_start_locked() at igb_start_locked+0x639/frame 0xffffff80e3464b20 igb_msix_que() at igb_msix_que+0xb7/frame 0xffffff80e3464b60 intr_event_execute_handlers() at intr_event_execute_handlers+0xfd/frame 0xf= fffff80e3464b90 ithread_loop() at ithread_loop+0x9d/frame 0xffffff80e3464be0 fork_exit() at fork_exit+0x11f/frame 0xffffff80e3464c30 fork_trampoline() at fork_trampoline+0xe/frame 0xffffff80e3464c30 --- trap 0, rip =3D 0, rsp =3D 0xffffff80e3464cf0, rbp =3D 0 --- db> Thanks in advance From owner-freebsd-net@freebsd.org Mon Nov 30 03:58:40 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2EDA1A3BCC1 for ; Mon, 30 Nov 2015 03:58:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 143C11981 for ; Mon, 30 Nov 2015 03:58:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tAU3wd7L018073 for ; Mon, 30 Nov 2015 03:58:39 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 204831] mld_v2 listener report does not report all active groups to the router Date: Mon, 30 Nov 2015 03:58:40 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.3-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 03:58:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204831 Andrey V. Elsukov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ae@FreeBSD.org, | |bms@FreeBSD.org --- Comment #1 from Andrey V. Elsukov --- It looks like the router, that sent general query uses very small "Maximum Response Delay" for such number of groups - 125 milliseconds. Is it possible to increase it? What is the system and software used on this router? FreeBSD limits the burst of replies to 4 packets, thereafter not yet sent packets will be send only after ~500 ms delay. Since response delay is very small, probably router just doesn't wait all packets? -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Mon Nov 30 09:08:16 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6ECF3A3C427 for ; Mon, 30 Nov 2015 09:08:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 401801F00 for ; Mon, 30 Nov 2015 09:08:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tAU98Gf6074750 for ; Mon, 30 Nov 2015 09:08:16 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 204831] mld_v2 listener report does not report all active groups to the router Date: Mon, 30 Nov 2015 09:08:16 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.3-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: scheffler@beuth-hochschule.de X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 09:08:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204831 scheffler@beuth-hochschule.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |scheffler@beuth-hochschule. | |de --- Comment #2 from scheffler@beuth-hochschule.de --- Andrey, are you sure you are reading the traces correctly? 1.) Maximum Response Code (Delay) is set to 10000 (10s) by the router. Which is the default value given by RFC3810. 2.) The Query Intervall (QQIC) is set to the (default) value of 125, but the unit of this value is seconds. The router is a Cisco 2811 running IOS 15.1-4.M10, the latest IOS for this platform supported by Cisco. The router has a basic MC configuration, no timer values have been changed from the default. The behaviour starts as soon as I enable 'IPv6 multicast-routing'. I also reproduced the behaviour on a 2901. Your description of 4-packet burts makes sense - I was wondering about the 500ms delay between packet groups. The 510 groups need 8 packets to report. So, the kernel should stop after the second packet group (having reported all 510 groups to the router for this reporting period). However, it does not! The trace clearly shows that it keeps on reporting the same groups over and over again until it suddenly starts losing groups from the report. So to me it looks like 2 bugs: 1.) Reporting should stop after having reported all 510 groups. 2.) We should not lose groups from the report which are still active. In the meantime I found a Linux-Box to run my MC code on and connected it to the very same router. Here the behaviour is very different. The router sends a General Query very 125 seconds. Linux reports the 510 groups (using 8 packets) and stays silent until it receives the next General Query. It also never reports less than the full 510 groups. If you think it helps, I can also attach the Linux-trace. Thomas -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Mon Nov 30 09:17:21 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 68152A3C65F for ; Mon, 30 Nov 2015 09:17:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 31369145B for ; Mon, 30 Nov 2015 09:17:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tAU9HL1u044519 for ; Mon, 30 Nov 2015 09:17:21 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 204831] mld_v2 listener report does not report all active groups to the router Date: Mon, 30 Nov 2015 09:17:21 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.3-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 09:17:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204831 --- Comment #3 from Andrey V. Elsukov --- (In reply to scheffler from comment #2) > are you sure you are reading the traces correctly? > > 1.) Maximum Response Code (Delay) is set to 10000 (10s) by the router. Which > is the default value given by RFC3810. Ah, yes, you are right. I read it incorrectly. > 2.) The Query Intervall (QQIC) is set to the (default) value of 125, but the > unit of this value is seconds. > > The router is a Cisco 2811 running IOS 15.1-4.M10, the latest IOS for this > platform supported by Cisco. The router has a basic MC configuration, no > timer values have been changed from the default. The behaviour starts as > soon as I enable 'IPv6 multicast-routing'. I also reproduced the behaviour > on a 2901. > > Your description of 4-packet burts makes sense - I was wondering about the > 500ms delay between packet groups. The 510 groups need 8 packets to report. > So, the kernel should stop after the second packet group (having reported > all 510 groups to the router for this reporting period). However, it does > not! Yes it looks strange to me too. But I think it should repeat these packets once again due to QRV equal to 2. > The trace clearly shows that it keeps on reporting the same groups over and > over again until it suddenly starts losing groups from the report. > So to me it looks like 2 bugs: > 1.) Reporting should stop after having reported all 510 groups. > 2.) We should not lose groups from the report which are still active. > > In the meantime I found a Linux-Box to run my MC code on and connected it to > the very same router. Here the behaviour is very different. The router sends > a General Query very 125 seconds. Linux reports the 510 groups (using 8 > packets) and stays silent until it receives the next General Query. It also > never reports less than the full 510 groups. > If you think it helps, I can also attach the Linux-trace. Yes, it is interesting. Thanks. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Mon Nov 30 09:22:58 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DF570A3C90F for ; Mon, 30 Nov 2015 09:22:58 +0000 (UTC) (envelope-from daniel.bilik@neosystem.cz) Received: from mail.neosystem.cz (mail.neosystem.cz [94.23.169.88]) (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 A4A2B1A9B; Mon, 30 Nov 2015 09:22:57 +0000 (UTC) (envelope-from daniel.bilik@neosystem.cz) Received: from mail.neosystem.cz (unknown [127.0.10.15]) by mail.neosystem.cz (Postfix) with ESMTP id 6855CBD24; Mon, 30 Nov 2015 10:22:49 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.neosystem.cz Received: from iron.sn.neosystem.cz (unknown [IPv6:2001:41d0:2:5ab8::100:107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.neosystem.cz (Postfix) with ESMTPSA id CB775BD1E; Mon, 30 Nov 2015 10:22:48 +0100 (CET) Date: Mon, 30 Nov 2015 10:18:38 +0100 From: Daniel Bilik To: Julian Elischer Cc: freebsd-net@freebsd.org Subject: Re: Outgoing packets being sent via wrong interface Message-Id: <20151130101838.e59be3db0eb3922d87544b16@neosystem.cz> In-Reply-To: <56597CB5.7030307@freebsd.org> References: <20151120155511.5fb0f3b07228a0c829fa223f@neosystem.org> <20151120163431.3449a473db9de23576d3a4b4@neosystem.org> <20151121212043.GC2307@vega.codepro.be> <20151122130240.165a50286cbaa9288ffc063b@neosystem.cz> <20151125092145.e93151af70085c2b3393f149@neosystem.cz> <20151125122033.GB41119@in-addr.com> <20151127101349.752c94090e78ca68cf0f81fc@neosystem.org> <56597CB5.7030307@freebsd.org> X-Mailer: Sylpheed 3.4.3 (GTK+ 2.24.28; amd64-portbld-freebsd10.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 09:22:59 -0000 On Sat, 28 Nov 2015 18:06:45 +0800 Julian Elischer wrote: > next time it happens try flushing the arp table. Just tried... arp -d -a ... didn't help. Followed by refreshing default route, which solved it again. -- Dan From owner-freebsd-net@freebsd.org Mon Nov 30 09:28:31 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A00ACA3CAED for ; Mon, 30 Nov 2015 09:28:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8B7F81E1E for ; Mon, 30 Nov 2015 09:28:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tAU9SVHq065713 for ; Mon, 30 Nov 2015 09:28:31 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 204831] mld_v2 listener report does not report all active groups to the router Date: Mon, 30 Nov 2015 09:28:31 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.3-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 09:28:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204831 --- Comment #4 from Andrey V. Elsukov --- It looks I was wrong again: "Therefore, to enhance protocol robustness, in spite of the possible unreliability of message exchanges, messages are retransmitted several times. Furthermore, timers are set so as to take into account the possible message losses, and to wait for retransmissions. Periodical General Queries and Current State Reports do not apply this rule, in order not to overload the link; it is assumed that in general these messages do not generate state changes, their main purpose being to refresh existing state." So, it shouldn't repeat these packets. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Mon Nov 30 09:32:45 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3C180A3CC87 for ; Mon, 30 Nov 2015 09:32:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 272CF11C5 for ; Mon, 30 Nov 2015 09:32:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tAU9WjaG077898 for ; Mon, 30 Nov 2015 09:32:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 204831] mld_v2 listener report does not report all active groups to the router Date: Mon, 30 Nov 2015 09:32:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.3-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: scheffler@beuth-hochschule.de X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 09:32:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204831 --- Comment #5 from scheffler@beuth-hochschule.de --- (In reply to Andrey V. Elsukov from comment #4) Correct. Repeated transmission is only expected for 'state change reports'. Otherwise section 9.4 applies and takes care of lost reports: http://tools.ietf.org/html/rfc3810#section-9.4 I will attach the Linux trace in a minute... -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Mon Nov 30 09:38:19 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 74A7DA3CDD7 for ; Mon, 30 Nov 2015 09:38:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 605AA1333 for ; Mon, 30 Nov 2015 09:38:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tAU9cJiO085446 for ; Mon, 30 Nov 2015 09:38:19 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 204831] mld_v2 listener report does not report all active groups to the router Date: Mon, 30 Nov 2015 09:38:19 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.3-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: scheffler@beuth-hochschule.de X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 09:38:19 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204831 --- Comment #6 from scheffler@beuth-hochschule.de --- Created attachment 163679 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=163679&action=edit Wireshark trace from Linux system This trace shows the mldv2 traffic between a Linux system (running the same MC code) and a similarily configured Cisco router. (It is not exactly the same router as in the FreeBSD case, because I am not in the lab right now. But this should not matter...). -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Mon Nov 30 09:41:43 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D05A3A3CFB6 for ; Mon, 30 Nov 2015 09:41:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BBF811921 for ; Mon, 30 Nov 2015 09:41:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tAU9fh3v091971 for ; Mon, 30 Nov 2015 09:41:43 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 204831] mld_v2 listener report does not report all active groups to the router Date: Mon, 30 Nov 2015 09:41:43 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.3-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ae@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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 09:41:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204831 Andrey V. Elsukov changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-net@FreeBSD.org |ae@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Mon Nov 30 15:47:38 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11AA1A3D573 for ; Mon, 30 Nov 2015 15:47:38 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DAECD150A for ; Mon, 30 Nov 2015 15:47:37 +0000 (UTC) (envelope-from julian@freebsd.org) 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.15.2/8.15.2) with ESMTPSA id tAUFlODQ001347 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 30 Nov 2015 07:47:28 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: Outgoing packets being sent via wrong interface To: Daniel Bilik References: <20151120155511.5fb0f3b07228a0c829fa223f@neosystem.org> <20151120163431.3449a473db9de23576d3a4b4@neosystem.org> <20151121212043.GC2307@vega.codepro.be> <20151122130240.165a50286cbaa9288ffc063b@neosystem.cz> <20151125092145.e93151af70085c2b3393f149@neosystem.cz> <20151125122033.GB41119@in-addr.com> <20151127101349.752c94090e78ca68cf0f81fc@neosystem.org> <56597CB5.7030307@freebsd.org> <20151130101838.e59be3db0eb3922d87544b16@neosystem.cz> Cc: freebsd-net@freebsd.org From: Julian Elischer Message-ID: <565C6F86.7090108@freebsd.org> Date: Mon, 30 Nov 2015 23:47:18 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151130101838.e59be3db0eb3922d87544b16@neosystem.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 15:47:38 -0000 On 30/11/2015 5:18 PM, Daniel Bilik wrote: > On Sat, 28 Nov 2015 18:06:45 +0800 > Julian Elischer wrote: > >> next time it happens try flushing the arp table. > Just tried... > > arp -d -a > > ... didn't help. Followed by refreshing default route, which solved it ok next time try netstat -raAnW before and after maybe we can spot at difference. > again. > > -- > Dan > From owner-freebsd-net@freebsd.org Mon Nov 30 16:09:32 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24B99A3DB00 for ; Mon, 30 Nov 2015 16:09:32 +0000 (UTC) (envelope-from elof2@sentor.se) Received: from smtp-out.sentor.se (smtp-out.sentor.se [176.124.225.2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DD8EF12A3 for ; Mon, 30 Nov 2015 16:09:31 +0000 (UTC) (envelope-from elof2@sentor.se) Received: from localhost (localhost [127.0.0.1]) by farmermaggot.shire.sentor.se (Postfix) with ESMTP id ED957B61D233 for ; Mon, 30 Nov 2015 17:09:28 +0100 (CET) Date: Mon, 30 Nov 2015 17:09:28 +0100 (CET) From: elof2@sentor.se To: freebsd-net Subject: Re: ngrep/ixgbe bpf bug In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 16:09:32 -0000 No one has a theory? /Elof On Thu, 5 Nov 2015, elof2@sentor.se wrote: > > Hi all! > > Why don't ngrep work on ix interfaces? > > > It shows nice values if I sniff on other interfaces, e.g. igb0 and > bridge0: > > # ngrep -d igb0 "q" ip > I see some matching packets. Everything looks good. > > # netstat -B > Pid Netif Flags Recv Drop Match Sblen Hblen Command > 1800 igb0 p--s--- 135 0 129 380 0 ngrep > The BPF stats show Recv and Match values. Good. > > > # ngrep -d bridge0 "q" ip > I see some matching packets. Good. > > # netstat -B > Pid Netif Flags Recv Drop Match Sblen Hblen Command > 1901 bridge0 p--s--- 661897 0 659170 425606 0 ngrep > Again, the BPF stats show Recv and Match values. Good. > > > > However, if I sniff on an ix interface: > > # ngrep -d ix1 "q" ip > I get no matching packets! > > # netstat -B > Pid Netif Flags Recv Drop Match Sblen Hblen Command > 1816 ix1 p--s--- 45340 0 0 0 0 ngrep > ^^^ > ...and the BPF stats always show zero Matches. > > > Bug in the ixgbe driver or in ngrep? > > /Elof > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@freebsd.org Mon Nov 30 16:16:49 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 76BE4A3DCC3 for ; Mon, 30 Nov 2015 16:16:49 +0000 (UTC) (envelope-from elof2@sentor.se) Received: from smtp-out.sentor.se (smtp-out.sentor.se [176.124.225.2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2FAED1947; Mon, 30 Nov 2015 16:16:48 +0000 (UTC) (envelope-from elof2@sentor.se) Received: from localhost (localhost [127.0.0.1]) by farmermaggot.shire.sentor.se (Postfix) with ESMTP id 9358DB61D233; Mon, 30 Nov 2015 17:07:22 +0100 (CET) Date: Mon, 30 Nov 2015 17:07:22 +0100 (CET) From: elof2@sentor.se To: Christian Peron cc: freebsd-net , "Alexander V. Chernikov" Subject: Re: netstat -B "Recv" In-Reply-To: <884C10B2-9C17-44C6-81AC-1C56548FE31D@sqrt.ca> Message-ID: References: <111891446726660@web29h.yandex.ru> <884C10B2-9C17-44C6-81AC-1C56548FE31D@sqrt.ca> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 16:16:49 -0000 Hi Christian. So... Any news regarding this? Should I create a bugzilla so the ball don't get dropped? /Elof On Fri, 6 Nov 2015, Christian Peron wrote: > It needs to get fixed.. let me generate a patch for you and you can test it. > > >> On Nov 5, 2015, at 8:51 AM, elof2@sentor.se wrote: >> >> On Thu, 5 Nov 2015, Alexander V. Chernikov wrote: >> >>> >>> >>> 04.11.2015, 19:55, "elof2@sentor.se" : >>>> Hi! >>>> >>>> Question: >>>> What do the Recv column in 'netstat -B' show? >>>> >>>> I thought it was tha amount of packets received, but appaently not so. >>>> >>>> I send 2000000 packets from a tcpreplay machine to a receiving machine. >>>> I do it a few times. >>>> >>>> On the receiver I see: >>>> netstat -in >>>> Name Mtu Network Address Ipkts Ierrs Idrop Opkts >>>> Oerrs Coll >>>> ix0 1500 0c:c4:7a:58:e2:3c 0 0 0 0 >>>> 0 0 >>>> ix1 1500 0c:c4:7a:58:e2:3d 6000000 0 0 0 >>>> 0 0 >>>> >>>> and then >>>> netstat -in >>>> Name Mtu Network Address Ipkts Ierrs Idrop Opkts >>>> Oerrs Coll >>>> ix0 1500 0c:c4:7a:58:e2:3c 0 0 0 0 >>>> 0 0 >>>> ix1 1500 0c:c4:7a:58:e2:3d 8000000 0 0 0 >>>> 0 0 >>>> >>>> So 6000000 has increased to 8000000. Good. >>>> >>>> However, 'netstat -B' show: >>>> Pid Netif Flags Recv Drop Match Sblen Hblen Command >>>> 25553 mon0 p--s--- 1996862 0 2000000 0 0 tcpdump >>>> >>>> How can the "Recv" be *lower* than "Match"? >>>> 1996862 < 2000000. >>>> >>>> For every new run (fast and slow) I get the same results, slightly less >>>> than 2000000 Recv. >>>> >>>> What am I missing? >>> Well, "Recv" is read from d->bd_rcount which is not per-cpu counter and is incrementing unlocked. >>> On the other hand, "Match" increases when filter returned match condition and we (w)locked bpf descriptor, so this one is accurate. >> >> Ah. Thanks. >> >> >> Will you make a bugzilla out of this? Or should I? Or is it not interesting enough to fix? >> >> /Elof >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@freebsd.org Mon Nov 30 21:23:36 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 450C0A3DC6D; Mon, 30 Nov 2015 21:23:36 +0000 (UTC) (envelope-from dudu.meyer@gmail.com) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0D57A128A; Mon, 30 Nov 2015 21:23:36 +0000 (UTC) (envelope-from dudu.meyer@gmail.com) Received: by obbnk6 with SMTP id nk6so138396413obb.2; Mon, 30 Nov 2015 13:23:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=B3m4+Q//6CS2fMcR17SUi5XsGVb1E6tcC1MbYNOYsZc=; b=kc1GzlZXrH1tHedARr6StZWfApr86RwnDy1Ajw9VoCZ0jUQPWxcyGfKmY7K8II4n3K BPNnNybldIqg7hETqmrhFoGNpYHKz/URvcDU0Ja4ci1FzUHIYHYZSvjtzNS//jT4K/Ug iIF0RMJA1ZP83g84YviazOT8MHU5DzOai6mKdIqtTXeQYTs3cJTRmkHwMVQ8h6iEeeW7 IwRvLUOfuumq3sbbh0z5ncZAwPQG+5e2BMRpEMmUXGV7CdxIFoOT0fnpFC/s7GreDZEx F7Qn3V+4u/4vCYakP2q5j5Ji4qzqwRmagtYUNs7fhqKctpoZnKqUnwoqb1/9/IusfeyW PB9g== MIME-Version: 1.0 X-Received: by 10.60.92.138 with SMTP id cm10mr44848386oeb.64.1448918615468; Mon, 30 Nov 2015 13:23:35 -0800 (PST) Received: by 10.182.116.167 with HTTP; Mon, 30 Nov 2015 13:23:35 -0800 (PST) In-Reply-To: References: Date: Mon, 30 Nov 2015 19:23:35 -0200 Message-ID: Subject: Re: Netmap vale + bridge on -STABLE From: Eduardo Meyer To: freebsd-stable@freebsd.org, "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 21:23:36 -0000 OK, I am running current now. If I run: tcpdump -ni vale0:2 -w /tmp/2 & tcpdump -ni vale0:1 -w /tmp/1 & pkt-gen -i vale0:0 -f tx I get half of all generated traffic on /tmp/2 and the other half of /tmp/1. I guess this is the expected behavior, different from what I expected. Is that the expected behavior? Is there a way to create a VALE port that will mirror the traffic? Or is there a way to run the pcap enabled application (tcpdump in this case) in netmap mode (pcap netmap) without removing the packets from the ring? Say, I want to be table to run: pkt-gen -i vale0:0 -f tx pkt-gen -i vale0:1 -f rx tcpdump -ni vale0:2 -w /tmp/1 and have a copy of all traffic on /tmp/1. In the above tests, if I run: pkt-gen -i vale0:0 -f tx pkt-gen -i vale0:1 -f rx tcpdump -ni vale0:1 -w /tmp/1 tcpdump will remove as many packets as it can from the ring, and rx rates will drop to 0 or close to it (the ramaining rate is what tcpdump can not process) thank you On Fri, Nov 27, 2015 at 3:50 PM, Eduardo Meyer wrote: > Hello, > > I am trying to achieve a netmap based bridge which will allow me to > capture packets from it, say, I want to bridge ix0 + ix1 and be able to > tcpdump it (in fact I want to run other applications which are netmap > aware). > > Should it work on -STABLE? Because as far as I remember I could make it > work in the past, and some other people[1] had some success doing it too > (at least the vale + wire bridge part) > > What I get is an error while opening ix0 connected to vale: > > # ./vale-ctl > 257.967371 bdg_ctl [148] bridge:0 port:0 vale0:fnm0 > 257.967399 bdg_ctl [148] bridge:0 port:1 vale0:ids0 > 257.967407 bdg_ctl [148] bridge:0 port:2 vale0:ix0 > 257.967414 bdg_ctl [148] bridge:1 port:0 vale1:fnm1 > 257.967419 bdg_ctl [148] bridge:1 port:1 vale1:ids1 > 257.967428 bdg_ctl [148] bridge:1 port:2 vale1:ix1 > > # ./bridge -i netmap:ix0 -i netmap:ix1 > ./bridge built Nov 26 2015 19:18:34 > 268.504787 nm_open [839] NIOCREGIF failed: Device busy ix0 > 268.504800 main [233] cannot open netmap:ix0 > Exit 1 > > How can I achieve it? Is it ok to expect to have another netmap capable > software (say like suricata) to use this other vale connected port? Or will > both software (bridge and suricata) concurrently copy and remove packets > from netmap rings and therefore mess up the whole thing? > > [1] > https://lists.openinfosecfoundation.org/pipermail/oisf-users/2015-October/005310.html > > > -- > =========== > Eduardo Meyer > pessoal: dudu.meyer@gmail.com > profissional: ddm.farmaciap@saude.gov.br > -- =========== Eduardo Meyer pessoal: dudu.meyer@gmail.com profissional: ddm.farmaciap@saude.gov.br From owner-freebsd-net@freebsd.org Mon Nov 30 21:58:28 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6F66EA3DE39 for ; Mon, 30 Nov 2015 21:58:28 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (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 474701ACD for ; Mon, 30 Nov 2015 21:58:28 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 83C6E205F8 for ; Mon, 30 Nov 2015 16:58:26 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute4.internal (MEProxy); Mon, 30 Nov 2015 16:58:26 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=1Yy9dfuSkVOcmAXclkOzJu0HT9A=; b=Zr1vA xDQvVpVyl9Nd8Y8owvDmaYI7J2ehuxjG73qkoPOnFHAQNQsbY2g/4VQoMz914mwG d2bYB2hM0ZnASzqlcTqW517fSdHZV6EYmOD3ge/BFysVr2yEJlxEsLxBgE06Lo6q +bjoFxjEAUD37r5i5eNVWNatX09MU3Wzo1XK94= Received: by web3.nyi.internal (Postfix, from userid 99) id 5D65A103295; Mon, 30 Nov 2015 16:58:26 -0500 (EST) Message-Id: <1448920706.962818.454005905.61CF9154@webmail.messagingengine.com> X-Sasl-Enc: PO/FNSpwuRBQK26xQejbDZMuNJzvKT/WqdWs8J03ygEH 1448920706 From: Mark Felder To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-227d657c Subject: IPFW blocked my IPv6 NTP traffic Date: Mon, 30 Nov 2015 15:58:26 -0600 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 21:58:28 -0000 I'm hoping someone can explain what happened here and this isn't a bug, but if it is a bug I'll gladly open a PR. I noticed in my ipfw logs that I was getting a log of "DENY" entries for an NTP server Nov 30 13:35:16 gw kernel: ipfw: 4540 Deny UDP [2604:a880:800:10::bc:c004]:123 [2001:470:1f11:1e8::2]:58285 in via gif0 Strange... I looked at ntpq output and sure enough I was trying to communicate with that server. But why was it getting blocked? I don't have a rule to allow IPv4 input from source port 123. I expected IPFW to handle this for me. I know UDP is stateless, but firewalls are usually able to "keep state" for UDP. I looked at my v4 rules which and I have keep-state on there: # Allow all outgoing, skip to NAT ###################################### $cmd 01300 skipto 5000 tcp from any to any out via $pif $ks $cmd 01310 skipto 5000 udp from any to any out via $pif $ks $cmd 01320 skipto 5000 icmp from any to any out via $pif ###################################### I noticed my outbound IPv6 didn't have $ks for udp, so I added it. However, that had no effect. The solution was to add an incoming rule: $cmd 03755 allow udp from any to any src-port 123 in via $pif6 $ks This seems wrong. Thoughts? -- Mark Felder ports-secteam member feld@FreeBSD.org From owner-freebsd-net@freebsd.org Mon Nov 30 22:26:07 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DAC28A3D4B8 for ; Mon, 30 Nov 2015 22:26:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BCE1D1EDF for ; Mon, 30 Nov 2015 22:26:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tAUMQ7wI011562 for ; Mon, 30 Nov 2015 22:26:07 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 178079] [tcp] Switching TCP CC algorithm panics on sparc64 with a complaint from the MMU Date: Mon, 30 Nov 2015 22:26:07 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mmoll@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc resolution bug_status 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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 22:26:08 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=178079 Michael Moll changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mmoll@freebsd.org Resolution|--- |FIXED Status|In Progress |Closed --- Comment #3 from Michael Moll --- not reproducible anymore with a fresh -CURRENT on sparc64 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Mon Nov 30 22:28:58 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B3F54A3D517 for ; Mon, 30 Nov 2015 22:28:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A06B21FEC for ; Mon, 30 Nov 2015 22:28:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tAUMSw5t015141 for ; Mon, 30 Nov 2015 22:28:58 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 189219] [dummynet] [patch] using dummynet on sparc64 and configuring a pipe is an insta-panic Date: Mon, 30 Nov 2015 22:28:58 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mmoll@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 22:28:58 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189219 Michael Moll changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mmoll@freebsd.org --- Comment #2 from Michael Moll --- still reproducible with a fresh -CURRENT on sparc64, could a net person have a look into that patch? -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Mon Nov 30 22:45:28 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0ECADA3D87A for ; Mon, 30 Nov 2015 22:45:28 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (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 DFCB31C95; Mon, 30 Nov 2015 22:45:27 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id C3.D8.09556.681DC565; Mon, 30 Nov 2015 14:45:26 -0800 (PST) X-AuditID: 11973e15-f79be6d000002554-d8-565cd186721f Received: from [17.149.224.20] (Unknown_Domain [17.149.224.20]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id E0.E2.05180.681DC565; Mon, 30 Nov 2015 14:45:26 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: IPFW blocked my IPv6 NTP traffic From: Charles Swiger In-Reply-To: <1448920706.962818.454005905.61CF9154@webmail.messagingengine.com> Date: Mon, 30 Nov 2015 14:45:26 -0800 Cc: freebsd-net@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <86B10B8B-6A12-41AB-9C19-17F7E65CDBB4@mac.com> References: <1448920706.962818.454005905.61CF9154@webmail.messagingengine.com> To: Mark Felder X-Mailer: Apple Mail (2.3112) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOLMWRmVeSWpSXmKPExsUi2FAYrNt2MSbMYGGbrsWuvoVsFh92tDM5 MHnM+DSfJYAxissmJTUnsyy1SN8ugSvj6qHbTAUHeSr2b7rO1MD4iLOLkZNDQsBEYu3EuWwQ tpjEhXvrgWwuDiGBvYwS5+YvZYIpWvRkHSNEYiqTxKWunywgCWYBLYkb/16CFfEK6EmcWLWb FcQWFtCVOHntEVANBwebgJrEhIk8ICangL/E5G4HkAoWAVWJz/+Os4OEmQWkJRb8iYEYqC2x bOFrZoiBVhJHP14AGygk4CexdMtfsEUiAkoSiz6cZoe4TFZi34YFUOe/ZZXYe0ZuAqPQLCS3 zUJy2ywkKxYwMq9iFMpNzMzRzcwz00ssKMhJ1UvOz93ECArZ6XaiOxjPrLI6xCjAwajEwyux NiZMiDWxrLgy9xCjNAeLkjjvkhKgkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsZJnXt1LEJP Vkw+FeQq3Nt7pfPA7eOMycGm91WC4t+fNj7w6WfWO58mi2+Olae32/xht1DKX1nrK3ArJzgz LWYNg/DXtzJu23nS/7+NWigob7XwgPtbPZ1FVacDL4eacfYduDBPPKAkQPBtvNyeRZ6eLxJ+ Tr7FbBc6P6jZ16Tp+xEfodP705VYijMSDbWYi4oTAVT8c2s6AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUiOPWBiG7bxZgwg0+bNC129S1ks/iwo53J gcljxqf5LAGMUVw2Kak5mWWpRfp2CVwZVw/dZio4yFOxf9N1pgbGR5xdjJwcEgImEouerGOE sMUkLtxbz9bFyMUhJDCVSeJS108WkASzgJbEjX8vmUBsXgE9iROrdrOC2MICuhInrz0CquHg YBNQk5gwkQfE5BTwl5jc7QBSwSKgKvH533F2kDCzgLTEgj8xEAO1JZYtfM0MMdBK4ujHC2AD hQT8JJZu+Qu2SERASWLRh9PsEJfJSuzbsIBtAiP/LCT3zEJyzywkYxcwMq9iFChKzUmsNNZL LCjISdVLzs/dxAgKsobC4B2Mf5ZZHWIU4GBU4uGVWBsTJsSaWFZcmXuIUYKDWUmE99UeoBBv SmJlVWpRfnxRaU5q8SFGaQ4WJXHeilX+YUIC6YklqdmpqQWpRTBZJg5OqQbGMO08jZtid6ND gt3nlMWaiWZp9TLssGjh9tjzIvjLqzz55PTnJz9e41RaoZs8yezQj+aH2l72yedqOeX2HVyq eT/70Aqthgnzrqblntnw5Jjgh9uCtqa1G16+i0syM1jw/Z7Z7JkNN4p2MoR+6+ENjRdgXMzF bxaUYnWt/Oi6Jfc+PjJc9nWGEktxRqKhFnNRcSIAZ8xG0i4CAAA= X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 22:45:28 -0000 Hi, Mark-- On Nov 30, 2015, at 1:58 PM, Mark Felder wrote: > [ ... ] > I noticed my outbound IPv6 didn't have $ks for udp, so I added it. > However, that had no effect. The solution was to add an incoming rule: >=20 > $cmd 03755 allow udp from any to any src-port 123 in via $pif6 $ks >=20 > This seems wrong. Thoughts? Yes, someone can perform a UDP scan of your network using source port of 123. That's generally not a huge risk, but that very much depends on what is binding to UDP protocol on your network. (Note that using a UDP source port of 53 for scans is very popular as = well.) I don't know whether UDP keepstate is broken for IPv6, but freebsd-ipfw = folks might have more info. Also note that performing stateful filtering of DNS and UDP traffic can be a bad idea because of DoS potential. Consider something like this: # allow DNS,NTP queries out in the world add pass udp from MYNET HIPORTS to any 53,123 add pass udp from any 53,123 to MYNET HIPORTS add pass udp from any 53,123 to any 53,123 # traceroute add pass udp from any HIPORTS to any 33434-33523 # add any other expected UDP traffic here, ie: # add pass udp from any 123,HIPORTS to MYNTPSERVER 123 # add pass udp from MYNTPSERVER 123 to any 123,HIPORTS # and then log outgoing and block unexpected incoming UDP traffic add pass log udp from MYNET to any add unreach filter-prohib log udp from any to any Regards, --=20 -Chuck PS: Yes, I think firewall_flags=3D"-p cpp" is a reasonable choice, but = /bin/sh is just fine if you prefer that. :-)= From owner-freebsd-net@freebsd.org Mon Nov 30 23:50:33 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C1D0A3C779 for ; Mon, 30 Nov 2015 23:50:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E7FFB139F for ; Mon, 30 Nov 2015 23:50:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tAUNoWnv010639 for ; Mon, 30 Nov 2015 23:50:32 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 189219] [dummynet] [patch] using dummynet on sparc64 and configuring a pipe is an insta-panic Date: Mon, 30 Nov 2015 23:50:32 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: glebius@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 23:50:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189219 Gleb Smirnoff changed: What |Removed |Added ---------------------------------------------------------------------------- CC|re@FreeBSD.org |glebius@FreeBSD.org --- Comment #3 from Gleb Smirnoff --- IMHO, this bug doesn't deserve re@ special attention. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Tue Dec 1 00:32:27 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CAFA0A3A450 for ; Tue, 1 Dec 2015 00:32:27 +0000 (UTC) (envelope-from nathan@vuid.com) Received: from mail.7sq.com.au (mail.7sq.com.au [119.148.74.199]) (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 764381A4E for ; Tue, 1 Dec 2015 00:32:26 +0000 (UTC) (envelope-from nathan@vuid.com) Received: from localhost (localhost [127.0.0.1]) by mail.7sq.com.au (Postfix) with ESMTP id 8D95D2C323B for ; Tue, 1 Dec 2015 10:27:50 +1000 (AEST) Received: from mail.7sq.com.au ([127.0.0.1]) by localhost (mail.7sq.com.au [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 6eVoIAQRXs8q for ; Tue, 1 Dec 2015 10:27:50 +1000 (AEST) Received: from localhost (localhost [127.0.0.1]) by mail.7sq.com.au (Postfix) with ESMTP id 67AAD2C327A for ; Tue, 1 Dec 2015 10:27:50 +1000 (AEST) X-Virus-Scanned: amavisd-new at mail.7sq.com.au Received: from mail.7sq.com.au ([127.0.0.1]) by localhost (mail.7sq.com.au [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3glKrx88cuge for ; Tue, 1 Dec 2015 10:27:50 +1000 (AEST) Received: from [192.168.156.153] (reddog2.lnk.telstra.net [110.142.196.96]) by mail.7sq.com.au (Postfix) with ESMTPSA id 29FFD2C323B for ; Tue, 1 Dec 2015 10:27:50 +1000 (AEST) From: Nathan Aherne Subject: vimage and jail networking Message-Id: <8538858C-BE02-489A-BC1B-2315AC18AD3F@vuid.com> Date: Tue, 1 Dec 2015 10:32:24 +1000 To: freebsd-net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 00:32:27 -0000 Hi Everyone! I am having trouble getting my head around vimage and jail networking. I = would like for my jails to have private IPs (10.0.0.0/24) and only use a = single public IP. I am having a hard time finding tutorials or information on how to = structure my network. My first thoughts were to clone the loopback = interface (have the jails on it) but then I get lost with how to = configure the bridging. I found this tutorial on the subject - = http://wiki.polymorf.fr/index.php/Howto:FreeBSD_jail_vnet = but I am = unsure how the bridging works as the bridge interface does not seem to = be bridged to anything. I would really appreciate it if someone could point me in the correct = direction. Regards, Nathan= From owner-freebsd-net@freebsd.org Tue Dec 1 03:45:35 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9C228A3D0BF for ; Tue, 1 Dec 2015 03:45:35 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 76FBC1F2C for ; Tue, 1 Dec 2015 03:45:35 +0000 (UTC) (envelope-from julian@freebsd.org) 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.15.2/8.15.2) with ESMTPSA id tB13jSUQ003880 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 30 Nov 2015 19:45:31 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: vimage and jail networking To: Nathan Aherne , freebsd-net@freebsd.org References: <8538858C-BE02-489A-BC1B-2315AC18AD3F@vuid.com> From: Julian Elischer Message-ID: <565D17D2.1090007@freebsd.org> Date: Tue, 1 Dec 2015 11:45:22 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <8538858C-BE02-489A-BC1B-2315AC18AD3F@vuid.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 03:45:35 -0000 On 1/12/2015 8:32 AM, Nathan Aherne wrote: > Hi Everyone! > > I am having trouble getting my head around vimage and jail networking. I would like for my jails to have private IPs (10.0.0.0/24) and only use a single public IP. > > I am having a hard time finding tutorials or information on how to structure my network. My first thoughts were to clone the loopback interface (have the jails on it) but then I get lost with how to configure the bridging. I found this tutorial on the subject - http://wiki.polymorf.fr/index.php/Howto:FreeBSD_jail_vnet but I am unsure how the bridging works as the bridge interface does not seem to be bridged to anything. > > I would really appreciate it if someone could point me in the correct direction. It seems to me you are thinking of it in the wrong way. think of the vimage jails as completely separate machines. they are connected by virtual point-to-point networks (if you use epair) or by a virtual ethernet (if you use netgraph). how would you do it if you had one nat router and a bunch of real machines on the 10 network behind it? check out, amongst other things: http://devinteske.com/wp/vimage-jails-on-freebsd-8/ also please first look on your own machine in /usr/share/examples/netgraph and especially look at the virtual.chain and virtual.lan examples I think they do exactly what you want. > > Regards, > > Nathan > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@freebsd.org Tue Dec 1 05:48:31 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6A93CA3EE51 for ; Tue, 1 Dec 2015 05:48:31 +0000 (UTC) (envelope-from nathan@vuid.com) Received: from mail.7sq.com.au (mail.7sq.com.au [119.148.74.199]) (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 168451456; Tue, 1 Dec 2015 05:48:30 +0000 (UTC) (envelope-from nathan@vuid.com) Received: from localhost (localhost [127.0.0.1]) by mail.7sq.com.au (Postfix) with ESMTP id C05032C3241; Tue, 1 Dec 2015 15:43:53 +1000 (AEST) Received: from mail.7sq.com.au ([127.0.0.1]) by localhost (mail.7sq.com.au [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id YGmm1JZ6vwAY; Tue, 1 Dec 2015 15:43:53 +1000 (AEST) Received: from localhost (localhost [127.0.0.1]) by mail.7sq.com.au (Postfix) with ESMTP id 817F12C3319; Tue, 1 Dec 2015 15:43:53 +1000 (AEST) X-Virus-Scanned: amavisd-new at mail.7sq.com.au Received: from mail.7sq.com.au ([127.0.0.1]) by localhost (mail.7sq.com.au [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xt5hV78Tt43u; Tue, 1 Dec 2015 15:43:53 +1000 (AEST) Received: from [192.168.156.153] (reddog2.lnk.telstra.net [110.142.196.96]) by mail.7sq.com.au (Postfix) with ESMTPSA id A700B2C3241; Tue, 1 Dec 2015 15:43:52 +1000 (AEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: vimage and jail networking From: Nathan Aherne In-Reply-To: <565D17D2.1090007@freebsd.org> Date: Tue, 1 Dec 2015 15:48:25 +1000 Cc: freebsd-net@freebsd.org Message-Id: <5101F264-B28E-42D0-8C21-623D6C01DFB6@vuid.com> References: <8538858C-BE02-489A-BC1B-2315AC18AD3F@vuid.com> <565D17D2.1090007@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.2104) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 05:48:31 -0000 Thank you for helping me to understand vimage better Julian! I have read = all three links you posted a number of times. I use iocage for jail management and it uses epair. =46rom your comments = it seems you recommend netgraph? This is the link to the iocage image instructions - = https://iocage.readthedocs.org/en/latest/networking.html#configuring-a-vne= t-jail = . It seems that iocage does a number of things automatically or = at least I am still confused on how to use iocage and vimage to have = multiple jails share a single public (external) IP. I will continue to = read the links you sent me in the hopes that the ahah moment comes to = me. Regards, Nathan > On 1 Dec 2015, at 1:45 pm, Julian Elischer wrote: >=20 > On 1/12/2015 8:32 AM, Nathan Aherne wrote: >> Hi Everyone! >>=20 >> I am having trouble getting my head around vimage and jail = networking. I would like for my jails to have private IPs (10.0.0.0/24) = and only use a single public IP. >>=20 >> I am having a hard time finding tutorials or information on how to = structure my network. My first thoughts were to clone the loopback = interface (have the jails on it) but then I get lost with how to = configure the bridging. I found this tutorial on the subject - = http://wiki.polymorf.fr/index.php/Howto:FreeBSD_jail_vnet = but I am = unsure how the bridging works as the bridge interface does not seem to = be bridged to anything. >>=20 >> I would really appreciate it if someone could point me in the correct = direction. >=20 > It seems to me you are thinking of it in the wrong way. > think of the vimage jails as completely separate machines. > they are connected by virtual point-to-point networks (if you use = epair) or by a virtual ethernet (if you use netgraph). >=20 > how would you do it if you had one nat router and a bunch of real = machines on the 10 network behind it? >=20 > check out, amongst other things: = http://devinteske.com/wp/vimage-jails-on-freebsd-8/ > also please first look on your own machine in = /usr/share/examples/netgraph and especially look at the > virtual.chain and virtual.lan examples > I think they do exactly what you want. >=20 >=20 >>=20 >> Regards, >>=20 >> Nathan >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to = "freebsd-net-unsubscribe@freebsd.org" >>=20 >=20 From owner-freebsd-net@freebsd.org Tue Dec 1 06:25:29 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 081C1A3E9C2 for ; Tue, 1 Dec 2015 06:25:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E8DC21C30 for ; Tue, 1 Dec 2015 06:25:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tB16PSkU098369 for ; Tue, 1 Dec 2015 06:25:28 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 189219] [dummynet] [patch] using dummynet on sparc64 and configuring a pipe is an insta-panic Date: Tue, 01 Dec 2015 06:25:28 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: hiren@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 06:25:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189219 Hiren Panchasara changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |luigi@FreeBSD.org --- Comment #4 from Hiren Panchasara --- Adding dummynet author/maintainer. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Tue Dec 1 06:58:49 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 045E4A3D1A5 for ; Tue, 1 Dec 2015 06:58:49 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from forward14h.cmail.yandex.net (forward14h.cmail.yandex.net [IPv6:2a02:6b8:0:f35::9f]) (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 B1B001A19 for ; Tue, 1 Dec 2015 06:58:48 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from web11h.yandex.ru (web11h.yandex.ru [84.201.186.40]) by forward14h.cmail.yandex.net (Yandex) with ESMTP id 97EAB20D57; Tue, 1 Dec 2015 09:58:36 +0300 (MSK) Received: from 127.0.0.1 (localhost [127.0.0.1]) by web11h.yandex.ru (Yandex) with ESMTP id D7FCA1225CD; Tue, 1 Dec 2015 09:58:35 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfw.ru; s=mail; t=1448953116; bh=zs9xAr34S8gVYrFlDjwT6SXJwdCB9l5AQIkHKVIL61s=; h=From:To:In-Reply-To:References:Subject:Date; b=Zf/0lnmhH8m4zZTBkfYTgbIRcOVSsIiBvsGprOwbfTCj9RnWg8HxVV6EJVmmfn2OV wIMl1etOuzUxw7fNR/2pUQ31lg+F6I15hemFumvp3CLK+qQtDDmtQ3y4u44GQfbsyF TvNL4vBQKH4cLYDpmwxeWPFyXesM7ihZ25bSHg24= Received: by web11h.yandex.ru with HTTP; Tue, 01 Dec 2015 09:58:35 +0300 From: Alexander V. Chernikov To: "elof2@sentor.se" , freebsd-net In-Reply-To: References: Subject: Re: ngrep/ixgbe bpf bug MIME-Version: 1.0 Message-Id: <944961448953115@web11h.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Tue, 01 Dec 2015 09:58:35 +0300 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=koi8-r X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 06:58:49 -0000 Do you have vlans on top of ixgbe? And actually I wonder what does tcpdump show for the same expression. ( and tcpdump -i ixX -lnes0 might provide good traces on what is going on) 30.11.2015, 19:09, "elof2@sentor.se" : > No one has a theory? > > /Elof > > On Thu, 5 Nov 2015, elof2@sentor.se wrote: > >> šHi all! >> >> šWhy don't ngrep work on ix interfaces? >> >> šIt shows nice values if I sniff on other interfaces, e.g. igb0 and >> šbridge0: >> >> š# ngrep -d igb0 "q" ip >> šI see some matching packets. Everything looks good. >> >> š# netstat -B >> ššPid Netif Flags Recv Drop Match Sblen Hblen Command >> š1800 igb0 p--s--- 135 0 129 380 0 ngrep >> šThe BPF stats show Recv and Match values. Good. >> >> š# ngrep -d bridge0 "q" ip >> ššI see some matching packets. Good. >> >> š# netstat -B >> ššPid Netif Flags Recv Drop Match Sblen Hblen Command >> š1901 bridge0 p--s--- 661897 0 659170 425606 0 ngrep >> šAgain, the BPF stats show Recv and Match values. Good. >> >> šHowever, if I sniff on an ix interface: >> >> š# ngrep -d ix1 "q" ip >> šI get no matching packets! >> >> š# netstat -B >> ššPid Netif Flags Recv Drop Match Sblen Hblen Command >> š1816 ix1 p--s--- 45340 0 0 0 0 ngrep >> šššššššššššššššššššššššššššššššššššššššššššššššš^^^ >> š...and the BPF stats always show zero Matches. >> >> šBug in the ixgbe driver or in ngrep? >> >> š/Elof >> >> š_______________________________________________ >> šfreebsd-net@freebsd.org mailing list >> šhttps://lists.freebsd.org/mailman/listinfo/freebsd-net >> šTo unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@freebsd.org Tue Dec 1 07:07:35 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E59D9A3DFE5 for ; Tue, 1 Dec 2015 07:07:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B96F110E8 for ; Tue, 1 Dec 2015 07:07:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tB177ZOq026869 for ; Tue, 1 Dec 2015 07:07:35 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 199287] Missing TCP retransmit timer reset Date: Tue, 01 Dec 2015 07:07:35 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: hiren@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 07:07:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199287 Hiren Panchasara changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hiren@FreeBSD.org --- Comment #1 from Hiren Panchasara --- (In reply to sebastian.huber from comment #0) Hi Sebastian, A few questions: 1) Is this a theory or are you seeing a real problem in your setup? 2) if answer to 1) is yes, does it only happen when you drop acks? 3) when you say the connection is dropped finally by tcp_Timer_rexmt(), is it because it has backed off > TCP_MAXRXTSHIFT times? (because timer was never reset as per the theory?) About resetting the retransmit timer, don't we do that in tcp_do_segment() at following place? /* * If all outstanding data is acked, stop retransmit * timer and remember to restart (more output or persist). * If there is more data to be acked, restart retransmit * timer, using current (possibly backed-off) value. */ if (th->th_ack == tp->snd_max) { tcp_timer_activate(tp, TT_REXMT, 0); needoutput = 1; } else if (!tcp_timer_active(tp, TT_PERSIST)) tcp_timer_activate(tp, TT_REXMT, tp->t_rxtcur); Or am I missing something? I'd love to understand this situation better. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Tue Dec 1 07:49:53 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1C922A3D2DD for ; Tue, 1 Dec 2015 07:49:53 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 98D0E1E38; Tue, 1 Dec 2015 07:49:52 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by lffu14 with SMTP id u14so229235475lff.1; Mon, 30 Nov 2015 23:49: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=BEZpkqlQIjEiY9BbIxlGyuAs2im7W2pkrH9yxOi8weE=; b=eNFFmGNxufMiv/S0+2bq1c/XKvCb+lFDb8Z6FiHE/fYWLOh9x4qjSC4VC2g3D256F0 222v2b62HdIAUbIAWbJEov9RtPDsx2c277j0z6JM9/p6B4q4Zu/NVlgZQ+hY/Xm+MYaf 6ggm6lChJIlC8nbbVMyOTS538zrepGacz4MzlCLqnuXj0PaFQJMxnWtiKlvLH6VhsANq qM741FUSe72eU5mmIcTO2Fy0IWB/H/vmy91QqrrUqvtvZQshCSpbHVwI/wh66XwGmvom Bhdb0JfSHrTsQZvkUCACHT0X53rP1kHOdr1KEr1XrNHtokRw8Kekxmc27dtyqPSrzro+ sdLw== MIME-Version: 1.0 X-Received: by 10.112.199.194 with SMTP id jm2mr21676163lbc.109.1448956190161; Mon, 30 Nov 2015 23:49:50 -0800 (PST) Received: by 10.25.141.129 with HTTP; Mon, 30 Nov 2015 23:49:50 -0800 (PST) In-Reply-To: <5101F264-B28E-42D0-8C21-623D6C01DFB6@vuid.com> References: <8538858C-BE02-489A-BC1B-2315AC18AD3F@vuid.com> <565D17D2.1090007@freebsd.org> <5101F264-B28E-42D0-8C21-623D6C01DFB6@vuid.com> Date: Tue, 1 Dec 2015 08:49:50 +0100 Message-ID: Subject: Re: vimage and jail networking From: Ben Woods To: Nathan Aherne Cc: Julian Elischer , freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 07:49:53 -0000 On 1 December 2015 at 06:48, Nathan Aherne wrote > Thank you for helping me to understand vimage better Julian! I have read > all three links you posted a number of times. > > I use iocage for jail management and it uses epair. From your comments it > seems you recommend netgraph? > > This is the link to the iocage image instructions - > https://iocage.readthedocs.org/en/latest/networking.html#configuring-a-vnet-jail > < > https://iocage.readthedocs.org/en/latest/networking.html#configuring-a-vnet-jail>. > It seems that iocage does a number of things automatically or at least I am > still confused on how to use iocage and vimage to have multiple jails share > a single public (external) IP. I will continue to read the links you sent > me in the hopes that the ahah moment comes to me. > > Regards, > > Nathan > The public IP will be configured on whichever device you have connected to the internet. Normally that is a physically separate edge firewall/router. It has the public IP and performs NAT for any devices on the LAN that talk to the internet. This configuration has nothing to do with your jails - it is required for any computers on your LAN which talk to the internet. The jails are then each configured with a LAN address (10.0.0.0/8 range if you like). When they need to talk to the internet, they will go via their default route, which is normally your edge firewall/router, and is often given a 10.0.0.1 address (but could be anything you like). The router will perform the NAT, and if you want the jails to host service listening for internet traffic, you will also need to configure port forwarding on the router to send traffic on the relevant ports to your jails on their LAN IP address. Note that if your router happens to be the host running the jails, this doesn't change any of the above. Regards, Ben From owner-freebsd-net@freebsd.org Tue Dec 1 08:08:57 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2BDDAA3DBF1 for ; Tue, 1 Dec 2015 08:08:57 +0000 (UTC) (envelope-from daniel.bilik@neosystem.cz) Received: from mail.neosystem.cz (mail.neosystem.cz [IPv6:2001:41d0:2:5ab8::10:15]) (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 B1C0A1A85; Tue, 1 Dec 2015 08:08:56 +0000 (UTC) (envelope-from daniel.bilik@neosystem.cz) Received: from mail.neosystem.cz (unknown [127.0.10.15]) by mail.neosystem.cz (Postfix) with ESMTP id 7F92C38A; Tue, 1 Dec 2015 09:08:53 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.neosystem.cz Received: from dragon.sn.neosystem.cz (unknown [IPv6:2001:41d0:2:5ab8::100:101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.neosystem.cz (Postfix) with ESMTPSA id 08DF6377; Tue, 1 Dec 2015 09:08:51 +0100 (CET) Date: Tue, 1 Dec 2015 09:03:32 +0100 From: Daniel Bilik To: Julian Elischer Cc: freebsd-net@freebsd.org Subject: Re: Outgoing packets being sent via wrong interface Message-Id: <20151201090332.09b038935b8eabf33288c24c@neosystem.cz> In-Reply-To: <565C6F86.7090108@freebsd.org> References: <20151120155511.5fb0f3b07228a0c829fa223f@neosystem.org> <20151120163431.3449a473db9de23576d3a4b4@neosystem.org> <20151121212043.GC2307@vega.codepro.be> <20151122130240.165a50286cbaa9288ffc063b@neosystem.cz> <20151125092145.e93151af70085c2b3393f149@neosystem.cz> <20151125122033.GB41119@in-addr.com> <20151127101349.752c94090e78ca68cf0f81fc@neosystem.org> <56597CB5.7030307@freebsd.org> <20151130101838.e59be3db0eb3922d87544b16@neosystem.cz> <565C6F86.7090108@freebsd.org> X-Mailer: Sylpheed 3.4.3 (GTK+ 2.24.28; x86_64-portbld-dragonfly4.3) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Tue__1_Dec_2015_09_03_32_+0100_6x3skEPKjLDdKR5L" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 08:08:57 -0000 This is a multi-part message in MIME format. --Multipart=_Tue__1_Dec_2015_09_03_32_+0100_6x3skEPKjLDdKR5L Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 30 Nov 2015 23:47:18 +0800 Julian Elischer wrote: > ok next time try > netstat -raAnW before and after Attached ("Internet6" part removed to reduce noise). > maybe we can spot at difference. According to diff(1), entries differ only by "Use" column between .pre and .during. The .post output shows the state after "refreshing" default route, so there are also different addresses for those entries. -- Dan --Multipart=_Tue__1_Dec_2015_09_03_32_+0100_6x3skEPKjLDdKR5L Content-Type: text/plain; name="netstat.pre" Content-Disposition: attachment; filename="netstat.pre" Content-Transfer-Encoding: 7bit Routing tables Internet: Address Destination Gateway Flags Use Mtu Netif Expire fffff80001bc8c98 (32) fffff800123cb0f8 : fffff8003102ee40 mk = fffff800716c4c20 {(0), (0) } fffff800123cb0f8 (33) fffff80001bc8c68 : fffff8003102f030 fffff80001bc8c68 (root node) => fffff8003100f000 default 82.x.y.29 UGS 1897332 1500 re0 mask (0) mk = fffff800716c4c20 {(0), (0) } fffff8003102f030 (34) fffff800123c8cb0 : fffff8003102f1c0 fffff800123c8cb0 (35) fffff800123c8c80 : fffff800123c8d78 fffff800123c8c80 78.x.y.5 82.x.y.29 UGHS 1849 1500 re0 fffff800123c8d78 (36) fffff800123c8e40 : fffff800123c8d48 fffff800123c8e40 (54) fffff800123c8e10 : fffff8003102ef08 fffff800123c8e10 28.x.y.16 82.x.y.29 UGHS 26170748 1500 re0 fffff8003102ef08 (62) fffff8003102f000 : fffff8003102eed8 mk = fffff800122c24e0 {(61), , (255) ffff ffff fff8 } fffff8003102f000 82.x.y.0/24 link#2 U 0 1500 re0 mask (255) ffff ffff fff8 mk = fffff800122c24e0 {(61), , (255) ffff ffff fff8 } fffff8003102eed8 82.x.y.50 link#2 UHS 0 16384 lo0 fffff800123c8d48 94.x.y.14 82.x.y.29 UGHS 6455 1500 re0 fffff8003102f1c0 (52) fffff800123cb0c8 : fffff8003100f288 fffff800123cb0c8 127.0.0.1 link#1 UH 341205 16384 lo0 fffff8003100f288 (60) fffff8003102f0f8 : fffff8003100f258 fffff8003102f0f8 (61) fffff8003102f190 : fffff8003102f0c8 fffff8003102f190 127.0.10.1 link#1 UH 4 16384 lo0 fffff8003102f0c8 127.0.10.5 link#1 UH 226889 16384 lo0 fffff8003100f258 127.0.10.15 link#1 UH 2042240 16384 lo0 fffff8003102ee40 (34) fffff800123de5a8 : fffff80001bc8cc8 fffff800123de5a8 (49) fffff800123de418 : fffff800123de4e0 fffff800123de418 (54) fffff800123de3e8 : fffff8003102ed78 fffff800123de3e8 192.168.1.0/24 192.168.123.1 UGS 8798807 1500 tap0 mask (255) ffff ffff ff fffff8003102ed78 (60) fffff8003100f1c0 : fffff800123debe8 mk = fffff800122c25e0 {(56), , (255) ffff ffff ff } fffff8003100f1c0 (61) fffff8003102ebe8 : fffff8003100f190 fffff8003102ebe8 (63) fffff8003102ee10 : fffff8003102ebb8 fffff8003102ee10 192.168.2.0/24 link#3 U 306549997 1500 re1 mask (255) ffff ffff ff mk = fffff800122c25e0 {(56), , (255) ffff ffff ff } fffff8003102ebb8 192.168.2.1 link#3 UHS 863741 16384 lo0 fffff8003100f190 192.168.2.5 link#3 UHS 1542937 16384 lo0 fffff800123debe8 (61) fffff8003102ed48 : fffff800123debb8 fffff8003102ed48 192.168.2.8 link#3 UHS 476942 16384 lo0 fffff800123debb8 192.168.2.15 link#3 UHS 4475968 16384 lo0 fffff800123de4e0 (62) fffff800123de578 : fffff800123de4b0 mk = fffff800c54c1f40 {(56), , (255) ffff ffff ff } fffff800123de578 192.168.123.0/24 link#5 U 50633 1500 tap0 mask (255) ffff ffff ff mk = fffff800c54c1f40 {(56), , (255) ffff ffff ff } fffff800123de4b0 192.168.123.2 link#5 UHS 0 16384 lo0 fffff80001bc8cc8 (root node) --Multipart=_Tue__1_Dec_2015_09_03_32_+0100_6x3skEPKjLDdKR5L Content-Type: text/plain; name="netstat.during" Content-Disposition: attachment; filename="netstat.during" Content-Transfer-Encoding: 7bit Routing tables Internet: Address Destination Gateway Flags Use Mtu Netif Expire fffff80001bc8c98 (32) fffff800123cb0f8 : fffff8003102ee40 mk = fffff800716c4c20 {(0), (0) } fffff800123cb0f8 (33) fffff80001bc8c68 : fffff8003102f030 fffff80001bc8c68 (root node) => fffff8003100f000 default 82.x.y.29 UGS 2388496 1500 re0 mask (0) mk = fffff800716c4c20 {(0), (0) } fffff8003102f030 (34) fffff800123c8cb0 : fffff8003102f1c0 fffff800123c8cb0 (35) fffff800123c8c80 : fffff800123c8d78 fffff800123c8c80 78.x.y.5 82.x.y.29 UGHS 1902 1500 re0 fffff800123c8d78 (36) fffff800123c8e40 : fffff800123c8d48 fffff800123c8e40 (54) fffff800123c8e10 : fffff8003102ef08 fffff800123c8e10 28.x.y.16 82.x.y.29 UGHS 26578601 1500 re0 fffff8003102ef08 (62) fffff8003102f000 : fffff8003102eed8 mk = fffff800122c24e0 {(61), , (255) ffff ffff fff8 } fffff8003102f000 82.x.y.0/24 link#2 U 0 1500 re0 mask (255) ffff ffff fff8 mk = fffff800122c24e0 {(61), , (255) ffff ffff fff8 } fffff8003102eed8 82.x.y.50 link#2 UHS 0 16384 lo0 fffff800123c8d48 94.x.y.14 82.x.y.29 UGHS 6549 1500 re0 fffff8003102f1c0 (52) fffff800123cb0c8 : fffff8003100f288 fffff800123cb0c8 127.0.0.1 link#1 UH 349078 16384 lo0 fffff8003100f288 (60) fffff8003102f0f8 : fffff8003100f258 fffff8003102f0f8 (61) fffff8003102f190 : fffff8003102f0c8 fffff8003102f190 127.0.10.1 link#1 UH 4 16384 lo0 fffff8003102f0c8 127.0.10.5 link#1 UH 232518 16384 lo0 fffff8003100f258 127.0.10.15 link#1 UH 2063363 16384 lo0 fffff8003102ee40 (34) fffff800123de5a8 : fffff80001bc8cc8 fffff800123de5a8 (49) fffff800123de418 : fffff800123de4e0 fffff800123de418 (54) fffff800123de3e8 : fffff8003102ed78 fffff800123de3e8 192.168.1.0/24 192.168.123.1 UGS 9201461 1500 tap0 mask (255) ffff ffff ff fffff8003102ed78 (60) fffff8003100f1c0 : fffff800123debe8 mk = fffff800122c25e0 {(56), , (255) ffff ffff ff } fffff8003100f1c0 (61) fffff8003102ebe8 : fffff8003100f190 fffff8003102ebe8 (63) fffff8003102ee10 : fffff8003102ebb8 fffff8003102ee10 192.168.2.0/24 link#3 U 309252264 1500 re1 mask (255) ffff ffff ff mk = fffff800122c25e0 {(56), , (255) ffff ffff ff } fffff8003102ebb8 192.168.2.1 link#3 UHS 882251 16384 lo0 fffff8003100f190 192.168.2.5 link#3 UHS 1578738 16384 lo0 fffff800123debe8 (61) fffff8003102ed48 : fffff800123debb8 fffff8003102ed48 192.168.2.8 link#3 UHS 487703 16384 lo0 fffff800123debb8 192.168.2.15 link#3 UHS 4513032 16384 lo0 fffff800123de4e0 (62) fffff800123de578 : fffff800123de4b0 mk = fffff800c54c1f40 {(56), , (255) ffff ffff ff } fffff800123de578 192.168.123.0/24 link#5 U 53749 1500 tap0 mask (255) ffff ffff ff mk = fffff800c54c1f40 {(56), , (255) ffff ffff ff } fffff800123de4b0 192.168.123.2 link#5 UHS 0 16384 lo0 fffff80001bc8cc8 (root node) --Multipart=_Tue__1_Dec_2015_09_03_32_+0100_6x3skEPKjLDdKR5L Content-Type: text/plain; name="netstat.post" Content-Disposition: attachment; filename="netstat.post" Content-Transfer-Encoding: 7bit Routing tables Internet: Address Destination Gateway Flags Use Mtu Netif Expire fffff80001bc8c98 (32) fffff800123cb0f8 : fffff8003102ee40 mk = fffff800c287df40 {(0), (0) } fffff800123cb0f8 (33) fffff80001bc8c68 : fffff8003102f030 fffff80001bc8c68 (root node) => fffff800123de320 default 82.x.y.29 UGS 1709 1500 re0 mask (0) mk = fffff800c287df40 {(0), (0) } fffff8003102f030 (34) fffff800123c8cb0 : fffff8003102f1c0 fffff800123c8cb0 (35) fffff800123c8c80 : fffff800123c8d78 fffff800123c8c80 78.x.y.5 82.x.y.29 UGHS 1902 1500 re0 fffff800123c8d78 (36) fffff800123c8e40 : fffff800123c8d48 fffff800123c8e40 (54) fffff800123c8e10 : fffff8003102ef08 fffff800123c8e10 28.x.y.16 82.x.y.29 UGHS 26580176 1500 re0 fffff8003102ef08 (62) fffff8003102f000 : fffff8003102eed8 mk = fffff800122c24e0 {(61), , (255) ffff ffff fff8 } fffff8003102f000 82.x.y.0/24 link#2 U 0 1500 re0 mask (255) ffff ffff fff8 mk = fffff800122c24e0 {(61), , (255) ffff ffff fff8 } fffff8003102eed8 82.x.y.50 link#2 UHS 0 16384 lo0 fffff800123c8d48 94.x.y.14 82.x.y.29 UGHS 6549 1500 re0 fffff8003102f1c0 (52) fffff800123cb0c8 : fffff8003100f288 fffff800123cb0c8 127.0.0.1 link#1 UH 349094 16384 lo0 fffff8003100f288 (60) fffff8003102f0f8 : fffff8003100f258 fffff8003102f0f8 (61) fffff8003102f190 : fffff8003102f0c8 fffff8003102f190 127.0.10.1 link#1 UH 4 16384 lo0 fffff8003102f0c8 127.0.10.5 link#1 UH 232518 16384 lo0 fffff8003100f258 127.0.10.15 link#1 UH 2063427 16384 lo0 fffff8003102ee40 (34) fffff800123de5a8 : fffff80001bc8cc8 fffff800123de5a8 (49) fffff800123de418 : fffff800123de4e0 fffff800123de418 (54) fffff800123de3e8 : fffff8003102ed78 fffff800123de3e8 192.168.1.0/24 192.168.123.1 UGS 9203026 1500 tap0 mask (255) ffff ffff ff fffff8003102ed78 (60) fffff8003100f1c0 : fffff800123debe8 mk = fffff800122c25e0 {(56), , (255) ffff ffff ff } fffff8003100f1c0 (61) fffff8003102ebe8 : fffff8003100f190 fffff8003102ebe8 (63) fffff8003102ee10 : fffff8003102ebb8 fffff8003102ee10 192.168.2.0/24 link#3 U 309273008 1500 re1 mask (255) ffff ffff ff mk = fffff800122c25e0 {(56), , (255) ffff ffff ff } fffff8003102ebb8 192.168.2.1 link#3 UHS 882317 16384 lo0 fffff8003100f190 192.168.2.5 link#3 UHS 1578782 16384 lo0 fffff800123debe8 (61) fffff8003102ed48 : fffff800123debb8 fffff8003102ed48 192.168.2.8 link#3 UHS 487720 16384 lo0 fffff800123debb8 192.168.2.15 link#3 UHS 4513175 16384 lo0 fffff800123de4e0 (62) fffff800123de578 : fffff800123de4b0 mk = fffff800c54c1f40 {(56), , (255) ffff ffff ff } fffff800123de578 192.168.123.0/24 link#5 U 53756 1500 tap0 mask (255) ffff ffff ff mk = fffff800c54c1f40 {(56), , (255) ffff ffff ff } fffff800123de4b0 192.168.123.2 link#5 UHS 0 16384 lo0 fffff80001bc8cc8 (root node) --Multipart=_Tue__1_Dec_2015_09_03_32_+0100_6x3skEPKjLDdKR5L-- From owner-freebsd-net@freebsd.org Tue Dec 1 08:21:26 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B3C21A3DEE3 for ; Tue, 1 Dec 2015 08:21:26 +0000 (UTC) (envelope-from artemrts@ukr.net) Received: from frv191.fwdcdn.com (frv191.fwdcdn.com [212.42.77.191]) (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 6DEB51EA5 for ; Tue, 1 Dec 2015 08:21:25 +0000 (UTC) (envelope-from artemrts@ukr.net) Received: from [10.10.1.23] (helo=frv199.fwdcdn.com) by frv191.fwdcdn.com with esmtp ID 1a3gBe-0005aw-Kh for freebsd-net@freebsd.org; Tue, 01 Dec 2015 10:21:22 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:To:Subject:From:Date; bh=FcLT0EHbsyFaMXzIVL8LKArVq3oJs6VRa1sx63G/5XI=; b=gmaCZC35eCoL6xLnBUJBLTtJwFZ8lZtGfbavP1+2n2gdWgLH0EkxqUwLCxApqqVyj8KPHw4gtQ6yNvBaYzgOJ0oRQbBGKTmZKYOaLYrjSjYhODFpb1QHat6GIkEA3V3VdY62NGGbEMGIkZQdg5c0kWgryMFduXThUqvBoQyUoMo=; Received: from [10.10.10.34] (helo=frv34.fwdcdn.com) by frv199.fwdcdn.com with smtp ID 1a3gBV-00057M-Qb for freebsd-net@freebsd.org; Tue, 01 Dec 2015 10:21:13 +0200 Date: Tue, 01 Dec 2015 10:21:13 +0200 From: wishmaster Subject: Re[2]: vimage and jail networking To: freebsd-net@freebsd.org X-Mailer: mail.ukr.net 5.0 Message-Id: <1448957193.218781171.7af7wapw@frv34.fwdcdn.com> In-Reply-To: <5101F264-B28E-42D0-8C21-623D6C01DFB6@vuid.com> References: <8538858C-BE02-489A-BC1B-2315AC18AD3F@vuid.com> <565D17D2.1090007@freebsd.org> <5101F264-B28E-42D0-8C21-623D6C01DFB6@vuid.com> X-Reply-Action: reply Received: from artemrts@ukr.net by frv34.fwdcdn.com; Tue, 01 Dec 2015 10:21:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary Content-Disposition: inline X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 08:21:26 -0000 Hi, Nathan. > Thank you for helping me to understand vimage better Julian! I have read all three links you posted a number of times. > > I use iocage for jail management and it uses epair. From your comments it seems you recommend netgraph? I thing epair is more easy than netgraph for you. So, read manual page for epair and below small example. /etc/rc.conf cloned_interfaces="epair999 epair1 epair2 epair3 epair4" ifconfig_epair999a="inet 192.168.254.253 netmask 255.255.255.252" # this is for "base" jail ifconfig_epair1a="inet 192.168.254.1 netmask 255.255.255.252" ifconfig_epair2a="inet 192.168.254.5 netmask 255.255.255.252" ifconfig_epair3a="inet 192.168.254.9 netmask 255.255.255.252" ifconfig_epair4a="inet 192.168.254.13 netmask 255.255.255.252" ifconfig_epair5a="inet 192.168.254.17 netmask 255.255.255.252" /etc/jail.conf must have configuration for each jail, below one example cctv { host.hostname = cctv; jid = 5; name = cctv; path = "/home/jails/cctv"; mount.fstab = "/etc/fstab.${name}"; vnet; vnet.interface = "epair5b"; exec.start = "/bin/sh /etc/rc"; exec.prestop = ""; exec.stop = "/bin/sh /etc/rc.shutdown"; securelevel = 2; devfs_ruleset = 4; mount.devfs; persist; #allowed allow.set_hostname = "false"; allow.sysvipc = "false"; allow.raw_sockets = "false"; allow.chflags = "false"; allow.mount = "false"; allow.mount.devfs = "false"; allow.mount.nullfs = "false"; allow.mount.procfs = "false"; allow.mount.zfs = "false"; allow.quotas = "false"; allow.socket_af = "false"; } IPFW disabled in jails. All filtering, port forwarding and NAT performs in the base system as with normal computer in your LAN. Very interesting concept of one base jail (base system and software) and number of "light" jails (running services and configurations). This is very convenient, but complex enough. You may try, at first, with standard jail described in the handbook. -- Cheers, Vitaliy From owner-freebsd-net@freebsd.org Tue Dec 1 08:22:01 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 15B1DA3DF17 for ; Tue, 1 Dec 2015 08:22:01 +0000 (UTC) (envelope-from artemrts@ukr.net) Received: from frv191.fwdcdn.com (frv191.fwdcdn.com [212.42.77.191]) (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 CC3F91F9A for ; Tue, 1 Dec 2015 08:22:00 +0000 (UTC) (envelope-from artemrts@ukr.net) Received: from [10.10.2.23] (helo=frv198.fwdcdn.com) by frv191.fwdcdn.com with esmtp ID 1a3ftf-000Nlz-M9 for freebsd-net@freebsd.org; Tue, 01 Dec 2015 10:02:47 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:To:Subject:From:Date; bh=XoBUokSEck9xBpB4t0etApPRx487vbpvnQBYDN1LXSo=; b=gnvPvXXy/tHnnkMav8IuPgRWOd3h/tZYMpD4qBlxZk0aUeG9jQDYdSM8NMKvl+hXSgYsa7na26fNrfnl+OaNt+frZnBXz3S1IAlwFmK9LyMAaSkSNWe1t9LpIa1Bn55DEqrW0Hv4aYN/+dKh2OkdB+e3pcEjo3IAQWorCN+N4fY=; Received: from [10.10.10.34] (helo=frv34.fwdcdn.com) by frv198.fwdcdn.com with smtp ID 1a3ftU-000NTX-4o for freebsd-net@freebsd.org; Tue, 01 Dec 2015 10:02:36 +0200 Date: Tue, 01 Dec 2015 10:02:35 +0200 From: wishmaster Subject: Re: IPFW blocked my IPv6 NTP traffic To: freebsd-net@freebsd.org X-Mailer: mail.ukr.net 5.0 Message-Id: <1448956697.854911427.15is5btc@frv34.fwdcdn.com> In-Reply-To: <1448920706.962818.454005905.61CF9154@webmail.messagingengine.com> References: <1448920706.962818.454005905.61CF9154@webmail.messagingengine.com> X-Reply-Action: reply Received: from artemrts@ukr.net by frv34.fwdcdn.com; Tue, 01 Dec 2015 10:02:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary Content-Disposition: inline X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 08:22:01 -0000 Hi, Mark. > I'm hoping someone can explain what happened here and this isn't a bug, > but if it is a bug I'll gladly open a PR. > > I noticed in my ipfw logs that I was getting a log of "DENY" entries for > an NTP server > > Nov 30 13:35:16 gw kernel: ipfw: 4540 Deny UDP > [2604:a880:800:10::bc:c004]:123 [2001:470:1f11:1e8::2]:58285 in via gif0 > > Strange... I looked at ntpq output and sure enough I was trying to > communicate with that server. But why was it getting blocked? I don't > have a rule to allow IPv4 input from source port 123. I expected IPFW to > handle this for me. I know UDP is stateless, but firewalls are usually > able to "keep state" for UDP. I looked at my v4 rules which and I have > keep-state on there: > > # Allow all outgoing, skip to NAT > ###################################### > $cmd 01300 skipto 5000 tcp from any to any out via $pif $ks > $cmd 01310 skipto 5000 udp from any to any out via $pif $ks > $cmd 01320 skipto 5000 icmp from any to any out via $pif > ###################################### > > I noticed my outbound IPv6 didn't have $ks for udp, so I added it. > However, that had no effect. The solution was to add an incoming rule: > > $cmd 03755 allow udp from any to any src-port 123 in via $pif6 $ks > > This seems wrong. Thoughts? > What is your 5000 rule? In general on public interface you should: $cmd 12345 allow log all from any to me 123 $ks And for outgoing traffic just: $cmd 1234 allow log all from me to any $ks This works for me. -- Cheers, Vitaliy From owner-freebsd-net@freebsd.org Tue Dec 1 08:30:43 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2975CA350A2 for ; Tue, 1 Dec 2015 08:30:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 14E9D142F for ; Tue, 1 Dec 2015 08:30:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tB18Ug5m032133 for ; Tue, 1 Dec 2015 08:30:42 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193724] [panic] [tcp] in tcp_discardcb (/usr/src/sys/netinet/tcp_subr.c:929) Date: Tue, 01 Dec 2015 08:30:43 +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 Only Me X-Bugzilla-Who: hiren@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 08:30:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193724 Hiren Panchasara changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hiren@FreeBSD.org --- Comment #2 from Hiren Panchasara --- Palle, Isn't this the one fixed by jch@? If so, we can close this bug. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Tue Dec 1 08:45:17 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B9463A35527 for ; Tue, 1 Dec 2015 08:45:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A0B9C1C1B for ; Tue, 1 Dec 2015 08:45:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tB18jHuk063189 for ; Tue, 1 Dec 2015 08:45:17 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 174535] [tcp] TCP fast retransmit feature works strange Date: Tue, 01 Dec 2015 08:45:17 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: hiren@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 08:45:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=174535 Hiren Panchasara changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hiren@FreeBSD.org --- Comment #2 from Hiren Panchasara --- Unsure if you are still chasing this but I am a bit lost on what you are trying to do. If you are trying to trigger fast-retransmit on 2 dupacks instead of 3, easiest way is to change 'const int tcprexmtthresh = 3' in tcp_input.c About tcpdump showing packet size > MSS, it usually happens with tso/lro. (Also providing actual pcaps help in such situations.) -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Tue Dec 1 09:02:34 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 31549A35C67 for ; Tue, 1 Dec 2015 09:02:34 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0CAA11515 for ; Tue, 1 Dec 2015 09:02:33 +0000 (UTC) (envelope-from julian@freebsd.org) 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.15.2/8.15.2) with ESMTPSA id tB192QSu005032 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 1 Dec 2015 01:02:29 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: vimage and jail networking To: Ben Woods , Nathan Aherne References: <8538858C-BE02-489A-BC1B-2315AC18AD3F@vuid.com> <565D17D2.1090007@freebsd.org> <5101F264-B28E-42D0-8C21-623D6C01DFB6@vuid.com> Cc: freebsd-net@freebsd.org From: Julian Elischer Message-ID: <565D621C.50402@freebsd.org> Date: Tue, 1 Dec 2015 17:02:20 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 09:02:34 -0000 On 1/12/2015 3:49 PM, Ben Woods wrote: > On 1 December 2015 at 06:48, Nathan Aherne > wrote interestingly this is the first time I see this email. I think something blocked he original for me. > > Thank you for helping me to understand vimage better Julian! I > have read all three links you posted a number of times. > I think the example in /usr/share/examples/netgraph actually does all that you want for you.. just edit and run. > > > I use iocage for jail management and it uses epair. From your > comments it seems you recommend netgraph? > no I recommend you use whatever works for you.. :-) epair allows you to connect jails together with point to point links. it is then jsut a routing problem. If you want a bridged solution I think you can combine epair with if_bridge, but haven't tried that myself. you can achieve the exact same with netgraph. netgraph will give you more flexibility but is more 'complex' to drive. On the other hand its designed to be embedded in scripts. So you don't usually have to confront the complexity each time you use it. > > This is the link to the iocage image instructions - > https://iocage.readthedocs.org/en/latest/networking.html#configuring-a-vnet-jail > . > It seems that iocage does a number of things automatically or at > least I am still confused on how to use iocage and vimage to > have multiple jails share a single public (external) IP. I will > continue to read the links you sent me in the hopes that the > ahah moment comes to me. > > Regards, > > Nathan > > > The public IP will be configured on whichever device you have > connected to the internet. Normally that is a physically separate > edge firewall/router. It has the public IP and performs NAT for any > devices on the LAN that talk to the internet. This configuration has > nothing to do with your jails - it is required for any computers on > your LAN which talk to the internet. > > The jails are then each configured with a LAN address (10.0.0.0/8 > range if you like). When they need to talk to > the internet, they will go via their default route, which is > normally your edge firewall/router, and is often given a 10.0.0.1 > address (but could be anything you like). The router will perform > the NAT, and if you want the jails to host service listening for > internet traffic, you will also need to configure port forwarding on > the router to send traffic on the relevant ports to your jails on > their LAN IP address. > > Note that if your router happens to be the host running the jails, > this doesn't change any of the above. yes usually I would have Nat on the outgoing interface of whichever jail isn my 'final router', and all the jails connected together by some bridge construction that has one leg on a second interface in the router jail (maybe the base jail but not necessarily). > > Regards, > Ben From owner-freebsd-net@freebsd.org Tue Dec 1 09:10:32 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 464ECA35E81 for ; Tue, 1 Dec 2015 09:10:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 313251961 for ; Tue, 1 Dec 2015 09:10:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tB19AWXl012426 for ; Tue, 1 Dec 2015 09:10:32 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193724] [panic] [tcp] in tcp_discardcb (/usr/src/sys/netinet/tcp_subr.c:929) Date: Tue, 01 Dec 2015 09:10:32 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: crash X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 09:10:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193724 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |crash -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Tue Dec 1 09:42:01 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7FBE0A3C6FB for ; Tue, 1 Dec 2015 09:42:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B45C19EA for ; Tue, 1 Dec 2015 09:42:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tB19g1Pl060851 for ; Tue, 1 Dec 2015 09:42:01 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193724] [panic] [tcp] in tcp_discardcb (/usr/src/sys/netinet/tcp_subr.c:929) Date: Tue, 01 Dec 2015 09:42:01 +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: crash X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: girgen@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 09:42:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193724 --- Comment #3 from Palle Girgensohn --- (In reply to Hiren Panchasara from comment #2) It is not entirely clear to me that this is the same problem, but it might well be, and if so, it could be marked as a duplicate of PR 203175 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Tue Dec 1 10:22:30 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E0E15A3D050 for ; Tue, 1 Dec 2015 10:22:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CD3471DB1 for ; Tue, 1 Dec 2015 10:22:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tB1AMUw4078570 for ; Tue, 1 Dec 2015 10:22:30 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193724] [panic] [tcp] in tcp_discardcb (/usr/src/sys/netinet/tcp_subr.c:929) Date: Tue, 01 Dec 2015 10:22:30 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: crash X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: see_also 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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 10:22:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193724 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=2031 | |75 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Tue Dec 1 10:22:31 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3EE43A3D052 for ; Tue, 1 Dec 2015 10:22:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 29CA71DB4 for ; Tue, 1 Dec 2015 10:22:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tB1AMVMl078585 for ; Tue, 1 Dec 2015 10:22:31 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 203175] Daily kernel crashes in tcp_twclose
on 10.2-p2 using VIMAGE Date: Tue, 01 Dec 2015 10:22:30 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: crash, needs-qa, patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: mfc-stable9? mfc-stable10? X-Bugzilla-Changed-Fields: see_also 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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 10:22:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203175 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=1937 | |24 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Tue Dec 1 10:24:31 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A02D7A3D103 for ; Tue, 1 Dec 2015 10:24:31 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 750701F0E for ; Tue, 1 Dec 2015 10:24:30 +0000 (UTC) (envelope-from julian@freebsd.org) 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.15.2/8.15.2) with ESMTPSA id tB1AOOFo005348 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 1 Dec 2015 02:24:27 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: Outgoing packets being sent via wrong interface To: Daniel Bilik References: <20151120155511.5fb0f3b07228a0c829fa223f@neosystem.org> <20151120163431.3449a473db9de23576d3a4b4@neosystem.org> <20151121212043.GC2307@vega.codepro.be> <20151122130240.165a50286cbaa9288ffc063b@neosystem.cz> <20151125092145.e93151af70085c2b3393f149@neosystem.cz> <20151125122033.GB41119@in-addr.com> <20151127101349.752c94090e78ca68cf0f81fc@neosystem.org> <56597CB5.7030307@freebsd.org> <20151130101838.e59be3db0eb3922d87544b16@neosystem.cz> <565C6F86.7090108@freebsd.org> <20151201090332.09b038935b8eabf33288c24c@neosystem.cz> Cc: freebsd-net@freebsd.org From: Julian Elischer Message-ID: <565D7552.30806@freebsd.org> Date: Tue, 1 Dec 2015 18:24:18 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151201090332.09b038935b8eabf33288c24c@neosystem.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 10:24:31 -0000 On 1/12/2015 4:03 PM, Daniel Bilik wrote: > On Mon, 30 Nov 2015 23:47:18 +0800 > Julian Elischer wrote: > >> ok next time try >> netstat -raAnW before and after > Attached ("Internet6" part removed to reduce noise). > >> maybe we can spot at difference. > According to diff(1), entries differ only by "Use" column between .pre > and .during. The .post output shows the state after "refreshing" default > route, so there are also different addresses for those entries. so that doesn't tell us much.. I"m as stumped as you are here.. if you reload pf it has no effect? pf is the part of the picture I have no experience with so I'm naturally suspicious of it. have you tried a simple ipfw nat instead? just as a sanity check? something like ipfw nat 1 config if re0 ipfw add 30 nat 1 ip from not me to any out xmit re0 ipfw add 40 nat 1 ip from any to me in recv re0 > > -- > Dan From owner-freebsd-net@freebsd.org Tue Dec 1 11:18:21 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7284EA3DE75 for ; Tue, 1 Dec 2015 11:18:21 +0000 (UTC) (envelope-from daniel.bilik@neosystem.cz) Received: from mail.neosystem.cz (mail.neosystem.cz [IPv6:2001:41d0:2:5ab8::10:15]) (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 33AF81AD3; Tue, 1 Dec 2015 11:18:20 +0000 (UTC) (envelope-from daniel.bilik@neosystem.cz) Received: from mail.neosystem.cz (unknown [127.0.10.15]) by mail.neosystem.cz (Postfix) with ESMTP id 52C84A9D; Tue, 1 Dec 2015 12:18:18 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.neosystem.cz Received: from dragon.sn.neosystem.cz (unknown [IPv6:2001:41d0:2:5ab8::100:101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.neosystem.cz (Postfix) with ESMTPSA id E11C3A97; Tue, 1 Dec 2015 12:18:12 +0100 (CET) Date: Tue, 1 Dec 2015 12:16:45 +0100 From: Daniel Bilik To: Julian Elischer Cc: freebsd-net@freebsd.org Subject: Re: Outgoing packets being sent via wrong interface Message-Id: <20151201121645.dbcf4bf900fd657a6e4ae3b4@neosystem.cz> In-Reply-To: <565D7552.30806@freebsd.org> References: <20151120155511.5fb0f3b07228a0c829fa223f@neosystem.org> <20151120163431.3449a473db9de23576d3a4b4@neosystem.org> <20151121212043.GC2307@vega.codepro.be> <20151122130240.165a50286cbaa9288ffc063b@neosystem.cz> <20151125092145.e93151af70085c2b3393f149@neosystem.cz> <20151125122033.GB41119@in-addr.com> <20151127101349.752c94090e78ca68cf0f81fc@neosystem.org> <56597CB5.7030307@freebsd.org> <20151130101838.e59be3db0eb3922d87544b16@neosystem.cz> <565C6F86.7090108@freebsd.org> <20151201090332.09b038935b8eabf33288c24c@neosystem.cz> <565D7552.30806@freebsd.org> X-Mailer: Sylpheed 3.4.3 (GTK+ 2.24.28; x86_64-portbld-dragonfly4.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 11:18:21 -0000 On Tue, 1 Dec 2015 18:24:18 +0800 Julian Elischer wrote: > if you reload pf it has no effect? > pf is the part of the picture I have no experience with so I'm > naturally suspicious of it. > have you tried a simple ipfw nat instead? just as a sanity check? Well, I have zero experience with ipfw and this is production system with quite complex pf setup. So I don't have enough courage to experiment much there. But next time it happens, I'll try to reload pf rules, and also to disable pf completely - it's acceptable for short period of time, and we'll see if there still are any "private" packets on "public" interface. Thanks for suggestions. -- Dan From owner-freebsd-net@freebsd.org Tue Dec 1 11:22:42 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0997BA3C035 for ; Tue, 1 Dec 2015 11:22:42 +0000 (UTC) (envelope-from elof2@sentor.se) Received: from smtp-out.sentor.se (smtp-out.sentor.se [176.124.225.2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BB47C1DBC for ; Tue, 1 Dec 2015 11:22:41 +0000 (UTC) (envelope-from elof2@sentor.se) Received: from localhost (localhost [127.0.0.1]) by farmermaggot.shire.sentor.se (Postfix) with ESMTP id 87738B61D233; Tue, 1 Dec 2015 12:22:38 +0100 (CET) Date: Tue, 1 Dec 2015 12:22:38 +0100 (CET) From: "elof2@sentor.se" To: "Alexander V. Chernikov" cc: freebsd-net Subject: Re: ngrep/ixgbe bpf bug In-Reply-To: <944961448953115@web11h.yandex.ru> Message-ID: References: <944961448953115@web11h.yandex.ru> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=koi8-r; format=flowed Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 11:22:42 -0000 Yes, 100% of the traffic is vlan-tagged, but I get the same results with: ngrep -d ix1 "q" vlan no matches If I invert the test to show all packets that do not contain "foobar", it still matches 0 packets: ngrep -d ix1 -v "foobar" ix1: no IPv4 address assigned: Can't assign requested address interface: ix1 don't match: foobar ^Cexit 263567 received, 0 dropped So 263567 vlan-tagged packets are received, 0 dropped. There are "q":s in there, and I promise that they don't all contain "foobar". :) If I add -R, to not drop privileges, I get the same result. 'tcpdump -i ix1 -lnes0' show packets just as it should: 12:14:02.113842 28:c0:da:db:c7:40 > 00:e0:20:11:0a:95, ethertype 802.1Q (0x8100), length 139: vlan 123, p 0, ethertype IPv4, 10.123.123.123.993 > 10.321.321.321.50904: Flags [P.], seq 2632602368:2632602437, ack 2214392113, win 8316, options [nop,nop,TS val 3824950099 ecr 179534445], length 69 ...and so on... Everything looks just as expected. #ifconfig ix1 ix1: flags=488c3 metric 0 mtu 1500 options=8403bb ether 0c:c4:7a:58:e2:3d nd6 options=29 media: Ethernet autoselect (10Gbase-T ) status: active Could ngrep fail because of monitor mode? #ifconfig ix1 -monitor #ifconfig ix1 ix1: flags=88c3 metric 0 mtu 1500 options=8403bb ether 0c:c4:7a:58:e2:3d nd6 options=29 media: Ethernet autoselect (10Gbase-T ) status: active #ngrep -d ix1 -v "foobar" ix1: no IPv4 address assigned: Can't assign requested address interface: ix1 don't match: foobar ^Cexit 157082 received, 0 dropped Nope, same-same. Zero BPF matches. #netstat -B Pid Netif Flags Recv Drop Match Sblen Hblen Command 12293 ix1 p--s--- 157082 0 0 0 0 ngrep ^^^^^^ /Elof On Tue, 1 Dec 2015, Alexander V. Chernikov wrote: > Do you have vlans on top of ixgbe? > And actually I wonder what does tcpdump show for the same expression. > ( and tcpdump -i ixX -lnes0 might provide good traces on what is going on) > > 30.11.2015, 19:09, "elof2@sentor.se" : >> No one has a theory? >> >> /Elof >> >> On Thu, 5 Nov 2015, elof2@sentor.se wrote: >> >>> šHi all! >>> >>> šWhy don't ngrep work on ix interfaces? >>> >>> šIt shows nice values if I sniff on other interfaces, e.g. igb0 and >>> šbridge0: >>> >>> š# ngrep -d igb0 "q" ip >>> šI see some matching packets. Everything looks good. >>> >>> š# netstat -B >>> ššPid Netif Flags Recv Drop Match Sblen Hblen Command >>> š1800 igb0 p--s--- 135 0 129 380 0 ngrep >>> šThe BPF stats show Recv and Match values. Good. >>> >>> š# ngrep -d bridge0 "q" ip >>> ššI see some matching packets. Good. >>> >>> š# netstat -B >>> ššPid Netif Flags Recv Drop Match Sblen Hblen Command >>> š1901 bridge0 p--s--- 661897 0 659170 425606 0 ngrep >>> šAgain, the BPF stats show Recv and Match values. Good. >>> >>> šHowever, if I sniff on an ix interface: >>> >>> š# ngrep -d ix1 "q" ip >>> šI get no matching packets! >>> >>> š# netstat -B >>> ššPid Netif Flags Recv Drop Match Sblen Hblen Command >>> š1816 ix1 p--s--- 45340 0 0 0 0 ngrep >>> šššššššššššššššššššššššššššššššššššššššššššššššš^^^ >>> š...and the BPF stats always show zero Matches. >>> >>> šBug in the ixgbe driver or in ngrep? >>> >>> š/Elof >>> >>> š_______________________________________________ >>> šfreebsd-net@freebsd.org mailing list >>> šhttps://lists.freebsd.org/mailman/listinfo/freebsd-net >>> šTo unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@freebsd.org Tue Dec 1 15:05:41 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A93CEA2C34E for ; Tue, 1 Dec 2015 15:05:41 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (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 7DE371858 for ; Tue, 1 Dec 2015 15:05:41 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 01DDE20EE4 for ; Tue, 1 Dec 2015 10:05:33 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute3.internal (MEProxy); Tue, 01 Dec 2015 10:05:34 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=h6Km/b5eBPbP9pM 7oWEY80aCbf8=; b=erm4IwEGUa/MDL97e4qYHQfV4bnCl+VHV1LYNriQWJi/RHt aRHsQN95VM3i98AEQsO/NmN6v9YRpPQeUxOdD+Rk98wuKF/crHDYPhbeq5TtsDZf qACB0Tc6GcSRE406LLWQnbgh6vt6PVIHFkajAVlwQtUlbYOTZubgyxNX1Cn8= Received: by web3.nyi.internal (Postfix, from userid 99) id B156810BE42; Tue, 1 Dec 2015 10:05:33 -0500 (EST) Message-Id: <1448982333.1269981.454734633.11BA4DB2@webmail.messagingengine.com> X-Sasl-Enc: /aLTHO70yUjVu3j9jc57/mB3bySOz+ZeqX6SA9T1yJ8n 1448982333 From: Mark Felder To: wishmaster , freebsd-net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-b94e6169 In-Reply-To: <1448956697.854911427.15is5btc@frv34.fwdcdn.com> References: <1448920706.962818.454005905.61CF9154@webmail.messagingengine.com> <1448956697.854911427.15is5btc@frv34.fwdcdn.com> Subject: Re: IPFW blocked my IPv6 NTP traffic Date: Tue, 01 Dec 2015 09:05:33 -0600 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 15:05:41 -0000 On Tue, Dec 1, 2015, at 02:02, wishmaster wrote: > > Hi, Mark. > > > > I'm hoping someone can explain what happened here and this isn't a bug, > > but if it is a bug I'll gladly open a PR. > > > > I noticed in my ipfw logs that I was getting a log of "DENY" entries for > > an NTP server > > > > Nov 30 13:35:16 gw kernel: ipfw: 4540 Deny UDP > > [2604:a880:800:10::bc:c004]:123 [2001:470:1f11:1e8::2]:58285 in via gif0 > > > > Strange... I looked at ntpq output and sure enough I was trying to > > communicate with that server. But why was it getting blocked? I don't > > have a rule to allow IPv4 input from source port 123. I expected IPFW to > > handle this for me. I know UDP is stateless, but firewalls are usually > > able to "keep state" for UDP. I looked at my v4 rules which and I have > > keep-state on there: > > > > # Allow all outgoing, skip to NAT > > ###################################### > > $cmd 01300 skipto 5000 tcp from any to any out via $pif $ks > > $cmd 01310 skipto 5000 udp from any to any out via $pif $ks > > $cmd 01320 skipto 5000 icmp from any to any out via $pif > > ###################################### > > > > I noticed my outbound IPv6 didn't have $ks for udp, so I added it. > > However, that had no effect. The solution was to add an incoming rule: > > > > $cmd 03755 allow udp from any to any src-port 123 in via $pif6 $ks > > > > This seems wrong. Thoughts? > > > > What is your 5000 rule? > $cmd 05000 nat 1 ip4 from any to any out via $pif > In general on public interface you should: > $cmd 12345 allow log all from any to me 123 $ks > > And for outgoing traffic just: > $cmd 1234 allow log all from me to any $ks > > This works for me. > Sure, I understand the risks and the workaround here but it just seems odd that I have to do this for ipv6 when ipv4 has worked fine. With UDP not really having "state" I understand why that traffic was blocked because the NTP server was trying to send data to my port 58285. I did a tcpdump and restarted ntpd to see what I could find other instances of this in the ipv4 traffic: root@gw:/usr/home/feld # tcpdump -i re0 -nttt dst port 123 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on re0, link-type EN10MB (Ethernet), capture size 262144 bytes 00:00:00.000000 IP 68.117.126.78.123 > 129.6.15.29.123: NTPv4, Client, length 48 00:00:00.105172 IP 129.6.15.29.123 > 68.117.126.78.123: NTPv4, Server, length 48 00:00:01.894636 IP 68.117.126.78.123 > 209.114.111.1.123: NTPv4, Client, length 48 00:00:00.000068 IP 68.117.126.78.123 > 129.6.15.29.123: NTPv4, Client, length 48 00:00:00.065549 IP 209.114.111.1.123 > 68.117.126.78.123: NTPv4, Server, length 48 00:00:00.045821 IP 129.6.15.29.123 > 68.117.126.78.123: NTPv4, Server, length 48 00:00:01.888500 IP 68.117.126.78.123 > 209.114.111.1.123: NTPv4, Client, length 48 00:00:00.000066 IP 68.117.126.78.123 > 129.6.15.29.123: NTPv4, Client, length 48 00:00:00.064383 IP 209.114.111.1.123 > 68.117.126.78.123: NTPv4, Server, length 48 00:00:00.042029 IP 129.6.15.29.123 > 68.117.126.78.123: NTPv4, Server, length 48 00:00:01.893509 IP 68.117.126.78.123 > 209.114.111.1.123: NTPv4, Client, length 48 00:00:00.000061 IP 68.117.126.78.123 > 129.6.15.29.123: NTPv4, Client, length 48 00:00:00.064418 IP 209.114.111.1.123 > 68.117.126.78.123: NTPv4, Server, length 48 00:00:00.044275 IP 129.6.15.29.123 > 68.117.126.78.123: NTPv4, Server, length 48 00:00:01.891510 IP 68.117.126.78.123 > 209.114.111.1.123: NTPv4, Client, length 48 00:00:00.000068 IP 68.117.126.78.123 > 129.6.15.29.123: NTPv4, Client, length 48 00:00:00.063342 IP 209.114.111.1.123 > 68.117.126.78.123: NTPv4, Server, length 48 00:00:00.044807 IP 129.6.15.29.123 > 68.117.126.78.123: NTPv4, Server, length 48 00:00:01.891549 IP 68.117.126.78.123 > 209.114.111.1.123: NTPv4, Client, length 48 00:00:00.000067 IP 68.117.126.78.123 > 129.6.15.29.123: NTPv4, Client, length 48 00:00:00.065415 IP 209.114.111.1.123 > 68.117.126.78.123: NTPv4, Server, length 48 00:00:00.038239 IP 68.117.126.78.16205 > 69.164.201.165.123: NTPv4, Client, length 48 00:00:01.896362 IP 68.117.126.78.123 > 209.114.111.1.123: NTPv4, Client, length 48 00:00:00.064590 IP 209.114.111.1.123 > 68.117.126.78.123: NTPv4, Server, length 48 00:00:06.057206 IP 68.117.126.78.16205 > 4.53.160.75.123: NTPv4, Client, length 48 00:00:08.003668 IP 68.117.126.78.16205 > 72.20.40.62.123: NTPv4, Client, length 48 00:00:08.051264 IP 68.117.126.78.16205 > 104.131.53.252.123: NTPv4, Client, length 48 Notice how almost all of them are port 123 on both sides, but a few of them are not. Why? The RFC says that NTP is supposed to be using port 123 as both the source and destination port, but I clearly have something happening on port 16205. Is something screwy with ntpd in CURRENT? -- Mark Felder ports-secteam member feld@FreeBSD.org From owner-freebsd-net@freebsd.org Tue Dec 1 15:19:10 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BA7D7A2C5BE for ; Tue, 1 Dec 2015 15:19:10 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4A74D1DCC for ; Tue, 1 Dec 2015 15:19:10 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from zero-gravitas.local ([IPv6:2001:8b0:151:1:2ef0:eeff:fe24:fa38]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.15.2/8.15.2) with ESMTPSA id tB1FIwe4058940 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 1 Dec 2015 15:18:59 GMT (envelope-from matthew@FreeBSD.org) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=FreeBSD.org DKIM-Filter: OpenDKIM Filter v2.10.3 smtp.infracaninophile.co.uk tB1FIwe4058940 Authentication-Results: smtp.infracaninophile.co.uk/tB1FIwe4058940; dkim=none; dkim-atps=neutral X-Authentication-Warning: lucid-nonsense.infracaninophile.co.uk: Host [IPv6:2001:8b0:151:1:2ef0:eeff:fe24:fa38] claimed to be zero-gravitas.local Subject: Re: IPFW blocked my IPv6 NTP traffic To: freebsd-net@freebsd.org References: <1448920706.962818.454005905.61CF9154@webmail.messagingengine.com> <1448956697.854911427.15is5btc@frv34.fwdcdn.com> <1448982333.1269981.454734633.11BA4DB2@webmail.messagingengine.com> From: Matthew Seaman Message-ID: <565DBA5B.20203@FreeBSD.org> Date: Tue, 1 Dec 2015 15:18:51 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <1448982333.1269981.454734633.11BA4DB2@webmail.messagingengine.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TmVMsQMKq8Ifili5mSUhmhlGRWTbmXSVC" X-Virus-Scanned: clamav-milter 0.98.7 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on lucid-nonsense.infracaninophile.co.uk X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 15:19:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TmVMsQMKq8Ifili5mSUhmhlGRWTbmXSVC Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2015/12/01 15:05, Mark Felder wrote: > Notice how almost all of them are port 123 on both sides, but a few of > them are not. Why? The RFC says that NTP is supposed to be using port > 123 as both the source and destination port, but I clearly have > something happening on port 16205. Is something screwy with ntpd in > CURRENT? NTP not using port 123 as the source port usually indicates that it is behind a NAT gateway at the other end. It's harmless and fairly common. Cheers, Matthew --TmVMsQMKq8Ifili5mSUhmhlGRWTbmXSVC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQJ8BAEBCgBmBQJWXbpiXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxOUYxNTRFQ0JGMTEyRTUwNTQ0RTNGMzAw MDUxM0YxMEUwQTlFNEU3AAoJEABRPxDgqeTnca8P/1p9ApkkoieNtD658c0QY8HP EFIiCAuvWWd65VGyvaKB2MncImxIE0zsB8Ios0dvDNcTTLL6io+5SkQmUDfZHHBY FF59jtmHO9UxniSVS7Z2H3BikGMFCtTRvX6agJOU6idgDaPjeYa8GdGT5sNJm/c5 ONmd1mtJcH0acD+iZGXXwCFL8JTGE2bllg4zHOKQOhv/Ks5OrE4TJSvdU+RNqQpr 6XfN8R82t8z/sj4pHLvaMyw4pnr9TlB/ZhwOJtfgpAnMZ6xLTKe3WlNEzbbHAz/L CZoyx6oJRRqo4PAL5M4dq7F28i7jYb0lyiN8FG1xEh4D8VjItBQdPB0itcsJK+Wk LsfJH7GEpIbyhMHUmCbcLM5Tm20izp9MxKJar3SzwNReeiNJSvb0qh7im4Z/qcA1 gbZUSl8xShcFmuwTh2ZG/6Au7rV2o28Z8ahP90G1cmaRQ2ntz1UCw0CQJ/MQFA+W opmjt0Ft1kovxoLIDq61Xm3OxVPA3otdFtcOgxAGf8n9TLXDMHo7umfU0IAjGHLu 8LCDsusNUTjwledbJtyzpZFuIwcKk1IN/yI9Pyw4rcC5sK9dgOsxatpqdKa+m/6V 3Lg3NITT7pFCIIIBVPrrBYCkbpBtZPpCPVztRbh0hcizD4TmHuzm4YeG96ktJbkj F43EG5KLONF5fCtsiHTt =yI9P -----END PGP SIGNATURE----- --TmVMsQMKq8Ifili5mSUhmhlGRWTbmXSVC-- From owner-freebsd-net@freebsd.org Tue Dec 1 15:36:22 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9066BA2CD6F for ; Tue, 1 Dec 2015 15:36:22 +0000 (UTC) (envelope-from artemrts@ukr.net) Received: from frv189.fwdcdn.com (frv189.fwdcdn.com [212.42.77.189]) (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 5225311CE for ; Tue, 1 Dec 2015 15:36:21 +0000 (UTC) (envelope-from artemrts@ukr.net) Received: from [10.10.1.26] (helo=frv197.fwdcdn.com) by frv189.fwdcdn.com with esmtp ID 1a3mfz-000KDZ-LD for freebsd-net@freebsd.org; Tue, 01 Dec 2015 17:17:07 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:To:Subject:From:Date; bh=xwDxOYjb8/4ZIoO81KLmBXrfz0b+vwzeUd+hUzxBNQM=; b=gxEcCMNjJVavdrNOS0Eot4qP7NDJ9P9puh5cUrHE/1K/gM+8QukRrtP1nhegUFqdfwFyqYdn9U8QV29AbnZ+nCSlxw0xfMeLazzaelAE5GHiIS3e6p5WSS4J62DLplKw3yH0dIUH/M92QcL47XszLgtvOLVcWoMUklRdIOj4CrA=; Received: from [10.10.10.34] (helo=frv34.fwdcdn.com) by frv197.fwdcdn.com with smtp ID 1a3mfr-000Dlw-Vl for freebsd-net@freebsd.org; Tue, 01 Dec 2015 17:16:59 +0200 Date: Tue, 01 Dec 2015 17:16:59 +0200 From: wishmaster Subject: Re[2]: IPFW blocked my IPv6 NTP traffic To: freebsd-net@freebsd.org X-Mailer: mail.ukr.net 5.0 Message-Id: <1448982799.434403138.1awkb6gu@frv34.fwdcdn.com> In-Reply-To: <1448982333.1269981.454734633.11BA4DB2@webmail.messagingengine.com> References: <1448920706.962818.454005905.61CF9154@webmail.messagingengine.com> <1448956697.854911427.15is5btc@frv34.fwdcdn.com> <1448982333.1269981.454734633.11BA4DB2@webmail.messagingengine.com> X-Reply-Action: reply Received: from artemrts@ukr.net by frv34.fwdcdn.com; Tue, 01 Dec 2015 17:16:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary Content-Disposition: inline X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 15:36:22 -0000 --- Original message --- From: "Mark Felder" Date: 1 December 2015, 17:05:35 > > > On Tue, Dec 1, 2015, at 02:02, wishmaster wrote: > > > > Hi, Mark. > > > > > > > I'm hoping someone can explain what happened here and this isn't a bug, > > > but if it is a bug I'll gladly open a PR. > > > > > > I noticed in my ipfw logs that I was getting a log of "DENY" entries for > > > an NTP server > > > > > > Nov 30 13:35:16 gw kernel: ipfw: 4540 Deny UDP > > > [2604:a880:800:10::bc:c004]:123 [2001:470:1f11:1e8::2]:58285 in via gif0 > > > > > > Strange... I looked at ntpq output and sure enough I was trying to > > > communicate with that server. But why was it getting blocked? I don't > > > have a rule to allow IPv4 input from source port 123. I expected IPFW to > > > handle this for me. I know UDP is stateless, but firewalls are usually > > > able to "keep state" for UDP. I looked at my v4 rules which and I have > > > keep-state on there: > > > > > > # Allow all outgoing, skip to NAT > > > ###################################### > > > $cmd 01300 skipto 5000 tcp from any to any out via $pif $ks > > > $cmd 01310 skipto 5000 udp from any to any out via $pif $ks > > > $cmd 01320 skipto 5000 icmp from any to any out via $pif > > > ###################################### > > > > > > I noticed my outbound IPv6 didn't have $ks for udp, so I added it. > > > However, that had no effect. The solution was to add an incoming rule: > > > > > > $cmd 03755 allow udp from any to any src-port 123 in via $pif6 $ks > > > > > > This seems wrong. Thoughts? > > > > > > > What is your 5000 rule? > > > > $cmd 05000 nat 1 ip4 from any to any out via $pif Hey. As I understand, there is a problem in connection clients from Inet with your NTP server. If yes, why do you use NAT rule? > > In general on public interface you should: > > $cmd 12345 allow log all from any to me 123 $ks > > > > And for outgoing traffic just: > > $cmd 1234 allow log all from me to any $ks > > > > This works for me. > > -- Vitaliy From owner-freebsd-net@freebsd.org Tue Dec 1 15:53:46 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 01A8CA3D39F for ; Tue, 1 Dec 2015 15:53:46 +0000 (UTC) (envelope-from elof2@sentor.se) Received: from smtp-out.sentor.se (smtp-out.sentor.se [176.124.225.2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B93B910EE; Tue, 1 Dec 2015 15:53:45 +0000 (UTC) (envelope-from elof2@sentor.se) Received: from localhost (localhost [127.0.0.1]) by farmermaggot.shire.sentor.se (Postfix) with ESMTP id 40D80B61D233; Tue, 1 Dec 2015 16:53:42 +0100 (CET) Date: Tue, 1 Dec 2015 16:53:42 +0100 (CET) From: elof2@sentor.se To: Matthew Seaman cc: freebsd-net Subject: Re: IPFW blocked my IPv6 NTP traffic In-Reply-To: <565DBA5B.20203@FreeBSD.org> Message-ID: References: <1448920706.962818.454005905.61CF9154@webmail.messagingengine.com> <1448956697.854911427.15is5btc@frv34.fwdcdn.com> <1448982333.1269981.454734633.11BA4DB2@webmail.messagingengine.com> <565DBA5B.20203@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 15:53:46 -0000 On Tue, 1 Dec 2015, Matthew Seaman wrote: > On 2015/12/01 15:05, Mark Felder wrote: >> Notice how almost all of them are port 123 on both sides, but a few of >> them are not. Why? The RFC says that NTP is supposed to be using port >> 123 as both the source and destination port, but I clearly have >> something happening on port 16205. Is something screwy with ntpd in >> CURRENT? > > NTP not using port 123 as the source port usually indicates that it is > behind a NAT gateway at the other end. It's harmless and fairly common. ...or simply that it is a ntp *client* like ntpdate, and not a daemon. Clients often use a random source port, while ntpd use source port 123. /Elof From owner-freebsd-net@freebsd.org Tue Dec 1 16:05:50 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 47F73A3DA57 for ; Tue, 1 Dec 2015 16:05:50 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E9ED317B5 for ; Tue, 1 Dec 2015 16:05:49 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: by wmww144 with SMTP id w144so3298881wmw.1 for ; Tue, 01 Dec 2015 08:05:48 -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=2F1JHopaUfty9/4abcRLYEMKxhXghmxqJNTajaS483M=; b=eIpInilJbc8FzwCajbzau5uSdpVwBoUphnF+ftWVkcT6ZxeAg3VbQ+XhHYWeBB5rUZ Rvcj9p+8dUkBkyPqCM4cPN4nOT3crZXbAirrLKgOc7ZHjwG2j7Ct/6HkEWg8xmpBaVgS ZZNLpI3iM6VaPaM9aGe4tb7+HC594BfGr5ddLDkzXjJcitZLiG8MdmEAuONMyqrt8cyA 0UiIxsvE01ZKphfYXzv2KJ/+fOqysivIfshUWCelQcPAWPr9jqKzURzHSAXbsKqCLPDS LRMZPot7PjEqe2rxPOsw+2qTEB3+SoWz7Q/iTDjU0ulR3E4FW6ZksUuamBnUVS3TfHFI c9mw== X-Received: by 10.194.63.238 with SMTP id j14mr92040242wjs.172.1448985948042; Tue, 01 Dec 2015 08:05:48 -0800 (PST) Received: from [192.168.2.30] ([2.176.176.59]) by smtp.googlemail.com with ESMTPSA id uw6sm1032072wjc.42.2015.12.01.08.05.46 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Dec 2015 08:05:47 -0800 (PST) Message-ID: <565DC558.5090108@gmail.com> Date: Tue, 01 Dec 2015 19:35:44 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" Subject: mbuf statistics 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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 16:05:50 -0000 Hi, On an idle freebsd 9.3 system: > vmstat -z | egrep "mbuf_cluster|ITEM" | column -t ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP mbuf_cluster: 2048, 10284, 1152, 56, 4237, 0, 0 > netstat -mb | grep "mbuf clusters in use" 512/696/1208/10284 mbuf clusters in use (current/cache/total/max) one can see that: current + cache == total == USED + FREE but the current/cache values as reported by netstat are very different form USED/FREE values reported by vmstat, so they should have different meaning. The question is: what is the exact meaning of USED/FREE and current/cache values? Is there any relationship between them? -- Best regards Hooman Fazaeli From owner-freebsd-net@freebsd.org Tue Dec 1 16:09:18 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2933CA3DD0B for ; Tue, 1 Dec 2015 16:09:18 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (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 EFBFD1172 for ; Tue, 1 Dec 2015 16:09:17 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id F06E92082F for ; Tue, 1 Dec 2015 11:09:16 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute6.internal (MEProxy); Tue, 01 Dec 2015 11:09:16 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=7ZpbDt1qDb/xez5 D0VJF0FoOzeo=; b=tpY4BF2VaUqkSty5n5KCVMbywYCTxycFqrwGBdvW3l5XxQI 1OJ9x0IDnNWGsPL7wEwHEsZ1/1lOuqPEGVh5SQkFlOy5l07H811t/irU/c5/AiN7 hCkh7daNWcIpgAOoV9d4wtEGWk8NoR8xsDIe/Q8aGqPj+YcINE5ETI2HfDlY= Received: by web3.nyi.internal (Postfix, from userid 99) id CACDE10C46A; Tue, 1 Dec 2015 11:09:16 -0500 (EST) Message-Id: <1448986156.1288999.454817825.3C08D1EA@webmail.messagingengine.com> X-Sasl-Enc: lknEcwEwnpBItc1i13lzGcyNfn/YZzHdKSKvXcW0tU4k 1448986156 From: Mark Felder To: elof2@sentor.se, Matthew Seaman Cc: "freebsd-net" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-b94e6169 Subject: Re: IPFW blocked my IPv6 NTP traffic Date: Tue, 01 Dec 2015 10:09:16 -0600 In-Reply-To: References: <1448920706.962818.454005905.61CF9154@webmail.messagingengine.com> <1448956697.854911427.15is5btc@frv34.fwdcdn.com> <1448982333.1269981.454734633.11BA4DB2@webmail.messagingengine.com> <565DBA5B.20203@FreeBSD.org> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 16:09:18 -0000 On Tue, Dec 1, 2015, at 09:53, elof2@sentor.se wrote: > > On Tue, 1 Dec 2015, Matthew Seaman wrote: > > > On 2015/12/01 15:05, Mark Felder wrote: > >> Notice how almost all of them are port 123 on both sides, but a few of > >> them are not. Why? The RFC says that NTP is supposed to be using port > >> 123 as both the source and destination port, but I clearly have > >> something happening on port 16205. Is something screwy with ntpd in > >> CURRENT? > > > > NTP not using port 123 as the source port usually indicates that it is > > behind a NAT gateway at the other end. It's harmless and fairly common. > > ...or simply that it is a ntp *client* like ntpdate, and not a daemon. > Clients often use a random source port, while ntpd use source port 123. > I wouldn't expect something in pool.ntp.org to be behind NAT and this wasn't an ntp client like ntpdate, but those are both interesting scenarios. Perhaps I'm just naive and they have a good reason for using NAT in front of that NTP server. -- Mark Felder ports-secteam member feld@FreeBSD.org From owner-freebsd-net@freebsd.org Tue Dec 1 16:27:44 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 26415A3E3BE for ; Tue, 1 Dec 2015 16:27:44 +0000 (UTC) (envelope-from elof2@sentor.se) Received: from smtp-out.sentor.se (smtp-out.sentor.se [176.124.225.2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DD62F14AF; Tue, 1 Dec 2015 16:27:43 +0000 (UTC) (envelope-from elof2@sentor.se) Received: from localhost (localhost [127.0.0.1]) by farmermaggot.shire.sentor.se (Postfix) with ESMTP id 7A695B61D233; Tue, 1 Dec 2015 17:27:36 +0100 (CET) Date: Tue, 1 Dec 2015 17:27:36 +0100 (CET) From: elof2@sentor.se To: Mark Felder cc: wishmaster , freebsd-net Subject: Re: IPFW blocked my IPv6 NTP traffic In-Reply-To: <1448982333.1269981.454734633.11BA4DB2@webmail.messagingengine.com> Message-ID: References: <1448920706.962818.454005905.61CF9154@webmail.messagingengine.com> <1448956697.854911427.15is5btc@frv34.fwdcdn.com> <1448982333.1269981.454734633.11BA4DB2@webmail.messagingengine.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 16:27:44 -0000 On Tue, 1 Dec 2015, Mark Felder wrote: > > > On Tue, Dec 1, 2015, at 02:02, wishmaster wrote: >> >> Hi, Mark. >> >> >>> I'm hoping someone can explain what happened here and this isn't a bug, >>> but if it is a bug I'll gladly open a PR. >>> >>> I noticed in my ipfw logs that I was getting a log of "DENY" entries for >>> an NTP server >>> >>> Nov 30 13:35:16 gw kernel: ipfw: 4540 Deny UDP >>> [2604:a880:800:10::bc:c004]:123 [2001:470:1f11:1e8::2]:58285 in via gif0 Three long-shots: 1) I see that you use a gif interface. That makes me wonder: Do the 'keep-state' function in 'ipfw' work as bad as it does in 'pf'? In pf, 'keep state" doesn't keep state between software network interfaces and real network interfaces. So if I allow something in via tun0 (a software OpenVPN NIC), with keep state, the response is *not* automatically (via the state table) allowed back in on the ethernet NIC it was sent out. So for all my VPN-rules, I have to make two of them like this: Pf example: pass in quick on tun0 inet proto tcp from to port 22 keep state label "VpnIN - SSH" pass out quick on em1 inet proto tcp from to port 22 keep state label "DmzOUT - SSH" 2) Is this hapening over and over, or was it just a one time thing? If the latter, could it be that you flushed your firewall state table just after a cron job ran 'ntpdate 2604:a880:800:10::bc:c004', so the query got out but immediately after the state table was emptied and hence the response got blocked? 3) If 2001:470:1f11:1e8::2 is not the ipfw node itself, but some node behind it, could the ntp query to 2604:a880:800:10::bc:c004 have taken a different path? I.e. the ipfw node doesn't see the query, but the response packet is routed to it, so it gets blocked. /Elof From owner-freebsd-net@freebsd.org Tue Dec 1 16:43:33 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EDECFA3E771 for ; Tue, 1 Dec 2015 16:43:32 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (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 AACCA1156 for ; Tue, 1 Dec 2015 16:43:32 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A13122095E for ; Tue, 1 Dec 2015 11:43:31 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Tue, 01 Dec 2015 11:43:31 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=pr5KnxGlF/quXmZ ANPT3dQAiFLs=; b=PV/ML4uOcljqxbMKPxAR6g70Cawy7VOFnUV7wlsES61Rrs+ JVCa3+rImvJ5sDD87/IUn9N9tffT8iHFRQlkkrBxif0ErWt4ZUIXolSJWvklp4pl cfaGg9R0kPpF9gobQ4WAXxibNLmhxsS/wluEgyh1MJWE2y5IwVhDfS5ESMuM= Received: by web3.nyi.internal (Postfix, from userid 99) id 77F1D10C6B2; Tue, 1 Dec 2015 11:43:31 -0500 (EST) Message-Id: <1448988211.1298751.454855961.765FA057@webmail.messagingengine.com> X-Sasl-Enc: kmpObBhAqGhjQZsZwDYYsg8AwY4rugbchj4OcYFnQeAr 1448988211 From: Mark Felder To: elof2@sentor.se Cc: "freebsd-net" , wishmaster MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-b94e6169 In-Reply-To: References: <1448920706.962818.454005905.61CF9154@webmail.messagingengine.com> <1448956697.854911427.15is5btc@frv34.fwdcdn.com> <1448982333.1269981.454734633.11BA4DB2@webmail.messagingengine.com> Subject: Re: IPFW blocked my IPv6 NTP traffic Date: Tue, 01 Dec 2015 10:43:31 -0600 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 16:43:33 -0000 On Tue, Dec 1, 2015, at 10:27, elof2@sentor.se wrote: > On Tue, 1 Dec 2015, Mark Felder wrote: > > > > > > > On Tue, Dec 1, 2015, at 02:02, wishmaster wrote: > >> > >> Hi, Mark. > >> > >> > >>> I'm hoping someone can explain what happened here and this isn't a bug, > >>> but if it is a bug I'll gladly open a PR. > >>> > >>> I noticed in my ipfw logs that I was getting a log of "DENY" entries for > >>> an NTP server > >>> > >>> Nov 30 13:35:16 gw kernel: ipfw: 4540 Deny UDP > >>> [2604:a880:800:10::bc:c004]:123 [2001:470:1f11:1e8::2]:58285 in via gif0 > > Three long-shots: > > 1) > I see that you use a gif interface. That makes me wonder: > Do the 'keep-state' function in 'ipfw' work as bad as it does in 'pf'? > > In pf, 'keep state" doesn't keep state between software network > interfaces and real network interfaces. So if I allow something in via > tun0 (a software OpenVPN NIC), with keep state, the response is *not* > automatically (via the state table) allowed back in on the ethernet NIC > it > was sent out. So for all my VPN-rules, I have to make two of them like > this: > > Pf example: > pass in quick on tun0 inet proto tcp from to > port 22 keep state label "VpnIN - SSH" > pass out quick on em1 inet proto tcp from to > port 22 keep state label "DmzOUT - SSH" > > That's an interesting idea. I wonder if that's happening here. > > 2) > Is this hapening over and over, or was it just a one time thing? > If the latter, could it be that you flushed your firewall state table > just after a cron job ran 'ntpdate 2604:a880:800:10::bc:c004', so the > query got out but immediately after the state table was emptied and > hence the response got blocked? > Nope, I don't run ntp via cron > > > 3) > If 2001:470:1f11:1e8::2 is not the ipfw node itself, but some node behind > it, could the ntp query to 2604:a880:800:10::bc:c004 have taken a > different path? I.e. the ipfw node doesn't see the query, but the > response > packet is routed to it, so it gets blocked. > 2001:470:1f11:1e8::2 is my firewall where ntpd runs. There are no alternate paths, but this is also a clever idea if I was multihomed and was running bgp with some routes preferred out different interfaces. -- Mark Felder ports-secteam member feld@FreeBSD.org From owner-freebsd-net@freebsd.org Tue Dec 1 16:50:48 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 76C68A3E88E for ; Tue, 1 Dec 2015 16:50:48 +0000 (UTC) (envelope-from elof2@sentor.se) Received: from smtp-out.sentor.se (smtp-out.sentor.se [176.124.225.2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 33488144F; Tue, 1 Dec 2015 16:50:47 +0000 (UTC) (envelope-from elof2@sentor.se) Received: from localhost (localhost [127.0.0.1]) by farmermaggot.shire.sentor.se (Postfix) with ESMTP id 06D61B61D233; Tue, 1 Dec 2015 17:50:45 +0100 (CET) Date: Tue, 1 Dec 2015 17:50:45 +0100 (CET) From: elof2@sentor.se To: Mark Felder cc: Matthew Seaman , freebsd-net Subject: Re: IPFW blocked my IPv6 NTP traffic In-Reply-To: <1448986156.1288999.454817825.3C08D1EA@webmail.messagingengine.com> Message-ID: References: <1448920706.962818.454005905.61CF9154@webmail.messagingengine.com> <1448956697.854911427.15is5btc@frv34.fwdcdn.com> <1448982333.1269981.454734633.11BA4DB2@webmail.messagingengine.com> <565DBA5B.20203@FreeBSD.org> <1448986156.1288999.454817825.3C08D1EA@webmail.messagingengine.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 16:50:48 -0000 On Tue, 1 Dec 2015, Mark Felder wrote: > > > On Tue, Dec 1, 2015, at 09:53, elof2@sentor.se wrote: >> >> On Tue, 1 Dec 2015, Matthew Seaman wrote: >> >>> On 2015/12/01 15:05, Mark Felder wrote: >>>> Notice how almost all of them are port 123 on both sides, but a few of >>>> them are not. Why? The RFC says that NTP is supposed to be using port >>>> 123 as both the source and destination port, but I clearly have >>>> something happening on port 16205. Is something screwy with ntpd in >>>> CURRENT? >>> >>> NTP not using port 123 as the source port usually indicates that it is >>> behind a NAT gateway at the other end. It's harmless and fairly common. >> >> ...or simply that it is a ntp *client* like ntpdate, and not a daemon. >> Clients often use a random source port, while ntpd use source port 123. >> > > I wouldn't expect something in pool.ntp.org to be behind NAT and this > wasn't an ntp client like ntpdate, but those are both interesting > scenarios. Perhaps I'm just naive and they have a good reason for using > NAT in front of that NTP server. Not that this helps this thread to move on, but just to clarify: In this case, the NAT that would introduce the randomized src port would be *your* NAT, not a NAT at pool.ntp.org. Deny UDP [2604:a880:800:10::bc:c004]:123 [2001:470:1f11:1e8::2]:58285 in via gif0 The blocked response came from port 123 just as expected. If the client truly sent out a query from src port 123, then it must have been your NAT that picked a free random port to use for its outgoing connection, i.e. port 58285. The server then respond back to your NAT-IP 2001:470:1f11:1e8::2 at port 58285. Your NAT should receive the packet, match it against its NAT table, find that it has indeed an ongoing UDP connection for that particular flow, so it rewrites the dst IP and dst port to your original internal IP address and original port (123) and send it back to the client. /Elof From owner-freebsd-net@freebsd.org Tue Dec 1 16:52:28 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A4CA7A3E9E1 for ; Tue, 1 Dec 2015 16:52:28 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (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 7474018BD for ; Tue, 1 Dec 2015 16:52:28 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 5E03C204AE for ; Tue, 1 Dec 2015 11:52:27 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute6.internal (MEProxy); Tue, 01 Dec 2015 11:52:27 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=nPHLmwbQl/QfsE0 0L52cUg2O0sc=; b=RDK+7FOVIHCw7uw07ZcO+Mk/1h6O2wFkDBQj7F9MIPQhMnK lRRGewbnWSbLq49QR1afM/WGcMmVBvNu2/fFBkiQOrkUo0mvaRld1e6kbISI5/B/ QWCu4+fMB13sLT56tESoqCv1FB3M9TVsZuuVrl2Z2CDV5Ghq8dHiNFH9p4GE= Received: by web3.nyi.internal (Postfix, from userid 99) id 31E9710C769; Tue, 1 Dec 2015 11:52:27 -0500 (EST) Message-Id: <1448988747.1302736.454866425.02D98B53@webmail.messagingengine.com> X-Sasl-Enc: 1bu3gLX+lRXOn2y+vCFT/avutoPal/yWt952cFNz9V3r 1448988747 From: Mark Felder To: elof2@sentor.se Cc: "freebsd-net" , Matthew Seaman MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-b94e6169 Subject: Re: IPFW blocked my IPv6 NTP traffic Date: Tue, 01 Dec 2015 10:52:27 -0600 In-Reply-To: References: <1448920706.962818.454005905.61CF9154@webmail.messagingengine.com> <1448956697.854911427.15is5btc@frv34.fwdcdn.com> <1448982333.1269981.454734633.11BA4DB2@webmail.messagingengine.com> <565DBA5B.20203@FreeBSD.org> <1448986156.1288999.454817825.3C08D1EA@webmail.messagingengine.com> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 16:52:28 -0000 On Tue, Dec 1, 2015, at 10:50, elof2@sentor.se wrote: > > Not that this helps this thread to move on, but just to clarify: > > In this case, the NAT that would introduce the randomized src port would > be *your* NAT, not a NAT at pool.ntp.org. > > > Deny UDP [2604:a880:800:10::bc:c004]:123 [2001:470:1f11:1e8::2]:58285 in > via gif0 > > The blocked response came from port 123 just as expected. > > If the client truly sent out a query from src port 123, then it must have > been your NAT that picked a free random port to use for its outgoing > connection, i.e. port 58285. > The server then respond back to your NAT-IP 2001:470:1f11:1e8::2 at port > 58285. > Your NAT should receive the packet, match it against its NAT table, find > that it has indeed an ongoing UDP connection for that particular flow, so > it rewrites the dst IP and dst port to your original internal IP address > and original port (123) and send it back to the client. > > /Elof > There's no NAT involved with my IPv6. -- Mark Felder ports-secteam member feld@FreeBSD.org From owner-freebsd-net@freebsd.org Tue Dec 1 17:03:54 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 39819A3ED67 for ; Tue, 1 Dec 2015 17:03:54 +0000 (UTC) (envelope-from elof2@sentor.se) Received: from smtp-out.sentor.se (smtp-out.sentor.se [176.124.225.2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ECD5C106D; Tue, 1 Dec 2015 17:03:53 +0000 (UTC) (envelope-from elof2@sentor.se) Received: from localhost (localhost [127.0.0.1]) by farmermaggot.shire.sentor.se (Postfix) with ESMTP id 7A08AB61D233; Tue, 1 Dec 2015 18:03:51 +0100 (CET) Date: Tue, 1 Dec 2015 18:03:51 +0100 (CET) From: elof2@sentor.se To: Mark Felder cc: freebsd-net , Matthew Seaman Subject: Re: IPFW blocked my IPv6 NTP traffic In-Reply-To: <1448988747.1302736.454866425.02D98B53@webmail.messagingengine.com> Message-ID: References: <1448920706.962818.454005905.61CF9154@webmail.messagingengine.com> <1448956697.854911427.15is5btc@frv34.fwdcdn.com> <1448982333.1269981.454734633.11BA4DB2@webmail.messagingengine.com> <565DBA5B.20203@FreeBSD.org> <1448986156.1288999.454817825.3C08D1EA@webmail.messagingengine.com> <1448988747.1302736.454866425.02D98B53@webmail.messagingengine.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 17:03:54 -0000 On Tue, 1 Dec 2015, Mark Felder wrote: > > > On Tue, Dec 1, 2015, at 10:50, elof2@sentor.se wrote: >> >> Not that this helps this thread to move on, but just to clarify: >> >> In this case, the NAT that would introduce the randomized src port would >> be *your* NAT, not a NAT at pool.ntp.org. >> >> >> Deny UDP [2604:a880:800:10::bc:c004]:123 [2001:470:1f11:1e8::2]:58285 in >> via gif0 >> >> The blocked response came from port 123 just as expected. >> >> If the client truly sent out a query from src port 123, then it must have >> been your NAT that picked a free random port to use for its outgoing >> connection, i.e. port 58285. >> The server then respond back to your NAT-IP 2001:470:1f11:1e8::2 at port >> 58285. >> Your NAT should receive the packet, match it against its NAT table, find >> that it has indeed an ongoing UDP connection for that particular flow, so >> it rewrites the dst IP and dst port to your original internal IP address >> and original port (123) and send it back to the client. >> >> /Elof >> > > There's no NAT involved with my IPv6. Good. :-) As I was saying, this was just a sidetrack to clarify that the portNAT would not be located at the ntp-server side. /Elof From owner-freebsd-net@freebsd.org Tue Dec 1 18:00:49 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 23D6BA3EC72 for ; Tue, 1 Dec 2015 18:00:49 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (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 D53801C91 for ; Tue, 1 Dec 2015 18:00:48 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id D527E20E5F for ; Tue, 1 Dec 2015 13:00:47 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute3.internal (MEProxy); Tue, 01 Dec 2015 13:00:47 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=4Dgqgpef0IiQQNE E7v3EiH6fBGU=; b=Ezqoi3thJhnXfAIKaZJ/9e443YzSkSdLcZeAuggiKIwKkJK Qpv4JGYGYaLdWCD/rBZd1O9hPshrpU4kpBBRimBBqEt5IrdVFWkkhivmEw6CvdBh GUUzGteca3uV/o07PbrpqtyMG+Wzo6dXwJA86j+iWJlGd6wR05emN16CfN00= Received: by web3.nyi.internal (Postfix, from userid 99) id A6E6B10D766; Tue, 1 Dec 2015 13:00:47 -0500 (EST) Message-Id: <1448992847.1321736.454930393.6EE09773@webmail.messagingengine.com> X-Sasl-Enc: yLDwoG6SUlcj1LGCKrOBP7YIdc/RNZEmKSxYF2/Jq3vd 1448992847 From: Mark Felder To: wishmaster , freebsd-net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-b94e6169 In-Reply-To: <1448982799.434403138.1awkb6gu@frv34.fwdcdn.com> References: <1448920706.962818.454005905.61CF9154@webmail.messagingengine.com> <1448956697.854911427.15is5btc@frv34.fwdcdn.com> <1448982333.1269981.454734633.11BA4DB2@webmail.messagingengine.com> <1448982799.434403138.1awkb6gu@frv34.fwdcdn.com> Subject: Re: IPFW blocked my IPv6 NTP traffic Date: Tue, 01 Dec 2015 12:00:47 -0600 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 18:00:49 -0000 On Tue, Dec 1, 2015, at 09:16, wishmaster wrote: > > --- Original message --- > From: "Mark Felder" > Date: 1 December 2015, 17:05:35 > > > > > > > > On Tue, Dec 1, 2015, at 02:02, wishmaster wrote: > > > > > > Hi, Mark. > > > > > > > > > > I'm hoping someone can explain what happened here and this isn't a bug, > > > > but if it is a bug I'll gladly open a PR. > > > > > > > > I noticed in my ipfw logs that I was getting a log of "DENY" entries for > > > > an NTP server > > > > > > > > Nov 30 13:35:16 gw kernel: ipfw: 4540 Deny UDP > > > > [2604:a880:800:10::bc:c004]:123 [2001:470:1f11:1e8::2]:58285 in via gif0 > > > > > > > > Strange... I looked at ntpq output and sure enough I was trying to > > > > communicate with that server. But why was it getting blocked? I don't > > > > have a rule to allow IPv4 input from source port 123. I expected IPFW to > > > > handle this for me. I know UDP is stateless, but firewalls are usually > > > > able to "keep state" for UDP. I looked at my v4 rules which and I have > > > > keep-state on there: > > > > > > > > # Allow all outgoing, skip to NAT > > > > ###################################### > > > > $cmd 01300 skipto 5000 tcp from any to any out via $pif $ks > > > > $cmd 01310 skipto 5000 udp from any to any out via $pif $ks > > > > $cmd 01320 skipto 5000 icmp from any to any out via $pif > > > > ###################################### > > > > > > > > I noticed my outbound IPv6 didn't have $ks for udp, so I added it. > > > > However, that had no effect. The solution was to add an incoming rule: > > > > > > > > $cmd 03755 allow udp from any to any src-port 123 in via $pif6 $ks > > > > > > > > This seems wrong. Thoughts? > > > > > > > > > > What is your 5000 rule? > > > > > > > $cmd 05000 nat 1 ip4 from any to any out via $pif > > Hey. As I understand, there is a problem in connection clients from Inet > with your NTP server. If yes, why do you use NAT rule? > > That's the NAT rule for my home network for outbound IPv4. It's working as expected. Outbound NTP traffic on high ports (not 123) works fine with IPv4. The reply from the NTP server is allowed through, presumably from the keep-state rule on outbound UDP traffic. Outbound NTP traffic on high ports with IPv6 is allowed outbound but the replies denied inbound. This has been my source of confusion and concern considering it should have been allowed by keep-state. -- Mark Felder ports-secteam member feld@FreeBSD.org From owner-freebsd-net@freebsd.org Tue Dec 1 18:08:27 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9EDD6A3EDED for ; Tue, 1 Dec 2015 18:08:27 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from mail.in-addr.com (mail.in-addr.com [IPv6:2a01:4f8:191:61e8::2525:2525]) (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 647AD1F84; Tue, 1 Dec 2015 18:08:27 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by mail.in-addr.com with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1a3pLl-0002Rg-Eg; Tue, 01 Dec 2015 18:08:25 +0000 Date: Tue, 1 Dec 2015 18:08:25 +0000 From: Gary Palmer To: Mark Felder Cc: freebsd-net@freebsd.org Subject: Re: IPFW blocked my IPv6 NTP traffic Message-ID: <20151201180825.GA79605@in-addr.com> References: <1448920706.962818.454005905.61CF9154@webmail.messagingengine.com> <1448956697.854911427.15is5btc@frv34.fwdcdn.com> <1448982333.1269981.454734633.11BA4DB2@webmail.messagingengine.com> <1448982799.434403138.1awkb6gu@frv34.fwdcdn.com> <1448992847.1321736.454930393.6EE09773@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1448992847.1321736.454930393.6EE09773@webmail.messagingengine.com> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on mail.in-addr.com); SAEximRunCond expanded to false X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 18:08:27 -0000 On Tue, Dec 01, 2015 at 12:00:47PM -0600, Mark Felder wrote: > > > On Tue, Dec 1, 2015, at 09:16, wishmaster wrote: > > > > --- Original message --- > > From: "Mark Felder" > > Date: 1 December 2015, 17:05:35 > > > > > > > > > > > > > On Tue, Dec 1, 2015, at 02:02, wishmaster wrote: > > > > > > > > Hi, Mark. > > > > > > > > > > > > > I'm hoping someone can explain what happened here and this isn't a bug, > > > > > but if it is a bug I'll gladly open a PR. > > > > > > > > > > I noticed in my ipfw logs that I was getting a log of "DENY" entries for > > > > > an NTP server > > > > > > > > > > Nov 30 13:35:16 gw kernel: ipfw: 4540 Deny UDP > > > > > [2604:a880:800:10::bc:c004]:123 [2001:470:1f11:1e8::2]:58285 in via gif0 > > > > > > > > > > Strange... I looked at ntpq output and sure enough I was trying to > > > > > communicate with that server. But why was it getting blocked? I don't > > > > > have a rule to allow IPv4 input from source port 123. I expected IPFW to > > > > > handle this for me. I know UDP is stateless, but firewalls are usually > > > > > able to "keep state" for UDP. I looked at my v4 rules which and I have > > > > > keep-state on there: > > > > > > > > > > # Allow all outgoing, skip to NAT > > > > > ###################################### > > > > > $cmd 01300 skipto 5000 tcp from any to any out via $pif $ks > > > > > $cmd 01310 skipto 5000 udp from any to any out via $pif $ks > > > > > $cmd 01320 skipto 5000 icmp from any to any out via $pif > > > > > ###################################### > > > > > > > > > > I noticed my outbound IPv6 didn't have $ks for udp, so I added it. > > > > > However, that had no effect. The solution was to add an incoming rule: > > > > > > > > > > $cmd 03755 allow udp from any to any src-port 123 in via $pif6 $ks > > > > > > > > > > This seems wrong. Thoughts? > > > > > > > > > > > > > What is your 5000 rule? > > > > > > > > > > $cmd 05000 nat 1 ip4 from any to any out via $pif > > > > Hey. As I understand, there is a problem in connection clients from Inet > > with your NTP server. If yes, why do you use NAT rule? > > > > > > That's the NAT rule for my home network for outbound IPv4. It's working > as expected. > > Outbound NTP traffic on high ports (not 123) works fine with IPv4. The > reply from the NTP server is allowed through, presumably from the > keep-state rule on outbound UDP traffic. > > Outbound NTP traffic on high ports with IPv6 is allowed outbound but the > replies denied inbound. This has been my source of confusion and concern > considering it should have been allowed by keep-state. Have you looked at the ipfw state tables to see if a state is recorded? ipfw -d list I think Gary From owner-freebsd-net@freebsd.org Tue Dec 1 18:22:38 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BAFCFA3E2D1 for ; Tue, 1 Dec 2015 18:22:38 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (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 8CE6B1ED8 for ; Tue, 1 Dec 2015 18:22:38 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 7214A2095B for ; Tue, 1 Dec 2015 13:22:37 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute5.internal (MEProxy); Tue, 01 Dec 2015 13:22:37 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=hlX/JW6YrQ95kEt gx3bpxcLBcAk=; b=JK+qQ+ncnzjlTiGJeVcQKd/g+pWekWNE2QoScV9BT07J/// h0aQ3zYirrjH/44dugKjF5bibCAX8Ge4Pa+5APvUVxZlw2sL77prRjEx+WT10uQ8 wsM/nB96lmmleOdo4x0d2wUJwapSRuZmFnGxKCOy3d/o/eDuYErzZpuNELDE= Received: by web3.nyi.internal (Postfix, from userid 99) id 49E5910D803; Tue, 1 Dec 2015 13:22:37 -0500 (EST) Message-Id: <1448994157.1328347.454947073.3503184F@webmail.messagingengine.com> X-Sasl-Enc: jRiZLJ4iQD10gAvadoMqsa0FCaMysQh0zrA6+2THvzeW 1448994157 From: Mark Felder To: Gary Palmer Cc: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-b94e6169 Subject: Re: IPFW blocked my IPv6 NTP traffic Date: Tue, 01 Dec 2015 12:22:37 -0600 In-Reply-To: <20151201180825.GA79605@in-addr.com> References: <1448920706.962818.454005905.61CF9154@webmail.messagingengine.com> <1448956697.854911427.15is5btc@frv34.fwdcdn.com> <1448982333.1269981.454734633.11BA4DB2@webmail.messagingengine.com> <1448982799.434403138.1awkb6gu@frv34.fwdcdn.com> <1448992847.1321736.454930393.6EE09773@webmail.messagingengine.com> <20151201180825.GA79605@in-addr.com> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 18:22:38 -0000 On Tue, Dec 1, 2015, at 12:08, Gary Palmer wrote: > > Have you looked at the ipfw state tables to see if a state is recorded? > > ipfw -d list > > I think > Yes, and I can see the state especially for IPv6. I think I have solved this mystery. There was a problem, and I solved it, but then was fooled into thinking a problem persisted. * keep-state was missing for some outbound IPv6 traffic * IPv6 outbound NTP from my firewall was not using high ports, nor was IPv4 * A host behind my firewall was found to be running ntpd and ntimed. ntpd was pointed at the same pool as my firewall and I happened to see some high-port traffic to the same servers I was associated with. * This host behind my firewall also has an almost identical IPv6 address with one octet being a single digit off (1f11 vs 1f10) as well as shares the same outbound IPv4 address ... * There was an issue with an IPv6 NTP server or I misread the NTP output (it was stuck in STEP and seemed to go away when I added an IPFW rule) * The combination of these coincidences caused confusion and fooled me into thinking the source was the firewall. I'm now confident the keep-state works for IPv6 gif interfaces in IPFW as I can see the states and am now guilty of wasting your time and INBOX space. :) At least I was able to find two problems and solve them. Thanks, IPFW logging! -- Mark Felder ports-secteam member feld@FreeBSD.org From owner-freebsd-net@freebsd.org Wed Dec 2 03:17:22 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2A75DA3F19C for ; Wed, 2 Dec 2015 03:17:22 +0000 (UTC) (envelope-from honzhan@microsoft.com) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0133.outbound.protection.outlook.com [157.56.111.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6EA3B185E for ; Wed, 2 Dec 2015 03:17:20 +0000 (UTC) (envelope-from honzhan@microsoft.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=h2KOCpCblnfJ1hadeFuWxnmm0G259y6bbct1QhFizVQ=; b=cu3kLar8t4kpjfv3ft3biTSGGz2nAqOcp8fUdAQnCNikEizN9kjSUz5p2bsPzUemswhJERMe6RvaANk0YVpz+962S0o4mP/X6tIJef4E8DBHh0/l2pkOIJxyGhJiZYarT5ZJs/KuKhBnJQhq3KZuPDsu7tp9abkdEKUsdDq8Wv0= Received: from BY2PR03CA078.namprd03.prod.outlook.com (10.141.249.51) by SN2PR03MB093.namprd03.prod.outlook.com (10.255.175.157) with Microsoft SMTP Server (TLS) id 15.1.331.20; Wed, 2 Dec 2015 03:02:49 +0000 Received: from BY2FFO11FD035.protection.gbl (2a01:111:f400:7c0c::134) by BY2PR03CA078.outlook.office365.com (2a01:111:e400:2c5d::51) with Microsoft SMTP Server (TLS) id 15.1.331.20 via Frontend Transport; Wed, 2 Dec 2015 03:02:49 +0000 Authentication-Results: spf=pass (sender IP is 206.191.228.180) smtp.mailfrom=microsoft.com; gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=pass action=none header.from=microsoft.com; Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 206.191.228.180 as permitted sender) receiver=protection.outlook.com; client-ip=206.191.228.180; helo=064-smtp-out.microsoft.com; Received: from 064-smtp-out.microsoft.com (206.191.228.180) by BY2FFO11FD035.mail.protection.outlook.com (10.1.14.220) with Microsoft SMTP Server (TLS) id 15.1.331.11 via Frontend Transport; Wed, 2 Dec 2015 03:02:47 +0000 Received: from SG2PR3002MB0106.064d.mgd.msft.net (141.251.56.18) by SG2PR3002MB0107.064d.mgd.msft.net (141.251.56.19) with Microsoft SMTP Server (TLS) id 15.1.337.9; Wed, 2 Dec 2015 03:02:35 +0000 Received: from SG2PR3002MB0106.064d.mgd.msft.net ([141.251.56.18]) by SG2PR3002MB0106.064d.mgd.msft.net ([141.251.56.18]) with mapi id 15.01.0337.009; Wed, 2 Dec 2015 03:02:35 +0000 From: Hongjiang Zhang To: Hooman Fazaeli , "freebsd-net@freebsd.org" Subject: RE: mbuf statistics Thread-Topic: mbuf statistics Thread-Index: AQHRLFIyh2Jd96b2bEud/S1CC0ulRZ63AbuA Date: Wed, 2 Dec 2015 03:02:35 +0000 Message-ID: <7dcef1f0edc04fb9b1ab35ec66383538@SG2PR3002MB0106.064d.mgd.msft.net> References: <565DC558.5090108@gmail.com> In-Reply-To: <565DC558.5090108@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [141.251.58.133] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD035; 1:S2/aQ/nxHFyo0hJeoFJsFd3+NXM1eQ463B2I1y6hWXDS+/y+YZeQydm1NfgI48gkScCkUwLdluaKk4LNVZvny8tIFKpCc0WjnrsKC2fPJyADQrGbjW8pH8f98waawAv9j8dJ3QWFn2H3Sb+gPBCdxvZ3RNtYVarNH0JGu2gzrDBJKx6F1oquOXXcRSAazNG9LDh0IUQ5pZX1q2ySXpICRhs2bkhUzF+1twSRaU4w7z1Y3OaXGvS8PGDkqoSkNkZs3KetMFmBQtKP6QR5MFWWpZeYhcRgstaCB/qYgcsDFdGmoA3YLat3jwcMYZl1gkoEQ1+J7moXIso2S5Dtq3SChrJMI9m25k5pi8sS+oYJqog= X-Forefront-Antispam-Report: CIP:206.191.228.180; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(3905003)(13464003)(199003)(189002)(5005710100001)(47776003)(47136003)(10090500001)(2501003)(92566002)(106116001)(108616004)(50466002)(15975445007)(5004730100002)(2950100001)(586003)(19580395003)(19580405001)(86146001)(1220700001)(50986999)(87936001)(86362001)(23696002)(1096002)(76176999)(16796002)(106466001)(48336001)(86612001)(69596002)(81156007)(66066001)(33646002)(221733001)(5008740100001)(10290500002)(5001960100002)(24736003)(5003600100002)(6116002)(189998001)(2900100001)(97736004)(54356999)(3846002)(107886002)(5001770100001)(6806005)(10400500002)(102836003)(11100500001)(111123002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR03MB093; H:064-smtp-out.microsoft.com; FPR:; SPF:Pass; PTR:ErrorRetry; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; SN2PR03MB093; 2:11nSKIb83wD/kRYhySlRGxorbnET0+G3y0kbmA+9YGrTMQ0uKCifKdGsuYvePq2xA7/Y1XiRAIrw66YJjSVHCmXqubtD4Dc31tvXgiDU1ifWQcWz/I6M6ruX873gn2SAOHitvrPa71fg5W8kFN8Emg==; 3:QConKdVnKOQ8DfVXYDkyaCE01my7O26SIKqrXu7FgaJFjHSg2KwjdNgSbJYHfdv6cBjB4qItZ2ptSyn27HCScRxGKy7lJA8FwtAOvGDwGoqC3E0d0New3qShMWE3Yan+M0/Ph1gwNxgCX1FnwecODgVgnOcPEpuRPkJUtf/Lho2JbYcDln2IYoo6lV43hs+SYgdieY6Ip20VS1J2gBCt5r+XMHupHfMiUtEF7UlX7n46L9jiZeu5dQksoJ2VmRj/TXteIoMygQaBgVpsA1e/wL9yDhGo1cifYtBl2kEKnubnqd3oYeGFPK0zEMfgYLNI; 25:OJ/NOsRaUNyK4VC2JV1K6m9fRVFubd9oZW0PbdeasVprT7D9uYT3U5PJEtWGGOiY9Elnn5mc9M/0kqpiDjYz23+a4EGFO7J3C/Fg2cDQs6B9ExYSGmBXh06qXMZscErJ/mJzPPnZ5L0bz2bRfkpKJV1dQforTGjvMZeB6kI8ZS+smA2gDYwSWpeIRtk+oR4vZclVzWrqPzX+Hi/48Ja7xX1TfvO3yXMmZmStY582xP5oU9ZTWMsvQX7olpJUkaWx X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(42134001)(42139001)(8251501001); SRVR:SN2PR03MB093; X-O365EOP-Header: O365_EOP: AllowList from IP - set SCL to -1 X-Microsoft-Exchange-Diagnostics: 1; SN2PR03MB093; 20:Fp7YhkEwWB2XtwB36f28vxS6MnB618tdWKkeakTe4MJqr0Kw05w5sTvq7Xbq7GdkRKqY538lpaA9zQZOOfKBbQsJvszNhL2nqdC43Duhl+isIONLrR46R9AaVo3mCGHO6VpdJd/oJ/VknKR4eOesSX/7sM3ngatEOmXt4HWHFFlSPzBGz5oadWmOmeOM0vTRF9+EDNmuegw+GfjE4oUw3cBm8u2XLWvUazKRQBvwMp588fWT4jdyEUkNjVwUNnBP7qzBGaoCpAUCoMfegv/KWmkxQlmrX7ocvRFSsCAhZ6/WK8lyBy6ED0k0cwiWAi0DsrGLZKkT852h/kjcjI/4HeGRF6ZS3ldrfnCpdrxplbqu1zqf1OkHfWabRLEfVlXCLPmZKYNv6pAGK6sGBm8fkz8i+H81x4w6+WxLu3M0zfXS9jNBtPq3ydKVio5LHwMh3u0Yzu0Jav8NDJGDLUhQG3n9Z0BoBonscc8g+5sNPi1h0RJ1BOh5yVyXL0cEe8iKxrwQu5Mc4mGVPN+aGZQ7reKU1XNoozBV+w/DQTN5eKyd/at8Xm5/sjEXQW5d/Taw8Eg/oLJYHDR+GitIqQMhejRhBIts6/hLXuBg1RMhfHY= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(202136424685340)(189930954265078)(108003899814671); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:SN2PR03MB093; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB093; X-Microsoft-Exchange-Diagnostics: 1; SN2PR03MB093; 4:uIAK+XiTDk+aIqHVgASn9Vc2ri+mirU/Atz05z11LSh6Fw9ALNfX+Bqt/mAegW6faB8tXgK9Dn2UtF5FA5NuNcWJ+pd7rrGoSmsdljhamJ+w4WF3ZWpT0CMr9ryAQuaw1krHE9WxumMGe4H+NmkSwtnwHgWPqouI+JGJmLXDx4C0fmIBCsRL4aJzUMLNvgs1XxJIuQ+rSDuQNGukGgrpQUB76KC756zP1ZsYr9W8uXmdyjaXhMfzayKnS1T2kLoFNzbdLeNRxUYR7FV09S2C3ZwbDfD43922W6R9ljSi0+drmO4FoOKb6962d36aYm/CbJ43/2AaSQqOrseeR1dHaIIno11HoxS+APXBeSJ0k9lxqyi5tSO3ZMiik8YF3blPslO1suVXRg1aR3uFYWDefei0TnyjGpp5btSEJfsH3jpcCIU+a08nWNqLI7G5kEd5tPgaPsgLjtZeRwC5cyru0Z/yURYyXOJQXAFb5sCF3E1ZGVIVFSUVQ4BjTJgth1LAfu9bWTKZVfu8PmwfWOoh4xROSwq7hYCW3j3N6YV9+Nm2Uqwicd+NZUYnMYTWKvTn X-Forefront-PRVS: 077884B8B5 X-Microsoft-Exchange-Diagnostics: =?gb2312?B?MTtTTjJQUjAzTUIwOTM7MjM6ZnEyRVE5YU9HeHkvL0k3ckd6V1JJWUErUFll?= =?gb2312?B?bEh4Z3RtRG5pNE52dmRLYTFTWFJuVkhvbjA3SURISlI2dmRLRk1VbVRjVlhZ?= =?gb2312?B?emNMNlk5ZHJhZXRGbUN0NDNxK1BzSVFLRnJ1bmtxSkMrTzd5bm5sWEJrOERz?= =?gb2312?B?blI2WjJHUko2WHhVMFpaY0dDdVNiT3IreHBKN2FzWi9pL1BPeVBpZmtkV25Y?= =?gb2312?B?MWtQTmlpTE1IeThYbnBEWmkxSFo0Q3FtTld0ZSttS1hJQzRPZkgwaDB2R01r?= =?gb2312?B?SURVVk5UNUR1dENkQ3BJM25JVWc3TmR6S21MbHk1bFlTRHNzVzIvVTRaMWJQ?= =?gb2312?B?cDZKVUw0amJidE9oWDFaV1VDQU8vUUVWTS9OK3dva0hrTFBEWWdBN3lDY1dQ?= =?gb2312?B?TldpQ2pUL1ZuSVF4WlA5VjhOMndoRnI4QzZwcWtJWGpnMmlPYXBjK3dNaEdy?= =?gb2312?B?NkNZS1o2cGQvU0JaNXFvZ056Ti9NWE9XUlpMcHlGSFJaVVBkM1JpRVo5VDA4?= =?gb2312?B?dTkvOGxaTW9UQVVsME1aSStmQ1YvMFV5cTlGTnE3QTFieUFlbmtBakcyR2tw?= =?gb2312?B?RmpFai9rMzlTcG9HZ1Z0bFJGQmxVK2VrMnpKM0JUczk0Ri96ZExXdHB3RDlw?= =?gb2312?B?TE9qdlo1SlVHSWtrbG5YMDRaZkk1Sy9POEhRRyt5WlhoT2lyVDRUc21JMk1M?= =?gb2312?B?Slp6SDJGa0V6RDNCV1pkb0NRUTNRRmtBSTVQSkhjd3N2ZktYWmtCc3lwYzV2?= =?gb2312?B?NTN4dHBQbE1ta3VtS1pOUytPb29ETFRoZ1dISmwzeWNMOVdCNVNTSDdRZ0p0?= =?gb2312?B?bTBaUGwxSDZEVHovUHFWVERWQ2l1TnIvNDZoaUNtSHpvRHJkZkxLKzcyU2Vl?= =?gb2312?B?Tm1TUjR5VDRSUUY3UEFycXF3UWE3UUh1NzhZT3RrZUVxUFhhcDhLNU85VCty?= =?gb2312?B?S29Fb0UzUWdiUyt2dlA4djduU2tXUVVhSXp0WHNhOFJXd2FUdmx4WGk0NmpP?= =?gb2312?B?L1h5V1JvbUdDOXljZ244OXdWMXZDTFhKYlJsaUJLVkR5N2xqSW5ZRE11MzRJ?= =?gb2312?B?SzZ0a0s0UkI5MFhBdnBQWEpnOEFGd0d3b25vSDlMT0M5SENweTVlUmJLWDVR?= =?gb2312?B?d1EzNDd0anpCOE44T0NYQ1FTRjUzZ1JLSFJKc2czNFJCc1I5UjVyZ3ZkdDN5?= =?gb2312?B?NWMwM0FKN0c3VHFNNEl6bEQ1a2M3NGtSZHJkdGN2MDdUY0pOUk5uQVY2QURr?= =?gb2312?B?MVNNbG8rNTR4TlJHeVNQSXZlTllodkdWYkVmY2F1TGROR2hlUW5sK1hRTVph?= =?gb2312?B?a04wUEQyMENKODBiN2pQL2d6czRmakVucU1IbWgvNGZHbzZ1YTFwSkh1eXBy?= =?gb2312?B?MWE4WExuWjYvaWRXMjFvbVFUMXM1QVVFdFFmSlN2WVlULzlUZUw1WnFSY2Zh?= =?gb2312?B?MjJYckoxSmJXc2k4NFluZW9lZ2JjVXFrZ3BNUklsYTE0Vi9ZY0hscDJ6aXNY?= =?gb2312?B?Z2FNdGk1QmFpSGNJV0tjU0lob2xPSDRycGNPKzFmYXRsNldtVGdvekRkbkh6?= =?gb2312?B?NzVicXVVNEsxaW85ZlRxL3dIOGpKQW1PN3BEOUd4SG5aSFJIQnZzN1lmVk9q?= =?gb2312?B?SitCeW9ONStDaXBTYnF5a2xtd2h6Wi9xQXREY1lmKzFFMzlkYzQ5R0VCRXdv?= =?gb2312?B?cjN5YlAvaXdMWnRBMStYZitPcDNFVXZMSG5WUFM3Wk8zMGJ3eW1PL2tkWGJX?= =?gb2312?B?b3g3OE1YQTRuNjVld3RCTU1BMSs0cHkzb1hueEdOcEszVG1XR05pUURrSEUw?= =?gb2312?B?U2gzc3NLZW0xenhrd3Z5N2RvN0Q3dTRFVFYxbHJaMU05ZkdCTVRHbHRycExC?= =?gb2312?B?MVFEWGVFWVRnd2E3ZEhOeVgrakt1VFBaZXkremk2UVBoV0Y0dCtmQmx3NXhR?= =?gb2312?B?YkhQbXE5cmRCY2VjamprZktFOGNnL0pqTDJsWm1Pa1NzU1gvNlM4WkdiM0xY?= =?gb2312?Q?x2H2l?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR03MB093; 5:DCKRGcMbNf+iYEnlOdxE8Sim3Bb/H060nfb+dkq8qFjijTwncCpIlNPuqtJ5/ymz/c5Xzp8zz7fXchoCdorMUqmtaMI6NtJhikTfViccbQW/JG8dmCW/D+yz1unWtc/EbVqA2yRaR5YEEziF/jTJhw==; 24:BjAaJTrweJur9ka47CUFrZlSKkm35nRmkTLjVYmt1SOkK8a4G8hmD6hmn3ko8LUGBRKtNihwQJ6qeJoq/Puje4Qizu7DZMBP1xdg3WIRq2Y= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Dec 2015 03:02:47.5872 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[206.191.228.180]; Helo=[064-smtp-out.microsoft.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB093 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 03:17:22 -0000 SSBjYW4gb2JzZXJ2ZSB0aGUgc2FtZSBwaGVub21lbmEgb24gRnJlZUJTRCAxMC4yOiBjdXJyZW50 K2NhY2hlPT10b3RhbD09VVNFRCtGUkVFLg0KVGhlcmUgbXVzdCBiZSBzb21lIHJlbGF0aW9uc2hp cCBiZXR3ZWVuIHRoZW0uDQoNCiQgbmV0c3RhdCAtbWJ8Z3JlcCAibWJ1ZiBjbHVzdGVycyINCjAv NzY2Lzc2Ni8xMjYxNDYgbWJ1ZiBjbHVzdGVycyBpbiB1c2UgKGN1cnJlbnQvY2FjaGUvdG90YWwv bWF4KQ0KDQokIHZtc3RhdCAtenxlZ3JlcCAibWJ1Zl9jbHVzdGVyfElURU0ifGNvbHVtbiAtdA0K SVRFTSAgICAgICAgICAgU0laRSAgIExJTUlUICAgIFVTRUQgIEZSRUUgIFJFUSAgIEZBSUwgIFNM RUVQDQptYnVmX2NsdXN0ZXI6ICAyMDQ4LCAgMTI2MTQ2LCAgNzU5LCAgNywgICAgNzU5LCAgMCwg ICAgMA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogb3duZXItZnJlZWJzZC1u ZXRAZnJlZWJzZC5vcmcgW21haWx0bzpvd25lci1mcmVlYnNkLW5ldEBmcmVlYnNkLm9yZ10gT24g QmVoYWxmIE9mIEhvb21hbiBGYXphZWxpDQpTZW50OiAyMDE1xOoxMtTCMsjVIDA6MDYNClRvOiBm cmVlYnNkLW5ldEBmcmVlYnNkLm9yZw0KU3ViamVjdDogbWJ1ZiBzdGF0aXN0aWNzDQoNCg0KSGks DQoNCk9uIGFuIGlkbGUgZnJlZWJzZCA5LjMgc3lzdGVtOg0KDQo+IHZtc3RhdCAteiB8IGVncmVw ICJtYnVmX2NsdXN0ZXJ8SVRFTSIgfCBjb2x1bW4gLXQNCklURU0gICAgICAgICAgIFNJWkUgICBM SU1JVCAgIFVTRUQgICBGUkVFICBSRVEgICAgRkFJTCAgU0xFRVANCm1idWZfY2x1c3RlcjogIDIw NDgsICAxMDI4NCwgIDExNTIsICA1NiwgICA0MjM3LCAgMCwgICAgMA0KDQo+IG5ldHN0YXQgLW1i IHwgZ3JlcCAibWJ1ZiBjbHVzdGVycyBpbiB1c2UiDQo1MTIvNjk2LzEyMDgvMTAyODQgbWJ1ZiBj bHVzdGVycyBpbiB1c2UgKGN1cnJlbnQvY2FjaGUvdG90YWwvbWF4KQ0KDQpvbmUgY2FuIHNlZSB0 aGF0Og0KDQpjdXJyZW50ICsgY2FjaGUgPT0gdG90YWwgPT0gVVNFRCArIEZSRUUNCg0KYnV0IHRo ZSBjdXJyZW50L2NhY2hlIHZhbHVlcyBhcyByZXBvcnRlZCBieSBuZXRzdGF0IGFyZSB2ZXJ5IGRp ZmZlcmVudCBmb3JtIFVTRUQvRlJFRSB2YWx1ZXMgcmVwb3J0ZWQgYnkgdm1zdGF0LCBzbyB0aGV5 IHNob3VsZCBoYXZlIGRpZmZlcmVudCBtZWFuaW5nLg0KDQpUaGUgcXVlc3Rpb24gaXM6IHdoYXQg aXMgdGhlIGV4YWN0IG1lYW5pbmcgb2YgVVNFRC9GUkVFIGFuZCBjdXJyZW50L2NhY2hlIHZhbHVl cz8gSXMgdGhlcmUgYW55IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZW0/DQoNCi0tDQpCZXN0IHJl Z2FyZHMNCkhvb21hbiBGYXphZWxpDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpmcmVlYnNkLW5ldEBmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QNCmh0 dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNh JTJmJTJmbGlzdHMuZnJlZWJzZC5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZmcmVlYnNkLW5l dCZkYXRhPTAxJTdjMDElN2Nob256aGFuJTQwMDY0ZC5tZ2QubWljcm9zb2Z0LmNvbSU3YzIzYjRm NGFiYmNlYjRmNzE3ZmJhMDhkMmZhNjk1MTM0JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAx MWRiNDclN2MxJnNkYXRhPWRwcnZhaERVWWRvTVlpMjJuT0hNZXMzODVuZ2M0Z0o2U0g4YUhYOExI aUElM2QNClRvIHVuc3Vic2NyaWJlLCBzZW5kIGFueSBtYWlsIHRvICJmcmVlYnNkLW5ldC11bnN1 YnNjcmliZUBmcmVlYnNkLm9yZyINCg== From owner-freebsd-net@freebsd.org Wed Dec 2 04:40:06 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B3E7FA3FDAF for ; Wed, 2 Dec 2015 04:40:06 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 81D5D1542; Wed, 2 Dec 2015 04:40:06 +0000 (UTC) (envelope-from julian@freebsd.org) 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.15.2/8.15.2) with ESMTPSA id tB24drc7009490 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 1 Dec 2015 20:39:57 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: IPFW blocked my IPv6 NTP traffic To: elof2@sentor.se, Mark Felder References: <1448920706.962818.454005905.61CF9154@webmail.messagingengine.com> <1448956697.854911427.15is5btc@frv34.fwdcdn.com> <1448982333.1269981.454734633.11BA4DB2@webmail.messagingengine.com> Cc: freebsd-net , wishmaster From: Julian Elischer Message-ID: <565E7613.1070303@freebsd.org> Date: Wed, 2 Dec 2015 12:39:47 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 04:40:06 -0000 On 2/12/2015 12:27 AM, elof2@sentor.se wrote: > On Tue, 1 Dec 2015, Mark Felder wrote: > >> >> >> On Tue, Dec 1, 2015, at 02:02, wishmaster wrote: >>> >>> Hi, Mark. >>> >>> >>>> I'm hoping someone can explain what happened here and this isn't >>>> a bug, >>>> but if it is a bug I'll gladly open a PR. >>>> >>>> I noticed in my ipfw logs that I was getting a log of "DENY" >>>> entries for >>>> an NTP server >>>> >>>> Nov 30 13:35:16 gw kernel: ipfw: 4540 Deny UDP >>>> [2604:a880:800:10::bc:c004]:123 [2001:470:1f11:1e8::2]:58285 in >>>> via gif0 > > Three long-shots: > > 1) > I see that you use a gif interface. That makes me wonder: > Do the 'keep-state' function in 'ipfw' work as bad as it does in 'pf'? Not to solve the problem here, but to give some general education, the keep-state in ipfw keeps a pointer to the action section of the rule that generates it, and if another packet from the same session is detected, the same action section is executed again. so, for example if the action section is "skipto 2" it will skip to rule 2, regardless of where it is. (it's theoretically possible to crash/hang your system that way by having a rule skip to a rule before itself, which is not normally allowed). No notice is taken of where ipfw was called from or what interface introduced the packet.. Only source and destination addresses (and ports) and the protocol are examined. (no ports if icmp). > > In pf, 'keep state" doesn't keep state between software network > interfaces and real network interfaces. So if I allow something in > via tun0 (a software OpenVPN NIC), with keep state, the response is > *not* automatically (via the state table) allowed back in on the > ethernet NIC it was sent out. So for all my VPN-rules, I have to > make two of them like this: > > Pf example: > pass in quick on tun0 inet proto tcp from to > port 22 keep state label "VpnIN - SSH" > pass out quick on em1 inet proto tcp from to > port 22 keep state label "DmzOUT - SSH" > > > > 2) > Is this hapening over and over, or was it just a one time thing? > If the latter, could it be that you flushed your firewall state > table just after a cron job ran 'ntpdate 2604:a880:800:10::bc:c004', > so the query got out but immediately after the state table was > emptied and hence the response got blocked? > > > > 3) > If 2001:470:1f11:1e8::2 is not the ipfw node itself, but some node > behind it, could the ntp query to 2604:a880:800:10::bc:c004 have > taken a different path? I.e. the ipfw node doesn't see the query, > but the response packet is routed to it, so it gets blocked. > > /Elof > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@freebsd.org Wed Dec 2 15:52:58 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36BD3A3EB34 for ; Wed, 2 Dec 2015 15:52:58 +0000 (UTC) (envelope-from daniel.bilik@neosystem.cz) Received: from mail.neosystem.cz (mail.neosystem.cz [94.23.169.88]) (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 ECD711922; Wed, 2 Dec 2015 15:52:57 +0000 (UTC) (envelope-from daniel.bilik@neosystem.cz) Received: from mail.neosystem.cz (unknown [127.0.10.15]) by mail.neosystem.cz (Postfix) with ESMTP id 073C7B339; Wed, 2 Dec 2015 16:52:49 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.neosystem.cz Received: from dragon.sn.neosystem.cz (unknown [IPv6:2001:41d0:2:5ab8::100:101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.neosystem.cz (Postfix) with ESMTPSA id 5F691B332; Wed, 2 Dec 2015 16:52:47 +0100 (CET) Date: Wed, 2 Dec 2015 16:48:05 +0100 From: Daniel Bilik To: Julian Elischer Cc: freebsd-net@freebsd.org Subject: Re: Outgoing packets being sent via wrong interface Message-Id: <20151202164805.575ce2d315fc8708f660d861@neosystem.cz> In-Reply-To: <20151201121645.dbcf4bf900fd657a6e4ae3b4@neosystem.cz> References: <20151120155511.5fb0f3b07228a0c829fa223f@neosystem.org> <20151120163431.3449a473db9de23576d3a4b4@neosystem.org> <20151121212043.GC2307@vega.codepro.be> <20151122130240.165a50286cbaa9288ffc063b@neosystem.cz> <20151125092145.e93151af70085c2b3393f149@neosystem.cz> <20151125122033.GB41119@in-addr.com> <20151127101349.752c94090e78ca68cf0f81fc@neosystem.org> <56597CB5.7030307@freebsd.org> <20151130101838.e59be3db0eb3922d87544b16@neosystem.cz> <565C6F86.7090108@freebsd.org> <20151201090332.09b038935b8eabf33288c24c@neosystem.cz> <565D7552.30806@freebsd.org> <20151201121645.dbcf4bf900fd657a6e4ae3b4@neosystem.cz> X-Mailer: Sylpheed 3.4.3 (GTK+ 2.24.28; x86_64-portbld-dragonfly4.5) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 15:52:58 -0000 On Tue, 1 Dec 2015 12:16:45 +0100 Daniel Bilik wrote: > But next time it happens, I'll try to reload pf rules, and also to > disable pf completely... Done. First I've tried to flush nat... # pfctl -f /etc/pf.conf -F nat -O -N nat cleared ... then rules... # pfctl -f /etc/pf.conf -F rules -O -R -Tl rules cleared ... but neither has helped. Ping to affected host has been reporting the known error all the time... ping: sendto: Operation not permitted Next, I've disabled pf completely... # pfctl -d pf disabled ... which changed ping error message to... ping: sendto: Host is down ... and tcpdump(1) confirmed that packets are still going via wrong interface... # tcpdump -i re0 -n icmp 07:54:44.538326 IP 82.x.y.50 > 192.168.2.33: ICMP echo request, id 54720, seq 24, length 64 ... now not being dropped by pf, but without any echo response (for obvious reasons). Again, refreshing default route solved the problem instantly. -- Dan From owner-freebsd-net@freebsd.org Wed Dec 2 22:35:24 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0DB31A3F442 for ; Wed, 2 Dec 2015 22:35:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E1D291A81 for ; Wed, 2 Dec 2015 22:35:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tB2MZNGQ080172 for ; Wed, 2 Dec 2015 22:35:23 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 189219] [dummynet] [patch] using dummynet on sparc64 and configuring a pipe is an insta-panic Date: Wed, 02 Dec 2015 22:35:24 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: lidl@pix.net X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 22:35:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189219 lidl@pix.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lidl@pix.net --- Comment #5 from lidl@pix.net --- I was able to replicate this on my sparc V120 machine today, running a pretty recent head (r291431). To reproduce this, I issued the following commands on the console: root@ton-128: /etc/rc.d/ipfw onestart root@ton-129: kldload dummynet DUMMYNET 0 with IPv6 initialized (100409) load_dn_sched dn_sched FIFO loaded load_dn_sched dn_sched QFQ loaded load_dn_sched dn_sched RR loaded load_dn_sched dn_sched WF2Q+ loaded load_dn_sched dn_sched PRIO loaded root@ton-130: ipfw pipe 1 config bw 100mbit panic: trap: memory address not aligned (kernel) cpuid = 0 KDB: stack backtrace: vpanic() at vpanic+0x1b4 panic() at panic+0x20 trap() at trap+0x5cc -- memory address not aligned sfar=0xfffff800015dee7c sfsr=0x40029 %o7=0xc4ac3518 -- userland() at do_config+0x59c user trace: trap %o7=0xc4ac3518 pc 0xc4ac2d9c, sp 0xee550831 done KDB: enter: panic [ thread pid 8997 tid 100587 ] Stopped at kdb_enter+0x80: ta %xcc, 1 Backtrace from the savecore run: KDB: enter: panic Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /usr/lib/debug// boot/kernel/zfs.ko.debug...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /usr/lib /debug//boot/kernel/opensolaris.ko.debug...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from /usr/lib /debug//boot/kernel/geom_mirror.ko.debug...done. done. Loaded symbols for /boot/kernel/geom_mirror.ko Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from /usr/lib/debug //boot/kernel/tmpfs.ko.debug...done. done. Loaded symbols for /boot/kernel/ipfw.ko Reading symbols from /boot/kernel/dummynet.ko...Reading symbols from /usr/lib/debug//boot/kernel/dummynet.ko.debug...done. done. Loaded symbols for /boot/kernel/dummynet.ko #0 0x00000000c05dd3a0 in doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:295 295 savectx(&dumppcb); (kgdb) #0 0x00000000c05dd3a0 in doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:295 #1 0x00000000c011c8d0 in db_dump (dummy=3227700832, dummy2=false, dummy3=-1, dummy4=0xee5504e0 "") at /usr/src/sys/ddb/db_command.c:533 #2 0x00000000c011ba04 in db_command (last_cmdp=0xc0d11880, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:440 #3 0x00000000c011bd14 in db_command_loop () at /usr/src/sys/ddb/db_command.c:493 #4 0x00000000c011fb74 in db_trap (type=, code=0) at /usr/src/sys/ddb/db_main.c:251 #5 0x00000000c062d70c in kdb_trap (type=107, code=0, tf=0xee5509f0) at /usr/src/sys/kern/subr_kdb.c:654 #6 0x00000000c09df4e0 in trap (tf=0xee5509f0) at /usr/src/sys/sparc64/sparc64/trap.c:344 #7 0x00000000c00b1080 in tl1_trap () #8 0x00000000c062ce60 in kdb_enter (why=0x12
, msg=0xc0bcfdc0 "panic") at /usr/src/sys/kern/subr_kdb.c:442 #9 0x00000000c062ce48 in kdb_enter (why=0xc0bcfdc0 "panic", msg=0xc0bcfdc0 "panic") at /usr/src/sys/kern/subr_kdb.c:441 #10 0x00000000c05dde00 in vpanic (fmt=0xc0c1b9a8 "trap: %s (kernel)", ap=0xee550dc8) at /usr/src/sys/kern/kern_shutdown.c:750 #11 0x00000000c05dde68 in panic (fmt=0xc0c1b9a8 "trap: %s (kernel)") at /usr/src/sys/kern/kern_shutdown.c:688 #12 0x00000000c09df754 in trap (tf=0xee550f30) at /usr/src/sys/sparc64/sparc64/trap.c:410 #13 0x00000000c00b1080 in tl1_trap () #14 0x00000000c4ac2d9c in do_config (p=, l=0) at /usr/src/sys/modules/dummynet/../../netpfil/ipfw/ip_dummynet.c:1235 #15 0x00000000c4ac3520 in do_config (p=, l=152) at /usr/src/sys/modules/dummynet/../../netpfil/ipfw/ip_dummynet.c:1540 #16 0x00000000c4ac3c40 in ip_dn_ctl (sopt=0xee551580) at /usr/src/sys/modules/dummynet/../../netpfil/ipfw/ip_dummynet.c:2112 #17 0x00000000c078a8dc in rip_ctloutput (so=0xfffff800055d2e88, sopt=0xee551580) at /usr/src/sys/netinet/raw_ip.c:661 #18 0x00000000c0688814 in sosetopt (so=0xfffff800055d2e88, sopt=0xee551580) at /usr/src/sys/kern/uipc_socket.c:2493 #19 0x00000000c0690930 in kern_setsockopt (td=0xfffff80096b0a9a0, s=3, level=0, name=49, val=0x40a18000, valseg=UIO_USERSPACE, valsize=) at /usr/src/sys/kern/uipc_syscalls.c:1459 #20 0x00000000c06909e8 in sys_setsockopt (td=0xfffff80096b0a9a0, uap=0xee551768) at /usr/src/sys/kern/uipc_syscalls.c:1413 #21 0x00000000c09de68c in syscall (tf=0xee551880) at subr_syscall.c:140 #22 0x00000000c00b0e60 in tl0_intr () #23 0x0000000000000000 in ?? () (kgdb) -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Wed Dec 2 23:45:32 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ACA4AA3F4C1 for ; Wed, 2 Dec 2015 23:45:32 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 459FF19DE for ; Wed, 2 Dec 2015 23:45:31 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by wmuu63 with SMTP id u63so199674wmu.0 for ; Wed, 02 Dec 2015 15:45:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-type; bh=TjLLQoOh0dmD4xugFArWPaYmc2gCunyresZm30MXqmQ=; b=qqTZpt04Ilho3Qk3xHCoVH3+u4nIROKuhSnYml1bl8yxJhZgyWbywA67fIXw+cR86H 3XmUXwtVi0LqeWQan3+JlGnCmxnxYb9q0fclgfHIMORl8dp3GQxcyJeRNGQLvxHfhW9G fcVDHrx2dKihNQBs/Yc7CTJDyhUUByboAp6qgMuLX5fHCSYxJVvWo9NAnXAP0ptKnGWi qYjYWb/CQOXycKdyesWJOlZB9BPzh+F5o/5kIQ/lX1QunPDn/6I3LZAkrFEtA2jTWv/T yS5SzSHllIH/Is/jMzLX2CI1n3UDn9JcvB3bcOM0AczXd/i8yhMwYjCarwr2Pu10JYGS v+SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-type; bh=TjLLQoOh0dmD4xugFArWPaYmc2gCunyresZm30MXqmQ=; b=dZjhznRq5lSR0+2QdMJKxx6IoufprWrqu92FziHhXOAliDqmMp4Dto+bw/N/Ke5wQJ tuSWA3AIec0rpYVJH1aRXZINS+6AwTMddeG5lyAMOCLnZ88SOUGfeoOvYucshA1xGvdn bxiK/fHdS4C964yPnB4vpb2q92qkgLBi26S1T8VN6WDTbb3ibOwd2PKNddv/H/lksp8/ 9Hrqj1HWVoWlH4fRxMSG6WaL5BKyCMza1WvF0Ufl3PDkgDvGnrMjezFHmGTE4LtolIeR ku9fD+qZDYDG67QDMUH1iyPKvnVfZ/dk8bW+rLQs0tmgXNJivelqiJd7dIQolxRmiSbr wRBw== X-Gm-Message-State: ALoCoQn4vtRO7BBDLwLCPCaIv0IQaqeEq1VUeG6AvmNONqgGy8j/COk7dJerN1of/aXCktT5vxWp X-Received: by 10.194.7.230 with SMTP id m6mr7554986wja.124.1449099929765; Wed, 02 Dec 2015 15:45:29 -0800 (PST) Received: from [10.10.1.58] (liv3d.labs.multiplay.co.uk. [82.69.141.171]) by smtp.gmail.com with ESMTPSA id b82sm33174942wmf.9.2015.12.02.15.45.28 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Dec 2015 15:45:28 -0800 (PST) To: "freebsd-net@freebsd.org" From: Steven Hartland Subject: Intel X710 NVM - Update not available Message-ID: <565F829A.5080406@multiplay.co.uk> Date: Wed, 2 Dec 2015 23:45:30 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 23:45:32 -0000 When starting on both FreeBSD and Linux the latest driver complains that the NVM should be updated. As there's no FreeBSD NVM update utility available I got the machine temporarily booted into Linux however the updater reports: "Update not available" I've attached the log from an inventory run which I believe identifies the card as a dual port X710: [02:00:00]: Intel(R) Ethernet Converged Network Adapter X710 LAN MAC: 3CFDFE007460 Alt MAC: 000000000000 SAN MAC: 3CFDFE007461 EEPROM: ETrackId: 80001867, Checksum valid VPD: Size: 152 Flash: Size: 8388608, CIVD: 16.5.10 Vendor: 8086 Device: 1572 Subvendor: 8086 Subdevice: 6 Revision: 1 Type: PXE, Version: 1.0.10, Checksum: Not Relevant Type: ISCSI, Version: 3.0.44, Checksum: Not Relevant Type: ISCSI_SETUP, Version: 3.0.44, Checksum: Not Relevant Type: EFI_X64, Version: 1.1.33, Checksum: None Type: CLP_LOADER, Version: 3.0.30, Checksum: Valid Type: IMAGE_SHARED_40G, Version: 1.0.7, Checksum: Not Relevant Looking in nvmupdate.cfg the device matches the XL710 but there's no match for EEPID which I believe corrisponds to the EEPROM: EtrackID of 80001867. So the question is where do I get the right NVM update from? ./nvmupdate64e -l update.log Intel(R) Ethernet NVM Update Tool NVMUpdate version 1.25.20.12 Copyright (C) 2013 - 2015 Intel Corporation. WARNING: TO AVOID DAMAGE TO YOUR DEVICE, DO NOT EXIT OR REBOOT OR POWER OFF THE SYSTEM DURING THIS UPDATE Inventory in progress. Please wait [*-........] Num Description Device-Id B:D Adapter Status === ====================================== ========= ===== ==================== 01) Intel(R) Ethernet Converged Network Ad 8086-1572 02:00 Update not available 02) Intel(R) 82574L Gigabit Network Connec 8086-10D3 03:00 Not supported 03) Intel(R) 82574L Gigabit Network Connec 8086-10D3 04:00 Not supported Tool execution completed with the following status: All operations completed successfully Press any key to exit. From owner-freebsd-net@freebsd.org Thu Dec 3 00:44:39 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66486A3E904 for ; Thu, 3 Dec 2015 00:44:39 +0000 (UTC) (envelope-from jeffrey.e.pieper@intel.com) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mx1.freebsd.org (Postfix) with ESMTP id 472B9111D for ; Thu, 3 Dec 2015 00:44:39 +0000 (UTC) (envelope-from jeffrey.e.pieper@intel.com) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP; 02 Dec 2015 16:44:39 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,375,1444719600"; d="scan'208";a="863464405" Received: from orsmsx106.amr.corp.intel.com ([10.22.225.133]) by orsmga002.jf.intel.com with ESMTP; 02 Dec 2015 16:44:37 -0800 Received: from orsmsx111.amr.corp.intel.com ([169.254.12.27]) by ORSMSX106.amr.corp.intel.com ([10.22.225.133]) with mapi id 14.03.0248.002; Wed, 2 Dec 2015 16:44:37 -0800 From: "Pieper, Jeffrey E" To: Steven Hartland , "freebsd-net@freebsd.org" Subject: RE: Intel X710 NVM - Update not available Thread-Topic: Intel X710 NVM - Update not available Thread-Index: AQHRLVuTXi8PnSi1Ok+91vgFye2CZ564bL3w Date: Thu, 3 Dec 2015 00:44:37 +0000 Message-ID: <2A35EA60C3C77D438915767F458D6568808FCC8A@ORSMSX111.amr.corp.intel.com> References: <565F829A.5080406@multiplay.co.uk> In-Reply-To: <565F829A.5080406@multiplay.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsIiwiaWQiOiI5ZmNhNzk4MS1jNWVlLTQzOGQtYmQ1YS03ZTFmN2RlNWFlNjEiLCJwcm9wcyI6W3sibiI6IkludGVsRGF0YUNsYXNzaWZpY2F0aW9uIiwidmFscyI6W3sidmFsdWUiOiJDVFBfUFVCTElDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjQuMTAuMTkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiY1NOZ0hHeGpPR2ZkTThiMDhlK1RidEN0NjdPRGlIZGplbFVuYWx0ajFrdz0ifQ== x-inteldataclassification: CTP_PUBLIC x-originating-ip: [10.22.254.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 00:44:39 -0000 Steve, Subdevice: 6 indicates that this is a Dell SKU, and as such I don't believe= their NVMs are included in Intel's public NVMUpdate tool. You'll need to u= se Dell's version, which you can find here: http://www.dell.com/support/home/us/en/19/Drivers/DriversDetails?driverId= =3DKWCDH Thanks, Jeff -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] = On Behalf Of Steven Hartland Sent: Wednesday, December 02, 2015 3:46 PM To: freebsd-net@freebsd.org Subject: Intel X710 NVM - Update not available When starting on both FreeBSD and Linux the latest driver complains that=20 the NVM should be updated. As there's no FreeBSD NVM update utility available I got the machine=20 temporarily booted into Linux however the updater reports: "Update not available" I've attached the log from an inventory run which I believe identifies=20 the card as a dual port X710: [02:00:00]: Intel(R) Ethernet Converged Network Adapter X710 LAN MAC: 3CFDFE007460 Alt MAC: 000000000000 SAN MAC: 3CFDFE007461 EEPROM: ETrackId: 80001867, Checksum valid VPD: Size: 152 Flash: Size: 8388608, CIVD: 16.5.10 Vendor: 8086 Device: 1572 Subvendor: 8086 Subdevice: 6 Revision: 1 Type: PXE, Version: 1.0.10, Checksum: Not Relevant Type: ISCSI, Version: 3.0.44, Checksum: Not Relevant Type: ISCSI_SETUP, Version: 3.0.44, Checksum: Not Relevant Type: EFI_X64, Version: 1.1.33, Checksum: None Type: CLP_LOADER, Version: 3.0.30, Checksum: Valid Type: IMAGE_SHARED_40G, Version: 1.0.7, Checksum: Not Relevant Looking in nvmupdate.cfg the device matches the XL710 but there's no=20 match for EEPID which I believe corrisponds to the EEPROM: EtrackID of=20 80001867. So the question is where do I get the right NVM update from? ./nvmupdate64e -l update.log Intel(R) Ethernet NVM Update Tool NVMUpdate version 1.25.20.12 Copyright (C) 2013 - 2015 Intel Corporation. WARNING: TO AVOID DAMAGE TO YOUR DEVICE, DO NOT EXIT OR REBOOT OR POWER=20 OFF THE SYSTEM DURING THIS UPDATE Inventory in progress. Please wait [*-........] Num Description Device-Id B:D Adapter Status =3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D= =3D=3D =3D=3D=3D=3D=3D=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 01) Intel(R) Ethernet Converged Network Ad 8086-1572 02:00 Update not=20 available 02) Intel(R) 82574L Gigabit Network Connec 8086-10D3 03:00 Not supported 03) Intel(R) 82574L Gigabit Network Connec 8086-10D3 04:00 Not supported Tool execution completed with the following status: All operations=20 completed successfully Press any key to exit. _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@freebsd.org Thu Dec 3 01:00:21 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A475FA3EB2E for ; Thu, 3 Dec 2015 01:00:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 86D9A159C for ; Thu, 3 Dec 2015 01:00:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tB310LK9095970 for ; Thu, 3 Dec 2015 01:00:21 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 189219] [dummynet] [patch] using dummynet on sparc64 and configuring a pipe is an insta-panic Date: Thu, 03 Dec 2015 01:00:21 +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: marius@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 01:00:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189219 --- Comment #6 from Marius Strobl --- (In reply to Michael Moll from comment #2) That patch is overly complicated for solving the unaligned access triggered by config_link(); it's way simpler to just fix do_config() to properly align dn_link before passing it on in the first place. Moreover, the latter also is the actual culprit here as do_config() casts a random chunk of memory to a struct dn_link pointer. Note, though, that the config_link() triggered unaligned access is only one instance of dummynet(4) misaligning dn_link. The following is a complete fix in that regard: http://people.freebsd.org/~marius/dummynet_unfuck_dn_link.diff However, the same incorrect patterns are used for virtually all of dn_ and additionally in some other stuff like flow ID related functions. So someone still needs to sit down and go through the entirety of ip_dummynet.c, fixing all other unaligned accesses. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Thu Dec 3 07:10:53 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9C8C9A3E69B for ; Thu, 3 Dec 2015 07:10:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 816961F87 for ; Thu, 3 Dec 2015 07:10:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tB37Ar7W081774 for ; Thu, 3 Dec 2015 07:10:53 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 189219] [dummynet] [patch] using dummynet on sparc64 and configuring a pipe is an insta-panic Date: Thu, 03 Dec 2015 07:10:53 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: crash, needs-qa, patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 07:10:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189219 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |crash, needs-qa, patch -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Thu Dec 3 07:11:55 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB2F0A3E6E3 for ; Thu, 3 Dec 2015 07:11:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B806B10CA for ; Thu, 3 Dec 2015 07:11:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tB37Btkx086270 for ; Thu, 3 Dec 2015 07:11:55 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 189219] [dummynet] [patch] using dummynet on sparc64 and configuring a pipe is an insta-panic Date: Thu, 03 Dec 2015 07:11:55 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: crash, needs-qa, patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 07:11:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189219 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Progress |Open --- Comment #7 from Kubilay Kocak --- Issue shouldn't be 'In Progress' without an Assignee. reset. Who wants to pick this up? -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Thu Dec 3 08:27:21 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45323A3FE00 for ; Thu, 3 Dec 2015 08:27:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 31D6D1082 for ; Thu, 3 Dec 2015 08:27:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tB38RLnV068309 for ; Thu, 3 Dec 2015 08:27:21 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 204437] 10.2 STABLE Crashing with IPSec Support Date: Thu, 03 Dec 2015 08:27:20 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: crash, needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: emeric.poupon@stormshield.eu X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: mfc-stable9? mfc-stable10? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 08:27:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204437 --- Comment #20 from emeric.poupon@stormshield.eu --- Done: https://svnweb.freebsd.org/base?view=revision&revision=291652 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Thu Dec 3 08:39:14 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A89AA3C04D for ; Thu, 3 Dec 2015 08:39:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 36D33163F for ; Thu, 3 Dec 2015 08:39:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tB38dEqZ090887 for ; Thu, 3 Dec 2015 08:39:14 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 204437] 10.2 STABLE Crashing with IPSec Support Date: Thu, 03 Dec 2015 08:39:14 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: crash, patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fabient@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: mfc-stable9? mfc-stable10+ X-Bugzilla-Changed-Fields: keywords bug_status assigned_to flagtypes.name 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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 08:39:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204437 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|needs-qa |patch Status|New |In Progress Assignee|freebsd-net@FreeBSD.org |fabient@FreeBSD.org Flags|mfc-stable10? |mfc-stable10+ --- Comment #21 from Kubilay Kocak --- Assign to committer that resolved. Commit has been merged to stable/10. @Fabien, if this commit doesn't apply to stable/9, please set the mfc-stable9 flag to -, otherwise set to + when merged. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Thu Dec 3 13:55:34 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63E1CA3F6D1 for ; Thu, 3 Dec 2015 13:55:34 +0000 (UTC) (envelope-from jvp@lateapex.net) Received: from riddler.lateapex.net (riddler.lateapex.net [108.28.193.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "riddler.lateapex.net", Issuer "riddler.lateapex.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1415F1DCD for ; Thu, 3 Dec 2015 13:55:33 +0000 (UTC) (envelope-from jvp@lateapex.net) Received: from [127.0.0.1] (riddler.lateapex.net [IPv6:2001:470:e2f8:6969:0:0:0:217]) (authenticated bits=0) by riddler.lateapex.net (8.15.2/8.15.2) with ESMTPA id tB3DsBkK061017 for ; Thu, 3 Dec 2015 08:54:14 -0500 (EST) (envelope-from jvp@lateapex.net) X-Authentication-Warning: riddler.lateapex.net: Host riddler.lateapex.net [IPv6:2001:470:e2f8:6969:0:0:0:217] claimed to be [127.0.0.1] To: freebsd-net@freebsd.org From: Jason Van Patten Subject: Bridge Interfaces and ARPs Message-ID: <56604982.9010003@lateapex.net> Date: Thu, 3 Dec 2015 08:54:10 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Milter: Spamilter DataSet=MTA-Peer; receiver=riddler.lateapex.net; sender-ip=2001:470:e2f8:6969::217; sender-helo=[127.0.0.1]; X-Milter: Spamilter DataSet=SessionId; receiver=riddler.lateapex.net; sessionid='b3107b765e146bc753d6930af8dcf48c'; X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 13:55:34 -0000 Hey gang - I posted this to the FreeBSD user forums but figured I'd send a message off to the list to see if anyone has any input, guidance, or ideas. Emailing diagrams around isn't good form (IMHO) but having a diagram handy will help with the discussion. So please glance at: http://pics.lateapex.net/vz.png Background: I have a business class Verizon FIOS connection for Internet at home. Along with that connection, I have 13 (not 14!) static IPs from VZ. They almost fall within a proper CIDR block, but not quite: 1.2.3.210 - 1.2.3.222. I don't own .209, so I can't claim 1.2.3.208/28 as my IP block (dammit!) The subnet for the static IPs is a /24, and the default route is *Verizon's* router: 1.2.3.1. There are a number of different choices for this network layout: DMZ, bridging, or binat. I chose bridging so that I don't have the complexity of binatting, and yet have some protection for the servers via my router. So, per the drawing, the FreeBSD router's em0 is connected to the Verizon equipment, while re0 and re1 are both connected to a managed Cisco switch, on different VLANs. VLAN 10 for re0: Public IPs (public services, etc) VLAN 20 for re1: Private IPs (NAS, wireless AP, etc) Via the router, VLAN 10 and Verizon's network are bridged together. The bridge interface on the router has IP: 1.2.3.222/24 with a default route set to 1.2.3.1. All servers on VLAN 10 have IPs within the allocated range (.210 - .220) and the same default route. Now: the problem. I used the LAGG'd server as an example in the diagram, but the same thing is happening with other servers: the router is learning ARP entries for the IPs I own *from* Verizon's router. As soon as the router caches that bad entry, it no longer routes traffic to those public IPs *from* VLAN 20 (private side). So, in other words, a laptop on the wireless network won't be able to get to 1.2.3.215. My work-around for now has been a series of static ARP entries on the router for each of my public servers. That seems to work fine, but I wonder if there's something I might be doing wrong? If I didn't include enough info, fire away. Thanks! -- Jason Van Patten From owner-freebsd-net@freebsd.org Thu Dec 3 14:28:30 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DB94AA3FD4F for ; Thu, 3 Dec 2015 14:28:30 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6AAB0108D for ; Thu, 3 Dec 2015 14:28:30 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: by wmvv187 with SMTP id v187so29861454wmv.1 for ; Thu, 03 Dec 2015 06:28:28 -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:cc:subject :references:in-reply-to:content-type; bh=l+WXVSvm7zHeCvk0DFe1VAvChC+SyZf1qnAMYjzNXUQ=; b=bTYkKWdOc3cy3OZvWw0AkmDdxqdKJCfEMV9bEoOelBpSZHqJRfVyMQGgoX0jcoeGj0 pbqsaI+0mB5R/pAEJ36pjcFmZmJz8HSAg8GsSdEM2uf9XtVHF+A2v37rWqOgYUUq1ThQ GwNod4P3v/dh2ggcz6a9MGglHusaHgdOMeBvzK4DOzF4fRi2rKawO3PksG94hUyJ91Nw qNl4jOGOHmMVA59pIWjVpK3uEYLo80shK4eA05zzbCt56l2WRWxvjdbnnuQ5tR9cnzFF pNNvmlBDolPn1r+evZRBJPdPzQOzlfdwH4NTakQ6ZUqG1zcj1DunR6Yx8Ent3BmL62BK y/Sg== X-Received: by 10.28.32.65 with SMTP id g62mr49412417wmg.81.1449152908702; Thu, 03 Dec 2015 06:28:28 -0800 (PST) Received: from [192.168.2.30] ([2.190.214.80]) by smtp.googlemail.com with ESMTPSA id w6sm7821608wjy.31.2015.12.03.06.28.26 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Dec 2015 06:28:28 -0800 (PST) Message-ID: <56605186.6000003@gmail.com> Date: Thu, 03 Dec 2015 17:58:22 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Jason Van Patten CC: freebsd-net@freebsd.org Subject: Re: Bridge Interfaces and ARPs References: <56604982.9010003@lateapex.net> In-Reply-To: <56604982.9010003@lateapex.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 14:28:31 -0000 On 12/3/2015 5:24 PM, Jason Van Patten wrote: > Hey gang - > > I posted this to the FreeBSD user forums but figured I'd send a message off to the list to see if anyone has any input, guidance, or ideas. Emailing diagrams around isn't good form (IMHO) but having > a diagram handy will help with the discussion. So please glance at: > > http://pics.lateapex.net/vz.png > > Background: I have a business class Verizon FIOS connection for Internet at home. Along with that connection, I have 13 (not 14!) static IPs from VZ. They almost fall within a proper CIDR block, > but not quite: 1.2.3.210 - 1.2.3.222. I don't own .209, so I can't claim 1.2.3.208/28 as my IP block (dammit!) The subnet for the static IPs is a /24, and the default route is *Verizon's* router: > 1.2.3.1. > > There are a number of different choices for this network layout: DMZ, bridging, or binat. I chose bridging so that I don't have the complexity of binatting, and yet have some protection for the > servers via my router. So, per the drawing, the FreeBSD router's em0 is connected to the Verizon equipment, while re0 and re1 are both connected to a managed Cisco switch, on different VLANs. > > VLAN 10 for re0: Public IPs (public services, etc) > VLAN 20 for re1: Private IPs (NAS, wireless AP, etc) > > Via the router, VLAN 10 and Verizon's network are bridged together. The bridge interface on the router has IP: 1.2.3.222/24 with a default route set to 1.2.3.1. All servers on VLAN 10 have IPs > within the allocated range (.210 - .220) and the same default route. > > Now: the problem. I used the LAGG'd server as an example in the diagram, but the same thing is happening with other servers: the router is learning ARP entries for the IPs I own *from* Verizon's > router. As soon as the router caches that bad entry, it no longer routes traffic to those public IPs *from* VLAN 20 (private side). So, in other words, a laptop on the wireless network won't be > able to get to 1.2.3.215. > > My work-around for now has been a series of static ARP entries on the router for each of my public servers. That seems to work fine, but I wonder if there's something I might be doing wrong? > > If I didn't include enough info, fire away. Thanks! > Can you post the output of the following commands (on freebsd router): # ifconfig # ifconfig bridgeX addr # arp -na # netstat -nr -f inet # sysctl net.inet.ip -- Best regards Hooman Fazaeli From owner-freebsd-net@freebsd.org Thu Dec 3 15:08:59 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E8222A3F88C for ; Thu, 3 Dec 2015 15:08:59 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from mxrelay.isc.freebsd.org (mxrelay.isc.freebsd.org [149.20.53.13]) by mx1.freebsd.org (Postfix) with ESMTP id C11131032 for ; Thu, 3 Dec 2015 15:08:59 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) by mxrelay.isc.freebsd.org (Postfix) with ESMTP id BB38C594 for ; Thu, 3 Dec 2015 15:08:59 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by phabric-backend.isc.freebsd.org (Postfix, from userid 1346) id B970733247EE; Thu, 3 Dec 2015 15:08:59 +0000 (UTC) Date: Thu, 3 Dec 2015 15:08:59 +0000 To: freebsd-net@freebsd.org From: "rodrigc (Craig Rodrigues)" Reply-to: D1944+325+8925873bdc96dfc2@reviews.freebsd.org Subject: [Differential] [Commented On] D1944: PF and VIMAGE fixes Message-ID: X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: Thread-Topic: D1944: PF and VIMAGE fixes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: NDc2NzM0MzY4OTdiYThiNTU1MjY2ZDZmMTJiIFZgWws= MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 15:09:00 -0000 rodrigc added a comment. @glebius : if you have time can you review this? you have expressed interest in PF + VIMAGE fixes in the past. @bz : do you have time to review this? I understand you are going to be doing some VIMAGE work REVISION DETAIL https://reviews.freebsd.org/D1944 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: nvass-gmx.com, bz, trociny, kristof, gnn, zec, rodrigc, glebius, eri Cc: mmoll, javier_ovi_yahoo.com, farrokhi, julian, robak, freebsd-virtualization-list, freebsd-pf-list, freebsd-net-list From owner-freebsd-net@freebsd.org Thu Dec 3 15:14:26 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 114D0A3FA84 for ; Thu, 3 Dec 2015 15:14:26 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from mxrelay.isc.freebsd.org (mxrelay.isc.freebsd.org [149.20.53.13]) by mx1.freebsd.org (Postfix) with ESMTP id E51CC1474 for ; Thu, 3 Dec 2015 15:14:25 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) by mxrelay.isc.freebsd.org (Postfix) with ESMTP id CE27F65D for ; Thu, 3 Dec 2015 15:14:25 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by phabric-backend.isc.freebsd.org (Postfix, from userid 1346) id CB9593324AF7; Thu, 3 Dec 2015 15:14:25 +0000 (UTC) Date: Thu, 3 Dec 2015 15:14:25 +0000 To: freebsd-net@freebsd.org From: "nvass-gmx.com (Nikos Vassiliadis)" Reply-to: D1944+325+8925873bdc96dfc2@reviews.freebsd.org Subject: [Differential] [Commented On] D1944: PF and VIMAGE fixes Message-ID: X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: Thread-Topic: D1944: PF and VIMAGE fixes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: NDc2NzM0MzY4OTdiYThiNTU1MjY2ZDZmMTJiIFZgXFE= MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 15:14:26 -0000 nvass-gmx.com added a comment. Hi from me as well, just want to say that I am here too and I am willing to work on this even if i have to do it scratch;) Please review:) Nikos REVISION DETAIL https://reviews.freebsd.org/D1944 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: nvass-gmx.com, bz, trociny, kristof, gnn, zec, rodrigc, glebius, eri Cc: mmoll, javier_ovi_yahoo.com, farrokhi, julian, robak, freebsd-virtualization-list, freebsd-pf-list, freebsd-net-list From owner-freebsd-net@freebsd.org Thu Dec 3 15:16:16 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6AC82A3FB7B for ; Thu, 3 Dec 2015 15:16:16 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from mxrelay.isc.freebsd.org (mxrelay.isc.freebsd.org [149.20.53.13]) by mx1.freebsd.org (Postfix) with ESMTP id 4C4B11762 for ; Thu, 3 Dec 2015 15:16:16 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) by mxrelay.isc.freebsd.org (Postfix) with ESMTP id 49F7B66E for ; Thu, 3 Dec 2015 15:16:16 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by phabric-backend.isc.freebsd.org (Postfix, from userid 1346) id 488453324BC5; Thu, 3 Dec 2015 15:16:16 +0000 (UTC) Date: Thu, 3 Dec 2015 15:16:16 +0000 To: freebsd-net@freebsd.org From: "robak (Bartek Rutkowski)" Reply-to: D1944+325+8925873bdc96dfc2@reviews.freebsd.org Subject: [Differential] [Commented On] D1944: PF and VIMAGE fixes Message-ID: <7b65e916e6e47f9acf5c2c41c0ab4805@localhost.localdomain> X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: Thread-Topic: D1944: PF and VIMAGE fixes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: NDc2NzM0MzY4OTdiYThiNTU1MjY2ZDZmMTJiIFZgXMA= MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 15:16:16 -0000 robak added a comment. Just to add an end-user update, this stuff keeps leaking, even in 10.2-p7, every single time a VIMAGE jail is being stopped. REVISION DETAIL https://reviews.freebsd.org/D1944 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: nvass-gmx.com, bz, trociny, kristof, gnn, zec, rodrigc, glebius, eri Cc: mmoll, javier_ovi_yahoo.com, farrokhi, julian, robak, freebsd-virtualization-list, freebsd-pf-list, freebsd-net-list From owner-freebsd-net@freebsd.org Thu Dec 3 16:39:41 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D72D1A40F90 for ; Thu, 3 Dec 2015 16:39:41 +0000 (UTC) (envelope-from jvp@lateapex.net) Received: from riddler.lateapex.net (riddler.lateapex.net [108.28.193.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "riddler.lateapex.net", Issuer "riddler.lateapex.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9A147155A for ; Thu, 3 Dec 2015 16:39:41 +0000 (UTC) (envelope-from jvp@lateapex.net) Received: from [127.0.0.1] (riddler.lateapex.net [IPv6:2001:470:e2f8:6969:0:0:0:217]) (authenticated bits=0) by riddler.lateapex.net (8.15.2/8.15.2) with ESMTPA id tB3GcIO1062686 for ; Thu, 3 Dec 2015 11:38:19 -0500 (EST) (envelope-from jvp@lateapex.net) X-Authentication-Warning: riddler.lateapex.net: Host riddler.lateapex.net [IPv6:2001:470:e2f8:6969:0:0:0:217] claimed to be [127.0.0.1] To: freebsd-net@freebsd.org From: Jason Van Patten Subject: Bridge Interfaces and ARPs Message-ID: <56606FFA.7090208@lateapex.net> Date: Thu, 3 Dec 2015 11:38:18 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Milter: Spamilter DataSet=MTA-Peer; receiver=riddler.lateapex.net; sender-ip=2001:470:e2f8:6969::217; sender-helo=[127.0.0.1]; X-Milter: Spamilter DataSet=SessionId; receiver=riddler.lateapex.net; sessionid='21db94a96b318a909b0a206070a396ea'; X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 16:39:41 -0000 Unfortunately, my aggressive spam-fighting milter ate Hooman Fazaeli's initial response to my question. I hope the subject line is recognized as being part of the same thread, and gets filed accordingly. Anyway: On 12/3/15 09:29 AM, Hooman Fazaeli wrote: > Can you post the output of the following commands (on freebsd router): > > # ifconfig > # ifconfig bridgeX addr > # arp -na > # netstat -nr -f inet > # sysctl net.inet.ip I'll be happy to, but I'm going to REDACT my public IPs for hopefully obvious reasons: # ifconfig re0: flags=8943 metric 0 mtu 1500 options=8209b ether 00:30:18:a3:b4:f8 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active re1: flags=8843 metric 0 mtu 1500 options=8209b ether 00:30:18:a3:b4:f9 inet 192.168.10.254 netmask 0xffffff00 broadcast 192.168.10.255 inet6 fe80::230:18ff:fea3:b4f9%re1 prefixlen 64 scopeid 0x2 inet6 [REDACTED] prefixlen 64 nd6 options=21 media: Ethernet autoselect (1000baseT ) status: active em0: flags=8943 metric 0 mtu 1500 options=209b ether 00:1b:21:7d:8d:cd nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 pflog0: flags=100 metric 0 mtu 33160 bridge0: flags=8843 metric 0 mtu 1500 ether 02:fe:4a:c8:9c:00 inet [REDACTED].222 netmask 0xffffff00 broadcast [REDACTED].255 inet6 fe80::fe:4aff:fec8:9c00%bridge0 prefixlen 64 scopeid 0x5 inet6 [REDACTED] prefixlen 64 nd6 options=21 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: re0 flags=143 ifmaxaddr 0 port 1 priority 128 path cost 20000 member: em0 flags=143 ifmaxaddr 0 port 3 priority 128 path cost 20000 gif0: flags=8051 metric 0 mtu 1280 tunnel inet [REDACTED].222 --> 216.66.22.2 inet6 [REDACTED] --> 2001:470:7:9af::1 prefixlen 128 inet6 fe80::230:18ff:fea3:b4f8%gif0 prefixlen 64 scopeid 0x6 nd6 options=21 # ifconfig bridge0 inet bridge0: flags=8843 metric 0 mtu 1500 inet [REDACTED].222 netmask 0xffffff00 broadcast [REDACTED].255 # arp -an ? ([REDACTED].211) at 08:62:66:87:4c:c3 on bridge0 permanent [bridge] ? ([REDACTED].210) at 0c:c4:7a:31:e3:d8 on bridge0 permanent [bridge] ? ([REDACTED].212) at 0c:c4:7a:31:e3:d8 on bridge0 permanent [bridge] ? ([REDACTED].215) at 0c:c4:7a:31:e3:d8 on bridge0 permanent [bridge] ? ([REDACTED].217) at 0c:c4:7a:31:e3:d8 on bridge0 permanent [bridge] ? ([REDACTED].216) at 0c:c4:7a:31:e3:d8 on bridge0 permanent [bridge] ? ([REDACTED].219) at 0c:c4:7a:31:e3:d8 on bridge0 permanent [bridge] ? ([REDACTED].221) at 02:fe:4a:c8:9c:00 on bridge0 permanent [bridge] ? ([REDACTED].222) at 02:fe:4a:c8:9c:00 on bridge0 permanent [bridge] ? ([REDACTED].1) at 54:e0:32:be:cf:c1 on bridge0 expires in 1196 seconds [bridge] ? ([REDACTED].1) at 54:e0:32:be:cf:c1 on em0 expires in 1196 seconds [ethernet] ? (192.168.10.1) at 68:05:ca:3c:d9:2b on re1 expires in 1179 seconds [ethernet] ? (192.168.10.4) at 14:10:9f:d4:ad:15 on re1 expires in 1080 seconds [ethernet] ? (192.168.10.47) at 3c:15:c2:df:33:da on re1 expires in 1178 seconds [ethernet] ? (192.168.10.13) at 10:1c:0c:49:ea:27 on re1 expires in 1157 seconds [ethernet] ? (192.168.10.16) at ac:87:a3:00:90:97 on re1 expires in 1091 seconds [ethernet] ? (192.168.10.22) at 00:05:cd:41:8e:59 on re1 expires in 1126 seconds [ethernet] ? (192.168.10.250) at 64:d8:14:63:9e:f9 on re1 expires in 1168 seconds [ethernet] ? (192.168.10.251) at 64:d8:14:63:a4:e9 on re1 expires in 966 seconds [ethernet] ? (192.168.10.24) at 00:04:20:f1:5c:7d on re1 expires in 794 seconds [ethernet] ? (192.168.10.25) at 00:11:d9:64:e5:cd on re1 expires in 1186 seconds [ethernet] ? (192.168.10.254) at 00:30:18:a3:b4:f9 on re1 permanent [ethernet] ? (192.168.10.252) at 88:43:e1:ae:d2:9b on re1 expires in 1153 seconds [ethernet] ? (192.168.10.253) at 90:84:0d:d2:69:e1 on re1 expires in 1179 seconds [ethernet] ? ([REDACTED].210) at 0c:c4:7a:31:e3:d8 on re0 expires in 787 seconds [ethernet] # netstat -nr -f inet Routing tables Internet: Destination Gateway Flags Netif Expire default 108.28.193.1 UGS bridge0 [REDACTED].0/24 link#5 U bridge0 [REDACTED].222 link#5 UHS lo0 127.0.0.1 link#4 UH lo0 192.168.10.0/24 link#2 U re1 192.168.10.254 link#2 UHS lo0 # sysctl net.inet.ip net.inet.ip.portrange.randomtime: 45 net.inet.ip.portrange.randomcps: 10 net.inet.ip.portrange.randomized: 1 net.inet.ip.portrange.reservedlow: 0 net.inet.ip.portrange.reservedhigh: 1023 net.inet.ip.portrange.hilast: 65535 net.inet.ip.portrange.hifirst: 49152 net.inet.ip.portrange.last: 65535 net.inet.ip.portrange.first: 10000 net.inet.ip.portrange.lowlast: 600 net.inet.ip.portrange.lowfirst: 1023 net.inet.ip.forwarding: 1 net.inet.ip.redirect: 1 net.inet.ip.ttl: 64 net.inet.ip.rtexpire: 3600 net.inet.ip.rtminexpire: 10 net.inet.ip.rtmaxcache: 128 net.inet.ip.sourceroute: 0 net.inet.ip.intr_queue_maxlen: 256 net.inet.ip.intr_queue_drops: 0 net.inet.ip.accept_sourceroute: 0 net.inet.ip.keepfaith: 0 net.inet.ip.gifttl: 30 net.inet.ip.fw.dyn_keepalive: 1 net.inet.ip.fw.dyn_short_lifetime: 5 net.inet.ip.fw.dyn_udp_lifetime: 10 net.inet.ip.fw.dyn_rst_lifetime: 1 net.inet.ip.fw.dyn_fin_lifetime: 1 net.inet.ip.fw.dyn_syn_lifetime: 20 net.inet.ip.fw.dyn_ack_lifetime: 300 net.inet.ip.fw.dyn_max: 4096 net.inet.ip.fw.dyn_count: 0 net.inet.ip.fw.curr_dyn_buckets: 256 net.inet.ip.fw.dyn_buckets: 256 net.inet.ip.fw.enable: 1 net.inet.ip.fw.static_count: 359 net.inet.ip.fw.default_to_accept: 0 net.inet.ip.fw.tables_max: 128 net.inet.ip.fw.default_rule: 65535 net.inet.ip.fw.verbose_limit: 0 net.inet.ip.fw.verbose: 0 net.inet.ip.fw.autoinc_step: 100 net.inet.ip.fw.one_pass: 1 net.inet.ip.process_options: 1 net.inet.ip.maxfragpackets: 3922 net.inet.ip.maxfragsperpacket: 16 net.inet.ip.fragpackets: 0 net.inet.ip.check_interface: 0 net.inet.ip.random_id: 0 net.inet.ip.sendsourcequench: 0 net.inet.ip.fastforwarding: 0 net.inet.ip.mcast.loop: 1 net.inet.ip.mcast.maxsocksrc: 128 net.inet.ip.mcast.maxgrpsrc: 512 net.inet.ip.random_id_total: 0 net.inet.ip.random_id_collisions: 0 net.inet.ip.random_id_period: 8192 net.inet.ip.no_same_prefix: 0 -- Jason Van Patten From owner-freebsd-net@freebsd.org Fri Dec 4 00:22:10 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92FD0A3F37A for ; Fri, 4 Dec 2015 00:22:10 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DF06A1933 for ; Fri, 4 Dec 2015 00:22:09 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from moby.local ([79.107.25.109]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LtDpH-1aGIDq2j5H-012tU7 for ; Fri, 04 Dec 2015 01:22:01 +0100 From: Nikos Vassiliadis Subject: etherip (or gif) tunnel blues To: FreeBSD Net Message-ID: <5660DC8B.1090309@gmx.com> Date: Fri, 4 Dec 2015 02:21:31 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:7PlXQFEFVLeFJFwYCLKHpRJW/aLuFti8uskTLVg7y7wcxPoKURy R9lysjcquSJl495eT+K5zBsAeDdip2ksf09kYLLoX5eVlW9xpX1BpczTGP0porvED9Wh4v8 o/xYEiS+hGWQ14NJGWB9CYgPlYAyVNjPzTTXnw63TqHyV9VFkQvQxrqJ2XBe+mvHsdf6Spb vyLjlDrChCObttmT2SYVA== X-UI-Out-Filterresults: notjunk:1;V01:K0:Hnz2gE98blM=:2ZP/jy+WGfxXq3H9idl1BV 4BkzAmwTZyd9htgM+2uicpDxGE0KppRwHtnIATw66iLoQYNRXlnhlYoCHDFJQ4CGXY9uhDoDC 9WqynAl3KKVKsqLxEH5+0x5s627rVCV/qku+wVdkGTiIdzMVWfX+QtMkcNUCJxRmn3hIcg0Ja ndL7F4GIrwkNa+RGuScILxATAjj22+fTb8j0qHMJjAU/3HQRq/aNWJJc+Nem9GIROXN/u0zUo Gz5AESBnRVfDc+/QsWp0ccQc9CSIQ15uZ7w2poOY36oBk5UFVoTdsrUKXExzjWdMfTv0bzzh9 1apUKDZ2NbgWo2cLQrmcCFY8tTr/Rsr4uB1JvsABVuOLV/mcUcm4k2FW5+SePuz8i9sSEpeoa SAz0luT3E2e8MlHk5ZzK1QhgYW8q84j/RynH3M9khOb3f0SqKWoNQinPbMHjdMlkUKwCJoNbK wnSMIKWnSNlPlVzO9zpp2g9Vzfwyd3iJGU9bHBLkT8Affy5awokk3mn3LFaASi+ryuSjmTSkk sReE0I2mANOpa5BJRNBvfzWDIJzC08pR5bdPmW0dv/7KzoL6G85cdX4tEsYx4gRilD8oNRB1M UqcrQf1VoH7E1A82floe+TIDPsQXzqjpIofVORKMdCmnUWmpav9CM+JwocpqoldgSTMVGqVwA FQTtOiDFZ+ecVncRd5GcFk5Kwbky+tFexXqrufBQsutkaM9Ybutb01gpFSxYKNevpJgQ9jAlH n9wQliFvdKUtCKz5UIQQ6wxg8Hy2aNOaMn7QIbm55YY1Ig93z9TmZ6QWx8sDuHnpCXhcrcurn 20WJlbh X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 00:22:10 -0000 Hi, we use ETHERIP to connect two remote locations and we discovered something that looks like a bug. A packet of specific size cannot go through the tunnel. Correct behavior: > root@prometheus:~ # ping -s 1450 10.65.0.1 > PING 10.65.0.1 (10.65.0.1): 1450 data bytes > 1458 bytes from 10.65.0.1: icmp_seq=0 ttl=64 time=0.302 ms > 1458 bytes from 10.65.0.1: icmp_seq=1 ttl=64 time=0.267 ms > 1458 bytes from 10.65.0.1: icmp_seq=2 ttl=64 time=0.275 ms > 1458 bytes from 10.65.0.1: icmp_seq=3 ttl=64 time=0.274 ms > ^C > --- 10.65.0.1 ping statistics --- > 4 packets transmitted, 4 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 0.267/0.279/0.302/0.013 ms If size is reduced to 1449 then the problem appears: > root@prometheus:~ # ping -s 1449 10.65.0.1 > PING 10.65.0.1 (10.65.0.1): 1449 data bytes > ^C > --- 10.65.0.1 ping statistics --- > 7 packets transmitted, 0 packets received, 100.0% packet loss It's not specific to ICMP, TCP also behaves likewise and most probably UDP as well but I haven't tested that. Hung TCP connections was the reason we discovered this behavior. The behavior is *always* the same with that specific size. Larger (and smaller of course) sized packets go through the tunnel as they should. If I reduce the MTU by 1 for that route (the default route), things appear to work again! > root@prometheus:~ # route change 0/0 -mtu 1499 > change net 0 fib 0 > root@prometheus:~ # ping -s 1449 10.65.0.1 > PING 10.65.0.1 (10.65.0.1): 1449 data bytes > 1457 bytes from 10.65.0.1: icmp_seq=0 ttl=64 time=0.285 ms > 1457 bytes from 10.65.0.1: icmp_seq=1 ttl=64 time=0.288 ms > 1457 bytes from 10.65.0.1: icmp_seq=2 ttl=64 time=0.297 ms > 1457 bytes from 10.65.0.1: icmp_seq=3 ttl=64 time=0.300 ms > ^C > --- 10.65.0.1 ping statistics --- > 4 packets transmitted, 4 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 0.285/0.292/0.300/0.006 ms I am not sure if this affects gif tunnels as well because at the moment we need a L2 tunnel. It'd be amazing if someone could help with an idea. Or patch;) The behavior is the same on 10-STABLE and 9-STABLE. Thanks in advance, Nikos From owner-freebsd-net@freebsd.org Fri Dec 4 00:53:20 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B09CA3FA1C for ; Fri, 4 Dec 2015 00:53:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E7F7F153F for ; Fri, 4 Dec 2015 00:53:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tB40rJGq028111 for ; Fri, 4 Dec 2015 00:53:19 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 189219] [dummynet] [patch] using dummynet on sparc64 and configuring a pipe is an insta-panic Date: Fri, 04 Dec 2015 00:53:19 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: crash, needs-qa, patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: lidl@pix.net X-Bugzilla-Status: Open 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.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 00:53:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189219 --- Comment #8 from lidl@pix.net --- Applying Marius' patch fixes up the ip_dummynet code at least enough to make the trivial configuration panic stop happening. Applying the patch to r291431, I can now do the following: root@ton-129: kldload dummynet ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, logging disabled DUMMYNET 0 with IPv6 initialized (100409) load_dn_sched dn_sched FIFO loaded load_dn_sched dn_sched QFQ loaded load_dn_sched dn_sched RR loaded load_dn_sched dn_sched WF2Q+ loaded load_dn_sched dn_sched PRIO loaded root@ton-130: /etc/rc.d/ipfw onestart ipfw: setsockopt(IP_FW_XDEL): Invalid argument ipfw: getsockopt(IP_FW_XADD): Invalid argument ipfw: getsockopt(IP_FW_XADD): Invalid argument ipfw: getsockopt(IP_FW_XADD): Invalid argument ipfw: getsockopt(IP_FW_XADD): Invalid argument ipfw: getsockopt(IP_FW_XADD): Invalid argument ipfw: getsockopt(IP_FW_XADD): Invalid argument ipfw: getsockopt(IP_FW_XADD): Invalid argument ipfw: getsockopt(IP_FW_XADD): Invalid argument ipfw: getsockopt(IP_FW_XADD): Invalid argument ipfw: getsockopt(IP_FW_XADD): Invalid argument Firewall rules loaded. root@ton-131: ipfw pipe 1 config bw 100mbit root@ton-132: /etc/rc.d/ipfw onestop net.inet.ip.fw.enable: 1 -> 0 net.inet6.ip6.fw.enable: 1 -> 0 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Fri Dec 4 07:02:40 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 21913A4060B for ; Fri, 4 Dec 2015 07:02:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0E0931FDF for ; Fri, 4 Dec 2015 07:02:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tB472d8J043605 for ; Fri, 4 Dec 2015 07:02:39 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 199287] Missing TCP retransmit timer reset Date: Fri, 04 Dec 2015 07:02:40 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sebastian.huber@embedded-brains.de X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 07:02:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199287 --- Comment #2 from sebastian.huber@embedded-brains.de --- (In reply to Hiren Panchasara from comment #1) 1) Yes, this was a real problem. It didn't show up, however, after I increased the DMA descriptor count. For your other questions I have to debug the target again. It will be next year before I can do this. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Fri Dec 4 08:09:22 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6CF7AA404A1 for ; Fri, 4 Dec 2015 08:09:22 +0000 (UTC) (envelope-from "."@babolo.ru) Received: from smtp1.babolo.ru (smtp1.babolo.ru [194.58.35.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp1.babolo.ru", Issuer "@BABOLO" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id ED23A1D24 for ; Fri, 4 Dec 2015 08:09:21 +0000 (UTC) (envelope-from "."@babolo.ru) Received: from cicuta.babolo.ru (cicuta.babolo.ru [194.58.246.5]) by smtp1.babolo.ru (8.14.2/8.14.2) with SMTP id tB480N79065633; Fri, 4 Dec 2015 12:00:23 +0400 (MSK) (envelope-from .@babolo.ru) Received: (nullmailer pid 16955 invoked by uid 136); Fri, 04 Dec 2015 07:06:06 -0000 Date: Fri, 4 Dec 2015 10:06:06 +0300 From: Aleksandr A Babaylov <.@babolo.ru> To: Jason Van Patten Cc: freebsd-net@freebsd.org Subject: Re: Bridge Interfaces and ARPs Message-ID: <20151204070606.GA16904@babolo.ru> References: <56604982.9010003@lateapex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56604982.9010003@lateapex.net> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 08:09:22 -0000 On Thu, Dec 03, 2015 at 08:54:10AM -0500, Jason Van Patten wrote: > Hey gang - > > I posted this to the FreeBSD user forums but figured I'd send a message > off to the list to see if anyone has any input, guidance, or ideas. > Emailing diagrams around isn't good form (IMHO) but having a diagram > handy will help with the discussion. So please glance at: > > http://pics.lateapex.net/vz.png > > Background: I have a business class Verizon FIOS connection for Internet > at home. Along with that connection, I have 13 (not 14!) static IPs > from VZ. They almost fall within a proper CIDR block, but not quite: > 1.2.3.210 - 1.2.3.222. I don't own .209, so I can't claim 1.2.3.208/28 > as my IP block (dammit!) The subnet for the static IPs is a /24, and > the default route is *Verizon's* router: 1.2.3.1. > > There are a number of different choices for this network layout: DMZ, > bridging, or binat. I chose bridging so that I don't have the > complexity of binatting, and yet have some protection for the servers > via my router. So, per the drawing, the FreeBSD router's em0 is > connected to the Verizon equipment, while re0 and re1 are both connected > to a managed Cisco switch, on different VLANs. > > VLAN 10 for re0: Public IPs (public services, etc) > VLAN 20 for re1: Private IPs (NAS, wireless AP, etc) > > Via the router, VLAN 10 and Verizon's network are bridged together. The > bridge interface on the router has IP: 1.2.3.222/24 with a default route > set to 1.2.3.1. All servers on VLAN 10 have IPs within the allocated > range (.210 - .220) and the same default route. > > Now: the problem. I used the LAGG'd server as an example in the > diagram, but the same thing is happening with other servers: the router > is learning ARP entries for the IPs I own *from* Verizon's router. As > soon as the router caches that bad entry, it no longer routes traffic to > those public IPs *from* VLAN 20 (private side). So, in other words, a > laptop on the wireless network won't be able to get to 1.2.3.215. > > My work-around for now has been a series of static ARP entries on the > router for each of my public servers. That seems to work fine, but I > wonder if there's something I might be doing wrong? > > If I didn't include enough info, fire away. Thanks! May be it is proxy arp from Verison. Just delete bridge0 ifconfig em0 inet 1.2.3.222/24 ifconfig re0 inet 127.127.127.127/24 or any other fake net route add 1.2.3.210/31 -iface re0 route add 1.2.3.212/30 -iface re0 route add 1.2.3.216/30 -iface re0 route add 1.2.3.220/31 -iface re0 sysctl net.link.ether.inet.proxyall=1 Default router for your public servers 1.2.3.222 in /28 or wider net. From owner-freebsd-net@freebsd.org Fri Dec 4 11:52:52 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 95F99A40AC0 for ; Fri, 4 Dec 2015 11:52:52 +0000 (UTC) (envelope-from jvp@lateapex.net) Received: from riddler.lateapex.net (riddler.lateapex.net [108.28.193.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "riddler.lateapex.net", Issuer "riddler.lateapex.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5835F1B3C for ; Fri, 4 Dec 2015 11:52:51 +0000 (UTC) (envelope-from jvp@lateapex.net) Received: from [127.0.0.1] (riddler.lateapex.net [IPv6:2001:470:e2f8:6969:0:0:0:217]) (authenticated bits=0) by riddler.lateapex.net (8.15.2/8.15.2) with ESMTPA id tB4BpRGS073964 for ; Fri, 4 Dec 2015 06:51:31 -0500 (EST) (envelope-from jvp@lateapex.net) X-Authentication-Warning: riddler.lateapex.net: Host riddler.lateapex.net [IPv6:2001:470:e2f8:6969:0:0:0:217] claimed to be [127.0.0.1] Subject: Re: Bridge Interfaces and ARPs References: <56604982.9010003@lateapex.net> <20151204070606.GA16904@babolo.ru> To: freebsd-net@freebsd.org From: Jason Van Patten Message-ID: <56617E3E.2060405@lateapex.net> Date: Fri, 4 Dec 2015 06:51:26 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151204070606.GA16904@babolo.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Milter: Spamilter DataSet=MTA-Peer; receiver=riddler.lateapex.net; sender-ip=2001:470:e2f8:6969::217; sender-helo=[127.0.0.1]; X-Milter: Spamilter DataSet=SessionId; receiver=riddler.lateapex.net; sessionid='8618af643c20d9458f391984adc1d230'; X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 11:52:52 -0000 On 12/4/15 2:06 AM, Aleksandr A Babaylov wrote: > > May be it is proxy arp from Verison. Fair assumption. They may be doing that to prevent one Verizon customer from talking directly to another without routing through them first, even though each customer is on the same broadcast domain. > sysctl net.link.ether.inet.proxyall=1 This is actually brilliant and hysterical at the same time: using a broken network tech to fix a broken network. Ha! I'm rebuilding the router with newer hardware this weekend. I'll give your suggestion a try and report back to the mailing list post upgrade. Thanks for the idea! -- Jason Van Patten From owner-freebsd-net@freebsd.org Fri Dec 4 14:51:56 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DA062A40738; Fri, 4 Dec 2015 14:51:56 +0000 (UTC) (envelope-from ludovit.koren@gmail.com) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 861D91046; Fri, 4 Dec 2015 14:51:56 +0000 (UTC) (envelope-from ludovit.koren@gmail.com) Received: by wmec201 with SMTP id c201so77643802wme.0; Fri, 04 Dec 2015 06:51:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:user-mail-address:date:message-id:user-agent :mime-version:content-type; bh=1ng20DpJy73O2AeUGNBuxxNCYRLXnECDlxjMoWqNf+4=; b=IpMOT+iqyIqbwWS3OAg/uOW3S+YRCFaoxWUtXRtLdP/Zas5nYvGrlrP2XeUus1Zqc8 XdSyd9yGQP94EO6i+WPV1q/2WUh/n4uYkbKXYHAtTZdIXFvIV40fkGVcHouRYk61a52m 3pEv46cvepsUMcUvJhNQnv/zgThrkOinBsSZayRQin9nYRBXE4qAGwgBFTlaLv5pDGrK MSDZiUD6soNW+pmlpLUr5ALxMwEcTMaQdS0Gwa5QcTafxSczyirrySMnjBa6e1tPJvnv a63dL6pLk/YLKB+OCKzNwGCgXILhsYNSZ1MTbjXZ3MiQf8rNT9tMjH3mHQj0KCGdm5ie HkVA== X-Received: by 10.28.226.86 with SMTP id z83mr5891823wmg.77.1449240714102; Fri, 04 Dec 2015 06:51:54 -0800 (PST) Received: from jedi.localdomain (109-230-45-66.dynamic.orange.sk. [109.230.45.66]) by smtp.gmail.com with ESMTPSA id w141sm3778375wmw.24.2015.12.04.06.51.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Dec 2015 06:51:53 -0800 (PST) Received: by jedi.localdomain (Postfix, from userid 1001) id B79A911332; Fri, 4 Dec 2015 15:51:52 +0100 (CET) From: Ludovit Koren To: freebsd-net@freebsd.org, freebsd-virtualization@freebsd.org Subject: bce bridge problem User-Mail-Address: ludovit.koren@gmail.com Date: Fri, 04 Dec 2015 15:51:52 +0100 Message-ID: <8637vimflj.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 14:51:56 -0000 Hi, I am trying to configure bhyve with FreeBSD Guest and Centos Guest. I am using FreeBSD 10.2 RELEASE or 11.0 CURRENT (November 19) as a host. The host is setup with bce as bridging interface. The network in the host is not working. (I did a similar setup with FreeBSD 10-STABLE and Centos using bge and the host network is running). I found a problem regarding bce and bridging: https://lists.freebsd.org/pipermail/freebsd-net/2010-August/026203.html but it is few years old. Have anybody problem with bce driver and bridging? Any solution or workarounds? Thank you very much in advance for your advice. Regards, lk From owner-freebsd-net@freebsd.org Fri Dec 4 15:28:03 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B7703A411B4 for ; Fri, 4 Dec 2015 15:28:03 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 422C71DE9 for ; Fri, 4 Dec 2015 15:28:02 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221]) by hz.grosbein.net (8.14.9/8.14.9) with ESMTP id tB4F1Qts011014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 4 Dec 2015 16:01:27 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: nvass@gmx.com Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTP id tB4F1KrD003048; Fri, 4 Dec 2015 22:01:20 +0700 (KRAT) (envelope-from eugen@grosbein.net) Subject: Re: etherip (or gif) tunnel blues To: Nikos Vassiliadis , FreeBSD Net References: <5660DC8B.1090309@gmx.com> From: Eugene Grosbein Message-ID: <5661AAC0.4000308@grosbein.net> Date: Fri, 4 Dec 2015 22:01:20 +0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <5660DC8B.1090309@gmx.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, T_DATE_IN_FUTURE_96_Q autolearn=no version=3.3.2 X-Spam-Report: * 0.0 T_DATE_IN_FUTURE_96_Q Date: is 4 days to 4 months after Received: * date * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hz.grosbein.net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 15:28:03 -0000 On 04.12.2015 07:21, Nikos Vassiliadis wrote: > Hi, > > we use ETHERIP to connect two remote locations and we discovered > something that looks like a bug. A packet of specific size > cannot go through the tunnel. > > Correct behavior: >> root@prometheus:~ # ping -s 1450 10.65.0.1 >> PING 10.65.0.1 (10.65.0.1): 1450 data bytes >> 1458 bytes from 10.65.0.1: icmp_seq=0 ttl=64 time=0.302 ms >> 1458 bytes from 10.65.0.1: icmp_seq=1 ttl=64 time=0.267 ms >> 1458 bytes from 10.65.0.1: icmp_seq=2 ttl=64 time=0.275 ms >> 1458 bytes from 10.65.0.1: icmp_seq=3 ttl=64 time=0.274 ms >> ^C >> --- 10.65.0.1 ping statistics --- >> 4 packets transmitted, 4 packets received, 0.0% packet loss >> round-trip min/avg/max/stddev = 0.267/0.279/0.302/0.013 ms > > If size is reduced to 1449 then the problem appears: >> root@prometheus:~ # ping -s 1449 10.65.0.1 >> PING 10.65.0.1 (10.65.0.1): 1449 data bytes >> ^C >> --- 10.65.0.1 ping statistics --- >> 7 packets transmitted, 0 packets received, 100.0% packet loss You should show output of ifconfig for your gif and bridge interfaces and obtain tcpdump output for them at sending and receiving side. From owner-freebsd-net@freebsd.org Fri Dec 4 19:32:25 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 18C3AA411A9; Fri, 4 Dec 2015 19:32:25 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (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 9895C10FC; Fri, 4 Dec 2015 19:32:23 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id B33661FE023; Fri, 4 Dec 2015 20:32:19 +0100 (CET) Subject: Re: panic in arptimer in r289937 To: "Alexander V. Chernikov" , Adrian Chadd References: <2739461446298483@web2h.yandex.ru> <1733241446303675@web19h.yandex.ru> Cc: FreeBSD Net , freebsd-current , Randall Stewart From: Hans Petter Selasky Message-ID: <5661EAAF.1010906@selasky.org> Date: Fri, 4 Dec 2015 20:34:07 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <1733241446303675@web19h.yandex.ru> Content-Type: multipart/mixed; boundary="------------010400080206050505080202" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 19:32:25 -0000 This is a multi-part message in MIME format. --------------010400080206050505080202 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Adrian, On 10/31/15 16:01, Alexander V. Chernikov wrote: > > > 31.10.2015, 16:46, "Adrian Chadd" : >> On 31 October 2015 at 09:34, Alexander V. Chernikov >> wrote: >>> 31.10.2015, 05:32, "Adrian Chadd" : >>>> Hiya, >>>> >>>> Here's a panic from arptimer: >>> Hi Adrian, >>> >>> As far as I see, line 205 in if_ether.c is IF_AFDATA_LOCK(ifp) which happens after LLE_WUNLOCK(). >>> So, it looks like (pre-cached) ifp had been freed before locking ifdata. >>> Do you have any more details on that? (e.g. was some interface detached at that moment, is it reproducible, etc..) >>> >>> From a quick glance, potential use-after-free has been possible for quite a long time, but I wonder why it hasn't been observed before. >>> Probably lltable_free() changes might have triggered that. >>> >>> I'll take a deeper look on that and reply. >> Observed on an idle box with projects/hps_head too: > panic: bogus refcnt 0 on lle 0xfffff8016508ca00 > cpuid = 7 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe03e4e8c7e0 > vpanic() at vpanic+0x182/frame 0xfffffe03e4e8c860 > kassert_panic() at kassert_panic+0x126/frame 0xfffffe03e4e8c8d0 > llentry_free() at llentry_free+0x136/frame 0xfffffe03e4e8c900 > arptimer() at arptimer+0x20e/frame 0xfffffe03e4e8c950 > softclock_call_cc() at softclock_call_cc+0x170/frame 0xfffffe03e4e8c9c0 > softclock() at softclock+0x47/frame 0xfffffe03e4e8c9e0 > intr_event_execute_handlers() at intr_event_execute_handlers+0x96/frame 0xfffffe03e4e8ca20 > ithread_loop() at ithread_loop+0xa6/frame 0xfffffe03e4e8ca70 > fork_exit() at fork_exit+0x84/frame 0xfffffe03e4e8cab0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe03e4e8cab0 > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- Looks like callout_reset() must be examined too, and was missed by: https://svnweb.freebsd.org/changeset/base/290805 Can you try the attached patch? Randall: Can you fix this ASAP? --HPS --------------010400080206050505080202 Content-Type: text/x-patch; name="callout_reset_arptimer.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="callout_reset_arptimer.diff" diff --git a/sys/dev/oce/oce_if.c b/sys/dev/oce/oce_if.c index 826cd3c..1cca876 100644 --- a/sys/dev/oce/oce_if.c +++ b/sys/dev/oce/oce_if.c @@ -343,7 +343,7 @@ oce_attach(device_t dev) callout_init(&sc->timer, 1); rc = callout_reset(&sc->timer, 2 * hz, oce_local_timer, sc); - if (rc) + if (rc > 0) goto stats_free; return 0; diff --git a/sys/netinet/if_ether.c b/sys/netinet/if_ether.c index dfba0b2..0aec1c4 100644 --- a/sys/netinet/if_ether.c +++ b/sys/netinet/if_ether.c @@ -420,7 +420,7 @@ arpresolve_full(struct ifnet *ifp, int is_gw, int create, struct mbuf *m, la->la_expire = time_uptime; canceled = callout_reset(&la->lle_timer, hz * V_arpt_down, arptimer, la); - if (canceled) + if (canceled > 0) LLE_REMREF(la); la->la_asked++; LLE_WUNLOCK(la); @@ -1084,7 +1084,7 @@ arp_mark_lle_reachable(struct llentry *la) la->la_expire = time_uptime + V_arpt_keep; canceled = callout_reset(&la->lle_timer, hz * V_arpt_keep, arptimer, la); - if (canceled) + if (canceled > 0) LLE_REMREF(la); } la->la_asked = 0; --------------010400080206050505080202-- From owner-freebsd-net@freebsd.org Fri Dec 4 19:51:02 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 79DE6A415B7; Fri, 4 Dec 2015 19:51:02 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (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 3E9401E40; Fri, 4 Dec 2015 19:51:01 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id F18E51FE023; Fri, 4 Dec 2015 20:50:59 +0100 (CET) Subject: Re: panic in arptimer in r289937 To: "Alexander V. Chernikov" , Adrian Chadd References: <2739461446298483@web2h.yandex.ru> <1733241446303675@web19h.yandex.ru> <5661EAAF.1010906@selasky.org> Cc: FreeBSD Net , freebsd-current , Randall Stewart From: Hans Petter Selasky Message-ID: <5661EF10.8060300@selasky.org> Date: Fri, 4 Dec 2015 20:52:48 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <5661EAAF.1010906@selasky.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 19:51:02 -0000 On 12/04/15 20:34, Hans Petter Selasky wrote: > Hi Adrian, > > On 10/31/15 16:01, Alexander V. Chernikov wrote: >> >> >> 31.10.2015, 16:46, "Adrian Chadd" : >>> On 31 October 2015 at 09:34, Alexander V. Chernikov >>> wrote: >>>> 31.10.2015, 05:32, "Adrian Chadd" : >>>>> Hiya, >>>>> >>>>> Here's a panic from arptimer: >>>> Hi Adrian, >>>> >>>> As far as I see, line 205 in if_ether.c is IF_AFDATA_LOCK(ifp) >>>> which happens after LLE_WUNLOCK(). >>>> So, it looks like (pre-cached) ifp had been freed before locking >>>> ifdata. >>>> Do you have any more details on that? (e.g. was some interface >>>> detached at that moment, is it reproducible, etc..) >>>> >>>> From a quick glance, potential use-after-free has been possible >>>> for quite a long time, but I wonder why it hasn't been observed before. >>>> Probably lltable_free() changes might have triggered that. >>>> >>>> I'll take a deeper look on that and reply. >>> > > Observed on an idle box with projects/hps_head too: > >> panic: bogus refcnt 0 on lle 0xfffff8016508ca00 >> cpuid = 7 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xfffffe03e4e8c7e0 >> vpanic() at vpanic+0x182/frame 0xfffffe03e4e8c860 >> kassert_panic() at kassert_panic+0x126/frame 0xfffffe03e4e8c8d0 >> llentry_free() at llentry_free+0x136/frame 0xfffffe03e4e8c900 >> arptimer() at arptimer+0x20e/frame 0xfffffe03e4e8c950 >> softclock_call_cc() at softclock_call_cc+0x170/frame 0xfffffe03e4e8c9c0 >> softclock() at softclock+0x47/frame 0xfffffe03e4e8c9e0 >> intr_event_execute_handlers() at >> intr_event_execute_handlers+0x96/frame 0xfffffe03e4e8ca20 >> ithread_loop() at ithread_loop+0xa6/frame 0xfffffe03e4e8ca70 >> fork_exit() at fork_exit+0x84/frame 0xfffffe03e4e8cab0 >> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe03e4e8cab0 >> --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > > Looks like callout_reset() must be examined too, and was missed by: > > https://svnweb.freebsd.org/changeset/base/290805 > > Can you try the attached patch? > > Randall: Can you fix this ASAP? > > --HPS > Hi, Randall: I see for 11-current, callout_reset() doesn't return -1 when the callout is stopped like with callout_stop(). Is this a bug or a feature? Why can't the callout_reset() and callout_stop() functions use the same return values? In nd6_llinfo_settimer_locked() the return value of both callout_reset() and callout_stop() is checked for positive values, but not in the other places mentioned by my patch. --HPS From owner-freebsd-net@freebsd.org Fri Dec 4 20:26:35 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 473EEA41C5F for ; Fri, 4 Dec 2015 20:26:35 +0000 (UTC) (envelope-from jvp@lateapex.net) Received: from riddler.lateapex.net (unknown [IPv6:2001:470:e2f8:6969::217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "riddler.lateapex.net", Issuer "riddler.lateapex.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1389C1242 for ; Fri, 4 Dec 2015 20:26:34 +0000 (UTC) (envelope-from jvp@lateapex.net) Received: from [127.0.0.1] (riddler.lateapex.net [IPv6:2001:470:e2f8:6969:0:0:0:217]) (authenticated bits=0) by riddler.lateapex.net (8.15.2/8.15.2) with ESMTPA id tB4KQVDP078658 for ; Fri, 4 Dec 2015 15:26:32 -0500 (EST) (envelope-from jvp@lateapex.net) X-Authentication-Warning: riddler.lateapex.net: Host riddler.lateapex.net [IPv6:2001:470:e2f8:6969:0:0:0:217] claimed to be [127.0.0.1] Subject: Re: Bridge Interfaces and ARPs References: <56604982.9010003@lateapex.net> <20151204070606.GA16904@babolo.ru> To: freebsd-net@freebsd.org From: Jason Van Patten Message-ID: <5661F728.5090108@lateapex.net> Date: Fri, 4 Dec 2015 15:27:20 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151204070606.GA16904@babolo.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Milter: Spamilter DataSet=MTA-Peer; receiver=riddler.lateapex.net; sender-ip=2001:470:e2f8:6969::217; sender-helo=[127.0.0.1]; X-Milter: Spamilter DataSet=SessionId; receiver=riddler.lateapex.net; sessionid='93b2cb09d73092e89abc69b4bfc6ef13'; X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 20:26:35 -0000 On 12/4/15 2:06 AM, Aleksandr A Babaylov wrote: > > sysctl net.link.ether.inet.proxyall=1 This looks like it's working; thanks a bunch! Whoda'thunk you could use something like proxy arp to un-break a broken network? It appears as though the above sysctl keeps resetting itself to 0 with *any* network interface changes. And from what I can see, that's as by design? Is there any way to get it to stay 1? The problem is that sysctl does its think during boot-up, before the interfaces and routing are all set in /etc/rc.conf. So I have to come back in and manually set it to 1. I suppose I can write an RC script to do that for me, but it's still suboptimal. Any guidance or suggestions on that one? Thanks again! -- Jason Van Patten From owner-freebsd-net@freebsd.org Fri Dec 4 23:33:53 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3E00BA40B41 for ; Fri, 4 Dec 2015 23:33:53 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D90011575 for ; Fri, 4 Dec 2015 23:33:52 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from amavis-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3pC9Mw3Z1vztN for ; Sat, 5 Dec 2015 00:33:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla4; t=1449272025; x=1451864026; bh=lvb xa7QwFZCt1+7z2KZ9i4aEH/AahD+9AWd2ztUjYsc=; b=Ox5IQOnjMZfBmpqb+VT dLrfIE36fez1o4fz61TE84uHUX2vNyxV+EaSSFgGcrifKLQInBc6ZQEyJ3sAeLPh ECT6Z5z+J1zB7GVx2Ob3VxpiCbW35fEtqYznEElGlOLKf0qH1IkgbZHf9Yq2VhM2 uwn7916+S1B7dtxVdeZbvVdM= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10026) with LMTP id eQQsHFKTjKCQ for ; Sat, 5 Dec 2015 00:33:45 +0100 (CET) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP id 3pC9Ms0bB2ztM for ; Sat, 5 Dec 2015 00:33:45 +0100 (CET) Received: from nabiralnik.ijs.si (nabiralnik.ijs.si [IPv6:2001:1470:ff80::80:16]) by mildred.ijs.si (Postfix) with ESMTP id 3pC9Mr6Jwfz3r for ; Sat, 5 Dec 2015 00:33:44 +0100 (CET) Received: from neli.ijs.si ([193.2.4.95]) by nabiralnik.ijs.si with HTTP (HTTP/1.1 POST); Sat, 05 Dec 2015 00:33:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 05 Dec 2015 00:33:44 +0100 From: Mark Martinec To: freebsd-net@freebsd.org Subject: Re: Outgoing packets being sent via wrong interface Organization: Jozef Stefan Institute In-Reply-To: <20151125092145.e93151af70085c2b3393f149@neosystem.cz> References: <20151120155511.5fb0f3b07228a0c829fa223f@neosystem.org> <20151120163431.3449a473db9de23576d3a4b4@neosystem.org> <20151121212043.GC2307@vega.codepro.be> <20151122130240.165a50286cbaa9288ffc063b@neosystem.cz> <20151125092145.e93151af70085c2b3393f149@neosystem.cz> Message-ID: X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.1.3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 23:33:53 -0000 On 2015-11-25 09:21, Daniel Bilik wrote: > It happened again, yesterday, and I can now definitely confirm > that it's related to default route. [...] > ... because again it was pushing outgoing packets wrong way, via public > interface, where it's dropped by pf... [...] > I've tried to just delete default route and enter it back to routing > table. > # route delete default ; sleep 1 ; route add default 82.x.y.29 > ... and voila, ping started to communicate with affected host... Seems like I have stumbled across the same problem as Daniel, as all that was said above applies to my case too. Running a fairly recent 10-STABLE, pf was disabled. 10.2-STABLE FreeBSD 10.2-STABLE #3 r291378: Fri Nov 27 12:45:53 CET 2015 ... amd64 In addition to a regular ethernet interface, I also have a gif tunnel. Routing directs a tunnel endpoint to the ethernet interface, and most of the rest goes through tunnel. Maybe worth mentioning that some processes (like ntpd) run in FIB 1 with their own routing able to force them to use a direct route. I was trying to set up an nginx proxy, but couldn't get it to respond to a remote client. After tcpdump sessions it turned out that a TCP SYN from a remote host came in through an ethernet interface, but a SYN ACK went out through gif, even through netstat -rn was still telling the default route is ethernet. Firewall was disabled. Funny thing is that a sshd process was still sending responses to the same remote host through the correct ethernet interface via a default route. Luckily I came across this thread, and sure enough, a: route delete default; route add default x.x.x.x solved the problem right away. The netstat -rn output of before and after the route reset were exactly the same. Unfortunately I can't reproduce the problem now, and I never experienced such problem in previous 10-STABLE revisions, or earlier. Anyway, just wanted to mention that possibly Daniel may not be alone with a default route becoming ineffective. Mark On 2015-11-25 09:21, Daniel Bilik wrote: > On Sun, 22 Nov 2015 13:02:40 +0100 > Daniel Bilik wrote: > >> Well, even though pf may play some role in the problem, I tend to >> suspect >> the routing table as the main trigger. There are several facts to >> support >> this... > > It happened again, yesterday, and I can now definitely confirm that > it's > related to default route. > > In this case, affected address was 192.168.2.33. This host was unable > to > connect to 192.168.2.15 (jail on the router), and router itself was > unable > to even ping the affected host... > > PING 192.168.2.33 (192.168.2.33): 56 data bytes > ping: sendto: Operation not permitted > ping: sendto: Operation not permitted > > ... because again it was pushing outgoing packets wrong way, via public > interface, where it's dropped by pf... > > 00:00:07.091814 rule 53..16777216/0(match): block out on re0: > 82.x.y.50 > 192.168.2.33: ICMP echo request, id 12037, seq 0, length > 64 > 00:00:01.011536 rule 53..16777216/0(match): block out on re0: > 82.x.y.50 > 192.168.2.33: ICMP echo request, id 12037, seq 1, length > 64 > > I've tried to just delete default route and enter it back to routing > table. > In one tmux session ping was running, in another session I've performed > this... > > # route delete default ; sleep 1 ; route add default 82.x.y.29 > > ... and voila, ping started to communicate with affected host... > > ping: sendto: Operation not permitted > ping: sendto: Operation not permitted > 64 bytes from 192.168.2.33: icmp_seq=12 ttl=128 time=0.535 ms > 64 bytes from 192.168.2.33: icmp_seq=13 ttl=128 time=0.264 ms > > Touching nothing else (pf etc.), not rebooting, just "refreshing" the > default route entry, and the problem disappeared. From owner-freebsd-net@freebsd.org Fri Dec 4 23:43:10 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E257A40D03 for ; Fri, 4 Dec 2015 23:43:10 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from mail.in-addr.com (mail.in-addr.com [IPv6:2a01:4f8:191:61e8::2525:2525]) (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 65C8419C1 for ; Fri, 4 Dec 2015 23:43:10 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by mail.in-addr.com with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1a500I-0009xY-6a; Fri, 04 Dec 2015 23:43:06 +0000 Date: Fri, 4 Dec 2015 23:43:06 +0000 From: Gary Palmer To: Jason Van Patten Cc: freebsd-net@freebsd.org Subject: Re: Bridge Interfaces and ARPs Message-ID: <20151204234306.GA18341@in-addr.com> References: <56604982.9010003@lateapex.net> <20151204070606.GA16904@babolo.ru> <5661F728.5090108@lateapex.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5661F728.5090108@lateapex.net> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on mail.in-addr.com); SAEximRunCond expanded to false X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 23:43:10 -0000 On Fri, Dec 04, 2015 at 03:27:20PM -0500, Jason Van Patten wrote: > On 12/4/15 2:06 AM, Aleksandr A Babaylov wrote: > > > > sysctl net.link.ether.inet.proxyall=1 > > This looks like it's working; thanks a bunch! Whoda'thunk you could use > something like proxy arp to un-break a broken network? It appears as > though the above sysctl keeps resetting itself to 0 with *any* network > interface changes. And from what I can see, that's as by design? Is > there any way to get it to stay 1? The problem is that sysctl does its > think during boot-up, before the interfaces and routing are all set in > /etc/rc.conf. So I have to come back in and manually set it to 1. I > suppose I can write an RC script to do that for me, but it's still > suboptimal. > > Any guidance or suggestions on that one? > > Thanks again! Try: sysrc arpproxy_all=YES You can remove the sysctl setting as that's what that option does. Regards, Gary From owner-freebsd-net@freebsd.org Fri Dec 4 23:57:29 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 38AA8A41108 for ; Fri, 4 Dec 2015 23:57:29 +0000 (UTC) (envelope-from jvp@lateapex.net) Received: from riddler.lateapex.net (unknown [IPv6:2001:470:e2f8:6969::217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "riddler.lateapex.net", Issuer "riddler.lateapex.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 02C941EAF for ; Fri, 4 Dec 2015 23:57:28 +0000 (UTC) (envelope-from jvp@lateapex.net) Received: from deadshot.private.lateapex.net (deadshot.private.lateapex.net [IPv6:2001:470:e2f8:7777:1610:9fff:fed4:ad15] (may be forged)) (authenticated bits=0) by riddler.lateapex.net (8.15.2/8.15.2) with ESMTPA id tB4NvRRv080422 for ; Fri, 4 Dec 2015 18:57:27 -0500 (EST) (envelope-from jvp@lateapex.net) Subject: Re: Bridge Interfaces and ARPs To: freebsd-net@freebsd.org References: <56604982.9010003@lateapex.net> <20151204070606.GA16904@babolo.ru> <5661F728.5090108@lateapex.net> <20151204234306.GA18341@in-addr.com> From: Jason Van Patten Message-ID: <56622866.8030908@lateapex.net> Date: Fri, 4 Dec 2015 18:57:26 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151204234306.GA18341@in-addr.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Milter: Spamilter DataSet=MTA-Peer; receiver=riddler.lateapex.net; sender-ip=2001:470:e2f8:7777:1610:9fff:fed4:ad15; sender-helo=deadshot.private.lateapex.net; X-Milter: Spamilter DataSet=GeoIP; receiver=riddler.lateapex.net; ip=2001:470:e2f8:7777:1610:9fff:fed4:ad15; CC=--; X-Milter: Spamilter DataSet=SessionId; receiver=riddler.lateapex.net; sessionid='72d885b5c05d675b8129c5b011070f02'; X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 23:57:29 -0000 On 12/4/15 6:43 PM, Gary Palmer wrote: > On Fri, Dec 04, 2015 at 03:27:20PM -0500, Jason Van Patten wrote: >> Any guidance or suggestions on that one? >> > > Try: > > sysrc arpproxy_all=YES > > You can remove the sysctl setting as that's what that option does. According to /etc/rc.d/routing, it looks like that does the trick during a 'service routing start' (or restart) command. Excellent. Thank you for that pointer! -- Jason Van Patten