No edit summary |
No edit summary |
||
| Line 7: | Line 7: | ||
=== INTEL MAC === | === INTEL MAC === | ||
<pre> | <pre> | ||
00:16:CB Macbook and Mini | 00:16:CB Macbook and Mini | ||
00:17:F2 Macbook | 00:17:F2 Macbook | ||
00:1F:F3 Macbook | 00:1F:F3 Macbook | ||
00:22:41 Macbook Pro | |||
</pre> | </pre> | ||
=== PPC MAC === | === PPC MAC === | ||
<pre> | <pre> | ||
00:03:93 G3 iBook, G4 tower | |||
00:0A:95 G5 | |||
00:0D:93 G5, G4 Powerbook, G4 iBook | |||
00:14:51 G5 | 00:14:51 G5 | ||
00:30:65 G3 iMac 400MHz | 00:30:65 G3 iMac 400MHz | ||
</pre> | </pre> | ||
Revision as of 17:24, 18 December 2008
Warren is trying to do the foolish task of figuring out if Apple MAC address prefixes are unique between PPC and Intel Macs. Please e-mail wtogami at redhat dot com if you have any MAC not already listed to add to the prefixes listed below. I especially want to know if you found a MAC address that upsets the trend.
Built-in Ethernet only! I only care about netboot, so wireless and add-on cards are not important here.
Why is Warren doing this? DHCP server has no other way of knowing the client is a PPC to give it a PPC netboot root-path. DHCP server can see the AAPLBSDPC vendor-client-identifier and correctly gives it yaboot, which then downloads kernel/initrd and boots Linux. But the initrd does DHCP discover a second time with the unhelpful vendor-client-identifer "nash".
INTEL MAC
00:16:CB Macbook and Mini 00:17:F2 Macbook 00:1F:F3 Macbook 00:22:41 Macbook Pro
PPC MAC
00:03:93 G3 iBook, G4 tower 00:0A:95 G5 00:0D:93 G5, G4 Powerbook, G4 iBook 00:14:51 G5 00:30:65 G3 iMac 400MHz