Re: Regression regarding ip_type when updating from 1.10.4 to 1.12.0

[Nick B]

Ah right, I see the problem now.  I think Dan’s suggestions would help 
tremendously.

Nevertheless, I tried ipv4v6 on Optus and Telstra in Australia.  On Telstra I 
get both, on Optus I’ll only get IPv4.  Specifying IPv6 on Optus yields no 
connection.  So maybe it’s working?

Best,
Nick
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

RE: Regression regarding ip_type when updating from 1.10.4 to 1.12.0

[Amol Lad]

Thanks Nick,

Leaving blank will not help:

modemmanager.proto
# ip type IPv4 is assumed if none explicitly given
[ -z "${iptype}" ] && iptype="ipv4"

Setting it to "ipv4v6" will configure it for dual stack? So how to set " 
MM_BEARER_IP_FAMILY_ANY "

include/ModemManager-enums.h:
/**
 * MMBearerIpFamily:
 * @MM_BEARER_IP_FAMILY_NONE: None or unknown.
 * @MM_BEARER_IP_FAMILY_IPV4: IPv4.
 * @MM_BEARER_IP_FAMILY_IPV6: IPv6.
 * @MM_BEARER_IP_FAMILY_IPV4V6: IPv4 and IPv6.
 * @MM_BEARER_IP_FAMILY_ANY: Mask specifying all IP families.
 *
 * Type of IP family to be used in a given Bearer.
 */
typedef enum { /*< underscore_name=mm_bearer_ip_family >*/
MM_BEARER_IP_FAMILY_NONE= 0,
MM_BEARER_IP_FAMILY_IPV4= 1 << 0,
MM_BEARER_IP_FAMILY_IPV6= 1 << 1,
MM_BEARER_IP_FAMILY_IPV4V6  = 1 << 2,
MM_BEARER_IP_FAMILY_ANY = 0x
} MMBearerIpFamily;



The information in this email communication (inclusive of attachments) is 
confidential to 4RF Limited and the intended recipient(s). If you are not the 
intended recipient(s), please note that any use, disclosure, distribution or 
copying of this information or any part thereof is strictly prohibited and that 
the author accepts no liability for the consequences of any action taken on the 
basis of the information provided. If you have received this email in error, 
please notify the sender immediately by return email and then delete all 
instances of this email from your system. 4RF Limited will not accept 
responsibility for any consequences associated with the use of this email 
(including, but not limited to, damages sustained as a result of any viruses 
and/or any action or lack of action taken in reliance on it).-Original 
Message-
From: Nick B 
Sent: Friday, 15 November 2019 9:19 AM
To: Amol Lad 
Cc: Andreas Fett ; modemmanager-devel@lists.freedesktop.org
Subject: Re: Regression regarding ip_type when updating from 1.10.4 to 1.12.0

I think you can just leave it blank, or you can try ipv4v6 with the latest 
master

Best,
Nick
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Regression regarding ip_type when updating from 1.10.4 to 1.12.0

[Nick B]

I think you can just leave it blank, or you can try ipv4v6 with the latest 
master

Best,
Nick
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

RE: Regression regarding ip_type when updating from 1.10.4 to 1.12.0

[Amol Lad]

Sorry for basic question. How to you set ip_type to ANY in OpenWrt conf 
(below). I tried : option iptype 'any' but it did not work

config interface 'wwan'
option device 
'/sys/devices/platform/soc/soc:internal-regs/f10f8000.usb3/usb5/5-1'
option proto 'modemmanager'
option apn 'internet'
option roaming '1'
option iptype 'ipv4'


The information in this email communication (inclusive of attachments) is 
confidential to 4RF Limited and the intended recipient(s). If you are not the 
intended recipient(s), please note that any use, disclosure, distribution or 
copying of this information or any part thereof is strictly prohibited and that 
the author accepts no liability for the consequences of any action taken on the 
basis of the information provided. If you have received this email in error, 
please notify the sender immediately by return email and then delete all 
instances of this email from your system. 4RF Limited will not accept 
responsibility for any consequences associated with the use of this email 
(including, but not limited to, damages sustained as a result of any viruses 
and/or any action or lack of action taken in reliance on it).-Original 
Message-
From: ModemManager-devel  On 
Behalf Of Andreas Fett
Sent: Friday, 15 November 2019 3:58 AM
To: modemmanager-devel@lists.freedesktop.org
Subject: Re: Regression regarding ip_type when updating from 1.10.4 to 1.12.0

Hi Dan,

thank you for your feedback.

On Thu, Nov 14, 2019 at 03:24:35PM -0600, Dan Williams wrote:
> Aleksander: we should probably fine-tune the logic something like this:
>
> 1) bearer default_ip_family follows what the modem is capable of via
> AT+CGDCONT=? or the equivalent; eg if the modem has V4V6 contexts then
> we default to IPV4V6.
> 2) If the user passes a specific IP family for the bearer, fail if
> that family is not successfully connected (as we do now?)
> 3) If the user passes ANY:
>   3a) use the default_ip_family (no change)
>   3b) the modem accepts whatever connect result happens, eg if v4 or
> v6-only that's fine, don't fail.
>   3c) if the connection result failed because the network rejected a
> V4V6 request for example, or the default_ip_family is V4 but the APN
> only accepts V6, then should we retry with V4?
>

My concern is to get Dualstack if available and any kind of Connectivity if 
it's not.

So I like your outline above very much and if ModemManager could guarantee that 
behaviour independetly of the actual modem driver I'd happily switch to pass 
ANY in the bearer an be done with it.

Andreas

--
The three chief virtues of a programmer are:
Laziness, Impatience and Hubris. -- Larry Wall
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

RE: OpenWrt package and udev rules

[Amol Lad]

This rule is already in MM 1.12.0. You had to apply it separately?

root@OpenWrt:/lib/udev/rules.d# cat 77-mm-sierra.rules

# do not edit this file, it will be overwritten on update
ACTION!="add|change|move|bind", GOTO="mm_sierra_end"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1199", GOTO="mm_sierra"
GOTO="mm_sierra_end"

LABEL="mm_sierra"
SUBSYSTEMS=="usb", ATTRS{bInterfaceNumber}=="?*", 
ENV{.MM_USBIFNUM}="$attr{bInterfaceNumber}"

# Netgear AC341U: enable connection status polling explicitly
ATTRS{idVendor}=="1199", ATTRS{idProduct}=="9057", 
ENV{ID_MM_QMI_CONNECTION_STATUS_POLLING_ENABLE}="1"

# MC74XX: Add port hints
#  if 03: primary port
#  if 02: raw NMEA port
#  if 00: diag/qcdm port
ATTRS{idVendor}=="1199", ATTRS{idProduct}=="9071", ENV{.MM_USBIFNUM}=="03", 
ENV{ID_MM_PORT_TYPE_AT_PRIMARY}="1"
ATTRS{idVendor}=="1199", ATTRS{idProduct}=="9071", ENV{.MM_USBIFNUM}=="02", 
ENV{ID_MM_PORT_TYPE_GPS}="1"
ATTRS{idVendor}=="1199", ATTRS{idProduct}=="9071", ENV{.MM_USBIFNUM}=="00", 
ENV{ID_MM_PORT_TYPE_QCDM}="1"

LABEL="mm_sierra_end"

From: ModemManager-devel  On 
Behalf Of Nick B
Sent: Friday, 15 November 2019 5:14 AM
To: Bjørn Mork 
Cc: ModemManager (development) ; 
Aleksander Morgado 
Subject: Re: OpenWrt package and udev rules

Hey,

FWIW, updating these rules definitely sped up the configuration of my MC7430 on 
OpenWrt by about 20 to 30 seconds. See:

https://www.mail-archive.com/modemmanager-devel@lists.freedesktop.org/msg05430.html


Best,
Nick

The information in this email communication (inclusive of attachments) is 
confidential to 4RF Limited and the intended recipient(s). If you are not the 
intended recipient(s), please note that any use, disclosure, distribution or 
copying of this information or any part thereof is strictly prohibited and that 
the author accepts no liability for the consequences of any action taken on the 
basis of the information provided. If you have received this email in error, 
please notify the sender immediately by return email and then delete all 
instances of this email from your system. 4RF Limited will not accept 
responsibility for any consequences associated with the use of this email 
(including, but not limited to, damages sustained as a result of any viruses 
and/or any action or lack of action taken in reliance on it).
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: OpenWrt package and udev rules

[Nick B]

Hey,

FWIW, updating these rules definitely sped up the configuration of my MC7430 on 
OpenWrt by about 20 to 30 seconds. See:

https://www.mail-archive.com/modemmanager-devel@lists.freedesktop.org/msg05430.html
 



Best,
Nick___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Regression regarding ip_type when updating from 1.10.4 to 1.12.0

[Dan Williams]

On Thu, 2019-11-14 at 21:59 +0100, Andreas Fett wrote:
> Hi Aleksander,
> 
> On Thu, Nov 14, 2019 at 06:57:54PM +0100, Aleksander Morgado wrote:
> > > Has the interpretation of the ip_type MM_BEARER_IP_FAMILY_IPV4V6
> > > changed when performing the connect?
> > > 
> > 
> > No it hasn't really. I really think you need to know whether the
> > network supports ipv4v6 for a given APN before attempting to use
> > it.
> 
> For writing end user oriented software where the networks and
> operators
> that will be used are unknown when implementing it this becomes a big
> problem.

I'm not sure I see how. If you pass MM_BEARER_IP_FAMILY_ANY then you
will get some kind of connectivity, most often V4 because that's what
most networks provide.

If you pass V4, V6, or V4V6 then MM will fail if the network cannot
provide that connectivity. Presumably you are passing these options
because you require the connectivity each one provides, otherwise if
all you care about is "can I get to the Internet" you could pass ANY.

> Wouldn't that mean one has to try a connect with all bearer types in
> whatever the preferred order is?

Or pass ANY and you'll get some kind of connection to the internet at
least?

Aleksander: we should probably fine-tune the logic something like this:

1) bearer default_ip_family follows what the modem is capable of via
AT+CGDCONT=? or the equivalent; eg if the modem has V4V6 contexts then
we default to IPV4V6.
2) If the user passes a specific IP family for the bearer, fail if that
family is not successfully connected (as we do now?)
3) If the user passes ANY:
  3a) use the default_ip_family (no change)
  3b) the modem accepts whatever connect result happens, eg if v4 or
v6-only that's fine, don't fail.
  3c) if the connection result failed because the network rejected a
V4V6 request for example, or the default_ip_family is V4 but the APN
only accepts V6, then should we retry with V4?

Dan

> Surely this information cannot be expected to be known
> by the user and is not even listed in registries like
> https://gitlab.gnome.org/GNOME/mobile-broadband-provider-info
> 
> Or are there any "cheaper" ways to probe for this than attempting a
> connect?
> 
> Andreas
> 
> ___
> ModemManager-devel mailing list
> ModemManager-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Regression regarding ip_type when updating from 1.10.4 to 1.12.0

[Andreas Fett]

Hi Aleksander,

On Thu, Nov 14, 2019 at 06:57:54PM +0100, Aleksander Morgado wrote:
> >
> > Has the interpretation of the ip_type MM_BEARER_IP_FAMILY_IPV4V6 changed 
> > when performing the connect?
> >
> 
> No it hasn't really. I really think you need to know whether the
> network supports ipv4v6 for a given APN before attempting to use it.

For writing end user oriented software where the networks and operators
that will be used are unknown when implementing it this becomes a big
problem.

Wouldn't that mean one has to try a connect with all bearer types in
whatever the preferred order is?

Surely this information cannot be expected to be known
by the user and is not even listed in registries like
https://gitlab.gnome.org/GNOME/mobile-broadband-provider-info

Or are there any "cheaper" ways to probe for this than attempting a
connect?

Andreas

-- 
The three chief virtues of a programmer are:
Laziness, Impatience and Hubris. -- Larry Wall


signature.asc
Description: PGP signature
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: ModemManager, libqmi, libmbim in openwrt packages repository - Test with ipv6-only isp

[Thomas Schäfer]

Am Donnerstag, 14. November 2019, 21:28:18 CET schrieb Thomas Schäfer:

> What is the NetworkManager part in openwrt together with ModemManager?

I found the answer here:
https://openwrt.org/docs/guide-user/network/wan/wwan/modemmanager

I will give it a chance soon.

Thomas



___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Regression regarding ip_type when updating from 1.10.4 to 1.12.0

[Aleksander Morgado]

Hey,

>
> Previous versions:
>
> - ModemManager 1.10.4
> - libmbim 1.18.2
>
> New versions:
>
> - ModemManager 1.12.0
> - libmbim 1.20.2
>
> The test device is a Lenovo T470s with a Sierra Wireless EM7455. The provider 
> is vodafone.de
>
> We configure our bearer with the ip_type MM_BEARER_IP_FAMILY_IPV4V6. We 
> assumed this means that IPv4 or IPv6 or both should be configured, whatever 
> provided by the network.
>

This is a bit more complicated I'm afraid. On MBIM devices, like the
one you're using, we pass the IP family type down to the modem during
the connection request, and if you request ipv4v6 (dual stack), that
is what the modem will try to manage with the network.

> In our tests this worked correctly with the version 1.10.4 of ModemManager, 
> when using a SIM from vodafone we got IPv4 connectivitiy, with a SIM from 
> telekom we got both IPv4 and IPv6 connectivity.
>
> However, after updating to version 1.12.0 strange behaviour occured. The 
> first view connections after a cold boot of the device failed with:
>
> 2019-11-08 09:54:31.286 modem-manager.service: [/dev/cdc-wdm0] Received 
> message (translated)...
>>> Header:
>>>   length  = 84
>>>   type= 
> command-done (0x8003)
>>>   transaction = 45
>>> Fragment header:
>>>   total   = 1
>>>   current = 0
>>> Contents:
>>>   status error = 'None' 
> (0x)
>>>   service  = 
> 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df)
>>>   cid  = 
> 'connect' (0x000c)
>>> Fields:
>>>   SessionId = '0'
>>>   ActivationState = 
> 'activated'
>>>   VoiceCallState = 
> 'none'
>>>   IpType = 'ipv4'
>>>   ContextType = 
> '7e5e2a7e-4e6f-7272-736b-656e7e5e2a7e'
>>>   NwError = '50'
> 2019-11-08 09:54:31.286 modem-manager.service: [1573206871.286147] Couldn't 
> connect bearer '/org/freedesktop/ModemManager1/Bearer/0': 'Unknown error (50)'
>
> At this moment the access tech was shown as: HSDPA | HSUPA
>

This could mean network doesn't allow dual-stack setup on 3G?

> A little later the access tech changed to LTE and I was able to connect with 
> this setting:
>
> 2019-11-08 09:55:12.822 modem-manager.service: [1573206912.822471] IPv4 
> configuration available: 'address, gateway, dns, mtu'
> 2019-11-08 09:55:12.822 modem-manager.service: [1573206912.822519]   IP 
> addresses (1)
> 2019-11-08 09:55:12.823 modem-manager.service: [1573206912.822576] IP 
> [0]: '100.96.188.174/30'
> 2019-11-08 09:55:12.823 modem-manager.service: [1573206912.822625]   Gateway: 
> '100.96.188.173'
> 2019-11-08 09:55:12.823 modem-manager.service: [1573206912.822660]   DNS 
> addresses (2)
> 2019-11-08 09:55:12.823 modem-manager.service: [1573206912.822706] DNS 
> [0]: '139.7.30.126'
> 2019-11-08 09:55:12.823 modem-manager.service: [1573206912.822753] DNS 
> [1]: '139.7.30.125'
> 2019-11-08 09:55:12.824 modem-manager.service: [1573206912.822784]   MTU: 
> '1500'
> 2019-11-08 09:55:12.824 modem-manager.service: [1573206912.822812] IPv6 
> configuration available: 'none'
> 2019-11-08 09:55:12.824 modem-manager.service: [1573206912.822961] (wwan0): 
> port now connected
> 2019-11-08 09:55:12.824 modem-manager.service: [1573206912.823046] Connected 
> bearer '/org/freedesktop/ModemManager1/Bearer/2'
>

In this case, I can see how you request a dual-stack ipv4v6 connection
setup, but the modem replies a ipv4-only connection success. MM
ignores that field and assumes the connection setup is ipv4v6 instead,
so tries to load ipv6 settings and finds none.

2019-11-08 09:55:12.630 modem-manager.service: [1573206912.630053]
Launching ipv4v6 connection with APN 'web.vodafone.de'...
2019-11-08 09:55:12.630 modem-manager.service: [/dev/cdc-wdm0] Sent message...
   << RAW:
   <<   length = 140
   <<   data   =