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 - http://forum.xda-developers.com/showthread.php?t=562773 . 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...
Created attachment 416564 [details] debug messages from modem-manager debug messages.
attached the same output, as BZ mangled it as usual.
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? AT+CPAS? AT+CGDCONT? AT+CSCS? We could add those to the detection list for GSM devices since CDMA devices will most likely not support these.
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 output...am I missing something? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
'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?
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 https://fedoraproject.org/wiki/BugZappers
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 https://fedoraproject.org/wiki/BugZappers
see https://bugzilla.redhat.com/show_bug.cgi?id=562502 - could that be what we're experiencing? do newer f12 kernels also have issues for you? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
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 https://fedoraproject.org/wiki/BugZappers
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.
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 https://fedoraproject.org/wiki/BugZappers
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: ERROR 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 https://fedoraproject.org/wiki/BugZappers
to be precise, it's ERROR and then three newlines and then ERROR again. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
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.
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.
I'm still having this issue too, with the same phone with various later WinMo images. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
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. :)
I can. is there anything else I can do to get this solved?
any chance to get an update in NM for this issue? then I can test with the latest. please let me know.
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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.
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.