Xoom 3.2 and Bluetooth Tethering...

M

Matt112211

Member
Dec 3, 2010
18
5
0
Jul 18, 2011 at 7:36 PM
Affter the update to 3.2 on the Wifi model, some people have reported issues with Bluetooth tethering and some have not. It seems that both people are right. It works once, but then after you disconnect, then it will not work again until you restart your Xoom.

There might be other ways around restarting, but so far that has worked every time that I have tried it. Which is annoying since it does take a while to restart. I just go ahead and restart when I have time, and then it is ready to go when I need to enable the connection.

Hopefully this is a minor issue that Google will resolve in 3.2.1

I am currently running stock 3.2 on a wi-fi only Xoom.

-Matt
 
  • Like
Reactions: okantomi
M

McDV

Senior Member
May 26, 2008
326
112
0
Jul 30, 2011 at 9:22 AM
OK, since nothing is happening anymore here, I'll get that thread up again. ;)

This issue really sucks, so I tried different things to get it fixed...

What I know: It seems to be a dhcp-problem. If you are rooted and type "netcfg" in a terminal, you'll see that the interface "bnep0" (that's the one for bluetooth-tethering) will only get an IP-address and a subnet-mask on the first connect.

After reconnecting the IP keeps stuck at 0.0.0.0/0. Anyway, it seems that it gets an IPV6-address!?

By typing "su dhcpcd" you sometimes can get a valid IP for bnep0 and a working tethering, but that's not sure... Sometimes you'll get an IP, but the subnet is stuck at 0.

At first I thought it was a bug with the dhcp-deamon, so I pulled /system/bin/dhcpcd out of a 3.1 ROM and pushed it to my 3.2 ROM. Unfortunately there was no difference...

My new ideas are:
1) Maybe it could be possible to define a static configuration for bnep0. My problem is that I don't find the proper config-files. Surely someone can tell me. This way we could maybe work around a dhcp-issue (if it is).

2) Maybe it could(!) also be something with IPV6... It could help to deactivate IPV6, but here it's the same, I don't know how.

Maybe you guys have more ideas! This issue really, really sucks and I am sure we can at least find a workaround! Rebooting can't be the solution. ;)
 
stachre

stachre

Senior Member
Mar 30, 2011
98
347
0
Jul 30, 2011 at 11:43 AM
McDV said:
Maybe you guys have more ideas! This issue really, really sucks and I am sure we can at least find a workaround! Rebooting can't be the solution. ;)
Click to expand...
Where I last left off, I found that dhcpcd was still running after terminating the initial successful Bluetooth tether. Pre-3.2, both kbnepd and dhcpcd would be stopped.

Killing dhcpcd before attempting a re-tether may be an interim solution. On my device (MZ604 Wi-Fi, 3.2 stock, rooted), if I killed the orphaned dhcpcd process, I could re-tether successfully without a reboot. Savvy users with root, please try this on your device and let me know your feedback:

  1. From a fresh boot, initiate a successful Bluetooth tether
  2. Before terminating the tether, bring up a terminal/adb shell
  3. Run ps, note the kbnepd and dhcpcd processes and their pid's
  4. Terminate the tether
  5. In the terminal/adb shell, run ps again
  6. Note the absence of kbnepd, but dhcpcd still running (same pid as before)
  7. kill dhcpcd
  8. Try re-tethering via Bluetooth

I compared getprop during a successful tether with that after terminating the tether to see if there was a property change which we could use as an init trigger for a hack (kill dhcpcd when x = y), but there was no change. kbnepd doesn't even show on getprop, unfortunately, at least on my device.

Note also that the 3.2 update patches dhcpcd (brd also pointed out changes to ramdisk [init.stingray.rc] regarding dhcpcd) and libnetutils. Comparing logcats between 3.1 and 3.2 and digging through pre-Honeycomb source code gives some indicators that the bug might be in libnetutils. Time wasn't very permitting for me to continue following up on it this week, however.

Until we find a better solution, I was considering putting together a quick and dirty 1x1 widget which rooted users could tap to manually kill dhcpcd before re-tethering. I'll await feedback first on whether manually killing dhcpcd (steps above) works for others. So lemme know. :D
 
Last edited:
M

McDV

Senior Member
May 26, 2008
326
112
0
Jul 30, 2011 at 2:35 PM
I've tried it, with no result.

For me there isn't the problem that dhcpcd isn't terminated. Anyway, I've tried to "su kill dhcpcd", but it doesn't help at all...

The idea with libnetutils.so sound good. So I've tried to replace it with the one from 3.1. Unfortunately it ended up in bootloops. ;) Maybe someone could try to fix libnetutils.so :)
 
M

McDV

Senior Member
May 26, 2008
326
112
0
Aug 4, 2011 at 6:45 PM
Does s.o. know, if it would be possible, to port the DHCP-client from 3.1 to 3.2? Maybe it would be sufficient to just copy mor than only /system/bin/dhcpcd or libnetutils.so. But I don't know which files need to be copied to not end up into bootloops.

For the moment I downgraded to 3.1, but that's not really satisfying...
 
M

McDV

Senior Member
May 26, 2008
326
112
0
Aug 11, 2011 at 2:29 PM
No fixes, workarounds or other solutions by now? OK, looks like I'll have to stay at 3.1 'till Ice Cream Sandwich. ;-)
 
M

McDV

Senior Member
May 26, 2008
326
112
0
Aug 18, 2011 at 4:08 PM
Anyway, it seems that we, who want to use bluetooth-tethering, are a minority, so no one really cares. Neither Google, nore the devs here. ;-) Not even the Tiamat-Team seems to care.

Maybe we'll have to wait until Ice Cream Sandwich is released or maybe there is a 3.2.1 or 3.3 update...

I think it would be possible to port the DHCP-client from 3.1 to 3.2 to solve the problem, but I don't know how.

So the only workaround is using 3.1 - optionally with Tiamat 1.4.4 kernel, because Tiamat 2.1 doesn't work with 3.1 anymore.
 
You must log in or register to reply here.

New posts

Our Apps
Get our official app!
The best way to access XDA on your phone
Nav Gestures
Add swipe gestures to any Android
One Handed Mode
Eases uses one hand with your phone