Region X is the program to use. It was written by XVI and works beautifully.

However, it will only work on drives that are hacked, as you said.

The more-direct D/L location is here:

xvi.rpc1.org/region.html

Which DVD-ROM do you have?

hi, where do i get pirates? and why do they not have a region code?
thanks Sina i have the same problem like you

No, your drive is RPC-2, which is how it shipped. There isn't currently a hacked firmware for your drive. Sorry.

Although a lot of reports are saying it doesn't work still. Do you see any success with it?

The address 01:23:45:AB:CD:EF is not a valid station address. There are two general rules to remember regarding ethernet addresses:

- If bit 0 in the first octet is set, the address is a multicast address. If it's clear, it's a unicast address.
- if bit 1 in the first octet is set, the address is locally defined instead of globally assigned.

So 01:23:45:AB:CD:EF is a multicast address, because bit 0 is set in the first octet (01). A unicast address represents a single destination: on a given ethernet network, only one station should have its receive filter programmed to receive ethernet frames with this destination address in its header. A multicast address represents a group: a frame with a multicast destination address may be received by any number of stations on a given ethernet network, if those stations have joined the group. (IPv6 is one of the things that depends on multicasting to work correctly.)

The address ff:ff:ff:ff:ff:ff is the broadcast address: a frame sent to this address is picked up by all stations on the same ethernet network. (The network stack may discard it later, but the ethernet controller will always accept broadcast frames and pass them up the line to the stack.) It's technically a special case of a multicast (or more accutately, the degenerate case): with regular mutlcasts, a station can choose to join a given group or not, but all stations implicitly are members of the "broadcast group."

A locally defined address is one that you pick out of a hat for temporary use (or testing). One place they're used a lot these days is for adhoc wireless networks. When you join a bunch of systems together in an adhoc net (i.e. without an access point), the first station that comes up on the network makes up a BSSID address which represents the adhoc cell that all the other stations should join. This address is only used while the adhoc cell exists and isn't assigned by the manufacturer, so it has bit 1 set. A globally defined address on the other hand is assigned by the manufacturer and is supposed to be globally unique -- no other device in the world should have the same address. (The IEEE is responsible for delegating blocks of addresses to hardware vendors to ensure there aren't any duplicates.)

Anyway, 00:01:02:03:04:05 would be a valid station address. 02:03:04:05:06:07 would also be valid, and would be an example of a locally defined address that won't be confused with any other vendor's address range. You can't use multicast addresses as station addresses because some pieces of networking hardware and network stacks handle them specially. (Ethernet switches usually "flood forward" multicast frames to all ports, whereas unicast frames are sent only to the port where the switch knows the destination station is connected.)

(This particular problem seems to crop up at work every couple of months. We have customers who build their own networking gear and I sometimes get support calls routed to me with complaints about simple connectivity tests failing in their lab. When I prod for details, I find out that the engineer doing the tests thought it would be ok temporarily set the MAC address on the prototype board to 01:02:03:04:05:06. Once they I convince them to change it, their connectivity problems miraculously vanish.)

I would try the following (with root privileges):

# ifconfig en0 down
# ifconfig en0 lladdr 00:01:02:03:04:05
# ifconfig en0 up

Afterwards, do "ifconfig en0" and check the output. If it shows the new address instead of the old one, then it should begin using the new address. If not, I would consider that a bug.

Note that two things that should happen:

- the OS should begin using the new address when sending frames on that interface
- the driver should program the receive filter in the underlying ethernet chip so that it will accept frames with
the new address (and ignore frames with the old address)

The first step depends entirely on the OS and is independent of the underlying driver. When the OS boots and the network driver is loaded, one of the first things it does is report the interface's station address to the network stack. (The address is usually stored in an EEPROM or other non-volatile memory connected to the ethernet controller chip, and the driver retrieves it during initialization -- it may also save a private copy of its own.) The network stack saves a copy of this address in one or two places. When assembling a frame for transmission, the stack grabs that address and inserts it into the source address field of the ethernet frame header. The lladdr ioctl should update all of the saved copies of the address inside the kernel, so once changed, all new frames will be sent out with the new address.

The second step depends on the driver. The ioctl should eventually filter down to the driver level, and once it receives the request to update the address, it should update its private copy (if it has one) and then reset the receive filter on the ethernet chip. The chip itself checks the headers on all incoming frames and will silently ignore all unicast frames that don't match its station address. In order to accept frames for the new address, the driver has to update the filter. This is usually pretty simple and can typically be done on the fly without even resetting any of the other receiver logic.

The comments in that article you linked to seem to indicate that the lladdr ioctl works for en1 (the wireless port) but not en0 (the ethernet port) on some machines, notably the Macbook Pro. Given that it does work at least for en1, that implies that the OS-specific parts of the address update are working correctly, and that the driver for the en1 interface is handling the update properly as well. This tends to point to a bug in the ethernet driver for the en0 interface.

I think the Macbook Pro (and in fact most recent Intel Macs with integrated ethernet) use the Marvell Yukon II chip. It's unclear whether the old address update command worked with the same chip previously and simply stopped working when Apple change the command from "ether" to "lladdr" or if it was broken all along. If it did used to work, then it's possible that any kernel changes that were made in conjunction with changing the command weren't propagated to the Marvell driver. If it never worked, then this particular driver is just busted.

If my suggestion of stopping and restarting the inderface as shown above doesn't work, here's an experiment someone can try to help narrow down the problem:

1) Use the ifconfig command to change the station address on en0 as shown above
2) Connect the Mac's ethernet port directly to a PC or other system running Wireshark/Ethereal,
tcpdump, or some other packet sniffer (these are all free programs)
3) On the Mac, do something to generate some network traffic (using ping from the terminal window
is one sure fire way, though MacOS is pretty chatty and will probably start sending some packets
on its own if you wait long enough)
4) Capture some of the packets originating from the Mac

There are a couple of possible results:

1) You fail to capture any packets at all
2) Packets are captured, but they still have the old MAC address
3) Packets are captured, and they have the new address

If you can't get the Mac to send any packets at all once you change the address, then this might mean that whoever wrote the ethernet driver decided to write the driver so that it will refuse to send any frames with a different address than the factory assigned one. It's highly unlikely this will be the case, but you never know.

If the you see frames, but they have the old address, then the chip may have a feature where it can automatically insert its station address into the ethernet frame header, and the driver has left the chip programmed to continue to use the old address. This is also unlikely: I've only seen a couple of chips that support this feature, and I don't think the Yukon II is one of them. There's also the slight chance that the driver code is "helpfully" forcing the source address to the one read from the EEPROM, but again this is also unlikely.

If you see frames and they have the new address, then the lladdr ioctl was at least partially successful: it did update the OS's copies of the MAC address. This means the TX path is working correctly. At this point, you should try to set up the Mac and the computer on the other end of the cable to try talking to each other. If that fails (as I expect to be the case), then it means the problem is in the RX path: the driver has not updated the RX filter on the Yukon II like it should have (or maybe it updated it incorrectly), so it isn't accepting frames for its new address.

If I'm right, then there's one possible workaround you can try:

# ifconfig en0 down
# ifconfig en0 lladdr 00:01:02:03:04:05
# ifconfig en0 up
# ifconfig en0 promisc

The last command should but the interface in promiscuous RX mode. In this mode, the RX filtering is disabled and the receiver will accept all frames regardless of their destination address. So if even if the RX unicast filter hasn't been updated, this should force the interface to receive frames with the new address anyway. This assumes of course that the driver has implemented promiscuous mode correctly too. :P Once you use the "promisc" command, "ifconfig en0" should show that the IFF_PROMISC flag is now set for the interface.

One last point to consider: I'm pretty sure that the code in the Marvell Yukon II driver that Apple ships was mostly written by Marvell rather than Apple. It's hard to say how many people at Apple have the necessary expertise to fix the problem themselves, especially if the bug is anywhere inside the hardware dependent code rather than the IOKit code which has undoubtedly been layered on top of it. This may explain why Apple hasn't fixed this bug yet: they have to get Marvell to do it.

Hm. I seem to have rambled on a bit. Apologies if I'm being boring. :)

-Bill

FM3J is the firmware revision. Run the "region free" one only. The other is to return the device back to RPC-2.