To remedy this, I created a two-line AppleScript application called “Launch iTunes & Close Window”

The source code is:

tell application "iTunes" to launch 
tell application "iTunes" to close window "iTunes"

Chimera can be found here from tonymacx86.

For me, just the Chimera update fixed my logon problems.  However, if the Chimera update does not solve your issues, you may have an issue with your built in network interfaces or a bad serial number.  If you cannot logon to iCloud after the Chimera update, try the following to reset your network settings on your Hackintosh:

1. Remove all network devices from System Preferences > Network.  It should look like this when you are done (and you will have no Internet access until completing the next steps):

2. If they don’t exist, add the following lines to the <dict> section of your boot plist in /Extra/org.chameleon.Boot.plist (for newer versions of Chameleon/Chimera):

<key>EthernetBuiltIn</key>
<string>Yes</string>

Others have reported that you need to add the following lines as well, but I don’t have them present and my iCloud works:

<key>PCIRootUID</key>
<string>1</string>

My <dict> portion of my com.chameleon.Boot.plist looks like this:

<dict>
	<key>Kernel</key>
	<string>mach_kernel</string>
	<key>Kernel Flags</key>
	<string>arch=i386</string>
	<key>GraphicsEnabler</key>
	<string>Yes</string>
	<key>Timeout</key>
	<string>2</string>
	<key>Legacy Logo</key>
	<string>Yes</string>
	<key>EthernetBuiltIn</key>
        <string>Yes</string>
 </dict>

3. Delete /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist

4. Delete /Library/Preferences/SystemConfiguration/com.apple.network.identification.plist

5. Reboot your computer.  Both the files deleted above will be automatically recreated.

6. Go back to System Preferences > Network and add your network devices, STARTING with Ethernet type as the first Ethernet interface (do not use WiFi as the first interface!).

After you hit “Apply”, your top interface should be the wired interface at en0:

Hopefully your iCloud and App Store is working at this point.

If you are still having issues (most likely due to a bad system type/serial):

Download and run Multibeast for Lion and update your system definition (Customization, System Definitions):

For good measure here’s my System Report so you can compare your system type, etc.:

The workaround, which I found here:

1. Unpair/Delete the phone from the Audi MMI
2. Remove the Audi pairing from the HTC Droid (unpair)
3. Re-pair the Audi to the HTC Droid
4. When the phone pops up with the “Audi MMI wants to access your contact lists, Allow or Deny?”
   Hit DENY numerous times.  After the 5-6th DENY all your contacts will sync.

Makes no sense and is totally counter-intuitive, but it works!

When I attempted to open the backup image I received an error stating “You do not have permission to open the document MacBook”.  Note: “MacBook” was the name of the system Time Machine was backing up.

After approximately an hour of experimentation and research, I found the fix:

Open Terminal in Applications/System Utilities.

“cd” to the folder where your sparsebundle file resides.
    (i.e. cd “/Volumes/Media/Time Machine”)

sudo chown -R `id -un`:`id -gn` MyTimeMachineBackup.sparsebundle

Enter your password.

Note the “`” quotes above are the slant-quote on your tilde key
on the top left of your Apple keyboard below the “esc” key.

You should now be able to access and mount the image.

Note the “vitelity_username” can be either your Main account or a sub-account off the primary.  I created two identical appearances on two lines (although only line1 is displayed in the config example below).  You will need to change the username/password/proxy to whatever your Vitelity settings are for your account.

line1_name : “vitelity_username”
line1_authname : “vitelity_username”
line1_password : “vitelitypasswordhere”
line1_shortname : “LineName”
line1_displayname : “8881112222″
proxy1_address : “sipXX.vitelity.net”
proxy1_port : 5060

outbound_proxy : UNPROVISIONED
outbound_proxy_port : 5060
nat_received_processing : 1
nat_enable : 1
nat_address : “”

start_media_port : 16384
end_media_port : 20000

preferred_codec : g711ulaw
dtmf_outofband : avt
dtmf_avt_payload : 101
dtmf_db_level : 3
dtmf_inband : 1

Assign your Cisco 7940 or 7960 a static IP on your LAN and forward 5060 TCP and 10000-20000 UDP to that IP from your firewall.

Because of a very specific issue with FIOS handling of caller ID in combination with IP office analog cards, the following occurs:

• The analog port, set to Loop Start ICLID picks up the ring.
• The call is delivered directly to a “main” hunt group.
• If a member of the hunt group picks up the call on the second ring, they will hear a loud buzzing/flutter for 1 second.  It sounds like this (recorded from speakerphone).  The sound is inaudible to the remote caller, FYI.

There is no real “fix” per se without completely disabling caller id on the carrier or IPO side, but there is a workaround which requires Embedded Voicemail, Voicemail Lite, or Voicemail Pro by utilizing “announcements.”

• Enable Announcements for your “main” hunt group (or extension if not using hunt groups), but don’t record one.
• Set announcement wait time to 0
• Set post announcement tone to “Ringing”
• Turn off 2nd and repeat announcements.

Because the call is picked up by the attendant and then routed, the crackle usually heard by the person picking up the call is intercepted by the “fake” attendant announcement.  Note that this workaround will occupy a single VM channel for about .5 secs when the call is picked up.  Also, caller ID continues to work well with the fix above.

Yet another alternative is to disable caller ID at the Verizon side, or set your IP Office analog lines to “Loop Start” with no CID.  Of course this will disable caller ID which is usually a dealbreaker in this day and age.

Jun 22 10:30:08    Severity:5    Joined BSS 00:23:69:67:dd:73
Jun 22 10:30:08    Severity:5    Installed unicast CCMP key for authenticator 00:23:69:67:dd:73
Jun 22 10:30:09    Severity:5    Joined BSS 00:23:69:67:dd:73
Jun 22 10:30:09    Severity:5    Installed unicast CCMP key for authenticator 00:23:69:67:dd:73
Jun 22 16:53:46    Severity:5    Disconnected from network.
Jun 22 16:53:49    Severity:5    Joined BSS 00:23:69:67:dd:73
Jun 22 16:53:49    Severity:5    Installed unicast CCMP key for authenticator 00:23:69:67:dd:73
Jun 22 16:53:51    Severity:5    Joined BSS 00:23:69:67:dd:73
Jun 22 16:53:51    Severity:5    Installed unicast CCMP key for authenticator 00:23:69:67:dd:73
Jun 24 03:28:47    Severity:5    Disconnected from network.
Jun 24 03:28:50    Severity:5    Joined BSS 00:23:69:67:dd:73
Jun 24 03:28:50    Severity:5    Installed unicast CCMP key for authenticator 00:23:69:67:dd:73
Jun 24 03:28:52    Severity:5    Joined BSS 00:23:69:67:dd:73
Jun 24 03:28:52    Severity:5    Installed unicast CCMP key for authenticator 00:23:69:67:dd:73
Jun 24 03:38:25    Severity:5    Joined BSS 00:23:69:67:dd:73
Jun 24 03:38:25    Severity:5    Installed unicast CCMP key for authenticator 00:23:69:67:dd:73
Jun 24 11:58:35    Severity:5    Disconnected from network.

This would cause my Slingbox stream to reset and restart on every disconnect.  After Googling around I found a few articles mentioning changing the advanced settings on the Linksys.  Specifically, the Beacon interval, RTS and fragmentation threshold values.  Once I changed them to the values displayed below, my Airport Express has been rock solid with no disconnects.  You want to set these values to:

Beacon Interval: 75 (some say 50 is best, but I use 75 and it works)
Fragmentation Interval: 2304
RTS Interval: 2307

My WLAN uses WPA2 encryption with AES + TKIP as displayed below:

Also my Airport Express is set to use a static IP address on my LAN versus DHCP.

]]> http://blog.waldrondigital.com/2010/11/03/apple-airport-express-disconnected-from-network-fixed/feed/ 7 http://blog.waldrondigital.com/2010/10/08/bad-response-from-server-with-youtube-channels/ http://blog.waldrondigital.com/2010/10/08/bad-response-from-server-with-youtube-channels/#comments Fri, 08 Oct 2010 23:51:06 +0000 Mike Waldron http://www.waldrondigital.com/?p=1109

After doing some Googling on this one, I tried all the proposed fixes: delete cookies, clear temp files/cache, etc… nothing helped in my client’s environment.  After doing some testing I found that the new version of AVG Internet Security (version 11) causes YouTube channel videos to report “bad response from server” when clicking from channels.  Once AVG was uninstalled, the channels work as intended with no errors.  If you don’t use AVG, I’d suggest removing your anti-virus/Internet security to see if the problem still manifests itself.  If not, you can start the troubleshooting process for your particular environment.

The fix (although not a great one) for AVG was to remove the LinkScanner components: AVG Search-Shield and Surf-Shield. Problem Solved!

Hope this helps someone out there banging their heads against the wall on this one!

The solution was to invent a neat little batch file that will keep the VPN alive by initiating a ping, and displaying a status window for the end user.  It’s a ghetto solution but hey, it works.

To use this script, simply place in a folder or your choosing, create a shortcut for your user with a neat title like “VPN Keepalive” with a pretty icon like so:

keepalive.bat 192.168.100.1 15

The red is the IP address (hostnames are not supported).
The green is the refresh period for user status (screen refresh).

Problem solved.

Download the script here

Large (i.e. 1 MB+) FTP uploads from newer client Windows OSes such as Windows Vista or Windows  7 running the FileZilla client (3.3.3) in passive mode, connecting to a Windows 2008 server would slow down, then hang/stall after a few seconds, eventually timing out.  In testing I found the issue occurred in both IIS/MS FTP/Microsoft FTP or FileZilla server running on the 2008 R2 box.  Here’s an example… on a Windows 7 FileZilla client, the transfer would hang at the EXACT same place EVERY time (in my case it hung exactly at 458,752 bytes):

Using a Mac or Windows XP FileZilla client did not produce a problem and the transfer always worked perfectly.

The solution was simple.  Enter this command line (must be run as admin) to disable the TCP autotuning mechanism on the server:

netsh int tcp set global autotuninglevel=disabled

Problem solved!  Big transfers – full speed ahead!  NOTE: I’m pretty sure this can be used on the client versus the server to work around the issue as well… please let me know in the comments.

Environment:

Server OS: Windows 2008 R2 Server
Client OS: Windows 7
FTP Server: IIS / MS FTP or FileZilla
FTP Client: FileZilla for Windows