Are you suffering from slow transfer speeds when copying files to a USB hard drive? Read on as this may be of some help.

I was experiencing very slow throughput when copying large files to a Western Digital Passport drive connected to a Shuttle SA76G2 running Fedora 10.

Using the command ‘lsusb’ you can see all the USB devices that are present on your system, e.g.

$ /sbin/lsusb | sort -n

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 005: ID 1058:070a Western Digital Technologies, Inc.
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

The above output shows that there are seven USB root hubs available on my system, but only two of these support the high-speed USB 2.0 protocol. In order to benefit from high-speed data throughput the external USB disk needs to be connected to a bus with a 2.0 root hub. It also helps if you attach one device per bus so they do not share bus bandwidth.

The Shuttle SA76G2 specs claim that all the USB ports are 2.0 compliant, but ‘lsusb’ reveals that Fedora 10 detects only two 2.0 root hubs. After moving the external drive between the physical USB ports I identified a port which was attached to a 2.0 root hub and since then data throughput has been excellent.

An aide memoire for me – here’s how to persuade Yum to use a HTTP proxy:

$ http_proxy=http://127.0.0.1:5865 ; export http_proxy

It’s as simple as that!

I spent a long time today struggling to work out why DNS lookups were failing on a MacBook Pro while connected over Airport WiFi, but not when using an ethernet connection to the same router.

It turns out that although the Airport connection looked perfectly normal, when I went into System Preferences -> Sharing, it showed that Internet Sharing was enabled. The AirPort status icon in the menu bar did not show that Internet Sharing was enabled, but sure enough as soon as I unchecked the box everything was back to normal.

Apple Leopard fail!

I have received a rather bizarre email from Microsoft:

Dear Windows Live User,

We are contacting you regarding your communication preference settings
for Windows Live and MSN.

Currently, your settings do not allow Microsoft to send you promotional
information or survey invitations about Windows Live and MSN. We would
like to communicate important product updates to you, so if you would
like to change your settings, please visit your account profile here
to change your preferences.

Sincerely,
The Windows Live Team

I wonder – what part of do not send me junk do they not understand?

My quest to unravel the hidden mysteries of the eFrame 1000’s proprietary protocols has been successful and I will start to share my initial findings.

The first significant discovery was that the frame acts as a client and connects to the PC server in response to specially formed broadcast packets or status requests. It also uses standard FTP to retrieve files from the PC.

To discover any photo frames on the network, the PC sends a broadcast UDP message to port 21900 and then waits for a response. The content of the message is as follows:

Search,PF110-PC,PF110-DEV,20021,21901,shuttle,shuttle,PF110,QmitwPF,1,192.168.1.2

• The 1st parameter (Search) is the command
• The 2nd & 3rd parameters (PF110) appear to be internal names for the eFrame
• The 4th parameter (20021) is the port number that the FTP server is listening on
• The 5th parameter (21901) is the port number that the message server is listening on
• The 6th & 7th parameters (‘shuttle’ in this case) is the name of the PC server
• The 8th parameter (PF110) is the FTP username
• The 9th parameter (QmitwPF) is the FTP password
• The 10th parameter (192.168.1.2) is the IP address of the server

When the frame receives this message, it responds to the server address and messaging port number with a message similar to the following:

Register,PF110-DEV,PF110,PC,21902,RegisterStatus,20021,21902,0829004123,”000829004123″,PhotoFrame,PhotoFrame,1,192.168.1.3

This message contains the port number of the frame’s messaging service and the device’s unique ID / serial number.

The PC server may also send status request messages:

Read,PF110-PC,PF110-DEV,21901,SystemStatus

To which the frame responds with:

Read-Resp,PF110-DEV,PF110-PC,21902,SystemStatus,0,0829004123,”000829004123″,1.0.0      ,53446460

The response contains the serial number / ID of the frame and the firmware version.

The following status request prompts the frame to report back the amount of free internal storage:

Read,PF110-PC,PF110-DEV,21901,StorageStatus

A typical response from the frame is as follows:

Read-Resp,PF110-DEV,PF110-PC,21902,StorageStatus,0,130990080,128073728

I have written some Perl scripts to automate the frame discovery, registration and file transfer which I will attach shortly.