How to Fix iMessage

[jaymonkey]

I can't wait to go home and see if this issue has affected my UP5-TH build. If Apple is collecting/blocking users on such systems, why do it through iMessage. Seems to be a soft way or generally insignificant way of blocking hackintoshes. Why not go full monty and block iTunes/icloud and software updates? While iMessage is pretty cool feature, it isn't vital.

Having said though, I'm a iMessage junky and hope this can be resolved.

@Wolfie81

I'll keep my fingers and toes crossed for you buddy, but it does look like UP5-TH systems are affected the most by this recent issue, to my knowledge no one with a UP5-TH mobo has iMessage working right now.

I agree it seems odd for Apple to target iMessage and not the other eco services such as Appstore and Updates ... etc, I believe that we are looking at more than one issue though as hypothesised in post #291 we could be looking at some sort of check against S/N / MAC Addr / UUID and maybe a Black/White list against the Organizationally Unique Identifier (OUI) of each MAC address ?

Let me know how things are once you get back and we'll take it from there.

Cheers
Jay

 

[arehep]

i`ve tryid to spoof the macaddress on both wifi and lan with 2 random generated id´s optaind using this terminal cmd.

openssl rand -hex 6 | sed 's/\(..\)/\1:/g; s/.$//'

And then

sudo ifconfig en0 ether xx:xx:xx:xx:xx:xx (my ethernet)

(replace “xx:xx:xx:xx:xx:xx” with the generated)

(For this cmd to take affect you have to do it twice (repeat after enter adminpass))

For my wifi.

sudo ifconfig en1 ether xx:xx:xx:xx:xx:xx


When i type ifconfig i can se the changes but when i open Network Utility.app there´s no changes.
And still no iMessage

I did´nt try to make a new SmBios..plist as it requires a reboot to take affect and then you´ll loose the spoofed macadresses as a reboot resets these id´s to the (original) hardcoded.

There´s a tool that apparently can auto generate after reboot but i did´nt manage to get it working

https://github.com/feross/SpoofMAC

Maybe some of you could give it a try

I hope i don’t violate the rules here on the forum as spoofing a MAC address is not illegal.
And there`s threads here on how to rebrand Broadcom wifi cards.
Rebranding these cards is about changing vendor and sub vendor id´s and also region code and when that´s possibly why not Mac address ?

 

[jaymonkey]

i`ve tryid to spoof the macaddress on both wifi and lan with 2 random generated id´s optaind using this terminal cmd.

@arehep

Thanks for your feedback

I'm not 100% sure but I don't think that method changes the Organizationally Unique Identifier (OUI) of a MAC address. Quote from Wiki MAC Address page:-

A locally administered address is assigned to a device by a network administrator, overriding the burned-in address. Locally administered addresses do not contain OUIs.

If Apple have introduced some sort of black or white list against MAC addresses it could only work against the OUI. I'm sure there is way it can be done but its going to take a little more ingenuity.

Cheers
Jay

 

[arehep]

Because that is the behaviour of a real mac, nether S/N or LAN MAC address would ever change.

We need to collect more information on systems that are suffering from this recent issue, I think a good start would be comparing the first three octets of MAC address's (the OUI), to see if there is a patten which could be identified against a black or white list on Apple's servers.

Cheers
Jay

Is this what you´re asking for ?

My Ethernet 90:2b:34:xx:xx:xx

My Wi-fi c4:17:fe:xx:xx:xx

If so ---
to all reporting iMessage problems please submit yours

You can optain these values by typing ifconfig in Terminal or open Network Utility.app

 

[mhollow]

I don't think so (simply blacklisting by OUI).
Look, there are may legal NICs such as Sonnet, and others which has MACintosh support natively OOB and can be legaly inserted in any MacPro.
I own two of them - Sonnet Presto and HP NC360T and both DON't work (I mean in terms of iMessage of cause) even with new generated serial.
And as far as I know, GA-UP5 has Intel Lan i210 chip which is also supports natively. So why Apple should block this OUI?

If Apple have introduced some sort of black or white list against MAC addresses it could only work against the OUI. I'm sure there is way it can be done but its going to take a little more ingenuity.

 

[jaymonkey]

I don't think so (simply blacklisting by OUI).

And as far as I know, GA-UP5 has Intel Lan i210 chip which is also supports natively. So why Apple should block this OUI?

Well, somethings happened at Apples end that is effecting many users, I'm just trying to help. Since all NIC's contain different OUI's its one possible way Apple could implement such a check without changing anything at our end. Just because these motherboards have the same LAN controller family does not mean they have the same OUI. It maybe that the OUI has nothing to do with it but its difficult to see what else (other than SN / UUID) could be used to enforce such a check if that is indeed what they are doing ?

Regards
Jay

 

[jaymonkey]

Is it this what you´re asking for ?

My Ethernet 90:2b:34:xx:xx:xx

My Wi-fi c4:17:fe:xx:xx:xx

Thanks Arehep,

Yes, I want to compare the OUI's on MAC address that work with iMessage to those that do not.

Cheers
Jay

 

[MaDxCrEaM]

my network card mac address is 90:2b:34:xx:xx:xx on my hackintosh that is not working

 

[mrcivic98]

The OUI of my hackintosh that is not working: bc:5f:f4

 

[jaymonkey]

Hey Guys,

You can check the OUI of your MAC address via this database lookup service:-

http://www.coffer.com/mac_find/

It looks like many integrated NIC OUI's are registered to the motherboard manufacturer not the NIC chipset supplier, similar to the way some WiFi NIC firmware's are branded to the board assembler not the chipset supplier, the OUI's of WiFi MAC addresses are also customised.

Examples:

• 90:2b:34 LAN NIC is registered to GigaByte not Intel despite using Intel Z77 Chipset.
• 6c:71:d9 WiFi NIC is registered to Azurewave not Broadcom despite using BCM94352 Chipset.

I've already checked my GA-Z77-UD5H and both the on-board Intel and Atheros NICs have a OUI of 90:2b:34 which is the same as the last few posts from GA-Z77-UP5-TH owners .... I know only a few of you have posted your OUI's so far (thanks), but even at this early stage you would have to say that this eliminates the OUI block list theory, unless someone can spot something i'm not.

I still think the issue could be with UUID / SN miss-matches but if anyone else has a theory or suggestion as to what could be going on please post your thoughts.

This afternoon I built a brand new system for a friend based on a GA-H77N mobo, installed OSX 10.9.2 , generated a new S/N using chameleon wizard (and applied preset SMBIOS 3,1) then installed FileNVRAM 1.1.2 ...... iMessage worked first time with no issues on both Realtek NIC's.

The mystery continues ...

Cheers
Jay