I occasionally find the desire to upload images via Eye-Fi while in a location that doesn’t have Wi-Fi, but my computer does have wired Internet access. Let’s say for lack of a better example location this could be a late 90’s remodeled hotel. In those instances, I feel using the Internet Sharing of Mac OS X seems to be an easy solution. Yeah, not so much. Most of the times I have used Internet Sharing, it worked great. However, those cases tended to be using other Apple hardware such as iPhone or iPad when I needed to trick it into thinking the device has a Wi-Fi connection when one was not readily available. However, using non-Apple devices seem to be a bit more tricky.
Using Internet Sharing in Max OS X utilizing the Airport for incoming tracking sets the Wi-Fi Network up in Infrastructure mode. The Mac is able to act as Router and provide NAT-based private IP addresses to clients. It also supports WEP, both 40 bit and 128 bit. It does not support WPA or WPA2 when the airport acts as access point.
reply_threshold_seconds
There are ample examples of findings of a bug in Mac OS X that a defect in the default configuration of DHCP server when Internet Sharing is enabled that delays the response to DHCP requests beyond what some client devices find acceptable. This causes the device to think it can’t receive an address and report an error. It turns out if this setting is decreased more devices can connect.
To fix:
- Go to System Preferences -> Sharing and enable Internet Sharing.
This is necessary because by default, the starting and stopping of Internet Sharing creates and deletes the /etc/bootpd.plist file.
- Open terminal and create a copy of the bootpd.plist file.
> cp /etc/bootpd.plist /tmp/bootpd.plist
- Open the /tmp/bootpd.plist file in editor (vi, TextEdit, TextWrangler, UltraEdit) and update the reply_threshold_seconds setting from 4 to 0.
Before:
... <key>reply_threshold_seconds</key> <integer>4</integer> ...After:
... <key>reply_threshold_seconds</key> <integer>0</integer> ... - Stop the Internet Sharing.
This is necessary to replace the /etc/bootpd.plist file. Doing the next step before this one will cause the file to disappear the next time Internet Sharing is turned off.
- From the terminal copy the edited file back to /etc directory.
> sudo cp /tmp/bootpd.plist /etc/ - Start Internet Sharing.
Once the /etc/bootpd.plist file exists different from the default, Starting/Stopping the service does not seem to affect the file any longer.
Assuming you do not enable WEP, it is likely any client device can now connect to the new wireless access point.
To WEP or Not To WEP
While WEP is accepted as broken and can easily be hacked to determine the password, the use of WEP and requirement of password does keep the average WiFi joe from hopping on to your network at their whim. There was a survey published recently that reported that while the vast majority of WiFi owners locked down their routers to prevent others from using their network, the people had little compunction about using other peoples network when found to be open. Once or twice I have been in a neighborhood and needed network access on laptop. It was handy to find open network I could VPN through. So, I would recommend using WEP when nothing else is available.
Unfortunately, this proved fruitless with Eye-Fi. There are plenty of examples on how to fix this for Windows-based machines that had problems connecting. In trying to come up with working solution for Eye-Fi I first determined whether another device, such as Windows XP laptop could connect to again see whether it was non-Apple issue in whole or Eye-Fi specific issue. What the WEP based troubleshooting all stated for this that when using an alphanumeric password, it is likely that different clients are encoding the plain text differently. So, it is best to use a hex password which doesn’t require encoding process to use.
To use hex password, you can’t just enter the 10 or 26 hex characters into the password field in Mac OS X. Rather you need to prefix it with ‘$’ (dollar sign) character. The character explicitly tells the Internet Sharing control to use the values as hex.
Example: 40 Bit Password. Enter the following in the Mac OS X password box:
$073E2ABF12
Enter the following in Windows or other client:
073E2ABF12
The 128 Bit version is much the same except using 26 hex character string.
Utilizing this approach I got the Windows laptop to connect, but the Eye-Fi card remain unable to fully connect. Except that I finally got a different response setting up the card in Eye Fi Center than previously. Specifically, most previous failures had the Connect button spinning into Idle Card state. This time, the error message stated to check whether the router was filtering MAC addresses and to allow the Eye-Fi card’s address if that was the case.
One last trick will be try setting the card up on Mac Mini connecting through to the Mac Book Pro in case there is any issues with circular connectivity. However, I don’t think this is the case since I added the network to the Eye-Fi card by stating the network wasn’t present. This should add the network to the card and if setup properly allow the card to connect in the camera. This still didn’t happen, so don’t have too much faith this is a circular/dual addressing issue.
No WEP, but locked with MAC Filtering
In the end, I want this to work even if I don’t have the illusion of security. So, go back to open access, but I don’t wan’t any Joe Blow connecting to my laptop. To prevent this then, means adding some MAC address filtering to allow allow known devices to connect to the Mac Book.
The problem is that the Internet Sharing preferences pane does not have an option for setting up MAC address filters. However, the bootpd configuration file does. Since I have already modified the /etc/bootpd.plist to change the reply_threshold_seconds it can be modified to enable MAC address filtering. To do this, just add the key allow with a string array value between the Subnets and bootp_enabled keys.
....
<key>allow</key>
<array>
<string>0:17:43:a3:2d:45</string>
</array></strong>
...
The MAC address entered is the one for the Eye-Fi card. In this case, since I got the error message with the address prominently displayed, it was pretty easy to find. Otherwise, right clicking on the card in Eye-Fi Center will list the MAC address in the menu with option to copy it.
Update the /etc/bootpd.plist file and restart the service. Now Eye-Fi could connect, but iPhone and Windows XP laptops could not. So all appears well enough.
Security
I never like not enabling some encryption even if it is just WEP. Even when on public hot spots, I like to use VPN to prevent local traffic sniffing.
I kind of figure in this case, the only thing being transferred is photos which generally end up in public locations anyway. If I need other devices somewhat secured, it is enough to make the changes, add the new device to MAC address filters and restart the filter.
What’s Next
I will keep trying to see if I can eventually get the card working with WEP through Mac OS X / Internet Sharing. One thing is to check if it is local or just as problematic same machine syndrome.
Full /etc/bootpd.plist File
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Subnets</key>
<array>
<dict>
<key>_creator</key>
<string>com.apple.nat</string>
<key>allocate</key>
<true/>
<key>dhcp_domain_name_server</key>
<string>10.0.2.1</string>
<key>dhcp_router</key>
<string>10.0.2.1</string>
<key>lease_max</key>
<integer>86400</integer>
<key>lease_min</key>
<integer>86400</integer>
<key>name</key>
<string>10.0.2</string>
<key>net_address</key>
<string>10.0.2.0</string>
<key>net_mask</key>
<string>255.255.255.0</string>
<key>net_range</key>
<array>
<string>10.0.2.2</string>
<string>10.0.2.254</string>
</array>
</dict>
</array>
<key>allow</key>
<array>
<string>0:17:43:a3:2d:45</string>
</array>
<key>bootp_enabled</key>
<false/>
<key>detect_other_dhcp_server</key>
<integer>1</integer>
<key>dhcp_enabled</key>
<array>
<string>en1</string>
</array>
<key>reply_threshold_seconds</key>
<integer>0</integer>
</dict>
</plist>
Awesome, this worked! You rock, sir!