For various reasons, you might end up needing to hook up your iOS device directly to an Ethernet network without using Wi-Fi. For example, maybe you’re in an area with bad Wi-Fi reception. Or perhaps you are trying to do something that requires high bandwidth and your Wi-Fi access point doesn’t have the best speed.

Well, it turns out that iOS has supported Ethernet for a while. Obviously your iOS device doesn’t have an Ethernet port, so you have to use a USB-to-Ethernet adapter. As of iOS 10.2, there is even a settings screen that appears when you plug in a supported adapter. Older versions of iOS apparently still supported Ethernet, but didn’t provide a screen for setting it up, so you were probably stuck with the default settings (grabbing an IP address from a DHCP server). Now that there is a setup screen, you can configure it exactly how you want.

I tested it out with three devices tonight, and they all worked flawlessly: iPhone 6, iPhone 7, and iPad Air.

Read the rest of this entry

I recently ran into a problem upgrading a computer from Windows 7 to Windows 10. I received an error message with the following error code: 0x800703ed

It turns out this system was a dual-boot Linux and Windows system. I was actually booting to a different hard drive which had GRUB installed, and then GRUB was booting to my Windows drive. I fixed the problem by switching my BIOS boot order to boot directly to the drive with Windows 7 installed and then repeated the update process. This resulted in a successful Windows 10 upgrade. After the upgrade was complete I was able to change my BIOS boot order back to the way it was before, and now everything works fine.

After upgrading my Ubuntu server from 14.04 to 16.04, I noticed that legacy AppleTalk clients connecting to my netatalk (afpd) server showed an empty volume list; I could no longer access my “Home Directory” share that showed up by default in 14.04.

After some research, I discovered that the 14.04 to 16.04 upgrade brought netatalk from version 2.2.2 up to 2.2.5. It turns out that 2.2.5 has a bug which causes AppleTalk clients to not see anything from /etc/netatalk/AppleVolumes.default; only /etc/netatalk/AppleVolumes.system is read. Here is a link to the bug report I posted.

You could rebuild netatalk 2.2.5 with the latest unreleased patches as I mentioned in my first comment of the bug report above, or you can do what I did: just put your volumes into /etc/netatalk/AppleVolumes.system instead. I’m unsure if the “~” share works properly when it’s in /etc/netatalk/AppleVolumes.system, so I hardcoded it to my home directory path just in case. It works fine!