This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 595902 - Cannot set up Bluetooth DUN with Windows Mobile phone
Cannot set up Bluetooth DUN with Windows Mobile phone
Product: Fedora
Classification: Fedora
Component: ModemManager (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2010-05-25 17:29 EDT by Adam Williamson
Modified: 2011-06-27 12:39 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-06-27 12:39:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:

Attachments (Terms of Use)
debug messages from modem-manager (2.21 KB, text/plain)
2010-05-25 17:30 EDT, Adam Williamson
no flags Details

  None (edit)
Description Adam Williamson 2010-05-25 17:29:43 EDT
Phone is an AT&T Tilt 2 - an HTC Rhodium variant - on the Telus network (a Canadian network, uses HSPA). Phone is running the EnergyROM third-party Windows Mobile build - . This is a very recent Windows Mobile 6.5.5 build with various customizations, it's very commonly used by owners of such phones as a substantial improvement on the stock Windows build.

Pairing works fine. On the final screen, when I check the 'Access the Internet using your mobile phone (DUN)' box, it tries to detect the settings. The phone asks whether I should allow the PC to connect to the Internet. I say 'yes'. It spins for a couple of minutes, then fails with 'Error: timed out detecting phone details.'

modem-manager --debug output, as requested by Dan:

** (modem-manager:5459): DEBUG: (tty/ttyS0): port's parent platform driver is not whitelisted
** (modem-manager:5459): DEBUG: (tty/ttyS1): port's parent platform driver is not whitelisted
** (modem-manager:5459): DEBUG: (tty/ttyS2): port's parent platform driver is not whitelisted
** (modem-manager:5459): DEBUG: (tty/ttyS3): port's parent platform driver is not whitelisted
** (modem-manager:5459): DEBUG: (net/pan0): could not get port's parent device
** (modem-manager:5459): DEBUG: (tty/rfcomm0): could not get port's parent device
** Message: (rfcomm0) opening serial device...
** (modem-manager:5459): DEBUG: <1274822685.356316> (rfcomm0) device open count is 1 (open)
** (modem-manager:5459): DEBUG: (rfcomm0): probe requested by plugin 'Generic'
** (modem-manager:5459): DEBUG: <1274822685.455750> (rfcomm0): --> 'AT+GCAP<CR>'
** (modem-manager:5459): DEBUG: <1274822686.267428> (rfcomm0): <-- '<CR><LF>+GCAP:0<CR><LF>'
** (modem-manager:5459): DEBUG: <1274822686.268510> (rfcomm0): <-- '<CR><LF>ERROR<CR><LF>'
** (modem-manager:5459): DEBUG: Got failure code 100: Unknown error
** (modem-manager:5459): DEBUG: <1274822686.268619> (rfcomm0): --> 'AT+GCAP<CR>'
** (modem-manager:5459): DEBUG: <1274822687.69618> (rfcomm0): <-- '<CR><LF>+GCAP:0<CR><LF><CR><LF>ERROR<CR><LF>'
** (modem-manager:5459): DEBUG: Got failure code 100: Unknown error
** (modem-manager:5459): DEBUG: <1274822687.69754> (rfcomm0): --> 'AT+GCAP<CR>'
** (modem-manager:5459): DEBUG: <1274822687.871810> (rfcomm0): <-- '<CR><LF>+GCAP:0<CR><LF><CR><LF>ERROR<CR><LF>'
** (modem-manager:5459): DEBUG: Got failure code 100: Unknown error
** (modem-manager:5459): DEBUG: <1274822687.871917> (rfcomm0): --> 'ATI<CR>'
** (modem-manager:5459): DEBUG: <1274822688.272394> (rfcomm0): <-- '5601<CR><LF><CR><LF>OK<CR><LF>'
** (modem-manager:5459): DEBUG: <1274822688.272543> (rfcomm0): --> 'AT+CPIN?<CR>'
** (modem-manager:5459): DEBUG: <1274822689.173760> (rfcomm0): <-- '<CR><LF>OK<CR><LF>'
** (modem-manager:5459): DEBUG: <1274822689.173897> (rfcomm0): --> 'AT+CGMM<CR>'
** (modem-manager:5459): DEBUG: <1274822689.975057> (rfcomm0): <-- '<CR><LF>OK<CR><LF>'
** (modem-manager:5459): DEBUG: <1274822689.975188> (rfcomm0) device open count is 0 (close)
** Message: (rfcomm0) closing serial device...
Comment 1 Adam Williamson 2010-05-25 17:30:56 EDT
Created attachment 416564 [details]
debug messages from modem-manager

debug messages.
Comment 2 Adam Williamson 2010-05-25 17:37:47 EDT
attached the same output, as BZ mangled it as usual.
Comment 3 Dan Williams 2010-05-26 01:23:19 EDT
Yup, the phone is pretty dumb and doesn't report any usable capabilities.  Need to figure out something else for these things.  Any chance you can do the BT rfcomm connection manually and then minicom to the phone and grab some AT command results?


We could add those to the detection list for GSM devices since CDMA devices will most likely not support these.
Comment 4 Adam Williamson 2010-05-26 16:09:31 EDT
well, I'm trying, but I'm not sure I'm doing it right...

I pair the phone, then do:

rfcomm bind /dev/rfcomm0 <BT:ADDRESS>
minicom -o -D /dev/rfcomm0

I enter the AT commands, but nothing comes up. Tried the same with cutecom, which is supposed to be a sort of graphical minicom, and the same - it can open /dev/rfcomm0 and seems to accept command input, but nothing provokes any kind of I missing something?

Fedora Bugzappers volunteer triage team
Comment 5 Dan Williams 2010-06-15 01:23:36 EDT
'bind' might work, but 'connect' is what I've been using.

But I've noticed that F13 is *screwed* talking to some devices.  It won't talk to my Sprint Rumor anymore at all, while F11 and F12 worked.  A lot of USB stack issues apparently with failures to resubmit URBs printed in 'dmesg'.  Do you get any dmesg output when trying to talk to the the phone?
Comment 6 Adam Williamson 2010-06-15 11:35:25 EDT
I didn't notice, but i'll check. Unfortunately I have no F12 installs left to compare against :/ Maybe I can compare from a live CD. I'll try and do this today.

Fedora Bugzappers volunteer triage team
Comment 7 Adam Williamson 2010-06-15 18:45:30 EDT
yup, tailing /var/log/messages while trying again, I see a bunch of messages of the type you describe. I'll see if I can try with an F12 live image (though it may be tricky as my test laptop is rather new and the hardware might not play with f12...)

Fedora Bugzappers volunteer triage team
Comment 8 Adam Williamson 2010-06-15 18:48:09 EDT
see - could that be what we're experiencing? do newer f12 kernels also have issues for you?

Fedora Bugzappers volunteer triage team
Comment 9 Adam Williamson 2010-06-17 14:16:33 EDT
just to note, tried this on a second laptop and it also gets the URB resubmit failures and no response from the phone.

Fedora Bugzappers volunteer triage team
Comment 10 Dan Williams 2010-06-24 12:29:04 EDT
So note that you have to actually tell rfcomm the channel that you want to use.  To get that, use:

sdptool browse <device bt addr>

and look for the "Dial Up Networking" section.  Grab the channel from there, then:

rfcomm connect hci0 <device bt addr> <channel #>

and see what you get.  I found this out the hard way.
Comment 11 Adam Williamson 2010-06-24 13:57:45 EDT
Aha! Okay. There's also a new version of the ROM I run with this mysterious note in the changelog:

"Internet sharing issues should be gone"

Internet sharing is quite ambiguous and could refer to tethering via USB, BT or Wifi, it's hard to know. I'll probably try again with your updated instructions with both the current ROM and the new one. Thanks.

Fedora Bugzappers volunteer triage team
Comment 12 Adam Williamson 2010-06-24 14:11:44 EDT
Okay, that definitely behaves differently. With the ROM I've been using this whole time, doing it that way and then sending any of your listed commands just seems to result in it spewing:


over and over and over again (I'm not sending the command more than once). So clearly something is out of whack there =) Nothing major in /var/log/messages , so I'd guess it's the phone that's screwy.

I will try with the updated ROM.

Fedora Bugzappers volunteer triage team
Comment 13 Adam Williamson 2010-06-24 14:12:14 EDT
to be precise, it's ERROR and then three newlines and then ERROR again.

Fedora Bugzappers volunteer triage team
Comment 14 Dan Williams 2010-06-24 14:21:51 EDT
You're sure the channel is correct, right?

What commands are you sending?

When I didn't get the channel correct using my phone, anything I type would be responded to with ERROR even before I'd hit return.  When I used the right channel that magically started working.

The BT wizard shouldn't have this problem though since when connecting Bluez does an SDP lookup to find the right channel, but this procedure can at least verify that the BT stack is working as expected, isolating the issue to Bluez/kernel instead of throwing NM into the mix.
Comment 15 Akira TAGOH 2010-09-26 22:03:30 EDT
I have same problem with my HTC Touch Pro. either of commands in Comment #3 gives an ERROR. but once creating a rfcomm device, I can connect to the network after setting up a PDP context with AT+CGDCONT=, dialing a number to the access point.
Comment 16 Adam Williamson 2010-09-27 11:34:53 EDT
I'm still having this issue too, with the same phone with various later WinMo images.

Fedora Bugzappers volunteer triage team
Comment 17 Adam Williamson 2010-12-01 18:32:16 EST
I can't help with this one any more, I switched phones. Akira, want to keep it open or close it?

Bluetooth DUN with the N900 works great, BTW. :)
Comment 18 Akira TAGOH 2010-12-01 20:09:05 EST
I can. is there anything else I can do to get this solved?
Comment 19 Akira TAGOH 2011-02-03 03:24:15 EST
any chance to get an update in NM for this issue? then I can test with the latest. please let me know.
Comment 20 Bug Zapper 2011-06-02 09:31:03 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here:
Comment 21 Akira TAGOH 2011-06-12 23:21:26 EDT
Though I still keep the WinMo device here, I'm switching to the android device now. I could still help if there are anything I can do but I don't have too much interests anymore. so please let me know if you want anything for testing/investigation. otherwise I don't blame you if you don't want to fix it.
Comment 22 Bug Zapper 2011-06-27 12:39:07 EDT
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.