Send connman mailing list submissions to
        [email protected]

To subscribe or unsubscribe 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: Get 4G LTE signaling strength level (Daniel Wagner)
   2. Re: [PATCH] openvpn: Use correct error value in VPN agent credential reply
      (Daniel Wagner)
   3. Re: simpler reproduction of connman error (Daniel Wagner)
   4. Re: How accuracy to get 4G LTE RSSI via connman dbus query?
      (Jonas Bonn)
   5. Re: 4G LTE GPRS Attach error? (Jonas Bonn)
   6. Re: How accuracy to get 4G LTE RSSI via connman dbus query? (JH)
   7. RE: simpler reproduction of connman error (Thomas Green)


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

Date: Mon, 9 Dec 2019 10:30:13 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: Get 4G LTE signaling strength level
To: JH <[email protected]>, connman <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi,

On 2019-12-06 00:15, JH wrote:
> How difference to get 4G LTE signaling strength level from connman
> dbus queries or to use qmicli --nas-get-signal-strength
> --device=/dev/cdc-wdm0? Are there equivalent that the connman dbus
> queries use the same qmicli mechanism? If not, what is the safe or
> preferable way to get 4G LTE signaling strength level?
> 
> Thanks for your insight comments.

As I said in my other email on this topic, ConnMan just passed the value 
from oFono forward. You need to look at the oFono code what is doing 
with the RSSI information. qmicli seems to interact with the modem 
directly so that means you might see a different value.

Thanks,
Daniel

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

Date: Mon, 9 Dec 2019 10:32:52 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH] openvpn: Use correct error value in VPN agent
        credential reply
To: Jussi Laakkonen <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi Jussi,

On 2019-11-21 13:45, Jussi Laakkonen wrote:
> Use the error value set earlier instead of always reporting back EACCES
> to vpn-provider.c:connect_cb().

Almost forgot about this patch. It's applied now.

Thanks,
Daniel

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

Date: Mon, 9 Dec 2019 10:35:13 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: simpler reproduction of connman error
To: Thomas Green <[email protected]>
Cc: connman <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed

Hi Thomas,

On 2019-11-22 01:11, Thomas Green wrote:
> Has anyone in the list been able to look at this?  I’d appreciate some help.

Sorry, I haven't had time to look at it again.

 > You said to also use gdb and give you a stack trace.  Where would you 
like to see the trace from?

Hmm, I need to look at it again. Forgot everything during my holiday.

Thanks,
Daniel

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

Date: Mon, 9 Dec 2019 16:17:15 +0100
From: Jonas Bonn <[email protected]>
Subject: Re: How accuracy to get 4G LTE RSSI via connman dbus query?
To: JH <[email protected]>, connman <[email protected]>
Cc: ofono <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi,

On 09/12/2019 07:50, JH wrote:
> Hi,
> 
> I get 4G LTE RSSI from dbus connman service, I usually got about -61 I 
> thought it was accurate. But today, we are doing a test to check 4G LTE 
> RSSI based on different antennas, when connected to a antenna, the RSSI 
> is about -61, when I did not connect to an antenna, the RSSI = -40 but 
> the 4G LTE connection lost:
> 
> kernel: qmi_wwan 1-1:1.3: nonzero urb status received: -71.

Here your modem has probably crashed, right?

> 
> Apparently that RSSI = -40 was wrong in the situation of without antenna 
> connection. I tried to build qmicli, but I could not get it running. 
> googling Internet, people pointed out, it could not be run if the qmi is 
> running by other services (ofono is running qmi on /dev/cdc-wdm0).
> 
> # qmicli --nas-get-signal-strength --device=/dev/cdc-wdm0
> error: couldn't create client for the 'nas' service: CID allocation 
> failed in the CTL client: Transaction timed out

Just make sure ofono is stopped before running ofono.

# systemctl stop ofono

/Jonas

> 
> Appreciate tips how to get qmicli running.
> 
> Thank you.
> 
> Kind regards,
> 
> - jh
> 
> _______________________________________________
> connman mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> 

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

Date: Mon, 9 Dec 2019 16:21:37 +0100
From: Jonas Bonn <[email protected]>
Subject: Re: 4G LTE GPRS Attach error?
To: JH <[email protected]>, connman <[email protected]>, ofono
        <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed



On 20/11/2019 10:39, JH wrote:
> Sorry missing the subject, I further checked, it is not SIM issue,
> then I am confused, does the 4G LTE is really using the old 2G GRPS?
> 
> Appreciate comments what is that error really means?
> 
> Thank you.
> 
> - jh
> 
> On 11/20/19, JH <[email protected]> wrote:
>> Hi,
>>
>> I have two 4G LTE devices, one can connect to 4G network, one could
>> not and has following error from connman log file:
>>
>> Failed to change property: /ubloxqmi_0/context1
>> org.ofono.ConnectionContext.Active: org.ofono.Error.AttachInProgress
>> GPRS Attach is in progress
>>
>> Does the error indicate the SIM is not activated? Or what could be the
>> problem?

No, quite the opposite.  It pretty much indicates that the SIM is 
activated and it is in the process of connecting to the network.

Don't be confused by the GPRS terminology, there.  I think even for LTE 
you'll get this message while attaching to the default bearer.

Is that the last message in the log?  If yes, I would run with debug 
output and check what's going on in more detail.

/Jonas

>>
>> Thank you.
>>
>> Kind regards,
>>
>> - jh
>>
> _______________________________________________
> ofono mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> 

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

Date: Tue, 10 Dec 2019 09:14:39 +1100
From: JH <[email protected]>
Subject: Re: How accuracy to get 4G LTE RSSI via connman dbus query?
To: Jonas Bonn <[email protected]>
Cc: connman <[email protected]>, ofono <[email protected]>
Message-ID:
        <CAA=hcwtoewoar6gou4egim8xq4mrg7mqfdr2xcqtreigbc9...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

Hi Jonas,

On 12/10/19, Jonas Bonn <[email protected]> wrote:
> Hi,
>
> On 09/12/2019 07:50, JH wrote:
>> Hi,
>>
>> I get 4G LTE RSSI from dbus connman service, I usually got about -61 I
>> thought it was accurate. But today, we are doing a test to check 4G LTE
>> RSSI based on different antennas, when connected to a antenna, the RSSI
>> is about -61, when I did not connect to an antenna, the RSSI = -40 but
>> the 4G LTE connection lost:
>>
>> kernel: qmi_wwan 1-1:1.3: nonzero urb status received: -71.
>
> Here your modem has probably crashed, right?

Right, I lost LTE connection at that time.

>>
>> Apparently that RSSI = -40 was wrong in the situation of without antenna
>> connection. I tried to build qmicli, but I could not get it running.
>> googling Internet, people pointed out, it could not be run if the qmi is
>> running by other services (ofono is running qmi on /dev/cdc-wdm0).
>>
>> # qmicli --nas-get-signal-strength --device=/dev/cdc-wdm0
>> error: couldn't create client for the 'nas' service: CID allocation
>> failed in the CTL client: Transaction timed out
>
> Just make sure ofono is stopped before running ofono.
>
> # systemctl stop ofono

Hmm, that is too difficult to use qmicli, it is not practical to stop
ofono every time. Are there any workarounds without stopping ofono?

Googling internet, followed suggestion to use qmi-proxy, but I still
could not get that work either:

# qmicli -p --nas-get-signal-strength --device=/dev/cdc-wdm0
error: couldn't open the QmiDevice: Couldn't spawn the qmi-proxy

The qmicli seems showing complete different values, but  it did make
sense than the values from connman dbus query:

[/dev/cdc-wdm0] Successfully got signal strength
Current:
        Network 'none': '-128 dBm'
RSSI:
        Network 'none': '-128 dBm'
ECIO:
        Network 'none': '-2.5 dBm'
IO: '-106 dBm'
SINR (8): '9.0 dB'

So RSSI from comman dbus query was false, right?

What is the normal methods you guys to measure the 4G LTE signaling strength?

Thank you very much Jonas,

Kind regards,

- jh

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

Date: Tue, 10 Dec 2019 00:43:59 +0000
From: Thomas Green <[email protected]>
Subject: RE: simpler reproduction of connman error
To: Daniel Wagner <[email protected]>
Cc: connman <[email protected]>
Message-ID:  <[email protected]
        prd04.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"

Thank you for your reply.  I hope you enjoyed your holiday.  I look forward to 
hearing from you again soon,

Tom

-----Original Message-----
From: Daniel Wagner <[email protected]> 
Sent: Monday, December 9, 2019 2:35 AM
To: Thomas Green <[email protected]>
Cc: connman <[email protected]>
Subject: Re: simpler reproduction of connman error

[EXTERNAL] 

Hi Thomas,

On 2019-11-22 01:11, Thomas Green wrote:
> Has anyone in the list been able to look at this?  I'd appreciate some help.

Sorry, I haven't had time to look at it again.

 > You said to also use gdb and give you a stack trace.  Where would you like 
 > to see the trace from?

Hmm, I need to look at it again. Forgot everything during my holiday.

Thanks,
Daniel

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

Subject: Digest Footer

_______________________________________________
connman mailing list -- [email protected]
To unsubscribe send an email to [email protected]


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

End of connman Digest, Vol 50, Issue 3
**************************************

Reply via email to