From owner-freebsd-net@FreeBSD.ORG Wed Jan 1 01:04:53 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4803773C for ; Wed, 1 Jan 2014 01:04:53 +0000 (UTC) Received: from mail-qe0-x234.google.com (mail-qe0-x234.google.com [IPv6:2607:f8b0:400d:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0AF841EC9 for ; Wed, 1 Jan 2014 01:04:52 +0000 (UTC) Received: by mail-qe0-f52.google.com with SMTP id ne12so12730108qeb.25 for ; Tue, 31 Dec 2013 17:04:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=Z1SSMwa/vxe0fXi7bUvj+pXOj5boXNYn5KLWAbjtf1U=; b=BNP5aHtAC8iHi6RRHMLeK8D3f20lY0T6u7f2tm+nJ3ER4qj1PWHFn+tScQT1RC8Ek1 lAm8bFLx+f/5tUSf7aUB8m0f7xlPTiAW2+9QcnoMJBa5/VfY2Ujg4xGqWB6p5zcP50wG deueblwz33A3ThER3z7CCkC1ksGZgNYdddSBDV+7ssIhf4czHBEEL2vkA3PEFlvPkS4e 8S5cHohu7FxS7fsNMFZ4asNwXtDe+I3Tse6FzULso5rnT7KtCCYLxRaX3eDWRzdPtg2y C815Uh0t8igEBRVs5m3+oIWC0dJJLOE+dYbJyFqpsltgr4dqNPLDBNC7MdqrOo4+MetA fEXg== MIME-Version: 1.0 X-Received: by 10.224.124.195 with SMTP id v3mr124236075qar.55.1388538292153; Tue, 31 Dec 2013 17:04:52 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Tue, 31 Dec 2013 17:04:52 -0800 (PST) Date: Tue, 31 Dec 2013 17:04:52 -0800 X-Google-Sender-Auth: 6YC8x35UtxSzMVhjpXNAswI2g5U Message-ID: Subject: ipv6 and flowtable? From: Adrian Chadd To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 01:04:53 -0000 Hi, Turns out flowtable isn't working for ipv6 on -HEAD : table name: ipv6 collisions: 4 allocated: 0 misses: 5934532302 max_depth: 0 free_checks: 41 frees: 10 hits: 2 lookups: 5934532384 I haven't dug into it yet. Has anyone seen this? -a From owner-freebsd-net@FreeBSD.ORG Wed Jan 1 01:12:00 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DA77995D for ; Wed, 1 Jan 2014 01:12:00 +0000 (UTC) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 997891F45 for ; Wed, 1 Jan 2014 01:12:00 +0000 (UTC) Received: by mail-qc0-f179.google.com with SMTP id i8so12660213qcq.10 for ; Tue, 31 Dec 2013 17:11:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=qlOFNI/WtzvCkfkcEJfJkOOe90mnPKPMxQ3Y6xI9s54=; b=ODko2XKvsV6hOgUlx2qd4JLlt0jbQxMcfc/GU0aQbQvtMlP/kgGQn4H/HTex0Hkv0+ EC212bcQ9/KWo6YJZ25HoSNU6r7bwL2YxQf9Atk5IWaoHj8bKLDyH9UMb+bJ4bQxZpad HwtqQy2yOC2+5uW7c1txgAJFjhN7sfiVbaVDNf/E6MCpOs6nIKa3EAXQU7Am/vwkHTu3 0eEyduccdPMo+wkhZg1K123fUAKWl7qApNCeaK0YgFOwi1Vfh3/2IpnZMMjnVJIVx0eG HlnQ0ZVUr3aFXL6O37xE7cIVMyTZwyyvoBvL6Mak9VeDcK3aqfNjIiCbPiL+brfPrb6d +L0Q== MIME-Version: 1.0 X-Received: by 10.49.38.37 with SMTP id d5mr126612394qek.17.1388538719777; Tue, 31 Dec 2013 17:11:59 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Tue, 31 Dec 2013 17:11:59 -0800 (PST) In-Reply-To: References: Date: Tue, 31 Dec 2013 17:11:59 -0800 X-Google-Sender-Auth: RcTz4B47JL2_bwrJvR1iayFdcKQ Message-ID: Subject: Re: ipv6 lock contention with parallel socket io From: Adrian Chadd To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 01:12:00 -0000 btw - just committed this to -HEAD. I'll MFC it to stable/10 in a few days if noone raises any objections. Thanks, -a On 31 December 2013 09:53, Adrian Chadd wrote: > On 30 December 2013 23:35, Adrian Chadd wrote: >> Hi, >> >> I've noticed a bunch of lock contention occurs when doing highly >> parallel (> 4096 sockets) TCP IPv6 traffic. >> >> The contention is here: >> > [snip] > >> >> .. it's the IF_ADATA lock surrounding the lla_lookup() calls. >> >> Now: >> >> * is there any reason this isn't an rmlock? >> * the instance early on in nd6_output_lle() isn't taking the read >> lock, it's taking the full lock. Is there any reason for this? >> >> I don't have much experience or time to spend on optimising the ipv6 >> code to scale better but this seems like one of those things that'll >> bite us in the ass as the amount of ipv6 deployed increases. >> >> Does anyone have any ideas/suggestions on how we could improve things? > > This improves things quite a bit - from 1.9gbyte/sec @ 100% cpu usage > to 2.7gbyte/sec @ 85% CPU usage. It's not perfect - the lock > contention is still there - but it's much less of an issue now. > > Are there any issues with it? > > Index: sys/netinet6/nd6.c > =================================================================== > --- sys/netinet6/nd6.c (revision 259475) > +++ sys/netinet6/nd6.c (working copy) > @@ -1891,9 +1891,9 @@ > flags = ((m != NULL) || (lle != NULL)) ? LLE_EXCLUSIVE : 0; > if (ln == NULL) { > retry: > - IF_AFDATA_LOCK(ifp); > + IF_AFDATA_RLOCK(ifp); > ln = lla_lookup(LLTABLE6(ifp), flags, (struct sockaddr *)dst); > - IF_AFDATA_UNLOCK(ifp); > + IF_AFDATA_RUNLOCK(ifp); > if ((ln == NULL) && nd6_is_addr_neighbor(dst, ifp)) { > /* > * Since nd6_is_addr_neighbor() internally > calls nd6_lookup(), > > > Thanks, > > > > -a From owner-freebsd-net@FreeBSD.ORG Wed Jan 1 04:20:15 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B886B6DF; Wed, 1 Jan 2014 04:20:15 +0000 (UTC) Received: from yoshi.bluerosetech.com (yoshi.brtsvcs.net [IPv6:2607:f2f8:a450::66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9F86D12B3; Wed, 1 Jan 2014 04:20:15 +0000 (UTC) Received: from chombo.houseloki.net (c-71-236-222-167.hsd1.wa.comcast.net [71.236.222.167]) by yoshi.bluerosetech.com (Postfix) with ESMTPSA id 8C17DE6048; Tue, 31 Dec 2013 20:20:14 -0800 (PST) Received: from [IPv6:2601:7:16c0:b50:a4d6:5ff6:5c8a:1f92] (unknown [IPv6:2601:7:16c0:b50:a4d6:5ff6:5c8a:1f92]) by chombo.houseloki.net (Postfix) with ESMTPSA id E144C15B; Tue, 31 Dec 2013 20:20:12 -0800 (PST) Message-ID: <52C39779.3030309@bluerosetech.com> Date: Tue, 31 Dec 2013 20:20:09 -0800 From: Darren Pilgrim User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: jhellenthal@dataix.net, net@freebsd.org, rc@freebsd.org Subject: Re: network.subr _aliasN handling References: <20131228055324.GA72764@aim7400.DataIX.local> In-Reply-To: <20131228055324.GA72764@aim7400.DataIX.local> 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.17 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 Jan 2014 04:20:15 -0000 On 12/27/2013 9:53 PM, jhellenthal@dataix.net wrote: > Looking at _alias'N' sequentialy feels like a neucense. It is. It's also very easy to overlook a gap and have the system break on a reboot. I thought ipv4_addrs_* was a good solution. From owner-freebsd-net@FreeBSD.ORG Wed Jan 1 06:14:48 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 956A9307 for ; Wed, 1 Jan 2014 06:14:48 +0000 (UTC) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 556C91AD2 for ; Wed, 1 Jan 2014 06:14:48 +0000 (UTC) Received: by mail-ig0-f175.google.com with SMTP id j1so39266900iga.2 for ; Tue, 31 Dec 2013 22:14:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=T0X8cBGY5fHXG723Znn/WN+h1cVYE2TJaBw1j5VaXJs=; b=DCzRKSzAZaR05Rg1TVQn9wbL5jWLdYQS8lrsyDIpsXroegEtPWtndNxpu3mzxQNOSu KxSNxrnqI/w2H3063gZ5EYvtJ0kr9wUNmy+UFXzZvObhvo2RatKwONJBbNTJQW5flFkV 0AskBEQU8quU5KjWi2buX8yb9PHQ4UxzOJZMw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=T0X8cBGY5fHXG723Znn/WN+h1cVYE2TJaBw1j5VaXJs=; b=YMVvFBZwuEnSDOizy/ltvxtW2ugAcS/2/qFCkjteRV533Oe4F8wUy6abvaEx5vrNbD cZ7Bcr79+71yJgboGvthv4oqrc2eAzj6SwYCGO53FtLXjn4dzkH3LxM4U9IJMfFjzCOU k+1167lK1HxJk8EPEO6yFnn/dTMNJkKoGYypkJ/eD0+sH82Hicb8wRCo80WmbsVH9jUe +Gd+PH0WmyrQ+AVLNcOkkhjA7AzNAA9NHqnJiEuSYCt8eIkJA4lCxjGLr8WmyGpsgfKj UBn6EeY4JbyJWGRguSigS2Lpdp8Hk66ir/zwDYwcIGdhNaeerWtDX7Fp3Gh/Hyt9vAYl kS5w== X-Gm-Message-State: ALoCoQlaE76vuv3pqXlu7okgod6synYb1JNWvybZPJNqHYar2buUJSFt5PPTG6lbURru2E0Z/OSd X-Received: by 10.50.238.196 with SMTP id vm4mr65529028igc.43.1388556887796; Tue, 31 Dec 2013 22:14:47 -0800 (PST) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id l7sm66333663igx.2.2013.12.31.22.14.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 31 Dec 2013 22:14:45 -0800 (PST) References: <20131228055324.GA72764@aim7400.DataIX.local> <52C39779.3030309@bluerosetech.com> Mime-Version: 1.0 (1.0) In-Reply-To: <52C39779.3030309@bluerosetech.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1A54B616-6826-4B6F-98E8-C7C1E19BAAB0; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <5BF34DE0-85C4-4AA3-9C0F-B9D27D5325BC@dataix.net> X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: network.subr _aliasN handling Date: Wed, 1 Jan 2014 01:14:42 -0500 To: Darren Pilgrim Cc: "rc@freebsd.org" , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 06:14:48 -0000 --Apple-Mail-1A54B616-6826-4B6F-98E8-C7C1E19BAAB0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On Dec 31, 2013, at 23:20, Darren Pilgrim w= rote: >=20 >> On 12/27/2013 9:53 PM, jhellenthal@dataix.net wrote: >> Looking at _alias'N' sequentialy feels like a neucense. >=20 > It is. It's also very easy to overlook a gap and have the system break on= a reboot. I thought ipv4_addrs_* was a good solution. >=20 Ipv4_addrs var while nice can get very lengthy very quick and then more pron= e to humanized errors. If you add ipv6 in there it grows horizontally tenfol= d. There just isn't an easy way around this unless we were to for say . . .=20= /etc/ifconfig_ipv4 /etc/ifconfig_ipv6 And then read in the lines one by one as . . .=20 $INTERFACE $ADDR $OPTS Personally I like the way Debian handles this but I really only see a need f= or handling it the initial way I wrote about non-sequentially which puts it f= airly close to how they do it.= --Apple-Mail-1A54B616-6826-4B6F-98E8-C7C1E19BAAB0 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDEwMTA2MTQ0NVowIwYJKoZIhvcN AQkEMRYEFALzNeGKeqifFFWY/uMc8cYHSbbuMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEAit8BWGzRSl+uG1MrYp/4 /KYXW700Zzwsw3kKSyvnDoO6gHdhweiXgkF8MxkiCHnyIamDQ38OOkoxeOu+wA6edXNDRIS46JwP icZxT/VXhUY803OSuzMNqMwNPpqnBWRiyM3ACQhyG0MAT5gaf6LASjAMJgKfVwR5ss00hKe/3+RX HEZDNolHbjLDliEZHEHqwPKAhXo/AmbzRPc7ZnQ3+g1PZvGc+w71p8sTFY2WWkpd7FBofVzIBZhr 0vgQ9y/Qpof9utyor0n9f+uMugygCV++2DX1mg70ujQXyftbXRowNaruPJ4ZinAzEbAG9EB1p5HX fXi9gBL3hZsrpILU0gAAAAAAAA== --Apple-Mail-1A54B616-6826-4B6F-98E8-C7C1E19BAAB0-- From owner-freebsd-net@FreeBSD.ORG Wed Jan 1 06:27:06 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55A6D48D; Wed, 1 Jan 2014 06:27:06 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 19D151B7C; Wed, 1 Jan 2014 06:27:05 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa07.fnfis.com (8.14.5/8.14.5) with ESMTP id s016Qvcw002129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 1 Jan 2014 00:26:59 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.7]) by LTCFISWMSGHT03.FNFIS.com ([10.132.206.31]) with mapi id 14.03.0158.001; Wed, 1 Jan 2014 00:26:56 -0600 From: "Teske, Devin" To: Jason Hellenthal Subject: Re: network.subr _aliasN handling Thread-Topic: network.subr _aliasN handling Thread-Index: AQHPBrp3g2zBVOFHpkK/1WPEBoXO2w== Date: Wed, 1 Jan 2014 06:26:55 +0000 Message-ID: <483E29B3-33C1-49BC-9048-3FBCCD1F0594@fisglobal.com> References: <20131228055324.GA72764@aim7400.DataIX.local> <52C39779.3030309@bluerosetech.com> <5BF34DE0-85C4-4AA3-9C0F-B9D27D5325BC@dataix.net> In-Reply-To: <5BF34DE0-85C4-4AA3-9C0F-B9D27D5325BC@dataix.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="us-ascii" Content-ID: <68A426B58F3DD14285EF588428E424B0@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-01-01_03:2014-01-01,2014-01-01,1970-01-01 signatures=0 Cc: Devin Teske , "rc@freebsd.org" , "net@freebsd.org" , "Teske, Devin" , Darren Pilgrim X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Devin Teske List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jan 2014 06:27:06 -0000 On Dec 31, 2013, at 10:14 PM, Jason Hellenthal wrote: >=20 >=20 >> On Dec 31, 2013, at 23:20, Darren Pilgrim wrote: >>=20 >>> On 12/27/2013 9:53 PM, jhellenthal@dataix.net wrote: >>> Looking at _alias'N' sequentialy feels like a neucense. >>=20 >> It is. It's also very easy to overlook a gap and have the system break = on a reboot. I thought ipv4_addrs_* was a good solution. >>=20 >=20 > Ipv4_addrs var while nice can get very lengthy very quick and then more p= rone to humanized errors. If you add ipv6 in there it grows horizontally te= nfold. >=20 > There just isn't an easy way around this unless we were to for say . . .= =20 > /etc/ifconfig_ipv4 > /etc/ifconfig_ipv6 >=20 > And then read in the lines one by one as . . .=20 > $INTERFACE $ADDR $OPTS >=20 >=20 > Personally I like the way Debian handles this but I really only see a nee= d for handling it the initial way I wrote about non-sequentially which puts= it fairly close to how they do it. Which I bet my patch would implement it the way you want. Any chance to get around to testing it yet? --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-net@FreeBSD.ORG Wed Jan 1 06:30:18 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BFC72552 for ; Wed, 1 Jan 2014 06:30:18 +0000 (UTC) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 74BB91C92 for ; Wed, 1 Jan 2014 06:30:18 +0000 (UTC) Received: by mail-ig0-f169.google.com with SMTP id hk11so39034293igb.0 for ; Tue, 31 Dec 2013 22:30:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=+rkvp1mLZjEXxrCgj2Sn8zXdBQvaXRKemOPIptpGuC8=; b=Ev2rIuIxi75PYajPkIcShzqd22cJdIzEnHPOWjmNDMqfCHmJWmnYLa9RlRnOV8pGYZ ApYAbBUJfGrto4w4JCaCEYI/cW0KNxdv/I9kidXEV/AupBBgRd6Mrt2sLkEa0+H4zEUs bX4o4pxnHGSC/2fVDzDKXOPWNss2iocL9byOM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=+rkvp1mLZjEXxrCgj2Sn8zXdBQvaXRKemOPIptpGuC8=; b=CSQzOoZkeqAaMgotFU+GuaRdCNsM3Idcjf9xifh+8P6+2jxpxnYJf91AYbSY7lluy8 JRDOaBMAijPHg7tr+zXiB3lVxHjOA/Pki0vsrKG1kQuNfaOzrSR1rlBOavhJQRIvM8UE 5JtxGL+3uQJ9scAMXGy5+eMYxQmoz8ir+j0/LtLW+FqDNOIhmq71u7LOBjN+7h68y3id 1rwDdFDjkG8GF3bXcmnXCwrpvZV+mBetvMto015qQk2JeuKieQUyOF9kA1/fipv3nXp8 5Tqm9YUCCbSXWf0PJ6pAAhh+nZgwwHyXjpnTLfKZqV4ku7A8opbkxyFWpTmanhD1Lvdn Twrg== X-Gm-Message-State: ALoCoQkbeYeqwm2OCNBVvnqoku/19w1nxBAxzjI3ZhGnlk4KJTsp9uLLtippMOeYJ0p78mj0yzq2 X-Received: by 10.50.176.201 with SMTP id ck9mr64539637igc.46.1388557817878; Tue, 31 Dec 2013 22:30:17 -0800 (PST) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id ft2sm66373623igb.5.2013.12.31.22.30.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 31 Dec 2013 22:30:15 -0800 (PST) References: <20131228055324.GA72764@aim7400.DataIX.local> <52C39779.3030309@bluerosetech.com> <5BF34DE0-85C4-4AA3-9C0F-B9D27D5325BC@dataix.net> <483E29B3-33C1-49BC-9048-3FBCCD1F0594@fisglobal.com> Mime-Version: 1.0 (1.0) In-Reply-To: <483E29B3-33C1-49BC-9048-3FBCCD1F0594@fisglobal.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2BFEC852-62A1-4AFE-8809-344F3DCA9E0C; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <0C612741-31AD-4CCF-B78B-60E2212324A7@dataix.net> X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: network.subr _aliasN handling Date: Wed, 1 Jan 2014 01:30:12 -0500 To: Devin Teske X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Devin Teske , "rc@freebsd.org" , "net@freebsd.org" , "Teske, Devin" , Darren Pilgrim X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 06:30:18 -0000 --Apple-Mail-2BFEC852-62A1-4AFE-8809-344F3DCA9E0C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I'll be able to finally get around to doing this on the 2nd, sorry for the d= elay. But just a quick overview of the code in my sight I do see it DTRT.=20 --=20 Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On Jan 1, 2014, at 1:26, "Teske, Devin" wrote:= >=20 >=20 >> On Dec 31, 2013, at 10:14 PM, Jason Hellenthal wrote: >>=20 >>=20 >>=20 >>>> On Dec 31, 2013, at 23:20, Darren Pilgrim wrote: >>>>=20 >>>> On 12/27/2013 9:53 PM, jhellenthal@dataix.net wrote: >>>> Looking at _alias'N' sequentialy feels like a neucense. >>>=20 >>> It is. It's also very easy to overlook a gap and have the system break o= n a reboot. I thought ipv4_addrs_* was a good solution. >>=20 >> Ipv4_addrs var while nice can get very lengthy very quick and then more p= rone to humanized errors. If you add ipv6 in there it grows horizontally ten= fold. >>=20 >> There just isn't an easy way around this unless we were to for say . . .= =20 >> /etc/ifconfig_ipv4 >> /etc/ifconfig_ipv6 >>=20 >> And then read in the lines one by one as . . .=20 >> $INTERFACE $ADDR $OPTS >>=20 >>=20 >> Personally I like the way Debian handles this but I really only see a nee= d for handling it the initial way I wrote about non-sequentially which puts i= t fairly close to how they do it. >=20 > Which I bet my patch would implement it the way you want. > Any chance to get around to testing it yet? > --=20 > Devin >=20 > _____________ > The information contained in this message is proprietary and/or confidenti= al. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any man= ner; and (iii) notify the sender immediately. In addition, please be aware t= hat any message addressed to our domain is subject to archiving and review b= y persons other than the intended recipient. Thank you. --Apple-Mail-2BFEC852-62A1-4AFE-8809-344F3DCA9E0C Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDEwMTA2MzAxNVowIwYJKoZIhvcN AQkEMRYEFAd8PBvKeajDT1LZn7snz+cCvo6xMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEASBxLPpqxc5YRN7FUEUwS r+YBeRdREHnpjbhGBP3CO2u+Hf6FKdc/qm7pfSrObUohtFX6RTMvzDuDPnxdAcIuoaRJil9EdDWw dZgEjSRKrsR0QM8cPX2acR+bWHGWuWb35cyuuQNDriUxQUQr29Sn5UzSHipvghaMEfSZqFXmd1O3 jVNEFTGRpYGGbPeK3gvFBTL7ShEUGZEChRzm4azZEJ6sd/stVoKU/Aazu6bnz86E5Uti3daLaNQV zTF41I4Awq4NBaDWV5rBapUfMy+VE3rxy1n9RVysn5xqquafu1CLV/y00KcsP24/gsEvynzofGbq p3kZhZcOOWQUtMzHRAAAAAAAAA== --Apple-Mail-2BFEC852-62A1-4AFE-8809-344F3DCA9E0C-- From owner-freebsd-net@FreeBSD.ORG Wed Jan 1 08:57:39 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A075C880 for ; Wed, 1 Jan 2014 08:57:39 +0000 (UTC) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3AC661562 for ; Wed, 1 Jan 2014 08:57:38 +0000 (UTC) Received: from server.rulingia.com (c220-239-250-249.belrs5.nsw.optusnet.com.au [220.239.250.249]) by vps.rulingia.com (8.14.7/8.14.7) with ESMTP id s018vRwm022562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 1 Jan 2014 19:57:27 +1100 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.7/8.14.7) with ESMTP id s018vLsV034486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 1 Jan 2014 19:57:21 +1100 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.7/8.14.7/Submit) id s018vLW3034485 for freebsd-net@freebsd.org; Wed, 1 Jan 2014 19:57:21 +1100 (EST) (envelope-from peter) Date: Wed, 1 Jan 2014 19:57:21 +1100 From: Peter Jeremy To: freebsd-net@freebsd.org Subject: IPv4 Multicast MAC Address issues Message-ID: <20140101085721.GA34334@server.rulingia.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 08:57:39 -0000 --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm trying to use multicast on my home network for the first time and have found an apparent anomoly in the destination MAC address. My reading of RFC1112 section 6.4 is that the the destination MAC address uses the low 23 bits of the destination (multicast) IP address. This is what Linux and Windows do and ifmcstat(8) on FreeBSD shows that as the multicast MAC filter. Unfortunately, it seems that (at least on FreeBSD-10), the destination MAC address uses the low 23 bits of the IP address of my default route. I am not doing any special multicast-related configuration on any of the hosts and have been using ping(8) to generate multicast packets. Does FreeBSD need special configuration to support multicast or is this a bug? --=20 Peter Jeremy --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iKYEARECAGYFAlLD2HFfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDBCRjc3QTcyNTg5NEVCRTY0RjREN0VFRUZF OEE0N0JGRjAwRkI4ODcACgkQ/opHv/APuId8KACfcedqTHKmw7FD8iqMTOkc/XKe gdEAnRCKv9LSbWNp+r4fMRhQbOVmfKTI =8tEW -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- From owner-freebsd-net@FreeBSD.ORG Wed Jan 1 13:11:01 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46ED698E; Wed, 1 Jan 2014 13:11:01 +0000 (UTC) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2AF291539; Wed, 1 Jan 2014 13:10:59 +0000 (UTC) Received: by mail-lb0-f181.google.com with SMTP id q8so6674998lbi.40 for ; Wed, 01 Jan 2014 05:10:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=1cnhelaWIueBGMomxFQZW3GDRmcNbfyV5SHGCSOZIJY=; b=KqzucI8LxJIUqDB84rN+NVX6TjSmXKvMIr7viYxvs0rQEJQsjpn03b+3TRWd4JPNAb UyuvCtp5RdHNzzJLT6SeGpW3yv6CeeUtPycDMGTq5PrqlsVDWd974CAOl2E7rj+NQa9g GVDMKlMZ4Hlernv1qPcZPYAEeffVhYamM5rCBVW6SEO/M+qd2ylrwuVpylZi4sWePKeo zIwwJ4K3/j5zVfJEWt70dq1fdI0Z1ZcpMEdJdnfA2wYVw1KrnIFMF12huJqd5MjAFyoH 5wspCTcA7AYmwI5NaPMwVy7gq2cOFJGPIRNGAjzSk0mCmIrKGqBUlsUYPYyHxLoU8gyb ESJQ== MIME-Version: 1.0 X-Received: by 10.112.17.39 with SMTP id l7mr701161lbd.51.1388581858051; Wed, 01 Jan 2014 05:10:58 -0800 (PST) Received: by 10.114.242.33 with HTTP; Wed, 1 Jan 2014 05:10:57 -0800 (PST) In-Reply-To: <201312221310.rBMDA0KH022980@freefall.freebsd.org> References: <201312221304.rBMD4q38060416@oldred.freebsd.org> <201312221310.rBMDA0KH022980@freefall.freebsd.org> Date: Wed, 1 Jan 2014 13:10:57 +0000 Message-ID: Subject: Re: misc/185092: panic: rtfree 2 (using RADIX_MPATH in a VNET jail) From: Nikolay Denev To: FreeBSD-gnats-submit@freebsd.org, freebsd-bugs@freebsd.org, "freebsd-net@freebsd.org" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 13:11:01 -0000 On Sun, Dec 22, 2013 at 1:10 PM, wrote: > Thank you very much for your problem report. > It has the internal identification `misc/185092'. > The individual assigned to look at your > report is: freebsd-bugs. > > You can access the state of your problem report at any time > via this link: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D185092 > > >Category: misc > >Responsible: freebsd-bugs > >Synopsis: panic: rtfree 2 (using RADIX_MPATH in a VNET jail) > >Arrival-Date: Sun Dec 22 13:10:00 UTC 2013 > I'm trying to understand exactly what is happening here, and examining a core dump with kgdb I'm getting some output that confuses me : (kgdb) bt #0 doadump (textdump=3D-1011569920) at pcpu.h:233 #1 0xc06069b2 in kern_reboot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0xc0606d0e in panic (fmt=3D) at /usr/src/sys/kern/kern_shutdown.c:754 #3 0xc06de639 in rtfree (rt=3D) at /usr/src/sys/net/route.c:464 #4 0xc06e188d in route_output (m=3D) at /usr/src/sys/net/rtsock.c:951 #5 0xc06de18f in raw_usend (so=3D, flags=3D0, m=3D, nam=3D0x0, control=3D, td=3D0xc3bd2000) at /usr/src/sys/net/raw_usrreq.c:238 #6 0xc066eca9 in sosend_generic (so=3D0xc3e9c1a8, uio=3D, top=3D, control=3D0x0, flags=3D, td=3D) at /usr/src/sys/kern/uipc_socket.c:1271 #7 0xc066efc7 in sosend (so=3D0xc3e9c1a8, addr=3D0x0, uio=3D0xd9b9cc10, to= p=3D0x0, control=3D0x0, flags=3D0, td=3D0xc3bd2000) at /usr/src/sys/kern/uipc_socket.c:1315 #8 0xc0654af4 in soo_write (fp=3D0xc3c0c818, uio=3D0xd9b9cc10, active_cred=3D0xc3f1dd00, flags=3D0, td=3D0xc3bd2000) at /usr/src/sys/kern/sys_socket.c:103 #9 0xc064c866 in dofilewrite (td=3D0xc3bd2000, fd=3D3, fp=3D0xc3c0c818, auio=3D0xd9b9cc10, offset=3D-1, flags=3D0) at file.h:303 #10 0xc064c566 in kern_writev (td=3D0xc3bd2000, fd=3D3, auio=3D) at /usr/src/sys/kern/sys_generic.c:467 #11 0xc064c4bc in sys_write (td=3D, uap=3D) at /usr/src/sys/kern/sys_generic.c:382 #12 0xc08614d3 in syscall (frame=3D) at subr_syscall.c:134 #13 0xc084cca1 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:270 #14 0x281975b7 in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) fr 3 #3 0xc06de639 in rtfree (rt=3D) at /usr/src/sys/net/route.c:464 464 panic("rtfree 2"); (kgdb) print *rt $1 =3D {rt_nodes =3D {{rn_mklist =3D 0xc3b4ab30, rn_parent =3D 0x1, rn_bit = =3D 0, rn_bmask =3D 0 '\0', rn_flags =3D 0 '\0', rn_u =3D {rn_leaf =3D { rn_Key =3D 0xc0882687 "shutdown_post_sync", rn_Mask =3D 0x1030000
, rn_Dupedkey =3D 0x0}, rn_node =3D { rn_Off =3D -1064819065, rn_L =3D 0x1030000, rn_R =3D 0x0}}}, {rn_= mklist =3D 0x0, rn_parent =3D 0x4, rn_bit =3D -18048, rn_bmask =3D -94 '?', rn_flags =3D 195 '?', rn_u =3D {rn_leaf =3D {rn_Key =3D 0xc3a545e0 ""= , rn_Mask =3D 0xc3a4e440 " ??(???\020'", rn_Dupedkey =3D 0xc3a4e880}, rn_node =3D {rn_Off =3D -1012578848, rn_L =3D 0xc3a4e440, rn_R =3D 0xc3a4e880}}}}, rt_gateway =3D 0x74756873, rt_flags =3D 1853321060, rt_refcnt =3D 1936683103, rt_ifp =3D 0x79735f74, rt_ifa =3D 0x636e, rt_rm= x =3D {rmx_mtu =3D 0, rmx_expire =3D 0, rmx_pksent =3D 0, rmx_weight =3D 0}, rt_fibnum =3D 0, rt_mtx =3D {lock_object =3D {lo_name =3D 0x0, lo_flags = =3D 0, lo_data =3D 0, lo_witness =3D 0x0}, mtx_lock =3D 0}} rn_Key with value of =93shutdown_post_sync=94 ? It=92s visible also in the raw_usend() frame: (kgdb) fr 5 #5 0xc06de18f in raw_usend (so=3D, flags=3D0, m=3D, nam=3D0x0, control=3D, td=3D0xc3bd2000) at /usr/src/sys/net/raw_usrreq.c:238 238 return ((*so->so_proto->pr_output)(m, so)); (kgdb) print *m $2 =3D {m_hdr =3D {mh_next =3D 0xc3b4ab30, mh_nextpkt =3D 0x1, mh_data =3D = 0x0, mh_len =3D -1064819065, mh_type =3D 0, mh_flags =3D 66304, mh_pad =3D 0}, M_dat =3D {MH =3D {MH_pkthdr =3D {rcvif =3D 0x0, tags =3D {slh_first =3D = 0x4}, len =3D -1012745856, flowid =3D 3282388448, csum_flags =3D 14097648373312316480, fibnum =3D 26739, cosqos =3D 1= 17 'u', rsstype =3D 116 't', l2hlen =3D 100 'd', l3hlen =3D 111 'o', l4hlen =3D 119 'w', l5hlen =3D 110 'n', PH_per =3D {eigth =3D "_pos= t_sy", sixteen =3D {28767, 29551, 24436, 31091}, thirtytwo =3D {1936683103, 2037604212}, sixtyfour =3D {8751443454668533855}, unintptr =3D {1936683103}, ptr =3D 0x736f705f}, PH_loc =3D { eigth =3D "nc\000\000\000\000\000", sixteen =3D {25454, 0, 0, 0}, thirtytwo =3D {25454, 0}, sixtyfour =3D {25454}, unintptr =3D {25454}, ptr =3D 0x636e}}, MH_dat =3D {MH_ext =3D {ref_cnt =3D 0x0, ext_bu= f =3D 0x0, ext_size =3D 0, ext_type =3D 0, ext_flags =3D 0, ext_free =3D 0, ext_arg1 =3D 0x0, ext_arg2 =3D 0x0}, MH_databuf =3D '\0' , "file", '\0' , "\006\000\000\000\020\000\000\000??\215?\000\000C\001\000\000\000\000\000\0= 00\000\000\004\000\000\000\000\000\000\00000Y?", '\0' , "`2Y?\000\000\000\000\000\000\000\000T\211\223?\022\000\000\000\000\203??\0= 00\000\000\000\000???", '\0' }}, M_databuf =3D "\000\000\000\000\004\000\000\000\200????E??@??\200??shutdown_post_sync", '\0' , "file", '\0' , "\006\000\000\000\020\000\000\000??\215?\000\000C\001\000\000\000\000\000\0= 00\000\000\004\000\000\000\000\000\000\00000Y?", '\0' , "`2Y?\000\000\000\000\000\000\000\000T\211\223?\022\000\000\000\000\203??\0= 00\000\000\000\000???", '\0' }} This is 10.0-PRERELEASE r259547M (with applied the recent nd6_nbr.c rtfree patch, which I thought earlier might be the cause of the panics I'm seeing). The machine is Soekris Net5501-70 with this kernel config : cpu I586_CPU cpu I686_CPU ident MARS options CPU_GEODE options CPU_SOEKRIS options HZ=3D2000 options DEVICE_POLLING options BPF_JITTER makeoptions DEBUG=3D-g # Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options TCP_OFFLOAD # TCP offload options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_DIRHASH # Improve performance on big directories options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=3D500 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=3D128 # Prevent printf output being interspersed. options KBD_INSTALL_CDEV # install a CDEV entry in /dev options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options CAPABILITY_MODE # Capsicum capability mode options CAPABILITIES # Capsicum capabilities options PROCDESC # Support for process descriptors options INCLUDE_CONFIG_FILE # Include this file in kernel # Debugging support. Always need this: options KDB # Enable kernel debugger support. options KDB_TRACE # Print a stack trace for a panic. options KDB_UNATTENDED options TEXTDUMP_PREFERRED options TEXTDUMP_VERBOSE device pci device ata # Legacy ATA/SATA controllers options ATA_STATIC_ID # Static device numbering # ATA/SCSI peripherals device scbus # SCSI bus (required for ATA/SCSI) device da # Direct Access (disks) device pass # Passthrough device (direct ATA/SCSI access) # Add suspend/resume support for the i8254. device pmtimer # Serial (COM) ports device uart # Generic UART driver device miibus # MII bus support device vr # VIA Rhine, Rhine II # Wireless NIC cards device wlan # 802.11 support options IEEE80211_DEBUG # enable debug msgs options IEEE80211_AMPDU_AGE # age frames in AMPDU reorder q's options IEEE80211_SUPPORT_MESH # enable 802.11s draft support device wlan_wep # 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device wlan_amrr # AMRR transmit rate control algorithm device ath # Atheros NICs device ath_pci # Atheros pci/cardbus glue device ath_hal # pci/cardbus chip support options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors options AH_AR5416_INTERRUPT_MITIGATION # AR5416 interrupt mitigation options ATH_ENABLE_11N # Enable 802.11n support for AR5416 and later device ath_rate_sample # SampleRate tx rate control for ath # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device vlan # 802.1Q VLAN support device tun # Packet tunnel. device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device gre device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module device if_bridge options VIMAGE options ROUTETABLES=3D8 options RADIX_MPATH options SW_WATCHDOG device crypto device cryptodev device glxsb options BOOTVERBOSE=3D1 #device pf #device pflog #device pfsync device carp device enc device lagg device epair #options ALTQ #options ALTQ_CBQ #options ALTQ_RED #options ALTQ_RIO #options ALTQ_HFSC #options ALTQ_PRIQ options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_NAT options LIBALIAS options IPDIVERT options DUMMYNET device bpf # Berkeley packet filter # USB support options USB_DEBUG # enable debug msgs device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) device umass # Disks/Mass storage - Requires scbus and da Also src.conf and make.conf : root@vpn_vrf:[VNET(x)]:/usr/src/sys # cat /etc/src.conf WITHOUT_ACCT=3Dyes WITHOUT_ACPI=3Dyes WITHOUT_AMD=3Dyes WITHOUT_APM=3Dyes WITHOUT_ASSERT_DEBUG=3Dyes WITHOUT_AT=3Dyes WITHOUT_ATF=3Dyes WITHOUT_ATM=3Dyes WITHOUT_AUDIT=3Dyes WITHOUT_BLUETOOTH=3Dyes WITHOUT_CALENDAR=3Dyes WITHOUT_CDDL=3Dyes WITHOUT_CTM=3Dyes WITHOUT_DICT=3Dyes WITHOUT_FLOPPY=3Dyes WITHOUT_GAMES=3Dyes WITHOUT_HTML=3Dyes WITHOUT_INFO=3Dyes WITHOUT_IPFILTER=3Dyes WITHOUT_IPX=3Dyes #WITHOUT_KERNEL_SYMBOLS=3Dyes WITHOUT_LEGACY_CONSOLE=3Dyes WITHOUT_LOCALES=3Dyes WITHOUT_LPR=3Dyes WITHOUT_MAIL=3Dyes WITHOUT_NDIS=3Dyes WITHOUT_QUOTAS=3Dyes WITHOUT_ROUTED=3Dyes WITHOUT_SENDMAIL=3Dyes WITH_SVN=3Dyes WITHOUT_ZFS=3Dyes root@vpn_vrf:[VNET(x)]:/usr/src/sys # cat /etc/make.conf CFLAGS=3D-O2 COPTFLAGS=3D -O -pipe CPUTYPE=3Dgeode KERNCONF=3DMARS NO_MODULES=3Dyes BOOTWAIT=3D0 DOC_LANG=3Den_US.ISO8859-1 --Nikolay From owner-freebsd-net@FreeBSD.ORG Wed Jan 1 13:21:16 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 952A4C33; Wed, 1 Jan 2014 13:21:16 +0000 (UTC) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 76F4515F1; Wed, 1 Jan 2014 13:21:15 +0000 (UTC) Received: by mail-lb0-f180.google.com with SMTP id x18so6810955lbi.11 for ; Wed, 01 Jan 2014 05:21:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=M7iQ2T7MzNhjcOqNlvmdFUI9vniQl4n4CvYtTbj+NFE=; b=xQc8sRkLoNQQnyYkflEDYAopXTdTGKFcodg3QNCYOTtUtw2zxFmrCk2QPRcYmvjdJG V5HR6T+WcgJRVi/wYaUQMCHcEBnmVQmsEbta5LE515Q9CNjlkXX7OYAK7DVEFkJV1dvA V6rmfURRlg9k7UBQGQpXtieB4Zr3SVhzPBQW/j9A1bY+ewkUamxq7F8TvylqfrFfY+Hr AbtgftXVNeKP2NRGU4LstGTB/cgdw8tWSfN8yWjtSeUkkbRHR7TN0K1s5L/8KnKHMiKI uLeSBtk7EQXG8WZ+rsk+/R/tcZ4KfkaUtUIRnp2XnwoJjseZizlMYMksee7YVVb9idZx UUvQ== MIME-Version: 1.0 X-Received: by 10.152.45.8 with SMTP id i8mr32299300lam.12.1388582473255; Wed, 01 Jan 2014 05:21:13 -0800 (PST) Received: by 10.114.242.33 with HTTP; Wed, 1 Jan 2014 05:21:13 -0800 (PST) In-Reply-To: References: <201312221304.rBMD4q38060416@oldred.freebsd.org> <201312221310.rBMDA0KH022980@freefall.freebsd.org> Date: Wed, 1 Jan 2014 13:21:13 +0000 Message-ID: Subject: Re: misc/185092: panic: rtfree 2 (using RADIX_MPATH in a VNET jail) From: Nikolay Denev To: FreeBSD-gnats-submit@freebsd.org, freebsd-bugs@freebsd.org, "freebsd-net@freebsd.org" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 13:21:16 -0000 On Wed, Jan 1, 2014 at 1:10 PM, Nikolay Denev wrote: > On Sun, Dec 22, 2013 at 1:10 PM, wrote= : > >> Thank you very much for your problem report. >> It has the internal identification `misc/185092'. >> The individual assigned to look at your >> report is: freebsd-bugs. >> >> You can access the state of your problem report at any time >> via this link: >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D185092 >> >> >Category: misc >> >Responsible: freebsd-bugs >> >Synopsis: panic: rtfree 2 (using RADIX_MPATH in a VNET jail) >> >Arrival-Date: Sun Dec 22 13:10:00 UTC 2013 >> > > I'm trying to understand exactly what is happening here, and examining a > core dump with kgdb I'm getting some output that confuses me : > > (kgdb) bt > #0 doadump (textdump=3D-1011569920) at pcpu.h:233 > #1 0xc06069b2 in kern_reboot (howto=3D260) at > /usr/src/sys/kern/kern_shutdown.c:447 > #2 0xc0606d0e in panic (fmt=3D) at > /usr/src/sys/kern/kern_shutdown.c:754 > #3 0xc06de639 in rtfree (rt=3D) at > /usr/src/sys/net/route.c:464 > #4 0xc06e188d in route_output (m=3D) at > /usr/src/sys/net/rtsock.c:951 > #5 0xc06de18f in raw_usend (so=3D, flags=3D0, m=3D<= value > optimized out>, nam=3D0x0, control=3D, > td=3D0xc3bd2000) at /usr/src/sys/net/raw_usrreq.c:238 > #6 0xc066eca9 in sosend_generic (so=3D0xc3e9c1a8, uio=3D out>, top=3D, control=3D0x0, > flags=3D, td=3D) at > /usr/src/sys/kern/uipc_socket.c:1271 > #7 0xc066efc7 in sosend (so=3D0xc3e9c1a8, addr=3D0x0, uio=3D0xd9b9cc10, > top=3D0x0, control=3D0x0, flags=3D0, td=3D0xc3bd2000) > at /usr/src/sys/kern/uipc_socket.c:1315 > #8 0xc0654af4 in soo_write (fp=3D0xc3c0c818, uio=3D0xd9b9cc10, > active_cred=3D0xc3f1dd00, flags=3D0, td=3D0xc3bd2000) > at /usr/src/sys/kern/sys_socket.c:103 > #9 0xc064c866 in dofilewrite (td=3D0xc3bd2000, fd=3D3, fp=3D0xc3c0c818, > auio=3D0xd9b9cc10, offset=3D-1, flags=3D0) at file.h:303 > #10 0xc064c566 in kern_writev (td=3D0xc3bd2000, fd=3D3, auio=3D out>) at /usr/src/sys/kern/sys_generic.c:467 > #11 0xc064c4bc in sys_write (td=3D, uap=3D optimized out>) at /usr/src/sys/kern/sys_generic.c:382 > #12 0xc08614d3 in syscall (frame=3D) at > subr_syscall.c:134 > #13 0xc084cca1 in Xint0x80_syscall () at > /usr/src/sys/i386/i386/exception.s:270 > #14 0x281975b7 in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > (kgdb) fr 3 > #3 0xc06de639 in rtfree (rt=3D) at > /usr/src/sys/net/route.c:464 > 464 panic("rtfree 2"); > (kgdb) print *rt > $1 =3D {rt_nodes =3D {{rn_mklist =3D 0xc3b4ab30, rn_parent =3D 0x1, rn_bi= t =3D 0, > rn_bmask =3D 0 '\0', rn_flags =3D 0 '\0', rn_u =3D {rn_leaf =3D { > rn_Key =3D 0xc0882687 "shutdown_post_sync", rn_Mask =3D 0x10300= 00 >
, rn_Dupedkey =3D 0x0}, rn_node =3D { > rn_Off =3D -1064819065, rn_L =3D 0x1030000, rn_R =3D 0x0}}}, > {rn_mklist =3D 0x0, rn_parent =3D 0x4, rn_bit =3D -18048, rn_bmask =3D -9= 4 '?', > rn_flags =3D 195 '?', rn_u =3D {rn_leaf =3D {rn_Key =3D 0xc3a545e0 = "", > rn_Mask =3D 0xc3a4e440 " ??(???\020'", rn_Dupedkey =3D 0xc3a4e880}, > rn_node =3D {rn_Off =3D -1012578848, rn_L =3D 0xc3a4e440, rn_R = =3D > 0xc3a4e880}}}}, rt_gateway =3D 0x74756873, rt_flags =3D 1853321060, > rt_refcnt =3D 1936683103, rt_ifp =3D 0x79735f74, rt_ifa =3D 0x636e, rt_= rmx =3D > {rmx_mtu =3D 0, rmx_expire =3D 0, rmx_pksent =3D 0, rmx_weight =3D 0}, > rt_fibnum =3D 0, rt_mtx =3D {lock_object =3D {lo_name =3D 0x0, lo_flags= =3D 0, > lo_data =3D 0, lo_witness =3D 0x0}, mtx_lock =3D 0}} > > > > rn_Key with value of =93shutdown_post_sync=94 ? > > It=92s visible also in the raw_usend() frame: > > (kgdb) fr 5 > #5 0xc06de18f in raw_usend (so=3D, flags=3D0, m=3D<= value > optimized out>, nam=3D0x0, control=3D, > td=3D0xc3bd2000) at /usr/src/sys/net/raw_usrreq.c:238 > 238 return ((*so->so_proto->pr_output)(m, so)); > (kgdb) print *m > $2 =3D {m_hdr =3D {mh_next =3D 0xc3b4ab30, mh_nextpkt =3D 0x1, mh_data = =3D 0x0, > mh_len =3D -1064819065, mh_type =3D 0, mh_flags =3D 66304, mh_pad =3D 0}, > M_dat =3D {MH =3D {MH_pkthdr =3D {rcvif =3D 0x0, tags =3D {slh_first = =3D 0x4}, len =3D > -1012745856, flowid =3D 3282388448, > csum_flags =3D 14097648373312316480, fibnum =3D 26739, cosqos =3D= 117 > 'u', rsstype =3D 116 't', l2hlen =3D 100 'd', l3hlen =3D 111 'o', > l4hlen =3D 119 'w', l5hlen =3D 110 'n', PH_per =3D {eigth =3D "_p= ost_sy", > sixteen =3D {28767, 29551, 24436, 31091}, thirtytwo =3D {1936683103, > 2037604212}, sixtyfour =3D {8751443454668533855}, unintptr = =3D > {1936683103}, ptr =3D 0x736f705f}, PH_loc =3D { > eigth =3D "nc\000\000\000\000\000", sixteen =3D {25454, 0, 0, 0= }, > thirtytwo =3D {25454, 0}, sixtyfour =3D {25454}, unintptr =3D {25454}, > ptr =3D 0x636e}}, MH_dat =3D {MH_ext =3D {ref_cnt =3D 0x0, ext_= buf =3D > 0x0, ext_size =3D 0, ext_type =3D 0, ext_flags =3D 0, ext_free =3D 0, > ext_arg1 =3D 0x0, ext_arg2 =3D 0x0}, > MH_databuf =3D '\0' , "file", '\0' times>, > "\006\000\000\000\020\000\000\000??\215?\000\000C\001\000\000\000\000\000= \000\000\000\004\000\000\000\000\000\000\00000Y?", > '\0' , > "`2Y?\000\000\000\000\000\000\000\000T\211\223?\022\000\000\000\000\203??= \000\000\000\000\000???", > '\0' }}, > M_databuf =3D > "\000\000\000\000\004\000\000\000\200????E??@??\200??shutdown_post_sync", > '\0' , "file", '\0' , > "\006\000\000\000\020\000\000\000??\215?\000\000C\001\000\000\000\000\000= \000\000\000\004\000\000\000\000\000\000\00000Y?", > '\0' , > "`2Y?\000\000\000\000\000\000\000\000T\211\223?\022\000\000\000\000\203??= \000\000\000\000\000???", > '\0' }} > > > This is 10.0-PRERELEASE r259547M (with applied the recent nd6_nbr.c rtfre= e > patch, which I thought earlier might be the cause of the panics I'm > seeing). > > The machine is Soekris Net5501-70 with this kernel config : > > cpu I586_CPU > cpu I686_CPU > ident MARS > options CPU_GEODE > options CPU_SOEKRIS > > options HZ=3D2000 > options DEVICE_POLLING > options BPF_JITTER > > makeoptions DEBUG=3D-g # Build kernel with gdb(1) debug symbols > > options SCHED_ULE # ULE scheduler > options PREEMPTION # Enable kernel thread preemption > options INET # InterNETworking > options INET6 # IPv6 communications protocols > options TCP_OFFLOAD # TCP offload > options FFS # Berkeley Fast Filesystem > options SOFTUPDATES # Enable FFS soft updates support > options UFS_DIRHASH # Improve performance on big directories > options PROCFS # Process filesystem (requires PSEUDOFS) > options PSEUDOFS # Pseudo-filesystem framework > options GEOM_PART_GPT # GUID Partition Tables. > options GEOM_LABEL # Provides labelization > options COMPAT_FREEBSD4 # Compatible with FreeBSD4 > options COMPAT_FREEBSD5 # Compatible with FreeBSD5 > options COMPAT_FREEBSD6 # Compatible with FreeBSD6 > options COMPAT_FREEBSD7 # Compatible with FreeBSD7 > options SCSI_DELAY=3D500 # Delay (in ms) before probing SCSI > options KTRACE # ktrace(1) support > options STACK # stack(9) support > options SYSVSHM # SYSV-style shared memory > options SYSVMSG # SYSV-style message queues > options SYSVSEM # SYSV-style semaphores > options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions > options PRINTF_BUFR_SIZE=3D128 # Prevent printf output being interspersed= . > options KBD_INSTALL_CDEV # install a CDEV entry in /dev > options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) > options CAPABILITY_MODE # Capsicum capability mode > options CAPABILITIES # Capsicum capabilities > options PROCDESC # Support for process descriptors > options INCLUDE_CONFIG_FILE # Include this file in kernel > > # Debugging support. Always need this: > options KDB # Enable kernel debugger support. > options KDB_TRACE # Print a stack trace for a panic. > options KDB_UNATTENDED > > options TEXTDUMP_PREFERRED > options TEXTDUMP_VERBOSE > > device pci > device ata # Legacy ATA/SATA controllers > options ATA_STATIC_ID # Static device numbering > > # ATA/SCSI peripherals > device scbus # SCSI bus (required for ATA/SCSI) > device da # Direct Access (disks) > device pass # Passthrough device (direct ATA/SCSI access) > > # Add suspend/resume support for the i8254. > device pmtimer > > # Serial (COM) ports > device uart # Generic UART driver > > device miibus # MII bus support > device vr # VIA Rhine, Rhine II > > # Wireless NIC cards > device wlan # 802.11 support > options IEEE80211_DEBUG # enable debug msgs > options IEEE80211_AMPDU_AGE # age frames in AMPDU reorder q's > options IEEE80211_SUPPORT_MESH # enable 802.11s draft support > device wlan_wep # 802.11 WEP support > device wlan_ccmp # 802.11 CCMP support > device wlan_tkip # 802.11 TKIP support > device wlan_amrr # AMRR transmit rate control algorithm > device ath # Atheros NICs > device ath_pci # Atheros pci/cardbus glue > device ath_hal # pci/cardbus chip support > options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors > options AH_AR5416_INTERRUPT_MITIGATION # AR5416 interrupt mitigation > options ATH_ENABLE_11N # Enable 802.11n support for AR5416 and later > device ath_rate_sample # SampleRate tx rate control for ath > > # Pseudo devices. > device loop # Network loopback > device random # Entropy device > device ether # Ethernet support > device vlan # 802.1Q VLAN support > device tun # Packet tunnel. > device md # Memory "disks" > device gif # IPv6 and IPv4 tunneling > device gre > device faith # IPv6-to-IPv4 relaying (translation) > device firmware # firmware assist module > device if_bridge > > options VIMAGE > options ROUTETABLES=3D8 > options RADIX_MPATH > > options SW_WATCHDOG > > device crypto > device cryptodev > device glxsb > > options BOOTVERBOSE=3D1 > > #device pf > #device pflog > #device pfsync > device carp > device enc > device lagg > device epair > > #options ALTQ > #options ALTQ_CBQ > #options ALTQ_RED > #options ALTQ_RIO > #options ALTQ_HFSC > #options ALTQ_PRIQ > > options IPFIREWALL > options IPFIREWALL_DEFAULT_TO_ACCEPT > options IPFIREWALL_NAT > options LIBALIAS > options IPDIVERT > options DUMMYNET > > device bpf # Berkeley packet filter > > # USB support > options USB_DEBUG # enable debug msgs > device uhci # UHCI PCI->USB interface > device ohci # OHCI PCI->USB interface > device ehci # EHCI PCI->USB interface (USB 2.0) > device usb # USB Bus (required) > device umass # Disks/Mass storage - Requires scbus and da > > > Also src.conf and make.conf : > > root@vpn_vrf:[VNET(x)]:/usr/src/sys # cat /etc/src.conf > WITHOUT_ACCT=3Dyes > WITHOUT_ACPI=3Dyes > WITHOUT_AMD=3Dyes > WITHOUT_APM=3Dyes > WITHOUT_ASSERT_DEBUG=3Dyes > WITHOUT_AT=3Dyes > WITHOUT_ATF=3Dyes > WITHOUT_ATM=3Dyes > WITHOUT_AUDIT=3Dyes > WITHOUT_BLUETOOTH=3Dyes > WITHOUT_CALENDAR=3Dyes > WITHOUT_CDDL=3Dyes > WITHOUT_CTM=3Dyes > WITHOUT_DICT=3Dyes > WITHOUT_FLOPPY=3Dyes > WITHOUT_GAMES=3Dyes > WITHOUT_HTML=3Dyes > WITHOUT_INFO=3Dyes > WITHOUT_IPFILTER=3Dyes > WITHOUT_IPX=3Dyes > #WITHOUT_KERNEL_SYMBOLS=3Dyes > WITHOUT_LEGACY_CONSOLE=3Dyes > WITHOUT_LOCALES=3Dyes > WITHOUT_LPR=3Dyes > WITHOUT_MAIL=3Dyes > WITHOUT_NDIS=3Dyes > WITHOUT_QUOTAS=3Dyes > WITHOUT_ROUTED=3Dyes > WITHOUT_SENDMAIL=3Dyes > WITH_SVN=3Dyes > WITHOUT_ZFS=3Dyes > > root@vpn_vrf:[VNET(x)]:/usr/src/sys # cat /etc/make.conf > CFLAGS=3D-O2 > COPTFLAGS=3D -O -pipe > CPUTYPE=3Dgeode > KERNCONF=3DMARS > NO_MODULES=3Dyes > BOOTWAIT=3D0 > DOC_LANG=3Den_US.ISO8859-1 > > > > --Nikolay > > Also, originally I thought that the panic is when a multi path route is being deleted, however again from the coredump it seems that the panic happens when openvpn deletes the host route it installs for the remote openvpn server pointed to the default gw (before openvpn installs the new default gw pointing to the vpn tunnel) : (kgdb) fr 12 (kgdb) x/12sb td->td_proc->p_args 0xc4269780: "\001" 0xc4269782: "" 0xc4269783: "" 0xc4269784: "B" 0xc4269786: "" 0xc4269787: "" 0xc4269788: "/sbin/route" 0xc4269794: "delete" 0xc426979b: "-net" 0xc42697a0: "78.90.222.xxx" 0xc42697ad: "10.255.255.0" 0xc42697ba: "255.255.255.255" (kgdb) I'm trying to reproduce this on a VirtualBox instance now, however so far no luck (no OpenVPN running, just adding and removing routes). --Nikolay From owner-freebsd-net@FreeBSD.ORG Wed Jan 1 17:39:46 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 568EB76E; Wed, 1 Jan 2014 17:39:46 +0000 (UTC) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 678541672; Wed, 1 Jan 2014 17:39:45 +0000 (UTC) Received: by mail-lb0-f175.google.com with SMTP id w6so6739657lbh.6 for ; Wed, 01 Jan 2014 09:39:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=kZvagYU709K9yZsz2Pe+lQ+hSIQH14qASTUFA3w2Hcg=; b=I3ICXmwx+ODDr6YyvL1WTd5bGGTn8e5M4/L6gGQIzRyVYynI8FD1+SRMVi+mBsy0o6 Yzymh7zK92qLKa87OWrFGvNCDpn2AOcklge787qXH+u2qZyq1BcgUF/OLG4EwY8gUf4G 8HEZQaQjUhLNnUyknN9oEO+dE/8IcBgjMPU3Z/23On2kLrD3a0yrQFosCDufb4SyUlIQ +vvKq4T4fAdUTShWpPy33RkBvg67WjMcjESHkR+goPkPq5blgKIHuyUJcdrcDzE0hXNf fOvMnpikZ9N2BBnXazIoEHfI9vGd9DOcwfaw0HKndMoMaioUhIhsOD4Uz+OrdpPAzu0c 7T3w== MIME-Version: 1.0 X-Received: by 10.152.23.39 with SMTP id j7mr19871082laf.28.1388597982231; Wed, 01 Jan 2014 09:39:42 -0800 (PST) Received: by 10.114.242.33 with HTTP; Wed, 1 Jan 2014 09:39:42 -0800 (PST) In-Reply-To: References: <201312221304.rBMD4q38060416@oldred.freebsd.org> <201312221310.rBMDA0KH022980@freefall.freebsd.org> Date: Wed, 1 Jan 2014 17:39:42 +0000 Message-ID: Subject: Re: misc/185092: panic: rtfree 2 (using RADIX_MPATH in a VNET jail) From: Nikolay Denev To: FreeBSD-gnats-submit@freebsd.org, freebsd-bugs@freebsd.org, "freebsd-net@freebsd.org" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 17:39:46 -0000 Ok, killing openvpn with -9 leaves the routes around, and particularly interesting are the following routes : 78.90.222.xx 10.255.255.0 UGHS 0 5841 epair0 =3D= > 78.90.222.xx/32 10.255.255.0 UGS 0 0 epair0 Now, if I do : route delete 78.90.222.xx 10.255.255.0 The route, with the H flag is deleted. If I repeat the command the second route is deleted as well, even if the second command specifies a netmask no panic. However the first delete command specifies the /32 mask like this : route delete 78.90.222.xx 10.255.255.0 255.255.255.255 Then I get "rtfree 2" kernel panic immediately. This seems to be happening as I'm manually installing static routes in the vnet jail for the VPN remote endpoints , however OpenVPN adds such routes too however differently, which results in two routing entries. For example : route add $IP $GW and route add $IP $GW 255.255.255.255 add to different route entries, one is /32 network, the other is a host rou= te. --Nikolay On Wed, Jan 1, 2014 at 1:21 PM, Nikolay Denev wrote: > On Wed, Jan 1, 2014 at 1:10 PM, Nikolay Denev wrote: >> >> On Sun, Dec 22, 2013 at 1:10 PM, wrot= e: >>> >>> Thank you very much for your problem report. >>> It has the internal identification `misc/185092'. >>> The individual assigned to look at your >>> report is: freebsd-bugs. >>> >>> You can access the state of your problem report at any time >>> via this link: >>> >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D185092 >>> >>> >Category: misc >>> >Responsible: freebsd-bugs >>> >Synopsis: panic: rtfree 2 (using RADIX_MPATH in a VNET jail) >>> >Arrival-Date: Sun Dec 22 13:10:00 UTC 2013 >> >> >> I'm trying to understand exactly what is happening here, and examining a >> core dump with kgdb I'm getting some output that confuses me : >> >> (kgdb) bt >> #0 doadump (textdump=3D-1011569920) at pcpu.h:233 >> #1 0xc06069b2 in kern_reboot (howto=3D260) at >> /usr/src/sys/kern/kern_shutdown.c:447 >> #2 0xc0606d0e in panic (fmt=3D) at >> /usr/src/sys/kern/kern_shutdown.c:754 >> #3 0xc06de639 in rtfree (rt=3D) at >> /usr/src/sys/net/route.c:464 >> #4 0xc06e188d in route_output (m=3D) at >> /usr/src/sys/net/rtsock.c:951 >> #5 0xc06de18f in raw_usend (so=3D, flags=3D0, m=3D= > optimized out>, nam=3D0x0, control=3D, >> td=3D0xc3bd2000) at /usr/src/sys/net/raw_usrreq.c:238 >> #6 0xc066eca9 in sosend_generic (so=3D0xc3e9c1a8, uio=3D> out>, top=3D, control=3D0x0, >> flags=3D, td=3D) at >> /usr/src/sys/kern/uipc_socket.c:1271 >> #7 0xc066efc7 in sosend (so=3D0xc3e9c1a8, addr=3D0x0, uio=3D0xd9b9cc10, >> top=3D0x0, control=3D0x0, flags=3D0, td=3D0xc3bd2000) >> at /usr/src/sys/kern/uipc_socket.c:1315 >> #8 0xc0654af4 in soo_write (fp=3D0xc3c0c818, uio=3D0xd9b9cc10, >> active_cred=3D0xc3f1dd00, flags=3D0, td=3D0xc3bd2000) >> at /usr/src/sys/kern/sys_socket.c:103 >> #9 0xc064c866 in dofilewrite (td=3D0xc3bd2000, fd=3D3, fp=3D0xc3c0c818, >> auio=3D0xd9b9cc10, offset=3D-1, flags=3D0) at file.h:303 >> #10 0xc064c566 in kern_writev (td=3D0xc3bd2000, fd=3D3, auio=3D> out>) at /usr/src/sys/kern/sys_generic.c:467 >> #11 0xc064c4bc in sys_write (td=3D, uap=3D> optimized out>) at /usr/src/sys/kern/sys_generic.c:382 >> #12 0xc08614d3 in syscall (frame=3D) at >> subr_syscall.c:134 >> #13 0xc084cca1 in Xint0x80_syscall () at >> /usr/src/sys/i386/i386/exception.s:270 >> #14 0x281975b7 in ?? () >> Previous frame inner to this frame (corrupt stack?) >> Current language: auto; currently minimal >> (kgdb) fr 3 >> #3 0xc06de639 in rtfree (rt=3D) at >> /usr/src/sys/net/route.c:464 >> 464 panic("rtfree 2"); >> (kgdb) print *rt >> $1 =3D {rt_nodes =3D {{rn_mklist =3D 0xc3b4ab30, rn_parent =3D 0x1, rn_b= it =3D 0, >> rn_bmask =3D 0 '\0', rn_flags =3D 0 '\0', rn_u =3D {rn_leaf =3D { >> rn_Key =3D 0xc0882687 "shutdown_post_sync", rn_Mask =3D 0x1030= 000 >>
, rn_Dupedkey =3D 0x0}, rn_node =3D { >> rn_Off =3D -1064819065, rn_L =3D 0x1030000, rn_R =3D 0x0}}}, >> {rn_mklist =3D 0x0, rn_parent =3D 0x4, rn_bit =3D -18048, rn_bmask =3D -= 94 '?', >> rn_flags =3D 195 '?', rn_u =3D {rn_leaf =3D {rn_Key =3D 0xc3a545e0= "", >> rn_Mask =3D 0xc3a4e440 " ??(???\020'", rn_Dupedkey =3D 0xc3a4e880}, >> rn_node =3D {rn_Off =3D -1012578848, rn_L =3D 0xc3a4e440, rn_R = =3D >> 0xc3a4e880}}}}, rt_gateway =3D 0x74756873, rt_flags =3D 1853321060, >> rt_refcnt =3D 1936683103, rt_ifp =3D 0x79735f74, rt_ifa =3D 0x636e, rt= _rmx =3D >> {rmx_mtu =3D 0, rmx_expire =3D 0, rmx_pksent =3D 0, rmx_weight =3D 0}, >> rt_fibnum =3D 0, rt_mtx =3D {lock_object =3D {lo_name =3D 0x0, lo_flag= s =3D 0, >> lo_data =3D 0, lo_witness =3D 0x0}, mtx_lock =3D 0}} >> >> >> >> rn_Key with value of =93shutdown_post_sync=94 ? >> >> It=92s visible also in the raw_usend() frame: >> >> (kgdb) fr 5 >> #5 0xc06de18f in raw_usend (so=3D, flags=3D0, m=3D= > optimized out>, nam=3D0x0, control=3D, >> td=3D0xc3bd2000) at /usr/src/sys/net/raw_usrreq.c:238 >> 238 return ((*so->so_proto->pr_output)(m, so)); >> (kgdb) print *m >> $2 =3D {m_hdr =3D {mh_next =3D 0xc3b4ab30, mh_nextpkt =3D 0x1, mh_data = =3D 0x0, >> mh_len =3D -1064819065, mh_type =3D 0, mh_flags =3D 66304, mh_pad =3D 0}= , >> M_dat =3D {MH =3D {MH_pkthdr =3D {rcvif =3D 0x0, tags =3D {slh_first = =3D 0x4}, len =3D >> -1012745856, flowid =3D 3282388448, >> csum_flags =3D 14097648373312316480, fibnum =3D 26739, cosqos = =3D 117 >> 'u', rsstype =3D 116 't', l2hlen =3D 100 'd', l3hlen =3D 111 'o', >> l4hlen =3D 119 'w', l5hlen =3D 110 'n', PH_per =3D {eigth =3D "_= post_sy", >> sixteen =3D {28767, 29551, 24436, 31091}, thirtytwo =3D {1936683103, >> 2037604212}, sixtyfour =3D {8751443454668533855}, unintptr = =3D >> {1936683103}, ptr =3D 0x736f705f}, PH_loc =3D { >> eigth =3D "nc\000\000\000\000\000", sixteen =3D {25454, 0, 0, = 0}, >> thirtytwo =3D {25454, 0}, sixtyfour =3D {25454}, unintptr =3D {25454}, >> ptr =3D 0x636e}}, MH_dat =3D {MH_ext =3D {ref_cnt =3D 0x0, ext= _buf =3D >> 0x0, ext_size =3D 0, ext_type =3D 0, ext_flags =3D 0, ext_free =3D 0, >> ext_arg1 =3D 0x0, ext_arg2 =3D 0x0}, >> MH_databuf =3D '\0' , "file", '\0' > times>, >> "\006\000\000\000\020\000\000\000??\215?\000\000C\001\000\000\000\000\00= 0\000\000\000\004\000\000\000\000\000\000\00000Y?", >> '\0' , >> "`2Y?\000\000\000\000\000\000\000\000T\211\223?\022\000\000\000\000\203?= ?\000\000\000\000\000???", >> '\0' }}, >> M_databuf =3D >> "\000\000\000\000\004\000\000\000\200????E??@??\200??shutdown_post_sync"= , >> '\0' , "file", '\0' , >> "\006\000\000\000\020\000\000\000??\215?\000\000C\001\000\000\000\000\00= 0\000\000\000\004\000\000\000\000\000\000\00000Y?", >> '\0' , >> "`2Y?\000\000\000\000\000\000\000\000T\211\223?\022\000\000\000\000\203?= ?\000\000\000\000\000???", >> '\0' }} >> >> >> This is 10.0-PRERELEASE r259547M (with applied the recent nd6_nbr.c rtfr= ee >> patch, which I thought earlier might be the cause of the panics I'm >> seeing). >> >> The machine is Soekris Net5501-70 with this kernel config : >> >> cpu I586_CPU >> cpu I686_CPU >> ident MARS >> options CPU_GEODE >> options CPU_SOEKRIS >> >> options HZ=3D2000 >> options DEVICE_POLLING >> options BPF_JITTER >> >> makeoptions DEBUG=3D-g # Build kernel with gdb(1) debug symbols >> >> options SCHED_ULE # ULE scheduler >> options PREEMPTION # Enable kernel thread preemption >> options INET # InterNETworking >> options INET6 # IPv6 communications protocols >> options TCP_OFFLOAD # TCP offload >> options FFS # Berkeley Fast Filesystem >> options SOFTUPDATES # Enable FFS soft updates support >> options UFS_DIRHASH # Improve performance on big directories >> options PROCFS # Process filesystem (requires PSEUDOFS) >> options PSEUDOFS # Pseudo-filesystem framework >> options GEOM_PART_GPT # GUID Partition Tables. >> options GEOM_LABEL # Provides labelization >> options COMPAT_FREEBSD4 # Compatible with FreeBSD4 >> options COMPAT_FREEBSD5 # Compatible with FreeBSD5 >> options COMPAT_FREEBSD6 # Compatible with FreeBSD6 >> options COMPAT_FREEBSD7 # Compatible with FreeBSD7 >> options SCSI_DELAY=3D500 # Delay (in ms) before probing SCSI >> options KTRACE # ktrace(1) support >> options STACK # stack(9) support >> options SYSVSHM # SYSV-style shared memory >> options SYSVMSG # SYSV-style message queues >> options SYSVSEM # SYSV-style semaphores >> options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extension= s >> options PRINTF_BUFR_SIZE=3D128 # Prevent printf output being intersperse= d. >> options KBD_INSTALL_CDEV # install a CDEV entry in /dev >> options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) >> options CAPABILITY_MODE # Capsicum capability mode >> options CAPABILITIES # Capsicum capabilities >> options PROCDESC # Support for process descriptors >> options INCLUDE_CONFIG_FILE # Include this file in kernel >> >> # Debugging support. Always need this: >> options KDB # Enable kernel debugger support. >> options KDB_TRACE # Print a stack trace for a panic. >> options KDB_UNATTENDED >> >> options TEXTDUMP_PREFERRED >> options TEXTDUMP_VERBOSE >> >> device pci >> device ata # Legacy ATA/SATA controllers >> options ATA_STATIC_ID # Static device numbering >> >> # ATA/SCSI peripherals >> device scbus # SCSI bus (required for ATA/SCSI) >> device da # Direct Access (disks) >> device pass # Passthrough device (direct ATA/SCSI access) >> >> # Add suspend/resume support for the i8254. >> device pmtimer >> >> # Serial (COM) ports >> device uart # Generic UART driver >> >> device miibus # MII bus support >> device vr # VIA Rhine, Rhine II >> >> # Wireless NIC cards >> device wlan # 802.11 support >> options IEEE80211_DEBUG # enable debug msgs >> options IEEE80211_AMPDU_AGE # age frames in AMPDU reorder q's >> options IEEE80211_SUPPORT_MESH # enable 802.11s draft support >> device wlan_wep # 802.11 WEP support >> device wlan_ccmp # 802.11 CCMP support >> device wlan_tkip # 802.11 TKIP support >> device wlan_amrr # AMRR transmit rate control algorithm >> device ath # Atheros NICs >> device ath_pci # Atheros pci/cardbus glue >> device ath_hal # pci/cardbus chip support >> options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors >> options AH_AR5416_INTERRUPT_MITIGATION # AR5416 interrupt mitigation >> options ATH_ENABLE_11N # Enable 802.11n support for AR5416 and later >> device ath_rate_sample # SampleRate tx rate control for ath >> >> # Pseudo devices. >> device loop # Network loopback >> device random # Entropy device >> device ether # Ethernet support >> device vlan # 802.1Q VLAN support >> device tun # Packet tunnel. >> device md # Memory "disks" >> device gif # IPv6 and IPv4 tunneling >> device gre >> device faith # IPv6-to-IPv4 relaying (translation) >> device firmware # firmware assist module >> device if_bridge >> >> options VIMAGE >> options ROUTETABLES=3D8 >> options RADIX_MPATH >> >> options SW_WATCHDOG >> >> device crypto >> device cryptodev >> device glxsb >> >> options BOOTVERBOSE=3D1 >> >> #device pf >> #device pflog >> #device pfsync >> device carp >> device enc >> device lagg >> device epair >> >> #options ALTQ >> #options ALTQ_CBQ >> #options ALTQ_RED >> #options ALTQ_RIO >> #options ALTQ_HFSC >> #options ALTQ_PRIQ >> >> options IPFIREWALL >> options IPFIREWALL_DEFAULT_TO_ACCEPT >> options IPFIREWALL_NAT >> options LIBALIAS >> options IPDIVERT >> options DUMMYNET >> >> device bpf # Berkeley packet filter >> >> # USB support >> options USB_DEBUG # enable debug msgs >> device uhci # UHCI PCI->USB interface >> device ohci # OHCI PCI->USB interface >> device ehci # EHCI PCI->USB interface (USB 2.0) >> device usb # USB Bus (required) >> device umass # Disks/Mass storage - Requires scbus and da >> >> >> Also src.conf and make.conf : >> >> root@vpn_vrf:[VNET(x)]:/usr/src/sys # cat /etc/src.conf >> WITHOUT_ACCT=3Dyes >> WITHOUT_ACPI=3Dyes >> WITHOUT_AMD=3Dyes >> WITHOUT_APM=3Dyes >> WITHOUT_ASSERT_DEBUG=3Dyes >> WITHOUT_AT=3Dyes >> WITHOUT_ATF=3Dyes >> WITHOUT_ATM=3Dyes >> WITHOUT_AUDIT=3Dyes >> WITHOUT_BLUETOOTH=3Dyes >> WITHOUT_CALENDAR=3Dyes >> WITHOUT_CDDL=3Dyes >> WITHOUT_CTM=3Dyes >> WITHOUT_DICT=3Dyes >> WITHOUT_FLOPPY=3Dyes >> WITHOUT_GAMES=3Dyes >> WITHOUT_HTML=3Dyes >> WITHOUT_INFO=3Dyes >> WITHOUT_IPFILTER=3Dyes >> WITHOUT_IPX=3Dyes >> #WITHOUT_KERNEL_SYMBOLS=3Dyes >> WITHOUT_LEGACY_CONSOLE=3Dyes >> WITHOUT_LOCALES=3Dyes >> WITHOUT_LPR=3Dyes >> WITHOUT_MAIL=3Dyes >> WITHOUT_NDIS=3Dyes >> WITHOUT_QUOTAS=3Dyes >> WITHOUT_ROUTED=3Dyes >> WITHOUT_SENDMAIL=3Dyes >> WITH_SVN=3Dyes >> WITHOUT_ZFS=3Dyes >> >> root@vpn_vrf:[VNET(x)]:/usr/src/sys # cat /etc/make.conf >> CFLAGS=3D-O2 >> COPTFLAGS=3D -O -pipe >> CPUTYPE=3Dgeode >> KERNCONF=3DMARS >> NO_MODULES=3Dyes >> BOOTWAIT=3D0 >> DOC_LANG=3Den_US.ISO8859-1 >> >> >> >> --Nikolay >> > > Also, originally I thought that the panic is when a multi path route is > being deleted, however again from the coredump it seems that the panic > happens when openvpn deletes the host route it installs for the remote > openvpn server pointed to the default gw (before openvpn installs the new > default gw pointing to the vpn tunnel) : > > (kgdb) fr 12 > (kgdb) x/12sb td->td_proc->p_args > 0xc4269780: "\001" > 0xc4269782: "" > 0xc4269783: "" > 0xc4269784: "B" > 0xc4269786: "" > 0xc4269787: "" > 0xc4269788: "/sbin/route" > 0xc4269794: "delete" > 0xc426979b: "-net" > 0xc42697a0: "78.90.222.xxx" > 0xc42697ad: "10.255.255.0" > 0xc42697ba: "255.255.255.255" > (kgdb) > > I'm trying to reproduce this on a VirtualBox instance now, however so far= no > luck (no OpenVPN running, just adding and removing routes). > > > --Nikolay From owner-freebsd-net@FreeBSD.ORG Wed Jan 1 20:03:06 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D28584F for ; Wed, 1 Jan 2014 20:03:06 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 401461120 for ; Wed, 1 Jan 2014 20:03:05 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s01K342n002845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jan 2014 12:03:05 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s01K347f002844; Wed, 1 Jan 2014 12:03:04 -0800 (PST) (envelope-from jmg) Date: Wed, 1 Jan 2014 12:03:04 -0800 From: John-Mark Gurney To: Peter Jeremy Subject: Re: IPv4 Multicast MAC Address issues Message-ID: <20140101200303.GS99167@funkthat.com> Mail-Followup-To: Peter Jeremy , freebsd-net@freebsd.org References: <20140101085721.GA34334@server.rulingia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140101085721.GA34334@server.rulingia.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 01 Jan 2014 12:03:05 -0800 (PST) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 20:03:06 -0000 Peter Jeremy wrote this message on Wed, Jan 01, 2014 at 19:57 +1100: > I'm trying to use multicast on my home network for the first time and > have found an apparent anomoly in the destination MAC address. > > My reading of RFC1112 section 6.4 is that the the destination MAC > address uses the low 23 bits of the destination (multicast) IP > address. This is what Linux and Windows do and ifmcstat(8) on > FreeBSD shows that as the multicast MAC filter. Unfortunately, it > seems that (at least on FreeBSD-10), the destination MAC address > uses the low 23 bits of the IP address of my default route. > > I am not doing any special multicast-related configuration on any > of the hosts and have been using ping(8) to generate multicast > packets. > > Does FreeBSD need special configuration to support multicast or is this > a bug? This is probably a bug, and I have confirmed this on: FreeBSD carbon.funkthat.com 11.0-CURRENT FreeBSD 11.0-CURRENT #4 r256870:258399M: Wed Nov 20 12:33:22 PST 2013 jmg@carbon.funkthat.com:/usr/src/sys/amd64/compile/lockprof amd64 [jmg@carbon ~]$ echo foobar | nc -u 239.100.100.100 3845 sldkfjsdlfkj # tcpdump -i re0 -n -e port 3845 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on re0, link-type EN10MB (Ethernet), capture size 65535 bytes capability mode sandbox enabled 11:59:03.998008 xx:xx:xx:xx:xx:xx > 01:00:5e:28:00:0e, ethertype IPv4 (0x0800), length 49: 192.168.0.21.15921 > 239.100.100.100.3845: UDP, length 7 -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Thu Jan 2 06:44:08 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B220425 for ; Thu, 2 Jan 2014 06:44:08 +0000 (UTC) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8C10F1A69 for ; Thu, 2 Jan 2014 06:44:07 +0000 (UTC) Received: from server.rulingia.com (c220-239-250-249.belrs5.nsw.optusnet.com.au [220.239.250.249]) by vps.rulingia.com (8.14.7/8.14.7) with ESMTP id s026i15w027393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 2 Jan 2014 17:44:02 +1100 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.7/8.14.7) with ESMTP id s026hu62073534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 2 Jan 2014 17:43:56 +1100 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.7/8.14.7/Submit) id s026humu073533 for freebsd-net@freebsd.org; Thu, 2 Jan 2014 17:43:56 +1100 (EST) (envelope-from peter) Date: Thu, 2 Jan 2014 17:43:56 +1100 From: Peter Jeremy To: freebsd-net@freebsd.org Subject: Re: IPv4 Multicast MAC Address issues Message-ID: <20140102064356.GL87348@server.rulingia.com> References: <20140101085721.GA34334@server.rulingia.com> <20140101200303.GS99167@funkthat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0eh6TmSyL6TZE2Uz" Content-Disposition: inline In-Reply-To: <20140101200303.GS99167@funkthat.com> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 06:44:08 -0000 --0eh6TmSyL6TZE2Uz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2014-Jan-01 12:03:04 -0800, John-Mark Gurney wrote: >Peter Jeremy wrote this message on Wed, Jan 01, 2014 at 19:57 +1100: >> I'm trying to use multicast on my home network for the first time and >> have found an apparent anomoly in the destination MAC address. =2E.. >> FreeBSD shows that as the multicast MAC filter. Unfortunately, it >> seems that (at least on FreeBSD-10), the destination MAC address >> uses the low 23 bits of the IP address of my default route. >This is probably a bug, and I have confirmed this on: >FreeBSD carbon.funkthat.com 11.0-CURRENT FreeBSD 11.0-CURRENT #4 r256870:2= 58399M: Wed Nov 20 12:33:22 PST 2013 jmg@carbon.funkthat.com:/usr/src/s= ys/amd64/compile/lockprof amd64 Thanks. I've since checked 9.2/amd64 and it's OK there, so this is a regression. I've raised kern/185395. --=20 Peter Jeremy --0eh6TmSyL6TZE2Uz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iKYEARECAGYFAlLFCqxfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDBCRjc3QTcyNTg5NEVCRTY0RjREN0VFRUZF OEE0N0JGRjAwRkI4ODcACgkQ/opHv/APuIcC/ACfZWhaYPj9p+FE7kAFDj8dr95+ PBgAn3RCpymGzDhxJHc13kkZhvt2Ynlb =4C57 -----END PGP SIGNATURE----- --0eh6TmSyL6TZE2Uz-- From owner-freebsd-net@FreeBSD.ORG Thu Jan 2 07:13:31 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5814E7AA for ; Thu, 2 Jan 2014 07:13:31 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 112E31D1D for ; Thu, 2 Jan 2014 07:13:30 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s027DTMj011552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jan 2014 23:13:29 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s027DSk0011551; Wed, 1 Jan 2014 23:13:28 -0800 (PST) (envelope-from jmg) Date: Wed, 1 Jan 2014 23:13:28 -0800 From: John-Mark Gurney To: Peter Jeremy Subject: Re: IPv4 Multicast MAC Address issues Message-ID: <20140102071328.GW99167@funkthat.com> Mail-Followup-To: Peter Jeremy , freebsd-net@freebsd.org References: <20140101085721.GA34334@server.rulingia.com> <20140101200303.GS99167@funkthat.com> <20140102064356.GL87348@server.rulingia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140102064356.GL87348@server.rulingia.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 01 Jan 2014 23:13:29 -0800 (PST) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 07:13:31 -0000 Peter Jeremy wrote this message on Thu, Jan 02, 2014 at 17:43 +1100: > On 2014-Jan-01 12:03:04 -0800, John-Mark Gurney wrote: > >Peter Jeremy wrote this message on Wed, Jan 01, 2014 at 19:57 +1100: > >> I'm trying to use multicast on my home network for the first time and > >> have found an apparent anomoly in the destination MAC address. > ... > >> FreeBSD shows that as the multicast MAC filter. Unfortunately, it > >> seems that (at least on FreeBSD-10), the destination MAC address > >> uses the low 23 bits of the IP address of my default route. > > >This is probably a bug, and I have confirmed this on: > >FreeBSD carbon.funkthat.com 11.0-CURRENT FreeBSD 11.0-CURRENT #4 r256870:258399M: Wed Nov 20 12:33:22 PST 2013 jmg@carbon.funkthat.com:/usr/src/sys/amd64/compile/lockprof amd64 > > Thanks. I've since checked 9.2/amd64 and it's OK there, so this is a > regression. I've raised kern/185395. I've done a quick look at the code and I don't see anything that changed that is odd, but I did notice that ETHER_MAP_IP_MULTICAST in if_ether.h doesn't put parens around ipaddr, but it's only use in if_ether.c looks safe. The one change around this code is the addition of const in the macro, but I don't think that could cause the issue... Hmmm... looking at the comments for arpresolve, it says dst is the next hop which would be the gateway, and not the multicast address, so that could be it, but I don't know the code well enough to figure out why dst isn't the multicast address... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Thu Jan 2 09:41:49 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DAE12E64 for ; Thu, 2 Jan 2014 09:41:49 +0000 (UTC) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id 2AA6F23F4; Thu, 2 Jan 2014 09:41:48 +0000 (UTC) Message-ID: <52C53443.7050704@FreeBSD.org> Date: Thu, 02 Jan 2014 13:41:23 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Peter Jeremy , freebsd-net@freebsd.org Subject: Re: IPv4 Multicast MAC Address issues References: <20140101085721.GA34334@server.rulingia.com> <20140101200303.GS99167@funkthat.com> <20140102064356.GL87348@server.rulingia.com> <20140102071328.GW99167@funkthat.com> In-Reply-To: <20140102071328.GW99167@funkthat.com> X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary="------------070105090207070507050803" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 09:41:49 -0000 This is a multi-part message in MIME format. --------------070105090207070507050803 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 02.01.2014 11:13, John-Mark Gurney wrote: > Hmmm... looking at the comments for arpresolve, it says dst is the next > hop which would be the gateway, and not the multicast address, so that > could be it, but I don't know the code well enough to figure out why > dst isn't the multicast address... Hi All, can you try this patch? -- WBR, Andrey V. Elsukov --------------070105090207070507050803 Content-Type: text/x-patch; name="multicast.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="multicast.diff" Index: sys/netinet/ip_output.c =================================================================== --- sys/netinet/ip_output.c (revision 260185) +++ sys/netinet/ip_output.c (working copy) @@ -418,6 +418,7 @@ again: goto done; } + gw = dst; goto sendit; } --------------070105090207070507050803-- From owner-freebsd-net@FreeBSD.ORG Thu Jan 2 10:29:49 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64EBA9DE for ; Thu, 2 Jan 2014 10:29:49 +0000 (UTC) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E62571935 for ; Thu, 2 Jan 2014 10:29:48 +0000 (UTC) Received: by mail-lb0-f174.google.com with SMTP id y6so7231331lbh.33 for ; Thu, 02 Jan 2014 02:29:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=K7sHdWX/EZ3Nrg5r9m9OL9+yfRdUyWGX6OCfMDXIYGM=; b=n/x49qIi240A8Tuig6p/cr0Yt69rn2zqqLII+6JxVclZyhnlaxL1uC2GguZOpI8Rz3 c5e7yiIb5Bom5Wyz7+yLXA/lmM4gtWxbDWaciZxxYAFGL1mDJ+oh6B6iv1Cu81+2vOKE LJF+L38JxeXE3eowql36ba/n7c82f9t41l6Ql715wzzD0R4pQhN5DSInzWrAT2WsT34y m4kSS6LmfTUJxlVASAGdqFqZiW8aKmIdmM/kPcag7PO2ivJJRmDcDVU6EqPbMUKiCDav tU3b/uwJ5kdDIOR1VsjAeA+QBNi2ny84QNzd1UqFxl+Ng1LaAvEV8TMFWp3iENG2Bl44 My3A== MIME-Version: 1.0 X-Received: by 10.152.23.39 with SMTP id j7mr21100203laf.28.1388658586980; Thu, 02 Jan 2014 02:29:46 -0800 (PST) Received: by 10.114.242.33 with HTTP; Thu, 2 Jan 2014 02:29:46 -0800 (PST) Date: Thu, 2 Jan 2014 10:29:46 +0000 Message-ID: Subject: Interface routes left over undeletable with RADIX_MPATH From: Nikolay Denev To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 10:29:49 -0000 Hi, While digging around for the "rtfree 2" panics with RADIX_MPATH I've reported in misc/185092, (yeah, should've been kern, or net, not misc) I've noticed that the interface routes that are installed on the loopback interface are left over when the address is removed and RADIX_MPATH is used. Moreover, since these now I believe are flagged as RTF_PINNED it's unable to delete them. Here is what happens with 10.0-RC3 GENERIC: # ifconfig em0 10.10.10.10/24 # netstat -rnfinet | grep 10.10.10.10 # 10.10.10.10 link#1 UHS 0 0 lo0 # ifconfig em0 delete # netstat -rnfinet | grep 10.10.10.10 # However, this happens with RADIX_MPATH kernel: # ifconfig em0 10.10.10.10/24 # netstat -rnfinet | grep 10.10.10.10 # 10.10.10.10 link#1 UHS 0 0 lo0 # ifconfig em0 delete # netstat -rnfinet | grep 10.10.10.10 # 10.10.10.10 link#1 UHS 0 0 lo0 # route delete 10.10.10.10 -iface lo0 # route: writing to routing socket: No such process # delete host 10.10.10.10: gateway lo0 fib0: not in table The address is successfully removed from the em0 interface, but the route over the loopback interface stays, even survives "route flush" --Nikolay From owner-freebsd-net@FreeBSD.ORG Thu Jan 2 11:08:04 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4DE66544; Thu, 2 Jan 2014 11:08:04 +0000 (UTC) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D60B91CDE; Thu, 2 Jan 2014 11:08:03 +0000 (UTC) Received: from server.rulingia.com (c220-239-250-249.belrs5.nsw.optusnet.com.au [220.239.250.249]) by vps.rulingia.com (8.14.7/8.14.7) with ESMTP id s02B7nMi028175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Jan 2014 22:07:50 +1100 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.7/8.14.7) with ESMTP id s02B7iwg079704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Jan 2014 22:07:44 +1100 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.7/8.14.7/Submit) id s02B7i48079703; Thu, 2 Jan 2014 22:07:44 +1100 (EST) (envelope-from peter) Date: Thu, 2 Jan 2014 22:07:44 +1100 From: Peter Jeremy To: "Andrey V. Elsukov" Subject: Re: IPv4 Multicast MAC Address issues Message-ID: <20140102110744.GO87348@server.rulingia.com> References: <20140101085721.GA34334@server.rulingia.com> <20140101200303.GS99167@funkthat.com> <20140102064356.GL87348@server.rulingia.com> <20140102071328.GW99167@funkthat.com> <52C53443.7050704@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MAH+hnPXVZWQ5cD/" Content-Disposition: inline In-Reply-To: <52C53443.7050704@FreeBSD.org> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 11:08:04 -0000 --MAH+hnPXVZWQ5cD/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2014-Jan-02 13:41:23 +0400, "Andrey V. Elsukov" wrote: >On 02.01.2014 11:13, John-Mark Gurney wrote: >> Hmmm... looking at the comments for arpresolve, it says dst is the next >> hop which would be the gateway, and not the multicast address, so that >> could be it, but I don't know the code well enough to figure out why >> dst isn't the multicast address... > >can you try this patch? I spun up a VBox running 11-current r260060 and that patch fixes the problem. I notice glebius@ has committed a different fix as r260188=20 --=20 Peter Jeremy --MAH+hnPXVZWQ5cD/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iKYEARECAGYFAlLFSIBfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDBCRjc3QTcyNTg5NEVCRTY0RjREN0VFRUZF OEE0N0JGRjAwRkI4ODcACgkQ/opHv/APuId70wCgtO926SEsJZ+b9volSANCa5az hCoAn1V/knncxTwYxlIVi3zmYBK/J4QH =4Bvs -----END PGP SIGNATURE----- --MAH+hnPXVZWQ5cD/-- From owner-freebsd-net@FreeBSD.ORG Thu Jan 2 14:41:44 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 13C007CE for ; Thu, 2 Jan 2014 14:41:44 +0000 (UTC) Received: from CMEXEDGE1.ext.emulex.com (cmexedge1.ext.emulex.com [138.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E3FB81F65 for ; Thu, 2 Jan 2014 14:41:43 +0000 (UTC) Received: from CMEXHTCAS2.ad.emulex.com (138.239.115.218) by CMEXEDGE1.ext.emulex.com (138.239.224.99) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 2 Jan 2014 06:26:53 -0800 Received: from CMEXMB1.ad.emulex.com ([169.254.1.137]) by CMEXHTCAS2.ad.emulex.com ([2002:8aef:71b8::8aef:71b8]) with mapi id 14.03.0146.002; Thu, 2 Jan 2014 06:26:31 -0800 From: Venkata Duvvuru To: "freebsd-net@freebsd.org" Subject: Mbuf reference count Thread-Topic: Mbuf reference count Thread-Index: Ac8Hxeb2Sg7MpN1TTGm43nDnBXjKAA== Date: Thu, 2 Jan 2014 14:26:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [138.239.140.248] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 14:41:44 -0000 Hi, Is there a way to increase the reference count of mbuf? I see there is a re= f count for external storage (m_ext) but couldn't find one for !M_EXT case. /Venkat. From owner-freebsd-net@FreeBSD.ORG Thu Jan 2 16:14:39 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 673FCD29; Thu, 2 Jan 2014 16:14:39 +0000 (UTC) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7652C1783; Thu, 2 Jan 2014 16:14:38 +0000 (UTC) Received: by mail-lb0-f181.google.com with SMTP id q8so7502478lbi.12 for ; Thu, 02 Jan 2014 08:14:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=EPpmkLe4J0xmyLdNFaXtSzV3LMFydYV7okmKaHB4AxI=; b=Gc6yRJ8a4+/3ltEEgA0C/w7iDtR+3zlSIRj2uwuRJsJTUotBHxXIuxim/6AwQ4NzZa yaHwxLGWVWGIN6FmkuqA7p4lVeOn2EbV0fyqROMNznNxAKg2d3nH7WHtzYUB0bG0hQG3 RzZ+QVUfrV4Qk5RC4E+pIQrEp+ygiYtgXtqcYpWKiZUxww31KxeAIgKxQtPzOrI8GwOB kzc6XUlT7B15W1UyG110/TId7zZVW34RfNdbCQ++TfrGxUytYBe0yeVIQgqj5frOqh4G WbDc/tL2PxRTHTO/Cbiaz9QobUs81njT4kVhbudNksuA+v8TfS2StUjce+GT/GOvFKqa uX2w== MIME-Version: 1.0 X-Received: by 10.112.201.167 with SMTP id kb7mr18063057lbc.32.1388679276185; Thu, 02 Jan 2014 08:14:36 -0800 (PST) Received: by 10.114.242.33 with HTTP; Thu, 2 Jan 2014 08:14:36 -0800 (PST) In-Reply-To: References: <201312221304.rBMD4q38060416@oldred.freebsd.org> <201312221310.rBMDA0KH022980@freefall.freebsd.org> Date: Thu, 2 Jan 2014 16:14:36 +0000 Message-ID: Subject: Re: misc/185092: panic: rtfree 2 (using RADIX_MPATH in a VNET jail) From: Nikolay Denev To: FreeBSD-gnats-submit@freebsd.org, freebsd-bugs@freebsd.org, "freebsd-net@freebsd.org" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 16:14:39 -0000 On Wed, Jan 1, 2014 at 5:39 PM, Nikolay Denev wrote: > Ok, killing openvpn with -9 leaves the routes around, and particularly > interesting are the following routes : > > 78.90.222.xx 10.255.255.0 UGHS 0 5841 epair0 = =3D> > 78.90.222.xx/32 10.255.255.0 UGS 0 0 epair0 > > Now, if I do : > > route delete 78.90.222.xx 10.255.255.0 > > The route, with the H flag is deleted. If I repeat the command the > second route is deleted as well, even if the second command specifies > a netmask no panic. > > However the first delete command specifies the /32 mask like this : > > route delete 78.90.222.xx 10.255.255.0 255.255.255.255 > > Then I get "rtfree 2" kernel panic immediately. > > This seems to be happening as I'm manually installing static routes in > the vnet jail for the VPN remote endpoints , however OpenVPN adds such > routes too however differently, which results in two routing entries. > > For example : > > route add $IP $GW > and > route add $IP $GW 255.255.255.255 > > add to different route entries, one is /32 network, the other is a host r= oute. > > > > --Nikolay > > On Wed, Jan 1, 2014 at 1:21 PM, Nikolay Denev wrote: >> On Wed, Jan 1, 2014 at 1:10 PM, Nikolay Denev wrote: >>> >>> On Sun, Dec 22, 2013 at 1:10 PM, wro= te: >>>> >>>> Thank you very much for your problem report. >>>> It has the internal identification `misc/185092'. >>>> The individual assigned to look at your >>>> report is: freebsd-bugs. >>>> >>>> You can access the state of your problem report at any time >>>> via this link: >>>> >>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D185092 >>>> >>>> >Category: misc >>>> >Responsible: freebsd-bugs >>>> >Synopsis: panic: rtfree 2 (using RADIX_MPATH in a VNET jail) >>>> >Arrival-Date: Sun Dec 22 13:10:00 UTC 2013 >>> >>> >>> I'm trying to understand exactly what is happening here, and examining = a >>> core dump with kgdb I'm getting some output that confuses me : >>> >>> (kgdb) bt >>> #0 doadump (textdump=3D-1011569920) at pcpu.h:233 >>> #1 0xc06069b2 in kern_reboot (howto=3D260) at >>> /usr/src/sys/kern/kern_shutdown.c:447 >>> #2 0xc0606d0e in panic (fmt=3D) at >>> /usr/src/sys/kern/kern_shutdown.c:754 >>> #3 0xc06de639 in rtfree (rt=3D) at >>> /usr/src/sys/net/route.c:464 >>> #4 0xc06e188d in route_output (m=3D) at >>> /usr/src/sys/net/rtsock.c:951 >>> #5 0xc06de18f in raw_usend (so=3D, flags=3D0, m= =3D>> optimized out>, nam=3D0x0, control=3D, >>> td=3D0xc3bd2000) at /usr/src/sys/net/raw_usrreq.c:238 >>> #6 0xc066eca9 in sosend_generic (so=3D0xc3e9c1a8, uio=3D>> out>, top=3D, control=3D0x0, >>> flags=3D, td=3D) at >>> /usr/src/sys/kern/uipc_socket.c:1271 >>> #7 0xc066efc7 in sosend (so=3D0xc3e9c1a8, addr=3D0x0, uio=3D0xd9b9cc10= , >>> top=3D0x0, control=3D0x0, flags=3D0, td=3D0xc3bd2000) >>> at /usr/src/sys/kern/uipc_socket.c:1315 >>> #8 0xc0654af4 in soo_write (fp=3D0xc3c0c818, uio=3D0xd9b9cc10, >>> active_cred=3D0xc3f1dd00, flags=3D0, td=3D0xc3bd2000) >>> at /usr/src/sys/kern/sys_socket.c:103 >>> #9 0xc064c866 in dofilewrite (td=3D0xc3bd2000, fd=3D3, fp=3D0xc3c0c818= , >>> auio=3D0xd9b9cc10, offset=3D-1, flags=3D0) at file.h:303 >>> #10 0xc064c566 in kern_writev (td=3D0xc3bd2000, fd=3D3, auio=3D>> out>) at /usr/src/sys/kern/sys_generic.c:467 >>> #11 0xc064c4bc in sys_write (td=3D, uap=3D>> optimized out>) at /usr/src/sys/kern/sys_generic.c:382 >>> #12 0xc08614d3 in syscall (frame=3D) at >>> subr_syscall.c:134 >>> #13 0xc084cca1 in Xint0x80_syscall () at >>> /usr/src/sys/i386/i386/exception.s:270 >>> #14 0x281975b7 in ?? () >>> Previous frame inner to this frame (corrupt stack?) >>> Current language: auto; currently minimal >>> (kgdb) fr 3 >>> #3 0xc06de639 in rtfree (rt=3D) at >>> /usr/src/sys/net/route.c:464 >>> 464 panic("rtfree 2"); >>> (kgdb) print *rt >>> $1 =3D {rt_nodes =3D {{rn_mklist =3D 0xc3b4ab30, rn_parent =3D 0x1, rn_= bit =3D 0, >>> rn_bmask =3D 0 '\0', rn_flags =3D 0 '\0', rn_u =3D {rn_leaf =3D { >>> rn_Key =3D 0xc0882687 "shutdown_post_sync", rn_Mask =3D 0x103= 0000 >>>
, rn_Dupedkey =3D 0x0}, rn_node =3D { >>> rn_Off =3D -1064819065, rn_L =3D 0x1030000, rn_R =3D 0x0}}}, >>> {rn_mklist =3D 0x0, rn_parent =3D 0x4, rn_bit =3D -18048, rn_bmask =3D = -94 '?', >>> rn_flags =3D 195 '?', rn_u =3D {rn_leaf =3D {rn_Key =3D 0xc3a545e= 0 "", >>> rn_Mask =3D 0xc3a4e440 " ??(???\020'", rn_Dupedkey =3D 0xc3a4e880}, >>> rn_node =3D {rn_Off =3D -1012578848, rn_L =3D 0xc3a4e440, rn_R = =3D >>> 0xc3a4e880}}}}, rt_gateway =3D 0x74756873, rt_flags =3D 1853321060, >>> rt_refcnt =3D 1936683103, rt_ifp =3D 0x79735f74, rt_ifa =3D 0x636e, r= t_rmx =3D >>> {rmx_mtu =3D 0, rmx_expire =3D 0, rmx_pksent =3D 0, rmx_weight =3D 0}, >>> rt_fibnum =3D 0, rt_mtx =3D {lock_object =3D {lo_name =3D 0x0, lo_fla= gs =3D 0, >>> lo_data =3D 0, lo_witness =3D 0x0}, mtx_lock =3D 0}} >>> >>> >>> >>> rn_Key with value of =93shutdown_post_sync=94 ? >>> >>> It=92s visible also in the raw_usend() frame: >>> >>> (kgdb) fr 5 >>> #5 0xc06de18f in raw_usend (so=3D, flags=3D0, m= =3D>> optimized out>, nam=3D0x0, control=3D, >>> td=3D0xc3bd2000) at /usr/src/sys/net/raw_usrreq.c:238 >>> 238 return ((*so->so_proto->pr_output)(m, so)); >>> (kgdb) print *m >>> $2 =3D {m_hdr =3D {mh_next =3D 0xc3b4ab30, mh_nextpkt =3D 0x1, mh_data = =3D 0x0, >>> mh_len =3D -1064819065, mh_type =3D 0, mh_flags =3D 66304, mh_pad =3D 0= }, >>> M_dat =3D {MH =3D {MH_pkthdr =3D {rcvif =3D 0x0, tags =3D {slh_first = =3D 0x4}, len =3D >>> -1012745856, flowid =3D 3282388448, >>> csum_flags =3D 14097648373312316480, fibnum =3D 26739, cosqos = =3D 117 >>> 'u', rsstype =3D 116 't', l2hlen =3D 100 'd', l3hlen =3D 111 'o', >>> l4hlen =3D 119 'w', l5hlen =3D 110 'n', PH_per =3D {eigth =3D "= _post_sy", >>> sixteen =3D {28767, 29551, 24436, 31091}, thirtytwo =3D {1936683103, >>> 2037604212}, sixtyfour =3D {8751443454668533855}, unintptr = =3D >>> {1936683103}, ptr =3D 0x736f705f}, PH_loc =3D { >>> eigth =3D "nc\000\000\000\000\000", sixteen =3D {25454, 0, 0,= 0}, >>> thirtytwo =3D {25454, 0}, sixtyfour =3D {25454}, unintptr =3D {25454}, >>> ptr =3D 0x636e}}, MH_dat =3D {MH_ext =3D {ref_cnt =3D 0x0, ex= t_buf =3D >>> 0x0, ext_size =3D 0, ext_type =3D 0, ext_flags =3D 0, ext_free =3D 0, >>> ext_arg1 =3D 0x0, ext_arg2 =3D 0x0}, >>> MH_databuf =3D '\0' , "file", '\0' >> times>, >>> "\006\000\000\000\020\000\000\000??\215?\000\000C\001\000\000\000\000\0= 00\000\000\000\004\000\000\000\000\000\000\00000Y?", >>> '\0' , >>> "`2Y?\000\000\000\000\000\000\000\000T\211\223?\022\000\000\000\000\203= ??\000\000\000\000\000???", >>> '\0' }}, >>> M_databuf =3D >>> "\000\000\000\000\004\000\000\000\200????E??@??\200??shutdown_post_sync= ", >>> '\0' , "file", '\0' , >>> "\006\000\000\000\020\000\000\000??\215?\000\000C\001\000\000\000\000\0= 00\000\000\000\004\000\000\000\000\000\000\00000Y?", >>> '\0' , >>> "`2Y?\000\000\000\000\000\000\000\000T\211\223?\022\000\000\000\000\203= ??\000\000\000\000\000???", >>> '\0' }} >>> >>> >>> This is 10.0-PRERELEASE r259547M (with applied the recent nd6_nbr.c rtf= ree >>> patch, which I thought earlier might be the cause of the panics I'm >>> seeing). >>> >>> The machine is Soekris Net5501-70 with this kernel config : >>> >>> cpu I586_CPU >>> cpu I686_CPU >>> ident MARS >>> options CPU_GEODE >>> options CPU_SOEKRIS >>> >>> options HZ=3D2000 >>> options DEVICE_POLLING >>> options BPF_JITTER >>> >>> makeoptions DEBUG=3D-g # Build kernel with gdb(1) debug symbols >>> >>> options SCHED_ULE # ULE scheduler >>> options PREEMPTION # Enable kernel thread preemption >>> options INET # InterNETworking >>> options INET6 # IPv6 communications protocols >>> options TCP_OFFLOAD # TCP offload >>> options FFS # Berkeley Fast Filesystem >>> options SOFTUPDATES # Enable FFS soft updates support >>> options UFS_DIRHASH # Improve performance on big directories >>> options PROCFS # Process filesystem (requires PSEUDOFS) >>> options PSEUDOFS # Pseudo-filesystem framework >>> options GEOM_PART_GPT # GUID Partition Tables. >>> options GEOM_LABEL # Provides labelization >>> options COMPAT_FREEBSD4 # Compatible with FreeBSD4 >>> options COMPAT_FREEBSD5 # Compatible with FreeBSD5 >>> options COMPAT_FREEBSD6 # Compatible with FreeBSD6 >>> options COMPAT_FREEBSD7 # Compatible with FreeBSD7 >>> options SCSI_DELAY=3D500 # Delay (in ms) before probing SCSI >>> options KTRACE # ktrace(1) support >>> options STACK # stack(9) support >>> options SYSVSHM # SYSV-style shared memory >>> options SYSVMSG # SYSV-style message queues >>> options SYSVSEM # SYSV-style semaphores >>> options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensio= ns >>> options PRINTF_BUFR_SIZE=3D128 # Prevent printf output being interspers= ed. >>> options KBD_INSTALL_CDEV # install a CDEV entry in /dev >>> options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) >>> options CAPABILITY_MODE # Capsicum capability mode >>> options CAPABILITIES # Capsicum capabilities >>> options PROCDESC # Support for process descriptors >>> options INCLUDE_CONFIG_FILE # Include this file in kernel >>> >>> # Debugging support. Always need this: >>> options KDB # Enable kernel debugger support. >>> options KDB_TRACE # Print a stack trace for a panic. >>> options KDB_UNATTENDED >>> >>> options TEXTDUMP_PREFERRED >>> options TEXTDUMP_VERBOSE >>> >>> device pci >>> device ata # Legacy ATA/SATA controllers >>> options ATA_STATIC_ID # Static device numbering >>> >>> # ATA/SCSI peripherals >>> device scbus # SCSI bus (required for ATA/SCSI) >>> device da # Direct Access (disks) >>> device pass # Passthrough device (direct ATA/SCSI access) >>> >>> # Add suspend/resume support for the i8254. >>> device pmtimer >>> >>> # Serial (COM) ports >>> device uart # Generic UART driver >>> >>> device miibus # MII bus support >>> device vr # VIA Rhine, Rhine II >>> >>> # Wireless NIC cards >>> device wlan # 802.11 support >>> options IEEE80211_DEBUG # enable debug msgs >>> options IEEE80211_AMPDU_AGE # age frames in AMPDU reorder q's >>> options IEEE80211_SUPPORT_MESH # enable 802.11s draft support >>> device wlan_wep # 802.11 WEP support >>> device wlan_ccmp # 802.11 CCMP support >>> device wlan_tkip # 802.11 TKIP support >>> device wlan_amrr # AMRR transmit rate control algorithm >>> device ath # Atheros NICs >>> device ath_pci # Atheros pci/cardbus glue >>> device ath_hal # pci/cardbus chip support >>> options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors >>> options AH_AR5416_INTERRUPT_MITIGATION # AR5416 interrupt mitigation >>> options ATH_ENABLE_11N # Enable 802.11n support for AR5416 and later >>> device ath_rate_sample # SampleRate tx rate control for ath >>> >>> # Pseudo devices. >>> device loop # Network loopback >>> device random # Entropy device >>> device ether # Ethernet support >>> device vlan # 802.1Q VLAN support >>> device tun # Packet tunnel. >>> device md # Memory "disks" >>> device gif # IPv6 and IPv4 tunneling >>> device gre >>> device faith # IPv6-to-IPv4 relaying (translation) >>> device firmware # firmware assist module >>> device if_bridge >>> >>> options VIMAGE >>> options ROUTETABLES=3D8 >>> options RADIX_MPATH >>> >>> options SW_WATCHDOG >>> >>> device crypto >>> device cryptodev >>> device glxsb >>> >>> options BOOTVERBOSE=3D1 >>> >>> #device pf >>> #device pflog >>> #device pfsync >>> device carp >>> device enc >>> device lagg >>> device epair >>> >>> #options ALTQ >>> #options ALTQ_CBQ >>> #options ALTQ_RED >>> #options ALTQ_RIO >>> #options ALTQ_HFSC >>> #options ALTQ_PRIQ >>> >>> options IPFIREWALL >>> options IPFIREWALL_DEFAULT_TO_ACCEPT >>> options IPFIREWALL_NAT >>> options LIBALIAS >>> options IPDIVERT >>> options DUMMYNET >>> >>> device bpf # Berkeley packet filter >>> >>> # USB support >>> options USB_DEBUG # enable debug msgs >>> device uhci # UHCI PCI->USB interface >>> device ohci # OHCI PCI->USB interface >>> device ehci # EHCI PCI->USB interface (USB 2.0) >>> device usb # USB Bus (required) >>> device umass # Disks/Mass storage - Requires scbus and da >>> >>> >>> Also src.conf and make.conf : >>> >>> root@vpn_vrf:[VNET(x)]:/usr/src/sys # cat /etc/src.conf >>> WITHOUT_ACCT=3Dyes >>> WITHOUT_ACPI=3Dyes >>> WITHOUT_AMD=3Dyes >>> WITHOUT_APM=3Dyes >>> WITHOUT_ASSERT_DEBUG=3Dyes >>> WITHOUT_AT=3Dyes >>> WITHOUT_ATF=3Dyes >>> WITHOUT_ATM=3Dyes >>> WITHOUT_AUDIT=3Dyes >>> WITHOUT_BLUETOOTH=3Dyes >>> WITHOUT_CALENDAR=3Dyes >>> WITHOUT_CDDL=3Dyes >>> WITHOUT_CTM=3Dyes >>> WITHOUT_DICT=3Dyes >>> WITHOUT_FLOPPY=3Dyes >>> WITHOUT_GAMES=3Dyes >>> WITHOUT_HTML=3Dyes >>> WITHOUT_INFO=3Dyes >>> WITHOUT_IPFILTER=3Dyes >>> WITHOUT_IPX=3Dyes >>> #WITHOUT_KERNEL_SYMBOLS=3Dyes >>> WITHOUT_LEGACY_CONSOLE=3Dyes >>> WITHOUT_LOCALES=3Dyes >>> WITHOUT_LPR=3Dyes >>> WITHOUT_MAIL=3Dyes >>> WITHOUT_NDIS=3Dyes >>> WITHOUT_QUOTAS=3Dyes >>> WITHOUT_ROUTED=3Dyes >>> WITHOUT_SENDMAIL=3Dyes >>> WITH_SVN=3Dyes >>> WITHOUT_ZFS=3Dyes >>> >>> root@vpn_vrf:[VNET(x)]:/usr/src/sys # cat /etc/make.conf >>> CFLAGS=3D-O2 >>> COPTFLAGS=3D -O -pipe >>> CPUTYPE=3Dgeode >>> KERNCONF=3DMARS >>> NO_MODULES=3Dyes >>> BOOTWAIT=3D0 >>> DOC_LANG=3Den_US.ISO8859-1 >>> >>> >>> >>> --Nikolay >>> >> >> Also, originally I thought that the panic is when a multi path route is >> being deleted, however again from the coredump it seems that the panic >> happens when openvpn deletes the host route it installs for the remote >> openvpn server pointed to the default gw (before openvpn installs the ne= w >> default gw pointing to the vpn tunnel) : >> >> (kgdb) fr 12 >> (kgdb) x/12sb td->td_proc->p_args >> 0xc4269780: "\001" >> 0xc4269782: "" >> 0xc4269783: "" >> 0xc4269784: "B" >> 0xc4269786: "" >> 0xc4269787: "" >> 0xc4269788: "/sbin/route" >> 0xc4269794: "delete" >> 0xc426979b: "-net" >> 0xc42697a0: "78.90.222.xxx" >> 0xc42697ad: "10.255.255.0" >> 0xc42697ba: "255.255.255.255" >> (kgdb) >> >> I'm trying to reproduce this on a VirtualBox instance now, however so fa= r no >> luck (no OpenVPN running, just adding and removing routes). >> >> >> --Nikolay Some more testing shows that it's pretty easy to panic the machine. One just have to try to delete twice a host route that has the same GW as the default gw and the machine panics. # ifconfig em0 10.0.0.155/24 up # route add default 10.0.0.1 add net default: gateway: 10.0.0.1 # route add 8.8.8.8 10.0.0.1 add host 8.8.8.8: gateway: 10.0.0.1 # route delete 8.8.8.8 10.0.0.1 delete host 8.8.8.8: gateway: 10.0.0.1 # route delete 8.8.8.8 10.0.0.1 panic: rtfree 2 --Nikolay From owner-freebsd-net@FreeBSD.ORG Thu Jan 2 17:23:05 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3975E221; Thu, 2 Jan 2014 17:23:05 +0000 (UTC) Received: from aussmtpmrkpc120.us.dell.com (aussmtpmrkpc120.us.dell.com [143.166.82.159]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CEA7D1E3C; Thu, 2 Jan 2014 17:23:04 +0000 (UTC) X-Loopcount0: from 64.238.244.148 X-IronPort-AV: E=Sophos;i="4.95,592,1384322400"; d="scan'208";a="66401734" Message-ID: <52C5A020.9010404@vangyzen.net> Date: Thu, 2 Jan 2014 11:21:36 -0600 From: Eric van Gyzen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Adrian Chadd , FreeBSD Net Subject: Re: ipv6 lock contention with parallel socket io References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 17:23:05 -0000 On 12/31/2013 11:53, Adrian Chadd wrote: > On 30 December 2013 23:35, Adrian Chadd wrote: >> Hi, >> >> I've noticed a bunch of lock contention occurs when doing highly >> parallel (> 4096 sockets) TCP IPv6 traffic. >> >> The contention is here: >> > [snip] > >> .. it's the IF_ADATA lock surrounding the lla_lookup() calls. >> >> Now: >> >> * is there any reason this isn't an rmlock? >> * the instance early on in nd6_output_lle() isn't taking the read >> lock, it's taking the full lock. Is there any reason for this? >> >> I don't have much experience or time to spend on optimising the ipv6 >> code to scale better but this seems like one of those things that'll >> bite us in the ass as the amount of ipv6 deployed increases. >> >> Does anyone have any ideas/suggestions on how we could improve things? > This improves things quite a bit - from 1.9gbyte/sec @ 100% cpu usage > to 2.7gbyte/sec @ 85% CPU usage. It's not perfect - the lock > contention is still there - but it's much less of an issue now. > > Are there any issues with it? > > Index: sys/netinet6/nd6.c > =================================================================== > --- sys/netinet6/nd6.c (revision 259475) > +++ sys/netinet6/nd6.c (working copy) > @@ -1891,9 +1891,9 @@ > flags = ((m != NULL) || (lle != NULL)) ? LLE_EXCLUSIVE : 0; > if (ln == NULL) { > retry: > - IF_AFDATA_LOCK(ifp); > + IF_AFDATA_RLOCK(ifp); > ln = lla_lookup(LLTABLE6(ifp), flags, (struct sockaddr *)dst); > - IF_AFDATA_UNLOCK(ifp); > + IF_AFDATA_RUNLOCK(ifp); > if ((ln == NULL) && nd6_is_addr_neighbor(dst, ifp)) { > /* > * Since nd6_is_addr_neighbor() internally > calls nd6_lookup(), This change looks safe, since flags can only contain LLE_EXCLUSIVE. However, the assertion in in6_lltable_lookup() seems insufficient. It asserts any lock on afdata. I think it should also assert a write-lock in the LLE_CREATE case. Granted, this is not strictly related to your change. Eric From owner-freebsd-net@FreeBSD.ORG Thu Jan 2 17:46:04 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A9BB4BFA for ; Thu, 2 Jan 2014 17:46:04 +0000 (UTC) Received: from mail-qe0-x236.google.com (mail-qe0-x236.google.com [IPv6:2607:f8b0:400d:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 682F51005 for ; Thu, 2 Jan 2014 17:46:04 +0000 (UTC) Received: by mail-qe0-f54.google.com with SMTP id cy11so14666491qeb.13 for ; Thu, 02 Jan 2014 09:46:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=UQqRzlgDKxzn5Wnj3l0L4JqFlou/RPMXL1DuhVHbq5A=; b=MyKOP6DHggxQ9IjdFg3GbrQIuLF2OZ8uSiHBt22m+sgVNxeAgIVs7qP3cbB7JGWeVd vKlyujfAtzptJjVBqq/XUXKuzWimBbVm8Cvx5D1EjBEJC4VVnEwiDNi4muc59BsyaH/k 82JPcXSFonjl+l5ca6bWNPubj+q7gAu4VqFR8onF4PEkW58B29D2C9rKPgYUjKLqOisQ Fv8MTy/gSsY3tFjgzM3Dh3A8uuHvDmBe4irkMZ2r/R2QCKKpJnT25LpBwVMtttaHq+Lt iDFYB2yDxcH/O2oLSFBDdGFvCgNuwR/OOMUAcQhzuI7XWzKoC2+4rsvYsP+fontInHaL sdvQ== MIME-Version: 1.0 X-Received: by 10.224.14.132 with SMTP id g4mr34232324qaa.26.1388684763573; Thu, 02 Jan 2014 09:46:03 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Thu, 2 Jan 2014 09:46:03 -0800 (PST) In-Reply-To: <52C5A020.9010404@vangyzen.net> References: <52C5A020.9010404@vangyzen.net> Date: Thu, 2 Jan 2014 09:46:03 -0800 X-Google-Sender-Auth: r86__bW_PpGZaIqxsuWlK3D8MbA Message-ID: Subject: Re: ipv6 lock contention with parallel socket io From: Adrian Chadd To: Eric van Gyzen Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 17:46:04 -0000 On 2 January 2014 09:21, Eric van Gyzen wrote: > On 12/31/2013 11:53, Adrian Chadd wrote: >> On 30 December 2013 23:35, Adrian Chadd wrote: >>> Hi, >>> >>> I've noticed a bunch of lock contention occurs when doing highly >>> parallel (> 4096 sockets) TCP IPv6 traffic. >>> >>> The contention is here: >>> >> [snip] >> >>> .. it's the IF_ADATA lock surrounding the lla_lookup() calls. >>> >>> Now: >>> >>> * is there any reason this isn't an rmlock? >>> * the instance early on in nd6_output_lle() isn't taking the read >>> lock, it's taking the full lock. Is there any reason for this? >>> >>> I don't have much experience or time to spend on optimising the ipv6 >>> code to scale better but this seems like one of those things that'll >>> bite us in the ass as the amount of ipv6 deployed increases. >>> >>> Does anyone have any ideas/suggestions on how we could improve things? >> This improves things quite a bit - from 1.9gbyte/sec @ 100% cpu usage >> to 2.7gbyte/sec @ 85% CPU usage. It's not perfect - the lock >> contention is still there - but it's much less of an issue now. >> >> Are there any issues with it? >> >> Index: sys/netinet6/nd6.c >> =================================================================== >> --- sys/netinet6/nd6.c (revision 259475) >> +++ sys/netinet6/nd6.c (working copy) >> @@ -1891,9 +1891,9 @@ >> flags = ((m != NULL) || (lle != NULL)) ? LLE_EXCLUSIVE : 0; >> if (ln == NULL) { >> retry: >> - IF_AFDATA_LOCK(ifp); >> + IF_AFDATA_RLOCK(ifp); >> ln = lla_lookup(LLTABLE6(ifp), flags, (struct sockaddr *)dst); >> - IF_AFDATA_UNLOCK(ifp); >> + IF_AFDATA_RUNLOCK(ifp); >> if ((ln == NULL) && nd6_is_addr_neighbor(dst, ifp)) { >> /* >> * Since nd6_is_addr_neighbor() internally >> calls nd6_lookup(), > > This change looks safe, since flags can only contain LLE_EXCLUSIVE. > However, the assertion in in6_lltable_lookup() seems insufficient. It > asserts any lock on afdata. I think it should also assert a write-lock > in the LLE_CREATE case. > > Granted, this is not strictly related to your change. Would you mind doing up a quick patch to demonstrate? I've heard mumblings at work that ipv6 panics if you change the routing tables during active traffic so if we're missing lock assertions I'd like to add them now and try to pick up the problem as it happens in testing. Thanks! -adrian From owner-freebsd-net@FreeBSD.ORG Fri Jan 3 02:07:28 2014 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D13E67CE; Fri, 3 Jan 2014 02:07:28 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A46451996; Fri, 3 Jan 2014 02:07:28 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s0327SUE048061; Fri, 3 Jan 2014 02:07:28 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s0327SjT048060; Fri, 3 Jan 2014 02:07:28 GMT (envelope-from linimon) Date: Fri, 3 Jan 2014 02:07:28 GMT Message-Id: <201401030207.s0327SjT048060@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/185427: [igb] freebsd 8.4, 9.1 and 9.2 panic Double-Fault with intel 82576 igb driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 02:07:28 -0000 Old Synopsis: freebsd 8.4, 9.1 and 9.2 panic Double-Fault with intel 82576 igb driver New Synopsis: [igb] freebsd 8.4, 9.1 and 9.2 panic Double-Fault with intel 82576 igb driver Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jan 3 02:06:34 UTC 2014 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=185427 From owner-freebsd-net@FreeBSD.ORG Fri Jan 3 02:55:47 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0ADD4454; Fri, 3 Jan 2014 02:55:47 +0000 (UTC) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id D3ECA1DA1; Fri, 3 Jan 2014 02:55:46 +0000 (UTC) Received: from latitude.home.vangyzen.net (173-20-209-204.client.mchsi.com [173.20.209.204]) by smtp.vangyzen.net (Postfix) with ESMTPSA id E15EE56423; Thu, 2 Jan 2014 20:55:45 -0600 (CST) Message-ID: <52C626AD.5030606@vangyzen.net> Date: Thu, 02 Jan 2014 20:55:41 -0600 From: Eric van Gyzen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: ipv6 lock contention with parallel socket io References: <52C5A020.9010404@vangyzen.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 02:55:47 -0000 >> However, the assertion in in6_lltable_lookup() seems insufficient. It >> asserts any lock on afdata. I think it should also assert a write-lock >> in the LLE_CREATE case. >> >> Granted, this is not strictly related to your change. > > Would you mind doing up a quick patch to demonstrate? Sure. http://www.vangyzen.net/FreeBSD/patches/in6_lltable_lookup_wlock_assert.diff This is not even compile-tested. > I've heard mumblings at work that ipv6 panics if you change the > routing tables during active traffic so if we're missing lock > assertions I'd like to add them now and try to pick up the problem as > it happens in testing. Excellent idea. Good luck, and thank you. Eric From owner-freebsd-net@FreeBSD.ORG Fri Jan 3 08:37:51 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BE49DD92 for ; Fri, 3 Jan 2014 08:37:51 +0000 (UTC) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8DF5F1669 for ; Fri, 3 Jan 2014 08:37:51 +0000 (UTC) Received: by mail-pb0-f53.google.com with SMTP id ma3so15363452pbc.40 for ; Fri, 03 Jan 2014 00:37:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mbVkyhtQ3Hl7e4IR5cl4Ioo6sKe4bs7TDXmTR9l0Znc=; b=D+Fr1qKnDTw3Sb0/S4aDHgFGh4hFyPYu8HbNi5/Deq8JSGQLs6t3VZdTxauOWKpLOU MU2VTeLt+FPWOXoZcBTVQGQYij3mv6Rt0ATkcO3iFu1QEzXsIzvsiJ9Y8c0AtdHI5XEj cK0H+8JhbiR2DG1RRWyb5B0c7YgTr3VgS0DXxRaMBgFJPJfUZfWC8/J6jFrTfvrhHyqt IyQyHQje2cmCkUXsoCJ0LBmYKartIe8YvJ7zfHcWC8ZbI3VvotVKsOBkOLOLBxmoXfPB dsTAR90bUXufb3MA+dbznRM0w8Ax2NiuyExmncNhhnKk6hlZSHUjQ6dUjSWmIzpM4TSr 0pHQ== MIME-Version: 1.0 X-Received: by 10.68.232.132 with SMTP id to4mr92451634pbc.141.1388738271222; Fri, 03 Jan 2014 00:37:51 -0800 (PST) Received: by 10.70.127.143 with HTTP; Fri, 3 Jan 2014 00:37:50 -0800 (PST) Received: by 10.70.127.143 with HTTP; Fri, 3 Jan 2014 00:37:50 -0800 (PST) In-Reply-To: References: Date: Fri, 3 Jan 2014 10:37:50 +0200 Message-ID: Subject: Re: Interface routes left over undeletable with RADIX_MPATH From: Sami Halabi To: Nikolay Denev Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 08:37:51 -0000 Hi, I've seen this problem also... My workaround : ifconfig lo0 delete (or destroy and rebuild i cant remmember) That deletef all thr ips in lo0 Sami =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A 2 =D7=91=D7=99=D7=A0=D7=95 2014 12:29,= "Nikolay Denev" =D7=9B=D7=AA=D7=91: > Hi, > > While digging around for the "rtfree 2" panics with RADIX_MPATH I've > reported in misc/185092, (yeah, should've been kern, or net, not misc) > I've noticed that the interface routes that are installed on the > loopback interface are left over when the address is removed and > RADIX_MPATH is used. Moreover, since these now I believe are flagged > as RTF_PINNED it's unable to delete them. > > Here is what happens with 10.0-RC3 GENERIC: > > # ifconfig em0 10.10.10.10/24 > # netstat -rnfinet | grep 10.10.10.10 > # 10.10.10.10 link#1 UHS 0 0 lo0 > # ifconfig em0 delete > # netstat -rnfinet | grep 10.10.10.10 > # > > However, this happens with RADIX_MPATH kernel: > > # ifconfig em0 10.10.10.10/24 > # netstat -rnfinet | grep 10.10.10.10 > # 10.10.10.10 link#1 UHS 0 0 lo0 > # ifconfig em0 delete > # netstat -rnfinet | grep 10.10.10.10 > # 10.10.10.10 link#1 UHS 0 0 lo0 > # route delete 10.10.10.10 -iface lo0 > # route: writing to routing socket: No such process > # delete host 10.10.10.10: gateway lo0 fib0: not in table > > The address is successfully removed from the em0 interface, but the > route over the loopback interface stays, even survives "route flush" > > > --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 Fri Jan 3 12:07:56 2014 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7B1DF466; Fri, 3 Jan 2014 12:07:56 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4E2881609; Fri, 3 Jan 2014 12:07:56 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s03C7u4e093770; Fri, 3 Jan 2014 12:07:56 GMT (envelope-from glebius@freefall.freebsd.org) Received: (from glebius@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s03C7sja093766; Fri, 3 Jan 2014 12:07:54 GMT (envelope-from glebius) Date: Fri, 3 Jan 2014 12:07:54 GMT Message-Id: <201401031207.s03C7sja093766@freefall.freebsd.org> To: sarumaru@yamayuri.org, glebius@FreeBSD.org, freebsd-net@FreeBSD.org, glebius@FreeBSD.org From: glebius@FreeBSD.org Subject: Re: kern/146082: [ng_l2tp] a false invaliant check was performed in ng_l2tp_seq_check() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 12:07:56 -0000 Synopsis: [ng_l2tp] a false invaliant check was performed in ng_l2tp_seq_check() State-Changed-From-To: open->patched State-Changed-By: glebius State-Changed-When: Fri Jan 3 12:07:15 UTC 2014 State-Changed-Why: Fixed in head. Responsible-Changed-From-To: freebsd-net->glebius Responsible-Changed-By: glebius Responsible-Changed-When: Fri Jan 3 12:07:15 UTC 2014 Responsible-Changed-Why: Fixed in head. http://www.freebsd.org/cgi/query-pr.cgi?pr=146082 From owner-freebsd-net@FreeBSD.ORG Fri Jan 3 13:14:52 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61962F6E; Fri, 3 Jan 2014 13:14:52 +0000 (UTC) Received: from m12-14.163.com (m12-14.163.com [220.181.12.14]) by mx1.freebsd.org (Postfix) with ESMTP id 60FA31A36; Fri, 3 Jan 2014 13:14:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Date:From:Subject:Message-Id:MIME-Version; bh=+r/Nn t3DoUVzqBVQ8TvtiOmwwMy7wku8ZP858BBc7ms=; b=ZSdZkC5mAnvQHItnEKG5i Qj73+4kOzakKj86uprYzo70K0y1lXFZo2pKecRToyDF8LoNfLvPXlJISby8oA2Dt mJAPZljJX70iR95TcizuQDWxcWVLwGbs3Y50+Q1CJegzvi+hXyBcF+sESXmnDAx9 PN5JnJZqqWYaK13M7jhrj4= Received: from [192.168.1.100] (unknown [60.255.0.17]) by smtp10 (Coremail) with SMTP id DsCowEC5g169t8ZSJjQHBw--.1050S2; Fri, 03 Jan 2014 21:14:39 +0800 (CST) X-Coremail-DSSMTP: 60.255.0.17 Date: Fri, 03 Jan 2014 21:14:33 +0800 From: sh1970 To: linimon@FreeBSD.org Subject: Re: kern/185427: [igb] freebsd 8.4, 9.1 and 9.2 panic Double-Fault with intel 82576 igb driver In-Reply-To: <201401030207.s0327SjT048060@freefall.freebsd.org> References: <201401030207.s0327SjT048060@freefall.freebsd.org> Message-Id: <20140103211431.4077.A3C13D1F@163.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.61.01 [en] X-CM-TRANSID: DsCowEC5g169t8ZSJjQHBw--.1050S2 X-Coremail-Antispam: 1Uf129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UbIYCTnIWIevJa73UjIFyTuYvj4RKKZWUUUUU X-Originating-IP: [60.255.0.17] X-CM-SenderInfo: 1vkrmlqq6rljoofrz/1tbi6w0IJlEAI1XDFgABs7 Cc: freebsd-net@FreeBSD.org, freebsd-bugs@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 13:14:52 -0000 I also have the same problem with freebsd 8.4 stable. -- sh1970 From owner-freebsd-net@FreeBSD.ORG Fri Jan 3 17:13:27 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4D36AAC for ; Fri, 3 Jan 2014 17:13:27 +0000 (UTC) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9536F1FD9 for ; Fri, 3 Jan 2014 17:13:27 +0000 (UTC) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 22A1820943 for ; Fri, 3 Jan 2014 12:13:26 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute2.internal (MEProxy); Fri, 03 Jan 2014 12:13:26 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=WEGQUu/ywgZTrmmH3+kKSvmbhJA=; b=JAI mF6NsEr5VaaVqLZIjFbUV1e9bzvJadP+djllFH/6rhXYVuheQR++et/BhAA5mhKL gJU/esPQ0qDnkiVqNny4gAYiPf3ooV21sf6hhVx4OXx6c/pf8RZPJRBzIzPi2k+J 5fphp2U3qLo28l7ppfuy9FMncPENMpnFsk64w1fE= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id F054410AEB5; Fri, 3 Jan 2014 12:13:25 -0500 (EST) Message-Id: <1388769205.18631.66232001.48DB5958@webmail.messagingengine.com> X-Sasl-Enc: 3XuGkntVBtLA3ntdKkvbQwvNWjLl2el0AYwcZXtni1KW 1388769205 From: Mark Felder To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-885bfc1c In-Reply-To: References: <20131228055324.GA72764@aim7400.DataIX.local> Subject: Re: network.subr _aliasN handling Date: Fri, 03 Jan 2014 11:13:25 -0600 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 17:13:27 -0000 On Sat, Dec 28, 2013, at 22:24, Teske, Devin wrote: > > On Dec 27, 2013, at 9:53 PM, wrote: > > > Curious what everyone's opinion would be on modifying the handling of _aliasN functions or providing a wrapper around it to handle non-sequential ordering. > > > > My goal on this is simple and based around groupings similiar to that of the way user id(1)'s in passwd and group are handled or denoted for use on modern systems. > > > > I.e.: I would like to achieve this... > > > > *_alias[1-99] = System type addresses "Importand addresses or internal" > > *_alias[100-199] = Aliases for interface 1 > > *_alias[200-299] = Aliases for interface 2 > > etc... > > > > NOt looking to achieve some sort of prefered naming convention for the interface aliases, but loosen them so they may be defined by the user in whatever means neccesary to their benefit. > > > > In a scheme similiar to above I attempted to set an address on every other 4th alias leaving 3 space rule room for insertion of further addresses but was surprised when the processing of the aliases ceased at the first non-sequential space. > > > > So why not just grab every _aliasN no matter of what it is for the interface and shove them into an arrary to be processed by a "for" statement ? the order would still be kept without having to inspect every defintion of alias and incrementing prehistorically. > > > > As well this could provide early loading of the addresses into their respective arrays so they may be processed and provided to any other functions that may need to access them earlier on in script fallthrough. > > > > Looking at _alias'N' sequentialy feels like a neucense. > > You mean something like the attached? > -- Commit this and I'll buy you a beverage of your choice the next time I run into you :-) I have webservers with a hundred or more aliases, each followed by a comment like: ifconfig_em0_aliasXX="1.2.3.4/32" # customer or vhost name And when you need to move an IP to another server or disable one temporarily it's very painful. Renumbering is not fun, and it's annoying when a new guy not familiar with the consequences makes a change on the server and then it's rebooted a month later and some IPs are no longer activated on boot! From owner-freebsd-net@FreeBSD.ORG Fri Jan 3 17:25:27 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 97A86CE3 for ; Fri, 3 Jan 2014 17:25:27 +0000 (UTC) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5031710BF for ; Fri, 3 Jan 2014 17:25:27 +0000 (UTC) Received: by mail-ig0-f177.google.com with SMTP id uy17so1563808igb.4 for ; Fri, 03 Jan 2014 09:25:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=3Bdb8TlpC6+pFVOY9lJ5NUwtKO3rx0YrDp1rNu9byuk=; b=X7MKtcLq4zdn1lz9us7/xCZFtNLz3vIlgshRPMfl6t0eD54YcYkoJAJ/tqPlkAUaIj D3M5haTK/N+suC4bzG0xJo0m0hnZS6FNkXwREC1iocZYtcyEcJeQ28lvuwPElvjmddEX e2HNmjCuk1BAvFD/6ZeXv37uN7gaYlLxOZjL0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=3Bdb8TlpC6+pFVOY9lJ5NUwtKO3rx0YrDp1rNu9byuk=; b=E8UVITbHa3wXVTo1VaJCsVMsdHIIZSM3Tk8a3+eFNzLYg6rqR83sJ84CMmRe07w0YY /Q2+nAYgR7iruxO4nVJ1+kZJNSVzgv+JbY9iNBuv1dixyIdshzx0WZ11s3Gq7o1XQnNa iKGHUhpuvQoDp8RMNPgXJ3FMIgqIiJAoLjxmnWROGAERPM2dA5NywpEC8+6xyecNCIPN cXZutV2vDSZhhX6L0iv/yTzIAnNGQRcF0LHjb+uycmP1cKOEhwMr2J4yC4uJH1qoctxw Ss3G6VGumO8mEPP0SPY3O5++Bkmcar4bdbCDGqNSVjicqainP2UV/g11pCs67ssbmDCk VMXw== X-Gm-Message-State: ALoCoQmh0UMgo1anF2FIQp6/ENcd3g+/REuGqQaz9fQOE1eGMnB1XqrVKuDOZS4TQhwn0+blRnyl X-Received: by 10.43.103.5 with SMTP id dg5mr3452650icc.50.1388769926628; Fri, 03 Jan 2014 09:25:26 -0800 (PST) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id t4sm2680215igm.10.2014.01.03.09.25.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Jan 2014 09:25:23 -0800 (PST) References: <20131228055324.GA72764@aim7400.DataIX.local> <1388769205.18631.66232001.48DB5958@webmail.messagingengine.com> Mime-Version: 1.0 (1.0) In-Reply-To: <1388769205.18631.66232001.48DB5958@webmail.messagingengine.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-97004E15-0B3F-4A67-B0CF-0113B2AEDCDD; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <722E0822-0511-49B5-82EB-BA298B0AA102@dataix.net> X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: network.subr _aliasN handling Date: Fri, 3 Jan 2014 12:25:20 -0500 To: Mark Felder X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 17:25:27 -0000 --Apple-Mail-97004E15-0B3F-4A67-B0CF-0113B2AEDCDD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Is that a confirmed test ? I still haven't got a chance on a run in with this yet but pretty damn confi= dent of it. --=20 Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On Jan 3, 2014, at 12:13, Mark Felder wrote: >=20 >> On Sat, Dec 28, 2013, at 22:24, Teske, Devin wrote: >>=20 >>> On Dec 27, 2013, at 9:53 PM, wrote: >>>=20 >>> Curious what everyone's opinion would be on modifying the handling of _a= liasN functions or providing a wrapper around it to handle non-sequential or= dering. >>>=20 >>> My goal on this is simple and based around groupings similiar to that of= the way user id(1)'s in passwd and group are handled or denoted for use on m= odern systems. >>>=20 >>> I.e.: I would like to achieve this... >>>=20 >>> *_alias[1-99] =3D System type addresses "Importand addresses or internal= " >>> *_alias[100-199] =3D Aliases for interface 1 >>> *_alias[200-299] =3D Aliases for interface 2 >>> etc... >>>=20 >>> NOt looking to achieve some sort of prefered naming convention for the i= nterface aliases, but loosen them so they may be defined by the user in what= ever means neccesary to their benefit. >>>=20 >>> In a scheme similiar to above I attempted to set an address on every oth= er 4th alias leaving 3 space rule room for insertion of further addresses bu= t was surprised when the processing of the aliases ceased at the first non-s= equential space. >>>=20 >>> So why not just grab every _aliasN no matter of what it is for the inter= face and shove them into an arrary to be processed by a "for" statement ? th= e order would still be kept without having to inspect every defintion of ali= as and incrementing prehistorically. >>>=20 >>> As well this could provide early loading of the addresses into their res= pective arrays so they may be processed and provided to any other functions t= hat may need to access them earlier on in script fallthrough. >>>=20 >>> Looking at _alias'N' sequentialy feels like a neucense. >>=20 >> You mean something like the attached? >> -- >=20 > Commit this and I'll buy you a beverage of your choice the next time I > run into you :-) I have webservers with a hundred or more aliases, each > followed by a comment like: >=20 > ifconfig_em0_aliasXX=3D"1.2.3.4/32" # customer or vhost name >=20 > And when you need to move an IP to another server or disable one > temporarily it's very painful. Renumbering is not fun, and it's annoying > when a new guy not familiar with the consequences makes a change on the > server and then it's rebooted a month later and some IPs are no longer > activated on boot! > _______________________________________________ > 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" --Apple-Mail-97004E15-0B3F-4A67-B0CF-0113B2AEDCDD Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDEwMzE3MjUyMlowIwYJKoZIhvcN AQkEMRYEFE2c3iHJKV3AKLmKy1TrxdHaQ0qXMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEAfUMpH9o3skRibGVoWn6V HkPpZuXyMQeHC3iLYpbD4fkXtU2ak+oSo2A8eeMjxy7VBVDwQnZ6WrSFPiDxJdhUy5Xo7BQh1U6e w7HnC9MUp8ls//xsHisBk+wKryNvKoz4NBclMOzSk2yUljz/fLuKqZEaV0Zh4fSCsNDXTUX7biG+ TCyB5+gxD6xRPZXb/ncbsbZ7fDpf6h4jo1R1Q40hpIy4IrZUrnzXTT29RZ7VJtRY+lCNh2UX6Dbz KswDMzOKMPviwvlDHKGo1gEO8sj7Bmp02B76yG7CRdLqbYgy2dYnhxagsrZ0CXkZg1Af9XvueaTW wjCe09mODEn6xSsScAAAAAAAAA== --Apple-Mail-97004E15-0B3F-4A67-B0CF-0113B2AEDCDD-- From owner-freebsd-net@FreeBSD.ORG Fri Jan 3 17:27:12 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0FDD0DDB; Fri, 3 Jan 2014 17:27:12 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BDB4E10D8; Fri, 3 Jan 2014 17:27:11 +0000 (UTC) Received: from secured.by.ipfw.ru ([95.143.220.47] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Vz4hI-000BNB-V0; Fri, 03 Jan 2014 17:21:57 +0400 Message-ID: <52C6F2E2.4000709@FreeBSD.org> Date: Fri, 03 Jan 2014 21:26:58 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130728 Thunderbird/17.0.7 MIME-Version: 1.0 To: Nikolay Denev Subject: Re: misc/185092: panic: rtfree 2 (using RADIX_MPATH in a VNET jail) References: <201312221304.rBMD4q38060416@oldred.freebsd.org> <201312221310.rBMDA0KH022980@freefall.freebsd.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/mixed; boundary="------------010209010603090701000503" Cc: "freebsd-net@freebsd.org" , freebsd-bugs@freebsd.org, FreeBSD-gnats-submit@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 17:27:12 -0000 This is a multi-part message in MIME format. --------------010209010603090701000503 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Please check if attached patch solves your issues. This fix is temporary, more proper one is on the way. --------------010209010603090701000503 Content-Type: text/x-patch; name="radix_mpath.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="radix_mpath.diff" Index: route.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- route.c (revision 260226) +++ route.c (working copy) @@ -943,9 +992,20 @@ register struct radix_node *rn; int error =3D 0; =20 - rn =3D rnh->rnh_matchaddr(dst, rnh); + rn =3D rnh->rnh_lookup(dst, netmask, rnh); if (rn =3D=3D NULL) return (ESRCH); + + if (netmask =3D=3D NULL) { + /* + * Check 'perfect match' case + */ + if (!sa_equal(dst, rn->rn_key)) + return (ESRCH); + if (rn->rn_mask !=3D NULL) + return (ESRCH); + } + rto =3D rt =3D RNTORT(rn); rt =3D rt_mpath_matchgate(rt, gateway); if (rt =3D=3D NULL) --------------010209010603090701000503-- From owner-freebsd-net@FreeBSD.ORG Fri Jan 3 17:27:26 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D06BEEB9; Fri, 3 Jan 2014 17:27:26 +0000 (UTC) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 772E210E0; Fri, 3 Jan 2014 17:27:25 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id DF5FE37B5AB; Fri, 3 Jan 2014 11:27:18 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3dwtN52DQ7zKwS; Fri, 3 Jan 2014 11:27:17 -0600 (CST) Date: Fri, 3 Jan 2014 11:27:17 -0600 From: "Matthew D. Fuller" To: Mark Felder Subject: Re: network.subr _aliasN handling Message-ID: <20140103172717.GJ99219@over-yonder.net> References: <20131228055324.GA72764@aim7400.DataIX.local> <1388769205.18631.66232001.48DB5958@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1388769205.18631.66232001.48DB5958@webmail.messagingengine.com> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.22 (2013-10-16) X-Virus-Scanned: clamav-milter 0.98 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 17:27:26 -0000 On Fri, Jan 03, 2014 at 11:13:25AM -0600 I heard the voice of Mark Felder, and lo! it spake thus: > > Commit this and I'll buy you a beverage of your choice the next time > I run into you :-) I have webservers with a hundred or more aliases, > each followed by a comment like: > > ifconfig_em0_aliasXX="1.2.3.4/32" # customer or vhost name That may suggest even moving it away from numbers, so you could rack up ifconfig_em0_alias_annoyingcustomer="1.2.3.4/32" and the like instead. Would even open up future possibilities through rc for running a single one of the aliases, which would be handy as a double-check when you add a new one to a running system. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-net@FreeBSD.ORG Fri Jan 3 17:36:08 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 904D6FE8 for ; Fri, 3 Jan 2014 17:36:08 +0000 (UTC) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 494871186 for ; Fri, 3 Jan 2014 17:36:08 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id x13so16150446ief.20 for ; Fri, 03 Jan 2014 09:36:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=msaOfrjfRKki6jvNrpRvUF3bgffBzbjzWoorKnZr1uw=; b=MxHs0qOYCnpb64jeRIDx80N3+g9PaJ9uxfXDlTlFbbIZz2HiN1CsRwmSlcZdC+rYwC FxUtIEFA3Cl00LU/3BHwDQw2YoXn3u2yZ8BEIHi1bpLNsf/7Wc3XDGx1OALfGWvUhEoj nWURt2++u2nb6DdNij+X/jTiHEb8CD4RidL5A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=msaOfrjfRKki6jvNrpRvUF3bgffBzbjzWoorKnZr1uw=; b=OWlofd8HGHWzegCh8Avxxy6iS+Kl2D8cTJ+qMMEpsna2RuEojnZKQPoH2UxNQCu5Bt bmDaqU1rFD037wGbY+lDB7JKDNo7U1DmCnmls0/Zg+4RL+URfk3a650kG8yQrwl9lnih 3tx2ww/k6awDuYFMz11/kt8NUro5It36zDupiBk4ZAhijxjwstOmolrD2eKKEpgRnFIC Um/aE87S82nRb80u3mgiO/5VGKk4JuSxQ29XLyu8vsmNAxC03OshIJHHmYVs1eMLtLc2 m436IPVWZT0J9jLuVrPMyO/AipDcbMvly3G/F2D12ogyU28k/qF8aKyi7vrvfyb0nH+G HMKA== X-Gm-Message-State: ALoCoQlNpWj+fboRvJV1RnH/vuM5xduJLpwbVA7edjXY27UVofha8CEDmq3LVYrahVQokzjQzTtj X-Received: by 10.50.138.98 with SMTP id qp2mr4239752igb.27.1388770567579; Fri, 03 Jan 2014 09:36:07 -0800 (PST) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id ft2sm2742576igb.5.2014.01.03.09.36.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Jan 2014 09:36:05 -0800 (PST) References: <20131228055324.GA72764@aim7400.DataIX.local> <1388769205.18631.66232001.48DB5958@webmail.messagingengine.com> <20140103172717.GJ99219@over-yonder.net> Mime-Version: 1.0 (1.0) In-Reply-To: <20140103172717.GJ99219@over-yonder.net> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8D001BF4-355B-4C54-91D8-0915EA0FF63C; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <276D42D3-48A6-41DB-A473-60F7AAB87E22@dataix.net> X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: network.subr _aliasN handling Date: Fri, 3 Jan 2014 12:36:03 -0500 To: "Matthew D. Fuller" X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-net@freebsd.org" , Mark Felder X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 17:36:08 -0000 --Apple-Mail-8D001BF4-355B-4C54-91D8-0915EA0FF63C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable --=20 Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On Jan 3, 2014, at 12:27, "Matthew D. Fuller" w= rote: >=20 > On Fri, Jan 03, 2014 at 11:13:25AM -0600 I heard the voice of > Mark Felder, and lo! it spake thus: >>=20 >> Commit this and I'll buy you a beverage of your choice the next time >> I run into you :-) I have webservers with a hundred or more aliases, >> each followed by a comment like: >>=20 >> ifconfig_em0_aliasXX=3D"1.2.3.4/32" # customer or vhost name >=20 > That may suggest even moving it away from numbers, so you could rack > up >=20 Yeah or anything . . .=20 ifconfig_int0_alias[array]=3D Maybe a little bit overkill but in instances would be awesome for usage. > ifconfig_em0_alias_annoyingcustomer=3D"1.2.3.4/32" >=20 > and the like instead. Would even open up future possibilities through > rc for running a single one of the aliases, which would be handy as a > double-check when you add a new one to a running system. >=20 >=20 > --=20 > Matthew Fuller (MF4839) | fullermd@over-yonder.net > Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ > On the Internet, nobody can hear you scream. > _______________________________________________ > 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" --Apple-Mail-8D001BF4-355B-4C54-91D8-0915EA0FF63C Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDEwMzE3MzYwNVowIwYJKoZIhvcN AQkEMRYEFAgqo1E1WtNdHOSANDheVIGc6bLCMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEAf2PzMGOlGrRpTDXgZOvt wOr2u4xU9rGDYEBFuMWvApCwBhR2hrhtXAMAZuAQzaIYFcwFFIdwxsqs3gV9fHVRcktwFNEnAbZM a3dnMZRT6xd4JeEC8YmHDK0RbOc3pdMABO2B2KMgX1MqQZH04S52yb7QtofpQqFQiDpRlZVGOiRT Zbww5Yj2XlU/4G82/xtjjS4Idktm8bcdvjq24y1+QxWmo8C9CBYl/9BSsw1li/ObS/6ClLu0bvBI 8AG7p69BQWHotQc3VPeFoBd2jmxkjYjll8ZXuND4BKiaVRu66MlrEfE3I66L5/m7fH0roxzuR8mA Hxkc0ECfp26CzivnqwAAAAAAAA== --Apple-Mail-8D001BF4-355B-4C54-91D8-0915EA0FF63C-- From owner-freebsd-net@FreeBSD.ORG Fri Jan 3 18:16:55 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A2F98182; Fri, 3 Jan 2014 18:16:55 +0000 (UTC) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 957DF152A; Fri, 3 Jan 2014 18:16:54 +0000 (UTC) Received: by mail-la0-f50.google.com with SMTP id el20so8374584lab.9 for ; Fri, 03 Jan 2014 10:16:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=91CND64OpgFitMACUxgjBnqazrUJgiMpPFqSnDkQ5wc=; b=ftwbenHKaI0cktQ5i/pSDMje82eZUDFa+NYlFyGJM36USof08Zg4ArxW95fJ92+0Uw 6FYOD73XfW2Iow96ioXFf1doG/jZNwFmi94xZiv7MCvivF9pCZK92zb7vohOebrS4DyX IgOOcBIYuOch94yrHgQhGAnr3q2Ur4hhO865aQCGTEti9+RUGBDxQI1YqPmLjnTy2+eJ DViPMZ2mGUipWVIlXTFurcHMrk5y/Ynv1CErrW2krsdCkmyYu9T8n6oeJa+owQXl7RdA D2SbXkGcuTM13WuIRlNNXUmGBXVZP87ttKHo3vH13in+M5dEl2kxhUjw1CfYyrCzJfgn PDRg== MIME-Version: 1.0 X-Received: by 10.112.157.234 with SMTP id wp10mr5675316lbb.50.1388773012546; Fri, 03 Jan 2014 10:16:52 -0800 (PST) Received: by 10.114.242.33 with HTTP; Fri, 3 Jan 2014 10:16:52 -0800 (PST) In-Reply-To: <52C6F2E2.4000709@FreeBSD.org> References: <201312221304.rBMD4q38060416@oldred.freebsd.org> <201312221310.rBMDA0KH022980@freefall.freebsd.org> <52C6F2E2.4000709@FreeBSD.org> Date: Fri, 3 Jan 2014 18:16:52 +0000 Message-ID: Subject: Re: misc/185092: panic: rtfree 2 (using RADIX_MPATH in a VNET jail) From: Nikolay Denev To: "Alexander V. Chernikov" Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" , freebsd-bugs@freebsd.org, FreeBSD-gnats-submit@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 18:16:55 -0000 On Fri, Jan 3, 2014 at 5:26 PM, Alexander V. Chernikov wrote: > Please check if attached patch solves your issues. > > This fix is temporary, more proper one is on the way. Thanks Alexander, this prevent the panics I was seeing, also the kernel now survives the route add/delete test from my previous email. --Nikolay From owner-freebsd-net@FreeBSD.ORG Fri Jan 3 20:33:17 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF00CC23 for ; Fri, 3 Jan 2014 20:33:17 +0000 (UTC) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8E72D10FF for ; Fri, 3 Jan 2014 20:33:17 +0000 (UTC) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id D811C2075E for ; Fri, 3 Jan 2014 15:27:57 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Fri, 03 Jan 2014 15:27:57 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=uPKneFP1jDLDWwdpQGC+nAxwcMo=; b=ubM N5kHIMs2DCWy4xQexA3WICZ9t3/0p1k/qAEM8uXBxpaJKvMjCoCxUt/ANj3fxr2w xCvnqKnjhNRPjyetMyy7rBU/03K6zEdKT0wPxxdLuAmaAnQlxwFdJE86syFXqX/V 04bXSCeiVMVdry9osiL+f8C9TVdnd26faNfrMSN0= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id B152610BE5A; Fri, 3 Jan 2014 15:27:57 -0500 (EST) Message-Id: <1388780877.14509.66300865.703FECAA@webmail.messagingengine.com> X-Sasl-Enc: roTrNmLIhmwr9JF1whwiMyXywIRyr4D5+BqiCnoZ48E4 1388780877 From: Mark Felder To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-885bfc1c In-Reply-To: <722E0822-0511-49B5-82EB-BA298B0AA102@dataix.net> References: <20131228055324.GA72764@aim7400.DataIX.local> <1388769205.18631.66232001.48DB5958@webmail.messagingengine.com> <722E0822-0511-49B5-82EB-BA298B0AA102@dataix.net> Subject: Re: network.subr _aliasN handling Date: Fri, 03 Jan 2014 14:27:57 -0600 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 20:33:17 -0000 On Fri, Jan 3, 2014, at 11:25, Jason Hellenthal wrote: > Is that a confirmed test ? > > I still haven't got a chance on a run in with this yet but pretty damn > confident of it. > I haven't had time to play with it yet; merely expressing my joy at the concept :) From owner-freebsd-net@FreeBSD.ORG Sat Jan 4 06:28:19 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2EEAA824 for ; Sat, 4 Jan 2014 06:28:19 +0000 (UTC) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DE66716EA for ; Sat, 4 Jan 2014 06:28:18 +0000 (UTC) Received: by mail-ig0-f178.google.com with SMTP id ut6so2847189igb.5 for ; Fri, 03 Jan 2014 22:28:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=rDBAG/wYlo2IcIABP46R3SCiCUJHhBjYBNiCeTH7shM=; b=grFV8BFfsbk93wbLcAlrfoDzafq8PQ+KZrrDFeXtNh2Xj7n7VpnmWSf8quX4ltdWEU hlDI2vNyUEgmUBJKVIXOw7tIDsITjDOckKIhD4I4JSHDX+oT2U54lzSEXdjSgz+Hia+q wOt2+DsP61U3VLXAy69+EN/8076w4Jh29NEgY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=rDBAG/wYlo2IcIABP46R3SCiCUJHhBjYBNiCeTH7shM=; b=Jp7mZesKSs0kRfKLdL5sObsp8jJwptKbWZGb1QA3rvwycwH+eEOnic9EjZKg0fWCTh WAHRHFvVveYGfH4Q81RnHiaY9O9pMJ3DUwAG4iX5E62EUH7qdZdfgJCryNFhL1anoGGh 1L9VsVQ2J90gz2HzR06kIRzZSTm+f8PHmgFlkKutv86RDy5nwIEj76m/2awBmjFX98VI WY+C3V3P3WkgvGfEzHHJcSGBCzeU168szCBxcUC8LuH8CzFglYi/6pDQ6cvzH/dSSDxE LF5uFc7vEPr3BaMAS8LWSXKvzdYPL4OHXljytDvi5Dbae/p/5hzxOaY5apv5uQnp92j3 BHVw== X-Gm-Message-State: ALoCoQmUi4uwTmGdUwI0zLyoxdy0zOnQZjtItky/S7XMqgqgDf1LpGpwmIKF83suNd6Rd21ZmYnE X-Received: by 10.43.137.5 with SMTP id im5mr5497202icc.55.1388816898261; Fri, 03 Jan 2014 22:28:18 -0800 (PST) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id qb4sm5346923igb.7.2014.01.03.22.28.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Jan 2014 22:28:15 -0800 (PST) References: <20131228055324.GA72764@aim7400.DataIX.local> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-B11F354E-727C-4E59-BA84-A775539EEFBA; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <9498BE8E-8090-4E7A-8317-18D29B1DDC08@dataix.net> X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: network.subr _aliasN handling Date: Sat, 4 Jan 2014 01:28:12 -0500 To: Devin Teske X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "rc@freebsd.org" , Devin Teske , "Teske, Devin" , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 06:28:19 -0000 --Apple-Mail-B11F354E-727C-4E59-BA84-A775539EEFBA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Alright something is a little off about this from a running standpoint it di= d what it is meant to do. Bug1: it seems to have looped back over itself reissuing two addresses from t= he top of the list. Test case: I have aliases 0-14 used numbered as such. Aliases 0-7 are ipv6 Aliases 8-14 are ipv4 I commented out alias 2 and 6 to break up consecutive order. Alias 8 & 9 appeared to have been run after alias 14. Something is awry but I can't quite pick out what it is yet. --=20 Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On Dec 28, 2013, at 23:24, "Teske, Devin" wrot= e: >=20 >=20 >> On Dec 27, 2013, at 9:53 PM, wrote: >>=20 >> Curious what everyone's opinion would be on modifying the handling of _al= iasN functions or providing a wrapper around it to handle non-sequential ord= ering. >>=20 >> My goal on this is simple and based around groupings similiar to that of t= he way user id(1)'s in passwd and group are handled or denoted for use on mo= dern systems. >>=20 >> I.e.: I would like to achieve this... >>=20 >> *_alias[1-99] =3D System type addresses "Importand addresses or internal"= >> *_alias[100-199] =3D Aliases for interface 1 >> *_alias[200-299] =3D Aliases for interface 2 >> etc... >>=20 >> NOt looking to achieve some sort of prefered naming convention for the in= terface aliases, but loosen them so they may be defined by the user in whate= ver means neccesary to their benefit. >>=20 >> In a scheme similiar to above I attempted to set an address on every othe= r 4th alias leaving 3 space rule room for insertion of further addresses but= was surprised when the processing of the aliases ceased at the first non-se= quential space. >>=20 >> So why not just grab every _aliasN no matter of what it is for the interf= ace and shove them into an arrary to be processed by a "for" statement ? the= order would still be kept without having to inspect every defintion of alia= s and incrementing prehistorically. >>=20 >> As well this could provide early loading of the addresses into their resp= ective arrays so they may be processed and provided to any other functions t= hat may need to access them earlier on in script fallthrough. >>=20 >> Looking at _alias'N' sequentialy feels like a neucense. >=20 > You mean something like the attached? > --=20 > Devin >=20 > _____________ > The information contained in this message is proprietary and/or confidenti= al. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any man= ner; and (iii) notify the sender immediately. In addition, please be aware t= hat any message addressed to our domain is subject to archiving and review b= y persons other than the intended recipient. Thank you. > --Apple-Mail-B11F354E-727C-4E59-BA84-A775539EEFBA Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDEwNDA2MjgxNFowIwYJKoZIhvcN AQkEMRYEFIMVLTJRDv7bRrK3vhY7KAZDHAgPMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEApuCdLoTt0eCOeCTwL9Cq V9tQb7+FDZTqwq7M+zYEr1MFNJL2GfcvQWahEqm/gywZJ6ReB1YyvlI1AdyCFJS0KI0Ree9fiDLU K7HeeyjlrXSpKsbSvkjnERm4EH6ylT9XXI24HTHS7usZavYCJWcEoEKMQwlvccLwWW1R1ODrcf7b qzm9OIAblfrF1J6q0X2ermvUagx1r2LIa1L01KtZH8kKbhwKXL4MO3QJ2D0FGu9xwPu8U41TaB4W TDSeyQxY7kFlmQgK8pLRK+RbYCQH2NkzDzQGP22QzVvQQsxf+MF/UHj42b+/GhtNsutEq8mMhKgb iw+wZtUaQ/gZcJSieQAAAAAAAA== --Apple-Mail-B11F354E-727C-4E59-BA84-A775539EEFBA-- From owner-freebsd-net@FreeBSD.ORG Sat Jan 4 06:36:30 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2BEF927 for ; Sat, 4 Jan 2014 06:36:30 +0000 (UTC) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AD6851798 for ; Sat, 4 Jan 2014 06:36:30 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id to1so16822840ieb.32 for ; Fri, 03 Jan 2014 22:36:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=TTPD5ALiJIsnLtfglJzsOSVfYSoF/P83EzW9FtegvZk=; b=DXQvY8ObZFxRpCp4MZURhHa7zqSQT8CW2jYNaowQ1CJeeFGCDKXZMdTpTrp4FnRvsn GJqWxKJdRO8Mgtyz2rFXueWXgYHS9E+nog9UoFuLI3mHAKDAarGvnvb7M8KzTgR2f1Um YC9i/6T38h2k/vhPM+TbH3pNZg2/jHtxcJP1g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=TTPD5ALiJIsnLtfglJzsOSVfYSoF/P83EzW9FtegvZk=; b=EpDSvKJ1nB4rMHbTkmdVpDNAJ9h/jd4yXTT9RJaDZk9U580mjRi35XAzuN/ejm6/xm SR3CC/lwbiEswoYsIUtYFVwhipwG1t8r2h+Vf2T5dMTwdRNQTYI0VfX5NT0G9gPfRnfI J7FXhz+3VoRedGTK58bmMvqjuBNWgfkRw2deI2DlkSg74QWFVDFWzN16wRe539Wh8Esv osCc6fx4j2/U5+0SXqNDhAgJNdue6dvs/pM5+R0sKleQ1ritIO5TyA0+LxFdHV/6tHzB Nbu+Dl9sMDMfTm2OBxnmMPQpNlqGWpfFBlxeumoV1UUfm3N2jwSnSL6QPl9NV0IPEHxE nygQ== X-Gm-Message-State: ALoCoQmy6UYBrbsHsRpzS4rJeKz9zKf4OKuBxRjcJvKWTU6lwpwShM0LKForcEndpiWca51F7MTu X-Received: by 10.50.56.38 with SMTP id x6mr6885909igp.31.1388817390049; Fri, 03 Jan 2014 22:36:30 -0800 (PST) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id ft2sm5379461igb.5.2014.01.03.22.36.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Jan 2014 22:36:28 -0800 (PST) References: <20131228055324.GA72764@aim7400.DataIX.local> <9498BE8E-8090-4E7A-8317-18D29B1DDC08@dataix.net> Mime-Version: 1.0 (1.0) In-Reply-To: <9498BE8E-8090-4E7A-8317-18D29B1DDC08@dataix.net> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2C24A6D5-9BA6-4FD9-B156-0443CCD0BAC7; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: network.subr _aliasN handling Date: Sat, 4 Jan 2014 01:36:24 -0500 To: Devin Teske X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "rc@freebsd.org" , Devin Teske , "Teske, Devin" , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 06:36:31 -0000 --Apple-Mail-2C24A6D5-9BA6-4FD9-B156-0443CCD0BAC7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Also I'm not using ipv6_ifconfig_int0_aliasN syntax vars here on stable/9 Strictly without ipv6_ since the original aliasing with "inet6 . . . " work= s and leaves for a nice clean list. --=20 Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On Jan 4, 2014, at 1:28, Jason Hellenthal wrote: >=20 > Alright something is a little off about this from a running standpoint it d= id what it is meant to do. >=20 > Bug1: it seems to have looped back over itself reissuing two addresses fro= m the top of the list. >=20 > Test case: > I have aliases 0-14 used numbered as such. > Aliases 0-7 are ipv6 > Aliases 8-14 are ipv4 >=20 > I commented out alias 2 and 6 to break up consecutive order. >=20 > Alias 8 & 9 appeared to have been run after alias 14. >=20 >=20 > Something is awry but I can't quite pick out what it is yet. >=20 > --=20 > Jason Hellenthal > Voice: 95.30.17.6/616 > JJH48-ARIN >=20 >> On Dec 28, 2013, at 23:24, "Teske, Devin" wro= te: >>=20 >>=20 >>> On Dec 27, 2013, at 9:53 PM, wrote: >>>=20 >>> Curious what everyone's opinion would be on modifying the handling of _a= liasN functions or providing a wrapper around it to handle non-sequential or= dering. >>>=20 >>> My goal on this is simple and based around groupings similiar to that of= the way user id(1)'s in passwd and group are handled or denoted for use on m= odern systems. >>>=20 >>> I.e.: I would like to achieve this... >>>=20 >>> *_alias[1-99] =3D System type addresses "Importand addresses or internal= " >>> *_alias[100-199] =3D Aliases for interface 1 >>> *_alias[200-299] =3D Aliases for interface 2 >>> etc... >>>=20 >>> NOt looking to achieve some sort of prefered naming convention for the i= nterface aliases, but loosen them so they may be defined by the user in what= ever means neccesary to their benefit. >>>=20 >>> In a scheme similiar to above I attempted to set an address on every oth= er 4th alias leaving 3 space rule room for insertion of further addresses bu= t was surprised when the processing of the aliases ceased at the first non-s= equential space. >>>=20 >>> So why not just grab every _aliasN no matter of what it is for the inter= face and shove them into an arrary to be processed by a "for" statement ? th= e order would still be kept without having to inspect every defintion of ali= as and incrementing prehistorically. >>>=20 >>> As well this could provide early loading of the addresses into their res= pective arrays so they may be processed and provided to any other functions t= hat may need to access them earlier on in script fallthrough. >>>=20 >>> Looking at _alias'N' sequentialy feels like a neucense. >>=20 >> You mean something like the attached? >> --=20 >> Devin >>=20 >> _____________ >> The information contained in this message is proprietary and/or confident= ial. If you are not the intended recipient, please: (i) delete the message a= nd all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware t= hat any message addressed to our domain is subject to archiving and review b= y persons other than the intended recipient. Thank you. >> --Apple-Mail-2C24A6D5-9BA6-4FD9-B156-0443CCD0BAC7 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDEwNDA2MzYyN1owIwYJKoZIhvcN AQkEMRYEFOwWEhlRaInQEmIy0w22J41koqYvMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEANnNLLe5CaKUQmmBpnBpE XYRpRY8HAWnPo1FLw6Kud3700R5FKNFbXW2/OctdGEc8ntYaioi8Qf0ppjHwxev/RhfbGQCPUWaE drGFS8a4+mCYVhVqRNTEGu8jzSur23R2nxQT8XxLyYEDv3SKbPjAVhx66m9twy5t+rhT+Tsnlfz5 LRWubyoucIp7hmJ49rINE7odnXQ1WmGPY/o/vHajWSJODlskRAD/V1eSyRVW6fi1iAbYQLGgeMEP lQHF2nlXt+H8l7dMKc9FxpL4zAdwdo7ESwdOyauS6UZYVuJK6KcD5tFEtocNXM1rfcoOdnJfcZVJ pldKZxl4Diq6t7hbEQAAAAAAAA== --Apple-Mail-2C24A6D5-9BA6-4FD9-B156-0443CCD0BAC7-- From owner-freebsd-net@FreeBSD.ORG Sat Jan 4 10:29:14 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 86AEB383; Sat, 4 Jan 2014 10:29:14 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4CC7E158B; Sat, 4 Jan 2014 10:29:13 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa03.fnfis.com (8.14.5/8.14.5) with ESMTP id s04ATB7N020074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 4 Jan 2014 04:29:12 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.7]) by LTCFISWMSGHT04.FNFIS.com ([10.132.206.15]) with mapi id 14.03.0158.001; Sat, 4 Jan 2014 04:29:11 -0600 From: "Teske, Devin" To: Jason Hellenthal Subject: Re: network.subr _aliasN handling Thread-Topic: network.subr _aliasN handling Thread-Index: AQHPBE3NCNy+IhmEZ0eModIwDB4CDw== Date: Sat, 4 Jan 2014 10:29:10 +0000 Message-ID: <7DBA7D58-E925-47BC-967C-F653348426A6@fisglobal.com> References: <20131228055324.GA72764@aim7400.DataIX.local> <9498BE8E-8090-4E7A-8317-18D29B1DDC08@dataix.net> In-Reply-To: <9498BE8E-8090-4E7A-8317-18D29B1DDC08@dataix.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-01-04_01:2014-01-03,2014-01-04,1970-01-01 signatures=0 Cc: "rc@freebsd.org" , Devin Teske , "Teske, Devin" , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Devin Teske List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2014 10:29:14 -0000 On Jan 3, 2014, at 10:28 PM, Jason Hellenthal wrote: > Alright something is a little off about this from a running standpoint it= did what it is meant to do. >=20 > Bug1: it seems to have looped back over itself reissuing two addresses fr= om the top of the list. >=20 > Test case: > I have aliases 0-14 used numbered as such. > Aliases 0-7 are ipv6 > Aliases 8-14 are ipv4 >=20 > I commented out alias 2 and 6 to break up consecutive order. >=20 > Alias 8 & 9 appeared to have been run after alias 14. >=20 >=20 > Something is awry but I can't quite pick out what it is yet. >=20 Sounds like I need to add some numerical sorting. --=20 Devin >=20 > On Dec 28, 2013, at 23:24, "Teske, Devin" wro= te: >=20 >>=20 >> On Dec 27, 2013, at 9:53 PM, wrote: >>=20 >>> Curious what everyone's opinion would be on modifying the handling of _= aliasN functions or providing a wrapper around it to handle non-sequential = ordering. >>>=20 >>> My goal on this is simple and based around groupings similiar to that o= f the way user id(1)'s in passwd and group are handled or denoted for use o= n modern systems. >>>=20 >>> I.e.: I would like to achieve this... >>>=20 >>> *_alias[1-99] =3D System type addresses "Importand addresses or interna= l" >>> *_alias[100-199] =3D Aliases for interface 1 >>> *_alias[200-299] =3D Aliases for interface 2 >>> etc... >>>=20 >>> NOt looking to achieve some sort of prefered naming convention for the = interface aliases, but loosen them so they may be defined by the user in wh= atever means neccesary to their benefit. >>>=20 >>> In a scheme similiar to above I attempted to set an address on every ot= her 4th alias leaving 3 space rule room for insertion of further addresses = but was surprised when the processing of the aliases ceased at the first no= n-sequential space. >>>=20 >>> So why not just grab every _aliasN no matter of what it is for the inte= rface and shove them into an arrary to be processed by a "for" statement ? = the order would still be kept without having to inspect every defintion of = alias and incrementing prehistorically. >>>=20 >>> As well this could provide early loading of the addresses into their re= spective arrays so they may be processed and provided to any other function= s that may need to access them earlier on in script fallthrough. >>>=20 >>> Looking at _alias'N' sequentialy feels like a neucense. >>=20 >> You mean something like the attached? >> --=20 >> Devin >>=20 >> _____________ >> The information contained in this message is proprietary and/or confiden= tial. If you are not the intended recipient, please: (i) delete the message= and all copies; (ii) do not disclose, distribute or use the message in any= manner; and (iii) notify the sender immediately. In addition, please be aw= are that any message addressed to our domain is subject to archiving and re= view by persons other than the intended recipient. Thank you. >> _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-net@FreeBSD.ORG Sat Jan 4 10:59:59 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8983F742 for ; Sat, 4 Jan 2014 10:59:59 +0000 (UTC) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4200B176F for ; Sat, 4 Jan 2014 10:59:59 +0000 (UTC) Received: by mail-ig0-f171.google.com with SMTP id c10so3148162igq.4 for ; Sat, 04 Jan 2014 02:59:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=87fLW0JcJcwHtix8iSEm+n8UrT+J+WgGqijH1Y4S1lk=; b=KuwBqpEiBa/57gZV9VsZzAcHhpFY4+NecZytC5pRvjanH+h2ZrB8AlfyjMnvcR1M6w zo61wnucMTS+3epdnzge9osaenmNLtYiWtUFmZdehHmhRgplNk87+fSyOROvAlzkCYLb BR7AD5me/50HexlSR1LKrJRoa0au+wvJG3Hic= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=87fLW0JcJcwHtix8iSEm+n8UrT+J+WgGqijH1Y4S1lk=; b=R+ffT69NvidH+rqZ+n2xddWpW5Q6G0y59IWJcceg73PegTid9EFuNd1bmTr7y6OBIE W5KKAUTstUkZ2DPiGkJWCb1QksDnW5u2Syq+O00/F7MqEQsCQfobJqkgCU6BUUC4MsqK dxrJtYkNjFvw+/agbUMP7Dl+L+Y3MX10kqSTft07NvtYEZUOE67aX5h9TEMq5IKx3ocY 1rY0eNL3ZcB05ojXi6AzFhG3PHAyrs1xlCCHZBT/pPMSwApkUbjAWVjwVNJX9s1vTkYO 6Lia3tWFbbEHNwMXCJA0kwjybR8U/qLFjtjkbFhgqmfEuhSCtStTyBERHUBEXqhVVo4I kTpw== X-Gm-Message-State: ALoCoQn+FULn+SHxjUO0Esj+BvCE0L0SJT9fThjrH8KpfYZ59kxLfoieHXLsVC12kM7oN8cifZUz X-Received: by 10.50.43.131 with SMTP id w3mr7775257igl.17.1388833198016; Sat, 04 Jan 2014 02:59:58 -0800 (PST) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id da14sm6029268igc.1.2014.01.04.02.59.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 04 Jan 2014 02:59:56 -0800 (PST) References: <20131228055324.GA72764@aim7400.DataIX.local> <9498BE8E-8090-4E7A-8317-18D29B1DDC08@dataix.net> <7DBA7D58-E925-47BC-967C-F653348426A6@fisglobal.com> Mime-Version: 1.0 (1.0) In-Reply-To: <7DBA7D58-E925-47BC-967C-F653348426A6@fisglobal.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-D1D391D0-1DA3-46B0-9239-11D17DF4D787; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: network.subr _aliasN handling Date: Sat, 4 Jan 2014 05:59:45 -0500 To: Devin Teske X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "rc@freebsd.org" , Devin Teske , "Teske, Devin" , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 10:59:59 -0000 --Apple-Mail-D1D391D0-1DA3-46B0-9239-11D17DF4D787 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I believe I know what you mean by that but in a way scares me when you say s= ort as in mixing up the original order they appear in which I would find to b= e really unattractive to most. --=20 Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On Jan 4, 2014, at 5:29, "Teske, Devin" wrote:= >=20 >=20 >> On Jan 3, 2014, at 10:28 PM, Jason Hellenthal wrote: >>=20 >> Alright something is a little off about this from a running standpoint it= did what it is meant to do. >>=20 >> Bug1: it seems to have looped back over itself reissuing two addresses fr= om the top of the list. >>=20 >> Test case: >> I have aliases 0-14 used numbered as such. >> Aliases 0-7 are ipv6 >> Aliases 8-14 are ipv4 >>=20 >> I commented out alias 2 and 6 to break up consecutive order. >>=20 >> Alias 8 & 9 appeared to have been run after alias 14. >>=20 >>=20 >> Something is awry but I can't quite pick out what it is yet. >=20 > Sounds like I need to add some numerical sorting. > --=20 > Devin >=20 >=20 >=20 >>=20 >>> On Dec 28, 2013, at 23:24, "Teske, Devin" wr= ote: >>>=20 >>>=20 >>>> On Dec 27, 2013, at 9:53 PM, wrote: >>>>=20 >>>> Curious what everyone's opinion would be on modifying the handling of _= aliasN functions or providing a wrapper around it to handle non-sequential o= rdering. >>>>=20 >>>> My goal on this is simple and based around groupings similiar to that o= f the way user id(1)'s in passwd and group are handled or denoted for use on= modern systems. >>>>=20 >>>> I.e.: I would like to achieve this... >>>>=20 >>>> *_alias[1-99] =3D System type addresses "Importand addresses or interna= l" >>>> *_alias[100-199] =3D Aliases for interface 1 >>>> *_alias[200-299] =3D Aliases for interface 2 >>>> etc... >>>>=20 >>>> NOt looking to achieve some sort of prefered naming convention for the i= nterface aliases, but loosen them so they may be defined by the user in what= ever means neccesary to their benefit. >>>>=20 >>>> In a scheme similiar to above I attempted to set an address on every ot= her 4th alias leaving 3 space rule room for insertion of further addresses b= ut was surprised when the processing of the aliases ceased at the first non-= sequential space. >>>>=20 >>>> So why not just grab every _aliasN no matter of what it is for the inte= rface and shove them into an arrary to be processed by a "for" statement ? t= he order would still be kept without having to inspect every defintion of al= ias and incrementing prehistorically. >>>>=20 >>>> As well this could provide early loading of the addresses into their re= spective arrays so they may be processed and provided to any other functions= that may need to access them earlier on in script fallthrough. >>>>=20 >>>> Looking at _alias'N' sequentialy feels like a neucense. >>>=20 >>> You mean something like the attached? >>> --=20 >>> Devin >>>=20 >>> _____________ >>> The information contained in this message is proprietary and/or confiden= tial. If you are not the intended recipient, please: (i) delete the message a= nd all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware t= hat any message addressed to our domain is subject to archiving and review b= y persons other than the intended recipient. Thank you. >>> >=20 > _____________ > The information contained in this message is proprietary and/or confidenti= al. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any man= ner; and (iii) notify the sender immediately. In addition, please be aware t= hat any message addressed to our domain is subject to archiving and review b= y persons other than the intended recipient. Thank you. --Apple-Mail-D1D391D0-1DA3-46B0-9239-11D17DF4D787 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDEwNDEwNTk0OVowIwYJKoZIhvcN AQkEMRYEFAzykiUwVo3f9mSZxeoFaw+P/SchMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEAUkKhtlG45loQ9QK+iv5I QvtnrwmB4EpGp7BvWbAeRymxysw1tUOzHNuAEGqL/Asw8tXPPyISdTW+I3PvehtuTHlZF8p/QhGJ rb3yhSQProkhYfRHJtTxZ4zoujszpbSWKLqZzLo0/CfKXRLHNU8FxyeLAO2BJZxJeJ/XkvHsVkc4 UFf4Mr/p8RiFEHX9R3pxpufobpLTYhWOIHIY9LLVR7GK2LHpLw2z1vyxwy3OE50KkTnQMOzBLYLw PgTw3bl2BatqpBZiWZhlR3XQkZj4lZ/prr+bq86dEXWjs1P5IY879viefVM9ESzUDvbuuIP4g+OY 5eOztYwu0kl9A9R+3QAAAAAAAA== --Apple-Mail-D1D391D0-1DA3-46B0-9239-11D17DF4D787-- From owner-freebsd-net@FreeBSD.ORG Sat Jan 4 11:25:16 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC7649F3; Sat, 4 Jan 2014 11:25:15 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9FC871914; Sat, 4 Jan 2014 11:25:15 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa05.fnfis.com (8.14.5/8.14.5) with ESMTP id s04BPDBN023775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 4 Jan 2014 05:25:13 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.7]) by LTCFISWMSGHT03.FNFIS.com ([10.132.206.31]) with mapi id 14.03.0158.001; Sat, 4 Jan 2014 05:25:12 -0600 From: "Teske, Devin" To: Jason Hellenthal Subject: Re: network.subr _aliasN handling Thread-Topic: network.subr _aliasN handling Thread-Index: AQHPBE3NCNy+IhmEZ0eModIwDB4CDw== Date: Sat, 4 Jan 2014 11:25:12 +0000 Message-ID: References: <20131228055324.GA72764@aim7400.DataIX.local> <9498BE8E-8090-4E7A-8317-18D29B1DDC08@dataix.net> <7DBA7D58-E925-47BC-967C-F653348426A6@fisglobal.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="us-ascii" Content-ID: <2F8EB90045F0BD4EAB959F42F1611480@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-01-04_01:2014-01-03,2014-01-04,1970-01-01 signatures=0 Cc: "rc@freebsd.org" , "Teske, Devin" , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Devin Teske List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2014 11:25:16 -0000 On Jan 4, 2014, at 2:59 AM, Jason Hellenthal wrote: > I believe I know what you mean by that but in a way scares me when you sa= y sort as in mixing up the original order they appear in which I would find= to be really unattractive to most. >=20 It's not as scary as it sounds. The issue is that the variables are sorted alphabetically, instead of numerically. Let's take four words: foo1, foo2, foo10, and foo20. If you sort them alphabetically, you get: foo1 foo10 foo2 foo20 You'll notice this when doing a directory listing, as that too is sorted alphabetically. This is why "alias14" is run before "alias8" and "alias9". Because they are processed in alphabetically sorted order. I didn't do anything to sort the values, they came pre-sorted in alphabetic order. If I simply throw in a "| sort -n", then it will change it to numerically s= orted. As you might expect, numerically sorting the above list would result in: foo1 foo2 foo10 foo20 Trivial really. I'll throw a patch at you when I get some cycles (soon). --=20 Devin > On Jan 4, 2014, at 5:29, "Teske, Devin" wrote: >=20 >>=20 >> On Jan 3, 2014, at 10:28 PM, Jason Hellenthal wrote: >>=20 >>> Alright something is a little off about this from a running standpoint = it did what it is meant to do. >>>=20 >>> Bug1: it seems to have looped back over itself reissuing two addresses = from the top of the list. >>>=20 >>> Test case: >>> I have aliases 0-14 used numbered as such. >>> Aliases 0-7 are ipv6 >>> Aliases 8-14 are ipv4 >>>=20 >>> I commented out alias 2 and 6 to break up consecutive order. >>>=20 >>> Alias 8 & 9 appeared to have been run after alias 14. >>>=20 >>>=20 >>> Something is awry but I can't quite pick out what it is yet. >>>=20 >>=20 >> Sounds like I need to add some numerical sorting. >> --=20 >> Devin >>=20 >>=20 >>=20 >>>=20 >>> On Dec 28, 2013, at 23:24, "Teske, Devin" w= rote: >>>=20 >>>>=20 >>>> On Dec 27, 2013, at 9:53 PM, wrote: >>>>=20 >>>>> Curious what everyone's opinion would be on modifying the handling of= _aliasN functions or providing a wrapper around it to handle non-sequentia= l ordering. >>>>>=20 >>>>> My goal on this is simple and based around groupings similiar to that= of the way user id(1)'s in passwd and group are handled or denoted for use= on modern systems. >>>>>=20 >>>>> I.e.: I would like to achieve this... >>>>>=20 >>>>> *_alias[1-99] =3D System type addresses "Importand addresses or inter= nal" >>>>> *_alias[100-199] =3D Aliases for interface 1 >>>>> *_alias[200-299] =3D Aliases for interface 2 >>>>> etc... >>>>>=20 >>>>> NOt looking to achieve some sort of prefered naming convention for th= e interface aliases, but loosen them so they may be defined by the user in = whatever means neccesary to their benefit. >>>>>=20 >>>>> In a scheme similiar to above I attempted to set an address on every = other 4th alias leaving 3 space rule room for insertion of further addresse= s but was surprised when the processing of the aliases ceased at the first = non-sequential space. >>>>>=20 >>>>> So why not just grab every _aliasN no matter of what it is for the in= terface and shove them into an arrary to be processed by a "for" statement = ? the order would still be kept without having to inspect every defintion o= f alias and incrementing prehistorically. >>>>>=20 >>>>> As well this could provide early loading of the addresses into their = respective arrays so they may be processed and provided to any other functi= ons that may need to access them earlier on in script fallthrough. >>>>>=20 >>>>> Looking at _alias'N' sequentialy feels like a neucense. >>>>=20 >>>> You mean something like the attached? >>>> --=20 >>>> Devin >>>>=20 >>>> _____________ >>>> The information contained in this message is proprietary and/or confid= ential. If you are not the intended recipient, please: (i) delete the messa= ge and all copies; (ii) do not disclose, distribute or use the message in a= ny manner; and (iii) notify the sender immediately. In addition, please be = aware that any message addressed to our domain is subject to archiving and = review by persons other than the intended recipient. Thank you. >>>> >>=20 >> _____________ >> The information contained in this message is proprietary and/or confiden= tial. If you are not the intended recipient, please: (i) delete the message= and all copies; (ii) do not disclose, distribute or use the message in any= manner; and (iii) notify the sender immediately. In addition, please be aw= are that any message addressed to our domain is subject to archiving and re= view by persons other than the intended recipient. Thank you. _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-net@FreeBSD.ORG Sat Jan 4 11:39:42 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6FE77C33 for ; Sat, 4 Jan 2014 11:39:42 +0000 (UTC) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 284A319E6 for ; Sat, 4 Jan 2014 11:39:42 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id as1so16924862iec.41 for ; Sat, 04 Jan 2014 03:39:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=bVkOgKuvmkeApaeG3GdZxO8MhBazL8WVHZl2iZnKWXo=; b=BzDf+RrAtwJH6nD5Ays8382ddDhKtUwQK4BW2b/cLKb0oO3PWz307kmKz38Y8/Ijrf QkeiyO+gCcTcL6jr8gHyNamez377ogZr+w1F4M/x1djfDbO1+prnLSm+/9N9+DS+2YVO jFRzMsCCzTw0DognRcj6yCJycE0kfx8X7zyPE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=bVkOgKuvmkeApaeG3GdZxO8MhBazL8WVHZl2iZnKWXo=; b=Bc9ZqnV5ixpurrWFgGMF73/DlbFAfQ9mEAOPW63uYzLQ9dgxg48Mlwem4M4WW4gKQ1 XhQmvnSx1djb+s+mj3yTSbze35+zOcF3CCeDkJZ6ftfVPVpgPzUXF+AVL+Drj76ierCH JFVQbM3Iqh3M3yYlt/xm/izaqrjS/BD9UaXVjPajhpYg/p4lCihjOpa6oBqCNY7OsfUE YVXaw7+JilZ6+XatO8QjuowV9uWA0HZOFkrRUG/ZFAKLWkIoG6xxBbMsH+x9LFYMvfIT RPjaGogE4IwZFkELOns4v9xVeZFRh+wro+V2CmefSunFU3tCkSwof8SEFLkzDAylCZ4U jWCA== X-Gm-Message-State: ALoCoQkyCLc3KRMRD3mehcM4KjY9zxL6ocIfRM/X2Ub5zkKnw0VTF+Fh5YC5B0bv4M1vD9yrBOR/ X-Received: by 10.50.25.129 with SMTP id c1mr8025732igg.23.1388835581640; Sat, 04 Jan 2014 03:39:41 -0800 (PST) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id qb4sm6099456igb.7.2014.01.04.03.39.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 04 Jan 2014 03:39:39 -0800 (PST) References: <20131228055324.GA72764@aim7400.DataIX.local> <9498BE8E-8090-4E7A-8317-18D29B1DDC08@dataix.net> <7DBA7D58-E925-47BC-967C-F653348426A6@fisglobal.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-F90A2C5A-C30C-4085-9CC8-683DB74D95CF; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <447D4E19-A122-4361-974F-DBDE70DBF593@dataix.net> X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: network.subr _aliasN handling Date: Sat, 4 Jan 2014 06:39:35 -0500 To: Devin Teske X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "rc@freebsd.org" , "Teske, Devin" , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 11:39:42 -0000 --Apple-Mail-F90A2C5A-C30C-4085-9CC8-683DB74D95CF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Alright that's what I thought was going on or at least seemed like it when I= read the output of ifconfig but didn't delve to deep into it. When I hear sort(1) particular circumstances come to mind from experience th= at hit me in the past so just for clarity wanted to see if I was on the same= page with what you were thinking. Thanks Devin much appreciated and sure it will be by the rest of the communi= ty as well. --=20 Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On Jan 4, 2014, at 6:25, "Teske, Devin" wrote:= >=20 >> On Jan 4, 2014, at 2:59 AM, Jason Hellenthal wrote: >>=20 >> I believe I know what you mean by that but in a way scares me when you sa= y sort as in mixing up the original order they appear in which I would find t= o be really unattractive to most. >=20 > It's not as scary as it sounds. >=20 > The issue is that the variables are sorted alphabetically, instead > of numerically. >=20 > Let's take four words: foo1, foo2, foo10, and foo20. > If you sort them alphabetically, you get: >=20 > foo1 > foo10 > foo2 > foo20 >=20 > You'll notice this when doing a directory listing, as that too is sorted > alphabetically. >=20 > This is why "alias14" is run before "alias8" and "alias9". Because they > are processed in alphabetically sorted order. I didn't do anything to sort= > the values, they came pre-sorted in alphabetic order. >=20 > If I simply throw in a "| sort -n", then it will change it to numerically s= orted. > As you might expect, numerically sorting the above list would result in: >=20 > foo1 > foo2 > foo10 > foo20 >=20 > Trivial really. I'll throw a patch at you when I get some cycles (soon). > --=20 > Devin >=20 >=20 >>> On Jan 4, 2014, at 5:29, "Teske, Devin" wrot= e: >>>=20 >>>=20 >>>> On Jan 3, 2014, at 10:28 PM, Jason Hellenthal wrote: >>>>=20 >>>> Alright something is a little off about this from a running standpoint i= t did what it is meant to do. >>>>=20 >>>> Bug1: it seems to have looped back over itself reissuing two addresses f= rom the top of the list. >>>>=20 >>>> Test case: >>>> I have aliases 0-14 used numbered as such. >>>> Aliases 0-7 are ipv6 >>>> Aliases 8-14 are ipv4 >>>>=20 >>>> I commented out alias 2 and 6 to break up consecutive order. >>>>=20 >>>> Alias 8 & 9 appeared to have been run after alias 14. >>>>=20 >>>>=20 >>>> Something is awry but I can't quite pick out what it is yet. >>>=20 >>> Sounds like I need to add some numerical sorting. >>> --=20 >>> Devin >>>=20 >>>=20 >>>=20 >>>>=20 >>>>> On Dec 28, 2013, at 23:24, "Teske, Devin" w= rote: >>>>>=20 >>>>>=20 >>>>>> On Dec 27, 2013, at 9:53 PM, wrote: >>>>>>=20 >>>>>> Curious what everyone's opinion would be on modifying the handling of= _aliasN functions or providing a wrapper around it to handle non-sequential= ordering. >>>>>>=20 >>>>>> My goal on this is simple and based around groupings similiar to that= of the way user id(1)'s in passwd and group are handled or denoted for use o= n modern systems. >>>>>>=20 >>>>>> I.e.: I would like to achieve this... >>>>>>=20 >>>>>> *_alias[1-99] =3D System type addresses "Importand addresses or inter= nal" >>>>>> *_alias[100-199] =3D Aliases for interface 1 >>>>>> *_alias[200-299] =3D Aliases for interface 2 >>>>>> etc... >>>>>>=20 >>>>>> NOt looking to achieve some sort of prefered naming convention for th= e interface aliases, but loosen them so they may be defined by the user in w= hatever means neccesary to their benefit. >>>>>>=20 >>>>>> In a scheme similiar to above I attempted to set an address on every o= ther 4th alias leaving 3 space rule room for insertion of further addresses b= ut was surprised when the processing of the aliases ceased at the first non-= sequential space. >>>>>>=20 >>>>>> So why not just grab every _aliasN no matter of what it is for the in= terface and shove them into an arrary to be processed by a "for" statement ?= the order would still be kept without having to inspect every defintion of a= lias and incrementing prehistorically. >>>>>>=20 >>>>>> As well this could provide early loading of the addresses into their r= espective arrays so they may be processed and provided to any other function= s that may need to access them earlier on in script fallthrough. >>>>>>=20 >>>>>> Looking at _alias'N' sequentialy feels like a neucense. >>>>>=20 >>>>> You mean something like the attached? >>>>> --=20 >>>>> Devin >>>>>=20 >>>>> _____________ >>>>> The information contained in this message is proprietary and/or confid= ential. If you are not the intended recipient, please: (i) delete the messag= e and all copies; (ii) do not disclose, distribute or use the message in any= manner; and (iii) notify the sender immediately. In addition, please be awa= re that any message addressed to our domain is subject to archiving and revi= ew by persons other than the intended recipient. Thank you. >>>>> >>>=20 >>> _____________ >>> The information contained in this message is proprietary and/or confiden= tial. If you are not the intended recipient, please: (i) delete the message a= nd all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware t= hat any message addressed to our domain is subject to archiving and review b= y persons other than the intended recipient. Thank you. >=20 > _____________ > The information contained in this message is proprietary and/or confidenti= al. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any man= ner; and (iii) notify the sender immediately. In addition, please be aware t= hat any message addressed to our domain is subject to archiving and review b= y persons other than the intended recipient. Thank you. --Apple-Mail-F90A2C5A-C30C-4085-9CC8-683DB74D95CF Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDEwNDExMzkzN1owIwYJKoZIhvcN AQkEMRYEFIhC6svZvZECW+TdpjCbhWex9HG4MIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEAOGt871pQQfKf5aJWKv5u UZxHS/54d55DF0Ihj/aPkx4i3jv9YGU4SJBFiAzaZaxZ/gC1PbKrRikxI66kEPP+yskX/XUhbnwG pA4/kNuMts+/8pG5WHMWn98FA+zKXNHVZ3Y0uYXvKZnr9GnhLHanTpExXlMwukAXc0+2+0qMTUaB YZvPLUOFozVFm0RRllLzG9ytDC8sz7rxu71QUia2SmIU8+phZ3BJ0qVeciygc98V2BZKPrntAq24 zi+9iQYv5J1zgnrX29EnYFDoxsb+LaBfV/fVw6AkbUA7Ya7JcLLII/IDT2RpSTWaIbe6HQdIsfRl tU99IRSo6r7vIDwScgAAAAAAAA== --Apple-Mail-F90A2C5A-C30C-4085-9CC8-683DB74D95CF-- From owner-freebsd-net@FreeBSD.ORG Sat Jan 4 13:06:03 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 73E36BFE; Sat, 4 Jan 2014 13:06:03 +0000 (UTC) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3338E1069; Sat, 4 Jan 2014 13:06:03 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id uy5so16646478obc.40 for ; Sat, 04 Jan 2014 05:06:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=sbl4FXQ3qDnbB4XkgGp1rgq2KMw1ystdVO9eawOfOYk=; b=pPgvzReqS3kV9pcSekWiBaftACpKOnBpRSLwpgxwH4/qWQueOF0iyHVa7iW0YPUtUa lyNA2AVzlAFa5L2Por3sM4BN8NH63z6nut1TOmou8lYH0fWyCU1cxfUcr81Lj4n/iNza tFzn7IVKQkiCqxZICKJKHjy55VLUaEZWdo1bng2Zy1rtpzY9AJdJHxolvUwrk0a2MVTp UEkJOwO/RRzC3VUgSxXKoR2XlTuhUDuxTnRt0H20ATMqwloPlkjjUqUe9DcOp+Xzift2 bjAgS4Wm6dOviOcJ2O0q57QY1pM/hcjWGT8xMsaVZtttbHi+vnT9CY51A71XRgav1lN5 52lQ== MIME-Version: 1.0 X-Received: by 10.60.161.229 with SMTP id xv5mr44024492oeb.20.1388840762437; Sat, 04 Jan 2014 05:06:02 -0800 (PST) Received: by 10.76.20.82 with HTTP; Sat, 4 Jan 2014 05:06:02 -0800 (PST) Date: Sat, 4 Jan 2014 15:06:02 +0200 Message-ID: Subject: 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBone Black due to unaligned access From: Guy Yur To: freebsd-net@freebsd.org, freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 13:06:03 -0000 Hi, I am running 10.0-RC1 arm.armv6 on the BeagleBone Black. The "pfctl -s state" command is crashing when trying to print the second entry. struct pfsync_state has a size that is not divisiable by 4 or 8 leading to the second entry in the returned state array not being aligned and pfctl core dumps on Bus error when trying to access a uint32_t field. (gdb) bt #0 print_host (addr=0x2085a11a, port=7660, af=2 '\002', opts=1024) at /usr/src/sbin/pfctl/pf_print_state.c:178 #1 0x00021c4c in print_state (s=0x2085a0f2, opts=1024) at /usr/src/sbin/pfctl/pf_print_state.c:236 #2 0x0000c664 in pfctl_show_states (dev=, iface=0x0, opts=1024) at /usr/src/sbin/pfctl/pfctl.c:1095 sizeof(struct pfsync_state_key) is 36 sizeof(struct pfsync_state_peer) is 32 sizeof(struct pf_addr) is 16 sizeof(struct pfsync_state) is 242 Removing the __spare[2] field will allow the struct to be aligned on 8 bytes for the u_int64_t id field and also cover the uint32_t fields alignment but this will break KBI. I am currently using an inefficient workaround in pfctl_show_states that memcpy each entry to a struct pfsync_state on the stack ensuring each call to print_state receives an aligned struct. 10.0-RC1 World and kernel were compiled in a VirtualBox VM running 9.2-RELEASE-p2 i386. clang and ARM_EABI used as the default make options. Regards, Guy From owner-freebsd-net@FreeBSD.ORG Sat Jan 4 17:00:13 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ACA0557A for ; Sat, 4 Jan 2014 17:00:13 +0000 (UTC) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 74AD31F8A for ; Sat, 4 Jan 2014 17:00:13 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id qd12so17175969ieb.1 for ; Sat, 04 Jan 2014 09:00:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Nhzav3bT7kO+Y+zllB/G5+kL3WTDX86fAmsZ4By94Sc=; b=lDlrrrr/Q9ev3EDmh0Zjlinvv2mQxZgk3dKWfEVECz+SS+rcsJla/GFjC/Fcowcvq1 KcoltkAOqj6pzzmZhKc+o+vd5a4HRAi9cEcUwAt6shpnRpnmkBtDNKs96RRgQXDrka4n d7BygoNjbN7V/8mE3LCbiQI6SnxLut5NZ3x9PT6ztoPOS1JXdOS9izVOH5Vkg85L6H9t vYIrrpEM6/6GiJ45aYxTI6kdklnHW+6tE7tqUqjKXs5VriFO80ZtajU4mqXWEHPmjzSk RejyAG7KLjn9YlwUUhBY8CsnpURCPqnt3dYNw4+VJ7JfNbfcAkuogISA9rVgKRIMKxCH V0Jg== X-Gm-Message-State: ALoCoQlDHVkYB/wk4/66FgIitmsbvqoyuc2brUuf1IwHX6mCcsHqPPTHjIcSuoQHvDoI58lNT8k0 X-Received: by 10.50.136.201 with SMTP id qc9mr9860121igb.11.1388854348952; Sat, 04 Jan 2014 08:52:28 -0800 (PST) Received: from [10.0.0.23] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id s4sm7149549ige.0.2014.01.04.08.52.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 04 Jan 2014 08:52:26 -0800 (PST) Sender: Warner Losh Subject: Re: 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBone Black due to unaligned access Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sat, 4 Jan 2014 09:50:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Guy Yur X-Mailer: Apple Mail (2.1085) Cc: freebsd-net@freebsd.org, freebsd-arm@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 17:00:13 -0000 I think this was changed in later RC versions. Warner On Jan 4, 2014, at 6:06 AM, Guy Yur wrote: > Hi, >=20 > I am running 10.0-RC1 arm.armv6 on the BeagleBone Black. > The "pfctl -s state" command is crashing when trying to print the > second entry. >=20 > struct pfsync_state has a size that is not divisiable by 4 or 8 = leading to the > second entry in the returned state array not being aligned and pfctl > core dumps on Bus error when trying to access a uint32_t field. >=20 > (gdb) bt > #0 print_host (addr=3D0x2085a11a, port=3D7660, af=3D2 '\002', = opts=3D1024) at > /usr/src/sbin/pfctl/pf_print_state.c:178 > #1 0x00021c4c in print_state (s=3D0x2085a0f2, opts=3D1024) at > /usr/src/sbin/pfctl/pf_print_state.c:236 > #2 0x0000c664 in pfctl_show_states (dev=3D, > iface=3D0x0, opts=3D1024) at /usr/src/sbin/pfctl/pfctl.c:1095 >=20 > sizeof(struct pfsync_state_key) is 36 > sizeof(struct pfsync_state_peer) is 32 > sizeof(struct pf_addr) is 16 > sizeof(struct pfsync_state) is 242 >=20 > Removing the __spare[2] field will allow the struct to be aligned on 8 = bytes > for the u_int64_t id field and also cover the uint32_t fields = alignment > but this will break KBI. >=20 > I am currently using an inefficient workaround in pfctl_show_states > that memcpy each entry to a struct pfsync_state on the stack > ensuring each call to print_state receives an aligned struct. >=20 >=20 > 10.0-RC1 World and kernel were compiled in a VirtualBox VM running > 9.2-RELEASE-p2 i386. > clang and ARM_EABI used as the default make options. >=20 >=20 > Regards, > Guy > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Jan 4 18:38:57 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F58F58F for ; Sat, 4 Jan 2014 18:38:57 +0000 (UTC) Received: from mail-gg0-x22b.google.com (mail-gg0-x22b.google.com [IPv6:2607:f8b0:4002:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 21FC716C2 for ; Sat, 4 Jan 2014 18:38:57 +0000 (UTC) Received: by mail-gg0-f171.google.com with SMTP id j1so3252759ggn.16 for ; Sat, 04 Jan 2014 10:38:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:content-type; bh=JSAgrF8ut7FMcZd7+bElnPVhJyl9ZTw49Z7HazO15Xs=; b=t8DcWP1tukq3H9s/eKwdmH9l6AJl2pnrRjxGR2B1Q4GeoZqoq9gUdL84mM/C6JRzgI /1RHlTCVqDQh1LWz1+GnRJIgU61fD5Jciw4ge4JBmd2S5+DfXjCPnngoyL4f5LlsPR+1 n1gkvd8itgKDtgfLC7tn8EMzzHIT4vKNbMOxg= 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:organization:user-agent :mime-version:to:cc:subject:content-type; bh=JSAgrF8ut7FMcZd7+bElnPVhJyl9ZTw49Z7HazO15Xs=; b=FJGSJ2M5WvOQeeIjOjRDh7RS2YIZLlSJP1vrR8RFdS5cS/8E1j1kLCZ5V49iEPByqU oBgSq2I5EduHUkceSIBdcDYm0iUJesClGFS2QECSeym5jPRI4r7CAH2i/0eDh/mKEeJF Ts8mCdU/Wi89QYZ/abGJfNQcznEoqx4uCJdtN9TjCeuUxKOcuVw4KFtqEximlI76qYBO LCKV806kA1IuQa+vYhNOHWt5f7CddUcHPSzzkjn9kXyJNTQmY/B4MzxtB2hzofDDK4ZY 5n4VV2W37O7zODDBybBO+rPI2qhDOodpw+BhkG+R2ZnN6W4017dKzEi2tP0YJgCYhTpG Cvtg== X-Gm-Message-State: ALoCoQmh3gpqn8aLvkZ3inP4d+NUg6qQu7Wb2zZ8u4z8VoaEqOj+9fSnHBzwaaNNaUaOHCqkrozT X-Received: by 10.236.84.226 with SMTP id s62mr2957048yhe.112.1388860736300; Sat, 04 Jan 2014 10:38:56 -0800 (PST) Received: from hackintosh.wemm.org ([2601:9:e80:770:7885:d41f:f3a8:eada]) by mx.google.com with ESMTPSA id k76sm9807111yho.18.2014.01.04.10.38.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 04 Jan 2014 10:38:54 -0800 (PST) Message-ID: <52C85537.7080307@wemm.org> Date: Sat, 04 Jan 2014 10:38:47 -0800 From: Peter Wemm Organization: World Domination in progress. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Long-haul problems - connections stuck in slow start Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="36bQ1sTSD7NQcDKVhvmAqAkjfWOnAOJmH" Cc: Gavin Atkinson , andre@freebsd.org, Peter Wemm X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 18:38:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --36bQ1sTSD7NQcDKVhvmAqAkjfWOnAOJmH Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We're seeing some unfortunate misbehavior with tcp over an intercontinent= al link. eg: fetching a 30GB http file from various package mirrors by a remote: us-west(ISC) -> london(BME) bd93e71c-cae4-44fd-943c-d1a88dbf6c6d.tar 0% of 29 GB 961 kBps 09h03m^= C us-east(NYI) -> london(BME) bd93e71c-cae4-44fd-943c-d1a88dbf6c6d.tar 0% of 29 GB 1070 kBps 08h08m^= C us-west(YSV) -> london(BME) bd93e71c-cae4-44fd-943c-d1a88dbf6c6d.tar 0% of 29 GB 14 kBps 590h22m= ^C Spot the one we're concerned about... Ping times for the three (in order): round-trip min/avg/max/std-dev =3D 144.330/144.532/144.797/0.157 ms round-trip min/avg/max/std-dev =3D 79.650/79.965/80.488/0.287 ms round-trip min/avg/max/std-dev =3D 148.588/153.292/155.688/2.903 ms The problem pair is worth showing some detail on: 16 bytes from ..:206a::1001:10, icmp_seq=3D4 hlim=3D55 time=3D148.588 ms 16 bytes from ..:206a::1001:10, icmp_seq=3D5 hlim=3D55 time=3D155.140 ms 16 bytes from ..:206a::1001:10, icmp_seq=3D6 hlim=3D55 time=3D149.443 ms 16 bytes from ..:206a::1001:10, icmp_seq=3D7 hlim=3D55 time=3D155.688 ms 16 bytes from ..:206a::1001:10, icmp_seq=3D8 hlim=3D55 time=3D148.630 ms 16 bytes from ..:206a::1001:10, icmp_seq=3D9 hlim=3D55 time=3D155.486 ms It appears that there are two packet paths between the endpoints that hav= e either ~148ms or ~155ms. I've done some longer samples and they're fairl= y consistent clusters. All four machines talk to each other. Here's where it gets interesting. On the sender at us-west(YSV), I see t= his: net.inet.tcp.hostcache.list: IP address SSTRESH RTT RTTVAR CWND HITS us-west(ISC) 59521 5ms 1ms 16845 15055031 eu-west(BME) 7343 150ms 2ms 13501 3433775 us-east(NYI) 530489 100ms 37ms 16681 43043786 The ssthresh is very low for the problematic ysv<->bme pair. When I do a tcpdump, I see the sender fire off 7343 bytes of data, then s= top and wait for acks. It's completely ignoring the receiver's window state.= It appears stuck in slowstart mode. Some other data: Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp6 0 1047852 2001:19:2.443 2001:41c8:.24490 ESTABLISHED (netstat -x, sorry about the wrap) Proto Recv-Q Send-Q Local Address Foreign Address R-MBUF S-MBUF R-CLUS S-CLUS R-HIWA S-HIWA R-LOWA S-LOWA R-BCNT S-BCNT R-BMAX S-B= MAX rexmt persist keep 2msl delack rcvtime tcp6 0 1048152 2001:1900:2254:2.443 2001:41c8:112:83.24490 0= 374 0 373 65688 1049580 1 2048 0 1420800 525504 8396640 0.43 0.00 7199.93 0.00 0.00 0.06 The "interesting" parts of -x: rexmt persist keep 2msl delack rcvtime 0.43 0.00 7199.93 0.00 0.00 0.06 -T Proto Rexmit OOORcv 0-win Local Address Foreign Address tcp6 54161 0 0 2001:192.443 2001:41:83.24490 note retransmits(!) Some tcpcb fields that caught my eye for the connection: snd_wnd =3D 1048576, snd_cwnd =3D 5712, t_srtt =3D 6391, t_rttvar =3D 903, t_rxtshift =3D 0, t_rttmin =3D 30, t_rttbest =3D 4903, t_rttupdated =3D 220095, max_sndwnd =3D 1048576, snd_cwnd_prev =3D 4284, snd_ssthresh_prev =3D 2856, snd_recover_prev =3D 1397053524, t_sndzerowin =3D 0, t_badrxtwin =3D 584273259, snd_limited =3D 0 '\0', t_rttlow =3D 150, I've stored some dumps of the tcpcb at http://people.freebsd.org/~peter/tcpcb.txt Note that some in the tcpcb.txt file also have snd_limited =3D 2 '\002', Over the last few days I've tried things like turning off sack, tso, the various rfc knobs etc. I believe they're all back to normal now. There's small ~15 second tcpdump sample of the sender side and the receiv= er side at: http://people.freebsd.org/~peter/send.cap.gz and http://people.freebsd.org/~peter/recv.cap.gz Both ends were ntp synced. The dumps have no sensitive data. For amusement, I just tried this, with roughly 1 second in between: peter@bme:~ % scp pkg-ysv:k.gz /tmp k.gz 100% 25MB 5.0MB/s 00:05 peter@bme:~ % scp pkg-ysv:k.gz /tmp k.gz 0% 960KB 20.3KB/s 41:29 ETA^C There was no pre-existing hostcache state between those two endpoints for= the first run. At the end, this was created in the hostcache: IP address SSTRESH RTT RTTVAR BANDWIDTH CWND 213.138.. 5952 165ms 21ms 0 8688 All connections went slow after that. Note that the ssh test was over ip= v4 - the rest above is on ipv6. However, we're seeing the same weird stuff with http over ipv4 as well between the same two endpoints. It was pointed out to me that this has come up before, eg: misc/173859 I know we've seen this at work as well. A few days earlier we were pushing ~45MB/sec (bytes, not bits) between th= ese endpoints. Out of the blue it crashed to ~10KB/sec. Why can't it get out= of slow-start? Is it even stuck in slow-start like I think? Is the 148-155= ms bimodal rtt the problem? Any insight would be greatly appreciated. (please don't drop me from cc:= ) --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6F= JV UTF-8: for when a ' just won\342\200\231t do. --36bQ1sTSD7NQcDKVhvmAqAkjfWOnAOJmH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLIVTsACgkQFRKuUnJ3cX9djgCfa8OuEF6AwFnlsyA1YT849YdN rsUAnA6X1BMs3Rsdgh5yUTkVubFquIuM =k83d -----END PGP SIGNATURE----- --36bQ1sTSD7NQcDKVhvmAqAkjfWOnAOJmH-- From owner-freebsd-net@FreeBSD.ORG Sat Jan 4 18:47:32 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61B7C9FE; Sat, 4 Jan 2014 18:47:32 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8B72B176B; Sat, 4 Jan 2014 18:47:31 +0000 (UTC) Received: from [192.168.1.103] (p508F1427.dip0.t-ipconnect.de [80.143.20.39]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id C25DA1C0C0695; Sat, 4 Jan 2014 19:47:28 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: 10.0-RC1: bad mbuf leak? From: Michael Tuexen In-Reply-To: <20131225133356.GL71033@FreeBSD.org> Date: Sat, 4 Jan 2014 19:47:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1387204500.12061.60192349.19EAE1B4@webmail.messagingengine.com> <3A115E20-3ADB-49BA-885D-16189B97842B@FreeBSD.org> <20131225133356.GL71033@FreeBSD.org> To: Gleb Smirnoff X-Mailer: Apple Mail (2.1510) Cc: FreeBSD Net , FreeBSD Stable Mailing List , Mark Felder X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 18:47:32 -0000 On Dec 25, 2013, at 2:33 PM, Gleb Smirnoff wrote: > Mark, >=20 > On Tue, Dec 24, 2013 at 10:54:33AM -0600, Mark Felder wrote: > M> > finally found some free time today to try to look into this. I = was digging into the SVN changelogs of sys/dev/e1000 and couldn't see = any obvious changes that I should revert. Instead I went a different = route and jumped to HEAD/CURRENT. I'm not seeing the mbufs leaking yet. = I'll need another 24 hours to confirm. Hopefully this is a worthwhile = clue. I'm a bit surprised nobody else has reported this type of = behavior... maybe 10 isn't getting the amount of testing we expect? = ...or maybe it's just my lonely, haunted hardware :( > M>=20 > M> Ok, I feel safe confirming that 10.0-RCs are not stable on my = hardware. The mbuf problem went away completely when I jumped to = head/current. > M>=20 > M> Can someone please suggest what patch I can attempt to back out to = fix this? I'd like to try to assist in fixing this before 10.0-RELEASE = happens or we're going to have some very angry users. >=20 > Is it possible for you to bisect head from the stable/10 branchpoint = up > to the current date and narrow down the revisions that introduced (and = later > fixed?) the leak? I did a bisect and http://svnweb.freebsd.org/changeset/base/258690 resolved the issue on my system: [bsd4:~] tuexen% uname -a FreeBSD bsd4.fh-muenster.de 11.0-CURRENT FreeBSD 11.0-CURRENT #192 = r258689: Sat Jan 4 19:48:27 CET 2014 = tuexen@bsd4.fh-muenster.de:/usr/home/tuexen/head/sys/amd64/compile/SCTP = amd64 [bsd4:~] tuexen% netstat -m 10755/315/11070 mbufs in use (current/cache/total) 10752/66/10818/508004 mbuf clusters in use (current/cache/total/max) 10752/30 mbuf+clusters out of packet secondary zone in use = (current/cache) 0/0/0/254001 4k (page size) jumbo clusters in use = (current/cache/total/max) 0/0/0/75259 9k jumbo clusters in use (current/cache/total/max) 0/0/0/42333 16k jumbo clusters in use (current/cache/total/max) 24192K/210K/24403K bytes allocated to network (current/cache/total) 150/5047/10782 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile [bsd4:~] tuexen% uname -a FreeBSD bsd4.fh-muenster.de 11.0-CURRENT FreeBSD 11.0-CURRENT #193 = r258690: Sat Jan 4 19:56:38 CET 2014 = tuexen@bsd4.fh-muenster.de:/usr/home/tuexen/head/sys/amd64/compile/SCTP = amd64 [bsd4:~] tuexen% netstat -m 10755/3000/13755 mbufs in use (current/cache/total) 10752/1374/12126/508004 mbuf clusters in use (current/cache/total/max) 10752/1373 mbuf+clusters out of packet secondary zone in use = (current/cache) 0/0/0/254001 4k (page size) jumbo clusters in use = (current/cache/total/max) 0/0/0/75259 9k jumbo clusters in use (current/cache/total/max) 0/0/0/42333 16k jumbo clusters in use (current/cache/total/max) 24192K/3498K/27690K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile [bsd4:~] tuexen%=20 Best regards Michael >=20 > --=20 > Totus tuus, Glebius. > _______________________________________________ > 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 From owner-freebsd-net@FreeBSD.ORG Sat Jan 4 19:20:29 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D87487E4 for ; Sat, 4 Jan 2014 19:20:29 +0000 (UTC) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8B80519B9 for ; Sat, 4 Jan 2014 19:20:29 +0000 (UTC) Received: by mail-yh0-f45.google.com with SMTP id v1so3379952yhn.32 for ; Sat, 04 Jan 2014 11:20:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type; bh=oMufCLOzru7bhrRY3zvSIPPdRXSrO3MOPynzwD3HT1A=; b=YzPGNZCJvjgXJixt6LiKZsjcwB6YWhRUjP3A33DAMSwRY7A24s76Evl+5uZJ+/O6Ii zG2wqC/FERzv67LbjC1BPqFgDs/WYU1htuSC5UbWb7Y6c/iyC6+APy/bDgy13cp+irf0 DvGjeEbrv4CyPj3u48ruNVNP82017s7ElEUC4= 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:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type; bh=oMufCLOzru7bhrRY3zvSIPPdRXSrO3MOPynzwD3HT1A=; b=KDzu5l8qo3wPrhwubOO5DKheFdztFBp7/3Gw4IndExuRxOcSXEKhwMkfph39hKZ6JA SXMmIwVaeS+neVrK5ca+A611fSB8hgLS8tM7jsc8+4FTgJdf1pby7welXtPlt4+G7jqp 25iGIlqXTos+UMl8CZVfSCjZxdpF+PmcmiQf3Sh1smx1eXi7hYnCsNS07ZtWV1x0P8Cz UnfAcycrGjfFcwgXWR9e82BNKz4iPQY6wICnAFp9CI6FzFFb0AgiVgs5bc8ReIAv9+6Y bgw61lQ1SWnJ5bxIYwVGj8vXW/AcBM/2TnuDpW6rr47DU6U4zqH9HqAaaLKueriPud7b 5uUw== X-Gm-Message-State: ALoCoQmm8kIiDipGQ/ZgZa1pH5BEMdcwTHMc7KDJlsouVj9JzfIaX1aB3TrrkFutIEvL1L36COhi X-Received: by 10.236.18.226 with SMTP id l62mr3038585yhl.105.1388863228838; Sat, 04 Jan 2014 11:20:28 -0800 (PST) Received: from hackintosh.wemm.org ([2601:9:e80:770:7885:d41f:f3a8:eada]) by mx.google.com with ESMTPSA id m9sm9986142yha.2.2014.01.04.11.20.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 04 Jan 2014 11:20:14 -0800 (PST) Message-ID: <52C85EED.801@wemm.org> Date: Sat, 04 Jan 2014 11:20:13 -0800 From: Peter Wemm Organization: World Domination in progress. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Long-haul problems - connections stuck in slow start References: <52C85537.7080307@wemm.org> In-Reply-To: <52C85537.7080307@wemm.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2qhRgDNowvCSusNohUdo2nMLk15gglXSo" Cc: Gavin Atkinson , andre@freebsd.org, Peter Wemm X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 19:20:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2qhRgDNowvCSusNohUdo2nMLk15gglXSo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 1/4/14, 10:38 AM, Peter Wemm wrote: > We're seeing some unfortunate misbehavior with tcp over an intercontine= ntal > link. I forgot to mention, the socket buffers have been generously tuned for th= ese endpoints. They don't seem to be being used while the sender is in some s= ort of limited transmit mode. When reading the tcpdumps, keep in mind the window scaling factor is 11 a= nd that's wasn't captured in the session. You'll have to manually compensat= e when reading the mid-session dumps. XXX footnote: It seems turning SACK off makes a huge difference for this= connection. The server must have been running with sack disabled when it= was working and hadn't been saved in sysctl.conf. Turning sack off on the= server again has raised the throughput from 8K/sec to 32MB/sec. That's a= nice 400x speedup. I'm investigating. --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6F= JV UTF-8: for when a ' just won\342\200\231t do. --2qhRgDNowvCSusNohUdo2nMLk15gglXSo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLIXu0ACgkQFRKuUnJ3cX8ORgCdGqZX/IMlh5I8TScjlHeXhcNb cFMAmgKr7VehEc8qO78XQngQJLycdyXT =yPlr -----END PGP SIGNATURE----- --2qhRgDNowvCSusNohUdo2nMLk15gglXSo-- From owner-freebsd-net@FreeBSD.ORG Sat Jan 4 19:52:12 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75BBFE40; Sat, 4 Jan 2014 19:52:12 +0000 (UTC) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 322491CC6; Sat, 4 Jan 2014 19:52:12 +0000 (UTC) Received: by mail-oa0-f45.google.com with SMTP id g12so1926379oah.18 for ; Sat, 04 Jan 2014 11:52:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=P+YoAydWULmrHNSiBA5rfifJoy9rFKlDcB2tFv/MQQE=; b=uOj/DMpiCJik7Ck/5QzeMABC4D5xlRAfU68tx/YCUhfZp6w55z7lXZb6jDnxz8+IXn 5Tw6o78isdK3CpSC43BzzkPdiEy7bb2gzCnDF1fux2YqowlO4C/DCHycYP8m5KdpoiLm VgQggoShzjYV8nEOHILMrb8v9pIZrqMrheXFR6egrG1Rt9OY/BX40wDkPbYVl/GnjVyI b67alroGoYN0huiJ8Vt+GQ6yMrSZ1YBj942b1hU74iioIziZqIpxCHJKQfUzmLgBe65p 4jAXy1RkxW9EC+/S5VGyJUFJdgENwb/bVAKyD7Aq3quRrCH+sZw7GINmxKPQoG4VmzJT KIRw== MIME-Version: 1.0 X-Received: by 10.60.54.168 with SMTP id k8mr1881834oep.56.1388865131471; Sat, 04 Jan 2014 11:52:11 -0800 (PST) Received: by 10.76.20.82 with HTTP; Sat, 4 Jan 2014 11:52:11 -0800 (PST) In-Reply-To: References: Date: Sat, 4 Jan 2014 21:52:11 +0200 Message-ID: Subject: Re: 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBone Black due to unaligned access From: Guy Yur To: freebsd-net@freebsd.org, freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 19:52:12 -0000 On Sat, Jan 4, 2014 at 6:50 PM, Warner Losh wrote: > I think this was changed in later RC versions. > > Warner > Do you mean r259308 in 10-STABLE? I compiled a new kernel with the change applied and still get SIGBUS on unaligned access. >From my reading of the ARM manual for Cortex-A it looks like setting CPU_CONTROL_AFLT_ENABLE to 1 means you want to get a trap on unaligned access. "1 = Strict alignment fault checking enabled." I see that dab_align delivers a SIGBUS on user-mode alignment fault. > On Jan 4, 2014, at 6:06 AM, Guy Yur wrote: > >> Hi, >> >> I am running 10.0-RC1 arm.armv6 on the BeagleBone Black. >> The "pfctl -s state" command is crashing when trying to print the >> second entry. >> >> struct pfsync_state has a size that is not divisiable by 4 or 8 leading to the >> second entry in the returned state array not being aligned and pfctl >> core dumps on Bus error when trying to access a uint32_t field. >> Regards, Guy From owner-freebsd-net@FreeBSD.ORG Sat Jan 4 19:55:15 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6283CF11; Sat, 4 Jan 2014 19:55:15 +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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BC66A1CD7; Sat, 4 Jan 2014 19:55:13 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id s04Jt6FI066439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 4 Jan 2014 23:55:06 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id s04Jt6cx066438; Sat, 4 Jan 2014 23:55:06 +0400 (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 Jan 2014 23:55:05 +0400 From: Gleb Smirnoff To: Michael Tuexen Subject: Re: 10.0-RC1: bad mbuf leak? Message-ID: <20140104195505.GV71033@glebius.int.ru> References: <1387204500.12061.60192349.19EAE1B4@webmail.messagingengine.com> <3A115E20-3ADB-49BA-885D-16189B97842B@FreeBSD.org> <20131225133356.GL71033@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: FreeBSD Net , FreeBSD Stable Mailing List , Mark Felder X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 19:55:15 -0000 Thanks, Michael! On Sat, Jan 04, 2014 at 07:47:27PM +0100, Michael Tuexen wrote: M> > On Tue, Dec 24, 2013 at 10:54:33AM -0600, Mark Felder wrote: M> > M> > finally found some free time today to try to look into this. I was digging into the SVN changelogs of sys/dev/e1000 and couldn't see any obvious changes that I should revert. Instead I went a different route and jumped to HEAD/CURRENT. I'm not seeing the mbufs leaking yet. I'll need another 24 hours to confirm. Hopefully this is a worthwhile clue. I'm a bit surprised nobody else has reported this type of behavior... maybe 10 isn't getting the amount of testing we expect? ...or maybe it's just my lonely, haunted hardware :( M> > M> M> > M> Ok, I feel safe confirming that 10.0-RCs are not stable on my hardware. The mbuf problem went away completely when I jumped to head/current. M> > M> M> > M> Can someone please suggest what patch I can attempt to back out to fix this? I'd like to try to assist in fixing this before 10.0-RELEASE happens or we're going to have some very angry users. M> > M> > Is it possible for you to bisect head from the stable/10 branchpoint up M> > to the current date and narrow down the revisions that introduced (and later M> > fixed?) the leak? M> I did a bisect and M> http://svnweb.freebsd.org/changeset/base/258690 M> resolved the issue on my system: I have just merged this change to head as r260280. Mark, can you pleast confirm that now stable/10 no longer leaks mbufs at your setup? -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Sat Jan 4 20:21:00 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 59FBF351 for ; Sat, 4 Jan 2014 20:21:00 +0000 (UTC) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1482C1E6C for ; Sat, 4 Jan 2014 20:20:59 +0000 (UTC) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id BCD2320CA4 for ; Sat, 4 Jan 2014 15:20:58 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Sat, 04 Jan 2014 15:20:58 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=pEz OLld5EGjPLpypjZYcGTKrI4I=; b=lBAv3XErT0PqwoWKQ6PE1lmAwLhOYIcNPm8 jsmkhD6RxNy/6mDbYeG2+1WnFpYX9ihvR6EiL5ePYc49n5hf/bsy/Gg82zjVKfek qSh7jsFA2EdDwsKvyCWpRzhj6zg5ea3E3sSmXQ6YmBx9dFRUITkW4MOvuV1qk/um 0CPAZ974= X-Sasl-enc: pidgLWZjNVyA7fY8n/eLhrrazwDXt7BD2GL1K9Oaxf5H 1388866858 Received: from [172.16.1.145] (unknown [68.117.126.78]) by mail.messagingengine.com (Postfix) with ESMTPA id E77F2C00E8D; Sat, 4 Jan 2014 15:20:57 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_74408AB9-BABD-4904-A0E4-EFD0533CC02C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: 10.0-RC1: bad mbuf leak? From: Mark Felder In-Reply-To: <20140104195505.GV71033@glebius.int.ru> Date: Sat, 4 Jan 2014 14:20:56 -0600 Message-Id: <11BB3983-28F7-40EF-87DA-FD95BD297EA7@FreeBSD.org> References: <1387204500.12061.60192349.19EAE1B4@webmail.messagingengine.com> <3A115E20-3ADB-49BA-885D-16189B97842B@FreeBSD.org> <20131225133356.GL71033@FreeBSD.org> <20140104195505.GV71033@glebius.int.ru> To: Gleb Smirnoff X-Mailer: Apple Mail (2.1827) Cc: Michael Tuexen , FreeBSD Stable Mailing List , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 20:21:00 -0000 --Apple-Mail=_74408AB9-BABD-4904-A0E4-EFD0533CC02C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 4, 2014, at 13:55, Gleb Smirnoff wrote: > Thanks, Michael! >=20 > On Sat, Jan 04, 2014 at 07:47:27PM +0100, Michael Tuexen wrote: > M> > On Tue, Dec 24, 2013 at 10:54:33AM -0600, Mark Felder wrote: > M> > M> > finally found some free time today to try to look into this. = I was digging into the SVN changelogs of sys/dev/e1000 and couldn't see = any obvious changes that I should revert. Instead I went a different = route and jumped to HEAD/CURRENT. I'm not seeing the mbufs leaking yet. = I'll need another 24 hours to confirm. Hopefully this is a worthwhile = clue. I'm a bit surprised nobody else has reported this type of = behavior... maybe 10 isn't getting the amount of testing we expect? = ...or maybe it's just my lonely, haunted hardware :( > M> > M>=20 > M> > M> Ok, I feel safe confirming that 10.0-RCs are not stable on my = hardware. The mbuf problem went away completely when I jumped to = head/current. > M> > M>=20 > M> > M> Can someone please suggest what patch I can attempt to back = out to fix this? I'd like to try to assist in fixing this before = 10.0-RELEASE happens or we're going to have some very angry users. > M> >=20 > M> > Is it possible for you to bisect head from the stable/10 = branchpoint up > M> > to the current date and narrow down the revisions that introduced = (and later > M> > fixed?) the leak? > M> I did a bisect and > M> http://svnweb.freebsd.org/changeset/base/258690 > M> resolved the issue on my system: >=20 > I have just merged this change to head as r260280. >=20 > Mark, can you pleast confirm that now stable/10 no longer leaks mbufs > at your setup? >=20 > --=20 > Totus tuus, Glebius. I'll build 10-STABLE right away. --Apple-Mail=_74408AB9-BABD-4904-A0E4-EFD0533CC02C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSyG0oAAoJEJg7ZFAfE+JSOmgIAJQXAat4oXKiNREH7QunVO5Q PT3inTgLc4vqzOVnMY+XGrIBj4aQ9BOZ+cp1G50X6bmoKeWbXJil7EdWrQHFcb/f u0SxmzLVpkKnne+hxzT87ZpvVkOa8xSyVX8SZyzaM3adS07PIKL1C3WecC+Kmncd cqldcGnnbUs6iaI8Y95bcpqpJrGYtBsPhJp7R7sag1yHNtkKoFHPBrmNrdk4cGbt i4Q6+pwoPqP8+bm+uaOkxDkvEJbN51tTCCmOhftC+ZfTwlvAA3OW/dxk/X9I4wWB sqPX7XwLv/ZqTh4MCpDV8q/2v2rL+Fk8KzQP4i/WbnHGVJPsEh3Bsd9bSzwnMcU= =L3vU -----END PGP SIGNATURE----- --Apple-Mail=_74408AB9-BABD-4904-A0E4-EFD0533CC02C-- From owner-freebsd-net@FreeBSD.ORG Sat Jan 4 20:41:01 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 37F2E754 for ; Sat, 4 Jan 2014 20:41:01 +0000 (UTC) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 036F51FE4 for ; Sat, 4 Jan 2014 20:41:00 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id bj1so17091568pad.2 for ; Sat, 04 Jan 2014 12:41:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ochH77LtGyaurLYIjeds6euOI4HA8nTOfG9FF7yviLI=; b=juxRLNYAAL6Q9w3NmeHNXLJ2nA+itDvusHUYjOhsXNgykA2WYkiAhQZTPNFfDMSXEp DZcVOQzi+1VSV0CYJUGZH2tVgxmYfjuWXhAevbiufo3QU9TRYj7tC5qChCW8ws/pCse1 Sy8O9AFsPCQZWqhpcRCV6Jq2nicKPO9L9+710= 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; bh=ochH77LtGyaurLYIjeds6euOI4HA8nTOfG9FF7yviLI=; b=F8vLBBkKhKDxOAQ1Sf+XW4J3jbUp+2kogmzO+2LJXsLUIOcS23sDtny3spym+Zy/Jv 99D/eJBuc4+0XiInOOjcVEBpX0Lp5ILI9VWCVBar0WsuqwBLFU9lbqMMPO0CB3cPQFTf /aT2VFo4qLUyBQe1tWFcOf+KU9YoFTMUNmOs9Kr7tzK4VZgvgVM9yTvBEK9kIy3IrTMp iMOsXIzRGmCrhCJ6fHe7qfdQ55D2NPkdMlZ/i+8ipx32glhy5K4ZH7zWMc+KyP3PIY4B jrDDczye/7W1LhoflfGKhUpnHNIUnYm9Nh3Hy6EDURT/N83P1j1fTk7y3Z0WdeTl4MPH moDw== X-Gm-Message-State: ALoCoQkUM1+CCMxDX2o6dxxZ8mB71ADphE3K5cxZ1ERCHHGCXyKMW+ylBAKamZvhfuiNRFVq4d62 MIME-Version: 1.0 X-Received: by 10.68.20.1 with SMTP id j1mr108912049pbe.148.1388868060497; Sat, 04 Jan 2014 12:41:00 -0800 (PST) Received: by 10.66.162.3 with HTTP; Sat, 4 Jan 2014 12:41:00 -0800 (PST) In-Reply-To: <52C85EED.801@wemm.org> References: <52C85537.7080307@wemm.org> <52C85EED.801@wemm.org> Date: Sat, 4 Jan 2014 12:41:00 -0800 Message-ID: Subject: Re: Long-haul problems - connections stuck in slow start From: Peter Wemm To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: Gavin Atkinson , Andre Oppermann , Peter Wemm X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 20:41:01 -0000 On Sat, Jan 4, 2014 at 11:20 AM, Peter Wemm wrote: > On 1/4/14, 10:38 AM, Peter Wemm wrote: >> We're seeing some unfortunate misbehavior with tcp over an intercontinental >> link. > > I forgot to mention, the socket buffers have been generously tuned for these > endpoints. They don't seem to be being used while the sender is in some sort > of limited transmit mode. > > When reading the tcpdumps, keep in mind the window scaling factor is 11 and > that's wasn't captured in the session. You'll have to manually compensate > when reading the mid-session dumps. > > XXX footnote: It seems turning SACK off makes a huge difference for this > connection. The server must have been running with sack disabled when it > was working and hadn't been saved in sysctl.conf. Turning sack off on the > server again has raised the throughput from 8K/sec to 32MB/sec. That's a > nice 400x speedup. > > I'm investigating. > It's still not solved. We just had a lucky break and the session ran fast for a while. SACK doesn't seem to be the variable. I'm looking at the duplicate acks in this trace from each end.. any clues where they're coming from? http://people.freebsd.org/~peter/acks.txt -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV Yes, I know, gmail sucks now. If you see this then I forgot. Habits are hard to break. From owner-freebsd-net@FreeBSD.ORG Sat Jan 4 21:41:04 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A4E851EE; Sat, 4 Jan 2014 21:41:04 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CF585138B; Sat, 4 Jan 2014 21:41:03 +0000 (UTC) Received: from [192.168.1.103] (p508F1427.dip0.t-ipconnect.de [80.143.20.39]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 0A76C1C0C0692; Sat, 4 Jan 2014 22:41:00 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Long-haul problems - connections stuck in slow start From: Michael Tuexen In-Reply-To: <52C85537.7080307@wemm.org> Date: Sat, 4 Jan 2014 22:40:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <90E0038B-7ED8-49B8-A947-86F8F33438D9@lurchi.franken.de> References: <52C85537.7080307@wemm.org> To: Peter Wemm X-Mailer: Apple Mail (2.1510) Cc: freebsd-net@freebsd.org, Gavin Atkinson , andre@freebsd.org, Peter Wemm X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 21:41:04 -0000 On Jan 4, 2014, at 7:38 PM, Peter Wemm wrote: > We're seeing some unfortunate misbehavior with tcp over an = intercontinental > link. >=20 > eg: fetching a 30GB http file from various package mirrors by a = remote: > us-west(ISC) -> london(BME) > bd93e71c-cae4-44fd-943c-d1a88dbf6c6d.tar 0% of 29 GB 961 kBps = 09h03m^C > us-east(NYI) -> london(BME) > bd93e71c-cae4-44fd-943c-d1a88dbf6c6d.tar 0% of 29 GB 1070 kBps = 08h08m^C > us-west(YSV) -> london(BME) > bd93e71c-cae4-44fd-943c-d1a88dbf6c6d.tar 0% of 29 GB 14 kBps = 590h22m^C >=20 > Spot the one we're concerned about... >=20 > Ping times for the three (in order): > round-trip min/avg/max/std-dev =3D 144.330/144.532/144.797/0.157 ms > round-trip min/avg/max/std-dev =3D 79.650/79.965/80.488/0.287 ms > round-trip min/avg/max/std-dev =3D 148.588/153.292/155.688/2.903 ms >=20 > The problem pair is worth showing some detail on: > 16 bytes from ..:206a::1001:10, icmp_seq=3D4 hlim=3D55 time=3D148.588 = ms > 16 bytes from ..:206a::1001:10, icmp_seq=3D5 hlim=3D55 time=3D155.140 = ms > 16 bytes from ..:206a::1001:10, icmp_seq=3D6 hlim=3D55 time=3D149.443 = ms > 16 bytes from ..:206a::1001:10, icmp_seq=3D7 hlim=3D55 time=3D155.688 = ms > 16 bytes from ..:206a::1001:10, icmp_seq=3D8 hlim=3D55 time=3D148.630 = ms > 16 bytes from ..:206a::1001:10, icmp_seq=3D9 hlim=3D55 time=3D155.486 = ms > It appears that there are two packet paths between the endpoints that = have > either ~148ms or ~155ms. I've done some longer samples and they're = fairly > consistent clusters. >=20 > All four machines talk to each other. >=20 > Here's where it gets interesting. On the sender at us-west(YSV), I = see this: > net.inet.tcp.hostcache.list: > IP address SSTRESH RTT RTTVAR CWND HITS > us-west(ISC) 59521 5ms 1ms 16845 15055031 > eu-west(BME) 7343 150ms 2ms 13501 3433775 > us-east(NYI) 530489 100ms 37ms 16681 43043786 >=20 > The ssthresh is very low for the problematic ysv<->bme pair. >=20 > When I do a tcpdump, I see the sender fire off 7343 bytes of data, = then stop > and wait for acks. It's completely ignoring the receiver's window = state. > It appears stuck in slowstart mode. >=20 > Some other data: > Proto Recv-Q Send-Q Local Address Foreign Address (state) > tcp6 0 1047852 2001:19:2.443 2001:41c8:.24490 ESTABLISHED >=20 > (netstat -x, sorry about the wrap) > Proto Recv-Q Send-Q Local Address Foreign Address = R-MBUF > S-MBUF R-CLUS S-CLUS R-HIWA S-HIWA R-LOWA S-LOWA R-BCNT S-BCNT R-BMAX = S-BMAX > rexmt persist keep 2msl delack rcvtime > tcp6 0 1048152 2001:1900:2254:2.443 2001:41c8:112:83.24490 = 0 > 374 0 373 65688 1049580 1 2048 0 1420800 525504 > 8396640 0.43 0.00 7199.93 0.00 0.00 0.06 >=20 > The "interesting" parts of -x: > rexmt persist keep 2msl delack rcvtime > 0.43 0.00 7199.93 0.00 0.00 0.06 >=20 > -T > Proto Rexmit OOORcv 0-win Local Address Foreign Address > tcp6 54161 0 0 2001:192.443 2001:41:83.24490 > note retransmits(!) >=20 > Some tcpcb fields that caught my eye for the connection: > snd_wnd =3D 1048576, > snd_cwnd =3D 5712, > t_srtt =3D 6391, > t_rttvar =3D 903, > t_rxtshift =3D 0, > t_rttmin =3D 30, > t_rttbest =3D 4903, > t_rttupdated =3D 220095, > max_sndwnd =3D 1048576, > snd_cwnd_prev =3D 4284, > snd_ssthresh_prev =3D 2856, > snd_recover_prev =3D 1397053524, > t_sndzerowin =3D 0, > t_badrxtwin =3D 584273259, > snd_limited =3D 0 '\0', > t_rttlow =3D 150, > I've stored some dumps of the tcpcb at > http://people.freebsd.org/~peter/tcpcb.txt > Note that some in the tcpcb.txt file also have > snd_limited =3D 2 '\002', >=20 > Over the last few days I've tried things like turning off sack, tso, = the > various rfc knobs etc. I believe they're all back to normal now. >=20 > There's small ~15 second tcpdump sample of the sender side and the = receiver > side at: http://people.freebsd.org/~peter/send.cap.gz and > http://people.freebsd.org/~peter/recv.cap.gz > Both ends were ntp synced. The dumps have no sensitive data. >=20 > For amusement, I just tried this, with roughly 1 second in between: > peter@bme:~ % scp pkg-ysv:k.gz /tmp > k.gz 100% 25MB 5.0MB/s 00:05 > peter@bme:~ % scp pkg-ysv:k.gz /tmp > k.gz 0% 960KB 20.3KB/s 41:29 ETA^C >=20 > There was no pre-existing hostcache state between those two endpoints = for > the first run. At the end, this was created in the hostcache: > IP address SSTRESH RTT RTTVAR BANDWIDTH CWND > 213.138.. 5952 165ms 21ms 0 8688 > All connections went slow after that. Note that the ssh test was over = ipv4 > - the rest above is on ipv6. However, we're seeing the same weird = stuff > with http over ipv4 as well between the same two endpoints. >=20 > It was pointed out to me that this has come up before, eg: misc/173859 > I know we've seen this at work as well. >=20 > A few days earlier we were pushing ~45MB/sec (bytes, not bits) between = these > endpoints. Out of the blue it crashed to ~10KB/sec. Why can't it get = out of > slow-start? Is it even stuck in slow-start like I think? Is the = 148-155ms > bimodal rtt the problem? >=20 > Any insight would be greatly appreciated. (please don't drop me from = cc:) Looking at the receiver tracefile shows that there is some message loss. This limits the throughput... Do you also observe a message loss rate = when using ping? Best regards Michael > --=20 > Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; = KI6FJV > UTF-8: for when a ' just won\342\200\231t do. >=20 From owner-freebsd-net@FreeBSD.ORG Sat Jan 4 22:36:48 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F005DBE for ; Sat, 4 Jan 2014 22:36:48 +0000 (UTC) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DDA5A1738 for ; Sat, 4 Jan 2014 22:36:47 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s04Majdj026167; Sat, 4 Jan 2014 17:36:45 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.7/8.14.4/Submit) id s04MaiBn026166; Sat, 4 Jan 2014 17:36:44 -0500 (EST) (envelope-from wollman) Date: Sat, 4 Jan 2014 17:36:44 -0500 (EST) From: Garrett Wollman Message-Id: <201401042236.s04MaiBn026166@hergotha.csail.mit.edu> To: peter@wemm.org Subject: Re: Long-haul problems - connections stuck in slow start X-Newsgroups: mit.lcs.mail.freebsd-net In-Reply-To: References: <52C85537.7080307@wemm.org> <52C85EED.801@wemm.org> Organization: none X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Sat, 04 Jan 2014 17:36:45 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 22:36:48 -0000 In article , Peter Wemm writes: >I'm looking at the duplicate acks in this trace from each end.. any >clues where they're coming from? My original suggestion was going to be that they're probably a result of your packets getting reordered because of that path instability you pointed out. 10 ms differential delay is much higher than the interarrival time should be, so you likely have a burst of packets headed down the slow path, followed by a burst of packets down the fast path, and the later packets arrive at the destination first, causing a burst of dupacks until the slow packets catch up. But that doesn't seem to be born out by your traces. Do you have TCP RX offload on this hardware? Could it be sending the dupacks without looping them back to BPF? (I haven't looked at our TCP offload code so I have no idea if that's even possible.) -GAWollman From owner-freebsd-net@FreeBSD.ORG Sat Jan 4 22:45:54 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87662EA3; Sat, 4 Jan 2014 22:45:54 +0000 (UTC) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1446217C6; Sat, 4 Jan 2014 22:45:54 +0000 (UTC) Received: by mail-qc0-f177.google.com with SMTP id m20so16060033qcx.8 for ; Sat, 04 Jan 2014 14:45:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=AJXuc/x/qKfXCCM36at2pa7tO7xJymXqROB2KDqcgmY=; b=kGWeb7r9h/h8FjtjUUGsFZRFzfMKiFGR4F0QJIyjAneeZ0mN49wAgHLgyS8Cvh+PHQ PT8ggPBtUi+7vfqqzh+z4wLepFIEx08G14q1PCa8LvKJ0X33xb+1btAtFprMwQBuzwAW lNuXKZuJWgsAuapv8yKSttlpNkCp2V6w0kw6ITYgcyswxf9t981Ur5i3tAHHmlNrKvsg qiXVDHq0N/YYXmBWOja/3MhbogjK3/YgF0eXys0BdEzzVaoLEQuKbzn4tr48gQfUaWHT pKV69LT+Aq4gRfmPGPvUs7xvhsqOiBOdr6Zlt/YbU4htkSXWFBfwOhZNzJA+CLoPbs8Q Q2lA== MIME-Version: 1.0 X-Received: by 10.49.38.37 with SMTP id d5mr168316539qek.17.1388875553213; Sat, 04 Jan 2014 14:45:53 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Sat, 4 Jan 2014 14:45:53 -0800 (PST) In-Reply-To: References: <521B9C2A-EECC-4412-9F68-2235320EF324@lurchi.franken.de> <201312131326.28952.jhb@freebsd.org> <201312131717.10863.jhb@freebsd.org> <0BC9D25E-639A-4305-A51A-222AE645152C@lurchi.franken.de> Date: Sat, 4 Jan 2014 14:45:53 -0800 X-Google-Sender-Auth: o1Oum4gJl8bE9JRJxyq0SMTAuOo Message-ID: Subject: Re: A small fix for if_em.c, if_igb.c, if_ixgbe.c From: Adrian Chadd To: Michael Tuexen , Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Cc: Yong-Hyeon Pyun , FreeBSD Net , John-Mark Gurney , Jack F Vogel , John Baldwin X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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 Jan 2014 22:45:54 -0000 hi, Happy New Year all. If noone objects, I'm going to commit Michael's patch to -HEAD in the next couple of days, with some extra comments explaining why things are the way they are. We can then flesh out the comments and API documentation about this stuff. Thanks! -a On 16 December 2013 19:25, Adrian Chadd wrote: > On 16 December 2013 13:04, Michael Tuexen > wrote: >> On Dec 16, 2013, at 9:15 PM, Adrian Chadd wrote: >> >>> On 16 December 2013 12:06, Michael Tuexen >>> wrote: >>> >>>>> i agree. if_transmit() should return 0 only if: >>>>> >>>>> * the driver queued it internally and intends to try transmitting it later; >>>>> * the driver directly dispatched the frame to the hardware. >>>>> >>>>> If it failed to do either of the above, it should return an error. >>>>> >>>>> How's that sound? >>>> That sounds good. However, The transport layer is interested in the case >>>> where if_transmit() returns a non-zero value. >>>> Does your statement imply: >>>> if_transmit() returns a non-zero value only if the packet will not >>>> make it on the wire (for example, it failed to queue it). >>> >>> If there's a queuing layer in the middle then we can't know that for >>> certain. If the driver can't transmit the frame (eg it fails because >>> of collisions, for example) then again, we can't know that for >>> certain. >>> >>> What we can only know is that it was either queued and may or may not >>> make it on the wire, or it wasn't queued/transmitted and it definitely >>> _won't_ make it on the wire. >> Correct. And I'm only interested in the "it wasn't queued/transmitted >> and it definitely _won't_ make it on the wire." part. >> So I would need something like >> >> if_transmit() returns an error only if it wasn't queued/transmitted >> and it definitely _won't_ make it on the wire. >> >> Acceptable for you? > > Sounds like the same thing to me, so yes. :) > > > > -a