Archive for the ‘Mac OS X’ Category

Using a TL866II+ programmer to update GCDual firmware

Monday, January 20th, 2020

I have a GCDual board, which is a modification for a Nintendo Gamecube to give it HDMI output. Firmware updates for this little PCB come out occasionally and to apply them requires attaching an EEPROM/flash programmer to the various pins and rewriting the chip directly.

I got wind of the latest 3.0a firmware update that actually lays the groundwork for future updates to be applied through software instead and figured it would be good have this.

There is a video that shows how to do the firmware update however I had a few issues with that process:

  1. I haven’t actually installed the PCB yet, (it’s in my TODO pile). This isn’t actually a problem as in the video, the 3.3V is provided by the Gamecube PSU instead of the programmer, but the programmer can supply this. In theory it should also negate taking precautions to ensure that the programmer doesn’t accidentally short something on the main Gamecube board.
  2. The process is using a CH341A programmer which I don’t have, and if I did get one it seems to be poorly supported on macOS. The programmer looks like it just needs to be able write SPI flash devices.

I do have a TL866II+ programmer which has a 6-pin ICSP port and comparing the pinout of that and the CH341A programmer looks like both programmers have the same required pins. The TL866II+ comes with an ICSP harness that is terminated as 6 individual female sockets so with a piece of pin header I arranged the pins in the correct order. Here is how the programmer expects the pins to be arranged logically:

So it was just a case of marrying those up to the header on the GCDual PCB. For reference it was 1-3, 2-2, 3-1, 4-4, 5-6, 6-5 for each pin on the TL866II+ to the GCDual respectively, with pin #1 on the GCDual being GND. This is what it looks like:

You can then insert the pins into the GCDual PCB and use a bit of light pressure to make contact without the need to solder anything:

Note that you need to bridge the two solder pads marked JP2 at the top right of the PCB in order to do anything with the flash chip otherwise the FPGA will fight with your programmer on the SPI bus when power is applied and you’ll read and/or write garbage.

Now we just need to flash the chip. For driving the programmer, I use the open source minipro rather than the provided software. The only bit of required information is the make & model of the flash chip; the original video shows it being programmed as an M25PE40 but my PCB actually has an MX25L4006E. The datasheets show these two chips are mostly identical anyway however minipro likes to check the chip ID. Writing the new firmware is as simple as the following:

$ minipro -i -p MX25L4006E -s -w GCDual_ADV7125_3.0a.bin
Found TL866II+ 04.2.109 (0x26d)
Activating ICSP...
Chip ID OK: 0xC22013
Warning: Incorrect file size: 346144 (needed 524288)
Erasing... 1.71Sec OK
Protect off...OK
Writing Code...  5.19Sec  OK
Reading Code...  2.48Sec  OK
Verification OK
Protect on...OK

The flags used are: use ICSP instead of the ZIF socket (-i), choose the correct flash chip (-p MX25L4006E), don’t complain that the firmware is smaller than the capacity of the chip (-s), and provide the firmware itself (-w ...).

Remember to remove the solder bridge with some wick prior to installing the PCB.

Exporting Mobile Configuration Profiles from Apple Configurator

Friday, January 9th, 2015

As I’ve secured my main Wi-Fi network with WPA2 Enterprise, my Apple Airport devices are pointed at a RADIUS server, which in turn is pointed at an LDAP directory which contains the user details. The LDAP directory does not store the password in the clear which means that authentication methods like CHAP, MSCHAP and MSCHAPv2 don’t work as they require the original password. I need to use EAP-TTLS with PAP authentication however iOS and OS X clients will not attempt this method by default.

It’s theoretically easy to make iOS and OS X clients use this method, you simply install a Mobile Configuration Profile (a file with a .mobileconfig extension) which amongst other things instructs the client how to connect to a given Wi-Fi network. The tricky part is generating this file if you maybe don’t have access to an OS X Server. Apple originally provided the iPhone Configuration Utility (iPCU) which has been deprecated in favour of the Apple Configurator utility. This works fine for iOS devices that you can attach directly by USB but sometimes you might want to transfer a profile to someone via e-mail or install it on an OS X client. It’s not obvious how to export a profile from the tool, but there is a way.

When you open Apple Configurator it looks like this:


If you enable Supervision the Profiles section changes to allow you to click + and create a new profile:


In my profile as a minimum I needed to import the root certificate of the authority used to sign the certificate on my RADIUS server. Then configure my Wi-Fi network with the SSID, Security Type, EAP Type of TTLS and then select PAP as the Inner Authentication. I also trusted the certificate I’d just imported which prevents iOS and OS X prompting you to trust it. By not setting the Username and Password this keeps the profile generic for any user. Then after saving the profile you can then export it:


This gives you the familiar .mobileconfig profile which can then be imported on any iOS or OS X client.

Apple Airport devices and guest networks in bridging mode

Friday, January 9th, 2015

The feature of being able to configure a separate guest Wi-Fi network has been present for a while now on Apple Airport gear. However, the documentation only ever alludes to this feature working when the Airport device is running in router/NAT mode, i.e. it’s in charge of connecting directly to the Internet and sharing the connection from your ISP.

Quite often people (like myself) use the Airport device(s) in bridging mode, i.e. as regular access points to attach Wi-Fi clients onto the Local Area Network and then some other device handles the routing and NAT function, (in my case an OpenBSD host), and it would be nice if you could also create a guest Wi-Fi network in this mode. The obvious way I would expect it to work is to utilise VLANs; the Airport device uses a single unique VLAN ID to tag Ethernet frames from clients on the guest Wi-Fi network. As the administrator you can then use that tag to segregate the traffic on your network; usually to allow guests some form of heavily-restricted Internet-only access, and not be able to access the rest of the network. The Airport Utility lets you create the guest network in bridging mode but doesn’t give you any details as to the mechanics of it.

Well it turns out my hunch was correct, it does use VLANs; Ethernet frames from clients on the normal Wireless network stay untagged so they Just Work on your network as before, however Ethernet frames from clients on your guest network are tagged with the VLAN ID 1003. This ID is not mentioned anywhere, nor can it be changed so you’d better hope you’ve not already used that ID for something else.

Armed with that information, I configured my Cisco SG300 switch like so:

switch#configure terminal
switch(config)#vlan database
switch(config-vlan)#vlan 1003
switch(config)#interface vlan 1003
switch(config-if)#name wifi
switch(config)#interface GigabitEthernet 1
switch(config-if)#switchport mode trunk
switch(config-if)#switchport trunk allowed vlan add 1003
switch(config)#interface GigabitEthernet 2
switch(config-if)#switchport mode trunk
switch(config-if)#switchport trunk allowed vlan add 1003
switch#show vlan
Created by: D-Default, S-Static, G-GVRP, R-Radius Assigned VLAN, V-Voice VLAN
Vlan       Name           Tagged Ports      UnTagged Ports      Created by    
---- ----------------- ------------------ ------------------ ---------------- 
 1           1                               gi1-8,Po1-8            D         
1003       wifi             gi1,gi2                                 S

This creates the VLAN, names it, configures two trunk ports where my Airport and OpenBSD router are attached and adds the new VLAN to the list of allowed ones on each port. Finally all that is left to do is to create a VLAN interface on the OpenBSD router:

# cat /etc/hostname.vlan1003
inet vlan 1003 vlandev em0

Providing any DHCP and/or DNS services and firewalling the traffic is outside the scope of this post but you now have a separate interface and subnet that you can treat it like any other regular network.

So now I have two separate wireless networks; one that gives me access to my LAN which I can secure using WPA2 Enterprise and another that can only reach the Internet which can be unrestricted or more likely secured with WPA2 Personal.

Annoying Keychain bug on Mavericks

Monday, January 27th, 2014

Just been bitten by this annoying bug on Mavericks after a seemingly innocuous reboot whereby I’m prompted repeatedly to unlock my “Local Items” keychain. No password I’m aware of works and mashing Cancel just puts you in an endless loop cycling through each application or framework that wants to access said keychain.

The solution is simple as outlined in the linked support document; just nuke the UUID-named folder in ~/Library/Keychains and reboot. The same folder will reappear afterwards but it’s fine to leave it if you’re not prompted to unlock it again. Obviously something got corrupted, possibly related to iCloud.

Setting the date on a Muvi Micro Camcorder

Sunday, February 27th, 2011

I recently got a little Veho Muvi Micro Camcorder after seeing my brother using one on his bike. I appear to have the Pro model which on the positive side can handle more frames per second, but on the negative side puts a bright green timestamp on your recordings and there’s no way to disable it.

So the best you can do is at least make sure the timestamp is correct; it will reset to some known epoch if the battery goes flat and it might lose accuracy over time although I can’t say I’ve paid attention to that. There’s a utility for Windows that ships with the device, but that’s no good on a Mac or Linux host so for the benefit of the lazyweb and myself because it’s fairly obscure how to do it…

Create a file called time.txt in the root of the Muvi filesystem (alongside the DCIM directory) with the following contents:


Unmount the device and turn it off and on, the file should be consumed and the time should be now set.

Here’s a video shot in my 1955 VW Beetle which demonstrates the annoying timestamp, although does show the Muvi does just about cope with the electromagnetic interference from the magneto ignition and noise levels from the exhaust, although it doesn’t cope with the lack of daylight, blame the black paint for that.

DivX playback on OS X

Sunday, December 5th, 2010

I normally install the DivX software to get the support enabled in QuickTime Player via the bundled plugin.

Recently a couple of DivX-encoded movies have confused QuickTime Player such that I get the sound, but no picture although they seem to work fine in the standalone DivX Player. I’d rather not have to use multiple video playback apps so this rather smells of plugin fail.

The DivX Preferences pane forces System Preferences to relaunch in 32-bit mode, so I tried starting QuickTime Player in 32-bit mode to see if that might help, but no joy.

While searching to see what other users have done, I stumbled across Perian which is a LGPL-licenced QuickTime component that supports DivX amongst a bunch of other formats.

Installing Perian got the troublesome DivX videos working properly in QuickTime Player, and its System Preferences pane works in native 64-bit mode so it’s also slightly less annoying in that respect.

NAT-PMP fixes for Transmission

Sunday, November 7th, 2010

I recently had a desire to play some old Amiga games in UAE and so I needed the Kickstart ROMs. Rather than dig out my old A1200 and somehow get the ROM image from that I attempted to just download them, (naughty, I know).

All I could find were BitTorrent links so I needed a BitTorrent client. I picked Transmission as it looked a decent OS X client and grabbed the Kickstart ROMs.

In the course of doing that I noticed a couple of small NAT-PMP related bugs, thanks to being more than slightly familiar with the protocol.

So once bugs #3727 and #3728 are fixed hopefully Transmission will play even better with natpmpd.

Back to My Mac and an OpenBSD firewall

Friday, August 27th, 2010

As I recently wrote, I’ve been playing with the Back to My Mac feature of MobileMe on my Macs. Put simply it’s a VPN for your Macs, you can access one remotely from another as if they were on the same LAN either at home or work.

Assuming you’ve entered all of your MobileMe account details, it should just be a case of going to the Back to My Mac tab in the MobileMe preferences and starting it up on each Mac you own.

However, with the first Mac I tried this on I hit this problem:

Back to My Mac Warning Screenshot

The router that OS X is complaining about in this case is a Soekris net4501 running OpenBSD, (well to be pedantic, there’s actually two of them in a failover configuration). OpenBSD doesn’t support NAT-PMP or UPnP out of the box, so I had a look for some additional software I could run that might support either protocol.

I came across MiniUPnPd which claimed to support both protocols and run on OpenBSD so I grabbed the source and compiled it up to try it. At the time I was still running OpenBSD 4.6 but was planning to do the upgrade to 4.7 soon, I noted that there was reports of MiniUPnPd not working properly on 4.7.

After configuring it and starting it up, it didn’t seem to work properly. After eliminating any obvious reasons, the Macs still didn’t think that the router supported either NAT-PMP or UPnP, and my Sony Playstation 3 which supports UPnP only, claimed UPnP was unavailable when I ran a network diagnostic but this seems to be a known issue with the Playstation 3. So MiniUPnPd wasn’t looking too useful to me.

Out of curiosity I investigated how complicated the NAT-PMP and UPnP protocols are as the specifications for both should be publicly available. The first one I looked at was UPnP as at the time this seemed the more well known of the two. UPnP appears be a fairly bewildering set of standards, even though it seemed the bit I only need to care about is the Internet Gateway Device (IGD) protocol. It also depends heavily on XML which I loath the more I have to deal with it.

NAT-PMP on the other hand seemed a far simpler protocol, the IETF draft was straightforward by comparison and as it was authored by Apple themselves, it should be the better supported of the two, at least on my Apple hardware. After a day or two of coding, I have a fully standalone NAT-PMP daemon – natpmpd, which I’m making available under the BSD licence.

The dedicated page documents the gory details on how to get it set up, but suffice to say once installed and running, I now get the following on each Mac:

Back to My Mac Working Screenshot

To test, I simply disconnected my MacBook Pro from my home network and instead connected through my mobile phone via 3G. The remaining Macs on the home network are still visible in the Finder and Screen and File sharing remain accessible. On my OpenBSD router using tcpdump(8) I can see the encrypted VPN traffic flowing between the remote and local Macs.

Snow Leopard and (uninstalling) Cisco VPN

Saturday, August 14th, 2010

I mentioned reinstalling Shimo when I upgraded to Snow Leopard and that works really nicely for controlling my Cisco VPN connection but for that to work, you still need to install the official Cisco VPN client.

I also use VMware Fusion and find both this and the Cisco VPN client have a propensity to step on each others toes in the networking department, my hunch is it’s most likely because both create and monitor virtual network interfaces. The usual symptoms are that my virtual machines lose network connectivity or cannot access the VPN, or that I can’t bring the VPN connection up in the first place. Sometimes I can restore order to the VPN by restarting it with the following in the Terminal:

$ sudo /System/Library/StartupItems/CiscoVPN/CiscoVPN restart

Anyway, while I was tethering my Mac to my mobile phone I was fiddling with the Network preferences and noticed Snow Leopard gained native support for CIsco VPN connections:

Cisco VPN Interface Screenshot

This was probably in the release notes which I didn’t read, (well-known male trait), but anyway adding this new interface and configuring it with the right settings got it working first, second, third time once I remembered the correct password. It even feels quicker.

That left me with little need for Shimo or the Cisco VPN client. Uninstalling Shimo was easy, I removed it from my Login Items under Accounts preferences and then dragged it from the Applications folder to the trash.

Uninstalling the Cisco VPN client was harder as that came from an .mpkg file but then I remembered something about these leaving package receipts somewhere. Sure enough, under /Library/Receipts was a handful of vpnclient-*.pkg files. A bit of a google suggested each contains a .bom file that you can inspect with lsbom(8), I found the following worked in the Terminal:

$ lsbom /Library/Receipts/vpnclient-api.pkg/Contents/Resources/
.	40755	502/0
./Library	40755	502/0
./Library/Frameworks	40755	502/0
./Library/Frameworks/cisco-vpnclient.framework	40755	502/0
./Library/Frameworks/cisco-vpnclient.framework/Headers	40755	502/0
./Library/Frameworks/cisco-vpnclient.framework/Headers/vpnapi.h	100644	502/0	20265	1156317900

Delete any Cisco-specific files, (obviously don’t delete things like /Library/Frameworks) and then reboot to make sure there’s no stale daemons running or kernel extensions loaded.

Using the built-in VPN support doesn’t seem to cause any conflicts with VMware, I started the VPN while it was running and the virtual machines then had access to hosts on the remote network with no obvious problems. JFW, as they say.

Tethering two Nokia phones under OS X

Thursday, August 5th, 2010

Now I’m running Snow Leopard one thing I needed to set up again was 3G access through my phone for that rare occurrence when my ADSL drops out and I need to raise a support ticket with my ISP (yes, quite) or I’m on the move somewhere.

I currently have a Nokia E71 with T-Mobile as a personal phone which I think will be my last Series 60 device but to be fair, it does seem to sync up with OS X pretty good. I also carry a Nokia E90 with Vodafone that my work provide for on call, it’s basically a glorified portable SSH terminal. I figured it’s probably advisable to set both phones up and as I don’t particularly want to carry cables for both phones (Nokia in their infinite wisdom decided to use a normal mini USB plug on the E90 but some proprietary plug on the E71), just using Bluetooth was good enough for me, so off I went.

Now, if you do this the usual way, you open Bluetooth preferences, search for the one phone and follow the Bluetooth Setup Assistant to pair the device and set up dial-up networking if OS X thinks the device supports it. Then you rinse and repeat for your second phone and here’s where you come unstuck as OS X will overwrite your dial-up networking configuration with whatever you specified the second time around and also will only use the second phone for any dial-up networking. I tried creating a second Bluetooth DUN profile but you’ll find there’s no obvious way to tie the profile to a particular phone.

So how do you do it?

Assuming you’ve not yet paired either phone, proceed to do so for each but when you’re prompted to set up the dial-up networking, just continue without entering any details. This will leave the Bluetooth DUN profile in Network preferences blank, but that’s okay as we won’t be using it.

Now here’s the non-obvious bit. Open up Bluetooth preferences and your two phones should be present in the list of devices, select one and with the little cog menu select the Edit Serial Ports… option. My E71 has a serial port configured here already by default, whereas there are none by default for the E90. In either case add a new serial port with the following settings:

  • Name: This will be something like NokiaE71-Dial-UpNetwork or NokiaE90-Dial-UpNetwork, the default is fine
  • Protocol: Modem
  • Service: Dial-Up Networking
  • Show in Network Preferences

Edit Serial Ports Screenshot

After adding the new port for each phone, OS X should notify you and ask you to configure it. First of all rename the profile which will default to the name of the serial port and isn’t terribly user-friendly, I tend to just use the phone model here. Now, I’m terrible at remembering the 3G details but Ross Barkman’s site is a great resource which lists the settings for many network operators in various countries. For each network I only really need the APN, username and password, for T-Mobile these are:

  • user
  • pass

And for Vodafone, they’re:

  • internet
  • web
  • web

The username and password go into the Account Name and Password fields, then hit Advanced… and make sure the Vendor and Model are Nokia and GPRS (GSM/3G) respectively, this should make the APN field visible into which you can enter the relevant value.

Now you should be able to hit Connect for either profile and after a few seconds you should be connected, signal permitting.

After working out how to do most of this, I discovered this blog post which walks you through much the same process, with pictures too.