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 733394 - Nokia/Icera plugin fails with ip-type ipv4v6 if network doesn't support IPv6
Nokia/Icera plugin fails with ip-type ipv4v6 if network doesn't support IPv6
Status: RESOLVED NOTGNOME
Product: NetworkManager
Classification: Platform
Component: ModemManager
git master
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2014-07-19 11:59 UTC by Tore Anderson
Modified: 2014-10-14 16:55 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
full debug journal showing problem being reproduced (31.42 KB, text/plain)
2014-07-19 11:59 UTC, Tore Anderson
Details

Description Tore Anderson 2014-07-19 11:59:10 UTC
Created attachment 281174 [details]
full debug journal showing problem being reproduced

This is what happens:

$ mmcli -m 18 --simple-connect=apn=telenor,ip-type=ipv4v6
error: couldn't connect the modem: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Failed: Couldn't parse IPv6 address '::''

Note that the modem in question, a Nokia 21M-02, will detect that the network doesn't support the dual-stack ipv4v6 PDP context type, and automatically attempt setting up two single-stack PDP contexts itself (one ipv4, one ipv6). This happens transparently and will appear as a single ipv4v6 bearer from MM's point of view.

However, in this case, I am attempting to connect to an APN that does not support the IPv6 PDP context type (a network provider limitation). So only the IPv4 single-stack bearer actually succeeds, which means that the IP information the modem can pass to MM contains no IPv6 information, but those fields are replaced with empty placeholders ('::)'. MM should handle this.

Note that in the inverse situation, where I connect using ip-type=ipv4v6 to an APN that only support ipv6 but not ipv4, and the modem returns IPv4 information as empty '0.0.0.0' placeholders, MM handles it just fine and ends up successfully connecting:

juli 19 13:55:10 envy.fud.no ModemManager[9550]: <debug> (ttyACM14): --> 'AT%IPDPADDR=1<CR>'
juli 19 13:55:10 envy.fud.no ModemManager[9550]: <debug> (ttyACM14): <-- '<CR><LF>%IPDPADDR: 1, 0.0.0.0, 0.0.0.0, 0.0.0.0, 0.0.0.0, 0.0.0.0, 0.0.0.0, 0.0.0.0, 0.0.0.0, fe80::1f:fad1:4c01, ::, 2001:4600:4:fff::54, 2001:4600:4:1fff::54, ::, ::, ::, ::<CR><LF>OK<CR><LF>'
juli 19 13:55:10 envy.fud.no ModemManager[9550]: <debug> (ttyACM14) device open count is 1 (close)
juli 19 13:55:10 envy.fud.no ModemManager[9550]: <debug> (enp0s20u2i7): port now connected
juli 19 13:55:10 envy.fud.no ModemManager[9550]: <debug> Connected bearer '/org/freedesktop/ModemManager1/Bearer/0'
juli 19 13:55:10 envy.fud.no ModemManager[9550]: <info>  Modem /org/freedesktop/ModemManager1/Modem/1: state changed (connecting -> connected)
juli 19 13:55:10 envy.fud.no ModemManager[9550]: <info>  Simple connect state (8/8): All done
Comment 1 Aleksander Morgado 2014-10-14 16:55:55 UTC
Moving bugreport to the new ModemManager bugzilla in fd.o; summarized the issue
there as well. Please subscribe to the new bugreport to get new updates.

https://bugs.freedesktop.org/show_bug.cgi?id=85012

Closing this report as NOTGNOME.

BTW; should be trivial to fix, will try to do it this week.