Bug 1234727
| Summary: | Modem Connection not established | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | UweR <richteruwe> |
| Component: | NetworkManager | Assignee: | Lubomir Rintel <lkundrak> |
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 22 | CC: | christian.groove, dcbw, gamberoni, lkundrak, psimerda, rkhan |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-07-19 19:12:58 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
UweR
2015-06-23 06:57:06 UTC
Jun 23 08:18:25 localhost ModemManager[1341]: <warn> couldn't load Supported IP families: 'SIM PIN required' Jun 23 08:18:25 localhost ModemManager[1341]: <info> Modem: state changed (unknown -> locked) The SIM is protected by a PIN. You should provide a PIN to unlock it. Did it worked before in F21? Can you try with nm-applet/nm-connection-editor instead of KDE programs? First, thx for your reply. - SIM/PIN: I unlocked the modem with the correct code. This works perfect. - F21: I upgraded using fedup from f20->f21 and immediately from f21->f22 without using f21. - nm-applet has the same behavior as KDE Now after some tries, I think the problem is a combination of the NetworkManager and the firewall. If I try to connect as described in the bug, the firewall shows no active zone (firewall-cmd --get-active-zones) But if I restart the NetworkManager before establishing the connection (service NetworkManager restart, and btw the NetworkManager has already been running since the boot time) everything works fine. A connection is established and an active zone is shown in the firewall. However, restarting the NetworkManager always couldn't be the solution? (In reply to UweR from comment #2) > - SIM/PIN: I unlocked the modem with the correct code. This works perfect. Oh, sorry about that. I haven't read the logs carefully to see that the modem was unlocked later. But what causes the connection to fail is this: Jun 23 08:18:46 localhost NetworkManager[1443]: <warn> (ttyUSB2): Failed to connect 'my Mobile Broadband 1': Connection requested both IPv4 and IPv6 but dual-stack addressing is unsupported by the modem. Jun 23 08:18:46 localhost NetworkManager[1443]: <info> (ttyUSB2): device state change: prepare -> failed (reason 'modem-init-failed') [40 120 28] The modem doesn't support dual-stack IPv4/IPv6. There was a change in handling that in NetworkManager, see upstream bug [1] and the commit [2]. It will fail when you have both IPv4 and IPv6 method as auto in the connection and ipv6.may-fail is no. So the fix is to set IPv6 method to ignore in the connection (or set ipv6.may-fail to yes, which should be dafault). Can you paste output of nmcli con show 'my Mobile Broadband 1' [1] https://bugzilla.gnome.org/show_bug.cgi?id=733696 [2] http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=85d9132464b76b75c0145376458c35f16472dc32 I configured the IPv6 issue using nm-connection-editor (btw there is no feature in KDE to ignore IPv6). But there were no result. Still the same behavior: Connect to the modem, resulting in an error. Connect again and this second connection is successful. Here is the output of nmcli con show 'my Mobile Broadband 1' [zzz@localhost ~]$ nmcli con show 'my Mobile Broadband 1' connection.id: my Mobile Broadband 1 connection.uuid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx connection.interface-name: -- connection.type: gsm connection.autoconnect: no connection.autoconnect-priority: 0 connection.timestamp: 1435354615 connection.read-only: no connection.permissions: connection.zone: FedoraWorkstation connection.master: -- connection.slave-type: -- connection.secondaries: connection.gateway-ping-timeout: 0 ipv4.method: auto ipv4.dns: ipv4.dns-search: ipv4.addresses: ipv4.gateway: -- ipv4.routes: ipv4.route-metric: -1 ipv4.ignore-auto-routes: no ipv4.ignore-auto-dns: no ipv4.dhcp-client-id: -- ipv4.dhcp-send-hostname: yes ipv4.dhcp-hostname: -- ipv4.never-default: no ipv4.may-fail: yes ipv6.method: ignore ipv6.dns: ipv6.dns-search: ipv6.addresses: ipv6.gateway: -- ipv6.routes: ipv6.route-metric: -1 ipv6.ignore-auto-routes: no ipv6.ignore-auto-dns: no ipv6.never-default: no ipv6.may-fail: yes ipv6.ip6-privacy: 0 (disabled) ipv6.dhcp-send-hostname: yes ipv6.dhcp-hostname: -- gsm.number: *99# gsm.username: -- gsm.password: <hidden> gsm.password-flags: 4 (not required) gsm.apn: web.vodafone.de gsm.network-id: -- gsm.pin: <hidden> gsm.pin-flags: 4 (not required) gsm.home-only: no This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. There is a similar issue in Fedora F23 bug 1297556: Modem Connection not established (GSM/Broadband) To me, not on Fedora but on Kubuntu 15.10, the same steps above give the same result: gen 16 18:38:47 p3 NetworkManager[653]: <warn> (ttyUSB2): Failed to connect '3 via E303': Connection requested IPv4 but IPv4 is unsuported by the modem. Searching for "Connection requested IPv4 but IPv4 is unsuported by the modem" I find three Redhat bugzilla bugs: this one and https://bugzilla.redhat.com/show_bug.cgi?id=1230681 https://bugzilla.redhat.com/show_bug.cgi?id=1297556 and not much else. My modem is an Huawei E303 and does not support the AT^SYSCFGEX command, only the AT^SYSCFG which gives this output: AT^SYSCFG=? ^SYSCFG: (2,13,14,16),(0-3),((2000000400380,"GSM900/GSM1800/WCDMA900WCDMA2100"),(280000,"GSM850/GSM1900"),(3fffffff,"All bands")),(0-2),(0-4) The downloadable "HUAWEI EM820W HSPA+ PC Embedded Module AT Command Interface Specification-(V100R001_02, English).pdf" specifies ^SYSCGF http://download-c.huawei.com/download/downloadCenter?downloadId=14254 Both the OP and me have the SIM PIN enabled, which is probably uncommon and relevant. Upon plugging in the USB dongle, ModemManager discovers the modem and puts it in locked state: gen 16 17:43:24 p3 ModemManager[3553]: Error while checking ^SYSCFGEX format: Unknown error gen 16 17:43:24 p3 ModemManager[3553]: <warn> couldn't load Supported IP families: 'SIM PIN required' gen 16 17:43:24 p3 NetworkManager[653]: <info> (ttyUSB2): modem state 'locked' because it doesn't know the pin, but NetworkManager registers the modem: gen 16 17:43:24 p3 NetworkManager[653]: <info> (ttyUSB2): device state change: unmanaged -> unavailable (reason 'none') [10 20 0] gen 16 17:43:24 p3 NetworkManager[653]: <info> (ttyUSB2): modem state 'locked' gen 16 17:43:24 p3 NetworkManager[653]: <info> (ttyUSB2): new Broadband device (carrier: UNKNOWN, driver: 'huawei_cdc_ncm, option1', ifindex: 0) I do not get any request for the pin, which is IMHO part of the bug, so I enter it via $ mmcli -i 2 --pin 1234 which succeeds $ mmcli -m 2 /org/freedesktop/ModemManager1/Modem/2 (device id 'dbba736909a9de18da3fca4e12a996067d17c47f') ------------------------- Hardware | manufacturer: 'huawei' | model: 'E303' | revision: '21.157.62.00.295' | supported: 'gsm-umts' | current: 'gsm-umts ... IP | supported: 'ipv4, ipv6, ipv4v6' and cause Network Manager to enable Mobile Broadband, but then fails to connect. If I restart NetworkManager, now that the modem is unlocked: $ systemctl restart network-manager.service whose log contains: gen 16 18:39:28 p3 systemd[1]: Started Network Manager Script Dispatcher Service. gen 16 18:39:28 p3 nm-dispatcher[7922]: Dispatching action 'down' for wlan0 gen 16 18:39:28 p3 NetworkManager[653]: (NetworkManager:653): GLib-GObject-CRITICAL **: g_type_instance_get_private: assertion 'instance != NULL && instance->g_class != gen 16 18:39:28 p3 kernel: show_signal_msg: 9 callbacks suppressed gen 16 18:39:28 p3 kernel: NetworkManager[653]: segfault at 168 ip 00000000004c39cd sp 00007fff94199850 error 4 in NetworkManager[400000+1bf000] gen 16 18:39:32 p3 systemd[1]: NetworkManager.service: Main process exited, code=dumped, status=11/SEGV gen 16 18:39:32 p3 systemd[1]: Stopped Network Manager. ... gen 16 18:39:33 p3 systemd[1]: Started Network Manager. ... gen 16 18:39:34 p3 NetworkManager[7948]: <info> (ttyUSB2): new Broadband device (carrier: UNKNOWN, driver: 'huawei_cdc_ncm, option1', ifindex: 0) gen 16 18:39:34 p3 NetworkManager[7948]: <info> (ttyUSB2): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2] gen 16 18:39:34 p3 NetworkManager[7948]: <info> (ttyUSB2): modem state 'registered' and now the connection succeeds: gen 16 18:39:43 p3 ModemManager[3553]: <info> Modem /org/freedesktop/ModemManager1/Modem/2: state changed (connecting -> connected) gen 16 18:39:43 p3 ModemManager[3553]: <info> Simple connect state (8/8): All done I guess Network Manager caches the information read at plug time, and does not notice the update that follows PIN input. Update.
Without me doing anything, now KDE Daemon ask for the PIN when plugging in the dongle.
Still getting Network Manager to establish a connection requires
systemctl restart network-manager.service
after PIN unlocking to work around this error:
gen 17 13:23:40 p3 NetworkManager[19545]: <warn> (ttyUSB2): Failed to connect '3 via modem USB': Connection requested both IPv4 and IPv6 but dual-stack addressing is unsupported by the modem.
Please notice that both the two Huawei devices 3131 and E303 referenced in this bug use the CDC NCM Huawei specific kernel module "huawei_cdc_ncm".
There is no pppd running when connected, these modems provide an ethernet over usb interface.
This also happened to my system, after i enabled the ModemManager via systemctl enable ModemManager systemctl start ModemManager 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. |