Re: Unable to get IPv4 over LTE
❦ 19 janvier 2016 23:59 +0100, Aleksander Morgado : > Would be interesting to see what ModemManager says in each of those > tries (--debug); and check which are the IP details given by the modem > for each case, before we even try to run the DHCP client. Could you > gather logs for both situations? Well, luckily, it failed again this morning. When failing: [mm-iface-modem-simple.c:641] connect_auth_ready(): Simple connect started... [mm-iface-modem-simple.c:651] connect_auth_ready():PIN: [mm-iface-modem-simple.c:653] connect_auth_ready():Operator ID: unspecified [mm-iface-modem-simple.c:655] connect_auth_ready():Allowed roaming: yes [mm-iface-modem-simple.c:657] connect_auth_ready():APN: internet [mm-iface-modem-simple.c:662] connect_auth_ready():IP family: ipv4v6 [mm-iface-modem-simple.c:673] connect_auth_ready():Allowed authentication: unspecified [mm-iface-modem-simple.c:675] connect_auth_ready():User: unspecified [mm-iface-modem-simple.c:677] connect_auth_ready():Password: unspecified [mm-iface-modem-simple.c:679] connect_auth_ready():Number: *99# [mm-iface-modem-simple.c:469] connection_step(): Simple connect state (4/8): Wait to get fully enabled [mm-iface-modem-simple.c:478] connection_step(): Simple connect state (5/8): Register [mm-iface-modem-3gpp.c:400] mm_iface_modem_3gpp_register_in_network(): Already registered in network '22802', automatic registration not launched... [mm-iface-modem-simple.c:501] connection_step(): Simple connect state (6/8): Bearer [mm-iface-modem-simple.c:521] connection_step(): Creating new bearer... [mm-broadband-modem-mbim.c:1163] modem_create_bearer(): Creating MBIM bearer in MBIM modem [mm-broadband-modem-mbim.c:1077] modem_create_bearer_finish(): New bearer created at DBus path '/org/freedesktop/ModemManager1/Bearer/0' [mm-iface-modem-simple.c:583] connection_step(): Simple connect state (7/8): Connect [mm-base-bearer.c:590] mm_base_bearer_connect(): Connecting bearer '/org/freedesktop/ModemManager1/Bearer/0' [mm-iface-modem.c:1392] __iface_modem_update_state_internal(): Modem /org/freedesktop/ModemManager1/Modem/0: state changed (registered -> connecting) [mm-bearer-mbim.c:897] _connect(): Launching connection with data port (net/wwan0) [mm-bearer-mbim.c:655] connect_context_step(): Activating packet service... ModemManager[12437]: [/dev/cdc-wdm0] Sent message... << RAW: << length = 52 << data = 03:00:00:00:34:00:00:00:1B:00:00:00:01:00:00:00:00:00:00:00:A2:89:CC:33:BC:BB:8B:4F:B6:B0:13:3E:C2:AA:E6:DF:0A:00:00:00:01:00:00:00:04:00:00:00:00:00:00:00 ModemManager[12437]: [/dev/cdc-wdm0] Sent message (translated)... << Header: << length = 52 << type= command (0x0003) << transaction = 27 << Fragment header: << total = 1 << current = 0 << Contents: << service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df) << cid = 'packet-service' (0x000a) << type= 'set' (0x0001) ModemManager[12437]: [/dev/cdc-wdm0] Received message... >> RAW: >> length = 76 >> data = >> 03:00:00:80:4C:00:00:00:1B:00:00:00:01:00:00:00:00:00:00:00:A2:89:CC:33:BC:BB:8B:4F:B6:B0:13:3E:C2:AA:E6:DF:0A:00:00:00:00:00:00:00:1C:00:00:00:00:00:00:00:02:00:00:00:20:00:00:00:80:F0:FA:02:00:00:00:00:00:E1:F5:05:00:00:00:00 ModemManager[12437]: [/dev/cdc-wdm0] Received message (translated)... >> Header: >> length = 76 >> type= command-done (0x8003) >> transaction = 27 >> Fragment header: >> total = 1 >> current = 0 >> Contents: >> status error = 'None' (0x) >> service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df) >> cid = 'packet-service' (0x000a) [mm-bearer-mbim.c:594] packet_service_set_ready(): Packet service update: [mm-bearer-mbim.c:595] packet_service_set_ready(): state: 'attached' [mm-bearer-mbim.c:596] packet_service_set_ready(): data class: 'lte' [mm-bearer-mbim.c:597] packet_service_set_ready(): uplink: '5000' bps [mm-bearer-mbim.c:598] packet_service_set_ready(): downlink: '1' bps [mm-bearer-mbim.c:676] connect_context_step(): Listing provisioned contexts... ModemManager[12437]: [/dev/cdc-wdm0] Sent message... << RAW: << length = 48 << data = 03:00:00:00:30:00:00:00:1C:00:00:00:01:00:00:00:00:00:00:00:A2:89:CC:33:BC:BB:8B:4F:B6:B0:13:3E:C2:AA:E6:DF:0D:00:00:00:00:00:00:00:00:00:00:00 ModemManager[12437]: [/dev/cdc-wdm0] Sent message (translated)... << Header: << length = 48 << type= command (0x0003) << transaction = 28 << Fragment header: << total = 1 << current = 0 << Contents: << service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df) << cid = 'provisioned-contexts' (0x000d) << type= 'query' (0x) ModemManager[12437]: [/dev/
Re: Unable to get IPv4 over LTE
On Tue, 2016-01-19 at 23:59 +0100, Aleksander Morgado wrote: > Hey Vincent! > > On Tue, Jan 19, 2016 at 10:08 PM, Vincent Bernat > wrote: > > I got an odd problem since some time. > > > > Bus 002 Device 045: ID 1199:a001 Sierra Wireless, Inc. > > ii modemmanager 1.4.12-1 amd64 D-Bus service for > > managing modems > > Linux zoro 4.3.0-1-amd64 #1 SMP Debian 4.3.3-5 (2016-01-04) x86_64 > > GNU/Linux > > > > When I am connected over LTE for the first time since a few days, I > > cannot get an IPv4. NM just starts a dhclient and the dhclient > > doesn't > > get an IP. > > > > NetworkManager[6880]: (cdc-wdm0): Activation: starting > > connection 'Sunrise' (fbce8984-7556-44e9-ad99-32d61e7fed7 > > NetworkManager[6880]: (cdc-wdm0): device state change: > > disconnected -> prepare (reason 'none') [30 40 0] > > NetworkManager[6880]: NetworkManager state is now > > CONNECTING > > ModemManager[6866]: Simple connect started... > > ModemManager[6866]: Simple connect state (4/8): Wait to get > > fully enabled > > ModemManager[6866]: Simple connect state (5/8): Register > > ModemManager[6866]: Simple connect state (6/8): Bearer > > ModemManager[6866]: Simple connect state (7/8): Connect > > ModemManager[6866]: Modem > > /org/freedesktop/ModemManager1/Modem/0: state changed (registered > > -> connecting) > > NetworkManager[6880]: (cdc-wdm0): modem state changed, > > 'registered' --> 'connecting' (reason: user-requested) > > ModemManager[6866]: Modem > > /org/freedesktop/ModemManager1/Modem/0: state changed (connecting > > -> connected) > > ModemManager[6866]: Simple connect state (8/8): All done > > NetworkManager[6880]: (cdc-wdm0): modem state changed, > > 'connecting' --> 'connected' (reason: user-requested) > > NetworkManager[6880]: (cdc-wdm0): device state change: > > prepare -> config (reason 'none') [40 50 0] > > NetworkManager[6880]: (cdc-wdm0): device state change: > > config -> ip-config (reason 'none') [50 70 0] > > NetworkManager[6880]: Activation (wwan0) Beginning DHCPv4 > > transaction (timeout in 15 seconds) > > NetworkManager[6880]: dhclient started with pid 7248 > > NetworkManager[6880]: (cdc-wdm0): IPv6 configuration > > disabled > > dhclient[7248]: DHCPDISCOVER on wwan0 to 255.255.255.255 port 67 > > interval 5 > > dhclient[7248]: DHCPDISCOVER on wwan0 to 255.255.255.255 port 67 > > interval 10 > > dhclient[7248]: DHCPDISCOVER on wwan0 to 255.255.255.255 port 67 > > interval 15 > > NetworkManager[6880]: (wwan0): DHCPv4 request timed out. > > NetworkManager[6880]: (wwan0): DHCPv4 state changed unknown > > -> timeout > > NetworkManager[6880]: (wwan0): canceled DHCP transaction, > > DHCP client pid 7248 > > NetworkManager[6880]: (wwan0): DHCPv4 state changed timeout > > -> done > > > > When I am not over LTE, the steps are different: > > > > ModemManager[8662]: Simple connect state (8/8): All done > > NetworkManager[8676]: (cdc-wdm0): modem state changed, > > 'connecting' --> 'connected' (reason: user-requested) > > NetworkManager[8676]: (cdc-wdm0): device state change: > > prepare -> config (reason 'none') [40 50 0] > > NetworkManager[8676]: (cdc-wdm0): device state change: > > config -> ip-config (reason 'none') [50 70 0] > > NetworkManager[8676]: (cdc-wdm0): IPv4 static > > configuration: > > NetworkManager[8676]: address 10.129.4.193/24 > > NetworkManager[8676]: gateway 10.129.4.1 > > NetworkManager[8676]: DNS 10.200.102.243 > > NetworkManager[8676]: DNS 10.200.102.244 > > [...] > > > > After that, it works just fine. If I happen to switch back to LTE > > during > > the connection, the connection keeps working. If I disconnect and > > reconnect over LTE, it connects immediately. > > > > I don't remember exactly when things has changed, but it worked > > fine in > > the past over LTE. I have tried with three different carriers with > > the > > same symptoms. If I use the modem daily, I have no problem > > connecting. If I don't connect for a week, I have to find a way to > > not > > be over LTE to be able to connect the first time. > > That's weird. > > Would be interesting to see what ModemManager says in each of those > tries (--debug); and check which are the IP details given by the > modem > for each case, before we even try to run the DHCP client. Could you > gather logs for both situations? > > Dan, maybe we should put the printed IP details as g_message() > instead > of g_debug()? They're probably worth having in the logs. Sure; pushed to master and mm-1-4. Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Unable to get IPv4 over LTE
Hey Vincent! On Tue, Jan 19, 2016 at 10:08 PM, Vincent Bernat wrote: > I got an odd problem since some time. > > Bus 002 Device 045: ID 1199:a001 Sierra Wireless, Inc. > ii modemmanager 1.4.12-1 amd64 D-Bus service for managing > modems > Linux zoro 4.3.0-1-amd64 #1 SMP Debian 4.3.3-5 (2016-01-04) x86_64 GNU/Linux > > When I am connected over LTE for the first time since a few days, I > cannot get an IPv4. NM just starts a dhclient and the dhclient doesn't > get an IP. > > NetworkManager[6880]: (cdc-wdm0): Activation: starting connection > 'Sunrise' (fbce8984-7556-44e9-ad99-32d61e7fed7 > NetworkManager[6880]: (cdc-wdm0): device state change: disconnected > -> prepare (reason 'none') [30 40 0] > NetworkManager[6880]: NetworkManager state is now CONNECTING > ModemManager[6866]: Simple connect started... > ModemManager[6866]: Simple connect state (4/8): Wait to get fully > enabled > ModemManager[6866]: Simple connect state (5/8): Register > ModemManager[6866]: Simple connect state (6/8): Bearer > ModemManager[6866]: Simple connect state (7/8): Connect > ModemManager[6866]: Modem /org/freedesktop/ModemManager1/Modem/0: > state changed (registered -> connecting) > NetworkManager[6880]: (cdc-wdm0): modem state changed, 'registered' > --> 'connecting' (reason: user-requested) > ModemManager[6866]: Modem /org/freedesktop/ModemManager1/Modem/0: > state changed (connecting -> connected) > ModemManager[6866]: Simple connect state (8/8): All done > NetworkManager[6880]: (cdc-wdm0): modem state changed, 'connecting' > --> 'connected' (reason: user-requested) > NetworkManager[6880]: (cdc-wdm0): device state change: prepare -> > config (reason 'none') [40 50 0] > NetworkManager[6880]: (cdc-wdm0): device state change: config -> > ip-config (reason 'none') [50 70 0] > NetworkManager[6880]: Activation (wwan0) Beginning DHCPv4 transaction > (timeout in 15 seconds) > NetworkManager[6880]: dhclient started with pid 7248 > NetworkManager[6880]: (cdc-wdm0): IPv6 configuration disabled > dhclient[7248]: DHCPDISCOVER on wwan0 to 255.255.255.255 port 67 interval 5 > dhclient[7248]: DHCPDISCOVER on wwan0 to 255.255.255.255 port 67 interval 10 > dhclient[7248]: DHCPDISCOVER on wwan0 to 255.255.255.255 port 67 interval 15 > NetworkManager[6880]: (wwan0): DHCPv4 request timed out. > NetworkManager[6880]: (wwan0): DHCPv4 state changed unknown -> timeout > NetworkManager[6880]: (wwan0): canceled DHCP transaction, DHCP client > pid 7248 > NetworkManager[6880]: (wwan0): DHCPv4 state changed timeout -> done > > When I am not over LTE, the steps are different: > > ModemManager[8662]: Simple connect state (8/8): All done > NetworkManager[8676]: (cdc-wdm0): modem state changed, 'connecting' > --> 'connected' (reason: user-requested) > NetworkManager[8676]: (cdc-wdm0): device state change: prepare -> > config (reason 'none') [40 50 0] > NetworkManager[8676]: (cdc-wdm0): device state change: config -> > ip-config (reason 'none') [50 70 0] > NetworkManager[8676]: (cdc-wdm0): IPv4 static configuration: > NetworkManager[8676]: address 10.129.4.193/24 > NetworkManager[8676]: gateway 10.129.4.1 > NetworkManager[8676]: DNS 10.200.102.243 > NetworkManager[8676]: DNS 10.200.102.244 > [...] > > After that, it works just fine. If I happen to switch back to LTE during > the connection, the connection keeps working. If I disconnect and > reconnect over LTE, it connects immediately. > > I don't remember exactly when things has changed, but it worked fine in > the past over LTE. I have tried with three different carriers with the > same symptoms. If I use the modem daily, I have no problem > connecting. If I don't connect for a week, I have to find a way to not > be over LTE to be able to connect the first time. That's weird. Would be interesting to see what ModemManager says in each of those tries (--debug); and check which are the IP details given by the modem for each case, before we even try to run the DHCP client. Could you gather logs for both situations? Dan, maybe we should put the printed IP details as g_message() instead of g_debug()? They're probably worth having in the logs. -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Unable to get IPv4 over LTE
Hey! I got an odd problem since some time. Bus 002 Device 045: ID 1199:a001 Sierra Wireless, Inc. ii modemmanager 1.4.12-1 amd64 D-Bus service for managing modems Linux zoro 4.3.0-1-amd64 #1 SMP Debian 4.3.3-5 (2016-01-04) x86_64 GNU/Linux When I am connected over LTE for the first time since a few days, I cannot get an IPv4. NM just starts a dhclient and the dhclient doesn't get an IP. NetworkManager[6880]: (cdc-wdm0): Activation: starting connection 'Sunrise' (fbce8984-7556-44e9-ad99-32d61e7fed7 NetworkManager[6880]: (cdc-wdm0): device state change: disconnected -> prepare (reason 'none') [30 40 0] NetworkManager[6880]: NetworkManager state is now CONNECTING ModemManager[6866]: Simple connect started... ModemManager[6866]: Simple connect state (4/8): Wait to get fully enabled ModemManager[6866]: Simple connect state (5/8): Register ModemManager[6866]: Simple connect state (6/8): Bearer ModemManager[6866]: Simple connect state (7/8): Connect ModemManager[6866]: Modem /org/freedesktop/ModemManager1/Modem/0: state changed (registered -> connecting) NetworkManager[6880]: (cdc-wdm0): modem state changed, 'registered' --> 'connecting' (reason: user-requested) ModemManager[6866]: Modem /org/freedesktop/ModemManager1/Modem/0: state changed (connecting -> connected) ModemManager[6866]: Simple connect state (8/8): All done NetworkManager[6880]: (cdc-wdm0): modem state changed, 'connecting' --> 'connected' (reason: user-requested) NetworkManager[6880]: (cdc-wdm0): device state change: prepare -> config (reason 'none') [40 50 0] NetworkManager[6880]: (cdc-wdm0): device state change: config -> ip-config (reason 'none') [50 70 0] NetworkManager[6880]: Activation (wwan0) Beginning DHCPv4 transaction (timeout in 15 seconds) NetworkManager[6880]: dhclient started with pid 7248 NetworkManager[6880]: (cdc-wdm0): IPv6 configuration disabled dhclient[7248]: DHCPDISCOVER on wwan0 to 255.255.255.255 port 67 interval 5 dhclient[7248]: DHCPDISCOVER on wwan0 to 255.255.255.255 port 67 interval 10 dhclient[7248]: DHCPDISCOVER on wwan0 to 255.255.255.255 port 67 interval 15 NetworkManager[6880]: (wwan0): DHCPv4 request timed out. NetworkManager[6880]: (wwan0): DHCPv4 state changed unknown -> timeout NetworkManager[6880]: (wwan0): canceled DHCP transaction, DHCP client pid 7248 NetworkManager[6880]: (wwan0): DHCPv4 state changed timeout -> done When I am not over LTE, the steps are different: ModemManager[8662]: Simple connect state (8/8): All done NetworkManager[8676]: (cdc-wdm0): modem state changed, 'connecting' --> 'connected' (reason: user-requested) NetworkManager[8676]: (cdc-wdm0): device state change: prepare -> config (reason 'none') [40 50 0] NetworkManager[8676]: (cdc-wdm0): device state change: config -> ip-config (reason 'none') [50 70 0] NetworkManager[8676]: (cdc-wdm0): IPv4 static configuration: NetworkManager[8676]: address 10.129.4.193/24 NetworkManager[8676]: gateway 10.129.4.1 NetworkManager[8676]: DNS 10.200.102.243 NetworkManager[8676]: DNS 10.200.102.244 [...] After that, it works just fine. If I happen to switch back to LTE during the connection, the connection keeps working. If I disconnect and reconnect over LTE, it connects immediately. I don't remember exactly when things has changed, but it worked fine in the past over LTE. I have tried with three different carriers with the same symptoms. If I use the modem daily, I have no problem connecting. If I don't connect for a week, I have to find a way to not be over LTE to be able to connect the first time. -- And do you think (fop that I am) that I could be the Scarlet Pumpernickel? ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: ModemManager using QMI doesnt always work in the first attemp.
On Tue, Jan 19, 2016 at 9:55 PM, c.lobr...@gmail.com wrote: > >> I have also noticed that ModemManager uses not documented AT+CFUN modes: >> >> root at ccimx6sbc:~# mmcli -m 0 --set-power-state-off >> ModemManager[791]: Modem powered off... may no longer be accessible >> successfully set new power state in the modem >> root at ccimx6sbc:~# microcom /dev/ttyUSB2 >> >> OK >> at+cfun? >> +CFUN: 7 >> >> OK >> root at ccimx6sbc:~# mmcli -m 0 --set-power-state-low >> successfully set new power state in the modem >> root at ccimx6sbc:~# microcom /dev/ttyUSB2 >> at+cfun? >> +CFUN: 6 >> >> OK >> >> The only documented modes are 0, 1, 4 ,5 (see >> >> http://www.coniugo.de/tl_files/dateien/downloads/at/AT%20Commands%20LE910.pdf, >> page 106). > > Here you can find a more recent document that defines also state 7 > > http://www.telit.com/products/cellular/4g/ > > e.g. If your modem is a LE910 (namely non V2): > > Parameters: > > - is the power saving function mode > 0 - minimum functionality, NON-CYCLIC SLEEP mode > 1 - mobile full functionality with power saving disabled (factory default) > 2 - disable TX (Not support) > 4 - disable both TX and RX > 5 - mobile full functionality with power saving enabled > Special modes , you can see them through the read command but you can't set > those > mode : > 7 – Offline mode > 8 – FTM The key point, though, is that the modem is being managed in QMI mode, not via AT commands. I wonder if the "QMI DMS operating system" request/responses aren't enough or something. -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: ModemManager using QMI doesnt always work in the first attemp.
Hi José, Aleksander, my two cents here > I have also noticed that ModemManager uses not documented AT+CFUN modes: > > root at ccimx6sbc:~# mmcli -m 0 --set-power-state-off > ModemManager[791]: Modem powered off... may no longer be accessible > successfully set new power state in the modem > root at ccimx6sbc:~# microcom /dev/ttyUSB2 > > OK > at+cfun? > +CFUN: 7 > > OK > root at ccimx6sbc:~# mmcli -m 0 --set-power-state-low > successfully set new power state in the modem > root at ccimx6sbc:~# microcom /dev/ttyUSB2 > at+cfun? > +CFUN: 6 > > OK > > The only documented modes are 0, 1, 4 ,5 (see > http://www.coniugo.de/tl_files/dateien/downloads/at/AT%20Commands%20LE910.pdf, > page 106). Here you can find a more recent document that defines also state 7 http://www.telit.com/products/cellular/4g/ e.g. If your modem is a LE910 (namely non V2): Parameters: - is the power saving function mode 0 - minimum functionality, NON-CYCLIC SLEEP mode 1 - mobile full functionality with power saving disabled (factory default) 2 - disable TX (Not support) 4 - disable both TX and RX 5 - mobile full functionality with power saving enabled Special modes , you can see them through the read command but you can't set those mode : 7 – Offline mode 8 – FTM Carlo ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: ModemManager using QMI doesnt always work in the first attemp.
Hey!
On Tue, Jan 19, 2016 at 6:36 PM, José wrote:
> Looking at
> http://cgit.freedesktop.org/ModemManager/ModemManager/tree/plugins/telit/mm-plugin-telit.c?id=1.4.12
> seems like the Telit plugin only handles tty port, but I am using QMI
> with the Telit LE910. Should it still be using the Telit plugin?
>
Ideally, the Telit plugin itself should be able to manage QMI modems.
That is what I was targeting to do in git master, no more generic
"gobi" plugin.
> The following lines appear at the log (in this order):
>
> (Telit) [wwan0] filtered by subsystem
> (Telit) [ttyUSB4] filtered by udev tags
> (Telit) [ttyUSB1] filtered by udev tags
> (Telit) [ttyUSB2] filtered by udev tags
> (Telit) [ttyUSB3] filtered by udev tags
> (Telit) [ttyUSB0] filtered by udev tags
> (Telit) [cdc-wdm0] filtered by subsystem
>
That means there are no udev tags for your device, I guess.
> I think at least one of the ttyUSBn device nodes should NOT filter
> Telit plugin, right? From the code:
>
Yes. All of them should have udev tags; check the udev rules in the
plugins/telit directory.
> /* If we didn't match any udev tag: unsupported */
> if (!self->priv->udev_tags[i]) {
> mm_dbg ("(%s) [%s] filtered by udev tags",
> self->priv->name,
> g_udev_device_get_name (port));
> return TRUE;
> }
>
>
> I have been looking at
> http://cgit.freedesktop.org/ModemManager/ModemManager/commit/?h=mm-1-4&id=0505021ac6c79c28bd28184a9daa988b0712c71f
> and seems like the idProduct is not in the udev rules. Should the
> idProduct 1201 be added? Looking around (for exapmle
> http://www.spinics.net/lists/linux-usb/msg115457.html) seems like this
> is the right productId for Telit LE910.
>
> I attach all the relevant information (I think) for the modem.
>
Also, as said earlier, I would make sure the Telit plugin handles QMI
when QMI is found, so that we see the Telit plugin managing the modem,
even if it's using the generic QMI implementation; in that way we
could subclass the QMI implementation in the plugin directly if needed
(as we do for Cinterion to provide AT-based GPS management given that
no QMI service is implemented).
So, to recap:
* Check if you can add udev tags for your device in the Telit plugin
udev rules.
* Check if you can add QMI support in the Telit plugin directly.
Thanks!
--
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: ModemManager using QMI doesnt always work in the first attemp.
Looking at
http://cgit.freedesktop.org/ModemManager/ModemManager/tree/plugins/telit/mm-plugin-telit.c?id=1.4.12
seems like the Telit plugin only handles tty port, but I am using QMI
with the Telit LE910. Should it still be using the Telit plugin?
The following lines appear at the log (in this order):
(Telit) [wwan0] filtered by subsystem
(Telit) [ttyUSB4] filtered by udev tags
(Telit) [ttyUSB1] filtered by udev tags
(Telit) [ttyUSB2] filtered by udev tags
(Telit) [ttyUSB3] filtered by udev tags
(Telit) [ttyUSB0] filtered by udev tags
(Telit) [cdc-wdm0] filtered by subsystem
I think at least one of the ttyUSBn device nodes should NOT filter
Telit plugin, right? From the code:
/* If we didn't match any udev tag: unsupported */
if (!self->priv->udev_tags[i]) {
mm_dbg ("(%s) [%s] filtered by udev tags",
self->priv->name,
g_udev_device_get_name (port));
return TRUE;
}
I have been looking at
http://cgit.freedesktop.org/ModemManager/ModemManager/commit/?h=mm-1-4&id=0505021ac6c79c28bd28184a9daa988b0712c71f
and seems like the idProduct is not in the udev rules. Should the
idProduct 1201 be added? Looking around (for exapmle
http://www.spinics.net/lists/linux-usb/msg115457.html) seems like this
is the right productId for Telit LE910.
I attach all the relevant information (I think) for the modem.
root@ccimx6sbc:~# lsusb
Bus 001 Device 003: ID 1bc7:1201 Telit
root@ccimx6sbc:~# udevadm info -a -p /sys/class/tty/ttyUSB0 | head -100
looking at device
'/devices/soc0/soc.0/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1/1-1.3/1-1.3:1.0/ttyUSB0/tty/ttyUSB0':
KERNEL=="ttyUSB0"
SUBSYSTEM=="tty"
DRIVER==""
looking at parent device
'/devices/soc0/soc.0/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1/1-1.3/1-1.3:1.0/ttyUSB0':
KERNELS=="ttyUSB0"
SUBSYSTEMS=="usb-serial"
DRIVERS=="option1"
ATTRS{port_number}=="0"
looking at parent device
'/devices/soc0/soc.0/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1/1-1.3/1-1.3:1.0':
KERNELS=="1-1.3:1.0"
SUBSYSTEMS=="usb"
DRIVERS=="option"
ATTRS{bInterfaceClass}=="ff"
ATTRS{bInterfaceSubClass}=="ff"
ATTRS{bInterfaceProtocol}=="ff"
ATTRS{bNumEndpoints}=="02"
ATTRS{supports_autosuspend}=="1"
ATTRS{bAlternateSetting}==" 0"
ATTRS{bInterfaceNumber}=="00"
looking at parent device
'/devices/soc0/soc.0/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1/1-1.3':
KERNELS=="1-1.3"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{bDeviceSubClass}=="00"
ATTRS{bDeviceProtocol}=="00"
ATTRS{devpath}=="1.3"
ATTRS{idVendor}=="1bc7"
ATTRS{speed}=="480"
ATTRS{bNumInterfaces}==" 7"
ATTRS{bConfigurationValue}=="1"
ATTRS{bMaxPacketSize0}=="64"
ATTRS{busnum}=="1"
ATTRS{devnum}=="3"
ATTRS{configuration}==""
ATTRS{bMaxPower}=="500mA"
ATTRS{authorized}=="1"
ATTRS{bmAttributes}=="80"
ATTRS{bNumConfigurations}=="1"
ATTRS{maxchild}=="0"
ATTRS{bcdDevice}=="0232"
ATTRS{avoid_reset_quirk}=="0"
ATTRS{quirks}=="0x0"
ATTRS{serial}=="0123456789ABCDEF"
ATTRS{version}==" 2.00"
ATTRS{urbnum}=="11"
ATTRS{ltm_capable}=="no"
ATTRS{manufacturer}=="Android"
ATTRS{removable}=="removable"
ATTRS{idProduct}=="1201"
ATTRS{bDeviceClass}=="00"
ATTRS{product}=="Android"
looking at parent device
'/devices/soc0/soc.0/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1':
KERNELS=="1-1"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{bDeviceSubClass}=="00"
ATTRS{bDeviceProtocol}=="02"
ATTRS{devpath}=="1"
ATTRS{idVendor}=="0424"
ATTRS{speed}=="480"
ATTRS{bNumInterfaces}==" 1"
ATTRS{bConfigurationValue}=="1"
ATTRS{bMaxPacketSize0}=="64"
ATTRS{busnum}=="1"
ATTRS{devnum}=="2"
ATTRS{configuration}==""
ATTRS{bMaxPower}=="2mA"
ATTRS{authorized}=="1"
ATTRS{bmAttributes}=="e0"
ATTRS{bNumConfigurations}=="1"
ATTRS{maxchild}=="4"
ATTRS{bcdDevice}=="0bb3"
ATTRS{avoid_reset_quirk}=="0"
ATTRS{quirks}=="0x0"
ATTRS{version}==" 2.00"
ATTRS{urbnum}=="37"
ATTRS{ltm_capable}=="no"
ATTRS{removable}=="unknown"
ATTRS{idProduct}=="2514"
ATTRS{bDeviceClass}=="09"
root@ccimx6sbc:~# udevadm info -a -p /sys/class/tty/ttyUSB1 | head -18
looking at device
'/devices/soc0/soc.0/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1/1-1.3/1-1.3:1.3/ttyUSB1/tty/ttyUSB1':
KERNEL=="ttyUSB1"
SUBSYSTEM=="tty"
DRIVER==""
looking at parent device
'/devices/soc0/soc.0/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1/1-1.3/1-1.3:1.3/ttyUSB1':
KERNELS=="ttyUSB1"
SUBSYSTEMS=="usb-serial"
DRIVERS=="option1"
ATTRS{port_number}=="0"
root@ccimx6sbc:~# udevadm info -a -p /sys/class/tty/ttyUSB2 | head -18
looking at device
'/devices/soc0/soc.0/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1/1-1.3/1-1.3:1.4/ttyUSB2/tty/ttyUSB2':
KERNEL=="ttyUSB2"
SUBSYSTEM=="tty"
DRIVER==""
lo
Re: ModemManager using QMI doesnt always work in the first attemp.
On Tue, Jan 19, 2016 at 4:51 PM, José wrote: > I have update to the last firmware (17.01.522 1 [Oct 16 2014 > 07:00:00]) and the issue is still reproducible. > > I am almost sure that the issue is related to power management. > > When the modem is in AT+CFUN=4, trying to enable it with ModemManager > (mmcli -m 0 -e) does not work. Trying to change the power state does > also not work (mmcli --set-power-state-on). > > root@ccimx6sbc:~# mmcli -m 0 --set-power-state-on > ModemManager[791]: Couldn't reload current power state: Unhandled > power state: 'reset' (4) > error: couldn't set new power state in the modem: > 'GDBus.Error:org.freedesktop.libqmi.Error.Protocol.InvalidTransaction: > Couldn't set operating mode: QMI protocol error (60): > 'InvalidTransaction'' > root@ccimx6sbc:~# mmcli -m 0 -e > ModemManager[791]: Modem > /org/freedesktop/ModemManager1/Modem/0: state changed (disabled -> > enabling) > ModemManager[791]: (ttyUSB2): port attributes not fully set > ModemManager[791]: (ttyUSB3): port attributes not fully set > ModemManager[791]: Couldn't reload current power state: Unhandled > power state: 'reset' (4) > ModemManager[791]: Modem > /org/freedesktop/ModemManager1/Modem/0: state changed (enabling -> > disabled) > error: couldn't enable the modem: > 'GDBus.Error:org.freedesktop.libqmi.Error.Protocol.InvalidTransaction: > Couldn't set operating mode: QMI protocol error (60): > 'InvalidTransaction'' > > Note that a SIM card is inserted. > > > I have also noticed that ModemManager uses not documented AT+CFUN modes: > > root@ccimx6sbc:~# mmcli -m 0 --set-power-state-off > ModemManager[791]: Modem powered off... may no longer be accessible > successfully set new power state in the modem > root@ccimx6sbc:~# microcom /dev/ttyUSB2 > > OK > at+cfun? > +CFUN: 7 > > OK > root@ccimx6sbc:~# mmcli -m 0 --set-power-state-low > successfully set new power state in the modem > root@ccimx6sbc:~# microcom /dev/ttyUSB2 > at+cfun? > +CFUN: 6 > > OK > > The only documented modes are 0, 1, 4 ,5 (see > http://www.coniugo.de/tl_files/dateien/downloads/at/AT%20Commands%20LE910.pdf, > page 106). > > I have noticed that mmcli -m 0 reports that the Generic plugin is > being used. Should it be using some specific for Telit? > Yes, it should be using the Telit plugin. > Just in case this is the report of mmcli -m 0 when the modem is in low > power state: > > root@ccimx6sbc:~# mmcli -m 0 > > /org/freedesktop/ModemManager1/Modem/0 (device id > 'dff8e6a4b1f4c5db7b0e79cea559b461ae4f450e') > - > Hardware | manufacturer: 'QUALCOMM INCORPORATED' >| model: '3' >| revision: '17.01.522 1 [Oct 16 2014 07:00:00]' >| supported: 'gsm-umts >| lte >| gsm-umts, lte' >|current: 'gsm-umts, lte' >| equipment id: 'unknown' > - > System | device: > '/sys/devices/soc0/soc.0/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1/1-1.3' >|drivers: 'qmi_wwan, option1' >| plugin: 'Generic' >| primary port: 'cdc-wdm0' >| ports: 'ttyUSB0 (qcdm), ttyUSB2 (at), ttyUSB3 > (at), wwan0 (net), cdc-wdm0 (qmi)' > - > Numbers | own : 'unknown' > - > Status | lock: 'sim-pin2' >| unlock retries: 'sim-pin (3), sim-pin2 (3), sim-puk (10), > sim-puk2 (10)' >| state: 'disabled' >|power state: 'low' >|access tech: 'unknown' >| signal quality: '0' (cached) > - > Modes| supported: 'allowed: 2g, 3g, 4g; preferred: none' >|current: 'allowed: 2g, 3g, 4g; preferred: none' > - > Bands| supported: 'cdma-bc15-aws, dcs, egsm, u2100, u800, > u850, u900, eutran-iii, eutran-vii, eutran-xx' >|current: 'cdma-bc15-aws, dcs, egsm, u2100, u800, > u850, u900, eutran-iii, eutran-vii, eutran-xx' > - > IP | supported: 'ipv4, ipv6, ipv4v6' > - > 3GPP | imei: 'unknown' >| enabled locks: 'none' >|operator id: 'unknown' >| operator name: 'unknown' >| subscription: 'unknown' >| registration: 'unknown' > - > SIM | path: '/org/freedesktop/ModemManager1/SIM/0' > > - > Bearers | paths: 'none' > -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: ModemManager using QMI doesnt always work in the first attemp.
I have update to the last firmware (17.01.522 1 [Oct 16 2014 07:00:00]) and the issue is still reproducible. I am almost sure that the issue is related to power management. When the modem is in AT+CFUN=4, trying to enable it with ModemManager (mmcli -m 0 -e) does not work. Trying to change the power state does also not work (mmcli --set-power-state-on). root@ccimx6sbc:~# mmcli -m 0 --set-power-state-on ModemManager[791]: Couldn't reload current power state: Unhandled power state: 'reset' (4) error: couldn't set new power state in the modem: 'GDBus.Error:org.freedesktop.libqmi.Error.Protocol.InvalidTransaction: Couldn't set operating mode: QMI protocol error (60): 'InvalidTransaction'' root@ccimx6sbc:~# mmcli -m 0 -e ModemManager[791]: Modem /org/freedesktop/ModemManager1/Modem/0: state changed (disabled -> enabling) ModemManager[791]: (ttyUSB2): port attributes not fully set ModemManager[791]: (ttyUSB3): port attributes not fully set ModemManager[791]: Couldn't reload current power state: Unhandled power state: 'reset' (4) ModemManager[791]: Modem /org/freedesktop/ModemManager1/Modem/0: state changed (enabling -> disabled) error: couldn't enable the modem: 'GDBus.Error:org.freedesktop.libqmi.Error.Protocol.InvalidTransaction: Couldn't set operating mode: QMI protocol error (60): 'InvalidTransaction'' Note that a SIM card is inserted. I have also noticed that ModemManager uses not documented AT+CFUN modes: root@ccimx6sbc:~# mmcli -m 0 --set-power-state-off ModemManager[791]: Modem powered off... may no longer be accessible successfully set new power state in the modem root@ccimx6sbc:~# microcom /dev/ttyUSB2 OK at+cfun? +CFUN: 7 OK root@ccimx6sbc:~# mmcli -m 0 --set-power-state-low successfully set new power state in the modem root@ccimx6sbc:~# microcom /dev/ttyUSB2 at+cfun? +CFUN: 6 OK The only documented modes are 0, 1, 4 ,5 (see http://www.coniugo.de/tl_files/dateien/downloads/at/AT%20Commands%20LE910.pdf, page 106). I have noticed that mmcli -m 0 reports that the Generic plugin is being used. Should it be using some specific for Telit? Just in case this is the report of mmcli -m 0 when the modem is in low power state: root@ccimx6sbc:~# mmcli -m 0 /org/freedesktop/ModemManager1/Modem/0 (device id 'dff8e6a4b1f4c5db7b0e79cea559b461ae4f450e') - Hardware | manufacturer: 'QUALCOMM INCORPORATED' | model: '3' | revision: '17.01.522 1 [Oct 16 2014 07:00:00]' | supported: 'gsm-umts | lte | gsm-umts, lte' |current: 'gsm-umts, lte' | equipment id: 'unknown' - System | device: '/sys/devices/soc0/soc.0/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1/1-1.3' |drivers: 'qmi_wwan, option1' | plugin: 'Generic' | primary port: 'cdc-wdm0' | ports: 'ttyUSB0 (qcdm), ttyUSB2 (at), ttyUSB3 (at), wwan0 (net), cdc-wdm0 (qmi)' - Numbers | own : 'unknown' - Status | lock: 'sim-pin2' | unlock retries: 'sim-pin (3), sim-pin2 (3), sim-puk (10), sim-puk2 (10)' | state: 'disabled' |power state: 'low' |access tech: 'unknown' | signal quality: '0' (cached) - Modes| supported: 'allowed: 2g, 3g, 4g; preferred: none' |current: 'allowed: 2g, 3g, 4g; preferred: none' - Bands| supported: 'cdma-bc15-aws, dcs, egsm, u2100, u800, u850, u900, eutran-iii, eutran-vii, eutran-xx' |current: 'cdma-bc15-aws, dcs, egsm, u2100, u800, u850, u900, eutran-iii, eutran-vii, eutran-xx' - IP | supported: 'ipv4, ipv6, ipv4v6' - 3GPP | imei: 'unknown' | enabled locks: 'none' |operator id: 'unknown' | operator name: 'unknown' | subscription: 'unknown' | registration: 'unknown' - SIM | path: '/org/freedesktop/ModemManager1/SIM/0' - Bearers | paths: 'none' On Tue, Jan 19, 2016 at 10:29 AM, Aleksander Morgado wrote: > On 19/01/16 10:13, José wrote: >> The problem only occurs if the LE910 was in low power mode (AT+CFUN=4) when >> plugged to the embbeded device. Does ModemManager manage power state modes? >> Should it automatically full enable the modem (AT+CFUN=1) when issuing >> mmcli --simple-connect? >> > > Yes, that we do by default, unless something is wrong somewhere. You can > check the debug logs and look for that command being sent I guess. > > -- > Aleksander > https://aleksander.es ___ ModemManager-devel mailing list ModemManager
Re: Trying to get MC7354 connected to Verizon data network
Aleksander Morgado writes: > On Tue, Jan 19, 2016 at 11:51 AM, Bjørn Mork wrote: >>> On Mon, Jan 18, 2016 at 10:15 PM, Glenn Washburn >>> wrote: "curl -v --interface wwan0 http://www.google.com"; >>> >>> You're binding the request to the wwan interface, which I assume it's >>> because it isn't the default route. >>> >>> Try to disable the reverse path filtering, something like: >>> # for i in /proc/sys/net/ipv4/conf/*/rp_filter ; do echo 0 > $i; done >> >> Nice catch! Personally I like to leave rp filtering to my ISP, blindly >> accepting anything they let through :) >> >> But I still do not understand how those synack's could pass the filter? > > You mean because they could be seen in the tcpdump? IIRC the rp-filter > happens afterwards, although I'm not 100% sure; this is a long time > ago I faced it myself when doing multiplexing of communications over > multiple wwans. You're right. I just tested and see the exact same behaviour. I wrongly assumed that the rp_filtering would apply somewhere around the iptables INPUT filtering, but it looks like it must be later. So you do see the synack packets in the packet dump, but tcp won't see them. So all that makes sense then. Turn off rp_filter, or set up the symmetrical routing. I usually do both myself :) Bjørn ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Trying to get MC7354 connected to Verizon data network
On Tue, Jan 19, 2016 at 11:51 AM, Bjørn Mork wrote: >> On Mon, Jan 18, 2016 at 10:15 PM, Glenn Washburn >> wrote: >>> "curl -v --interface wwan0 http://www.google.com"; >> >> You're binding the request to the wwan interface, which I assume it's >> because it isn't the default route. >> >> Try to disable the reverse path filtering, something like: >> # for i in /proc/sys/net/ipv4/conf/*/rp_filter ; do echo 0 > $i; done > > Nice catch! Personally I like to leave rp filtering to my ISP, blindly > accepting anything they let through :) > > But I still do not understand how those synack's could pass the filter? You mean because they could be seen in the tcpdump? IIRC the rp-filter happens afterwards, although I'm not 100% sure; this is a long time ago I faced it myself when doing multiplexing of communications over multiple wwans. -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Trying to get MC7354 connected to Verizon data network
Aleksander Morgado writes: > On Mon, Jan 18, 2016 at 10:15 PM, Glenn Washburn > wrote: >> "curl -v --interface wwan0 http://www.google.com"; > > You're binding the request to the wwan interface, which I assume it's > because it isn't the default route. > > Try to disable the reverse path filtering, something like: > # for i in /proc/sys/net/ipv4/conf/*/rp_filter ; do echo 0 > $i; done Nice catch! Personally I like to leave rp filtering to my ISP, blindly accepting anything they let through :) But I still do not understand how those synack's could pass the filter? Bjørn ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: ModemManager using QMI doesnt always work in the first attemp.
On 19/01/16 10:13, José wrote: > The problem only occurs if the LE910 was in low power mode (AT+CFUN=4) when > plugged to the embbeded device. Does ModemManager manage power state modes? > Should it automatically full enable the modem (AT+CFUN=1) when issuing > mmcli --simple-connect? > Yes, that we do by default, unless something is wrong somewhere. You can check the debug logs and look for that command being sent I guess. -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: ModemManager using QMI doesnt always work in the first attemp.
The problem only occurs if the LE910 was in low power mode (AT+CFUN=4) when plugged to the embbeded device. Does ModemManager manage power state modes? Should it automatically full enable the modem (AT+CFUN=1) when issuing mmcli --simple-connect? I am going to test with a new firmware I have received from Telit and check if the issue is reproducible. On Mon, Jan 18, 2016 at 6:04 PM, Dan Williams wrote: > On Mon, 2016-01-18 at 16:55 +0100, José wrote: > > I was not sure what caused the 'limited' registration state... I am > > going to check if there is any firmware updates available and try > > that. > > > > They all are nanoSIM. Not sure if there is any errors when using > > Movistar and Yoigo SIMs, I will try it out and check the logs as soon > > as I can. > > Yes, some SIMs cannot be read by some modems. > > For example, there is a bug in older Icera-based modems (Nokia 21M-02, > Samsung Y3300 and Y3400, T-Mobile Rocket 2, Option GIO-322) that > refuses to read T-Mobile USA SIMs that have Isis/Softcard mobile wallet > capabilities. Other, non-Isis-branded T-Mobile USA SIMs do not have > this problem. These Icera devices will never receive a firmware update > to fix the problem, so they will remain incompatible forever. > > For the Telit device, your only recourse would be to ask Telit if it is > a known bug, and request an updated firmware to fix the issue. Or use > a different SIM :( > > Dan > ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
