3.2 Bluetooth Tether Issue Workaround
Workaround
Further following up on the findings which I described upthread, I've successfully tested a workaround and several US Wi-Fi devices (MZ604), and I'd like to get some more feedback on it.
I implemented this workaround as an init trigger in the init.stingray.rc file, which, unfortunately, is located on the boot partition. This means that the workaround requires a modded boot image, and flashing any other boot images (kernels, etc.) will overwrite the workaround. Although I would have preferred to dive deeper into the Honeycomb code and fix the bug right at the source, time isn't on my side lately.
Installation via Clockwork Mod Recovery
Today, I posted a rooted 3.2.1 update for the US Xoom Wi-Fi that includes my Bluetooth tether issue workaround:
[UPDATE][US WIFI ONLY]Android 3.2.1 on Xoom Wi-Fi, Root, via ClockworkMod Recovery
If you have a US MZ604 Xoom Wi-Fi and you're comfortable flashing a modded stock ROM and kernel, please give this a shot and let me know if it works for you.
If you have a different version of the device or if you want to keep your custom kernel, however, then those specific boot images need to be updated to include the workaround, which is a developer-level activity.
Developer Notes
Those who are already comfortable unpacking and repacking boot images can append the following snippet to the init.stingray.rc file to implement the workaround:
It's pretty simple. More background follows.
When comparing getprops between 3.0.1 and 3.2 all through the Bluetooth tethering process, there were a few incongruities, one of which opened up the possibility of using an init trigger:
At first, I was concerned that triggering the stopping of dhcpcd after the failing second tether attempt (rather than after the ending of the successful first one) would be an issue, but it seems like the service is stopped before kbnepd gets its groove on. This allows all subsequent tether attempts to proceed properly, and I haven't found any situations where stopping dhcpcd when dhcp.bnep0.result="" would have any negative impact.
Again, this is more of a hack than a bugfix, but it's worked for several devices so far. Please chime in if you have any feedback. Thanks!
Even if other issues are prioritized higher, it doesn't mean that no one cares. *hug*
Workaround
Further following up on the findings which I described upthread, I've successfully tested a workaround and several US Wi-Fi devices (MZ604), and I'd like to get some more feedback on it.
I implemented this workaround as an init trigger in the init.stingray.rc file, which, unfortunately, is located on the boot partition. This means that the workaround requires a modded boot image, and flashing any other boot images (kernels, etc.) will overwrite the workaround. Although I would have preferred to dive deeper into the Honeycomb code and fix the bug right at the source, time isn't on my side lately.
Installation via Clockwork Mod Recovery
Today, I posted a rooted 3.2.1 update for the US Xoom Wi-Fi that includes my Bluetooth tether issue workaround:
[UPDATE][US WIFI ONLY]Android 3.2.1 on Xoom Wi-Fi, Root, via ClockworkMod Recovery
If you have a US MZ604 Xoom Wi-Fi and you're comfortable flashing a modded stock ROM and kernel, please give this a shot and let me know if it works for you.
If you have a different version of the device or if you want to keep your custom kernel, however, then those specific boot images need to be updated to include the workaround, which is a developer-level activity.
Developer Notes
Those who are already comfortable unpacking and repacking boot images can append the following snippet to the init.stingray.rc file to implement the workaround:
Code:
# Bluetooth tethering issue (introduced in 3.2 HTJ85B) workaround
on property:dhcp.bnep0.result=""
stop dhcpcdWhen comparing getprops between 3.0.1 and 3.2 all through the Bluetooth tethering process, there were a few incongruities, one of which opened up the possibility of using an init trigger:
- After attempting 1st tether
- 3.0.1: dhcp.bnep0.result=[ok]
- 3.2: dhcp.bnep0.result=[ok]
- After ending 1st tether
- 3.0.1: dhcp.bnep0.result=[failed]
- 3.2: dhcp.bnep0.result=[ok] (UNCHANGED)
- After attempting 2nd tether
- 3.0.1: dhcp.bnep0.result=[ok]
- 3.2: dhcp.bnep0.result=[]
At first, I was concerned that triggering the stopping of dhcpcd after the failing second tether attempt (rather than after the ending of the successful first one) would be an issue, but it seems like the service is stopped before kbnepd gets its groove on. This allows all subsequent tether attempts to proceed properly, and I haven't found any situations where stopping dhcpcd when dhcp.bnep0.result="" would have any negative impact.
Again, this is more of a hack than a bugfix, but it's worked for several devices so far. Please chime in if you have any feedback. Thanks!
Last edited:
