My remedy is shsu -- a very simple patch on top of the standard recovery image that will prevent loss of root access when applying an OTA update. Here's how to install and use it:

1. Download flash_image and recovery-ERE22D-shsu.
2. Push them to /sdcard on the phone -- either mount the SD card and copy it or use

   adb push flash_image /sdcard/
   adb push recovery-ERE22D-shsu.img /sdcard/
   

   .
3. Execute within adb shell:

   cd /sdcard/
   chmod 755 flash_image
   su -c ./flash_image recovery recovery-ERE22D-shsu.img
   

Test Drive

Verify that you have installed the recovery image correctly, by rebooting into recovery mode. The easiest way:

adb reboot recovery

[ szym ] system recovery utility

This recovery will install shsu (shell-only su) every time it exits, so after rebooting back you can check that it worked by running within adb shell:

ls -l /system/xbin/shsu
-rwsr-x--- root     shell       80492 2011-01-02 02:10 shsu
shsu
id
uid=0(root) gid=0(root) groups=...

Restoring root access using shsu

It is now safe to apply an OTA update. After applying the update, you will lose root access via regular su. Assuming the (now ineffective) su binary is in /system/xbin we need to fix its permissions. Enter adb shell:

shsu
mount -o remount,rw /dev/block/mtdblock4 /system
chmod 4755 /system/xbin/su
mount -o remount,ro /dev/block/mtdblock4 /system

HTC Aria, Liberty, Desire(?)

1. Download fw_bcm4329.bin to /sdcard/. You probably won't be able to download this on the phone (due to the .bin extension) so download it on your computer and then put it on /sdcard either by mounting the SD card via USB and copying the file over or via adb:

   adb push fw_bcm4329.bin /sdcard/
   

2. Unmount the SD card (it needs to be unmounted from USB in order for Android apps to read from it).
3. In Barnacle, configure Settings > Custom Wifi Ad-hoc > Aria/Liberty
4. Start Barnacle

The reason why 0.6.5 (37) was failing on Milestone is most bizarre: a process would exit with status 0 and yet the shell would treat that as "false", hence this was failing (only on Milestone!):

./wifi load || exit

The problem here is timing. Basically, the wireless driver on many Android phones only beacons an ad-hoc network for a while, and then if no other client associates, it stops. The next time it tries, it uses a different BSSID. Unfortunately, AFAIK, there's nothing we can do to stop it. If you try providing a BSSID in the settings, it might simply fail to beacon at all (it would only associate with an existing network matching that BSSID).

On the other hand it seems that the iPad won't beacon a network. It only wants to associate with an existing network and it does so by matching the BSSID after you tell it to connect. So you can see, there is a very short window from the moment your Droid starts beaconing to the moment it will inevitably change its BSSID. This short window is when your iPad can connect with it.

The known workaround right now is to first establish an ad-hoc network by other means and then tell an iPad to connect to it. For example, if you can connect your laptop to barnacle, you should then be able to connect iPad without issues. You can then turn your laptop off. ]]> http://szym.net/2010/12/barnacle-and-ipad/feed/ 11 http://szym.net/2010/12/whats-new-in-barnacle-0-6-5/ http://szym.net/2010/12/whats-new-in-barnacle-0-6-5/#comments Fri, 24 Dec 2010 07:28:05 +0000 szym http://szym.net/?p=287 read more »]]> Version 0.6.5 is hopefully the last of the December series of updates (starting at 0.6, 0.6.1, 0.6.2, 0.6.3 and 0.6.4 so far).

In 0.6.4, three distinct exceptions (also known as Force Close or FC) got squished. Also, added some handling of the nasty situation when another app enables wifi. If this happens, Barnacle tries to restart as gracefully as possible (which is not that gracefully unfortunately).

In 0.6.5, the setup scripts got a handful of fixes. There should be no more spurious "su not found" nor errors when connecting to NAT (for Access Control). Finally, switching between 3G and 4G should be as simple as restarting Barnacle (it will use whatever is available at the time of start).

Unfortunately, didn't have time to fix the GRE forwarding issue. ]]> http://szym.net/2010/12/whats-new-in-barnacle-0-6-5/feed/ 2 http://szym.net/2010/12/whats-new-in-barnacle-0-6-3/ http://szym.net/2010/12/whats-new-in-barnacle-0-6-3/#comments Wed, 22 Dec 2010 10:34:54 +0000 szym http://szym.net/?p=281 read more »]]> Version 0.6.3 is so major I was contemplating calling it 0.7.

Widget, encryption, bug fixes, ... a whole bunch of goodies for the holidays!

Donation widget!

"Barnacle Wifi Tether - donate" is now the "Barnacle Widget"! Everyone who donated so far (2000 users!) gets a nice gift for the holidays

You will need to download the free Barnacle Wifi Tether yourself, but that shouldn't be too hard.

After some experimentation, I discovered that due to some bad design in Android's permissions, you will also need to reinstall Barnacle Widget (from the Market) after installing Barnacle Wifi Tether for the first time. Otherwise, the widget won't be granted the permissions to control Barnacle.

wpa_supplicant fixed for Droid 2.2

After quite a bit of work, I managed to get wpa_supplicant to behave on Moto Droid 2.2. A working wpa_supplicant means WEP is working again! More than that, it seems the new wpa_supplicant is much more consistent with respect to the beaconed BSSID and it features its own auto-beaconing.

I also added a small fix that allows wpa_supplicant join existing ad-hoc networks. This could help in the few cases when the laptop won't connect to Barnacle, but Barnacle can connect to the laptop.

40- and 104-bit WEP keys in wext

Users who don't have wpa_supplicant working might be able to get WEP working on their phones as well after support for both 40- and 104-bit keys is fixed. Note, however, that whether WEP will actually work without wpa_supplicant depends on how well the wireless driver for your device implements wireless extensions.

More reliable cleanup

I managed to make the after-shutdown-cleanup much more reliable, so you should see "port already in use" much less frequently. Similarly, wifi should now work after Barnacle is stopped without having to kill the app.

"run not found" fixed?

Finally, added a small fix that should make the "run not found" problem (due to some bad implementations of su) go away, and squished yet another FC.

Ad-hoc has slipped in priority in favor of other superior solutions keeping power constraints and security in mind. Soft Ap support exists and wi-fi direct support will come in the future.

...even though ad-hoc is an age old technology supported by many many devices, and direct wifi is not available yet. But there's hope:

Wifi direct is a layer that auto configures one of the devices as a Soft Ap. The benefits you have with Soft Ap are the same that you will get with wifi direct (wpa2 and power management). Thats not to say there is no good reason to add ad-hoc, there is - compatibility with devices that only support ad-hoc. (...) Expect to see both direct and ad-hoc support in the future.

I wonder though if Wi-Fi Direct will support group communication, or will one device (the soft AP) need to do all the heavy lifting. In an ad-hoc network, no node acts as a relay: all traffic is direct, broadcasts are direct. In an infrastructure (or soft AP) network, the AP relays all traffic: even broadcast packets will be sent to the AP which then broadcasts them to all.

Here's a snippet from Wi-Fi Alliance's FAQ on Wi-Fi Direct:

Is this the same as Ad Hoc mode?

No. Ad Hoc, or IBSS, mode is a legacy protocol for Wi-Fi devices, and Wi-Fi Direct is a new innovation. Wi-Fi Direct brings important security features, ease of setup, and higher performance that is not currently available in Ad Hoc mode. With Wi-Fi Direct, a device can maintain a simultaneous connection to an infrastructure network – this isn’t possible with Ad Hoc.

Is the specification underlying the Wi-Fi Direct certification program based on the IEEE 802.11s (Mesh) or 802.11z (Direct Link Setup) standards?

No. The specification underlying the Wi-Fi Direct certification program was developed within the Wi-Fi Alliance by member companies. It operates on 802.11 devices but is not linked to any specific IEEE 802.11 amendment.

This means, Wi-Fi Direct is not an IEEE standard, but a specification from the Wi-Fi Alliance. It's not necessarily a bad thing. The rationale here seems to be that the reason why ad-hoc failed despite Wi-Fi certification was because it wasn't "easy enough for home users", and so Wi-Fi Direct is essentially built on top of Wi-Fi Protected Setup.

I have to say I'm rather disappointed by the arguments that legacy ad-hoc, or IBSS, deserves to be abandoned now because it was insecure or slow. Ad-hoc is basically defined above the MAC, so there's no fundamental reason why ad-hoc would not be able to support any of the data-rates or data encryption algorithms that are supported by the client device. That ad-hoc never evolved beyond 802.11b is to be blamed on the Wi-Fi Alliance for not updating the certification to allow 802.11g data-rates or WPA2 AES-based encryption.

Although I can see how WPS will make the "nightmare of setting up ad-hoc" go away for many users, I don't see any substantial advantages of the AP - STA approach taken in Wi-Fi Direct. It almost seems like this is a "lazy" solution along the lines of: since soft AP is becoming more proliferate (ironically to support the crippled STA devices that cannot do ad-hoc, like PS3, Wii, etc.), why not come up with a protocol that will establish which station should become a soft AP on-demand?

• Auto Associate enables the auto-beaconing feature but you should disable it if it's causing trouble
• New Client Actions allows you to set notification options (sound/light) and specify that a new client should be automatically granted access. (You can always deny access from the clients list later.)

An OTA update typically removes the setuid bit from all executables on the system partition (the only one allowed to have the setuid bit set). To avoid losing root, I crafted my own recovery image which differs from the vanilla recovery image in one major aspect: before it reboots, it installs shsu: a shell-only su. Thus, even after unintended OTA update (happened before), I keep my root access.

shsu branch

This is a direct import of bootable/recovery from the AOSP master. A minimal patch adds a new option install shsu which installs the included standard su as shsu (shsu stands for shell-only su which means it only works over adb shell).

The new option install shsu is executed every time before reboot. The action is implemented by setting a property shsu.install=1. This change is picked up by init which executes the action specified in init.rc using builtins only:

# copy su to /system/xbin/shsu using builtins only
on property:shsu.install=1
    mount yaffs2 mtd@system /system
    mount yaffs2 mtd@system /system rw remount
    mkdir /system/xbin

    copy /sbin/su /system/xbin/shsu
    chown root shell /system/xbin/shsu
    chmod 4750 /system/xbin/shsu

    setprop shsu.installed 1
    write /sbin/shsu.installed 1

    # also, recovery overwrite precautions
    copy /system/etc/install-recovery.sh /system/etc/install-recovery.sh.not
    write /system/etc/install-recovery.sh "exit #"

One of the effects of this action is also disabling the automated patching of the recovery partition. You can later apply the recovery patch manually by executing (in su shell):

    sh /etc/install-recovery.sh.not

fix-recovery

A simple script tools/fix-recovery.sh automates the process of retrieving the current recovery image, replacing the recovery binary, installing the shsu.install hook, and reflashing the image. It also installs busybox if available in your out directory and "unsecures" properties to enable adb.

This script depends on unbootimg

Usage:

./fix-recovery.sh (all|pull|fix|flash) [recovery-image-name]

You will need to build the following from the Android repo beforehand:

make su flash_image recovery adbd unpack.sh repack.sh mkbootimg unbootimg

If you can't use fix_recovery.sh (for example, you're using Windows) I have prepared an auto-root recovery for Motorola Droid.]]> http://szym.net/2010/12/shsu-recovery/feed/ 2