I knew this day would come, as it has come for all other friends of mine who became fathers: create back-ups of your original kids-content DVDs, as their constant playback is not only difficult to manage but damaging to the discs themselves. Hooray for the media playback method: digital files! Long live the Matroska format!

An excellent tool that I’ve been using since my first Intel-based OS X days, HandBrake is the solution to digital files creation and of course, MKVs are the only way to go nowadays. Simple in its GUI yet powerful, HandBrake has been a companion for many of us and I am very happy that its development is still on-going.

What I didn’t know until recently is that HandBrake was counting on third-party software to directly read CSS-encrypted DVDs (e.g. “Fairmount” for Mac, by Metakine) something I’ve never experimented with until now. However, this “third-party” software is no longer available nor updated, as “Fairmount” has been acquired by DVDSuki Software and has been merged into “Mac DVDRipper Pro”. But according to this older article in MacWorld, we can still read and convert encrypted DVDs to MKVs for use with our favourite digital media players. In my case, a Western Digital WDTV Live player.

When prompted by HandBrake, simply install the necessary CSS library in your system, re-launch HandBrake and you’re good to go. In effect, what you need is the installation of the file libdvdcss.2.dylib in /usr/lib/ on your Mac system and you won’t be getting these error messages on HandBrake anymore:

HandBreak Missing Library Warning

Open the inserted DVD via HandBrake and wait until it reads all titles and chapters, then just select what you want to convert. Happy converting…

UPDATE: Just found out that user pmetzger got the source code for Fairmount and released a tweaked version. It may or may not remain alive as a project, but it’s worth having a look: http://github.com/pmetzger/Fairmount/

UPDATE: Seems that MacWorld have updated their same article and now we can get the updated libdvdcss.2.dylib versions directly from http://www.videolan.org/developers/libdvdcss.html

You may certainly find guides on how to share an Internet connection (e.g. from your Ethernet to wireless devices via embedded Wi-Fi) on a Mac computer running Mountain Lion 10.8.x but maybe you are in the same boat as I was, some time ago: do the exact opposite.

Due to the serious economical conditions in my home country, I had to leave wife, child, family and friends and move to another country in Europe where I found employment anew. However, renting a furnished flat was easy; getting a telephone and ADSL connection proved impossible.

I therefore had the landlord talk to my neighbour and convince him to eventually share his Wi-Fi with me, at a monthly fee, therefore providing me with a link to the “outside world” in the evenings (that is, FaceTime with my family).

However, I still wanted to hook up to the Internet my 2 Hackintosh computers and my WDTV Live device, besides my iPad. I had to devise a plan and share Wi-Fi Internet through Ethernet.

My smaller Hackintosh (a Gigabyte GA-H61N-USB3 with Intel Core i3-2125 and 8GB RAM) is used as a file/media server and seemed ideal for the task. Back then, while running 10.8.2, I thought that using Server.app would solve my problems. However, being computer-literate but networking-apprentice, I could not set it up properly and abandoned all hope.

I then turned to the famous, easy “Internet Sharing” feature of the Mac OS X system, but doing the opposite of what most users did; and it was tricky. After purchasing an OEM 802.11n USB dongle with a flexible antenna (running with the official Realtek RTL8192CU8 driver) the task was to properly configure the settings so I could share Internet via Ethernet to my other devices too: my powerful Hackintosh and WDTV Live player, all hooked to a Gigabit switch.

First step was to set up the Wi-Fi dongle driver, then I made sure the connection was working by using DHCP for quicker, fool-proof results. In this case, the ADSL wireless router was serving a range of 192.168.1.x addresses, whilst the DNS assigned was the router/gateway itself, i.e. 192.168.1.1:

Mountain Lion 'Internet Sharing' Wi-Fi Settings

Then, after a lot of searching and experimenting, I realised that the Wi-Fi dongle (en1) had to be first in the list of network devices, as it’s the one that is providing the connection to the Internet. The Ethernet (en0) connection would thus be second:

Mountain Lion 'Internet Share' Service Order

The next step was the tricky one: the Ethernet (en0) connection must get a manual IP address so that DHCP (a service running on Mountain Lion, this time) can serve any wired devices. This IP range had to be different, however, to the one served by the wireless modem/router and in this case I decided to go with 192.168.2.x and that meant I needed to assign 192.168.2.1 on this computer (to start the DHCP pool):

Mountain Lion 'Internet Share' Ethernet Setup

As it can be seen, the tricky part lied to the Router and DNS settings, as Ethernet (en0) now is relying on Wi-Fi (en1) to have all packets properly routed to the Internet. Both these settings had to be set as 192.168.1.1, pointing to the wireless modem/router. The Subnet remained the same 255.255.255.0 for the sake of simplicity.

The final step involved just activating the actual “Internet Sharing” itself. In the “Sharing” preferences pane and after clicking on the “Internet Sharing” service, I made sure that my source was set to the 802.11n WLAN Adapter, sharing to computers using Ethernet. When ticked both the “destination” and the service itself, I could see that my other devices immediately picked up an IP address and got connected to the Internet.

Mountain Lion 'Internet Share' Set Connections

As with each Hackintosh set-up, there are changes and updates needing to reboot the computer. Coming from Windows mentality I often reboot this Hackintosh file/media server, sometimes due to the frame-buffering issues that appear on the vanilla Intel HD 3000 display driver. Even after updating to 10.8.4, the new problem found was that upon reach reboot and despite the “Internet Sharing” service being ticked (implying “active”) the actual underlying service would not kick-start. I always had to manually stop and re-start this service by un-ticking and re-ticking this service on the list. Otherwise, wired devices had no access to Internet and curiously enough, could not get an IP address either.

Mountain Lion 'Internet Share' Confirm Start

This was a harder bug to crunch, as for countless times I was literally “digging” in Google results to find a solution using a multitude of keywords. The answer came after reading for a third or fourth time the insightful article “Running DHCP on Mountain Lion Server” where I found that the bootpd deamon is responsible for my problem. Moreover, it seems that Apple programmers decided to keep this daemon dormant at each reboot, as seen in the untouched file /System/Library/LaunchDaemons/bootps.plist where the <Disabled> key is set to <true> by default, meaning that Mac OS X forces the user to manually start DHCP, whenever it is needed. I guess this is the right way to do things but Apple programmers could at least have “Internet Sharing” stopped and un-checked at each shutdown!

The necessary edit is to change this <Disabled> key in line 6 from <true> to <false> and just reboot the system. Better make a backup copy of the file bootps.plist, just in case. This change is quite sensitive and needs to be performed only if the computer is intended to always behave as a DHCP server just like in my own case; now, it is not necessary to stop and re-start the service after each reboot, as long as “Internet Sharing” remains untouched.

Mountain Lion 'Internet Share' Activate Sharing

After activating “Internet Sharing” and following this article found on StackExchange.com, I could now see how connectivity works with the new bridge created on the file/media server:

$ ifconfig
lo0: flags=8049 mtu 16384
	options=3
	inet6 fe82::1%lo0 prefixlen 64 scopeid 0x1 
	inet 127.0.0.1 netmask 0xff000000 
	inet6 ::1 prefixlen 128
en0: flags=8963 mtu 1500
	options=2b
	ether 00:e0:40:48:e0:40 
	media: autoselect (1000baseT )
	status: active
en1: flags=8863 mtu 1500
	ether 08:02:0a:0d:4c:05 
	inet6 fe82::4a02:2aff:fe9d:4c35%en1 prefixlen 64 scopeid 0x5 
	inet 192.168.1.39 netmask 0xffffff00 broadcast 192.168.1.255
	media: autoselect
	status: active
bridge0: flags=8863 mtu 1500
	ether a8:d2:4a:10:d0:b9 
	inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255
	Configuration:
		priority 0 hellotime 0 fwddelay 0 maxage 0
		ipfilter disabled flags 0x2
	member: en0 flags=3
	         port 4 priority 0 path cost 0

 
NOTE: The boodpd daemon starts with the network settings found in /etc/bootpd.plist which were created when “Internet Sharing” was previously activated. This file must not be confused with the actual daemon launch behaviour in bootps.plist.

I accidentally stumbled upon this tip, the other day, while searching for something completely different. I upgraded to Mountain Lion directly from Snow Leopard, thus ignoring the AirDrop functionality introduced in Lion. However, I soon realized that on my old MacBook Pro 2007 model (MacBookPro3,1) this feature did not exist at all.

Apparently, for AirDrop to work natively (with Lion and Mountain Lion, only) Apple requires the existence of “hardware necessary to support a certain type of point-to-point Wi-Fi connection” that is probably not present on older models.

Thankfully, it appears that it is possible to allow “unsupported” Macs to enable this functionality, too, via a simple Terminal.app command, as with all good things on OS X:

defaults write com.apple.NetworkBrowser BrowseAllInterfaces 1

Whether it works well or not, that is another story!

After successfully entering the command above, it is advised to either relaunch Finder or simply reboot the computer. This system setting appears to be permanent, after each reboot.

People reported that even for newer models, I need to activate this feature on every Mac in my local network in order to use it properly, including ethernet-only connected Macs.

To disable this feature, I only need to set the last digit back to zero, of course:

defaults write com.apple.NetworkBrowser BrowseAllInterfaces 0

I am quite happy this “hack” still works under Mountain Lion 10.8.0 and 10.8.1, so if you have an older Mac computer that can still run Lion or Mountain Lion natively, no need to go jealous on the AirDrop functionality of newer computers!

My thanks to OSXDaily.com for posting the original tip of the anonymous user over MacOSXHints.com.

Update: Looks like it works fine with my MacBook Pro (2007) via Wi-Fi and my Hackintosh via Ethernet! (both running Mountain Lion 10.8.2)

The process of setting up an optimised hackintosh requires the extraction, de-compilation, editing and re-compilation of the computer’s DSDT table. The extraction process itself is extremely easy, using Ubuntu’s Live CD and just typing one command in Terminal. However, it seems that since Ubuntu v11.x the syntax of this command had drastically changed.

After installing Ubuntu on a USB flash disk for this purpose, using the excellent Universal USB Installer tool, open up a terminal session and type the following command (assuming you will later copy the generated/extracted file from the Desktop to another FAT-32 formatted USB flash disk):

cd ~/Desktop
sudo cat /sys/firmware/acpi/tables/DSDT > DSDT.aml

 
For those of you still using Ubuntu Live CD v9.x and v10.x, just type:

cd ~/Desktop
sudo cat /proc/acpi/dsdt > DSDT.aml

 
This extracted file can later be de-compiled using iasl and edited according to various guides (such as those found over at InsanelyMac). But if you definitely need to obtain such a text-version of this file, you can install iasl and de-compile it as easily:

sudo apt-get install iasl

 
…wait while it loads from the Internet and installs (obviously your network card must be properly detected and working) and then type:

iasl -d DSDT.aml

 
The resulting file will be called DSDT.dsl and will also be placed in ~/Desktop/ which can be edited with a simple (but good enough) visual text editor.

Thanks to user AsereBLN for his original article back in October 2009, when I started exploring Mac OS X outside my iMac.

Happy patching!

A few months ago, I had successfully updated the firmware on my Thomson TG585 v8 router to version 8.2.7.8 when I also found out that I could connect to it via telnet, as per my previous post.

Recently, due to connectivity problems, my ISP requested that I perform a factory reset on the device. After solving those connectivity problems, I realised that access via telnet was not possible anymore. The weird thing was that I had not changed any settings on either router or computer, so this problem got really puzzling.

Finally, I found the reason why this was happening, as well as a working solution from member ZhenXlogic over the Greek forum at www.adslgr.com which I replicate here, in English, for those of you that could not easily find a solution, yet. The steps are easy.

First, save your current router settings by visiting the web interface over at 192.168.1.254 and selecting the left icon “Thomson Gateway”. Once inside, click on “Configuration” and then choose to “Save or Restore Configuration”. Then click on “Backup Configuration Now…” and select the location where user.ini will be saved.

Now with your favourite text editor, open the file user.ini and carefully browse inside, until you find the section [servmgr.ini] where you will see the problem itself: the new settings of the router have restrictions on the IP addresses that will access it via telnet, as seen in this output of mine:

[ servmgr.ini ]
ifadd name=PPTP group=lan
ifadd name=HTTP group=lan
ifadd name=HTTPs group=lan
ifadd name=HTTPs group=wan
ifadd name=FTP group=lan
ifadd name=FTP group=wan
ifadd name=TELNET group=lan
ifadd name=TELNET group=wan
ifadd name=DNS-S group=lan
ifadd name=MDAP group=lan
ifadd name=SSDP group=lan
ifadd name=PING_RESPONDER group=lan
ipadd name=HTTPs ip=212.251.87.4
ipadd name=HTTPs ip=62.1.46.29
ipadd name=HTTPs ip=62.1.46.30
ipadd name=HTTPs ip=10.24.11.19
ipadd name=HTTPs ip=10.24.11.20
ipadd name=FTP ip=212.251.87.4
ipadd name=FTP ip=62.1.46.29
ipadd name=FTP ip=62.1.46.30
ipadd name=FTP ip=10.24.11.19
ipadd name=FTP ip=10.24.11.20
ipadd name=TELNET ip=62.1.46.29
ipadd name=TELNET ip=62.1.46.30
ipadd name=TELNET ip=10.24.11.19
ipadd name=TELNET ip=10.24.11.20
ipadd name=TELNET ip=212.251.87.4
modify name=PPTP state=enabled
modify name=SNTP state=enabled
modify name=SLA_ICMP_PING state=enabled
modify name=SLA_UDP_PING state=disabled
modify name=HTTP state=enabled
modify name=HTTPs state=enabled
modify name=WEBF state=disabled
modify name=TFTP-C state=disabled
modify name=FTP state=enabled
modify name=TELNET state=enabled
modify name=RIP state=disabled
modify name=IGMP-Proxy state=enabled
modify name=DNS-S state=enabled
modify name=DNS-C state=enabled
modify name=DHCP-S state=enabled
modify name=MDAP state=enabled
modify name=CWMP-C state=enabled qoslabel=Management
modify name=CWMP-S state=enabled
modify name=SSDP state=enabled
modify name=GRE state=disabled
modify name=IPIP state=disabled
modify name=IP_COMMANDS state=enabled
modify name=PING_RESPONDER state=enabled
mapadd name=HTTP port=www-http
mapadd name=HTTPs port=443
mapadd name=HTTPI intf=LocalNetwork port=www-http
mapadd name=HTTPI intf=LocalNetwork port=1080
mapadd name=HTTPI intf=LocalNetwork port=httpproxy
mapadd name=FTP port=ftp
mapadd name=TELNET port=telnet
mapadd name=DNS-S port=dns
mapadd name=MDAP port=3235
mapadd name=SSDP port=1900

 
As you can see, unless you set the IP of your computer to the above specific values in highlighted red, the router will not allow access to its telnet console. For some reason, the developers of the Thomson firmware forgot to include the router’s default IP subnet, i.e. 192.168.1.xxx completely.

To remedy this situation, you simply need to add the line below as the first entry for TELNET, in order to allow the current router’s IP subnet (static or DHCP) computers to connect to it:

ipadd name=TELNET ip=192.168.1.[1-100]

 
In my example, I restrict the range from 1 to 100 but you can also set it from 1 to 200, accordingly. Therefore, insert this entry with your text editor back in the [servmgr.ini] section, like I did:

[ servmgr.ini ]
ifadd name=PPTP group=lan
ifadd name=HTTP group=lan
ifadd name=HTTPs group=lan
ifadd name=HTTPs group=wan
ifadd name=FTP group=lan
ifadd name=FTP group=wan
ifadd name=TELNET group=lan
ifadd name=TELNET group=wan
ifadd name=DNS-S group=lan
ifadd name=MDAP group=lan
ifadd name=SSDP group=lan
ifadd name=PING_RESPONDER group=lan
ipadd name=HTTPs ip=212.251.87.4
ipadd name=HTTPs ip=62.1.46.29
ipadd name=HTTPs ip=62.1.46.30
ipadd name=HTTPs ip=10.24.11.19
ipadd name=HTTPs ip=10.24.11.20
ipadd name=FTP ip=212.251.87.4
ipadd name=FTP ip=62.1.46.29
ipadd name=FTP ip=62.1.46.30
ipadd name=FTP ip=10.24.11.19
ipadd name=FTP ip=10.24.11.20
ipadd name=TELNET ip=192.168.1.[1-100]
ipadd name=TELNET ip=62.1.46.29
ipadd name=TELNET ip=62.1.46.30
ipadd name=TELNET ip=10.24.11.19
ipadd name=TELNET ip=10.24.11.20
ipadd name=TELNET ip=212.251.87.4
modify name=PPTP state=enabled
modify name=SNTP state=enabled
modify name=SLA_ICMP_PING state=enabled
modify name=SLA_UDP_PING state=disabled
modify name=HTTP state=enabled
modify name=HTTPs state=enabled
modify name=WEBF state=disabled
modify name=TFTP-C state=disabled
modify name=FTP state=enabled
modify name=TELNET state=enabled
modify name=RIP state=disabled
modify name=IGMP-Proxy state=enabled
modify name=DNS-S state=enabled
modify name=DNS-C state=enabled
modify name=DHCP-S state=enabled
modify name=MDAP state=enabled
modify name=CWMP-C state=enabled qoslabel=Management
modify name=CWMP-S state=enabled
modify name=SSDP state=enabled
modify name=GRE state=disabled
modify name=IPIP state=disabled
modify name=IP_COMMANDS state=enabled
modify name=PING_RESPONDER state=enabled
mapadd name=HTTP port=www-http
mapadd name=HTTPs port=443
mapadd name=HTTPI intf=LocalNetwork port=www-http
mapadd name=HTTPI intf=LocalNetwork port=1080
mapadd name=HTTPI intf=LocalNetwork port=httpproxy
mapadd name=FTP port=ftp
mapadd name=TELNET port=telnet
mapadd name=DNS-S port=dns
mapadd name=MDAP port=3235
mapadd name=SSDP port=1900

 
Notice the entries in orange, where TELNET is enabled for access via wired (lan) and wireless (wan) computers, at the default port 23:

ifadd name=TELNET group=lan
ifadd name=TELNET group=wan
modify name=TELNET state=enabled
mapadd name=TELNET port=telnet

 
Now that you’re at it, you can disable (unbind) the router’s SIP port mapping to allow your own SIP devices to work perfectly, as per my older post. Simply remove the line below from section [connection.ini] within user.ini:

bind application=SIP port=5060-5060

 
You can also disable the WPS functionality by setting the proper field inside [wireless.ini] section:

wps config ssid_id=0 state=enabled

 
to:

wps config ssid_id=0 state=disabled

 
Once saved, you need to upload the new configuration back to the router. Thus, you need to visit again the web interface over at 192.168.1.254 and select the left icon “Thomson Gateway”. Right under, click on “Configuration” and then choose to “Save or Restore Configuration”. Then click on “Restore Configuration Now…” and point to the modified user.ini to be uploaded.

The device will reboot in order to apply the new settings; in a couple of minutes, you shall have telnet access!

I recently wanted to completely wipe (not format) my two Intel X25-M Solid State (SSD) Drives that replaced the ones found in my MacBook Pro (2007) and my Dell Mini 10v (2009) so I went back to a favourite website -that I had saved- to seek instructions using Ubuntu’s Live CD:

http://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

 
However, to my surprise, the site doesn’t carry that information anymore (I barely caught the Google-chached page) so I started digging up the web again for a possible fresh set of instructions and compare them to my notes. Nevertheless, after successfully wiping these two Intel SSD drives using the “secure erase ATA command”, I am posting an updated copy of those Wiki instructions that are now down the… world wide drain!

First of all, go grab the Ubuntu v9.04 Live CD image (ubuntu-9.04-desktop-i386.iso) and burn it to a blank CD-R with your favourite application (either on Mac or PC). Update: It seems Ubuntu only supports v10.04 LTS now, as their oldest distro, so use Google to find v9.04 if your computer is more than 2 years old, otherwise v10.04 will do just fine. On the Ubuntu download page, there are also instructions on how to conver the .iso into a bootable USB drive; however, after following their Mac OS X instructions carefully, my MacBook Pro did not want to boot Ubuntu via USB so I ended up burning a CD-R. That’s 0,10 Euros wasted!

Once you successfully boot into the Ubuntu desktop, you will first need to determine the device that your SSD drive is assigned to. Find and run GParted and you should end up with a list of drives and partitions:

As you can see, in this example, the drive to be erased (the only one actually connected to the Dell Mini) is /dev/sda that has 3 partitions (EFI, Apple HFS+ and NFTS) from my current Hackintosh hybrid.

This procedure below describes how to use the hdparm command to issue a Secure Erase ATA instruction to a target storage device. When a Secure Erase is issued to an SSD drive, all of its cells will be marked as empty, restoring it to factory-default write performance. This is very different from the format command, especially for SSD technology.

DISCLAIMER: This will erase all your data, and will not be recoverable by even data recovery services.

DISCLAIMER: If you encounter kernel or firmware bugs (which are plenty with non-widely-tested features such as the ATA Secure Erase) this procedure might render the drive unusable or crash the computer it’s running on.

To successfully issue the so-called ATA Security Erase command, you need to first set a user password. This step is somehow omitted from almost all other sources which describe how to secure erase with hdparm.

The example output shown is from an Intel X25-M (34nm) 40GB SSD running the latest 02M3 firmware. It was run from an Ubuntu 9.04 32-bit (Jaunty) Live CD, booted from CD-ROM.

Start by opening Terminal in Ubuntu.

Step 1 – Make sure the drive’s security is not frozen

You will start by issuing the following command, where “X” matches your device (in my case, sda):

sudo hdparm -I /dev/X
i.e.
sudo hdparm -I /dev/sda

 
Typically, you should obtain the following information, at the very end of the command output:

Security:
	Master password revision code = 65534
		supported
	not	enabled
	not	locked
		frozen
	not	expired: security count
		supported: enhanced erase
	2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.

 
If the command output at the end shows “frozen”, then you cannot immediately continue to the next step. It is likely that your BIOS does not allow the ATA Secure Erase command, as it typically issues a “SECURITY FREEZE” command to “freeze” the drive, before booting any operating system. In this case, you could check if your BIOS may (most likely not) have a switch to disable the security freeze.

The only way that I personally was able to reset the “frozen” state of the SSD drive was to put the system into “sleep”. Placing both my MacBook Pro and Dell Mini into “sleep” and then “waking” them (simply by closing and opening the lid after a few seconds) is a trick that seems to work, as the sudo hdparm -I /dev/sda command now issues the required and correct “not frozen” output:

Security:
	Master password revision code = 65534
		supported
	not	enabled
	not	locked
	not frozen
	not	expired: security count
		supported: enhanced erase
	2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.

 
You may now confidently proceed to step 2 below!

Step 2 – Enable security by setting a user password

WARNING: When the user password is set, the drive will be locked after next power cycle! (the drive will deny normal access until unlocked with the correct password)

For this process, any password will do as this should only be temporary. After performing the secure erase to the drive, the password will be set back to NULL. For this procedure, I used the password “Eins” like everybody else on the web:

sudo hdparm --user-master u --security-set-pass Eins /dev/sda

 
This has resulted to the following output:

security_password="Eins"

/dev/sda:
Issuing SECURITY_SET_PASS command, password="Eins", user=user, mode=high

 
The password is now properly set and you should again check the status of the drive, by entering again:

sudo hdparm -I /dev/sda

 
You should now read “enabled” at the end of the command output:

Security:
	Master password revision code = 65534
		supported
		enabled
	not	locked
	not	frozen
	not	expired: security count
		supported: enhanced erase
	2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.

 
Now you can safely proceed to the next step of actually erasing the drive.

Step  3 – Issuing the ATA Secure Erase command

Still at the Terminal, type:

sudo time hdparm --user-master u --security-erase Eins /dev/sda

 
Please wait white the process completes. This may take a few minutes; on my MacBook Pro and the Intel X25-M 80GB, it took about 1 minute to complete, whilst on my Dell Mini and the Intel X25-M 40GB about half-minute. It is reported that for 1TB disk it could take 3 hours or more!

The output should now read the following:

security_password="Eins"

/dev/sda:
  Issuing SECURITY_ERASE command, password="Eins", user=user
  0.00 user  0.00 system  0:16.71 elapsed  0% CPU
  (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+165minor)pagefaults 0swaps

 
Step 4 – Verify the security of the erased SSD

After successfully erasing it, the drive’s security should automatically be reset to “disabled” (thus, no longer requiring a password for access). You have to verify this by running again the following command at the Terminal:

sudo hdparm -I /dev/sda

 
The command output at the end should thus show the following:

Security:
	Master password revision code = 65534
		supported
	not enabled
	not	locked
	not	frozen
	not	expired: security count
		supported: enhanced erase
	2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.

 
The process is now officially over. Run or refresh GParted and verify that the drive was been wiped out completely:

Known issues

1. Executing security erase without setting a password

Some variations of this method are spread on various internet sites, but they will not work because security is “not enabled”, when issuing the hdparm command:

sudo hdparm --user-master u --security-erase NULL /dev/sda

 
As you can see, this results to the following output/error:

security_password=""

/dev/sda:
Issuing SECURITY_ERASE command, password="", user=user
ERASE_PREPARE: Input/output error

 
2. Getting “Error: 25″ when setting a password

With some other Linux distributions, it seems that setting a password simply does not work:

sudo hdparm --user-master u --security-set-pass Eins /dev/sda

 
…which, in turn, outputs:

/dev/sda:
Issuing SECURITY_SET_PASS command, password="Eins", user=user, mode=high
Problem issuing security command: Inappropriate ioctl for device
Error: 25

 
The only advice found is that you try to compile the latest hdparm from http://sourceforge.net/projects/hdparm/

Update

I remember seeing this somewhere but it seems you can issue another parameter to the hdparm command, above, for securely erasing your SSD in an “enhanced” way. According to the command manual, besides issuing the command above in Step 1:

sudo time hdparm --user-master u --security-erase Eins /dev/sda

 
you can replace the parameter –security-erase with –security-erase-enhanced provided that your SSD supports this (it must report “supported: enhanced erase” when you issue sudo hdparm -I /dev/sda in Step 2):

sudo time hdparm --user-master u --security-erase-enhanced Eins /dev/sda

 
The main difference is that “Secure Erase overwrites all user data areas with binary zeroes. Enhanced Secure Erase writes pre-determined data patterns (set by the manufacturer) to all user data areas, including sectors that are no longer in use due to re-allocation” thus, offering better data-wiping. Read more here.

Last year, while browsing the WikiDot forum for MyBook World Edition network drives, I found out that we can hide/disable the “Backup” share of these drives, so it is not visibly “annoying” when using Finder windows in Mac OS X. Since I use two MyBook World Edition II drives for my media needs and won’t ever use them for their TimeMachine backup feature, I wanted to remove the Finder sidebar entries of “MyBookWorld-Backup”.

This was easily possible for previous MyBook World Edition II firmwares, where all we had to do was to simply edit the file /etc/mDNSResponder.conf and comment-out the last line that refers to _adisk._tcp just like in the example below:

"MyBookMedia" _http._tcp local. 80 "TXTVersion=1.0" "DeviceModel=WDH2NC" "Vendor=WDC" "path=/index.php"
"MyBookMedia" _daap._tcp local. 3689 "TXTVersion=1.0" "DeviceModel=WDH2NC" "Vendor=WDC"
"MyBookMedia" _afpovertcp._tcp local. 548 "TXTVersion=1.0" "DeviceModel=WDH2NC" "Vendor=WDC"
/* "MyBookMedia-Backup" _adisk._tcp local. 9 "sys=waMA=07:e0:17:8f:11:2f" "dk0=adVF=0x83,adVN=WD_Backup" */

(please note that the MAC address above is not the real one of my drives but a generated fake, for the sake of understanding the hack)

Since the Western Digital update to firmware v1.02.10 though, this hack was no longer working, as any modification to the file /etc/mDNSResponder.conf would result to a fresh proper copy of it, upon rebooting the drive. So I started looking for the files that were either a template to that file and overwriting it upon reboot, or the files that were actually creating it every time.

While searching the drive’s system contents, I accidentally found that mDNSConfPatch.php is the one that checks the file mDNSResponder.conf and makes appropriate modifications. So assuming you’ve successfully installed ipkg and nano, the hack now consists of editing two separate files (after performing a necessary backup):

cd /proto/SxM_webui/admin/tools/

cp -p mDNSConfPatch.php mDNSConfPatch.php.original

nano mDNSConfPatch.php

and commenting out the latter part of this file, that checks for the _adisk._tcp service:

#!/usr/bin/php -q
<?php
require_once('wixHooks.class');
$hookObj = new wixHooks();

$macAddrFile = '/sys/class/net/eth0/address';
$macAddr = trim(@file_get_contents($macAddrFile));
$mDNSConfFile = '/etc/mDNSResponder.conf';

$isADiskExist = false;
$hostName = trim(@file_get_contents('/etc/hostname'));

$mdnsinfo = $hookObj->getMDNSInfo($mDNSConfFile);
for($i = 0; $i < count($mdnsinfo['mdns']); $i++) {
  if($mdnsinfo['mdns'][$i]['type'] == '_adisk._tcp') {
    $mdnsinfo['mdns'][$i]['txtversion'] = "\"sys=waMA=$macAddr\"";
    $isADiskExist = true;
  }
}

/*
if(!$isADiskExist) {
  $mdnsinfo['mdns'][$i]['name'] = "\"$hostName-Backup\"";
  $mdnsinfo['mdns'][$i]['type'] = '_adisk._tcp';
  $mdnsinfo['mdns'][$i]['domain'] = 'local.';
  $mdnsinfo['mdns'][$i]['port'] = '9';
  $mdnsinfo['mdns'][$i]['txtversion'] = "\"sys=waMA=$macAddr\"";
  $mdnsinfo['mdns'][$i]['model'] = "\"dk0=adVF=0x83,adVN=WD_Backup\"";
  $mdnsinfo['mdns'][$i]['vendor'] = '';
}
*/

$hookObj->setMDNSInfo($mdnsinfo, $mDNSConfFile);

return TRUE;
?>

Now that we disabled the check for the contents of file /etc/mDNSResponder.conf we can go ahead and edit it accordingly, just as before, and comment out (or delete) the last line that refers to the _adisk._tcp system service:

"MyBookMedia" _http._tcp local. 80 "TXTVersion=1.0" "DeviceModel=WDH2NC" "Vendor=WDC" "path=/index.php"
"MyBookMedia" _daap._tcp local. 3689 "TXTVersion=1.0" "DeviceModel=WDH2NC" "Vendor=WDC"
"MyBookMedia" _afpovertcp._tcp local. 548 "TXTVersion=1.0" "DeviceModel=WDH2NC" "Vendor=WDC"
// "MyBookMedia-Backup" _adisk._tcp local. 9 "sys=waMA=07:e0:17:8f:11:2f" "dk0=adVF=0x83,adVN=WD_Backup"

Reboot and you’re done ;-)