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 701507 - DUN via bluetooth fails
DUN via bluetooth fails
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2013-06-03 11:17 UTC by Ritesh Khadgaray ( irc:ritz)
Modified: 2013-09-02 07:16 UTC
See Also:
GNOME target: ---
GNOME version: 3.7/3.8


Attachments
[PATCH] ppp: fix getting username/password for Bluetooth connections (5.28 KB, patch)
2013-08-29 08:45 UTC, Jiri Klimes
none Details | Review

Description Ritesh Khadgaray ( irc:ritz) 2013-06-03 11:17:40 UTC
from

$ cat /etc/NetworkManager/system-connection/example
[connection]
id=Mobil-BT connection
uuid=c57749ea-92fb-4297-8db4-875b66b3319a
type=bluetooth
autoconnect=false

[bluetooth]
bdaddr=00:16:4E:24:EA:2F
type=dun

[gsm]
number=*99#
apn=apn.example.com
username=userexample
password=secret
pin=1234

[serial]
baud=115200

--------------------------------

 351
 352 static gboolean
 353 extract_details_from_connection (NMConnection *connection,
 354 const char **username,
 355 const char **password,
 356 GError **error)
 357 {

...
 372 setting = nm_connection_get_setting_by_name (connection, connection_type);
 373
// We need to add this section as we do not check for bluetooth ( which can hold either gsm or cdma settings

 374 if (NM_IS_SETTING_BLUETOOTH(setting)) {
 375 /* wrong connection type, try to get gsm connection settings */
 376 setting = nm_connection_get_setting_by_name(connection, NM_SETTING_GSM_SETTING_NAME);
 377 if (!setting) {
 378 setting = nm_connection_get_setting_by_name(connection, NM_SETTING_CDMA_SETTING_NAME);
 379 }
 380 }
 381
 382 if (!setting) {
 383 g_set_error_literal (error, NM_PPP_MANAGER_ERROR, NM_PPP_MANAGER_ERROR_UNKOWN,
 384 "Missing type-specific setting; no secrets could be found.");
 385 return FALSE;
 386 }
 387

// regular code
...
 395 } else if (NM_IS_SETTING_GSM (setting)) {
 396 *username = nm_setting_gsm_get_username (NM_SETTING_GSM (setting));
 397 *password = nm_setting_gsm_get_password (NM_SETTING_GSM (setting));
 398 } else if (NM_IS_SETTING_CDMA (setting)) {
 399 *username = nm_setting_cdma_get_username (NM_SETTING_CDMA (setting));
 400 *password = nm_setting_cdma_get_password (NM_SETTING_CDMA (setting));



reference - https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1186273
Comment 1 Jiri Klimes 2013-06-03 14:40:52 UTC
A fix is available in jklimes/ppp-user-pass.

It handles the bluetooth type. In addition the code is restructured - moving
username and password getting code to libnm-util.
Comment 2 Dan Winship 2013-06-03 16:19:03 UTC
looks good to me
Comment 3 Ritesh Khadgaray ( irc:ritz) 2013-06-03 16:50:34 UTC
@Jiri  sweet, thanks. This works beautifully.
Comment 4 Dan Williams 2013-06-03 21:55:16 UTC
Hmm, not sure I'm comfortable adding generic connection accessors for user/password to the connection, for a few reasons:

1) the GSM/CDMA passwords aren't always used with PPP; they're also get sent whenever ModemManager (or pppd) needs authentication info, including when connecting a WWAN connection that doesn't use PPP.  So the name isn't quite correct since it shouldn't always be used for PPP only.  (see create_gsm_connect_properties() in src/modem-manager/nm-modem-broadband.c)

2) also, since the patch adds new items to the NMSetting class, we're technically breaking ABI compat if the new MM gets used with older clients and those clients haven't been recompiled.  Clients not rebuilt for the new NM would get glib warnings about class size mismatches an fail pretty hard.

3) I'd like to keep the logic about what setting gets asked for passwords in NM, since it's somewhat convoluted.  The connection stuff should be kept a fairly simple data store without a ton of logic.

Instead would it work to cache the setting name we got back from nm_connection_need_secrets() and then use that to extract the username/password from the connection in impl_ppp_manager_need_secrets() and ppp_secrets_cb()?  That way a bluetooth connection would ask for secrets from cdma/gsm instead of ppp, and we'd actually be using the right setting that we're asking for secrets from.  Right now that's not the case, because we're throwing away the setting name and then redoing all that work again to get the user/pass.
Comment 5 Pavel Simerda 2013-07-11 11:18:53 UTC
I pretty much agree with the comments by Dan regarding the reorganization. But I believe the original bug report can be fixed without reorganization and that it's exactly what we should do. After that we should close this bug report as FIXED and open a new bug report for the reorg.

Note that I don't have deep insight into this particular issue and might be utterly wrong.
Comment 6 Jiri Klimes 2013-08-29 08:45:43 UTC
Created attachment 253475 [details] [review]
[PATCH] ppp: fix getting username/password for Bluetooth connections

Reworked the code according to comment #4. It is also published in jklimes/ppp-user-pass branch.
Comment 7 Dan Williams 2013-08-31 01:04:38 UTC
Patch looks good and passes my tests on both CDMA and GSM.  Please  merge and close, thanks!
Comment 8 Jiri Klimes 2013-09-02 07:16:53 UTC
5ce25c5eb41953b9179313daf3eeab3807d14597 (master)