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 02:50:24 -0800	[thread overview]
Message-ID: <CAA93jw79xMAc+Ru0ffEctYzvqs7F33Mgi380XL107mWU12kRPQ@mail.gmail.com> (raw)
In-Reply-To: <1E158A98-D7F5-489F-89B6-B1673FBB8E84@intermapper.com>

On Thu, Mar 1, 2012 at 8:22 PM, Richard Brown
<richard.e.brown@dartware.com> wrote:
> While I was posting a note about 3.3-rc5-1 and tidying the site, I noticed that the table on the Default Network Numbering page (http://www.bufferbloat.net/projects/cerowrt/wiki/Default_network_numbering) was incorrect - it still showed the default se00 at 172.30.42.33. It's fixed. I also added a row for ge00 as the public IP.

thx!

>
> 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 the same for 3.3.)

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 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.)

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.

>
> - 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'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.

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.

>
> - 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. In the case of ipv6 autoconfiguration,
you get EUI-64s based on the underlying
mac addresses, which are long...

In the case of 6to4 autoassignment ( the openwrt feature that didn't
work for me in this week's test), each interface gets a
2002:X:Y:Z::1/64
where Z=1 for se00, and increments by one for every interface
configured for the ge01 device.

In the case of using dhcp-pd youu can either use ipv6
autoconfiguration for the downstream nodes, or install a dhcpv6 server
to give more rationally numbered clients.
>
> Best,
>
> Rich
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>



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

  reply	other threads:[~2012-03-02 10:50 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 [this message]
2012-03-02 15:37     ` Richard Brown
2012-03-02 15:56       ` Dave Taht
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=CAA93jw79xMAc+Ru0ffEctYzvqs7F33Mgi380XL107mWU12kRPQ@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