Bug 1230681

Summary: Huawei E173: IPv4 unsupported by modem
Product: [Fedora] Fedora Reporter: Filip Bartmann <filbar>
Component: ModemManagerAssignee: Lubomir Rintel <lkundrak>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 22CC: anthony.hartin, dcbw, fedora, redhat-bugzilla
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-07-19 19:11:29 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Filip Bartmann 2015-06-11 10:52:36 UTC
Description of problem:

When I try co connect to mobile broadband with Fedora 22, then modem don't connect and in /var/log/messages I have:
--------------------------------------------------------
Jun 11 09:12:25 ntb NetworkManager[834]: <info>  (ttyUSB1): Activation: starting connection 'T-Mobile Výchozí'
Jun 11 09:12:25 ntb NetworkManager[834]: <info>  (ttyUSB1): Activation: Stage 1 of 5 (Device Prepare) scheduled...
Jun 11 09:12:25 ntb NetworkManager[834]: <info>  (ttyUSB1): Activation: Stage 1 of 5 (Device Prepare) started...
Jun 11 09:12:25 ntb NetworkManager[834]: <info>  (ttyUSB1): device state change: disconnected -> prepare (reason 'none') [30 40 0]
Jun 11 09:12:25 ntb NetworkManager[834]: <warn>  (ttyUSB1): Failed to connect 'T-Mobile Výchozí': Connection requested IPv4 but IPv4 is unsuported by the modem.
Jun 11 09:12:25 ntb NetworkManager[834]: <info>  (ttyUSB1): device state change: prepare -> failed (reason 'modem-init-failed') [40 120 28]
Jun 11 09:12:25 ntb NetworkManager[834]: <warn>  (ttyUSB1): Activation: failed for connection 'T-Mobile Výchozí'
Jun 11 09:12:25 ntb NetworkManager[834]: <info>  (ttyUSB1): Activation: Stage 1 of 5 (Device Prepare) complete.
Jun 11 09:12:25 ntb NetworkManager[834]: <info>  (ttyUSB1): device state change: failed -> disconnected (reason 'none') [120 30 0]
--------------------------------------------------------


Version-Release number of selected component (if applicable):
Before upgrade to Fedora 22 on Fedora 21 this work's good.


How reproducible:
Connect USB HUAWEI Mobile Broadband E173 and try to connect to broadband via NetworkManager.

Comment 1 Tony 2015-06-12 14:38:14 UTC
I have the same problem. Found a work around. NetworkManager allows you to enter pin and the connection gets registered. Then find the modem device using

mmcli -m <n>  where n is 0,1,2..

Then you can connect with

mmcli -m <n> --simple-connect pin="xxxx",apn="xxxx" 

but NetworkManager still wont assign an ip. If you keep the USB modem in and reboot, NetworkManager will then let you connect. This doesnt persist, you have to keep doing the same procedure each time.

The other problem that appeared with the FC22 upgrade for my HUAWEI USB is that it can no longer create a new ad-hoc wireless network to share the modem

Comment 2 Tony 2015-06-15 11:06:50 UTC
Its rather drastic I know, but until multiple problems are fixed in fc22 you can downgrade wpa_supplicant, ModemManager and NetworkManager to their fc21 versions and everything once again works:

sudo dnf downgrade NetworkManager wpa_supplicant ModemManager --allowerasing  --releasever 21

Comment 3 Thomas Sailer 2015-06-17 16:27:39 UTC
I had that too (with another phone), it turned out that the response of the phone to the AT+CGDCONT=? was in a form that ModemManager couldn't parse.

It might help if you posted the response of your modem to AT+CGDCONT=? to the NetworkManager mailing list... (run ModemManager --debug as root)

Comment 4 Fedora Admin XMLRPC Client 2015-08-18 14:54:18 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 5 Ralf Ertzinger 2015-08-21 21:50:58 UTC
I can manually create a connection on my modem using mmcli and pppd, so the device itself works fine.

The last AT+CGDCONT exchange before NM failed to create the connection was:

Aug 21 23:17:31 faith.camperquake.de ModemManager[677]: <debug> (ttyUSB2): --> 'AT+CGDCONT=?<CR>'
Aug 21 23:17:31 faith.camperquake.de ModemManager[677]: <debug> (ttyUSB2): <-- '<CR><LF>+CGDCONT: (1-16),"IP",,,(0-2),(0-3)<CR><LF>+CGDCONT: (1-16),"PPP",,,(0-2),(0-3)<CR><LF>+CGDCONT: (1-16),"IPV6",,,(0-2),(0-3)<CR><LF><CR><LF>OK<CR><LF>'
Aug 21 23:17:31 faith.camperquake.de ModemManager[677]: <debug> Unhandled PDP type in CGDCONT=? reply: 'PPP'


I do notice that I have to run PPP on this modem, the bearer specifies it:

Bearer '/org/freedesktop/ModemManager1/Bearer/2'
  -------------------------
  Status             |   connected: 'yes'
                     |   suspended: 'no'
                     |   interface: 'ttyUSB0'
                     |  IP timeout: '20'
  -------------------------
  Properties         |         apn: 'pinternet.interkom.de'
                     |     roaming: 'allowed'
                     |     IP type: 'none'
                     |        user: 'none'
                     |    password: 'none'
                     |      number: 'none'
                     | Rm protocol: 'unknown'
  -------------------------
  IPv4 configuration |   method: 'ppp'
                     |  address: 'unknown'
                     |   prefix: '0'
                     |  gateway: 'unknown'
                     |      DNS: none
  -------------------------
  IPv6 configuration |   method: 'unknown'

(but from the ModemManager log the connection never gets this far as NM never sends the connect command)

Comment 6 Lubomir Rintel 2016-03-31 12:57:50 UTC
I'm wondering if you could re-check with this build?

f22: http://koji.fedoraproject.org/koji/taskinfo?taskID=13516588
f23: http://koji.fedoraproject.org/koji/taskinfo?taskID=13516583

Comment 7 Fedora End Of Life 2016-07-19 19:11:29 UTC
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

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