From owner-freebsd-net@FreeBSD.ORG Sun Mar 29 08:35:38 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64D94688 for ; Sun, 29 Mar 2015 08:35:38 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4AD3A18E for ; Sun, 29 Mar 2015 08:35:38 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2T8Zc5v090649 for ; Sun, 29 Mar 2015 08:35:38 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 198928] mbuf tags aren't being copied from the leading fragment (header) to the subsequent fragment packets Date: Sun, 29 Mar 2015 08:35:38 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: hselasky@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: hselasky@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 08:35:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198928 Hans Petter Selasky changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-net@FreeBSD.org |hselasky@FreeBSD.org CC| |hselasky@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sun Mar 29 10:36:37 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BE7BCCDB for ; Sun, 29 Mar 2015 10:36:37 +0000 (UTC) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (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 70B3AE76 for ; Sun, 29 Mar 2015 10:36:37 +0000 (UTC) Received: by qcay5 with SMTP id y5so49733693qca.1 for ; Sun, 29 Mar 2015 03:36:36 -0700 (PDT) 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=fyW/olx1kJhNeZoyhYhdmASXlsDCNVn3ZjOguQDEDGs=; b=Zu61Hzn2gwZ4luPFsuOxjIRB9PdhF9o/piGIMay5sZ5g+mD7S0d4c0nfvehTVyp/uv Wql9KGG60bCyA6ZyC7jEK9Wu1yuba4oUVP2IllOL5GH1kYR8BdT8C2mNQjMExhdbT8sk fKUw0bCj6mIOx6my6S7r5h/xahRGtFwabWRsRycThto0qE3vh5SuXWDfbl/HjanOvmeI 2krZvsM43HlZ5/zlM60+TDIeZ2D/2utlib2N1qzeQFxBV8ua2vTe/F5wLBaQtXDP7nvO LM0I9zlDJPS728P+l0FtUV5CC8se8vWchQHEF2y3ZgmeIf+n1SIt5IkPdyYy6VjZSqLq 1hOA== MIME-Version: 1.0 X-Received: by 10.229.96.194 with SMTP id i2mr36059167qcn.1.1427625396513; Sun, 29 Mar 2015 03:36:36 -0700 (PDT) Received: by 10.229.220.129 with HTTP; Sun, 29 Mar 2015 03:36:36 -0700 (PDT) In-Reply-To: <20150319175145.GH53237@strugglingcoder.info> References: <5506A5BB.5060204@selasky.org> <20150319175145.GH53237@strugglingcoder.info> Date: Sun, 29 Mar 2015 13:36:36 +0300 Message-ID: Subject: Re: Unbalanced LACP link From: Vitalii Duk To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 10:36:37 -0000 It worked fine, but today I've got one more error: Mar 29 01:03:08 router kernel: igb1: Interface stopped DISTRIBUTING, possible flapping Mar 29 01:08:02 router kernel: igb2: Interface stopped DISTRIBUTING, possible flapping Mar 29 01:08:02 router kernel: igb3: Interface stopped DISTRIBUTING, possible flapping Mar 29 01:11:01 router kernel: igb1: Interface stopped DISTRIBUTING, possible flapping Mar 29 01:11:01 router kernel: igb0: Interface stopped DISTRIBUTING, possible flapping Mar 29 01:13:11 router kernel: igb0: Interface stopped DISTRIBUTING, possible flapping Mar 29 01:13:16 router kernel: igb1: Interface stopped DISTRIBUTING, possible flapping Mar 29 01:13:42 router kernel: igb2: Interface stopped DISTRIBUTING, possible flapping Mar 29 01:13:46 router kernel: igb3: Interface stopped DISTRIBUTING, possible flapping On 19 March 2015 at 19:51, hiren panchasara wrote: > On 03/17/15 at 12:34P, Adrian Chadd wrote: > > On 17 March 2015 at 11:33, Jason Wolfe wrote: > > > On Mon, Mar 16, 2015 at 2:43 AM, Hans Petter Selasky > wrote: > > >> On 03/16/15 10:37, Vitalii Duk wrote: > > >>> > > >>> I've changed use_flowid to 0 and it helped! But isn't it setting > > >>> significant? In a description it says "Shift flowid bits to prevent > > >>> multiqueue collisions". > > >> > > >> > > >> Hi, > > >> > > >> Maybe your ethernet hardware is not properly setting the m_flowid ... > > >> > > >> --HPS > > >> > > > > > > Flip use_flowid back to 1 and try setting > > > net.link.lagg.default_flowid_shift / net.link.lagg.X.flowid_shift to 0 > > > as Hiren suggested. r260179 added this shift, which has caused us > > > balancing issues with the i350/igb. > > > > > > https://svnweb.freebsd.org/base?view=revision&revision=260179 > > > > > > Based on Adrian's comment about igb/ixgbe not setting the 'full > > > flowid' under normal conditions, does that mean this shift should be 0 > > > by default to ensure we don't break balancing for devices that only > > > set the CPU/MSIX queue? > > > > Or we can just see if there's anything wrong with putting the full 32 > > bit RSS flowid in received packets that have them. > > It'd be nice to have but for now I am proposing following to fix a known > broken case because of an optimization: > https://reviews.freebsd.org/D2098 > > Cheers, > Hiren > From owner-freebsd-net@FreeBSD.ORG Sun Mar 29 21:00:01 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A9D40984 for ; Sun, 29 Mar 2015 21:00:01 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7E62484F for ; Sun, 29 Mar 2015 21:00:01 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2TL01Wq088018 for ; Sun, 29 Mar 2015 21:00:01 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201503292100.t2TL01Wq088018@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-net@FreeBSD.org Subject: Problem reports for freebsd-net@FreeBSD.org that need special attention X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 Date: Sun, 29 Mar 2015 21:00:01 +0000 Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 21:00:01 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 197535 | [re] [panic] if_re (Realtek 8168) causes memory w 1 problems total for which you should take action. From owner-freebsd-net@FreeBSD.ORG Mon Mar 30 09:08:51 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 20F0226C; Mon, 30 Mar 2015 09:08:51 +0000 (UTC) Received: from gddsn.org.cn (gddsn.org.cn [218.19.164.145]) (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 316E1DEC; Mon, 30 Mar 2015 09:08:47 +0000 (UTC) Received: by gddsn.org.cn (Postfix, from userid 65534) id 68CE92E072; Mon, 30 Mar 2015 17:08:29 +0800 (CST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on gddsn.org.cn X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,HTML_MESSAGE autolearn=ham autolearn_force=no version=3.4.0 Received: from lp.gddsn.org.cn (unknown [10.44.8.136]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: wsk) by gddsn.org.cn (Postfix) with ESMTPSA id DB5372E05C; Mon, 30 Mar 2015 17:08:14 +0800 (CST) From: =?gb2312?B?zuLK5cCk?= Subject: BCM5709 controller attach returned failed Date: Mon, 30 Mar 2015 17:08:12 +0800 Message-Id: To: net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "questions@freebsd.org ; stable@freebsd.org; current@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 09:08:51 -0000 hi, folks I got bce0 attach returned 6 on my Freebsd 10.1-RELEASE-p8 server. It=A1=AF= s a quad ports NIC. any help? bce0: mem = 0xd4000000-0xd5ffffff irq 18 at device 0.0 on pci6 bce0: /usr/src/sys/dev/bce/if_bce.c(1247): Management firmware enabled = but not running! bce0: /usr/src/sys/dev/bce/if_bce.c(3974): Firmware synchronization = timeout! msg_data =3D 0x01020002 bce0: /usr/src/sys/dev/bce/if_bce.c(5057): Firmware did not complete = initialization! bce0: /usr/src/sys/dev/bce/if_bce.c(1305): Controller reset failed! device_attach: bce0 attach returned 6 none6@pci0:6:0:0: class=3D0x020000 card=3D0x090614e4 = chip=3D0x163914e4 rev=3D0x20 hdr=3D0x00 vendor =3D 'Broadcom Corporation' device =3D 'NetXtreme II BCM5709 Gigabit Ethernet' class =3D network subclass =3D ethernet BTW: the BCM5716 on board works anyway. bce0@pci0:2:0:0: class=3D0x020000 card=3D0x02a31028 = chip=3D0x163b14e4 rev=3D0x20 hdr=3D0x00 vendor =3D 'Broadcom Corporation' device =3D 'NetXtreme II BCM5716 Gigabit Ethernet' class =3D network subclass =3D ethernet bce1@pci0:2:0:1: class=3D0x020000 card=3D0x02a31028 = chip=3D0x163b14e4 rev=3D0x20 hdr=3D0x00 vendor =3D 'Broadcom Corporation' device =3D 'NetXtreme II BCM5716 Gigabit Ethernet' class =3D network subclass =3D ethernet I don=A1=AFt understand that why attach returned 6 on bce0 on bootmesgs = ? and why bce0 and bce1 on board works finally? -- pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 3.0 on pci0 pci4: on pcib1 pcib2: at device 0.0 on pci4 pci5: on pcib2 pcib3: at device 2.0 on pci5 pci6: on pcib3 bce0: mem = 0xd4000000-0xd5ffffff irq 18 at device 0.0 on pci6 bce0: /usr/src/sys/dev/bce/if_bce.c(1247): Management firmware enabled = but not running! bce0: /usr/src/sys/dev/bce/if_bce.c(3974): Firmware synchronization = timeout! msg_data =3D 0x01020002 bce0: /usr/src/sys/dev/bce/if_bce.c(5057): Firmware did not complete = initialization! bce0: /usr/src/sys/dev/bce/if_bce.c(1305): Controller reset failed! device_attach: bce0 attach returned 6 bce0: mem = 0xd6000000-0xd7ffffff irq 19 at device 0.1 on pci6 bce0: /usr/src/sys/dev/bce/if_bce.c(1247): Management firmware enabled = but not running! bce0: /usr/src/sys/dev/bce/if_bce.c(3974): Firmware synchronization = timeout! msg_data =3D 0x01020002 bce0: /usr/src/sys/dev/bce/if_bce.c(5057): Firmware did not complete = initialization! bce0: /usr/src/sys/dev/bce/if_bce.c(1305): Controller reset failed! device_attach: bce0 attach returned 6 pcib4: at device 4.0 on pci5 pci7: on pcib4 bce0: mem = 0xd0000000-0xd1ffffff irq 16 at device 0.0 on pci7 bce0: /usr/src/sys/dev/bce/if_bce.c(1247): Management firmware enabled = but not running! bce0: /usr/src/sys/dev/bce/if_bce.c(3974): Firmware synchronization = timeout! msg_data =3D 0x01020002 bce0: /usr/src/sys/dev/bce/if_bce.c(5057): Firmware did not complete = initialization! bce0: /usr/src/sys/dev/bce/if_bce.c(1305): Controller reset failed! device_attach: bce0 attach returned 6 bce0: mem = 0xd2000000-0xd3ffffff irq 17 at device 0.1 on pci7 bce0: /usr/src/sys/dev/bce/if_bce.c(1247): Management firmware enabled = but not running! bce0: /usr/src/sys/dev/bce/if_bce.c(3974): Firmware synchronization = timeout! msg_data =3D 0x01020002 bce0: /usr/src/sys/dev/bce/if_bce.c(5057): Firmware did not complete = initialization! bce0: /usr/src/sys/dev/bce/if_bce.c(1305): Controller reset failed! device_attach: bce0 attach returned 6 pcib5: at device 5.0 on pci0 pci8: on pcib5 igb0: port = 0xecc0-0xecdf mem = 0xdd7c0000-0xdd7dffff,0xdd800000-0xddbfffff,0xdd7b8000-0xdd7bbfff irq 16 = at device 0.0 on pci8 igb0: Using MSIX interrupts with 5 vectors igb0: Ethernet address: 00:1b:21:a9:c7:5c igb0: Bound queue 0 to cpu 0 igb0: Bound queue 1 to cpu 1 igb0: Bound queue 2 to cpu 2 igb0: Bound queue 3 to cpu 3 igb1: port = 0xece0-0xecff mem = 0xdd7e0000-0xdd7fffff,0xddc00000-0xddffffff,0xdd7bc000-0xdd7bffff irq 17 = at device 0.1 on pci8 igb1: Using MSIX interrupts with 5 vectors igb1: Ethernet address: 00:1b:21:a9:c7:5d igb1: Bound queue 0 to cpu 0 igb1: Bound queue 1 to cpu 1 igb1: Bound queue 2 to cpu 2 igb1: Bound queue 3 to cpu 3 ehci0: mem 0xde0fc000-0xde0fc3ff = irq 22 at device 26.0 on pci0 usbus0: EHCI version 1.0 usbus0 on ehci0 pcib6: at device 28.0 on pci0 pci3: on pcib6 mpt0: port 0xfc00-0xfcff mem = 0xde2ec000-0xde2effff,0xde2f0000-0xde2fffff irq 16 at device 0.0 on pci3 mpt0: MPI Version=3D1.5.18.0 mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 ) mpt0: 1 Active Volume (2 Max) mpt0: 2 Hidden Drive Members (14 Max) pcib7: at device 28.4 on pci0 pci2: on pcib7 bce0: mem = 0xd8000000-0xd9ffffff irq 16 at device 0.0 on pci2 miibus0: on bce0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, = 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bce0: Ethernet address: 78:2b:cb:3d:a5:cb bce0: ASIC (0x57092008); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.2.3); = Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (NCSI 2.0.11) Coal (RX:6,6,18,18; TX:20,20,80,80) bce1: mem = 0xda000000-0xdbffffff irq 17 at device 0.1 on pci2 miibus1: on bce1 brgphy1: PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, = 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bce1: Ethernet address: 78:2b:cb:3d:a5:cc bce1: ASIC (0x57092008); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.2.3); = Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (NCSI 2.0.11) Coal (RX:6,6,18,18; TX:20,20,80,80) ehci1: mem 0xde0fe000-0xde0fe3ff = irq 22 at device 29.0 on pci0 --- Cheers= From owner-freebsd-net@FreeBSD.ORG Mon Mar 30 13:49:56 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CDBAC240 for ; Mon, 30 Mar 2015 13:49:56 +0000 (UTC) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (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 9D2C72E5 for ; Mon, 30 Mar 2015 13:49:56 +0000 (UTC) Received: by pddn5 with SMTP id n5so60278601pdd.2 for ; Mon, 30 Mar 2015 06:49:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=iyrjjFelvBDkcld16fLzYhzMEwOpB71hkGAySuBbmLE=; b=Q4kFdmbxYU3fQbLKssDLBs/JLwZRulMeJVLsZfm74BD83hKxNR/f3PQ9lzonVQWv1a K505QApZg3wpLaR9+ZrAnoDfyVp+6e4OYr4bv/6KYEyvz6hdYdnTnUCc2OuCDMFsxpYM JZUCSRaU1NgyiyNPOsnISph30UMBBhyHtZLw2kqOMbVwVvSCVQabZ6sJvy3i0SHJbMjL 8ME77LgUDv5A0l4X4IgbKdQHI5Wpk/8rtReJqi6Fq2IW7837HOlTX+K7Kep2Ja8Dgj86 yaW/KJlaXBaz4ZE3qPeXUyPkDcf1rAJutbI+EFHkDjx8RzdCYhrqh4kbFhdmUt5GS2H3 B2PQ== MIME-Version: 1.0 X-Received: by 10.70.41.202 with SMTP id h10mr12401248pdl.84.1427723396159; Mon, 30 Mar 2015 06:49:56 -0700 (PDT) Received: by 10.66.83.137 with HTTP; Mon, 30 Mar 2015 06:49:56 -0700 (PDT) Date: Mon, 30 Mar 2015 09:49:56 -0400 Message-ID: Subject: Programmatically Creating VLAN in the Kernel From: Juan Mojica To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 13:49:56 -0000 I'm trying to programmatically create a VLAN in the kernel via ifioctl, but I'm hitting a "copyin" in the ioctl path, and since the address I'm passing in is a kernel address and not a user space address, the copyin is failing. Calling the ioctl from user space is a non-starter at this point, and I believe there will be other ioctls that will have to be called from the kernel which will hit the same issue. Any suggestions? So far I've thought about marking the ifreq flags to indicate the request came from the kernel and essentially bypass the copyin. Another option would be to make the create functions globally available, but this would violate the modularity of the VLAN module. Thanks in advance, -- Juan Mojica Email: jmojica@gmail.com From owner-freebsd-net@FreeBSD.ORG Mon Mar 30 22:59:45 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB9E1D7E; Mon, 30 Mar 2015 22:59:45 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (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 D1004766; Mon, 30 Mar 2015 22:59:45 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id 22BC310446C; Mon, 30 Mar 2015 15:59:45 -0700 (PDT) Date: Mon, 30 Mar 2015 15:59:45 -0700 From: hiren panchasara To: Adrian Chadd Subject: Re: Full 32bit flowid from igb(4) Message-ID: <20150330225945.GI10892@strugglingcoder.info> References: <20150323233908.GT53237@strugglingcoder.info> <20150323234214.GU53237@strugglingcoder.info> <20150324154931.GC53237@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="+PbGPm1eXpwOoWkI" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Jack F Vogel , FreeBSD Net , erj@freebsd.org, Jack Vogel , Jason Wolfe X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 22:59:46 -0000 --+PbGPm1eXpwOoWkI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 03/24/15 at 01:51P, Adrian Chadd wrote: > Hi, >=20 > The main reason I didn't add it outside of RSS is that I didn't want > to impact the behaviour that was there before. Before, it wasn't using > the flowid - only the msix/queue id. It'd break things if not all igb chips behave the same way in this regard. In which case, we'd have to fix them on per-case basis by pointing broken ones to the old behavior. >=20 > I read the intel datasheets about that particular field - I'm pretty > sure that by default we'll only see RSS hashed packets for IPv4/IPv6, > however non v4/v6 packets won't have a flowid. I guess that'd be okay for tiny traffic going through non-hashed. > There are also cases of > the flow director or some hardware checksum config using the same > field as the flowid. I don't understand your point here. Which field do you refer to as "the same field"? Can you please explain a bit more? >=20 > The /full/ solution would very carefully check the return status and > ensure what's in the flowid field is a flowid. Yes, I am waiting for Eric or Jack to comment on it. >=20 > The "sometimes it may have a flowid, sometimes it won't" problem isn't > so bad with kernel RSS enabled - it'll just software hash it. True. Cheers, Hiren --+PbGPm1eXpwOoWkI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVGdVgXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/l5EMH/31tknnYUFrwNRKdm5+mIrnR fg0sgMfFed113f4/qVYLp1JwaY8oRCl+uSnQUgGdYAAyr7/8D6z/qLC71VhrWLjU 9V+mzK6Eqq5Q+uIDvZVAsTULYvR83PxiyjxjACWTDT3FR0RSf0uzf3PMABGAMVk9 BXl7qN/3Dz84yQ8zOb6PuqeYMXW93z/qWL28giAvytdcfG+1eZkPSgH2HCR1frWB UUtwecCcDELYbUpTSob9N8Z5hnTw/D/GmkwKnFvC/YozX4nwmOkHT7lwTT+GpVve NBRbmrN0uBv38KkGfApWwtoZ+jKhoxRyvwAyoLT/OarEntcqxgsa1nQblADrYdI= =7y9Z -----END PGP SIGNATURE----- --+PbGPm1eXpwOoWkI-- From owner-freebsd-net@FreeBSD.ORG Mon Mar 30 23:33:52 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A39B88B; Mon, 30 Mar 2015 23:33:52 +0000 (UTC) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5C423AE1; Mon, 30 Mar 2015 23:33:52 +0000 (UTC) Received: by igcau2 with SMTP id au2so3835997igc.0; Mon, 30 Mar 2015 16:33:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=eEuIpDGuIawiWi+RzH9zd+zIoz+Qra5UWiv+2+d/xow=; b=VdmrZxe0xcyJF3r/vDWZgzyzX9hSjvVXgzqy4IjetHAD76lzmDk30cf0sVdZ3o9E9J CwoysW5t6GPPkreV1nEkcsnlYstFZLjAeedKfRBdYpfQ5kg2lFxvifS29C78D5dQuh5w legFKVP7nn1ex5Bd/KnQJFYe8u7TtJ5nmhhzb1LNFS+sAXqGSfEQ5pxYfqm34Y6TXw2n goOh6z5zDho3zSfal9JirdVuq23Qu/UNvS7i/LYOsV2UTKRy4AfxJAES69wcy9CcEk4X l/c2/iYi7whv3ZllTvbOYRpoK0hyYYCEn9olTlLXdFDGlVGYT1tym4A6OJPxvrgE1xzO vrbw== MIME-Version: 1.0 X-Received: by 10.43.82.137 with SMTP id ac9mr7551168icc.37.1427758431870; Mon, 30 Mar 2015 16:33:51 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Mon, 30 Mar 2015 16:33:51 -0700 (PDT) In-Reply-To: <20150330225945.GI10892@strugglingcoder.info> References: <20150323233908.GT53237@strugglingcoder.info> <20150323234214.GU53237@strugglingcoder.info> <20150324154931.GC53237@strugglingcoder.info> <20150330225945.GI10892@strugglingcoder.info> Date: Mon, 30 Mar 2015 16:33:51 -0700 X-Google-Sender-Auth: M1vXaXw5D3Pa4MZunfwvmqFncLc Message-ID: Subject: Re: Full 32bit flowid from igb(4) From: Adrian Chadd To: hiren panchasara Content-Type: text/plain; charset=UTF-8 Cc: Jack F Vogel , FreeBSD Net , erj@freebsd.org, Jack Vogel , Jason Wolfe X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 23:33:52 -0000 So, the 32 bit field that has the flowid in the rx descriptor can mean multiple things - not just the flowid. For igb it can also mean one of the RX checksums. for ixgbe it can also mean RX checksum, or flowdirector flow information, or a few other thngs. -adrian From owner-freebsd-net@FreeBSD.ORG Tue Mar 31 05:06:32 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09141BA2; Tue, 31 Mar 2015 05:06:32 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (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 DFD52250; Tue, 31 Mar 2015 05:06:31 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id E2620105AB1; Mon, 30 Mar 2015 22:06:28 -0700 (PDT) Date: Mon, 30 Mar 2015 22:06:28 -0700 From: hiren panchasara To: Adrian Chadd Subject: Re: Full 32bit flowid from igb(4) Message-ID: <20150331050628.GJ10892@strugglingcoder.info> References: <20150323233908.GT53237@strugglingcoder.info> <20150323234214.GU53237@strugglingcoder.info> <20150324154931.GC53237@strugglingcoder.info> <20150330225945.GI10892@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5me2qT3T17SWzdxI" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Jack F Vogel , FreeBSD Net , erj@freebsd.org, Jack Vogel , Jason Wolfe X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 05:06:32 -0000 --5me2qT3T17SWzdxI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 03/30/15 at 04:33P, Adrian Chadd wrote: > So, the 32 bit field that has the flowid in the rx descriptor can mean > multiple things - not just the flowid. >=20 > For igb it can also mean one of the RX checksums. I care about igb(4) right now and I350 specifically. I checked the spec and section 7.1.2.8 Receive-Side Scaling (RSS) which defines it. In igb_initialise_rss_mapping(), we do set MRQC register which means we are getting RSS hash in flowid. And we disable packet checksum to get RSS type via PCSD register.=20 Is my understanding not correct? I am missing how can we not get RSS hash in flowid in this case. Can you please explain? Cheers, Hiren --5me2qT3T17SWzdxI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVGitUXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lKbQH/iikNL7O3IXlboxmV4b7DVBM 4MuzKx7uEz7fFwq4ybDc5PbSZ3+iFE68A1C7sS5rI0Lf8Ph1xdkDsPYFKFiR1t3v wpT+oNl0fJfFZgGafvxmWcN08XVgOMPJLVWi6ci07/JYv6KTxug4hyTZNs7khYGA nAGd0TjzqVBvO6suXWvufIojpRuxx7R44mtytUjpBdmATdz7Dv/qDOsrrcuAbUal qbNMd0IHPn9gXWDzNne0aNepQKbcCjJ0YTImVnGpZaGtBqNFbwjM41ZjJbM/bT+3 IlCM6//r5E/v3xtIkbymtiQRd7DvApL69qTNfihkinPj7fPDT2nxI8zsyuprwB8= =f/Qc -----END PGP SIGNATURE----- --5me2qT3T17SWzdxI-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 31 05:53:04 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 01AB03B1; Tue, 31 Mar 2015 05:53:03 +0000 (UTC) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (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 B5B85989; Tue, 31 Mar 2015 05:53:03 +0000 (UTC) Received: by igcxg11 with SMTP id xg11so8669849igc.0; Mon, 30 Mar 2015 22:53:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lVTsiyKOfbNqhswY6RepkW332BXZAS/2vTRWPfdi2U8=; b=hZvPl1NsZK2GJ/PzpAir88l1zLzNno/QxIAOwzjN/4/oeTmEZ3Z4X91NZDSQYlFSMe lW5X4qTDtct32THm7rB25xnxVhbIUao68Gt/Rl4FyexDuKDVKobkn9I3xSbCgqT6cNCU J4VrlVJ+h1wI/d+uWbqBRuWmZw8B5KabFumDWNbN7s34SOWFachTKA3viZuQraiLb4dA IjwlBlkrCs48oSN7hb/cn4HGyhQv1lCPwcfd3jqzg7PXcnFmqZ9GIoOnuQTEtowvGJWf fbikpWM29N6vIYRm/bXJKPqApYAu4iSoYu6yAz2u3Op0twfe7KASakPtOpi2SaaUwqTA Dvaw== MIME-Version: 1.0 X-Received: by 10.50.67.100 with SMTP id m4mr1787394igt.32.1427781183183; Mon, 30 Mar 2015 22:53:03 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Mon, 30 Mar 2015 22:53:03 -0700 (PDT) In-Reply-To: <20150331050628.GJ10892@strugglingcoder.info> References: <20150323233908.GT53237@strugglingcoder.info> <20150323234214.GU53237@strugglingcoder.info> <20150324154931.GC53237@strugglingcoder.info> <20150330225945.GI10892@strugglingcoder.info> <20150331050628.GJ10892@strugglingcoder.info> Date: Mon, 30 Mar 2015 22:53:03 -0700 X-Google-Sender-Auth: K3z4aJyurtwrC5QMqp1lePpC6CA Message-ID: Subject: Re: Full 32bit flowid from igb(4) From: Adrian Chadd To: hiren panchasara Content-Type: text/plain; charset=UTF-8 Cc: Jack F Vogel , FreeBSD Net , erj@freebsd.org, Jack Vogel , Jason Wolfe X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 05:53:04 -0000 No, you're absolutely right. However, you (a) get flowid for L3/L4 V4/v6 but not other things, and (b) I was worried about changing the default behaviour of the driver, and who knows what other weird crap people may have done to their local driver. stuff like enabled checksums instead, or hacked in flowtable support. :) So, I'm totally fine if you want to populate the flowid for a given flow. Totally okay. You just can't set it blindly - you can only set it when the relevant descriptor bits say "it's a flowid!". Then I guess we'll figure out if something breaks down the line. -adrian From owner-freebsd-net@FreeBSD.ORG Tue Mar 31 12:32:55 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 747C7CE for ; Tue, 31 Mar 2015 12:32:55 +0000 (UTC) Received: from smtp.mimar.rs (smtp.mimar.rs [193.53.106.135]) by mx1.freebsd.org (Postfix) with ESMTP id 1F435C1D for ; Tue, 31 Mar 2015 12:32:54 +0000 (UTC) Received: from vscan.mimar.rs (vscan.mimar.rs [193.53.106.134]) by smtp.mimar.rs (Postfix) with ESMTP id B27A4898EF for ; Tue, 31 Mar 2015 14:22:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mimar.rs; h= content-transfer-encoding:content-type:content-type:mime-version :x-mailer:organization:message-id:subject:subject:from:from:date :date:received:received; s=mimar-0901; t=1427804569; x= 1429618970; bh=vd7MaUV0ulD6dMbaydlaRJHTWGOFWRX1qgSvlDd0hnQ=; b=V Ztgki2QZZxXWgHM5f4x9F5OM31QRtuRWcEXIBf+6VibyDNseWnk+Ar7nYjP3DIf0 7Aiuyuvt0/XDVVZpyXJIUDaQLbHORF6uN0s3LT/IgT76EcA7hH4k77xcXyZD5cVC zzmjgigYKDbTz3BEfr6LKe3bwPVSbcgqLs509n/vqg= X-Virus-Scanned: amavisd-new at mimar.rs Received: from smtp.mimar.rs ([193.53.106.135]) by vscan.mimar.rs (vscan.mimar.rs [193.53.106.134]) (amavisd-new, port 10026) with ESMTP id jk8J9eze5Y60 for ; Tue, 31 Mar 2015 14:22:49 +0200 (CEST) Received: from efreet (unknown [193.53.106.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: marko.cupac@mimar.rs) by smtp.mimar.rs (Postfix) with ESMTPSA id 49D96898EC for ; Tue, 31 Mar 2015 14:22:49 +0200 (CEST) Date: Tue, 31 Mar 2015 14:22:48 +0200 From: Marko =?UTF-8?B?Q3VwYcSH?= To: freebsd-net@freebsd.org Subject: FreeBSD 10.1 and ESXi 5.5 CARP setup Message-ID: <20150331142248.29b961db@efreet> Organization: Mimar X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 12:32:55 -0000 Hi, I have CARP set up on two pairs of firewalls running OpenBSD directly on metal. It works like a charm for almost 3 years now. Failover is almost instant when shutting down master node. I am trying to implement CARP on a pair of FreeBSD 10.1 servers running on top of VMWare ESXi 5.5U2, but so far haven't succedded. I tried both e1000 and vmx3f vNICs. I have made adjustments to ESXi as described here: https://doc.pfsense.org/index.php/CARP_Configuration_Troubleshooting#Hyperv= isor_users_.28Especially_VMware_ESX.2FESXi.29 I had interfaces stuck in INIT mode until I found this thread: https://lists.freebsd.org/pipermail/freebsd-net/2014-October/040116.html After i put 'up' at the end of ifconfig_em0 It appears I am getting MASTER and BACKUP, however on reboot of master, failover happens only after master completely shuts down, which is almost 5 seconds. Is CARP supposed to work on FreeBSD 10.1 as ESXi 5.5 guest the same as on bare-metal OpenBSD (instant failover)? If so, I'd be very grateful if someone pointed me in the right direction. Thank you in advance, --=20 Marko Cupa=C4=87 https://www.mimar.rs From owner-freebsd-net@FreeBSD.ORG Tue Mar 31 16:48:45 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E9A22A8C for ; Tue, 31 Mar 2015 16:48:45 +0000 (UTC) Received: from nef2.ens.fr (nef2.ens.fr [129.199.96.40]) by mx1.freebsd.org (Postfix) with ESMTP id 58F396F for ; Tue, 31 Mar 2015 16:48:44 +0000 (UTC) Received: from biologie.ens.fr (milda.ens.fr [129.199.18.219]) by nef2.ens.fr (8.13.6/1.01.28121999) with ESMTP id t2VG2krX081596 for ; Tue, 31 Mar 2015 18:02:47 +0200 (CEST) X-Envelope-To: Received: from localhost (av3.biologie.ens.fr [129.199.21.124]) by biologie.ens.fr (Postfix) with ESMTP id E450F32C2 for ; Tue, 31 Mar 2015 18:02:46 +0200 (CEST) X-Virus-Scanned: spam & virus filtering at av3.ens.fr X-Spam-Flag: NO X-Spam-Score: -10.91 X-Spam-Level: X-Spam-Status: No, score=-10.91 tagged_above=-9999 required=5 tests=[ALL_TRUSTED=-1, AUTHD_RELAY=-8, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from biologie.ens.fr ([IPv6:::ffff:129.199.18.219]) by localhost (av3.biologie.ens.fr [::ffff:129.199.21.124]) (amavisd-new, port 10024) with ESMTP id n8TrO+vcmx79 for ; Tue, 31 Mar 2015 18:02:45 +0200 (CEST) Received: from [129.199.16.44] (hades.ens.fr [129.199.16.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: phnguyen) by biologie.ens.fr (Postfix) with ESMTPSA id 4FB2D32B0 for ; Tue, 31 Mar 2015 18:02:45 +0200 (CEST) Message-ID: <551AC524.7070208@biologie.ens.fr> Date: Tue, 31 Mar 2015 18:02:44 +0200 From: Phi-Phong NGUYEN User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: FreeBSD 10.1 and ESXi 5.5 CARP setup References: <20150331142248.29b961db@efreet> In-Reply-To: <20150331142248.29b961db@efreet> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (nef2.ens.fr [129.199.96.32]); Tue, 31 Mar 2015 18:02:47 +0200 (CEST) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 16:48:46 -0000 I have a problem with carp too on FreeBSD 10.1 servers and posted a question but it seems to be more related to firmware network card. However your problem seems simplier as I had the same : If tcpdump reveals vrrp packets between servers and they are stuck in INIT state, try this workaround : Simply add in your /etc/sysctl.conf : ------------------- net.inet.carp.senderr_demotion_factor=0 # (default 240) If not, no preempt -> bug since FreeBSD10 ------------------- Cheers. On 03/31/2015 02:22 PM, Marko Cupać wrote: > Hi, > > I have CARP set up on two pairs of firewalls running OpenBSD directly > on metal. It works like a charm for almost 3 years now. Failover is > almost instant when shutting down master node. > > I am trying to implement CARP on a pair of FreeBSD 10.1 servers running > on top of VMWare ESXi 5.5U2, but so far haven't succedded. > > I tried both e1000 and vmx3f vNICs. I have made adjustments to ESXi as > described here: > https://doc.pfsense.org/index.php/CARP_Configuration_Troubleshooting#Hypervisor_users_.28Especially_VMware_ESX.2FESXi.29 > > I had interfaces stuck in INIT mode until I found this thread: > https://lists.freebsd.org/pipermail/freebsd-net/2014-October/040116.html > > After i put 'up' at the end of ifconfig_em0 It appears I am getting > MASTER and BACKUP, however on reboot of master, failover happens only > after master completely shuts down, which is almost 5 seconds. > > Is CARP supposed to work on FreeBSD 10.1 as ESXi 5.5 guest the same as > on bare-metal OpenBSD (instant failover)? If so, I'd be very grateful > if someone pointed me in the right direction. > > Thank you in advance, -- Phi-Phong NGUYEN Service informatique Institut de Biologie ENS 46 rue d'Ulm 75230 PARIS CEDEX 05 Tel: 01 44 32 36 34 Fax: 01 44 32 36 30 From owner-freebsd-net@FreeBSD.ORG Tue Mar 31 16:49:32 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B378B4B for ; Tue, 31 Mar 2015 16:49:32 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 20D798E for ; Tue, 31 Mar 2015 16:49:32 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2VGnVHq023337 for ; Tue, 31 Mar 2015 16:49:31 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 171711] [dummynet] [panic] Kernel panic in dummynet Date: Tue, 31 Mar 2015 16:49: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: 8.3-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dblais@interplex.ca X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 16:49:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=171711 dblais@interplex.ca changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dblais@interplex.ca --- Comment #2 from dblais@interplex.ca --- Hi, We have the very same issue here on FreeBSD 9.2 RELEASE on different hardware (HP DL360 G6 and HP Microserver G7). I suggest someone change Importance to something else than "Normal Affects Only me" because we have at least 8 such servers with the same issue. It happens more often when there's more load (customers and/or traffic). Don't know how it scales exactly (linear, quadratic or exponential) nor if it scales with traffic or the amount of pppoe clients but it sure if one of them of a mix of them. Here's the kernel dump: FreeBSD hiden_host 9.2-RELEASE FreeBSD 9.2-RELEASE #0 r255898: Thu Sep 26 22:50:31 UTC 2013 root@bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: current process = 0 (dummynet) trap number = 12 panic: page fault cpuid = 7 KDB: stack backtrace: #0 0xffffffff80947986 at kdb_backtrace+0x66 #1 0xffffffff8090d9ae at panic+0x1ce #2 0xffffffff80cf20d0 at trap_fatal+0x290 #3 0xffffffff80cf2431 at trap_pfault+0x211 #4 0xffffffff80cf29e4 at trap+0x344 #5 0xffffffff80cdbd13 at calltrap+0x8 #6 0xffffffff809c5959 at bpf_mtap2+0x89 #7 0xffffffff8188e11a at ng_iface_bpftap+0x2a #8 0xffffffff8188eb11 at ng_iface_output+0xf1 #9 0xffffffff80a3a104 at ip_output+0xd74 #10 0xffffffff81864edc at dummynet_send+0x13c #11 0xffffffff81865467 at dummynet_task+0x1b7 #12 0xffffffff80954554 at taskqueue_run_locked+0x74 #13 0xffffffff80955506 at taskqueue_thread_loop+0x46 #14 0xffffffff808db67f at fork_exit+0x11f #15 0xffffffff80cdc23e at fork_trampoline+0xe Uptime: 21d19h53m27s Dumping 1450 out of 16359 MB:..2%..12%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel/if_carp.ko...Reading symbols from /boot/kernel/if_carp.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_carp.ko Reading symbols from /boot/kernel/pf.ko...Reading symbols from /boot/kernel/pf.ko.symbols...done. done. Loaded symbols for /boot/kernel/pf.ko Reading symbols from /boot/kernel/ipfw.ko...Reading symbols from /boot/kernel/ipfw.ko.symbols...done. done. Loaded symbols for /boot/kernel/ipfw.ko Reading symbols from /boot/kernel/dummynet.ko...Reading symbols from /boot/kernel/dummynet.ko.symbols...done. done. Loaded symbols for /boot/kernel/dummynet.ko Reading symbols from /boot/kernel/ng_socket.ko...Reading symbols from /boot/kernel/ng_socket.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_socket.ko Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from /boot/kernel/netgraph.ko.symbols...done. done. Loaded symbols for /boot/kernel/netgraph.ko Reading symbols from /boot/kernel/ng_mppc.ko...Reading symbols from /boot/kernel/ng_mppc.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_mppc.ko Reading symbols from /boot/kernel/rc4.ko...Reading symbols from /boot/kernel/rc4.ko.symbols...done. done. Loaded symbols for /boot/kernel/rc4.ko Reading symbols from /boot/kernel/ng_ether.ko...Reading symbols from /boot/kernel/ng_ether.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_ether.ko Reading symbols from /boot/kernel/ng_pppoe.ko...Reading symbols from /boot/kernel/ng_pppoe.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_pppoe.ko Reading symbols from /boot/kernel/ng_tee.ko...Reading symbols from /boot/kernel/ng_tee.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_tee.ko Reading symbols from /boot/kernel/ng_iface.ko...Reading symbols from /boot/kernel/ng_iface.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_iface.ko Reading symbols from /boot/kernel/ng_ppp.ko...Reading symbols from /boot/kernel/ng_ppp.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_ppp.ko #0 doadump (textdump=) at pcpu.h:234 234 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=) at pcpu.h:234 #1 0xffffffff8090d486 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:449 #2 0xffffffff8090d987 in panic (fmt=0x1
) at /usr/src/sys/kern/kern_shutdown.c:637 #3 0xffffffff80cf20d0 in trap_fatal (frame=0xc, eva=) at /usr/src/sys/amd64/amd64/trap.c:879 #4 0xffffffff80cf2431 in trap_pfault (frame=0xffffff8882642700, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:795 #5 0xffffffff80cf29e4 in trap (frame=0xffffff8882642700) at /usr/src/sys/amd64/amd64/trap.c:463 #6 0xffffffff80cdbd13 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #7 0xffffffff8090adb0 in _rw_rlock (rw=0xfffffe013aade5a8, file=0x0, line=485069968) at /usr/src/sys/kern/kern_rwlock.c:382 #8 0xffffffff809c5959 in bpf_mtap2 (bp=0xfffffe013aade580, data=0xffffff88826429bc, dlen=4, m=0xfffffe0300f46700) at /usr/src/sys/net/bpf.c:2197 #9 0xffffffff8188e11a in ng_iface_bpftap (ifp=, m=0x0, family=144 '\220') at /usr/src/sys/modules/netgraph/iface/../../../netgraph/ng_iface.c:444 #10 0xffffffff8188eb11 in ng_iface_output (ifp=0xfffffe014566a000, m=0xfffffe0300f46700, dst=0xffffff8882642aac, ro=) at /usr/src/sys/modules/netgraph/iface/../../../netgraph/ng_iface.c:394 #11 0xffffffff80a3a104 in ip_output (m=0xfffffe0300f46700, opt=, ro=0xffffff8882642a90, flags=, imo=0x0, inp=0x0) at /usr/src/sys/netinet/ip_output.c:631 #12 0xffffffff81864edc in dummynet_send (m=0xfffffe0300f46700) at /usr/src/sys/modules/dummynet/../../netpfil/ipfw/ip_dn_io.c:655 #13 0xffffffff81865467 in dummynet_task (context=, pending=) at /usr/src/sys/modules/dummynet/../../netpfil/ipfw/ip_dn_io.c:618 #14 0xffffffff80954554 in taskqueue_run_locked (queue=0xfffffe000d2d1a80) at /usr/src/sys/kern/subr_taskqueue.c:312 #15 0xffffffff80955506 in taskqueue_thread_loop (arg=) at /usr/src/sys/kern/subr_taskqueue.c:501 #16 0xffffffff808db67f in fork_exit ( callout=0xffffffff809554c0 , arg=0xffffffff81869be0, frame=0xffffff8882642c40) at /usr/src/sys/kern/kern_fork.c:992 #17 0xffffffff80cdc23e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:606 #18 0x0000000000000000 in ?? () (kgdb) -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Tue Mar 31 16:58:47 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F0AAF5B for ; Tue, 31 Mar 2015 16:58:47 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 75CDD1AF for ; Tue, 31 Mar 2015 16:58:47 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2VGwluA036627 for ; Tue, 31 Mar 2015 16:58:47 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 171711] [dummynet] [panic] Kernel panic in dummynet Date: Tue, 31 Mar 2015 16:58:47 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 8.3-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dblais@interplex.ca X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 16:58:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=171711 --- Comment #3 from dblais@interplex.ca --- Sorry, some errors in my previous post: "Don't know how it scales exactly (linear, quadratic or exponential) nor if it scales with traffic or the amount of pppoe clients but it sure if one of them of a mix of them." should be: "I don't know how it scales exactly (linear, quadratic or exponential) nor if it scales with traffic or the amount of pppoe clients but it sure is one of them or a mix of them." -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Tue Mar 31 17:05:54 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF70C2D8 for ; Tue, 31 Mar 2015 17:05:53 +0000 (UTC) Received: from smtpx.interplex.ca (smtpx.interplex.ca [199.114.234.201]) by mx1.freebsd.org (Postfix) with ESMTP id 9F945300 for ; Tue, 31 Mar 2015 17:05:53 +0000 (UTC) Received: from win2008.domnt.abi.ca (office.abi.ca [199.114.234.18]) by smtpx.interplex.ca (Postfix) with ESMTP id E5E46C3F3B for ; Tue, 31 Mar 2015 13:00:45 -0400 (EDT) Received: from WIN2008.Domnt.abi.ca ([fe80::146d:6eee:c89b:f7d2]) by WIN2008.Domnt.abi.ca ([fe80::146d:6eee:c89b:f7d2%16]) with mapi; Tue, 31 Mar 2015 13:00:46 -0400 From: Dominic Blais To: "freebsd-net@freebsd.org" Date: Tue, 31 Mar 2015 13:00:43 -0400 Subject: Update on issue 171711 (about dummynet / mpd ) Thread-Topic: Update on issue 171711 (about dummynet / mpd ) Thread-Index: AdBr1Dk2J7AyB7i8TmuU6ctj3ocMBA== Message-ID: <2DE61B0869B7484997BCA012845482C701C3D56F585D@WIN2008.Domnt.abi.ca> Accept-Language: fr-FR, fr-CA Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, fr-CA MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 17:05:54 -0000 Hi! Could someone take a look at this please? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D171711 We have the same bug and it's clearly more important and serious than previ= ously tought..... From owner-freebsd-net@FreeBSD.ORG Tue Mar 31 17:09:35 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34DAD3D6; Tue, 31 Mar 2015 17:09:35 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (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 16BB7337; Tue, 31 Mar 2015 17:09:34 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id A83BE1068C5; Tue, 31 Mar 2015 10:09:33 -0700 (PDT) Date: Tue, 31 Mar 2015 10:09:33 -0700 From: hiren panchasara To: Adrian Chadd Subject: Re: Full 32bit flowid from igb(4) Message-ID: <20150331170933.GK10892@strugglingcoder.info> References: <20150323233908.GT53237@strugglingcoder.info> <20150323234214.GU53237@strugglingcoder.info> <20150324154931.GC53237@strugglingcoder.info> <20150330225945.GI10892@strugglingcoder.info> <20150331050628.GJ10892@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IA03tywDYuoVKXrw" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Jack F Vogel , FreeBSD Net , erj@freebsd.org, Jack Vogel , Jason Wolfe X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 17:09:35 -0000 --IA03tywDYuoVKXrw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 03/30/15 at 10:53P, Adrian Chadd wrote: > No, you're absolutely right. However, you (a) get flowid for L3/L4 > V4/v6 but not other things, and (b) I was worried about changing the > default behaviour of the driver, and who knows what other weird crap > people may have done to their local driver. stuff like enabled > checksums instead, or hacked in flowtable support. :) >=20 > So, I'm totally fine if you want to populate the flowid for a given > flow. Totally okay. You just can't set it blindly - you can only set > it when the relevant descriptor bits say "it's a flowid!". Thanks for taking time and answering. Totally agree. Looking at the code, igb does setup everything correctly to get RSS hash in flowid when num_queues > 1. I'm not sure and I've not checked what other chipsets do but I350 looks fine. If needed I am okay to guard this with mac_type check. Jack/Eric: Let me know what you guys think. Cheers, Hiren --IA03tywDYuoVKXrw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVGtTNXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lVUsH/0rQirWlljyzZkN+nlCO59hK NErW1lRJtq1b7ztWQjqWc3VDvCmYdoBAZksEPWm3nQoc6MgNYWLdNkm5zjbudbOh 8Q9+TSCberuS3RlZdM2eCppUuDtm68Uq6Zc8dTfjhWsZ6M5V5jwRMkhN9qRF7i0Y gVYA4eh0f0qyeIS0wc3wMi06ZjC6ve7zCSZk11i0knrX0kLAyEPyzilF1b+286IU nrcp0I55eLFy4X2cnTq/JWMWpjOf014468fhFS0VtPSF1wckTvlG3vvfz6LHRFMm LsAyai+mlTx05xIRrtFYA7LMwEepRnLVUM0WxlBEahMogsRFkzmhYXA5nSDg+zs= =wcC7 -----END PGP SIGNATURE----- --IA03tywDYuoVKXrw-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 31 17:35:25 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 67A9ED7E for ; Tue, 31 Mar 2015 17:35:25 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D19B8CE for ; Tue, 31 Mar 2015 17:35:25 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2VHZPop014466 for ; Tue, 31 Mar 2015 17:35:25 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 171711] [dummynet] [panic] Kernel panic in dummynet Date: Tue, 31 Mar 2015 17:35:25 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 8.3-STABLE 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: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 17:35:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=171711 --- Comment #4 from Hiren Panchasara --- (In reply to dblais from comment #2) I cannot look into this right now but noticed that what you are reporting looks different than the original post. That seems double free and what you are seeing is locking issue in bpf. I don't know the code very well but that's my understanding. 1 more suggestion, if you have many servers with the exact same panic, what is the frequency of the panics? Can you provide any more info? It'd be really helpful if you can run -current or stable10/release10 on one of those machines as those branches are actively being worked on and there are higher chances that what you are seeing _might_ have been fixed there. my 2 c. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Tue Mar 31 18:15:20 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CFEF096F; Tue, 31 Mar 2015 18:15:20 +0000 (UTC) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8E4BDD7B; Tue, 31 Mar 2015 18:15:20 +0000 (UTC) Received: by ignm3 with SMTP id m3so17135247ign.0; Tue, 31 Mar 2015 11:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=OuEVmyI/F4rWM1uTrGllgNA3h41Pb5UjFUoDngoK47g=; b=ZGKJ/MkFgfjLjo4bb4PhzsRc2NzfoOIuhyh3yjAhslTAWm6gZioVX/R7jb/dkn1gWM 5xHjsrIQEvK/L0LxLan+S+0CJTM6Cky1zyFqH4YyyqaOSsbQlr3FpgAfMgbXEiJtsktw PkFzse93EAJsUkNwHPUqYEm4jJYSHXIaD2sGr2RCD5bqxu6H4Wuw7qI116vwponyLK72 bo+aWeOCnIvpz1zDNRCfOeWH8f96QvM3dsbxCpCPLwuSK5DepRTRtlLSkM8GCs8TRH2a 2787b4mfozHD+Rs8XwSgD9K/fB2hNH8Lv++q/yyIL/r0zyBPX3ZZ53RvPyDXhj4T2PN3 Zomw== MIME-Version: 1.0 X-Received: by 10.42.109.12 with SMTP id j12mr27929355icp.22.1427825719695; Tue, 31 Mar 2015 11:15:19 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Tue, 31 Mar 2015 11:15:19 -0700 (PDT) In-Reply-To: <20150331170933.GK10892@strugglingcoder.info> References: <20150323233908.GT53237@strugglingcoder.info> <20150323234214.GU53237@strugglingcoder.info> <20150324154931.GC53237@strugglingcoder.info> <20150330225945.GI10892@strugglingcoder.info> <20150331050628.GJ10892@strugglingcoder.info> <20150331170933.GK10892@strugglingcoder.info> Date: Tue, 31 Mar 2015 11:15:19 -0700 X-Google-Sender-Auth: 3ki58GAyz-cRP1fQJyG6CoHqWIE Message-ID: Subject: Re: Full 32bit flowid from igb(4) From: Adrian Chadd To: hiren panchasara Content-Type: text/plain; charset=UTF-8 Cc: Jack F Vogel , FreeBSD Net , erj@freebsd.org, Jack Vogel , Jason Wolfe X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 18:15:20 -0000 Yeah, I think the right thing to do is: * If the descriptor says it's RSS, then use the flowid + rss type * else, set it to queue id and set the type to opaque. -a From owner-freebsd-net@FreeBSD.ORG Tue Mar 31 23:39:16 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0BC14EFE for ; Tue, 31 Mar 2015 23:39:16 +0000 (UTC) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id D0C2AAA7 for ; Tue, 31 Mar 2015 23:39:15 +0000 (UTC) Received: from yuri.doctorlan.com (c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128]) (authenticated bits=0) by shell1.rawbw.com (8.14.9/8.14.9) with ESMTP id t2VNdE8J051627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 31 Mar 2015 16:39:14 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128] claimed to be yuri.doctorlan.com Message-ID: <551B3021.4050206@rawbw.com> Date: Tue, 31 Mar 2015 16:39:13 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: net@freebsd.org Subject: tap(4): will it be more reasonable if it preserved UP/DOWN state, when closed? Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 23:39:16 -0000 Currently tap(4) device gets to 'down' state when the last process closes it, regardless of the original 'up/down' state. Will it be reasonable to modify this behavior and keep this bit 'was_up_before_open', and leave it 'up' if it was 'up' when it was first opened? Practically speaking, I set it up in rc.conf to be 'up' with the particular IP, but it goes to 'down' state when VirtualBox closes it. If tap(4) can be 'up' without users, there shouldn't be any problem in leaving it 'up' after use as well? Yuri From owner-freebsd-net@FreeBSD.ORG Wed Apr 1 01:24:17 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD99468A for ; Wed, 1 Apr 2015 01:24:17 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 89A468DE for ; Wed, 1 Apr 2015 01:24:17 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t311OHjD002320 for ; Wed, 1 Apr 2015 01:24:17 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t311OHmW002319; Wed, 1 Apr 2015 01:24:17 GMT (envelope-from root) Date: Wed, 1 Apr 2015 01:24:17 +0000 To: freebsd-net@freebsd.org From: "nvass-gmx.com (Nikos Vassiliadis)" Subject: [Differential] [Commented On] D1944: PF and VIMAGE fixes Message-ID: <02f354cff103057d71261129101830d6@localhost.localdomain> X-Priority: 3 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-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NDc2NzM0MzY4OTdiYThiNTU1MjY2ZDZmMTJiIFUbSME= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 01:24:17 -0000 nvass-gmx.com added a comment. >>! In D1944#11, @kristof wrote: > Don't we still need to do all of this somewhere? >>! In D1944#11, @kristof wrote: > Don't we still need to do all of this somewhere? INLINE COMMENTS sys/netpfil/pf/pf_ioctl.c:325 pf_unload is called before pf_vnet_unit, this is why we do very little things in pf_unload. We need everything until the last vnet is destroyed. sys/netpfil/pf/pf_ioctl.c:3725 The patch includes per-VNET initialization, so this is not need anymore. pf_vnet_init() handles all per-VNET initialization, including DEFAULT_VNET. REVISION DETAIL https://reviews.freebsd.org/D1944 To: nvass-gmx.com, gnn, bz, zec, trociny, glebius, rodrigc, kristof Cc: freebsd-virtualization, freebsd-pf, freebsd-net From owner-freebsd-net@FreeBSD.ORG Wed Apr 1 02:01:59 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E608B1B7; Wed, 1 Apr 2015 02:01:58 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (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 C4FE6D22; Wed, 1 Apr 2015 02:01:58 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id 483EE106CDA; Tue, 31 Mar 2015 19:01:52 -0700 (PDT) Date: Tue, 31 Mar 2015 19:01:52 -0700 From: hiren panchasara To: freebsd-net@freebsd.org Subject: Re: em(4): difference between missed_packets and rx_overrun Message-ID: <20150401020152.GM10892@strugglingcoder.info> References: <20150326200853.GA19536@strugglingcoder.info> <20150327173334.GB39674@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kunpHVz1op/+13PW" Content-Disposition: inline In-Reply-To: <20150327173334.GB39674@strugglingcoder.info> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: jfv@freebsd.org, erj@freebsd.org, nitroboost@gmail.com X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 02:01:59 -0000 --kunpHVz1op/+13PW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 03/27/15 at 10:33P, hiren panchasara wrote: > + jfv, erj from Intel. >=20 > On 03/26/15 at 01:08P, hiren panchasara wrote: > > This is what we are seeing on em(4) 82574L chipset running stable/10: > >=20 > > dev.em.0.mac_stats.missed_packets: 1441927 > > dev.em.0.interrupts.rx_overrun: 153 > >=20 > > From the datasheet: > > http://www.intel.com/content/www/us/en/ethernet-controllers/82574l-gbe-= controller-datasheet.html > >=20 > > 10.2.7.4 Missed Packets Count - MPC (0x04010; R) > > Counts the number of missed packets. Packets are missed when the receive > > FIFO has insufficient space to store the incoming packet. This could be > > caused because of too few buffers allocated, or because there is > > insufficient bandwidth on the IO bus. Events setting this counter > > cause RXO, the receiver overrun interrupt, to be set. This register > > does not increment if receives are not enabled. > >=20 > > 10.2.4.1 Interrupt Cause Read Register - ICR (0x000C0; RC/WC) > > RXO Receiver Overrun > > Set on receive data FIFO overrun. Could be caused either because > > there are no available buffers or because PCIe receive bandwidth is > > inadequate. > >=20 > > So, first one is a count and another one is an interrupt. Are these 2 > > related? Both seem to be happen when on card FIFO gets full. We see no > > evidence of RX queue on the host being full based on > > dev.em.0.mac_stats.recv_no_buff. > >=20 > > Many a times we see missed_packets increasing without rx_overrun > > changing. > >=20 > > The spec says there is a 40KB buffer on card which seems to be used by > > both RX and TX? Is is split between them for 20KB each? OR is it > > possible that when we are doing high rate TX, we use up that buffer and > > RX suffers from that? So, I found some seemingly useful things in the spec: 10.2.12 Diagnostic Register Descriptions I tried to read on-chip FIFO head/tail to make a sense of what we have there when we see mpc (missed packet count) increase. In em_update_stats_counters() whenever I see mpc increasing, I go print following registers. fhead =3D E1000_READ_REG(&adapter->hw, E1000_RDFH); ftail =3D E1000_READ_REG(&adapter->hw, E1000_RDFT); fheads =3D E1000_READ_REG(&adapter->hw, E1000_RDFHS); ftails =3D E1000_READ_REG(&adapter->hw, E1000_RDFTS); fcount =3D E1000_READ_REG(&adapter->hw, E1000_RDFPC); But I do not see any pattern here. Some times I see a large differenec between head and tail and still no mpc increase and sometimes mpc++ when head/tail are following eachother closely. Also, fcount E1000_RDFPC which is supposed to be "The number of received packets currently in the RX FIFO." is always 0 OR a moderately low number. That doesn't make sense to me. If FIFO is not full why do we get so many missed packets? cheers, Hiren --kunpHVz1op/+13PW Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVG1GPXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lLSYH/27M2X+5Kj3YCgPH5kEWMyts +kO7dOrPPLa1VOR1qC++M1SE3+0N9m7TSSAXe0NLretU1ln+v+2G94xAOoRh7IXl p+07fO/zMgqwsKVjzsahkSC7c8L/EdXgWd5kT5XKtuV6PyONgXUVTcaFFwDgJ74v g/w6CgsqVURKgH+n/uteG77VCZkrKzQ/HIvUMKOnjXw53HmbwdeAF3SmH7W2Hslq EeyYdH3lmxxWjiQW3Yb/JpXP6Ig2JiElsvjrsPLopKkVk9TKhigWQT5RDjOHtTmc HVz0kCRVhXUQbG5DDGlShnfig+TVJPmAmpmGxgkCgHdR38BEY+KX1peGICISZoU= =2bW7 -----END PGP SIGNATURE----- --kunpHVz1op/+13PW-- From owner-freebsd-net@FreeBSD.ORG Wed Apr 1 06:19:41 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93C4BC3E for ; Wed, 1 Apr 2015 06:19:41 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 799CD6CB for ; Wed, 1 Apr 2015 06:19:41 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t316Je3e050799 for ; Wed, 1 Apr 2015 06:19:41 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 171711] [dummynet] [panic] Kernel panic in dummynet Date: Wed, 01 Apr 2015 06:19:41 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 8.3-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ae@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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 06:19:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=171711 Andrey V. Elsukov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ae@FreeBSD.org --- Comment #7 from Andrey V. Elsukov --- (In reply to dblais from comment #2) > #6 0xffffffff80cdbd13 in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:232 > #7 0xffffffff8090adb0 in _rw_rlock (rw=0xfffffe013aade5a8, file=0x0, > line=485069968) at /usr/src/sys/kern/kern_rwlock.c:382 > #8 0xffffffff809c5959 in bpf_mtap2 (bp=0xfffffe013aade580, > data=0xffffff88826429bc, dlen=4, m=0xfffffe0300f46700) > at /usr/src/sys/net/bpf.c:2197 > #9 0xffffffff8188e11a in ng_iface_bpftap (ifp=, m=0x0, > family=144 '\220') > at /usr/src/sys/modules/netgraph/iface/../../../netgraph/ng_iface.c:444 > #10 0xffffffff8188eb11 in ng_iface_output (ifp=0xfffffe014566a000, > m=0xfffffe0300f46700, dst=0xffffff8882642aac, ro=) > at /usr/src/sys/modules/netgraph/iface/../../../netgraph/ng_iface.c:394 This panic looks different. Probably an interface has gone away and BPF's interface departure handler already destroyed bif_lock. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Wed Apr 1 05:15:37 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5C4F41B9B for ; Wed, 1 Apr 2015 05:15:37 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 43582C65 for ; Wed, 1 Apr 2015 05:15:37 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t315Fbjg001396 for ; Wed, 1 Apr 2015 05:15:37 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 171711] [dummynet] [panic] Kernel panic in dummynet Date: Wed, 01 Apr 2015 05:15:37 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 8.3-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: eugen@grosbein.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: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 05:15:37 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=171711 --- Comment #6 from eugen@grosbein.net --- (In reply to Hiren Panchasara from comment #4) This PR is probably duplicate of my later PR *195102* that contains more details. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Wed Apr 1 05:12:27 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2CE481AFF for ; Wed, 1 Apr 2015 05:12:27 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 13A91C1F for ; Wed, 1 Apr 2015 05:12:27 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t315CQNW099128 for ; Wed, 1 Apr 2015 05:12:26 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 171711] [dummynet] [panic] Kernel panic in dummynet Date: Wed, 01 Apr 2015 05:12:26 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 8.3-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: eugen@grosbein.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: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 05:12:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=171711 --- Comment #5 from eugen@grosbein.net --- (In reply to Hiren Panchasara from comment #4) This PR is probably duplicate of my later PR 149513 that contains more details. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Wed Apr 1 10:13:51 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D14C177D for ; Wed, 1 Apr 2015 10:13:51 +0000 (UTC) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 8B3713A1 for ; Wed, 1 Apr 2015 10:13:51 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id A56492842F; Wed, 1 Apr 2015 12:13:42 +0200 (CEST) Received: from illbsd.quip.test (ip-89-177-50-74.net.upcbroadband.cz [89.177.50.74]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 6545628428; Wed, 1 Apr 2015 12:13:41 +0200 (CEST) Message-ID: <551BC4D5.9010006@quip.cz> Date: Wed, 01 Apr 2015 12:13:41 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32 MIME-Version: 1.0 To: Yuri , net@freebsd.org Subject: Re: tap(4): will it be more reasonable if it preserved UP/DOWN state, when closed? References: <551B3021.4050206@rawbw.com> In-Reply-To: <551B3021.4050206@rawbw.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 10:13:51 -0000 Yuri wrote on 04/01/2015 01:39: > Currently tap(4) device gets to 'down' state when the last process > closes it, regardless of the original 'up/down' state. > Will it be reasonable to modify this behavior and keep this bit > 'was_up_before_open', and leave it 'up' if it was 'up' when it was first > opened? > > Practically speaking, I set it up in rc.conf to be 'up' with the > particular IP, but it goes to 'down' state when VirtualBox closes it. > > If tap(4) can be 'up' without users, there shouldn't be any problem in > leaving it 'up' after use as well? Doesn't sysctl net.link.tap.up_on_open=1 fix your problem? Miroslav Lachman From owner-freebsd-net@FreeBSD.ORG Wed Apr 1 10:37:34 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 688A4E04 for ; Wed, 1 Apr 2015 10:37:34 +0000 (UTC) Received: from kerio.tuxis.nl (alcyone.saas.tuxis.net [31.3.111.19]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DB945810 for ; Wed, 1 Apr 2015 10:37:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tuxis.nl; s=mail; h=from:subject:date:message-id:to:mime-version:content-type; bh=BStJw8kQsNtdpWWnBE3m+syJhR8rHmrOkPVUBWdpYng=; b=S+oXQYWCBRpmp5xrqXkybalrEHH6bCh795+EetVX7OcSfwTpNFUZRq9fE/ZL12WdpyWv57S+Qkgb5 0QAfvNg/OuMy/aJj+S5FXIUR4w9OlGTbhR4Iu/ZtqTvEICEenlDT/uacvnsVTUmAGGj/9mOqHNemSP coUkMS7noiWn6mL6NvKcugNau3TYuliCzZ5V2QwIoOsZBxqwVrWNqp/8rk7GsPIbmmsjVnA6SFRLyW oG5k49QBwSwlUmBetKzqPm81xAO7IPycZ1qOATOvbY3xkMW/VrGDApIw/oypZ4phBJ1hxiiiWS+rne vXMjzUR60U0SZH9T1ON9YYFS6unN6wg== X-Footer: dHV4aXMubmw= Received: from [87.212.163.171] ([87.212.163.171]) by kerio.tuxis.nl (Kerio Connect 8.5.0 beta 1) for freebsd-net@freebsd.org; Wed, 1 Apr 2015 12:07:19 +0200 Date: Wed, 1 Apr 2015 12:07:19 +0200 Subject: Urgent matter: LACP trunk stops distributing X-Mailer: Kerio Connect 8.5.0 beta 1/Kerio Connect Client X-User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0 Message-ID: <1953214074-10699@kerio.tuxis.nl> X-Priority: 3 Importance: Normal MIME-Version: 1.0 MIME-Version: 1.0 MIME-Version: 1.0 MIME-Version: 1.0 MIME-Version: 1.0 MIME-Version: 1.0 MIME-Version: 1.0 MIME-Version: 1.0 MIME-Version: 1.0 From: Mark Schouten To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="=-s6s/AkihafHNXJiAlI+f" X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 10:37:34 -0000 --=-s6s/AkihafHNXJiAlI+f Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, I've got an urgent matter on my hands, my FreeBSD iScsibox has dropped it's= LACP trunk twice in the last 24 hours, which causes a whole lot of issues = on my VPS cluster, using that storage.=20 It's a FreeBSD box with two igb-interfaces in an LACP trunk with jumboframe= s and vlans. If the connection drops, the only thing I see is: Apr=C2=A0 1 10:37:18 zstore02 kernel: igb0: Interface stopped DISTRIBUTING,= possible flapping Apr=C2=A0 1 10:37:28 zstore02 kernel: igb1: Interface stopped DISTRIBUTING,= possible flapping The switch has nothing to say, so it doesn't seem that there are acual link= flaps. I have a feeling that it's this LACP trunk that goes haywire somewhe= re on the FreeBSD side. If anyone can help me with this, I'd be grateful. I= f someone (preferably EU-based) wants to help out professionally as a consu= ltant, that would be fine too. Or if anyone knows someone in .nl that offer= s this level of expertise on consultingbase, let me know. I'm running 10.1-RELEASE on the box, see the (AFAICS) relevant config below= . The switch is a Brocade ICX6430. [root@zstore02 ~]# ifconfig lagg0 lagg0: flags=3D8843 metric 0 mtu 90= 00 =C2=A0=C2=A0=C2=A0 options=3D4019b =C2=A0=C2=A0=C2=A0 ether 0c:c4:7a:12:13:dc =C2=A0=C2=A0=C2=A0 nd6 options=3D29 =C2=A0=C2=A0=C2=A0 media: Ethernet autoselect =C2=A0=C2=A0=C2=A0 status: active =C2=A0=C2=A0=C2=A0 laggproto lacp lagghash l2,l3,l4 =C2=A0=C2=A0=C2=A0 laggport: em1 flags=3D0<> =C2=A0=C2=A0=C2=A0 laggport: em0 flags=3D0<> =C2=A0=C2=A0=C2=A0 laggport: igb1 flags=3D1c =C2=A0=C2=A0=C2=A0 laggport: igb0 flags=3D1c [root@zstore02 ~]# sysctl -a | grep lacp net.link.lagg.lacp.debug: 0 net.link.lagg.0.lacp.lacp_strict_mode: 1 net.link.lagg.0.lacp.debug.rx_test: 0 net.link.lagg.0.lacp.debug.tx_test: 0 Met vriendelijke groeten, --=C2=A0 Kerio Operator in de Cloud? https://www.kerioindecloud.nl/ Mark Schouten | Tuxis Internet Engineering KvK:=C2=A061527076=C2=A0| http://www.tuxis.nl/ T: 0318 200208 | info@tuxis.nl= --=-s6s/AkihafHNXJiAlI+f Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: Electronic Signature S/MIME Content-Transfer-Encoding: base64 MIIRwQYJKoZIhvcNAQcCoIIRsjCCEa4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCDt4w ggUbMIIEA6ADAgECAhAsv+VdGX6YsSHI/WRu2j2JMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE0MDcwMTAwMDAwMFoXDTE1MDcwMTIzNTk1OVow HjEcMBoGCSqGSIb3DQEJARYNbWFya0B0dXhpcy5ubDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBANHu3SxlMZOG5GA0/mqtRXR1QmWwhUXzmCIprI0IPtSBWSA31YBJ5qcmXRhLzaiTB3Fr UpIGkW5aAZnDms9DD64kasF3oZE00Fvfnj/BDGbw098px1PukKfg4hasbTaELAjQTSUj8xRSHzKk VVynvLA/YmyRT/+u3ueK4wdaxcej241xH6mNfZeiKMAvbkv6Tm9vdup0BtqqbRSKcnc01KKrspun Eh73jLIUhP21uJv8vuOTxS1I9zJSlhIcMCEapjBQ+26cQl+s+qBuAs/LP3UPVytSbxvicdhDxtqH npN2h3jJ/+J86zGfQi8bG7EamsULTGHkbgIJL9AdKZRgAKECAwEAAaOCAd0wggHZMB8GA1UdIwQY MBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBR+dMZE22X/SMCyTxYzIP+NMZBNXTAO BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGy MQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiG Rmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2Vj dXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5j b21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBgGA1UdEQQRMA+BDW1hcmtA dHV4aXMubmwwDQYJKoZIhvcNAQEFBQADggEBAIB8FhqaML1EzfvgNwwHDC3k0ICeMerOncgee6uJ KLxwU2mstttX5jtAmgK9RuDOu+TrMkkpF2yxYMTPpSM8nL7r+N/kdogu5Bustol8WTsW1e5vs+Nh hJYFORk113ouur1kSjXuHF8TWy+/PjFJBS/xm/H+/fkghppRU+4Dj2IReUBvlexAPYr4VDxjV7AD xPOXqTQkP15LWGvhTz2YVbJ3IAVOyUNkRhr9QwzToUxXa9k/QAOpXMuvS74AT2RBV/YCEEx7ebRD MAR6lZcbYiV8sXv1ASbnMdO3Fh2F98g+5rJn5PfFH8qLpapsZx0I2/axtSG09QMDJqXd3Ab6NpEw ggUaMIIEAqADAgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQG EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVh dGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hf ZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrh o/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0 mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MP bXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRc WzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAd BgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQI MAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwu dXNlcnRydXN0LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwu Y3JsMHQGCCsGAQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29t L1VUTkFkZFRydXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRy dXN0LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ 9RtaxdKtG3NuPukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1 ei+eupN5yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B 080zX5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCC BJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMC U0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAg TmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5 MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcT DlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsT GGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQg QXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA sjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p 1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K 2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bU MSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjK aJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0 tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8E BAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDeg NYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUG CCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlf sXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5lDd1 ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJxggzpiDbj 2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTGCAqswggKnAgEBMIGo MIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAsv+VdGX6YsSHI/WRu2j2JMAkG BSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUw NDAxMTAwNzE5WjAjBgkqhkiG9w0BCQQxFgQUMyWI2pn433sTjGutluhzeAFLBXsweQYJKoZIhvcN AQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw DQYJKoZIhvcNAQEBBQAEggEAUBjKv2F1Xmkfq+VwkpZxrmeE7kxryFQtHQpqHPQr3ur3rHztQUB0 L0Mr9tdL7NzBsBP8TrBWz4IDbnR2rVoDE4RSpogC/IOGm1fU8ff5PkF8W8fScYNxL9cCMyo0iq5U KRW+z/dOLuNqG82k6IV9j0NwyPsbyFHS71nozrstJkInb1hm8VVNxvqfAV+jmytHmSpsl1z0MU6g 4BEwQk98LmDc762r1sd9JctkhpidkJ8PhotULvdPFoa4LGMjNedQDI7NLCSSVIe/6K6pY1s4d6Kb pu09DBdpi1PQrw1qj0ofngOs+331aGpbFOKnbggFgN3DvX5eUCNmIsmTKqmWJQ== --=-s6s/AkihafHNXJiAlI+f-- From owner-freebsd-net@FreeBSD.ORG Wed Apr 1 10:55:28 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A44C057F for ; Wed, 1 Apr 2015 10:55:28 +0000 (UTC) Received: from noether.irl.styx.org (noether.irl.styx.org [IPv6:2a00:d880:6:1a4::98dc]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "noether.irl.styx.org", Issuer "noether.irl.styx.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 44EF4A03 for ; Wed, 1 Apr 2015 10:55:28 +0000 (UTC) Received: by noether.irl.styx.org (Postfix, from userid 66) id D41C319E2C; Wed, 1 Apr 2015 10:55:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mavrino.styx.org (Postfix) with ESMTP id 680F03A07A3 for ; Wed, 1 Apr 2015 11:50:48 +0100 (BST) Date: Wed, 01 Apr 2015 11:50:48 +0100 (BST) Message-Id: <20150401.115048.1362042954044146751.wwaites@tardis.ed.ac.uk> To: freebsd-net@freebsd.org Subject: ng_netgraph and BGP From: William Waites X-Mailer: Mew version 6.6 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="--Security_Multipart(Wed_Apr__1_11_50_48_2015_924)--" Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 10:55:28 -0000 ----Security_Multipart(Wed_Apr__1_11_50_48_2015_924)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit I run a small network composed of even smaller networks each encapsulated in an autonomous system. I'd like to do traffic accounting using netflow aggregated by ASN. My border routers run FreeBSD and BIRD. Right now, and this is mentioned in ng_netflow(4), we do not fill in the source and destination ASN because there is no information to get this from the routing daemon's RIB. Probably if we come up with such a way it should be generic so it could be used by Quagga, BIRD or OpenBGPD. I've done a little bit of thinking about how this could be done, and come up with two main strategies: 1. A new kind of netgraph node inserted before ng_netflow knows how to query the routing daemon and decorates the packet with the result, which ng_netflow then puts into the flow packet if present. This entails either a copy (tee) or putting the lookup in the data path which may be suboptimal. 2. A new hook added to the ng_netflow node that allows it to query the routing daemon through a different new kind of netgraph node. This is probably better but may be slightly more complicated to implement. Is anyone working on this or has given this though? I wasn't able to find much by searching the list archives. It may be that I will soon have some students that I can set on this task but would not like to unnecessarily duplicate effort. Cheers, -w -- William Waites | School of Informatics http://tardis.ed.ac.uk/~wwaites/ | University of Edinburgh http://www.hubs.net.uk/ | HUBS AS60241 The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ----Security_Multipart(Wed_Apr__1_11_50_48_2015_924)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQIcBAABCgAGBQJVG82IAAoJEHhNnKzjwx5/QhMP/iH7OkNPjQZ64n/GLYXzACGK VTWUfhjWk2GWvY7xmdMqc/djHxrbilGvhHtCyjRyN/n4Ji+nLNi8wo3Y3ESItlit 3txRqnrBXNQWvV64ag6c+8o9XYY+ZpJTo2wGzAUpGxXreco8c8pAzvDUXGkSbI9d fUBn9jdkuM1ETm6AKtvOTqFkMxVihj6ZbX9WD+8YD9LvaG492aMMRQ/ukvMvowHg zdGenrLARHcvJ5EHTgFgzc1ULzVIrmjB3nThWNaEtvs9o62ttLxrxbdpkhIMYV9e zZ38c1g1CVbTyd8iiv+AcoTlMm0BkbR9qxI1ExcRqBHQJxliKbxR5AQ4wXUtzmk6 /YGiV74npR6HeTHu5oN9emu0frLas0Y4QzWozzFeKH8lxxKE0DhOYy/k6Hld53de bfhwlwNMwE7r7OiCWJS7nAUbx67EHKiEnNIOXRlpnvB5pVszteBHmKuuMB+ZJG8b bUHfrfIyFJai5smyOLYZB3QTCdxKmRU7cqycvQzEBK9P4TVM8ZsHQpqyjVVQCiYv sXktOZnwBHCZ2HdLvXs9gqAZq6NJJTtT8ixltUxLLjszXv4gMoX4dp1ai1+IvOUC /vYh2qshy33bihXBFcsZ4DTmoq0UZatxG6tzAewxWSUQoIJZ2LsQw7PzbB1ddiqj cOoYs7vsmkYfzYrKf4nh =Zx1v -----END PGP SIGNATURE----- ----Security_Multipart(Wed_Apr__1_11_50_48_2015_924)---- From owner-freebsd-net@FreeBSD.ORG Wed Apr 1 11:32:55 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 946C4ED for ; Wed, 1 Apr 2015 11:32:55 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49DA1E20 for ; Wed, 1 Apr 2015 11:32:55 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-255-201.lns20.per4.internode.on.net [121.45.255.201]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t31BWoF8024449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 1 Apr 2015 04:32:53 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <551BD75C.4040505@freebsd.org> Date: Wed, 01 Apr 2015 19:32:44 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: William Waites , freebsd-net@freebsd.org Subject: Re: ng_netgraph and BGP References: <20150401.115048.1362042954044146751.wwaites@tardis.ed.ac.uk> In-Reply-To: <20150401.115048.1362042954044146751.wwaites@tardis.ed.ac.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 11:32:55 -0000 On 4/1/15 6:50 PM, William Waites wrote: > I run a small network composed of even smaller networks each > encapsulated in an autonomous system. I'd like to do traffic > accounting using netflow aggregated by ASN. My border routers run > FreeBSD and BIRD. > > Right now, and this is mentioned in ng_netflow(4), we do not fill in > the source and destination ASN because there is no information to get > this from the routing daemon's RIB. Probably if we come up with such a > way it should be generic so it could be used by Quagga, BIRD or > OpenBGPD. > > I've done a little bit of thinking about how this could be done, and > come up with two main strategies: > > 1. A new kind of netgraph node inserted before ng_netflow knows how > to query the routing daemon and decorates the packet with the > result, which ng_netflow then puts into the flow packet if > present. This entails either a copy (tee) or putting the lookup > in the data path which may be suboptimal. > > 2. A new hook added to the ng_netflow node that allows it to query > the routing daemon through a different new kind of netgraph > node. This is probably better but may be slightly more > complicated to implement. > > Is anyone working on this or has given this though? I wasn't able to > find much by searching the list archives. It may be that I will soon > have some students that I can set on this task but would not like to > unnecessarily duplicate effort. there is no reason the netflow node could not be modified to make external requests.. it could certainly spawn off a worker thread that could do those sorts of things. > > Cheers, > -w > > -- > William Waites | School of Informatics > http://tardis.ed.ac.uk/~wwaites/ | University of Edinburgh > http://www.hubs.net.uk/ | HUBS AS60241 > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. From owner-freebsd-net@FreeBSD.ORG Wed Apr 1 14:24:08 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6CEEB76E for ; Wed, 1 Apr 2015 14:24:08 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5257F38C for ; Wed, 1 Apr 2015 14:24:08 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t31EO8bG002539 for ; Wed, 1 Apr 2015 14:24:08 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 185967] [lagg] [patch] Link Aggregation LAGG: LACP not working in 10.0 Date: Wed, 01 Apr 2015 14:24:06 +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: vanheugten@gmail.com X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 14:24:08 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185967 --- Comment #18 from Jeroen van Heugten --- In our case the problem was due to a bug in TSO (tcp segment offloading). This has been resolved in 10.1. You can easily exclude issues TSO by turning it temporary off for your interfaces (ifconfig ix# -tso). -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Wed Apr 1 17:19:23 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6450A494 for ; Wed, 1 Apr 2015 17:19:23 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4A61AC7D for ; Wed, 1 Apr 2015 17:19:23 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t31HJN30029358 for ; Wed, 1 Apr 2015 17:19:23 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 171711] [dummynet] [panic] Kernel panic in dummynet Date: Wed, 01 Apr 2015 17:19: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: 8.3-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dblais@interplex.ca X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 17:19:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=171711 --- Comment #8 from dblais@interplex.ca --- I just opened a new bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199096 since my error is similar but different. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Wed Apr 1 18:08:57 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C8D534A for ; Wed, 1 Apr 2015 18:08:57 +0000 (UTC) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (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 AFB2327F for ; Wed, 1 Apr 2015 18:08:56 +0000 (UTC) Received: by lbbug6 with SMTP id ug6so42450894lbb.3 for ; Wed, 01 Apr 2015 11:08:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=tQMaGfsDgDraiTEV1bxKSJj+v7PNo0YcTXfW00sT7x0=; b=sjgDf7JkRhckqaQLivNUEXINWpijozQyW2zcVS4qrsfGlQRA6aNDoOK+CrO8qog83F MHcpBgkWy66JAxObkyBMLTWfCvE/j+pF974CiPtrp5QvWA7S9xmbbc+2mQLbOyUSU/NK e0H3yy3mF1AcvmizjeOsWgIOq6AIOG5xgq2BgUgNsNxvPUel51vqQwvMibzbXioLM8S6 32LSy5L/zUVt/kdGbiEdySO7m3h/3aHoVrowPWhYAbfLFX++2ZXEU3re0/OjNdhLYu6I LXVfpHl2Sf7zbIpBa1f1dqtPez5rZL8tq19zpoZ5XRqQyWqCIh8j7WkfMwROuWwpgzga +DDw== MIME-Version: 1.0 X-Received: by 10.112.63.165 with SMTP id h5mr36345786lbs.16.1427911734890; Wed, 01 Apr 2015 11:08:54 -0700 (PDT) Sender: ndenev@gmail.com Received: by 10.112.130.231 with HTTP; Wed, 1 Apr 2015 11:08:54 -0700 (PDT) In-Reply-To: <20150401.115048.1362042954044146751.wwaites@tardis.ed.ac.uk> References: <20150401.115048.1362042954044146751.wwaites@tardis.ed.ac.uk> Date: Wed, 1 Apr 2015 20:08:54 +0200 X-Google-Sender-Auth: 8Q7mF8fly5IAxzrsgFeW2Wgl7sw Message-ID: Subject: Re: ng_netgraph and BGP From: Nikolay Denev To: William Waites Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 18:08:57 -0000 On Wed, Apr 1, 2015 at 12:50 PM, William Waites wrote: > I run a small network composed of even smaller networks each > encapsulated in an autonomous system. I'd like to do traffic > accounting using netflow aggregated by ASN. My border routers run > FreeBSD and BIRD. > > Right now, and this is mentioned in ng_netflow(4), we do not fill in > the source and destination ASN because there is no information to get > this from the routing daemon's RIB. Probably if we come up with such a > way it should be generic so it could be used by Quagga, BIRD or > OpenBGPD. > > I've done a little bit of thinking about how this could be done, and > come up with two main strategies: > > 1. A new kind of netgraph node inserted before ng_netflow knows how > to query the routing daemon and decorates the packet with the > result, which ng_netflow then puts into the flow packet if > present. This entails either a copy (tee) or putting the lookup > in the data path which may be suboptimal. > > 2. A new hook added to the ng_netflow node that allows it to query > the routing daemon through a different new kind of netgraph > node. This is probably better but may be slightly more > complicated to implement. > > Is anyone working on this or has given this though? I wasn't able to > find much by searching the list archives. It may be that I will soon > have some students that I can set on this task but would not like to > unnecessarily duplicate effort. > > Cheers, > -w > > -- > William Waites | School of Informatics > http://tardis.ed.ac.uk/~wwaites/ | University of Edinburgh > http://www.hubs.net.uk/ | HUBS AS60241 > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > Hi, It's not ng_netflow, but if you need this today you can take a look at http://www.pmacct.net ? (there is a package/port too). It comes with BGP daemon (stripped down quagga) and can export this data. --Nikolay From owner-freebsd-net@FreeBSD.ORG Wed Apr 1 18:24:13 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E649478F for ; Wed, 1 Apr 2015 18:24:13 +0000 (UTC) Received: from smtpx.interplex.ca (smtpx.interplex.ca [199.114.234.201]) by mx1.freebsd.org (Postfix) with ESMTP id B77E866C for ; Wed, 1 Apr 2015 18:24:13 +0000 (UTC) Received: from win2008.domnt.abi.ca (office.abi.ca [199.114.234.18]) by smtpx.interplex.ca (Postfix) with ESMTP id 5E56EC3F3B for ; Wed, 1 Apr 2015 14:24:06 -0400 (EDT) Received: from WIN2008.Domnt.abi.ca ([fe80::146d:6eee:c89b:f7d2]) by WIN2008.Domnt.abi.ca ([fe80::146d:6eee:c89b:f7d2%16]) with mapi; Wed, 1 Apr 2015 14:24:07 -0400 From: Dominic Blais To: "freebsd-net@freebsd.org" Date: Wed, 1 Apr 2015 14:24:05 -0400 Subject: New BR 199096 about mpd / ipfw causing kernel panics Thread-Topic: New BR 199096 about mpd / ipfw causing kernel panics Thread-Index: AdBsqQlphwGD9U+qRl6U+WHMsxqmPw== Message-ID: <2DE61B0869B7484997BCA012845482C701C3D56F587F@WIN2008.Domnt.abi.ca> Accept-Language: fr-FR, fr-CA Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: fr-FR, fr-CA MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 18:24:14 -0000 Hi, I posted into BR 171711 but as Andrey V. Elsukov pointed out, my issue is a= bit different so I opened a new one (BR 199096). -- [cid:image001.gif@01D06C87.8255CBF0] From owner-freebsd-net@FreeBSD.ORG Wed Apr 1 18:28:53 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4BB3885C; Wed, 1 Apr 2015 18:28:53 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (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 32975698; Wed, 1 Apr 2015 18:28:52 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id 08996106E14; Wed, 1 Apr 2015 11:28:52 -0700 (PDT) Date: Wed, 1 Apr 2015 11:28:51 -0700 From: hiren panchasara To: "Andrey V. Elsukov" Subject: Re: pagefault in IPv6 codepath in defrouter_select() Message-ID: <20150401182851.GA55015@strugglingcoder.info> References: <20150325214832.GI53237@strugglingcoder.info> <5514560C.5070406@FreeBSD.org> <20150326190858.GL53237@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="k+w/mQv8wyuph6w0" Content-Disposition: inline In-Reply-To: <20150326190858.GL53237@strugglingcoder.info> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-net@freebsd.org, hrs@freebsd.org, nitroboost@gmail.com, markj@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 18:28:53 -0000 --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 03/26/15 at 12:08P, hiren panchasara wrote: > My mailclient is doing something funny. Sorry for that. Trying again to > reply to this tread actually. >=20 > On 03/26/15 at 09:55P, Andrey V. Elsukov wrote: > > On 26.03.2015 00:48, hiren panchasara wrote: > > > This is 3rd occurence of this panic. What could be the cause? > > > I have vmcore and can provide more info if needed. > >=20 > > Hi, > >=20 > > the problem is that ND6 code maintains at least two lists of prefixes > > without any locking: V_nd_defrouter and V_nd_prefix. >=20 > I am not too familiar with the code here but is following relevant here? > https://lists.freebsd.org/pipermail/freebsd-net/2013-February/034695.html >=20 > Also ccing markj@ Andrey, Did you get a chance to look at this or have any comments? Thanks in advance, Hiren --k+w/mQv8wyuph6w0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVHDjjXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/l8CwH/joU8ignYxkCnrwUWHbjCtmW ZUmsj2M8C3ORtazP94ItDSLGAW2XkCz2FFm5dXgR23a6bxZ8JHa/0cQToW2262gt DEUzJYFsAKx+54kTnLde4RgSkPgVs7AY0Ex1rJe6799bhG1BECued+Ulc3c1k7rK 35bY7oaVf5HNJ5rTKm0KlqQp30OjvySiVm6jZYour5BzS5jQrCEBFoTMFyVFl072 v4U9PUIRFR2t+v0FUl58hFjnsCxA/8nBShrAxM3/QiAqZTUZq4VNTF+w4SYjXZ0C iHMNhqy1h/Njt/n0xAogAiZoCQJD83JVm6vuxOJvCc/ZQ7v89fBhaBHi96mMYuQ= =4VEk -----END PGP SIGNATURE----- --k+w/mQv8wyuph6w0-- From owner-freebsd-net@FreeBSD.ORG Wed Apr 1 18:40:16 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A6C62C77 for ; Wed, 1 Apr 2015 18:40:16 +0000 (UTC) Received: from noether.irl.styx.org (noether.irl.styx.org [IPv6:2a00:d880:6:1a4::98dc]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "noether.irl.styx.org", Issuer "noether.irl.styx.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 446167FE for ; Wed, 1 Apr 2015 18:40:16 +0000 (UTC) Received: by noether.irl.styx.org (Postfix, from userid 66) id EC9F219E22; Wed, 1 Apr 2015 18:40:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mavrino.styx.org (Postfix) with ESMTP id 2231D3A1412; Wed, 1 Apr 2015 19:35:19 +0100 (BST) Date: Wed, 01 Apr 2015 19:35:18 +0100 (BST) Message-Id: <20150401.193518.925462305272872435.wwaites@tardis.ed.ac.uk> To: nike_d@cytexbg.com Subject: Re: ng_netflow and BGP From: William Waites In-Reply-To: References: <20150401.115048.1362042954044146751.wwaites@tardis.ed.ac.uk> X-Mailer: Mew version 6.6 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="--Security_Multipart(Wed_Apr__1_19_35_18_2015_534)--" Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 18:40:16 -0000 ----Security_Multipart(Wed_Apr__1_19_35_18_2015_534)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit (Fixing the subject header. Oops) On Wed, 1 Apr 2015 20:08:54 +0200, Nikolay Denev said: > It's not ng_netflow, but if you need this today you can take a > look at http://www.pmacct.net ? (there is a package/port too). > It comes with BGP daemon (stripped down quagga) and can export > this data. Hi Nikolay. Thanks, we are actually doing exactly that, so there's no immediate pressure. It's just not the most elegant solution for various reasons. -w -- William Waites | School of Informatics http://tardis.ed.ac.uk/~wwaites/ | University of Edinburgh http://www.hubs.net.uk/ | HUBS AS60241 The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ----Security_Multipart(Wed_Apr__1_19_35_18_2015_534)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQIcBAABCgAGBQJVHDpmAAoJEHhNnKzjwx5/msMP/0lm89uAq6COkENL/HiqUCNj FjK3UhqObq4XLRP4HO/drl9vgqrjg0FnpMUeyHbXE8Z8ppFpVP4WGyS7BhVgfWoO WCLVeJvWIoIcOyQiGx5veKuoptcyG98PUSrtIUwdNUeA7n196Om9tARGFI92C1Zr nQqWlx4SqqczVsBg913f81AWH6q4Wq5IMgz7V/0+YVG8ZCOS5Hu23Fbsqs3YXMtU c5w62+iD4oP1DamhiUg8P6DkkIQu+8vJLXlndRFkuW84qrBkus1qwiKXyfdGVP7g sTMbfRKyX1ZtFhtqBXpaHyupNao/JhPFostyJy1ygd0cfiBOa7u2Ge6eXWbSnzFC p9IEJmti3T1C2SZSNEzs60xlwIxXJgqo8e/QC3GnP8z/jrHVcB+afh9A9Y+MYZ9c dHJ0EkAwE+Yb/y2bnUHgm+XEKYGTT81SRgp8h5xyz/r4iqLq3E4A3X58rznQ7VXh P7MmYftNenLF+nLxfEgxT9ZNqATdfTLaOxG3WemTH9hHUmjTd/6cI2xTwdOPrs6m XyQOt6nHNarLpnhDPVEBXl1SWBaA9yfW0s++0TQZc3fvVuAwh8vSEudqi7sa0g1+ 7vHEfgdyTCox/vAy6fYTiM1S8caR/M0Q7ArZYDkXyG80xI+2CIhPt+jkVbl2RuMo VLYvVJB9I14CFW7PfbOa =6TQy -----END PGP SIGNATURE----- ----Security_Multipart(Wed_Apr__1_19_35_18_2015_534)---- From owner-freebsd-net@FreeBSD.ORG Wed Apr 1 21:49:40 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 136C8B5A for ; Wed, 1 Apr 2015 21:49:40 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D5983EE7 for ; Wed, 1 Apr 2015 21:49:39 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t31LndQn019261 for ; Wed, 1 Apr 2015 21:49:39 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 197076] Only One Port Of Dual Port EC2000S (RTL8111E, r8169) Detected Date: Wed, 01 Apr 2015 21:49:39 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 21:49:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197076 --- Comment #3 from commit-hook@freebsd.org --- A commit references this bug: Author: jhb Date: Wed Apr 1 21:48:59 UTC 2015 New revision: 280970 URL: https://svnweb.freebsd.org/changeset/base/280970 Log: MFC 261790: Add support for managing PCI bus numbers. As with BARs and PCI-PCI bridge I/O windows, the default is to preserve the firmware-assigned resources. PCI bus numbers are only managed if NEW_PCIB is enabled and the architecture defines a PCI_RES_BUS resource type. - Add a helper API to create top-level PCI bus resource managers for each PCI domain/segment. Host-PCI bridge drivers use this API to allocate bus numbers from their associated domain. - Change the PCI bus and CardBus drivers to allocate a bus resource for their bus number from the parent PCI bridge device. - Change the PCI-PCI and PCI-CardBus bridge drivers to allocate the full range of bus numbers from secbus to subbus from their parent bridge. The drivers also always program their primary bus register. The bridge drivers also support growing their bus range by extending the bus resource and updating subbus to match the larger range. - Add support for managing PCI bus resources to the Host-PCI bridge drivers used for amd64 and i386 (acpi_pcib, mptable_pcib, legacy_pcib, and qpi_pcib). - Define a PCI_RES_BUS resource type for amd64 and i386. PR: 197076 Changes: _U stable/10/ stable/10/sys/amd64/include/resource.h stable/10/sys/dev/acpica/acpi_pcib_acpi.c stable/10/sys/dev/acpica/acpi_pcib_pci.c stable/10/sys/dev/cardbus/cardbus.c stable/10/sys/dev/cardbus/cardbusvar.h stable/10/sys/dev/pccbb/pccbb.c stable/10/sys/dev/pccbb/pccbb_isa.c stable/10/sys/dev/pccbb/pccbb_pci.c stable/10/sys/dev/pccbb/pccbbvar.h stable/10/sys/dev/pci/pci.c stable/10/sys/dev/pci/pci_pci.c stable/10/sys/dev/pci/pci_private.h stable/10/sys/dev/pci/pci_subr.c stable/10/sys/dev/pci/pcib_private.h stable/10/sys/i386/include/resource.h stable/10/sys/sparc64/pci/apb.c stable/10/sys/x86/include/legacyvar.h stable/10/sys/x86/pci/pci_bus.c stable/10/sys/x86/pci/qpi.c stable/10/sys/x86/x86/mptable_pci.c -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Wed Apr 1 22:17:06 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A41765C4 for ; Wed, 1 Apr 2015 22:17:06 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8AA49267 for ; Wed, 1 Apr 2015 22:17:06 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t31MH6Gf078551 for ; Wed, 1 Apr 2015 22:17:06 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 197076] Only One Port Of Dual Port EC2000S (RTL8111E, r8169) Detected Date: Wed, 01 Apr 2015 22:17:06 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: jhb@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 22:17:06 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197076 John Baldwin changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|New |Closed --- Comment #4 from John Baldwin --- I have merged the change that I believe should fix this back to stable/10. I do not plan on merging this to 9.x, and I do not plan on trying to get this into 10.1 as an EN. It should be present in 10.2 when that is released. Please reopen if this fix does not work for you when you test it. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Wed Apr 1 22:58:25 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB3CA384 for ; Wed, 1 Apr 2015 22:58:25 +0000 (UTC) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 94895918 for ; Wed, 1 Apr 2015 22:58:25 +0000 (UTC) Received: from yuri.doctorlan.com (c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128]) (authenticated bits=0) by shell1.rawbw.com (8.14.9/8.14.9) with ESMTP id t31MwO8R087076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 1 Apr 2015 15:58:24 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128] claimed to be yuri.doctorlan.com Message-ID: <551C780F.4050202@rawbw.com> Date: Wed, 01 Apr 2015 15:58:23 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Miroslav Lachman <000.fbsd@quip.cz>, net@freebsd.org Subject: Re: tap(4): will it be more reasonable if it preserved UP/DOWN state, when closed? References: <551B3021.4050206@rawbw.com> <551BC4D5.9010006@quip.cz> In-Reply-To: <551BC4D5.9010006@quip.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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 22:58:25 -0000 On 04/01/2015 03:13, Miroslav Lachman wrote: > > Doesn't sysctl net.link.tap.up_on_open=1 fix your problem? net.link.tap.up_on_open only works on open. I am going to create the corresponding net.link.tap.down_on_close. It will have 3 values: 0: up/down state will not change on close 1: (default) state will be preserved as it was before close - makes sense for most users I believe 2: state will change to down (like tap works now) Yuri From owner-freebsd-net@FreeBSD.ORG Thu Apr 2 01:07:52 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B68F0363 for ; Thu, 2 Apr 2015 01:07:52 +0000 (UTC) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) (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 87529867 for ; Thu, 2 Apr 2015 01:07:52 +0000 (UTC) Received: by pdbni2 with SMTP id ni2so72210872pdb.1 for ; Wed, 01 Apr 2015 18:07:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xkBFMMWNL6blysqTXbNXFBWHxHaTVSxKcsshCreXgaU=; b=b3be/WlCiG2HajkLo9FJ+hYygvrSm8c8KtmqaZbu5ww85e/BP540TFnOyfwrpFeUBT pSQaZqyRZ1V+gm1cMoB809waNPszstCT15Q7ikXQxXvxLMuiCIvQQrv+kN45KTSufOQ/ C1569G/FT4DGXBHam6EuvRQzt1CDweZWs8zDwmYC6GpApC86BWf6EsCLeHZTytnQ98Nq d9X0Jnctlqby+hKTnBJqfy/qPAb4DMLXFyEARHcuExCEFHtfftaXcvp0cteq+R2H4QEC Xs1v4Zh1pmxDVKxrWtdz+8pX6vSWCudj6cA5Y7RdcYQzPHUlqwVQ3eMgt1omZL/RT+uX PghA== X-Gm-Message-State: ALoCoQlnC48fs/B4Q1h5yOvUb5CQoKBFr2E0NdB1fOFUpt6dhgyUC19LK5vPlBRY0CnLAu3MAEEy X-Received: by 10.66.150.165 with SMTP id uj5mr83167181pab.54.1427936871363; Wed, 01 Apr 2015 18:07:51 -0700 (PDT) Received: from [128.199.254.70] (sgp.sin.winterei.se. [128.199.254.70]) by mx.google.com with ESMTPSA id x1sm3323484pdn.96.2015.04.01.18.07.49 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Apr 2015 18:07:50 -0700 (PDT) Message-ID: <551C9651.7050003@winterei.se> Date: Thu, 02 Apr 2015 10:07:29 +0900 From: "Paul S." User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: ng_netgraph and BGP References: <20150401.115048.1362042954044146751.wwaites@tardis.ed.ac.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 01:07:52 -0000 Additionally, pmacct doesn't seem to really work in FreeBSD -- as far as the latest versions go. Their use of 'return' (with no args) on functions that are meant to return an int flat out makes it unable to compile on FreeBSD. If you fix those by hand, it compiles, but just seems to segfault -- I didn't get the time to look into it further with GDB. There's another option that claims to be able to do the same thing (introduce BGP accounting data to normal flows - ntop's nprobe (www.ntop.org/products/nprobe/), but it's not free. I don't know if it works in FreeBSD well either.) As to the ng_netflow hook, +1, excellent idea. On 4/2/2015 午前 03:08, Nikolay Denev wrote: > On Wed, Apr 1, 2015 at 12:50 PM, William Waites > wrote: > >> I run a small network composed of even smaller networks each >> encapsulated in an autonomous system. I'd like to do traffic >> accounting using netflow aggregated by ASN. My border routers run >> FreeBSD and BIRD. >> >> Right now, and this is mentioned in ng_netflow(4), we do not fill in >> the source and destination ASN because there is no information to get >> this from the routing daemon's RIB. Probably if we come up with such a >> way it should be generic so it could be used by Quagga, BIRD or >> OpenBGPD. >> >> I've done a little bit of thinking about how this could be done, and >> come up with two main strategies: >> >> 1. A new kind of netgraph node inserted before ng_netflow knows how >> to query the routing daemon and decorates the packet with the >> result, which ng_netflow then puts into the flow packet if >> present. This entails either a copy (tee) or putting the lookup >> in the data path which may be suboptimal. >> >> 2. A new hook added to the ng_netflow node that allows it to query >> the routing daemon through a different new kind of netgraph >> node. This is probably better but may be slightly more >> complicated to implement. >> >> Is anyone working on this or has given this though? I wasn't able to >> find much by searching the list archives. It may be that I will soon >> have some students that I can set on this task but would not like to >> unnecessarily duplicate effort. >> >> Cheers, >> -w >> >> -- >> William Waites | School of Informatics >> http://tardis.ed.ac.uk/~wwaites/ | University of Edinburgh >> http://www.hubs.net.uk/ | HUBS AS60241 >> >> The University of Edinburgh is a charitable body, registered in >> Scotland, with registration number SC005336. >> > > Hi, > > It's not ng_netflow, but if you need this today you can take a look at > http://www.pmacct.net ? (there is a package/port too). > It comes with BGP daemon (stripped down quagga) and can export this data. > > --Nikolay > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Apr 2 08:10:32 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4FE3D276 for ; Thu, 2 Apr 2015 08:10:32 +0000 (UTC) Received: from noether.irl.styx.org (noether.irl.styx.org [IPv6:2a00:d880:6:1a4::98dc]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "noether.irl.styx.org", Issuer "noether.irl.styx.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DD6BFAA3 for ; Thu, 2 Apr 2015 08:10:31 +0000 (UTC) Received: by noether.irl.styx.org (Postfix, from userid 66) id 7724F19E2A; Thu, 2 Apr 2015 08:10:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mavrino.styx.org (Postfix) with ESMTP id C40E73A07AB; Thu, 2 Apr 2015 09:05:54 +0100 (BST) Date: Thu, 02 Apr 2015 09:05:54 +0100 (BST) Message-Id: <20150402.090554.1118238546466593001.wwaites@tardis.ed.ac.uk> To: contact@winterei.se Subject: Re: ng_netflow and BGP From: William Waites In-Reply-To: <551C9651.7050003@winterei.se> References: <20150401.115048.1362042954044146751.wwaites@tardis.ed.ac.uk> <551C9651.7050003@winterei.se> X-Mailer: Mew version 6.6 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="--Security_Multipart(Thu_Apr__2_09_05_54_2015_124)--" Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 08:10:32 -0000 ----Security_Multipart(Thu_Apr__2_09_05_54_2015_124)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit On Thu, 02 Apr 2015 10:07:29 +0900, "Paul S." said: > [pmacct's] use of 'return' (with no args) on functions that are > meant to return an int flat out makes it unable to compile on > FreeBSD. Yes, I found that surprising that any modern C compiler would tolerate that at all. > If you fix those by hand, it compiles, but just seems to > segfault -- I didn't get the time to look into it further with > GDB. I also fixed this by hand but it does not segfault for me. I'll try to make a proper patch for the ports tree and submit it in the next few days. One thing that it cannot not do is simply put the required information into the flow messages and forward them on. This is a bit hard to do for Netflow V9 because in general it means mangling the templates as well as the flow messages themselves and according to the author the main use case in "tee" mode is simply splitting the flow and doing nothing else which translates to about one order of magnitude of throughput. So you can either use nfacctd to compute aggregates, or you can use it to split/copy flow data but you cannot use it to enrich the data and then do the computations after the fact with standard tools like nfdump or flow-tools. It also seems to get confused by multiple BGP sessions (IPv4 and IPv6) with the same router-id, as you have to do with BIRD because it does not support a single session with multiple address families. This causes one or the other protocol to be mis-classified depending on which session it has decided to use. I may have mis-diagnosed this problem, but definitely something of the kind appears to happen. This is all on top of consuming extra RAM for BGP tables on the collector which is just unnecessary. > As to the ng_netflow hook, +1, excellent idea. Great! -w -- William Waites | School of Informatics http://tardis.ed.ac.uk/~wwaites/ | University of Edinburgh http://www.hubs.net.uk/ | HUBS AS60241 The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ----Security_Multipart(Thu_Apr__2_09_05_54_2015_124)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQIcBAABCgAGBQJVHPhiAAoJEHhNnKzjwx5/ss0P/3Hm92jYWkHiZ/FUv1DJ8SH3 TTRg9n/SsISpEFaleUIVzZc23Cik5RjGb/PHzQ79OeACSUEpYEt4zgbrsjNHu4Bx z7VgVb2nLJA416nEMzq71BqFPzTT1dd8715az2qV+0uuE+Bw48hH0BvNZVZqUkbh UhbVVr9ROFxdhpT/pdhKcr/17T4vqAM/CRyB/LP4A8l0QpvymnpO43HyGligRn5w VHnTlwgOSLcRQjQaQECDpg8B0R1fpZcfJITxuXRZOLhBQ/1m742s22nuRgOpVplK Z0JNYAIfnIfw8KtKZLM9WHD4I3dinSJO6vjfTDVsBXfzZIIyLXPeHyMBXEsLanZA nl2Axil5/Ef90DHMyTJYmZ2Wixxu9SLc0cqCaxO6UhNhsD+FHi11lb+chX7nDFMJ H++NrVxKDJVanNvcKnxpSOSHS2hw6rf5KjCekeBRLwQhn8OWvvwAOzuyDFyA07Gb +11UiNJOyTGQtSIt6gyAimma58OTasHjIWqx579bNXvcdVz3gfhn3L8LgL/aOsvZ O7xY/GL3JroyzHfeWhiBL4ARWY//d64wYKx1/+mqnggCF1cNEcA+MABn0nPqNl1t 2H8SUtGBVzkv4+uoTnuuajNpdLdkonYRnaE6L2W8lzKOfwqhI/sG5D3MLKUjkorJ 8yFCtWVz7SDQ/FQ+oEtU =hdGL -----END PGP SIGNATURE----- ----Security_Multipart(Thu_Apr__2_09_05_54_2015_124)---- From owner-freebsd-net@FreeBSD.ORG Thu Apr 2 08:35:41 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06459559 for ; Thu, 2 Apr 2015 08:35:41 +0000 (UTC) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id BC464DE0 for ; Thu, 2 Apr 2015 08:35:40 +0000 (UTC) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id D90233C5AE2; Thu, 2 Apr 2015 19:35:30 +1100 (AEDT) Date: Thu, 2 Apr 2015 19:35:29 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: William Waites Subject: Re: ng_netflow and BGP In-Reply-To: <20150402.090554.1118238546466593001.wwaites@tardis.ed.ac.uk> Message-ID: <20150402192937.F1001@besplex.bde.org> References: <20150401.115048.1362042954044146751.wwaites@tardis.ed.ac.uk> <551C9651.7050003@winterei.se> <20150402.090554.1118238546466593001.wwaites@tardis.ed.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=A5NVYcmG c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=kCD_AYBHDVm8onu12G0A:9 a=CjuIK1q_8ugA:10 Cc: freebsd-net@freebsd.org, contact@winterei.se X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 08:35:41 -0000 On Thu, 2 Apr 2015, William Waites wrote: > On Thu, 02 Apr 2015 10:07:29 +0900, "Paul S." said: > > > [pmacct's] use of 'return' (with no args) on functions that are > > meant to return an int flat out makes it unable to compile on > > FreeBSD. > > Yes, I found that surprising that any modern C compiler would tolerate > that at all. This is interestingly different in C90 and C99. In C90, the behaviour for returning without a value in a non-void function is only explicitly undefined if the return value is used. In C99, it is a constraint error to return without a value. So C90 compilers should warn about the return but not fail to compile the file unless they can tell that the return value is used, while C99 compilers should warn about the return and fail to compile the file. Bruce From owner-freebsd-net@FreeBSD.ORG Thu Apr 2 11:01:54 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D5DAA43 for ; Thu, 2 Apr 2015 11:01:54 +0000 (UTC) Received: from kerio.tuxis.nl (alcyone.saas.tuxis.net [31.3.111.19]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7E42CF83 for ; Thu, 2 Apr 2015 11:01:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tuxis.nl; s=mail; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to; bh=bmskgIuzIhTFXKP7htiPQKUsetpDqFscS6GG7MUF+NM=; b=RYzEaqYZGtAaPI/FJlwxAwYXrImj6Pw8zzPV/s0xUWb8f0VGGoXRwoquoek6q4mXp3QcfAYMTmEBu v6KIjGjyxf/G1cMSzZZ38+0FTSk4iOAexGDD6C9h6U4K/Wmm8QZOEW4a0GVBQ7dGfwHutTQ2UfQpFx neIYNjPyUNK3/AOE4vcZF3TTgv7QO5Wt/iGO9D+YYbNyeqyRQ0SaH1Nrci6EpRsIRjpbZ+U+IpGW6H LHbcFVV/eEC00iW3HnBJDNp0Wrb51uJieg0VKc7D/IxtbTi9LOI+due/qYa1C1gJdFqHwCmQ2+1M3E R/3vVqI/qkx8kXAjQsU/a5EHIXtpTFA== X-Footer: dHV4aXMubmw= Received: from [31.3.104.222] ([31.3.104.222]) by kerio.tuxis.nl (Kerio Connect 8.5.0 beta 1) for freebsd-net@freebsd.org; Thu, 2 Apr 2015 13:01:42 +0200 Date: Thu, 2 Apr 2015 13:01:42 +0200 Subject: Re: Urgent matter: LACP trunk stops distributing X-Mailer: Kerio Connect 8.5.0 beta 1/Kerio Connect Client X-User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.76 Safari/537.36 Message-ID: <2042783266-15365@kerio.tuxis.nl> X-Priority: 3 Importance: Normal In-Reply-To: <1953214074-10699@kerio.tuxis.nl> MIME-Version: 1.0 MIME-Version: 1.0 MIME-Version: 1.0 MIME-Version: 1.0 From: Mark Schouten To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="=-lq2bHpg3wDF3v+pWDHkm" X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 11:01:54 -0000 --=-lq2bHpg3wDF3v+pWDHkm Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, So I've changed the configuration last night, eliminating the possibility t= hat the issue was LACP. All traffic was handled by the single igb interface= . It didn't help, at all. This morning the interface stopped working, without any form of messages an= d started working again after a few minutes. Then, some minutes later it st= opped again, to resume after a few minutes. So now I plugged the switch into an em-port and I tried to move the vlan in= terfaces to the em-interface. That worked, partially. The server kept the o= ld mac-address in the arp-table. Even after I deleted the vlan interface. I rebooted the box, and so far so good. But still, any help is appreciated. Met vriendelijke groeten, --=C2=A0 Kerio Operator in de Cloud? https://www.kerioindecloud.nl/ Mark Schouten | Tuxis Internet Engineering KvK:=C2=A061527076=C2=A0| http://www.tuxis.nl/ T: 0318 200208 | info@tuxis.nl Van: Mark Schouten =20 Aan: =20 Verzonden: 1-4-2015 12:07=20 Onderwerp: Urgent matter: LACP trunk stops distributing=20 Hi,=20 =20 I've got an urgent matter on my hands, my FreeBSD iScsibox has dropped it's= LACP trunk twice in the last 24 hours, which causes a whole lot of issues = on my VPS cluster, using that storage. =20 =20 It's a FreeBSD box with two igb-interfaces in an LACP trunk with jumboframe= s and vlans. If the connection drops, the only thing I see is:=20 =20 Apr=C2=A0 1 10:37:18 zstore02 kernel: igb0: Interface stopped DISTRIBUTING,= possible flapping=20 Apr=C2=A0 1 10:37:28 zstore02 kernel: igb1: Interface stopped DISTRIBUTING,= possible flapping=20 =20 The switch has nothing to say, so it doesn't seem that there are acual link= flaps. I have a feeling that it's this LACP trunk that goes haywire somewhe= re on the FreeBSD side. If anyone can help me with this, I'd be grateful. I= f someone (preferably EU-based) wants to help out professionally as a consu= ltant, that would be fine too. Or if anyone knows someone in .nl that offer= s this level of expertise on consultingbase, let me know.=20 =20 I'm running 10.1-RELEASE on the box, see the (AFAICS) relevant config below= . The switch is a Brocade ICX6430.=20 =20 [root@zstore02 ~]# ifconfig lagg0=20 lagg0: flags=3D8843 metric 0 mtu 90= 00=20 =C2=A0=C2=A0=C2=A0 options=3D4019b=20 =C2=A0=C2=A0=C2=A0 ether 0c:c4:7a:12:13:dc=20 =C2=A0=C2=A0=C2=A0 nd6 options=3D29=20 =C2=A0=C2=A0=C2=A0 media: Ethernet autoselect=20 =C2=A0=C2=A0=C2=A0 status: active=20 =C2=A0=C2=A0=C2=A0 laggproto lacp lagghash l2,l3,l4=20 =C2=A0=C2=A0=C2=A0 laggport: em1 flags=3D0<>=20 =C2=A0=C2=A0=C2=A0 laggport: em0 flags=3D0<>=20 =C2=A0=C2=A0=C2=A0 laggport: igb1 flags=3D1c=20 =C2=A0=C2=A0=C2=A0 laggport: igb0 flags=3D1c=20 =20 [root@zstore02 ~]# sysctl -a | grep lacp=20 net.link.lagg.lacp.debug: 0=20 net.link.lagg.0.lacp.lacp_strict_mode: 1=20 net.link.lagg.0.lacp.debug.rx_test: 0=20 net.link.lagg.0.lacp.debug.tx_test: 0=20 =20 =20 =20 Met vriendelijke groeten,=20 =20 --=C2=A0=20 Kerio Operator in de Cloud? https://www.kerioindecloud.nl/=20 Mark Schouten =C2=A0| Tuxis Internet Engineering=20 KvK:=C2=A061527076=C2=A0| http://www.tuxis.nl/=20 T: 0318 200208 | info@tuxis.nl = --=-lq2bHpg3wDF3v+pWDHkm Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: Electronic Signature S/MIME Content-Transfer-Encoding: base64 MIIRwQYJKoZIhvcNAQcCoIIRsjCCEa4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCDt4w ggUbMIIEA6ADAgECAhAsv+VdGX6YsSHI/WRu2j2JMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE0MDcwMTAwMDAwMFoXDTE1MDcwMTIzNTk1OVow HjEcMBoGCSqGSIb3DQEJARYNbWFya0B0dXhpcy5ubDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBANHu3SxlMZOG5GA0/mqtRXR1QmWwhUXzmCIprI0IPtSBWSA31YBJ5qcmXRhLzaiTB3Fr UpIGkW5aAZnDms9DD64kasF3oZE00Fvfnj/BDGbw098px1PukKfg4hasbTaELAjQTSUj8xRSHzKk VVynvLA/YmyRT/+u3ueK4wdaxcej241xH6mNfZeiKMAvbkv6Tm9vdup0BtqqbRSKcnc01KKrspun Eh73jLIUhP21uJv8vuOTxS1I9zJSlhIcMCEapjBQ+26cQl+s+qBuAs/LP3UPVytSbxvicdhDxtqH npN2h3jJ/+J86zGfQi8bG7EamsULTGHkbgIJL9AdKZRgAKECAwEAAaOCAd0wggHZMB8GA1UdIwQY MBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBR+dMZE22X/SMCyTxYzIP+NMZBNXTAO BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGy MQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiG Rmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2Vj dXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5j b21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBgGA1UdEQQRMA+BDW1hcmtA dHV4aXMubmwwDQYJKoZIhvcNAQEFBQADggEBAIB8FhqaML1EzfvgNwwHDC3k0ICeMerOncgee6uJ KLxwU2mstttX5jtAmgK9RuDOu+TrMkkpF2yxYMTPpSM8nL7r+N/kdogu5Bustol8WTsW1e5vs+Nh hJYFORk113ouur1kSjXuHF8TWy+/PjFJBS/xm/H+/fkghppRU+4Dj2IReUBvlexAPYr4VDxjV7AD xPOXqTQkP15LWGvhTz2YVbJ3IAVOyUNkRhr9QwzToUxXa9k/QAOpXMuvS74AT2RBV/YCEEx7ebRD MAR6lZcbYiV8sXv1ASbnMdO3Fh2F98g+5rJn5PfFH8qLpapsZx0I2/axtSG09QMDJqXd3Ab6NpEw ggUaMIIEAqADAgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQG EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVh dGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hf ZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrh o/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0 mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MP bXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRc WzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAd BgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQI MAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwu dXNlcnRydXN0LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwu Y3JsMHQGCCsGAQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29t L1VUTkFkZFRydXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRy dXN0LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ 9RtaxdKtG3NuPukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1 ei+eupN5yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B 080zX5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCC BJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMC U0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAg TmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5 MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcT DlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsT GGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQg QXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA sjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p 1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K 2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bU MSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjK aJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0 tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8E BAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDeg NYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUG CCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlf sXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5lDd1 ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJxggzpiDbj 2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTGCAqswggKnAgEBMIGo MIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAsv+VdGX6YsSHI/WRu2j2JMAkG BSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUw NDAyMTEwMTQyWjAjBgkqhkiG9w0BCQQxFgQUBzMjEFFutXYkJ4baYIyiV2MNDBwweQYJKoZIhvcN AQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw DQYJKoZIhvcNAQEBBQAEggEASXS6OF4pnKqNvKEx9qZ6Z4er059azmik5Hv68oYbbD8Q+QGjY/Mp HubV4hHXIfElA1F2REuGbkZ0S0ZWtvGn/sBWiFuZakokaCKGFfs9nDAoUB1WEFUj3vVKr0przRBj emeyOWZczeeUOhKLdMIGg64RrZQ+CKOtm8byCn2TAPbYJJU8BpfKh9CkpXJy+Xtes+ZCF+znuops 7bGmPmpShoh7QPKhenFLqBbeToF8zzJkZbPF5LiQAjxAbxlP9pBmuIUCp0y4X7xtQ7OqkBhWb0Bk sK3g70hYUakcZDOOAszH46MYZM7KZ+zr0HlncRsaPJMoR8RZFDrhSBGkzWrZrg== --=-lq2bHpg3wDF3v+pWDHkm-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 2 15:52:22 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2176EF94 for ; Thu, 2 Apr 2015 15:52:22 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D397796D for ; Thu, 2 Apr 2015 15:52:21 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (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 D76401FE022; Thu, 2 Apr 2015 17:52:18 +0200 (CEST) Message-ID: <551D65DE.4090808@selasky.org> Date: Thu, 02 Apr 2015 17:53:02 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Karim Fodil-Lemelin , freebsd-net@freebsd.org Subject: Re: Another fragment question / patch References: <550C3A62.3080403@gmail.com> <550C5F6C.3080302@selasky.org> <550C7D0C.3090603@gmail.com> <550D3675.5030900@selasky.org> <551017D1.60008@gmail.com> In-Reply-To: <551017D1.60008@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 15:52:22 -0000 On 03/23/15 14:40, Karim Fodil-Lemelin wrote: > Hi, > > Your patch seems to work as well as mine, albeit completely swinging the > other way now since your copying a lot more from the packet header with > the call to m_dup_pkthdr() (including the M_COPYFLAGS, vlan tags, etc..). > > I think this is fine, one would expect IP fragments to be somewhat very > close to the original packet. > FYI: https://svnweb.freebsd.org/changeset/base/280991 --HPS From owner-freebsd-net@FreeBSD.ORG Thu Apr 2 20:53:08 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D83E9CA7 for ; Thu, 2 Apr 2015 20:53:08 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (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 C404E295 for ; Thu, 2 Apr 2015 20:53:08 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id 5FDBD10BAF8 for ; Thu, 2 Apr 2015 13:53:07 -0700 (PDT) Date: Thu, 2 Apr 2015 13:53:07 -0700 From: hiren panchasara To: freebsd-net@freebsd.org Subject: Bring "netstat -R" to stable10 Message-ID: <20150402205307.GA72165@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 20:53:08 -0000 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I want to use netstat -R on stable10 and following 2 commits are needed to be MFC'd for that: https://svnweb.freebsd.org/base?view=3Drevision&revision=3D266418 https://svnweb.freebsd.org/base?view=3Drevision&revision=3D266448 r266418 adds a field to 'struct inpcb' but it uses a spare field so I _think_ it's MFCable and doesn't break KBI/KPI?=20 Can someone please comment if that's not the case? Cheers, Hiren --4Ckj6UjgE2iN1+kY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVHawyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lGg8H/RAnNgeu/y4h9rlBjOF8ZQ5I scrWul/e/nrjLLo60UeanuwR5kozlHBmxlJ6j6JcK13QWOq9HqOAeXccGYvOjGT3 EfiQxcpi0SHaLsgoUCjuy3V8+drYDbjQehxImGt633lI0x1CYQoNwLngeV+moOgS ALwfIvXq2YhiXm+i7QV2bZyKzzUWauRi9Z1XpMogS837IrtZaRAJ4MoH3FllVXgJ arJE7oj8lkwl0sQJ1sIj2M8UG79ciT9WdOkAF11GqI5NxxtD8eydv5gIkbn4TgdH GrXWsWh5AGfmF74EyJftePO3qgUIO3tww51Koi5oYXlkSUfv6Gs7szpEPX2r4Us= =lFWL -----END PGP SIGNATURE----- --4Ckj6UjgE2iN1+kY-- From owner-freebsd-net@FreeBSD.ORG Fri Apr 3 01:44:56 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8BE85CB for ; Fri, 3 Apr 2015 01:44:56 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CF560A0E for ; Fri, 3 Apr 2015 01:44:56 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t331iuYN001840 for ; Fri, 3 Apr 2015 01:44:56 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 199096] Kernel panic after some time using mpd (netgraph) and ipfw Date: Fri, 03 Apr 2015 01:44:57 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@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: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 01:44:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199096 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Apr 3 01:58:00 2015 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2C4B4FF4; Fri, 3 Apr 2015 01:58:00 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0111.outbound.protection.outlook.com [157.56.111.111]) (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 8B6E8C09; Fri, 3 Apr 2015 01:57:59 +0000 (UTC) Received: from BLUPR0501MB1060.namprd05.prod.outlook.com (25.160.36.150) by BLUPR0501MB1057.namprd05.prod.outlook.com (25.160.36.148) with Microsoft SMTP Server (TLS) id 15.1.130.23; Fri, 3 Apr 2015 01:42:49 +0000 Received: from BLUPR0501MB1060.namprd05.prod.outlook.com ([25.160.36.150]) by BLUPR0501MB1060.namprd05.prod.outlook.com ([25.160.36.150]) with mapi id 15.01.0125.002; Fri, 3 Apr 2015 01:42:49 +0000 From: Anuranjan Shukla To: Gleb Smirnoff , "net@FreeBSD.org" , "arch@FreeBSD.org" Subject: Re: opaque ifnet progress Thread-Topic: opaque ifnet progress Thread-Index: AQHQYltzPIeBpH4YSUKvLiCk4V0dnp06JOeA Date: Fri, 3 Apr 2015 01:42:49 +0000 Message-ID: References: <20150319154309.GT64665@FreeBSD.org> In-Reply-To: <20150319154309.GT64665@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.14] authentication-results: FreeBSD.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB1057; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(479174004)(51704005)(52604005)(377454003)(24454002)(450100001)(1720100001)(77156002)(62966003)(102836002)(83506001)(15975445007)(46102003)(2900100001)(87936001)(36756003)(76176999)(86362001)(2201001)(2501003)(99286002)(92566002)(54356999)(19273905006)(107886001)(122556002)(19580395003)(19580405001)(66066001)(106116001)(40100003)(2950100001)(2656002)(50986999)(563064011); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1057; H:BLUPR0501MB1060.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BLUPR0501MB1057; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1057; x-forefront-prvs: 05352A48BE Content-Type: text/plain; charset="us-ascii" Content-ID: <892277E2AEDD87409D4C8BF836EBCF48@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2015 01:42:49.2005 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1057 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 01:58:00 -0000 Hello Gleb, Thanks for sharing the details. >From looking at the wiki page it's not exactly clear what your plan is regarding the accessor functions as they stand today (if_get*/if_set* after drvapi change was made). I briefly glanced through some of the code changes but that takes time so it'd be good to know sort of the overall plan in that area if you foresee major rework. Thanks Anu On 3/19/15, 8:43 AM, "Gleb Smirnoff" wrote: > Hi! > > It is already several years as the "opaque ifnet" has been discussed, >and almost a year since it was announced to be worked on. > >For now I've got a branch in svn, where some proof of concept is done: > > http://svn.freebsd.org/base/projects/ifnet > >I've described what's going on in wiki: > >https://wiki.freebsd.org/projects/ifnet > > If you are writing/maintaining a NIC driver, you must look there >and share your opinion with me. You should also look at already >converted drivers and again share your opinion. > At current stage I need feeling of approvement and agreement >from people who write drivers, since being on my own I don't >feel confident that I am doing things right. So, please look >at wiki and code! > >P.S. Of course job of converting all drivers to new KPI is extremely >heavy lifting, so any help with the project if very much appreciated. > >--=20 >Totus tuus, Glebius. >_______________________________________________ >freebsd-arch@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-arch >To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Apr 3 02:16:18 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7FFCF3BA for ; Fri, 3 Apr 2015 02:16:18 +0000 (UTC) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 19D82DFA for ; Fri, 3 Apr 2015 02:16:18 +0000 (UTC) Received: by wgra20 with SMTP id a20so100579806wgr.3 for ; Thu, 02 Apr 2015 19:16:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=Ydnta1NlMfzRvfHVKUMTtf9FI1GO//1K0BNBvQlQ/7o=; b=kX0rpvkSX/Ah8gfvFwAHCmt5PZWZT8gMdTeAjZEY1EqcJ9Mh6huOBxyhGgAuTw2n/r 5zZQpcdzgPMCOgAh7li0F5P+LUP/vHZBRwrEPuOKISqd5K3z1E43n5WPtwPCXVyXZnbn bNo8t10i728I5ftTpVhYCbaKRM1N9iDkvL5QE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=Ydnta1NlMfzRvfHVKUMTtf9FI1GO//1K0BNBvQlQ/7o=; b=PlhrjvXyYoVJ2R/BMQvWsp8Uwt1hS6WPNcm+lzqO+oY7HlLvkkedNaIw+9r0mtwBUr 20EL2dG8BoTSc1ehd+5zqG2CkSupzqN3AzaE470VNe+psZZGRHegR1MkzACzJSCni1le le2ZKD32x1ldF+fYGZm4zBpTSnOy7vXZviI5uPF/RvJXlkE07VK1sFuGXZ0UD5X98oId 0x48xLfvKZak/2Afd2wBeDzlp1DprZog7fFBzWXw7vGgT/HV/bDm4COYMuvb9RllBIIt v5EHhgf80kAumcJqwM6C+2Q+ha1wwA0/RzzpWYjVH4Mi/4UfX2wJ5ejOu8QiRWeQ2k3X jM7Q== X-Gm-Message-State: ALoCoQnrsz3BhR0WMlMvHNYE3G1Z2YGFGj3NvJkl8SNTBAjDcX+78Uxl6PmCzMR7tJetuzMQe6i0 X-Received: by 10.180.216.38 with SMTP id on6mr1235751wic.15.1428027375726; Thu, 02 Apr 2015 19:16:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.211.135 with HTTP; Thu, 2 Apr 2015 19:15:45 -0700 (PDT) In-Reply-To: References: From: Eitan Adler Date: Thu, 2 Apr 2015 19:15:45 -0700 Message-ID: Subject: Fwd: [oss-security] CVE Request : IPv6 Hop limit lowering via RA messages To: FreeBSD Security Team , "freebsd-net@freebsd.org" , ljungmark@modio.se, oss-security@lists.openwall.com Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 02:16:18 -0000 + FreeBSD lists since I haven't seen any relevant patches (although I might have missed them). ---------- Forwarded message ---------- From: D.S. Ljungmark Date: 2 April 2015 at 10:19 Subject: [oss-security] CVE Request : IPv6 Hop limit lowering via RA messages To: oss-security@lists.openwall.com An unprivileged user on a local network can use IPv6 Neighbour Discovery ICMP to broadcast a non-route with a low hop limit, this causing machines to lower the hop limit on existing IPv6 routes. Linux Patch: http://www.spinics.net/lists/netdev/msg322361.html Redhat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1203712 Projects impacted: Linux kernel, NetworkManager, FreeBSD Kernel Regards, D.S. Ljungmark -- Eitan Adler From owner-freebsd-net@FreeBSD.ORG Fri Apr 3 04:06:50 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4A66D9A9 for ; Fri, 3 Apr 2015 04:06:50 +0000 (UTC) Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) (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 0C721BAD for ; Fri, 3 Apr 2015 04:06:49 +0000 (UTC) Received: by obbgh1 with SMTP id gh1so150250109obb.1 for ; Thu, 02 Apr 2015 21:06:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=uY1f20CmaJ09ww0i6t0ERKKYocXtICkeKBgu6O0R6Ww=; b=dcwGIlRtQhrlGiArt/IwWd0cwkwdvGPpGW+iwqmJvdqIPU9qMe0HTnTqasOmGwInmO NTF8J7KGsT8+GuvOYNAxjTWDg+9R/oVzPjZ0/QeFWneZ3UNTXKPQignQH8spF+wtjuGn qbHXoArfRmH6IxrsyAaT1G4kSA8ioqIgHVSiWIumWwU5/RMNKxmJ2mehm3e6SpVt+SLX B7I+yhjUQVJYXHZ4OBgZo8AcJG5Ml6VgRLtPoJC7671oGHMSnnrtoDReoKiJzrsK7lPo OFkJTtPsTtUyMF/eKoN2fpaYRWjV9BVnZXuhtTxyaXlmqwWZM7/C9+J7u4LhSMx1uRIL 8Zhw== X-Gm-Message-State: ALoCoQk+kooyi2M6vQTtfxvJVFjAHlX5r6NRikP1m8IeCZC/BGOmNdqi0lfZBASJ5axLZbLFdboz X-Received: by 10.182.19.132 with SMTP id f4mr737527obe.8.1428034003659; Thu, 02 Apr 2015 21:06:43 -0700 (PDT) Received: from jims-mbp.netgate.com (65-36-83-120.static.grandenetworks.net. [65.36.83.120]) by mx.google.com with ESMTPSA id jt2sm6090032oeb.13.2015.04.02.21.06.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Apr 2015 21:06:43 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2096\)) Subject: Re: [oss-security] CVE Request : IPv6 Hop limit lowering via RA messages From: Jim Thompson In-Reply-To: Date: Thu, 2 Apr 2015 23:06:43 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <942E0C08-E883-429E-9F27-22715C00B684@netgate.com> References: To: Eitan Adler X-Mailer: Apple Mail (2.2096) Cc: oss-security@lists.openwall.com, ljungmark@modio.se, FreeBSD Security Team , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 04:06:50 -0000 have you considered that there might not be a relevant patch because = FreeBSD=E2=80=99s implementation isn=E2=80=99t affected? Jim > On Apr 2, 2015, at 9:15 PM, Eitan Adler wrote: >=20 > + FreeBSD lists since I haven't seen any relevant patches (although I > might have missed them). >=20 > ---------- Forwarded message ---------- > From: D.S. Ljungmark > Date: 2 April 2015 at 10:19 > Subject: [oss-security] CVE Request : IPv6 Hop limit lowering via RA = messages > To: oss-security@lists.openwall.com >=20 >=20 > An unprivileged user on a local network can use IPv6 Neighbour > Discovery ICMP to broadcast a non-route with a low hop limit, this > causing machines to lower the hop limit on existing IPv6 routes. >=20 > Linux Patch: http://www.spinics.net/lists/netdev/msg322361.html > Redhat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=3D1203712 >=20 > Projects impacted: Linux kernel, NetworkManager, FreeBSD Kernel >=20 >=20 > Regards, > D.S. Ljungmark >=20 >=20 > --=20 > Eitan Adler > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Apr 3 07:11:34 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E501CD0E for ; Fri, 3 Apr 2015 07:11:34 +0000 (UTC) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id B2DCECF5 for ; Fri, 3 Apr 2015 07:11:34 +0000 (UTC) Received: from yuri.doctorlan.com (c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128]) (authenticated bits=0) by shell1.rawbw.com (8.14.9/8.14.9) with ESMTP id t337BRRd076634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 3 Apr 2015 00:11:27 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128] claimed to be yuri.doctorlan.com Message-ID: <551E3D1E.3070501@rawbw.com> Date: Fri, 03 Apr 2015 00:11:26 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: net@freebsd.org Subject: Re: tap(4): will it be more reasonable if it preserved UP/DOWN state, when closed? References: <551B3021.4050206@rawbw.com> <551BC4D5.9010006@quip.cz> <551C780F.4050202@rawbw.com> In-Reply-To: <551C780F.4050202@rawbw.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Miroslav Lachman <000.fbsd@quip.cz> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 07:11:35 -0000 On 04/01/2015 15:58, Yuri wrote: > > I am going to create the corresponding net.link.tap.down_on_close. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199136 From owner-freebsd-net@FreeBSD.ORG Fri Apr 3 09:54:02 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B0C462C9 for ; Fri, 3 Apr 2015 09:54:02 +0000 (UTC) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) (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 749B5F1A for ; Fri, 3 Apr 2015 09:54:01 +0000 (UTC) Received: by obvd1 with SMTP id d1so166017824obv.0 for ; Fri, 03 Apr 2015 02:54:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KTF0xwZrEgIVvNeHlB9fXgiEmVevYWiW//A3lq9kU2U=; b=loTzwGOtZ0q9aUxva9xDKhK/npuEetWxnTG4lczElaFDC3fLU3AsCVmVa8UPTmWM6v whi8DqHiJGL/xnY3m0N285zhYH4jlCMPmXCPHxZnTpIiCcPJ38pfcKLI2FE2Bk3IHQMA PE4/KuCS+rAFDkL+E8RH1oLK1pkYJeS+M9qyKJ8xD86vUGsIy0220buHCAk+0WYKXBo4 pv/tksM2UKxrLwgoZyMjypbc0ZKfNYrwTeoVgJh+b/bMvx6OoqouIF/N6PIqgahYVY4n JVRwkdd921fKmhSei0nihN59Hx3N1WYWuLRb8DlzCEAQnJEjAn6zw7lGkKyJ3gD3P24A +2SQ== X-Gm-Message-State: ALoCoQnIn53dPu3sLQL/VDCjiXVfrNg596/GXYgdluWqLMRXNk6J6oA5tb30mxvDRJVMM89tbBUm MIME-Version: 1.0 X-Received: by 10.182.125.130 with SMTP id mq2mr2036134obb.52.1428054841071; Fri, 03 Apr 2015 02:54:01 -0700 (PDT) Received: by 10.76.151.104 with HTTP; Fri, 3 Apr 2015 02:54:01 -0700 (PDT) In-Reply-To: <942E0C08-E883-429E-9F27-22715C00B684@netgate.com> References: <942E0C08-E883-429E-9F27-22715C00B684@netgate.com> Date: Fri, 3 Apr 2015 11:54:01 +0200 Message-ID: Subject: Re: [oss-security] CVE Request : IPv6 Hop limit lowering via RA messages From: "D.S. Ljungmark" To: Jim Thompson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Eitan Adler , oss-security@lists.openwall.com, FreeBSD Security Team , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 09:54:02 -0000 On Fri, Apr 3, 2015 at 6:06 AM, Jim Thompson wrote: > have you considered that there might not be a relevant patch because Free= BSD=E2=80=99s implementation isn=E2=80=99t affected? sys/netinet6/nd6_rtr.c 300 if (nd_ra->nd_ra_curhoplimit) 301 ndi->chlim =3D nd_ra->nd_ra_curhoplimit; The only "OUT" in that function I see are tests for: Not accepting RA hoplimit on current packet !=3D 255 not link-local No extended ipv6 header Based on previous testing ( early March 2015), and reading of the source, I say that FreeBSD is vulnerable. Regards, D.S. Ljungmark > > Jim > >> On Apr 2, 2015, at 9:15 PM, Eitan Adler wrote: >> >> + FreeBSD lists since I haven't seen any relevant patches (although I >> might have missed them). >> >> ---------- Forwarded message ---------- >> From: D.S. Ljungmark >> Date: 2 April 2015 at 10:19 >> Subject: [oss-security] CVE Request : IPv6 Hop limit lowering via RA mes= sages >> To: oss-security@lists.openwall.com >> >> >> An unprivileged user on a local network can use IPv6 Neighbour >> Discovery ICMP to broadcast a non-route with a low hop limit, this >> causing machines to lower the hop limit on existing IPv6 routes. >> >> Linux Patch: http://www.spinics.net/lists/netdev/msg322361.html >> Redhat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=3D1203712 >> >> Projects impacted: Linux kernel, NetworkManager, FreeBSD Kernel >> >> >> Regards, >> D.S. Ljungmark >> >> >> -- >> Eitan Adler >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Apr 3 09:57:03 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D39933DF; Fri, 3 Apr 2015 09:57:03 +0000 (UTC) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A58BCF4C; Fri, 3 Apr 2015 09:57:03 +0000 (UTC) Received: by igbqf9 with SMTP id qf9so92252689igb.1; Fri, 03 Apr 2015 02:57:03 -0700 (PDT) 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:content-transfer-encoding; bh=Mm0593gYOMoF6mhevP+2akcfvk/u93/DEKaVqtzSbUg=; b=mUKXzsSMWgnCtaKfZYasR0itWw10MzLfT5O+XwU9kOnFAZ796AtkN1ytvBKUAp24TA zoIPBQJ8a2yQc8YQrUeMQkP9vjkNlGpEyG7RSACl8I7uomk8+BW2G7sAPYvbu3o6UAwJ emlZqDJUqPkFUaxceFBMWaC2kMtXrvQL7mMFS/3mZUejz0Nbuu/Pj/lza35pnoAwUFas Ud8QJdNs28bYxEOAQL9k7/jt8cM/RF3UEFPZg9lwPaqBstdpvs+wanhqajMP2yISeLTG Uta3A+Q+0DQrPOZAB8zVXPDiT1Wm9H2vNLfU78l2Vrq8NbZ1TSwQna7KN5bp1/l42+6r VHGw== MIME-Version: 1.0 X-Received: by 10.43.14.199 with SMTP id pr7mr2839801icb.3.1428055023008; Fri, 03 Apr 2015 02:57:03 -0700 (PDT) Received: by 10.50.25.231 with HTTP; Fri, 3 Apr 2015 02:57:02 -0700 (PDT) In-Reply-To: References: <942E0C08-E883-429E-9F27-22715C00B684@netgate.com> Date: Fri, 3 Apr 2015 13:57:02 +0400 Message-ID: Subject: Re: [oss-security] CVE Request : IPv6 Hop limit lowering via RA messages From: Loganaden Velvindron To: oss-security@lists.openwall.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Eitan Adler , Jim Thompson , FreeBSD Security Team , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 09:57:04 -0000 On Fri, Apr 3, 2015 at 1:54 PM, D.S. Ljungmark wrote: > On Fri, Apr 3, 2015 at 6:06 AM, Jim Thompson wrote: >> have you considered that there might not be a relevant patch because Fre= eBSD=E2=80=99s implementation isn=E2=80=99t affected? > > sys/netinet6/nd6_rtr.c > > 300 if (nd_ra->nd_ra_curhoplimit) > 301 ndi->chlim =3D nd_ra->nd_ra_curhoplimit; > > The only "OUT" in that function I see are tests for: > Not accepting RA > hoplimit on current packet !=3D 255 > not link-local > No extended ipv6 header It is vulnerable. Harrison Grundy and I worked on a patch, and sent it to secteam@. > > > Based on previous testing ( early March 2015), and reading of the > source, I say that FreeBSD is vulnerable. > > > Regards, > D.S. Ljungmark > > >> >> Jim >> >>> On Apr 2, 2015, at 9:15 PM, Eitan Adler wrote: >>> >>> + FreeBSD lists since I haven't seen any relevant patches (although I >>> might have missed them). >>> >>> ---------- Forwarded message ---------- >>> From: D.S. Ljungmark >>> Date: 2 April 2015 at 10:19 >>> Subject: [oss-security] CVE Request : IPv6 Hop limit lowering via RA me= ssages >>> To: oss-security@lists.openwall.com >>> >>> >>> An unprivileged user on a local network can use IPv6 Neighbour >>> Discovery ICMP to broadcast a non-route with a low hop limit, this >>> causing machines to lower the hop limit on existing IPv6 routes. >>> >>> Linux Patch: http://www.spinics.net/lists/netdev/msg322361.html >>> Redhat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=3D1203712 >>> >>> Projects impacted: Linux kernel, NetworkManager, FreeBSD Kernel >>> >>> >>> Regards, >>> D.S. Ljungmark >>> >>> >>> -- >>> Eitan Adler >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> --=20 This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present. From owner-freebsd-net@FreeBSD.ORG Fri Apr 3 11:03:50 2015 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 20A8B517; Fri, 3 Apr 2015 11:03:50 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9C8A78EC; Fri, 3 Apr 2015 11:03:48 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id t33B3jCu072377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 3 Apr 2015 14:03:45 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id t33B3jHa072376; Fri, 3 Apr 2015 14:03:45 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 3 Apr 2015 14:03:45 +0300 From: Gleb Smirnoff To: Anuranjan Shukla Subject: Re: opaque ifnet progress Message-ID: <20150403110345.GM64665@glebius.int.ru> References: <20150319154309.GT64665@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "arch@FreeBSD.org" , "net@FreeBSD.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 11:03:50 -0000 Anuranjan, On Fri, Apr 03, 2015 at 01:42:49AM +0000, Anuranjan Shukla wrote: A> Hello Gleb, A> Thanks for sharing the details. A> From looking at the wiki page it's not exactly clear what your plan is A> regarding the accessor functions as they stand today (if_get*/if_set* A> after drvapi change was made). I briefly glanced through some of the code A> changes but that takes time so it'd be good to know sort of the overall A> plan in that area if you foresee major rework. The plan is that they go away. They were a quick solution, that allow to avoid recompilation of a driver when struct ifnet change, but they still dictate the layout of the structure and don't give enough flexibility for the stacj to change in future. Also, new world order dictates that all change to flags/capenable/etc go directly through if_ioctl, so that we have one place to catch all events. Field accessor functions violate this rule. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri Apr 3 14:38:25 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41119289 for ; Fri, 3 Apr 2015 14:38:25 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A6444142 for ; Fri, 3 Apr 2015 14:38:24 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id t33EcMt4073473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 3 Apr 2015 17:38:22 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id t33EcLjt073472; Fri, 3 Apr 2015 17:38:21 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 3 Apr 2015 17:38:21 +0300 From: Gleb Smirnoff To: William Waites Subject: Re: ng_netgraph and BGP Message-ID: <20150403143821.GY64665@FreeBSD.org> References: <20150401.115048.1362042954044146751.wwaites@tardis.ed.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150401.115048.1362042954044146751.wwaites@tardis.ed.ac.uk> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 14:38:25 -0000 On Wed, Apr 01, 2015 at 11:50:48AM +0100, William Waites wrote: W> I run a small network composed of even smaller networks each W> encapsulated in an autonomous system. I'd like to do traffic W> accounting using netflow aggregated by ASN. My border routers run W> FreeBSD and BIRD. W> W> Right now, and this is mentioned in ng_netflow(4), we do not fill in W> the source and destination ASN because there is no information to get W> this from the routing daemon's RIB. Probably if we come up with such a W> way it should be generic so it could be used by Quagga, BIRD or W> OpenBGPD. W> W> I've done a little bit of thinking about how this could be done, and W> come up with two main strategies: W> W> 1. A new kind of netgraph node inserted before ng_netflow knows how W> to query the routing daemon and decorates the packet with the W> result, which ng_netflow then puts into the flow packet if W> present. This entails either a copy (tee) or putting the lookup W> in the data path which may be suboptimal. W> W> 2. A new hook added to the ng_netflow node that allows it to query W> the routing daemon through a different new kind of netgraph W> node. This is probably better but may be slightly more W> complicated to implement. W> W> Is anyone working on this or has given this though? I wasn't able to W> find much by searching the list archives. It may be that I will soon W> have some students that I can set on this task but would not like to W> unnecessarily duplicate effort. The issue is open since I've written the ng_netflow node. You would agree that keeping the ASN information in kernel, just for the sake of exporting it out, is rather strange. Anyway, in 2004 I've written a patch to ng_netflow, rtsock and quagga to do that. But it didn't went into FreeBSD for the above reasons. Also, it required changing the rtsock API. You may try to search for the patch in internet archives. But the proper solution, I think, is to do prefix -> ASN matching at the collector. Or, if you cannot modify the collector, you can create a proxy collector that is feeded data from ng_netflow and resends it to collector with ASN filled in. You can put the proxy on the machine that runs either ng_netflow, or the collector. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri Apr 3 14:40:08 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E3229453 for ; Fri, 3 Apr 2015 14:40:08 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6BF1D15B for ; Fri, 3 Apr 2015 14:40:08 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id t33Ee6FG073493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 3 Apr 2015 17:40:06 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id t33Ee6tL073492; Fri, 3 Apr 2015 17:40:06 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 3 Apr 2015 17:40:06 +0300 From: Gleb Smirnoff To: Juan Mojica Subject: Re: Programmatically Creating VLAN in the Kernel Message-ID: <20150403144006.GZ64665@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 14:40:09 -0000 On Mon, Mar 30, 2015 at 09:49:56AM -0400, Juan Mojica wrote: J> I'm trying to programmatically create a VLAN in the kernel via ifioctl, but J> I'm hitting a "copyin" in the ioctl path, and since the address I'm passing J> in is a kernel address and not a user space address, the copyin is failing. J> J> Calling the ioctl from user space is a non-starter at this point, and I J> believe there will be other ioctls that will have to be called from the J> kernel which will hit the same issue. J> J> Any suggestions? J> J> So far I've thought about marking the ifreq flags to indicate the request J> came from the kernel and essentially bypass the copyin. Another option J> would be to make the create functions globally available, but this would J> violate the modularity of the VLAN module. If you really want to do that you need to export the vlan_cloner and its methods, then call vlan_clone_create directly. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri Apr 3 16:54:19 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 295D9CF0; Fri, 3 Apr 2015 16:54:19 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (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 0AB3C305; Fri, 3 Apr 2015 16:54:18 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id D727810B023; Fri, 3 Apr 2015 09:54:11 -0700 (PDT) Date: Fri, 3 Apr 2015 09:54:11 -0700 From: hiren panchasara To: Adrian Chadd Subject: Re: Full 32bit flowid from igb(4) Message-ID: <20150403165411.GC72165@strugglingcoder.info> References: <20150323234214.GU53237@strugglingcoder.info> <20150324154931.GC53237@strugglingcoder.info> <20150330225945.GI10892@strugglingcoder.info> <20150331050628.GJ10892@strugglingcoder.info> <20150331170933.GK10892@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Fig2xvG2VGoz8o/s" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Jack F Vogel , FreeBSD Net , erj@freebsd.org, Jack Vogel , Jason Wolfe X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 16:54:19 -0000 --Fig2xvG2VGoz8o/s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On 03/31/15 at 11:15P, Adrian Chadd wrote: > Yeah, I think the right thing to do is: > > * If the descriptor says it's RSS, then use the flowid + rss type So, if we have multiqueue, we do everything needed to get RSS flowid/type. That means, with num_queues > 1 we can just expose those. > * else, set it to queue id and set the type to opaque. This part becomes irrelevant as it's a single queue case. Do we care about setting flowid value/type in case of single queue? cheers, Hiren --Fig2xvG2VGoz8o/s Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVHsWzXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lRpEH/R8DJSQN8QTLv0TTNAO3M2AH ZtOD23V/DPBJf7xvam/Z4UNXqga2Z2JsaD1R/iKqs7EpRWaPMsGd4l3VH6FEmnua fUgFZwR9aKa9lygAvZ5JHxmBHeD1P62pU0wt3UKrGC/JpBCxWVWNapNEFz3T6plk x/FeMewMfw7d3/0VWGtr8FjJXGFCdU4e9wKDZ2Al64kegWRsPT7gwjBF41Qr9b0C 1f1AU6w/1ek1Fp6SfXAuIO5Onje5mxPP5QdpnvwkKhUzapyOCPfT4p9Tx3A8WVYH sWGDCqoZ+SfE/JRW3G2nlMSDarT26b4BC7CaJslHAq2eiyWKc/KN1xqUr820UdQ= =LPTL -----END PGP SIGNATURE----- --Fig2xvG2VGoz8o/s-- From owner-freebsd-net@FreeBSD.ORG Fri Apr 3 17:00:03 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6247E6E; Fri, 3 Apr 2015 17:00:03 +0000 (UTC) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 836B4346; Fri, 3 Apr 2015 17:00:03 +0000 (UTC) Received: by ierf6 with SMTP id f6so94493641ier.2; Fri, 03 Apr 2015 10:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=BCgh2lxAX+83UOtEg0mIJygnRu0ZqHHcoauBI97XUcA=; b=CVPTF7mnq6kUaZK3PFrsXLvXy4mlqTvQKnHJy5/RLlCN8UYCsVop3SQDTv0CFwFRIw JaVRbKzyW2bHmrvoThnhz892SI9NqGqLiAYrBDojwhCUaMG16V9L6V6620XVu2tB2loc kHz8vivHzB8mB5euIqao9UX/mz6nXOT68FKS6v5684mvHWdbDUvY/j9Em8zInS+Q6Kf9 FJzh28x7Q0Wdetpgyv0q+WyaD1GwlFOxYUIboXUSAb7Ve0stB7/hOCE6Jhy55+KqXbY0 aad1uJ0Vkhph/BhQSKNHEpF/2D0oVcQOfBWIqE5Xe8witemKyNqeUYB6sGRI4bGwUhFY pdXQ== MIME-Version: 1.0 X-Received: by 10.50.132.66 with SMTP id os2mr29294372igb.6.1428080402487; Fri, 03 Apr 2015 10:00:02 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Fri, 3 Apr 2015 10:00:02 -0700 (PDT) In-Reply-To: <20150403165411.GC72165@strugglingcoder.info> References: <20150323234214.GU53237@strugglingcoder.info> <20150324154931.GC53237@strugglingcoder.info> <20150330225945.GI10892@strugglingcoder.info> <20150331050628.GJ10892@strugglingcoder.info> <20150331170933.GK10892@strugglingcoder.info> <20150403165411.GC72165@strugglingcoder.info> Date: Fri, 3 Apr 2015 10:00:02 -0700 X-Google-Sender-Auth: kGpZU6IwHXhSWreXesOVVATT6cI Message-ID: Subject: Re: Full 32bit flowid from igb(4) From: Adrian Chadd To: hiren panchasara Content-Type: text/plain; charset=UTF-8 Cc: Jack F Vogel , FreeBSD Net , erj@freebsd.org, Jack Vogel , Jason Wolfe X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 17:00:03 -0000 On 3 April 2015 at 09:54, hiren panchasara wrote: > On 03/31/15 at 11:15P, Adrian Chadd wrote: >> Yeah, I think the right thing to do is: >> >> * If the descriptor says it's RSS, then use the flowid + rss type > So, if we have multiqueue, we do everything needed to get RSS > flowid/type. That means, with num_queues > 1 we can just expose those. > >> * else, set it to queue id and set the type to opaque. > > This part becomes irrelevant as it's a single queue case. Do we care > about setting flowid value/type in case of single queue? My whole point with not always setting it is that people may do things to /other/ parts of the driver and suddenly the RSS field isn't the RSS field anymore. Doubly so if you start playing with multiqueue + flowdirector on ixgbe. :) So I'd rather the driver be right and correct - checking if the field /is/ RSS and only setting the flowid+flowtype /if/ the value in that register is an RSS flowid, rather than setting it to whatever's there and hoping it's an RSS value. :) -adrian From owner-freebsd-net@FreeBSD.ORG Fri Apr 3 17:02:40 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9543CD; Fri, 3 Apr 2015 17:02:40 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (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 94F935E9; Fri, 3 Apr 2015 17:02:40 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id E84F310B154; Fri, 3 Apr 2015 10:02:39 -0700 (PDT) Date: Fri, 3 Apr 2015 10:02:39 -0700 From: hiren panchasara To: Adrian Chadd Subject: Re: Full 32bit flowid from igb(4) Message-ID: <20150403170239.GD72165@strugglingcoder.info> References: <20150324154931.GC53237@strugglingcoder.info> <20150330225945.GI10892@strugglingcoder.info> <20150331050628.GJ10892@strugglingcoder.info> <20150331170933.GK10892@strugglingcoder.info> <20150403165411.GC72165@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="llIrKcgUOe3dCx0c" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Jack F Vogel , FreeBSD Net , erj@freebsd.org, Jack Vogel , Jason Wolfe X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 17:02:40 -0000 --llIrKcgUOe3dCx0c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 04/03/15 at 10:00P, Adrian Chadd wrote: > On 3 April 2015 at 09:54, hiren panchasara w= rote: > > On 03/31/15 at 11:15P, Adrian Chadd wrote: > >> Yeah, I think the right thing to do is: > >> > >> * If the descriptor says it's RSS, then use the flowid + rss type > > So, if we have multiqueue, we do everything needed to get RSS > > flowid/type. That means, with num_queues > 1 we can just expose those. > > > >> * else, set it to queue id and set the type to opaque. > > > > This part becomes irrelevant as it's a single queue case. Do we care > > about setting flowid value/type in case of single queue? >=20 > My whole point with not always setting it is that people may do things > to /other/ parts of the driver and suddenly the RSS field isn't the > RSS field anymore. >=20 > Doubly so if you start playing with multiqueue + flowdirector on ixgbe. :) >=20 > So I'd rather the driver be right and correct - checking if the field > /is/ RSS and only setting the flowid+flowtype /if/ the value in that > register is an RSS flowid, rather than setting it to whatever's there > and hoping it's an RSS value. :) Okay, I guess it doesn't hurt to read those registers again at the time of actually assigning flowid/type. I'll do that and post a review on phabricator. Cheers, Hiren --llIrKcgUOe3dCx0c Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVHsevXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/la70H/jTWqxtkQxzF6HaOfkO4jXKb AIYB3fgM2o5UjcvQ18F7MT5u2oRMk17jJhEb0BwUs0BJwljFprd3Q72pM41xr894 qGn1Px0fLs+RbtCyaDgLJKnx1lIzxpCbsq8f0cV4hjBQ+oM4aiLC4yk0S0MkLR8T UlgaeVzP9+zQ5OgfIZ23fS0Y4ZPMZQBWAfw8d5JeRxS+EP+oWoLqpsPfVXbqVrPs nLKp7QGx5PMfK5YfBcCdbvTqoF0Deto2I/TdIMTfMbfjj7yW5tquzagPHKsz3FMX ATWF7Ew2XnVPicMEAH1BmUUBogKx5yfWF9FrPM5oPnReBISp+u2Xt0feea26U0g= =xmQ9 -----END PGP SIGNATURE----- --llIrKcgUOe3dCx0c-- From owner-freebsd-net@FreeBSD.ORG Fri Apr 3 19:15:55 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5BDA41B9; Fri, 3 Apr 2015 19:15:55 +0000 (UTC) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::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 18DB36B3; Fri, 3 Apr 2015 19:15:55 +0000 (UTC) Received: by iebmp1 with SMTP id mp1so89680043ieb.0; Fri, 03 Apr 2015 12:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=oD6qnnfNBDuOSvQ31j0fUg2k6ElFFE365bsJ6je/Gwo=; b=CLW2lPn213bJIUcg8LMGDJQRWxBi23SZ+RJZyAY2N6P8ZoZFq8vj5ZU+1sgNaagE2b dl8dkSibvzcMgyNUNyzJXnP42O9fjzthZBNWfI0ts/bkRlrZDgqXcWP/jszKYoVoEL3p kVY6zDUU6XdOyYt0JeLkd9/R70a+2WxboPPUPWrjbVQrE/AU+hxej/BJuTNZAr06ISys fIFDutdD+ld2Rhw+/unQ31MdXnMIibonG1d01LG5TDIrZgQ8Ykl9o41FsQE0LXy/OQh+ HBh9s+cCTK9Tb7ekQehSHm0oC42O52d+C1yZJuQ/rGHoBwjNuNGHHXvquGBX7JInpHY0 3rkg== MIME-Version: 1.0 X-Received: by 10.50.73.168 with SMTP id m8mr23382332igv.32.1428088554443; Fri, 03 Apr 2015 12:15:54 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Fri, 3 Apr 2015 12:15:54 -0700 (PDT) In-Reply-To: <20150403170239.GD72165@strugglingcoder.info> References: <20150324154931.GC53237@strugglingcoder.info> <20150330225945.GI10892@strugglingcoder.info> <20150331050628.GJ10892@strugglingcoder.info> <20150331170933.GK10892@strugglingcoder.info> <20150403165411.GC72165@strugglingcoder.info> <20150403170239.GD72165@strugglingcoder.info> Date: Fri, 3 Apr 2015 12:15:54 -0700 X-Google-Sender-Auth: vwTOLXa2cIxfAc3TOY6t22iluHY Message-ID: Subject: Re: Full 32bit flowid from igb(4) From: Adrian Chadd To: hiren panchasara Content-Type: text/plain; charset=UTF-8 Cc: Jack F Vogel , FreeBSD Net , erj@freebsd.org, Jack Vogel , Jason Wolfe X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 19:15:55 -0000 On 3 April 2015 at 10:02, hiren panchasara wrote: > On 04/03/15 at 10:00P, Adrian Chadd wrote: >> On 3 April 2015 at 09:54, hiren panchasara wrote: >> > On 03/31/15 at 11:15P, Adrian Chadd wrote: >> >> Yeah, I think the right thing to do is: >> >> >> >> * If the descriptor says it's RSS, then use the flowid + rss type >> > So, if we have multiqueue, we do everything needed to get RSS >> > flowid/type. That means, with num_queues > 1 we can just expose those. >> > >> >> * else, set it to queue id and set the type to opaque. >> > >> > This part becomes irrelevant as it's a single queue case. Do we care >> > about setting flowid value/type in case of single queue? >> >> My whole point with not always setting it is that people may do things >> to /other/ parts of the driver and suddenly the RSS field isn't the >> RSS field anymore. >> >> Doubly so if you start playing with multiqueue + flowdirector on ixgbe. :) >> >> So I'd rather the driver be right and correct - checking if the field >> /is/ RSS and only setting the flowid+flowtype /if/ the value in that >> register is an RSS flowid, rather than setting it to whatever's there >> and hoping it's an RSS value. :) > > Okay, I guess it doesn't hurt to read those registers again at the time > of actually assigning flowid/type. I'll do that and post a review on > phabricator. Well, the "Is this RSS flowid" bits are in the RX descriptor, so you don't have to worry about reading registers. :) -adrian From owner-freebsd-net@FreeBSD.ORG Fri Apr 3 21:16:20 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 98898FAF; Fri, 3 Apr 2015 21:16:20 +0000 (UTC) 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 574D3356; Fri, 3 Apr 2015 21:16:19 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (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 BAD111FE022; Fri, 3 Apr 2015 23:16:16 +0200 (CEST) Message-ID: <551F034A.3040402@selasky.org> Date: Fri, 03 Apr 2015 23:16:58 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" , Gleb Smirnoff , "Robert N. M. Watson" Subject: Patch to reduce use of global IP ID value(s) to avoid leaking information Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 21:16:20 -0000 Hi, Moving this discussion away from the committers list, like requested by Gorge N. On 04/03/15 17:14, Gleb Smirnoff wrote:> Hans, > > What the hell? At Fri, 3 Apr 2015 15:41:21 +0300 (MSK) you ask: An expression like that requires a good answer. I've pulled together some parts and pieces from some existing code to make a test application showing the problem. Maybe when you hear the problem with your own ears, you will get it. Setup: I'm running 11-current prior to Gleb's IP ID commits. Possibly Gleb's IP ID commits won't change much. This little crude application I've called "pingphone" almost allows you to speak PCM audio through ICMP packets with zero payload. You need a computer with a sound card that can handle 8KHz PCM which plays through the default /dev/dsp ! Set the default audio adapter using: sysctl hw.snd.default_unit=XXX Also make sure that "kern.hz" is set to 1000 or 8000 and not 100. Else change it and reboot. fetch http://home.selasky.org:8192/privat/pingphone/pingphone.c Or try this if the above fails: fetch http://home.selasky.org/privat/pingphone/pingphone.c Compile it: cc -Wall pingphone.c Let me know if it doesn't compile. Start the ping recorder on localhost (IPv4): ./a.out -m 1 -T 127.0.0.1 Start audio producer on localhost: ./a.out -m 0 -T 127.0.0.1 Stop audio producer on localhost. Start the audio producer from another box so that the traffic goes accross a real network. Maybe inside a jail too? ./a.out -m 0 -T 192.168.x.x Still don't understand what the problem is? Should I make it play some Beethoven piece perhaps ;-) When you're done you maybe want to restore the ICMP limit back to the default: sysctl net.inet.icmp.icmplim=200 What's stated in: https://svnweb.freebsd.org/changeset/base/281024 Is correct. I see no technical reason to pull that out. For the future I've made a new project branch called "hps_head" where I will do development for sys/net/ sys/netinet and sys/netinet6 if I need. Gleb and Robert: You will have -current all to yourself and I hope to not receive any further angry comments from you regarding the issues that appeared this easter. Thank you for the attention. --HPS From owner-freebsd-net@FreeBSD.ORG Fri Apr 3 21:36:44 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 48AEF2BE; Fri, 3 Apr 2015 21:36:44 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C3D8B6ED; Fri, 3 Apr 2015 21:36:43 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id t33Lafsv075347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 4 Apr 2015 00:36:41 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id t33LafjP075346; Sat, 4 Apr 2015 00:36:41 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sat, 4 Apr 2015 00:36:41 +0300 From: Gleb Smirnoff To: Hans Petter Selasky Subject: Re: Patch to reduce use of global IP ID value(s) to avoid leaking information Message-ID: <20150403213641.GM64665@glebius.int.ru> References: <551F034A.3040402@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <551F034A.3040402@selasky.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-net@freebsd.org" , "Robert N. M. Watson" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 21:36:44 -0000 Hans, On Fri, Apr 03, 2015 at 11:16:58PM +0200, Hans Petter Selasky wrote: H> > What the hell? At Fri, 3 Apr 2015 15:41:21 +0300 (MSK) you ask: H> H> An expression like that requires a good answer. I've pulled together H> some parts and pieces from some existing code to make a test application H> showing the problem. Maybe when you hear the problem with your own ears, H> you will get it. H> H> Setup: H> H> I'm running 11-current prior to Gleb's IP ID commits. Possibly Gleb's IP H> ID commits won't change much. H> H> This little crude application I've called "pingphone" almost allows you H> to speak PCM audio through ICMP packets with zero payload. ... Thanks for a nice hack, I'll look at it :) H> What's stated in: H> H> https://svnweb.freebsd.org/changeset/base/281024 H> H> Is correct. I see no technical reason to pull that out. Hans, no one argued with you, that there is a covert channel. Yes there is one! And there are dozens of other covert channels in TCP/IP. But our manual pages are not an essays on hacking the Internet, however. The point of the manual pages is to provide documentation on knobs and switches. The point of the manual pages is not to describe funny stuff you can achieve turning the knobs on or off. The documentation on net.inet.ip.random_id is solid and doesn't need the text from your commit. If you don't agree with me, let's ask opinion of Mike Silbersack, the author of the random IP ID code. What does he things on manual page diff? P.S. Let me notice again, that you give 1 hour and 40 minutes for review. Why so impatient? The paragraph was sitting there without modification for a decade. Can it wait for at least a day? -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri Apr 3 22:01:45 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46D056AD; Fri, 3 Apr 2015 22:01:45 +0000 (UTC) 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 03DE99BC; Fri, 3 Apr 2015 22:01:44 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (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 B4F921FE022; Sat, 4 Apr 2015 00:01:42 +0200 (CEST) Message-ID: <551F0DF0.5010703@selasky.org> Date: Sat, 04 Apr 2015 00:02:24 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: Patch to reduce use of global IP ID value(s) to avoid leaking information References: <551F034A.3040402@selasky.org> <20150403213641.GM64665@glebius.int.ru> In-Reply-To: <20150403213641.GM64665@glebius.int.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , "Robert N. M. Watson" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 22:01:45 -0000 On 04/03/15 23:36, Gleb Smirnoff wrote: > If you don't agree with me, let's ask opinion of Mike Silbersack, the author > of the random IP ID code. What does he things on manual page diff? Hi Gleb, Feel free to modify or update that text. Sure we could ask Mike Silbersack for advice about this one. > P.S. Let me notice again, that you give 1 hour and 40 minutes for review. > Why so impatient? The paragraph was sitting there without modification for > a decade. Can it wait for at least a day? Let's talk this over at the coming BSD conference(s) face to face. I'm fine using "hps_head" for committing stuff that is not directly USB related. --HPS From owner-freebsd-net@FreeBSD.ORG Sat Apr 4 08:39:49 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 696F5E04; Sat, 4 Apr 2015 08:39:49 +0000 (UTC) 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 2612BA49; Sat, 4 Apr 2015 08:39:49 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (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 1E4B71FE022; Sat, 4 Apr 2015 10:39:44 +0200 (CEST) Message-ID: <551FA37B.90609@selasky.org> Date: Sat, 04 Apr 2015 10:40:27 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: Patch to reduce use of global IP ID value(s) to avoid leaking information References: <551F034A.3040402@selasky.org> <20150403213641.GM64665@glebius.int.ru> In-Reply-To: <20150403213641.GM64665@glebius.int.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , "Robert N. M. Watson" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2015 08:39:49 -0000 Hi Gleb, On 04/03/15 23:36, Gleb Smirnoff wrote: > The documentation on net.inet.ip.random_id is solid and doesn't need the > text from your commit. Let me detail a bit more. The old text describing "random_id" clearly gives the wrong impression. It says that information is only leaking one way. It is for sure very misleading. Information can leak both from the inside to the outside and from the outside to the inside. And also between two outsiders or two insiders. That's what's scares me. Try using my testapp if you don't believe me. Given that the ICMP limit is 200 per second by default, I would guess that 199 bits could at maximum be transferred per second in between two parties using the proper algorithms. If I myself was setting up a firewall, this is the kind of stuff I would like to know about in advance. --HPS From owner-freebsd-net@FreeBSD.ORG Sat Apr 4 12:39:03 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6A79ECEB; Sat, 4 Apr 2015 12:39:03 +0000 (UTC) Received: from noether.irl.styx.org (noether.irl.styx.org [IPv6:2a00:d880:6:1a4::98dc]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "noether.irl.styx.org", Issuer "noether.irl.styx.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 02AD128B; Sat, 4 Apr 2015 12:39:02 +0000 (UTC) Received: by noether.irl.styx.org (Postfix, from userid 66) id 6658D19E2A; Sat, 4 Apr 2015 12:38:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mavrino.styx.org (Postfix) with ESMTP id 41B5E3A0496; Sat, 4 Apr 2015 12:12:42 +0100 (BST) Date: Sat, 04 Apr 2015 12:12:42 +0100 (BST) Message-Id: <20150404.121242.1559454934762438716.wwaites@tardis.ed.ac.uk> To: glebius@FreeBSD.org Subject: Re: ng_netflow and BGP From: William Waites In-Reply-To: <20150403143821.GY64665@FreeBSD.org> References: <20150401.115048.1362042954044146751.wwaites@tardis.ed.ac.uk> <20150403143821.GY64665@FreeBSD.org> X-Mailer: Mew version 6.6 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="--Security_Multipart(Sat_Apr__4_12_12_42_2015_989)--" Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2015 12:39:03 -0000 ----Security_Multipart(Sat_Apr__4_12_12_42_2015_989)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Gleb! > The issue is open since I've written the ng_netflow node. You > would agree that keeping the ASN information in kernel, just for > the sake of exporting it out, is rather strange. I agree with this. > But the proper solution, I think, is to do prefix -> ASN > matching at the collector. I don't think I agree with this. The reason is, once the flow data has left the router, a lot of context is lost. In principle, we might also collect other things like localpref, MED, next hop and so forth. All of this information is in the routing daemon, it knows why it installed one route and not another in the kernel, and what the extra metadata about that route was. If the collector has to try and reconstruct this, there will be corner cases when it does not work properly. I can think of a few such corner cases. One is with inconsistent origin ASNs which can be legitimately used for anycast prefixes, a famous one being the 6to4 automatic tunneling network, but also things like local DNS and NTP servers that may use a well known (within a confederation) address that is announced by multiple ASNs. The problem with putting this after ng_netflow is that (for V9) ng_netflow has already decided what the template is, so adding in any extra information means mangling the template which doesn't seem like a good idea. I guess a middle ground is to use V5 which doesn't have templates and a proxy on the router that augments this and sends V9. At the same time, as I said, I agree that most of this does not belong in the kernel. Maybe a solution is to move much of what ng_netflow does out of the kernel and to arrange so that packet headers get sent to a userland daemon that speaks with the routing daemon and generates the flow data. I also do not like requiring the collector to maintain complete routing tables. To me, its job should be simple -- take the flow data and write it to disk. Not try to reconstruct complicated things about what the routing daemon may have been thinking. In our case the extra RAM requirements also hurt -- we are a shoestring operation so keeping a copy of the tables of each border router (so we have enough information to do the reconstruction according to the source of the flow data) seems wasteful. Cheers, -w -- William Waites | School of Informatics http://tardis.ed.ac.uk/~wwaites/ | University of Edinburgh http://www.hubs.net.uk/ | HUBS AS60241 The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ----Security_Multipart(Sat_Apr__4_12_12_42_2015_989)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQIcBAABCgAGBQJVH8cqAAoJEHhNnKzjwx5/L/wQAL/GKCZRKXzYj3Jy44sOPeLz GDewXEDQRYWHHgsk7sAHQJqx/2lH+RusUTDB4yQVdwQHCu8KfEqj1rFgEaHg0Lkd +2gUhAoORvEcKMl0j185jn/rp97ub7eULDfy0ZiVnD9iq8Rc4+1nGaoYlivJXCGe vFyzdrsFQn/9/RXdoJ4MAZYt5Og6REEJMAAqC/ntkIP7BguUmS0T/r0O6bi1QiFv o0iF1ocdcCRAiuG1NUnpEkRp+AfIQdryssH33VPOaM+4bkKesdsJfrg5zx6D/m34 FzUVP8xtJi3I5yYyAYh7WbcuWC8Yg9cWMdS/Wu+VZ1/Wty5o+u0aNbJPqnzz0thB MwMP2BCl3Otwz6lq490Gel7My0Z1e6VDLu8CUR49pDDYsqKhb3W41FkKMMNXLkxp AEYJI+64x1Nkio990cm7qOi6ds2T4q7BqsmTWdUfzIm/f5KVyXp3V4TbQzOX6GuQ +b//GPS7Xh/8kF1SzJY1BYfOa/1UX33C7reZE+lHp/37QjGtQeo0ox6w796EDZ9D mq/3Ybl1Jyi16bXlPPt1WlTp+eCtp0tvBCsNo7+tTKs3vljRhJTrKGRZ7K6p79Ad M0/yWmV6u8XnNV1uGK8nuifK9gNvF88K6DeUYJAGtnIZUPZ/qcdqtmUsGR7KMIsn X9bZYXKkKYem0q/ELYa3 =Sa+n -----END PGP SIGNATURE----- ----Security_Multipart(Sat_Apr__4_12_12_42_2015_989)---- From owner-freebsd-net@FreeBSD.ORG Sat Apr 4 12:54:45 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EC47A7D4; Sat, 4 Apr 2015 12:54:45 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id C32EC66D; Sat, 4 Apr 2015 12:54:45 +0000 (UTC) Received: from [10.0.1.22] (host81-157-243-31.range81-157.btcentralplus.com [81.157.243.31]) by cyrus.watson.org (Postfix) with ESMTPSA id CC94046B89; Sat, 4 Apr 2015 08:54:44 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Patch to reduce use of global IP ID value(s) to avoid leaking information From: "Robert N. M. Watson" X-Mailer: iPhone Mail (12D508) In-Reply-To: <551FA37B.90609@selasky.org> Date: Sat, 4 Apr 2015 13:54:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <35F9F267-EDB3-45FC-95E0-4573556BD736@freebsd.org> References: <551F034A.3040402@selasky.org> <20150403213641.GM64665@glebius.int.ru> <551FA37B.90609@selasky.org> To: Hans Petter Selasky Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2015 12:54:46 -0000 On 4 Apr 2015, at 09:40, Hans Petter Selasky wrote: >> On 04/03/15 23:36, Gleb Smirnoff wrote: >> The documentation on net.inet.ip.random_id is solid and doesn't need the >> text from your commit. >=20 > Let me detail a bit more. The old text describing "random_id" clearly give= s the wrong impression. It says that information is only leaking one way. It= is for sure very misleading. Information can leak both from the inside to t= he outside and from the outside to the inside. And also between two outsider= s or two insiders. That's what's scares me. >=20 > Try using my testapp if you don't believe me. >=20 > Given that the ICMP limit is 200 per second by default, I would guess that= 199 bits could at maximum be transferred per second in between two parties u= sing the proper algorithms. >=20 > If I myself was setting up a firewall, this is the kind of stuff I would l= ike to know about in advance. Covert and side channels are inherent to the design of contemporary processo= rs and operating systems -- via caches, memory bandwidth, OS scheduling, sta= tistics, clock drift due to temperature, protocol counters, rate limiters, e= tc. The inherent difficulty of addressing malicious information-leak mechani= sms means that our time is far better invested in trying to document and mit= igate side channels than covert channels, whose existence must be taken for g= ranted. And it's not just the IP ID field: almost any practical firewall con= figuration will be susceptible to lots of leaks of this sort. For example, r= ate limiting ICMP replies, TCP RST packets, etc, are all potential covert ch= annels. And that is before you start letting through application-level proto= cols like DNS. Instead, we simply need warning that the fundamental function of a firewall -= - of communication as much as blocking or it would be a dual-homed host not a= firewall -- makes it susceptible to covert channels by design. Firewalls ar= e about limiting overt communication -- if you want to limit covert communic= ation you need very different hardware and software designs. Robert= From owner-freebsd-net@FreeBSD.ORG Sat Apr 4 14:12:57 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC330847; Sat, 4 Apr 2015 14:12:57 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7A3F6DA2; Sat, 4 Apr 2015 14:12:57 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (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 47A881FE022; Sat, 4 Apr 2015 16:12:55 +0200 (CEST) Message-ID: <551FF191.2090109@selasky.org> Date: Sat, 04 Apr 2015 16:13:37 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Robert N. M. Watson" Subject: Re: Patch to reduce use of global IP ID value(s) to avoid leaking information References: <551F034A.3040402@selasky.org> <20150403213641.GM64665@glebius.int.ru> <551FA37B.90609@selasky.org> <35F9F267-EDB3-45FC-95E0-4573556BD736@freebsd.org> In-Reply-To: <35F9F267-EDB3-45FC-95E0-4573556BD736@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "emeric.poupon@stormshield.eu >> Emeric POUPON" , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2015 14:12:57 -0000 Hi Robert, On 04/04/15 14:54, Robert N. M. Watson wrote: > Covert and side channels are inherent to the design of > contemporary processors and operating systems -- via caches, > memory bandwidth, OS scheduling, statistics, clock drift due to > temperature, protocol counters, rate limiters, etc. The inherent > difficulty of addressing malicious information-leak mechanisms > means that our time is far better invested in trying to document > and mitigate side channels than covert channels, whose existence > must be taken for granted. And it's not just the IP ID field: > almost any practical firewall configuration will be susceptible > to lots of leaks of this sort. For example, rate limiting ICMP > replies, TCP RST packets, etc, are all potential covert > channels. And that is before you start letting through > application-level protocols like DNS. > > Instead, we simply need warning that the fundamental function of > a firewall -- of communication as much as blocking or it would be > a dual-homed host not a firewall -- makes it susceptible to > covert channels by design. Firewalls are about limiting overt > communication -- if you want to limit covert communication you > need very different hardware and software designs. I don't disagree that we can totally eliminate covert and side channels. It's like you say a part of digital life. There is however a big difference providing a 1 bit per hour statistically proven _unicast_ side channel having X percent error and a 199 bit per second digital _broadcast_ side channel having 0 percent error under good conditions into a firewall or router subsystem. And I think you should agree about that. I was curious enough to Google this topic a bit and I found that NMAP can provide information about hosts which use incremental IPID generation. * OpenBSD always randomize IP ID http://www.securityfocus.com/columnists/361/2 * MacOSX - incremental ? http://forums.macnn.com/90/mac-os-x/119605/mac-os-x-portscan-results/ * All Windows versions - incremental ? http://serverfault.com/questions/258790/changing-tcp-ip-ipid-sequence-generation-algorithm-on-windows-server There are several mentions of using IPID for fingerprinting systems, but no mentions of using it as a communication channel, or for that sake covertly storing 16-bits of information at a remote host. Given the large number of IP addresses in use, several GBytes can be stored this way. I think we should take OpenBSD's example in this case. Also we should think about performance so that this feature can be default on, and not have problems like mutex congestion and so on like Emeric mentioned. --HPS From owner-freebsd-net@FreeBSD.ORG Sat Apr 4 15:58:33 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA904779; Sat, 4 Apr 2015 15:58:33 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 546F88B0; Sat, 4 Apr 2015 15:58:33 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (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 D20B91FE022; Sat, 4 Apr 2015 17:58:30 +0200 (CEST) Message-ID: <55200A51.3090008@selasky.org> Date: Sat, 04 Apr 2015 17:59:13 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Robert N. M. Watson" Subject: Re: Patch to reduce use of global IP ID value(s) to avoid leaking information References: <551F034A.3040402@selasky.org> <20150403213641.GM64665@glebius.int.ru> <551FA37B.90609@selasky.org> <35F9F267-EDB3-45FC-95E0-4573556BD736@freebsd.org> <551FF191.2090109@selasky.org> In-Reply-To: <551FF191.2090109@selasky.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "emeric.poupon@stormshield.eu >> Emeric POUPON" , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2015 15:58:34 -0000 On 04/04/15 16:13, Hans Petter Selasky wrote: > Hi Robert, > > On 04/04/15 14:54, Robert N. M. Watson wrote: >> Covert and side channels are inherent to the design of >> contemporary processors and operating systems -- via caches, >> memory bandwidth, OS scheduling, statistics, clock drift due to >> temperature, protocol counters, rate limiters, etc. The inherent >> difficulty of addressing malicious information-leak mechanisms >> means that our time is far better invested in trying to document >> and mitigate side channels than covert channels, whose existence >> must be taken for granted. And it's not just the IP ID field: >> almost any practical firewall configuration will be susceptible >> to lots of leaks of this sort. For example, rate limiting ICMP >> replies, TCP RST packets, etc, are all potential covert >> channels. And that is before you start letting through >> application-level protocols like DNS. >> >> Instead, we simply need warning that the fundamental function of >> a firewall -- of communication as much as blocking or it would be >> a dual-homed host not a firewall -- makes it susceptible to >> covert channels by design. Firewalls are about limiting overt >> communication -- if you want to limit covert communication you >> need very different hardware and software designs. > > I don't disagree that we can totally eliminate covert and side channels. > It's like you say a part of digital life. There is however a big > difference providing a 1 bit per hour statistically proven _unicast_ > side channel having X percent error and a 199 bit per second digital > _broadcast_ side channel having 0 percent error under good conditions > into a firewall or router subsystem. And I think you should agree about > that. > > I was curious enough to Google this topic a bit and I found that NMAP > can provide information about hosts which use incremental IPID generation. > > * OpenBSD always randomize IP ID > http://www.securityfocus.com/columnists/361/2 > > * MacOSX - incremental ? > http://forums.macnn.com/90/mac-os-x/119605/mac-os-x-portscan-results/ > > * All Windows versions - incremental ? > http://serverfault.com/questions/258790/changing-tcp-ip-ipid-sequence-generation-algorithm-on-windows-server > > > There are several mentions of using IPID for fingerprinting systems, but > no mentions of using it as a communication channel, or for that sake > covertly storing 16-bits of information at a remote host. Given the > large number of IP addresses in use, several GBytes can be stored this way. > > I think we should take OpenBSD's example in this case. Also we should > think about performance so that this feature can be default on, and not > have problems like mutex congestion and so on like Emeric mentioned. > > --HPS Hi Robert, I think you confuse what I'm trying to explain to you from the responses I get. I'm not talking about putting data into the IP ID field or other IP fields, which then someone at the receiving end picks out and stores. This is well known. I'm talking about sampling the IP ID value you get in return from a PING response. A firewall typically has multiple ports. If pinging the gateway from any of these ports cause an increment of a shared IP ID value, then anyone that can ping the common firewall will see the IP ID updates the other parties are doing. This can be used for RX and TX communication. Can you confirm that you understand? I have a feeling we are talking about completely different ways of side channel communication. --HPS From owner-freebsd-net@FreeBSD.ORG Sat Apr 4 17:11:55 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D27081FE for ; Sat, 4 Apr 2015 17:11:55 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 7FE80EE9 for ; Sat, 4 Apr 2015 17:11:55 +0000 (UTC) Received: from [10.0.1.17] (host81-157-243-31.range81-157.btcentralplus.com [81.157.243.31]) by cyrus.watson.org (Postfix) with ESMTPSA id B027546B89; Sat, 4 Apr 2015 13:11:53 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: Patch to reduce use of global IP ID value(s) to avoid leaking information From: "Robert N. M. Watson" In-Reply-To: <55200A51.3090008@selasky.org> Date: Sat, 4 Apr 2015 18:11:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <551F034A.3040402@selasky.org> <20150403213641.GM64665@glebius.int.ru> <551FA37B.90609@selasky.org> <35F9F267-EDB3-45FC-95E0-4573556BD736@freebsd.org> <551FF191.2090109@selasky.org> <55200A51.3090008@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.2070.6) Cc: "emeric.poupon@stormshield.eu >> Emeric POUPON" , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2015 17:11:55 -0000 On 4 Apr 2015, at 16:59, Hans Petter Selasky wrote: > I think you confuse what I'm trying to explain to you from the = responses I get. I'm not talking about putting data into the IP ID field = or other IP fields, which then someone at the receiving end picks out = and stores. This is well known. >=20 > I'm talking about sampling the IP ID value you get in return from a = PING response. A firewall typically has multiple ports. If pinging the = gateway from any of these ports cause an increment of a shared IP ID = value, then anyone that can ping the common firewall will see the IP ID = updates the other parties are doing. This can be used for RX and TX = communication. Can you confirm that you understand? I have a feeling we = are talking about completely different ways of side channel = communication. I entirely understood, and have entirely understood throughout the = thread, what you were describing, but you appear to be confused about = the terminology. Normally, 'covert channel' and 'side channel' are used = in the following senses: A 'covert channel' is a mechanism by which two collaborating (and, = arguably, colluding) parties are able to communicate data despite it not = being an intentional communications channel. It is widely recognised = that covert channels are effectively impossible to eliminate when a = resource is shared by two potentially colluding parties -- e.g., a = common processor, cache, bus, etc. A global IP ID counter is a potential = covert channel because two parties can modulate a signal, with a = variable amount of noise, but it's far from the only one -- signals can = be modulated onto a variety of protocol IDs (e.g., TCP and UDP = port-number allocation) but also timing information (e.g., ICMP and TCP = rate limiters that also exist in the stack and can also be used for = signalling). One particularly neat covert channel, published by Steven = Murdoch, is using CPU load to trigger clock drift, on which a signal can = be modulated quite effectively -- albeit slowly -- which will be visible = via TCP timestamping. A 'side channel' is a mechanism by which an attacking party (the 'spy') = can extract information about an (unwilling) target process without = their collaboration or collusion, despite an assumed isolation policy. = It is widely recognised that side channels are difficult to eliminate = while maintaining efficient sharing of an underlying resource -- e.g., a = common processor, cache, bus, etc -- and almost impossible if the shared = medium isn't fully understood. The IP ID counter can also be a side = channel as it can reveal information about the global IP transmission = rate of a host, for example. Another recent example is that of the cache = side-channel attack, in which the effectiveness of process isolation is = greatly limited by hyperthreaded processors. During the 1980s and 1990s, covert channels were studied heavily in the = security literature, especially in the context of secure operating = systems. It was common to try to both measure the effective bandwidth of = covert channels (e.g., how fast a signal could be modulated onto CPU = utilisation between 'high' and 'low' processes in an MLS system). By the = early 1990s, it had been demonstrated that covert channels were almost = impossible to control in practice for general-purpose systems, even = using very restrictive kernel designs and real-time scheduling policies = -- today, some systems do effectively accomplish this (e.g., MILS = systems) but only through very restrictive policies and simplistic = designs. By the late 1990s, the topic of covert-channel analysis had = become extremely niche due to broad recognition that trying to solve the = problem was effectively pointless. The topic has seen some recent = resurgence in large part because covert channels can be used to attack = anonymity systems such as Tor -- e.g., causing hidden services reached = via Tor's overlay network to reveal themselves via the Internet. Where we can limit or close covert channels efficiently, reliably, and = without disrupting underlying functionality, it doesn't hurt to do so. = However, limiting covert channels as a primary design concern -- and in = particular, suggesting that we can do so in a strong way -- is simply = setting ourselves up for failure, as shown by a long research = literature. For the IP ID field, a far more pressing problem is to = ensure maximum robustness for high packet rates. The technique you've = proposed -- simple cryptographic randomness of a global field -- can = substantially damage robustness by reduce the reuse period for IP IDs, = increasing the chances of data corruption when, for example, using >MTU = UDP frames at a significant rate. The good news is that addressing that = problem also reduces the degree to which covert channels can be = utilised, since maintaining the IP ID at greater 2-tuple granularity = reduces the degree to which shared channels exist at all. More mature = mechanisms can help reduce the reuse period for pseudo-random sequences = as well (e.g., dedicating a few MSB or LSB to ensuring a minimum reuse = period). As Gleb and I have both pointed out, there are extensive covert channels = in the design of the TCP/IP protocol suite and its practical = implementations, and given the 'weakest link' nature of covert channel = defence (any channel is sufficient), it is wise to be extremely = sceptical of claims that these can be resolved in a way that provides = any benefit at all to our users. A more reasonable conclusion is that = firewall consumers should not make incorrect assumptions about defence = against colluding parties, as there are countless means of signalling = information across a shared resource such as a firewall. This is = especially true as firewalls are frequently configured to allow = intentional communication, and almost any type of communication taking = place at higher layers in the stack will allow signalling at vast = bandwidths -- e.g., via DNS query content and rates, VPN packet rates, = etc. If you want to make covert-channel prevention a primary design goal if = the FreeBSD stack, a vast amount of work will be required -- you've = spotted just one instance of many possible covert channels -- and it's = not clear it will offer practical benefit nor allow the implementation = to be at all efficient -- which is far more important to most FreeBSD = users. Being alarmist about just one of many covert channels has little = actual benefit, and is leading you to propose design solutions that may = substantially damage real network-stack functionality. If you want to = pursue a goal of covert-channel reduction, you need to be far more = systematic in analysing the potential channels, rather than just hacking = on the one you happen to have observed. If you aren't systematic, = there's actually no benefit to changing the system to address just one = channel! But, more generally, trying to limit covert channels is = something you need to seek a broad architectural consensus on from the = network-stack developer community, and make a primary review goal for = all existing, and all future, code. This will mean new coding standards, = testing tools, etc. The reason I say this is that prior work in this = area -- in particular relating to trusted-system design as captured in = first the Orange Book and later Common Criteria Protection Profiles -- = has provided clear evidence that this is a vastly difficult undertaking, = which has been effectively abandoned for all but the highest-security of = system designs. Robert= From owner-freebsd-net@FreeBSD.ORG Sat Apr 4 18:23:34 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 97179304; Sat, 4 Apr 2015 18:23:34 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4EFC88F3; Sat, 4 Apr 2015 18:23:34 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (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 000391FE022; Sat, 4 Apr 2015 20:23:31 +0200 (CEST) Message-ID: <55202C4E.1010902@selasky.org> Date: Sat, 04 Apr 2015 20:24:14 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Robert N. M. Watson" Subject: Re: Patch to reduce use of global IP ID value(s) to avoid leaking information References: <551F034A.3040402@selasky.org> <20150403213641.GM64665@glebius.int.ru> <551FA37B.90609@selasky.org> <35F9F267-EDB3-45FC-95E0-4573556BD736@freebsd.org> <551FF191.2090109@selasky.org> <55200A51.3090008@selasky.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "emeric.poupon@stormshield.eu >> Emeric POUPON" , "freebsd-net@freebsd.org" , "Peter N. M. Hansteen" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2015 18:23:34 -0000 Hi Robert, On 04/04/15 19:11, Robert N. M. Watson wrote: > and it's not clear it will offer practical benefit nor allow the implementation to be at all efficient -- which is far more important to most FreeBSD users Then what Putin stated public last year is absolutely true: http://www.theguardian.com/world/2014/apr/24/vladimir-putin-web-breakup-internet-cia The IPv4 protocol was intentionally designed to be such, that in any ways trying to make it more secure, will require additional CPU overhead, like keeping track of 2-tuples for generating per-stream IP IDs, that it will not be feasible in practice and then vendors will do insecure implementations instead of secure implementations to get the needed performance. The IP ID field was then intentionally designed to be too small, 16-bit. If Snowden leaks documents on this, would for sure confirm this claim. OK, Robert, I fully understand and will not touch this issue any more before my head gets cut off :-) I appreciate your openness and willingness to share information on this issue. You know the IPv4 history even before I came to this world. --HPS From owner-freebsd-net@FreeBSD.ORG Sat Apr 4 19:06:46 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5943E17 for ; Sat, 4 Apr 2015 19:06:46 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 99407D4C for ; Sat, 4 Apr 2015 19:06:46 +0000 (UTC) Received: from [10.0.1.17] (host81-157-243-31.range81-157.btcentralplus.com [81.157.243.31]) by cyrus.watson.org (Postfix) with ESMTPSA id 3FEC246B97; Sat, 4 Apr 2015 15:06:45 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: Patch to reduce use of global IP ID value(s) to avoid leaking information From: "Robert N. M. Watson" In-Reply-To: <55202C4E.1010902@selasky.org> Date: Sat, 4 Apr 2015 20:06:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <67C313E4-8B93-4B59-AC80-E4DEFFF8B15E@FreeBSD.org> References: <551F034A.3040402@selasky.org> <20150403213641.GM64665@glebius.int.ru> <551FA37B.90609@selasky.org> <35F9F267-EDB3-45FC-95E0-4573556BD736@freebsd.org> <551FF191.2090109@selasky.org> <55200A51.3090008@selasky.org> <55202C4E.1010902@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.2070.6) Cc: "emeric.poupon@stormshield.eu >> Emeric POUPON" , "freebsd-net@freebsd.org" , "Peter N. M. Hansteen" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2015 19:06:46 -0000 On 4 Apr 2015, at 19:24, Hans Petter Selasky wrote: > The IPv4 protocol was intentionally designed to be such, that in any = ways trying to make it more secure, will require additional CPU = overhead, like keeping track of 2-tuples for generating per-stream IP = IDs, that it will not be feasible in practice and then vendors will do = insecure implementations instead of secure implementations to get the = needed performance. The IP ID field was then intentionally designed to = be too small, 16-bit. If Snowden leaks documents on this, would for sure = confirm this claim. Remember that TCP/IP is a product of 1980s computer architecture and = communication technologies. While it's true that a number of the key = design decisions from that period are suited for very different problems = than we face today (e.g., a real concern with global passive = adversaries), they were also working with far more limited = communications speeds, processor speeds, and memory sizes. Although I = wasn't there myself, you have to suspect that some folk involved felt = that 16 bits was far too much when prevailing communication speeds were = <9,600bps. More generally, though, the covert channel problem is actually a = fundamental one to the design of computer systems, and in the territory = of "we just don't know how to engineer solutions to this problem in a = scalable way" still. Maybe another 10-20 years will fix that, especially = with formal techniques becoming more viable. In the end, I think that = does need to the approach due to weakest-link concerns in security. The = good news is that formal methods are starting to become viable at scale, = so there is real hope in that regard (I believe, anyway). I think there is real, interesting, and immediate work to do in = improving our IP ID implementation though, which will have substantial = performance and functionality benefits, along with the side effect of = reducing the impact of the covert channel you've raised, though. = Hopefully that's something we can sort out in the next few months since = it will help with contention issues such as the one raised. Robert >=20 > OK, Robert, I fully understand and will not touch this issue any more = before my head gets cut off :-) I appreciate your openness and = willingness to share information on this issue. You know the IPv4 = history even before I came to this world. >=20 > --HPS