After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 741813 - Cannot connect to network via bluetooth dun with Nokia N9
Cannot connect to network via bluetooth dun with Nokia N9
Status: RESOLVED OBSOLETE
Product: NetworkManager
Classification: Platform
Component: Documentation
1.0.x
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2014-12-20 18:53 UTC by Weng Xuetian
Modified: 2020-11-12 14:27 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
nm debug log (147.86 KB, text/x-log)
2014-12-21 21:49 UTC, Weng Xuetian
Details
nm debug log (844.84 KB, text/plain)
2014-12-21 21:54 UTC, Weng Xuetian
Details
mm debug log (88.50 KB, text/plain)
2014-12-21 21:55 UTC, Weng Xuetian
Details
new mm log after 3 -> 20 change (69.10 KB, text/plain)
2014-12-22 20:51 UTC, Weng Xuetian
Details

Description Weng Xuetian 2014-12-20 18:53:37 UTC
I'm trying to use bluez 5.24 and nm 1.0.0 to connect to bluetooth via dun.

When I using usb based modem mode for Nokia N9, I can use following configuration to connect:

[connection]
id=H2OWireless
uuid=aa21bf39-de63-48b2-bc6d-a8a22b62351f
type=gsm
autoconnect=false

[ipv6]
method=auto

[ipv4]
method=auto

[gsm]
number=*99#
password-flags=1
apn=att.mvno
pin-flags=1

And here's my bluetooth configuration for it:
[gsm]
number=*99#
apn=att.mvno

[bluetooth]
bdaddr=[**mac address**]
type=dun

[ipv6]
method=auto
dns-search=

[ipv4]
method=auto
dns-search=

[connection]
id=Nokia N9
uuid=9cc45579-e7f9-49b3-be1d-f07bd3473aa2
type=bluetooth
permissions=
secondaries=

Here's the log from journcalctl

<info>  Auto-activating connection 'Nokia N9'.
<info>  (40:98:4E:BF:B3:54): Activation: starting connection 'Nokia N9'
<info>  (40:98:4E:BF:B3:54): Activation: Stage 1 of 5 (Device Prepare) scheduled...
<info>  (40:98:4E:BF:B3:54): Activation: Stage 1 of 5 (Device Prepare) started...
<info>  (40:98:4E:BF:B3:54): device state change: disconnected -> prepare (reason 'none') [30 40 0]
<info>  (40:98:4E:BF:B3:54): Activation: Stage 2 of 5 (Device Configure) scheduled...
<info>  (40:98:4E:BF:B3:54): Activation: Stage 1 of 5 (Device Prepare) complete.
<info>  (40:98:4E:BF:B3:54): Activation: Stage 2 of 5 (Device Configure) starting...
<info>  (40:98:4E:BF:B3:54): device state change: prepare -> config (reason 'none') [40 50 0]
<info>  (40:98:4E:BF:B3:54): Activation: Stage 2 of 5 (Device Configure) complete.
<info>  (40:98:4E:BF:B3:54): Activation: (bluetooth) Stage 2 of 5 (Device Configure) modem found.
<info>  (rfcomm7): modem state changed, 'disabled' --> 'enabling' (reason: user-requested)
<info>  (40:98:4E:BF:B3:54): Activation: (bluetooth) Stage 2 of 5 (Device Configure) modem found.
(NetworkManager:18382): NetworkManager-bluetooth-WARNING **: (nm-device-bt.c:650):component_added: code should not be reached
<info>  (rfcomm7): modem state changed, 'disabled' --> 'enabling' (reason: user-requested)
<info>  (rfcomm7): modem state changed, 'enabling' --> 'enabled' (reason: user-requested)
<info>  (rfcomm7): modem state changed, 'enabled' --> 'connecting' (reason: user-requested)
<info>  (rfcomm7): modem state changed, 'connecting' --> 'connected' (reason: user-requested)
<info>  (40:98:4E:BF:B3:54): device state change: config -> deactivating (reason 'user-requested') [50 110 39]
<info>  (40:98:4E:BF:B3:54): device state change: deactivating -> disconnected (reason 'user-requested') [110 30 39]
<info>  (40:98:4E:BF:B3:54): deactivating device (reason 'user-requested') [39]
Comment 1 Aleksander Morgado 2014-12-21 17:48:44 UTC
Could you gather debug logs for both NetworkManager and ModemManager while trying to connect via Bluetooth DUN? See:
http://www.freedesktop.org/wiki/Software/ModemManager/Debugging/

The "code should not be reached" warning is already a very good indication of the issue, but I wonder if MM debug logs will tell us more stuff.
Comment 2 Weng Xuetian 2014-12-21 21:49:20 UTC
Created attachment 293158 [details]
nm debug log
Comment 3 Weng Xuetian 2014-12-21 21:54:38 UTC
Created attachment 293159 [details]
nm debug log
Comment 4 Weng Xuetian 2014-12-21 21:55:01 UTC
Created attachment 293160 [details]
mm debug log
Comment 5 Aleksander Morgado 2014-12-22 08:56:56 UTC
Hum... a couple of different issues here. The worst one I think is in ModemManager, as the modem ends up timing out for the "AT+CSCS=?" command (response comes after 16s!), and therefore all the next commands end up failing badly. The default command timeout is 3s for AT+CSCS=?.

Also, 3GPP registration checks seem to be left around once the ports are gone (the log shows issues with rfcomm1 and rfcomm0, while it is rfcomm2 the one being used, so I suspect the other ports were from previous tries).

Weng, do you think you could build your own ModemManager from git and change the +CSCS=? command timeout to something bigger, like 20s? That would be in the modem_load_supported_charsets() method in mm-broadband-modem.c (replacing the "3" with a "20"). it's not the final fix, but it could help us try to see if we can go on after that change.
Comment 6 Weng Xuetian 2014-12-22 20:51:04 UTC
Thank you very much, after I change from 3 -> 20

 I can now connect to network via bluetooth dun.
Comment 7 Weng Xuetian 2014-12-22 20:51:41 UTC
Created attachment 293200 [details]
new mm log after 3 -> 20 change
Comment 8 Aleksander Morgado 2014-12-23 11:19:47 UTC
(In reply to comment #6)
> Thank you very much, after I change from 3 -> 20
> 
>  I can now connect to network via bluetooth dun.

Nice!

Do you still see the "code should not be reached" warning in the NetworkManager log, though?
Comment 9 Aleksander Morgado 2014-12-23 11:22:49 UTC
Bug for ModemManager being tracked here:
https://bugs.freedesktop.org/show_bug.cgi?id=87635

I'd leave this bug open if the NetworkManager logs still show the "code should not be reached" warning.
Comment 10 Weng Xuetian 2014-12-24 22:57:03 UTC
The warning doesn't show up in nm log again.
Comment 11 Aleksander Morgado 2014-12-25 11:41:34 UTC
(In reply to comment #10)
> The warning doesn't show up in nm log again.

Ok good, anyway a quick check on the source code wouldn't hurt to see why the warning appeared.
Comment 12 André Klapper 2020-11-12 14:27:42 UTC
bugzilla.gnome.org is being shut down in favor of a GitLab instance. 
We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time.

If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/

Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).