No edit summary |
No edit summary |
||
| Line 20: | Line 20: | ||
00:03:93 G3 iBook, G4 tower | 00:03:93 G3 iBook, G4 tower | ||
00:05:02 G3 333MHz Radeon 7000 | 00:05:02 G3 333MHz Radeon 7000 | ||
00:0A:27 | |||
00:0A:95 G5 | 00:0A:95 G5 | ||
00:0D:93 G5, G4 Powerbook, G4 iBook | 00:0D:93 G5, G4 Powerbook, G4 iBook | ||
| Line 30: | Line 31: | ||
=== UNIDENTIFIED === | === UNIDENTIFIED === | ||
<pre> | <pre> | ||
</pre> | </pre> | ||
Revision as of 18:44, 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", where it cannot differentiate i386 and PPC.
INTEL MAC
00:16:CB Macbook and Mini 00:17:F2 Macbook 00:1B:63 Macbook Pro 00:1F:F3 Macbook 00:1F:5B Macpro 00:1F:F3 Macbook Pro 00:22:41 Macbook Pro
PPC MAC
00:03:93 G3 iBook, G4 tower 00:05:02 G3 333MHz Radeon 7000 00:0A:27 00:0A:95 G5 00:0D:93 G5, G4 Powerbook, G4 iBook 00:11:24 G4 Mac Mini 00:14:51 G5 00:30:65 G3 iMac 400MHz 00:50:E4