Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: Richard Brown <richard.e.brown@dartware.com>
Cc: "<cerowrt-devel@lists.bufferbloat.net>"
	<cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] CeroWrt port numbering
Date: Fri, 2 Mar 2012 07:56:08 -0800	[thread overview]
Message-ID: <CAA93jw7mGC0DXiLekjug0S3ecMFZ02jOjuWZTBznKZ-KgtRGxA@mail.gmail.com> (raw)
In-Reply-To: <BB299907-3375-4ED0-82C1-6B50FB8AEDBF@intermapper.com>

On Fri, Mar 2, 2012 at 7:37 AM, Richard Brown
<richard.e.brown@dartware.com> wrote:

>
> I don't (yet) have facilities for testing IPv6 here, so I can't offer any advice

I'm going to get to where I have a ula generating script to make that
easier. soon. (unfinished draft  in ceropackages/ipv6/ipv6policy)

>>> - I'm a little surprised that the babel interfaces both have ...224/32. (But I don't know anything about babel...)
>>
>> 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.
>>
>> It makes failover simpler in the mesh routing case.
>
> I was just curious whether they were meant to be the same /32 address...

yes. The routing scheme figures out the right interface with using the
/32 or a /128 on the same ip.

www.pps.jussieu.fr/~jch/software/babel/wbmv4.pdf

I'd been doing mesh networking for a long time prior
to this project. I still find it kind of wierd to disconnect
from my wired interface and go wireless and lose all
my ssh connections. Others seem to find this normal,
but it makes me mildly nuts.

with a full mesh config, which is not the default cero can
fails over to wireless in a split second,
moves back to wired in a few seconds when you plug in the wired
connection, no connection loss, no muss no fuss.



>
>>> - 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 that by design?
>>
>> Two issues:
>>
>> 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 byte is the "local" bit; the 0x01 bit is the multicast bit. See:  http://en.wikipedia.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...
>
> I still don't understand the reasoning behind the mix and match (see list below). Why wouldn't you put all the wireless together as C4:... and Ethernet on the other? Or divide by 2.4GHz or 5GHz? or Secure vs. Guest, or some other scheme? (Or is it purposely to prevent people like me from imputing meaning where none is needed? :-)

I think your diagnosis is correct.

>>> - 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?
>>>
>>> - I also note that the MAC addresses sort to an odd order, intermixing ethernet and wireless. (This is related to the previous item.)
>>>
>>> sw00    C4:3D:C7:9D:E3:9A
>>> ge00    C4:3D:C7:9D:E3:9B
>>> sw10    C4:3D:C7:9D:E3:9C
>>>
>>> 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
>>
>> Hopefully what I wrote above sort of explains this.
>>
>>> - Finally, I haven't fired up 6to4 or anything, but will the global IP address assignments be randomized more than the local (fe80) address?
>>
>> Not sure what you mean here.
>
> Privacy advocates are saying that the "easy way" to create a global IPv6 address 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 powerful) 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/105438-Barrera.pdf )

This debate has been going on for a decade.

I would like all those trying to make ipv6 even harder for mere
mortals to use to go off and work on ipv7, hip, and the like.

DNS naming has been hopelessly screwed up as it is, and while I'm a
big privacy advocate, I'd like ip addresses to be mapped to DNS names
and I figure that that will bug that crowd, too.

See also 'dname debacle'

http://www.ietf.org/mail-archive/web/ipv6/current/msg08079.html

> Thanks!
>
> Rich
>
>



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net

  reply	other threads:[~2012-03-02 15:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.2.1330632002.8558.cerowrt-devel@lists.bufferbloat.net>
2012-03-02  4:22 ` Richard Brown
2012-03-02 10:50   ` Dave Taht
2012-03-02 15:37     ` Richard Brown
2012-03-02 15:56       ` Dave Taht [this message]
2012-03-02 16:26         ` Dave Taht
2012-03-02 16:51           ` Dave Taht

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAA93jw7mGC0DXiLekjug0S3ecMFZ02jOjuWZTBznKZ-KgtRGxA@mail.gmail.com \
    --to=dave.taht@gmail.com \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=richard.e.brown@dartware.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox