From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from TX2EHSOBE001.bigfish.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.global.frontbridge.com", Issuer "Microsoft Secure Server Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 3EB2420024C for ; Fri, 2 Mar 2012 07:38:04 -0800 (PST) Received: from mail53-tx2-R.bigfish.com (10.9.14.236) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.23; Fri, 2 Mar 2012 15:38:02 +0000 Received: from mail53-tx2 (localhost [127.0.0.1]) by mail53-tx2-R.bigfish.com (Postfix) with ESMTP id 11300E0600; Fri, 2 Mar 2012 15:38:02 +0000 (UTC) X-SpamScore: -10 X-BigFish: VPS-10(zz103dK1432Nzz1202hzz122ac1I8275dhz31h2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: softfail (mail53-tx2: transitioning domain of dartware.com does not designate 157.56.244.213 as permitted sender) client-ip=157.56.244.213; envelope-from=richard.e.brown@dartware.com; helo=CH1PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail53-tx2 (localhost.localdomain [127.0.0.1]) by mail53-tx2 (MessageSwitch) id 1330702679860881_17593; Fri, 2 Mar 2012 15:37:59 +0000 (UTC) Received: from TX2EHSMHS036.bigfish.com (unknown [10.9.14.242]) by mail53-tx2.bigfish.com (Postfix) with ESMTP id CBA3D2E004D; Fri, 2 Mar 2012 15:37:59 +0000 (UTC) Received: from CH1PRD0510HT003.namprd05.prod.outlook.com (157.56.244.213) by TX2EHSMHS036.bigfish.com (10.9.99.136) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 2 Mar 2012 15:37:57 +0000 Received: from CH1PRD0510MB381.namprd05.prod.outlook.com ([169.254.11.57]) by CH1PRD0510HT003.namprd05.prod.outlook.com ([10.255.150.38]) with mapi id 14.16.0123.000; Fri, 2 Mar 2012 15:37:53 +0000 From: Richard Brown To: Dave Taht Thread-Topic: [Cerowrt-devel] CeroWrt port numbering Thread-Index: AQHM+CwJkRiRI4QZUEmPHa3qap5DJZZW1DIAgABQUIA= Date: Fri, 2 Mar 2012 15:37:52 +0000 Message-ID: References: <1E158A98-D7F5-489F-89B6-B1673FBB8E84@intermapper.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.150.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: dartware.com Cc: Richard Brown , "" Subject: Re: [Cerowrt-devel] CeroWrt port numbering X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 15:38:04 -0000 >> This led me to look at the various tables made available via SNMP, and I= had a couple consistency questions. (See the attached spreadsheet for the = data, especially rows 58-66. It was taken from bql-40, but I believe it's t= he same for 3.3.) >=20 > I won't be able to look into the snmp stuff until next week. > I'd like to know how well that is working with ipv6, btw, overall. I don't (yet) have facilities for testing IPv6 here, so I can't offer any a= dvice >> - I note that there's no interface at 172.30.42.33/27. I believe this is= correct, but just checking. (It's thinkable that the se00 wired interface = could go to a /26 if more wired devices were needed. But let's keep to the = rule "Everything's a /27" for a while longer.) >=20 > I thought about widening the default /27 in this case, but long on my > mind has been getting to where vlans could be successfully used and > tested, so mentally that's 'reserved for > dmz vlan'. This was actually why .33 was used instead of .1 for the > main router interface in the early days, but too many people found > that puzzling. Good choices (both reserving for dmz vlan and switching to .1) >> - I'm a little surprised that the babel interfaces both have ...224/32. = (But I don't know anything about babel...) >=20 > Actually that's an 'AHCP'-ism. Babel is capable of mesh routing, and > with p2p wireless links nothing more than a /32 or /128 (for ipv6) is > needed to be distributed on mesh node links. >=20 > It makes failover simpler in the mesh routing case. I was just curious whether they were meant to be the same /32 address... >> - I'm confused about the OUI's for the interfaces. As expected, C4:3D:C7= ... is the OUI for Netgear. But C6:3D:C7... isn't allocated to anyone. Is t= hat by design? >=20 > Two issues: >=20 > There is no separate mac address for one of the network devices on the > wndr, so we take a known good address from one of the devices, and > flip the 'local mac' bit. Ahah. I learn something every day. The 0x02 bit of the most significant byt= e is the "local" bit; the 0x01 bit is the multicast bit. See: http://en.wi= kipedia.org/wiki/Organizationally_Unique_Identifier > Each wireless VIF creates it's own mac address as well, based on > incrementing the underlying mac, and I don't remember the algo > offhand. Yes, that makes sense. But...=20 I still don't understand the reasoning behind the mix and match (see list b= elow). Why wouldn't you put all the wireless together as C4:... and Etherne= t on the other? Or divide by 2.4GHz or 5GHz? or Secure vs. Guest, or some o= ther scheme? (Or is it purposely to prevent people like me from imputing me= aning where none is needed? :-) >> - I don't understand the pattern of the OUIs for the interfaces: why is = the C4 prefix issued to the Ethernet ge00 and wireless sw00 and sw10, while= C6 goes to Ethernet se00 and the remaining wireless interfaces? >>=20 >> - I also note that the MAC addresses sort to an odd order, intermixing e= thernet and wireless. (This is related to the previous item.) >>=20 >> sw00 C4:3D:C7:9D:E3:9A >> ge00 C4:3D:C7:9D:E3:9B >> sw10 C4:3D:C7:9D:E3:9C >>=20 >> se00 C6:3D:C7:9D:E3:9A >> gw00 C6:3D:C7:9D:E3:9B >> gw01 C6:3D:C7:9D:E3:9C >> gw10 C6:3D:C7:9D:E3:9D >> gw11 C6:3D:C7:9D:E3:9E >=20 > Hopefully what I wrote above sort of explains this. >=20 >> - Finally, I haven't fired up 6to4 or anything, but will the global IP a= ddress assignments be randomized more than the local (fe80) address? >=20 > Not sure what you mean here. Privacy advocates are saying that the "easy way" to create a global IPv6 ad= dress is bad: it's too easy to plop the MAC address in the lower 64 bits of= your address, and then the bad guys can use that as another (really powerf= ul) tracking identifier. This is clearly not a CeroWrt-specific issue, and = it's actively in discussion. (See, for example Barrera et al, in the Usenix= Vol 36, Number 1, https://www.usenix.org/system/files/login/articles/10543= 8-Barrera.pdf ) Thanks! Rich