No edit summary |
|||
| (One intermediate revision by one other user not shown) | |||
| Line 7: | Line 7: | ||
=== INTEL MAC === | === INTEL MAC === | ||
<pre> | <pre> | ||
00:16:CB Macbook | 00:16:CB Macbook, Mac Mini, iMac | ||
00:17:F2 Macbook | 00:17:F2 Macbook | ||
00:19:E3 Macbook | 00:19:E3 Macbook | ||
| Line 32: | Line 32: | ||
=== UNIDENTIFIED === | === UNIDENTIFIED === | ||
<pre> | <pre> | ||
00:A0:3F | 00:A0:3F Probably Intel but would be good to have verification. | ||
</pre> | </pre> | ||
Latest revision as of 19:54, 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, Mac Mini, iMac 00:17:F2 Macbook 00:19:E3 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
UNIDENTIFIED
00:A0:3F Probably Intel but would be good to have verification.
TOO OLD TO MATTER
00:A0:40 http://www.macintouch.com/ethernetbugs_old.html 08:00:07 http://www.macintouch.com/ethernetbugs_old.html