[ previous ] [ next ] [ threads ]
 
 From:  "Molle Bestefich" <molle dot bestefich at gmail dot com>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: MAC address problems?
 Date:  Thu, 18 May 2006 11:35:40 +0200
Tom Anderson wrote:
> Did you try using Chris's guide on his website?
>
> http://chrisbuechler.com/m0n0wall/nokia/ip110.html

Going to try that today, thanks!


Chris Buechler wrote:
> Uh, that's not the solution.  Read that article more closely.
> pfsense, and FreeBSD 5.x and 6.x, won't boot on IP110's.

Damn, you're right, I wasn't paying attention.

Using pfSense, the kernel dies with a page fault when it's
initializing the PCI bus.

Too bad, things would have been much simpler with console over serial
that pfSense has.

I mean, when this box dies on me one day, I'll have to find a
replacement fast to keep the downtime on web sites etc. low.  I might
choose a box which is not exactly an IP110.  There should be as little
fiddling as possible, so I can get everything in the air as quickly as
possible.

The automatic interface detection and "1 xml config file" principle is
great, but it's outplayed if I have to shift the IDE disk back and
forth between two boxes:
 * first add an image (box 1), then
 * autodetect the interfaces (box 2), then
 * add spoofmac entries in config.xml using some OS that can
read/write UFS (box 1)
 * merge in non-interface parts of old config.xml (box 1)
 * finally boot new system (box 2).

There's a high risk that I'm going to forget half of this :-/.

Oh well, enough moaning :-).


Craig wrote:
> Yeah - you need to edit your config.xml file and add a
>   <spoofmac>00:99:c0:ed:ba:be</spoofmac>
> line for each device of fxp0, 1, and 2
>
> Remember you can use 00 to FF, and there have to be 6
> octets separated by colons.
> Each NIC must have a different MAC address.
> The first octet should be 00:
> (actually I believe it can be any even number but lets keep it simple)

Thanks!

I've tried to find out which MAC's to avoid.
In case anyone else might be interested...

I've looked up this:
 * 1st octet, bit 0x1 means "group addressing" (multicast, broadcast, etc)
 * 1st octet, bit 0x2 means "locally administered address"
(software-assigned / private)

Of the group (bit 0x1 set) addresses, some has distinct meaning:
 * Bit 0xF0 in 4th octet means "other multicast" (vs. "internet multicast")
 * All bits set in all octets (ff:ff:ff:etc) means "broadcast"
 * 01:80:C2:xx:xx:xx are used for fx. STP (and thus filtered) by IEEE
802.1D compliant bridges
 * 01:00:5E:(00:00:00-7f:ff:ff) are IANA IP multicast addresses
 * 01:00:5E:00:00:05 is reserved for OSPF
 * 09:00:2B:00:00:0{4,5} is reserved for ISO 9542 (routing exchange protocol)
 * Lots of equipment discovery protocols uses specific group addresses
(fx. Cisco CDP uses 01:00:0C:CC:CC:CC)
 * Probably many others...

What a jungle.
Lucky I don't need a group address, so none of the above matters.
Ahem :-)...

Of the non-group addresses (bit 0x1 not set), some has special meaning too:
 * The "fe:fd" range of mac addresses are reserved for personal use by
the IEEE (seen on the xen-users list)
 * I've seen "fe:ff" used somewhere too, but I guess that's just a typo.

I think I'll try to restore the IPSO software and see what MAC
addresses it assigned to the interfaces and grab those.  If that goes
wrong, I'll use fe:fd:RR:RR:RR:0{1,2,3} where R is some random number
I make up for my box.

Gah :-)...

By the way, now I don't understand why the 4d:4d:00:00:00:00 address
doesn't work.  Seems like a perfectly legal non-group address to me?