NM does not activate ofono Inet contexts w/Username but no Password ( eg. giffgaff )

Bug #1435776 reported by Andrea Bernabei
28
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Canonical System Image
Fix Released
High
Canonical Phone Foundations
network-manager (Ubuntu)
Fix Released
High
Tony Espy
network-manager (Ubuntu RTM)
Fix Released
High
Tony Espy

Bug Description

Device: Krillin
Software: Vivid r157

NM does not activate a valid ofono context which is present in the gprs file (context_1 in this case)

I was able to activate the context manually using ./activate-context /ril_0 1

You can find syslog, list-modems and list-contexts attached

Tags: connectivity

Related branches

Revision history for this message
Andrea Bernabei (faenil) wrote :
  • syslog Edit (247.0 KiB, application/octet-stream)
Revision history for this message
Andrea Bernabei (faenil) wrote :
Revision history for this message
Andrea Bernabei (faenil) wrote :
Tony Espy (awe)
tags: added: connectivity
Changed in network-manager (Ubuntu):
assignee: nobody → Tony Espy (awe)
Tony Espy (awe)
Changed in network-manager (Ubuntu):
assignee: Tony Espy (awe) → Alfonso Sanchez-Beato (alfonsosanchezbeato)
Revision history for this message
Jonathan Cave (jocave) wrote :

ubuntu-touch/devel-proposed/krillin.en r29 krillin

Also happening to me on the above with a giffgaff SIM

Revision history for this message
Jonathan Cave (jocave) wrote :
Revision history for this message
Alfonso Sanchez-Beato (alfonsosanchezbeato) wrote :

Maybe this trace is the key here:

Mar 24 10:27:01 ubuntu-phablet NetworkManager[1377]: <info> (ril_0): device state change: prepare -> failed (reason 'no-secrets') [40 120

I have seen this error in some cases where I was unable to start a cellular data connection. Rebooting solved the issue, and when the connection started you could not see that trace in syslog.

Tony Espy (awe)
Changed in network-manager (Ubuntu):
assignee: Alfonso Sanchez-Beato (alfonsosanchezbeato) → Tony Espy (awe)
Revision history for this message
Jonathan Cave (jocave) wrote :

Syslog using the same setup as per my previous comment

Revision history for this message
Tony Espy (awe) wrote :

OK, after a quick look... my gut tells me that this error is caused by the fact that the 'giffgaff' APNs define a 'Username' but not a 'Password'. Working on confirming this theory now.

Revision history for this message
Tony Espy (awe) wrote :

Just confirmed this theory on mako running vivid-devel image #155 by modifying my ATT Phone APN and adding a 'Username'. No more mobile data connection, and I get the same error pointed out by Alfosno in comment #6.

Changed in network-manager (Ubuntu):
importance: Undecided → High
status: New → Confirmed
Revision history for this message
Tony Espy (awe) wrote :

This is another 0.9.10 related regression. This works just fine on mako with RTM image #17.

Changed in canonical-devices-system-image:
assignee: nobody → Canonical Phone Foundations (canonical-phonedations-team)
Tony Espy (awe)
Changed in canonical-devices-system-image:
status: New → Confirmed
Revision history for this message
Andrea Bernabei (faenil) wrote :

I can confirm adding password=password fixed it for me, I now have mobile data connection with giffgaff apn

Tony Espy (awe)
summary: - NM does not activate a valid ofono context
+ NM does not activate ofono Inet contexts w/Username but no Password (
+ eg. giffgaff )
Revision history for this message
Dave Morley (davmor2) wrote :

I added a custom apn config
Internet APN: giffgaff.com
Username: giffgaff
Password: <empty>

I now get a tick on this network and a reliable 3g connection.

Revision history for this message
Dave Morley (davmor2) wrote :

Previously the giffgaff Internet refused to stay checked.

Revision history for this message
John McAleely (john.mcaleely) wrote :

@pmcgowan - for canonical-system-image, I think this needs triage, and probably should be 'critical'. There's a lot of use of giffgaff, and we partner with them in various ways.

Changed in canonical-devices-system-image:
importance: Undecided → High
milestone: none → ww21-2015
Revision history for this message
Tony Espy (awe) wrote :

@John

Critical should be reserved for crashes, and/or serious bugs that have no workaround.

That said, this is one of the last 0.9.10 regressions ( I hope ). We'll definitely fix for the next OTA, if not before. This may be related to bug #1450790 as well.

Tony Espy (awe)
Changed in network-manager (Ubuntu):
status: Confirmed → In Progress
Revision history for this message
Tony Espy (awe) wrote :

This bug is caused by the fact the NM's ofono plugin checks for the existence of Username and Password properties in the APN, and if found, adds them as settings to the NM_SETTING_GSM instance ( which is added to the associated NM_CONNECTION instance ).

For some reason, the fact that only 'Username' is set doesn't seem to effect the first connection attempt, but them for some reason, the NM settings code resets its secrets logic and thinks that a 'Password' is required the next time a connection attempt occurs.

Rather than debug the settings secrets logic, I opted to remove the code in the ofono plugin which adds these settings, as in reality, NM does nothing with them, they're actually used by ofono directly.

Likewise the same code ( in src/settings/plugins/ofono/parser.c ) adds an APN setting to the NM_SETTING_GSM instance, however it searches for the APN in the context using the key "Apn", when the key is actually named "AccessPointName". So, the code was always adding an NM_SETTING_GSM_APN with value of "".

I will add a branch to the bug later this afternoon.

In the meanwhile, anyone who'd like to test can use the version ( 0.9.10.0-4ubuntu15.1~awe4 ) in the phablet-team's telephony PPA:

https://launchpad.net/~phablet-team/+archive/ubuntu/telephony

Revision history for this message
Tony Espy (awe) wrote :

Note, as I've been using the phablet-team telephony PPA for other testing, so although the version in the PPA has the fix, it has some other experimental changes, so it might cause other problems when testing. Use at your own risk...

If all goes well, we should have this in a silo in the next day or so.

Changed in canonical-devices-system-image:
milestone: ww21-2015 → ww22-2015
Tony Espy (awe)
Changed in network-manager (Ubuntu RTM):
status: New → Fix Committed
Changed in network-manager (Ubuntu):
status: In Progress → Fix Committed
Changed in network-manager (Ubuntu RTM):
importance: Undecided → High
assignee: nobody → Tony Espy (awe)
Tony Espy (awe)
Changed in canonical-devices-system-image:
status: Confirmed → Fix Committed
Changed in canonical-devices-system-image:
status: Fix Committed → Fix Released
Revision history for this message
Tony Espy (awe) wrote :

Changed the status of the Ubuntu task as the fix has not yet been merged for wily.

Changed in network-manager (Ubuntu):
status: Fix Committed → In Progress
Tony Espy (awe)
Changed in network-manager (Ubuntu RTM):
status: Fix Committed → Fix Released
Revision history for this message
Tony Espy (awe) wrote :

Changing the Status to FixReleased for Ubuntu ( ie. Wily ) task as this wasn't recorded properly in the changelog. This was fixed in version: 0.9.10.0-4ubuntu19.

Changed in network-manager (Ubuntu):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.