Send connman mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.01.org/mailman/listinfo/connman
or, via email, send a message with subject or body 'help' to
        [email protected]

You can reach the person managing the list at
        [email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."


Today's Topics:

   1. Re: Race condition on too fast stop&&start resulting in Error
      /net/connman/technology/wifi: Not supported that does not
      recovery without another restart (Wawrzek Niewodniczanski)
   2. [PATCH] rtnl: Allow watch callback to remove itself (Slava Monich)
   3. Re: Unsalble cellular connection (JH)
   4. Re: Unsalble cellular connection (Jonas Bonn)
   5. Re: Race condition on too fast stop&&start resulting in Error
      /net/connman/technology/wifi: Not supported that does not
      recovery without another restart (Daniel Wagner)
   6. Re: [PATCH] rtnl: Allow watch callback to remove itself
      (Daniel Wagner)


----------------------------------------------------------------------

Message: 1
Date: Sun, 18 Aug 2019 23:52:49 +0100
From: Wawrzek Niewodniczanski <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: KARBOWSKI Piotr <[email protected]>,
        "[email protected]" <[email protected]>
Subject: Re: Race condition on too fast stop&&start resulting in Error
        /net/connman/technology/wifi: Not supported that does not recovery
        without another restart
Message-ID:
        <CAC7-vpBuq7hTTtjAPONZjO26=hzt6mukzyxupkqfcxhyt5z...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

On Fri, 28 Jun 2019 at 11:38, Daniel Wagner <[email protected]> wrote:

[...]
> Thanks for your report. I'll try to reproduce it and address it if
> possible. wpa_supplicant and ConnMan is a difficult topic :).

What would you suggest as a replacement for wpa_supplicant? Asking
because I have my one problem with patch wifi and not sure where is
the problem (hardware, linux drivers, wpa_supplicant or connaman).

Wawrzek
-- 
Dr  Wawrzyniec Niewodnicza?ski    or Wawrzek for short
  PhD in Quantum Chemistry  & MSc in Molecular Engineering
   WWW: http://wawrzek.name E-MAIL: [email protected]
      Linux User #177124


------------------------------

Message: 2
Date: Mon, 19 Aug 2019 02:28:30 +0300
From: Slava Monich <[email protected]>
To: [email protected]
Subject: [PATCH] rtnl: Allow watch callback to remove itself
Message-ID: <[email protected]>

---
 src/rtnl.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/src/rtnl.c b/src/rtnl.c
index cba5ef7..dfe6bb6 100644
--- a/src/rtnl.c
+++ b/src/rtnl.c
@@ -494,14 +494,15 @@ static void process_newlink(unsigned short type, int 
index, unsigned flags,
                __connman_technology_add_interface(interface->service_type,
                        interface->index, interface->ident);
 
-       for (list = watch_list; list; list = list->next) {
+       list = watch_list;
+       while (list) {
+               GSList *next = list->next;
                struct watch_data *watch = list->data;
 
-               if (watch->index != index)
-                       continue;
-
-               if (watch->newlink)
+               if (watch->index == index && watch->newlink)
                        watch->newlink(flags, change, watch->user_data);
+
+               list = next;
        }
 }
 
-- 
1.9.1



------------------------------

Message: 3
Date: Mon, 19 Aug 2019 11:51:44 +1000
From: JH <[email protected]>
To: Michael Nazzareno Trimarchi <[email protected]>
Cc: Jonas Bonn <[email protected]>, connman <[email protected]>,
        Giacinto Cifelli <[email protected]>, Daniel Wagner <[email protected]>,
        "[email protected]" <[email protected]>
Subject: Re: Unsalble cellular connection
Message-ID:
        <CAA=hcwqm56r-fa_wr1haxkjfymnewntnnagcybnzbvc-y7g...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

Hi  Michael,

On 8/18/19, Michael Nazzareno Trimarchi <[email protected]> wrote:
> Aug 17 11:32:44 solar kernel: usb 1-1: new high-speed USB device
> number 5 using ci_hdrc
> Aug 17 11:32:45 solar kernel: usb 1-1: New USB device found,
> idVendor=05c6, idProduct=90b2, bcdDevice= 0.00
> Aug 17 11:32:45 solar kernel: usb 1-1: New USB device strings: Mfr=1,
> Product=2, SerialNumber=3
> Aug 17 11:32:45 solar kernel: usb 1-1: Product: QHSUSB__BULK
> Aug 17 11:32:45 solar kernel: usb 1-1: Manufacturer: Qualcomm CDMA
> Technologies MSM
> Aug 17 11:32:45 solar kernel: usb 1-1: SerialNumber: 5ff10299
>
> Here seems that reboot in bootloader mode. I have couple of disconnect
> and reconnect and I don't know if connman
> send some power on/off at command and make this strange behavior. The
> fact that start in bootloader mode can be a power
> issue? can you try to connect using a powered HUB?

I did a couple of restarting ofonod and connmand during the debug, one
or two times power recycling manually, not clear if it was me to cause
those reboot or not.

Like Daniel said, it was unlikely that connman would run reboot, it
might just record some messages from kernel.

Just talked to the hardware engineer, he said who is very concerning
we are using kernel 5.1.0, he said we should use kernel 4.9.123, could
the kernel 5.1.0 cause that issue? Jonas what is your comments?

Let me further clarify it, the issue did not occur very often, it
occurred randomly between hours to many days, that is a big worry, LTE
should be 100% stable.

Thank you.

Kind regards,

- jh


------------------------------

Message: 4
Date: Mon, 19 Aug 2019 07:38:29 +0200
From: Jonas Bonn <[email protected]>
To: JH <[email protected]>, Michael Nazzareno Trimarchi
        <[email protected]>
Cc: connman <[email protected]>, Giacinto Cifelli
        <[email protected]>, Daniel Wagner <[email protected]>,
        "[email protected]" <[email protected]>
Subject: Re: Unsalble cellular connection
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi JH,

On 19/08/2019 03:51, JH wrote:
> Hi  Michael,
> 
> On 8/18/19, Michael Nazzareno Trimarchi <[email protected]> wrote:
>> Aug 17 11:32:44 solar kernel: usb 1-1: new high-speed USB device
>> number 5 using ci_hdrc
>> Aug 17 11:32:45 solar kernel: usb 1-1: New USB device found,
>> idVendor=05c6, idProduct=90b2, bcdDevice= 0.00
>> Aug 17 11:32:45 solar kernel: usb 1-1: New USB device strings: Mfr=1,
>> Product=2, SerialNumber=3
>> Aug 17 11:32:45 solar kernel: usb 1-1: Product: QHSUSB__BULK
>> Aug 17 11:32:45 solar kernel: usb 1-1: Manufacturer: Qualcomm CDMA
>> Technologies MSM
>> Aug 17 11:32:45 solar kernel: usb 1-1: SerialNumber: 5ff10299
>>
>> Here seems that reboot in bootloader mode. I have couple of disconnect
>> and reconnect and I don't know if connman
>> send some power on/off at command and make this strange behavior. The
>> fact that start in bootloader mode can be a power
>> issue? can you try to connect using a powered HUB?
> 
> I did a couple of restarting ofonod and connmand during the debug, one
> or two times power recycling manually, not clear if it was me to cause
> those reboot or not.
> 
> Like Daniel said, it was unlikely that connman would run reboot, it
> might just record some messages from kernel.

Neither connman nor ofono are currently capable of rebooting the modem.

> 
> Just talked to the hardware engineer, he said who is very concerning
> we are using kernel 5.1.0, he said we should use kernel 4.9.123, could
> the kernel 5.1.0 cause that issue? Jonas what is your comments?

I find the advice rather concerning!  Hope you're not getting investment 
advice from this guy, too...

The kernel log has this:

Aug 17 08:51:46 solar kernel: usb 1-1: USB disconnect, device number 3
Aug 17 08:51:46 solar kernel: option1 ttyUSB0: GSM modem (1-port) 
converter now disconnected from ttyUSB0
Aug 17 08:51:46 solar kernel: option 1-1:1.0: device disconnected
Aug 17 08:51:46 solar kernel: option1 ttyUSB1: GSM modem (1-port) 
converter now disconnected from ttyUSB1
Aug 17 08:51:46 solar kernel: option 1-1:1.2: device disconnected
Aug 17 08:51:46 solar kernel: qmi_wwan 1-1:1.3: nonzero urb status 
received: -71

That's a USB communication failure!

Aug 17 08:51:46 solar kernel: qmi_wwan 1-1:1.3: wdm_int_callback - 0 bytes
Aug 17 08:51:46 solar kernel: qmi_wwan 1-1:1.3: wdm_int_callback - 
usb_submit_urb failed with result -19
Aug 17 08:51:46 solar kernel: qmi_wwan 1-1:1.3 wwan0: unregister 
'qmi_wwan' usb-ci_hdrc.1-1, WWAN/QMI device

Below, the device (modem) is reenumerated, which would indicate to me 
that it has restarted.  I don't think the kernel automatically sends a 
reset to a device on comm failures...???  This explains the 
communication failure, at least.

Aug 17 08:51:49 solar kernel: usb 1-1: new high-speed USB device number 
4 using ci_hdrc
Aug 17 08:51:50 solar kernel: usb 1-1: New USB device found, 
idVendor=05c6, idProduct=90b2, bcdDevice= 0.00
Aug 17 08:51:50 solar kernel: usb 1-1: New USB device strings: Mfr=3, 
Product=2, SerialNumber=4
Aug 17 08:51:50 solar kernel: usb 1-1: Product: Qualcomm CDMA 
Technologies MSM
Aug 17 08:51:50 solar kernel: usb 1-1: Manufacturer: Qualcomm, Incorporated
Aug 17 08:51:50 solar kernel: usb 1-1: SerialNumber: 5ff10299
Aug 17 08:51:50 solar kernel: option 1-1:1.0: GSM modem (1-port) 
converter detected
Aug 17 08:51:50 solar kernel: usb 1-1: GSM modem (1-port) converter now 
attached to ttyUSB0
Aug 17 08:51:50 solar kernel: option 1-1:1.2: GSM modem (1-port) 
converter detected
Aug 17 08:51:50 solar kernel: usb 1-1: GSM modem (1-port) converter now 
attached to ttyUSB1
Aug 17 08:51:50 solar kernel: qmi_wwan 1-1:1.3: cdc-wdm0: USB WDM device
Aug 17 08:51:50 solar kernel: qmi_wwan 1-1:1.3 wwan0: register 
'qmi_wwan' at usb-ci_hdrc.1-1, WWAN/QMI device, f6:0d:90:fa:af:24

ofono should _definitely_ show this device reenumeration in its logs. 
Why is that not there???

-----------------------

Subsequently, the kernel log shows:

Aug 17 11:32:43 solar kernel: usb 1-1: USB disconnect, device number 4
Aug 17 11:32:43 solar kernel: option1 ttyUSB0: GSM modem (1-port) 
converter now disconnected from ttyUSB0
Aug 17 11:32:43 solar kernel: option 1-1:1.0: device disconnected
Aug 17 11:32:43 solar kernel: option1 ttyUSB1: GSM modem (1-port) 
converter now disconnected from ttyUSB1
Aug 17 11:32:43 solar kernel: option 1-1:1.2: device disconnected
Aug 17 11:32:44 solar kernel: qmi_wwan 1-1:1.3: nonzero urb status 
received: -71

Again, comm error.

Aug 17 11:32:44 solar kernel: qmi_wwan 1-1:1.3: wdm_int_callback - 0 bytes
Aug 17 11:32:44 solar kernel: qmi_wwan 1-1:1.3: wdm_int_callback - 
usb_submit_urb failed with result -19
Aug 17 11:32:44 solar kernel: qmi_wwan 1-1:1.3 wwan0: unregister 
'qmi_wwan' usb-ci_hdrc.1-1, WWAN/QMI device

Modem has rebooted and is reenumerated below.

Aug 17 11:32:44 solar kernel: usb 1-1: new high-speed USB device number 
5 using ci_hdrc
Aug 17 11:32:45 solar kernel: usb 1-1: New USB device found, 
idVendor=05c6, idProduct=90b2, bcdDevice= 0.00
Aug 17 11:32:45 solar kernel: usb 1-1: New USB device strings: Mfr=1, 
Product=2, SerialNumber=3
Aug 17 11:32:45 solar kernel: usb 1-1: Product: QHSUSB__BULK
Aug 17 11:32:45 solar kernel: usb 1-1: Manufacturer: Qualcomm CDMA 
Technologies MSM
Aug 17 11:32:45 solar kernel: usb 1-1: SerialNumber: 5ff10299
Aug 17 11:32:45 solar kernel: option 1-1:1.0: GSM modem (1-port) 
converter detected
Aug 17 11:32:45 solar kernel: usb 1-1: GSM modem (1-port) converter now 
attached to ttyUSB0

Here, however, the modem isn't booting up into normal operational state, 
but rather into some other configuration that, presumably, is intended 
for doing device firmware updates...

So you have a couple of things to figure out:
i)  Why is the modem restarting (crashing) spontaneously?
ii) What are the conditions for entering the bootloader/firmware update 
state?  How are you managing to meet these conditions?
iii)  Why is ofono not showing the device reenumeration... it should, 
and it should show the modem being taken down and brought back up again. 
  (I suspect it's just a matter of your logs being out of sync... it's 
probably there if you look, again).

> 
> Let me further clarify it, the issue did not occur very often, it
> occurred randomly between hours to many days, that is a big worry, LTE
> should be 100% stable.

The issue doesn't seem to have anything to do with the radio link.  The 
LTE is probably stable; the issue lies elsewhere.

/Jonas

> 
> Thank you.
> 
> Kind regards,
> 
> - jh
> 


------------------------------

Message: 5
Date: Mon, 19 Aug 2019 08:55:56 +0200
From: Daniel Wagner <[email protected]>
To: Wawrzek Niewodniczanski <[email protected]>
Cc: KARBOWSKI Piotr <[email protected]>,
        "[email protected]" <[email protected]>
Subject: Re: Race condition on too fast stop&&start resulting in Error
        /net/connman/technology/wifi: Not supported that does not recovery
        without another restart
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed

On 8/19/19 12:52 AM, Wawrzek Niewodniczanski wrote:
> On Fri, 28 Jun 2019 at 11:38, Daniel Wagner <[email protected]> wrote:
> 
> [...]
>> Thanks for your report. I'll try to reproduce it and address it if
>> possible. wpa_supplicant and ConnMan is a difficult topic :).
> 
> What would you suggest as a replacement for wpa_supplicant? Asking
> because I have my one problem with patch wifi and not sure where is
> the problem (hardware, linux drivers, wpa_supplicant or connaman).

iwd [1][2] is a replacement for wpa_supplicant. Though, the current 
plugin in ConnMan to communicate with iwd needs to be updated. It's on 
my todo list but I need time to do so, which is the biggest problem. So 
if someone else has time on his hand, please help out.

In other words, with wpa_supplicant you get more features and better 
integrated into ConnMan but has a few nasty bugs, difficult to fix. 
While with iwd you get a cleaner technical solution but someone needs to 
add missing features (or cleanups).

HTH!

Thanks,
Daniel


[1] https://git.kernel.org/pub/scm/network/wireless/iwd.git/
[2] https://www.youtube.com/watch?v=QIqT2obSPDk


------------------------------

Message: 6
Date: Mon, 19 Aug 2019 08:59:58 +0200
From: Daniel Wagner <[email protected]>
To: Slava Monich <[email protected]>, [email protected]
Subject: Re: [PATCH] rtnl: Allow watch callback to remove itself
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi Slava,

On 8/19/19 1:28 AM, Slava Monich wrote:
> ---
>   src/rtnl.c | 11 ++++++-----
>   1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/src/rtnl.c b/src/rtnl.c
> index cba5ef7..dfe6bb6 100644
> --- a/src/rtnl.c
> +++ b/src/rtnl.c
> @@ -494,14 +494,15 @@ static void process_newlink(unsigned short type, int 
> index, unsigned flags,
>               __connman_technology_add_interface(interface->service_type,
>                       interface->index, interface->ident);
>   
> -     for (list = watch_list; list; list = list->next) {
> +     list = watch_list;
> +     while (list) {
> +             GSList *next = list->next;
>               struct watch_data *watch = list->data;
>   
> -             if (watch->index != index)
> -                     continue;
> -
> -             if (watch->newlink)
> +             if (watch->index == index && watch->newlink)
>                       watch->newlink(flags, change, watch->user_data);
> +
> +             list = next;
>       }

Patch applied.

Thanks,
Daniel


------------------------------

Subject: Digest Footer

_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman


------------------------------

End of connman Digest, Vol 46, Issue 18
***************************************

Reply via email to