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: Raspberry Pi 3 stretch connman V1.33 no p2p (Jose Blanquicet)
   2. Re: Raspberry Pi 3 stretch connman V1.33 no p2p (Carl D. Blake)
   3. Re: Raspberry Pi 3 stretch connman V1.33 no p2p (Jose Blanquicet)
   4. Re: Raspberry Pi 3 stretch connman V1.33 no p2p (Carl D. Blake)
   5. Re: Raspberry Pi 3 stretch connman V1.33 no p2p (Carl D. Blake)
   6. Re: Raspberry Pi 3 stretch connman V1.33 no p2p (Jose Blanquicet)
   7. Re: When BackgroundScanning = false, connman's Scan() dbus
      method is broken (Jonah Petri)


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

Message: 1
Date: Wed, 23 Aug 2017 21:18:29 +0200
From: Jose Blanquicet <[email protected]>
To: "Carl D. Blake" <[email protected]>
Cc: [email protected]
Subject: Re: Raspberry Pi 3 stretch connman V1.33 no p2p
Message-ID:
        <cafc8ijkk1okzb5naevxupc_tmoxqvjymr+b45zltuo_9vjk...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

Hi Carl,

On Wed, Aug 23, 2017 at 7:37 PM, Carl D. Blake
<[email protected]> wrote:
> I'm using a Raspberry Pi 3 with the stretch distribution.  Connman is at
> V1.33 and wpa_supplicant is at V2.4.  connmanctl technologies does not
> show p2p.  However iw list shows p2p go and p2p client support and I can
> run wpa_cli and do a p2p_find command which shows p2p available devices.

Well, that's strange.

> Does anybody know what's going on here?  Why won't connmanctl
> technologies show p2p?

Let's start from the very first checks. First of all, make sure wifi
technology is enabled, if it is disabled then any WiFi activity is
denied on your system and P2P is part of them. Therefore, ConnMan will
not even show you P2P as technology.

Now, if that was not the reason, let's check if wpa_supplicant is
correctly notifying ConnMan about the capabilities supported by your
system:

1. Check wpa_supplicant global capabilities by executing D-Bus call:
dbus-send --system --print-reply --dest=fi.w1.wpa_supplicant1
/fi/w1/wpa_supplicant1 org.freedesktop.DBus.Properties.GetAll
string:"fi.w1.wpa_supplicant1"
You should see something like:
    [...]
    dict entry(
     string "Capabilities"
     variant             array [
           [...]
           string "p2p"
        ]
    )
    [...]

2. Check per interface capabilities. Change X with the value(s) you
got in (1) into "Interfaces" property.
dbus-send --system --print-reply --dest=fi.w1.wpa_supplicant1
/fi/w1/wpa_supplicant1/Interfaces/{X}
org.freedesktop.DBus.Properties.GetAll
string:"fi.w1.wpa_supplicant1.Interface"
Here, look for "Modes" property, you should see something like:
    [...]
    dict entry(
      string "Modes"
      variant                      array [
            [...]
            string "p2p"
         ]
    )
    [...]

For me those are the very first checks you should do, nothing else
comes to my mind for now. If everything is on point, we will probably
ask you to send us your ConnMan's logs with CONNMAN_SUPPLICANT_DEBUG
enabled to try to understand what is going on.

I hope this help you.

Best regards,

Jose Blanquicet


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

Message: 2
Date: Wed, 23 Aug 2017 13:08:47 -0700
From: "Carl D. Blake" <[email protected]>
To: Jose Blanquicet <[email protected]>
Cc: [email protected]
Subject: Re: Raspberry Pi 3 stretch connman V1.33 no p2p
Message-ID: <1503518927.26575.354.camel@ironhills>
Content-Type: text/plain; charset="UTF-8"

Hi Jose,

On Wed, 2017-08-23 at 21:18 +0200, Jose Blanquicet wrote:
> Hi Carl,
> 
> On Wed, Aug 23, 2017 at 7:37 PM, Carl D. Blake
> <[email protected]> wrote:
> > I'm using a Raspberry Pi 3 with the stretch distribution.  Connman is at
> > V1.33 and wpa_supplicant is at V2.4.  connmanctl technologies does not
> > show p2p.  However iw list shows p2p go and p2p client support and I can
> > run wpa_cli and do a p2p_find command which shows p2p available devices.
> 
> Well, that's strange.
> 
> > Does anybody know what's going on here?  Why won't connmanctl
> > technologies show p2p?
> 
> Let's start from the very first checks. First of all, make sure wifi
> technology is enabled, if it is disabled then any WiFi activity is
> denied on your system and P2P is part of them. Therefore, ConnMan will
> not even show you P2P as technology.

The command:
    connmanctl technologies
gives the following result:

/net/connman/technology/bluetooth
  Name = Bluetooth
  Type = bluetooth
  Powered = False
  Connected = False
  Tethering = False
/net/connman/technology/wifi
  Name = WiFi
  Type = wifi
  Powered = True
  Connected = False
  Tethering = False

> 
> Now, if that was not the reason, let's check if wpa_supplicant is
> correctly notifying ConnMan about the capabilities supported by your
> system:
> 
> 1. Check wpa_supplicant global capabilities by executing D-Bus call:
> dbus-send --system --print-reply --dest=fi.w1.wpa_supplicant1
> /fi/w1/wpa_supplicant1 org.freedesktop.DBus.Properties.GetAll
> string:"fi.w1.wpa_supplicant1"
> You should see something like:
>     [...]
>     dict entry(
>      string "Capabilities"
>      variant             array [
>            [...]
>            string "p2p"
>         ]
>     )
>     [...]
> 

This command shows string "p2p" in the "Capabilities" just as you
showed.

> 2. Check per interface capabilities. Change X with the value(s) you
> got in (1) into "Interfaces" property.
> dbus-send --system --print-reply --dest=fi.w1.wpa_supplicant1
> /fi/w1/wpa_supplicant1/Interfaces/{X}
> org.freedesktop.DBus.Properties.GetAll
> string:"fi.w1.wpa_supplicant1.Interface"
> Here, look for "Modes" property, you should see something like:
>     [...]
>     dict entry(
>       string "Modes"
>       variant                      array [
>             [...]
>             string "p2p"
>          ]
>     )
>     [...]
> 

I assume with this command that you want me to run this on each
interface as listed in the dict entry( string "Interfaces".
Unfortunately, there are no interfaces listed in this dict entry.  It
shows:
      dict entry(
         string "Interfaces"
         variant             array [
            ]
      )

Thoughts?  Thank you for your detailed help.

> For me those are the very first checks you should do, nothing else
> comes to my mind for now. If everything is on point, we will probably
> ask you to send us your ConnMan's logs with CONNMAN_SUPPLICANT_DEBUG
> enabled to try to understand what is going on.
> 
> I hope this help you.
> 
> Best regards,
> 
> Jose Blanquicet




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

Message: 3
Date: Wed, 23 Aug 2017 22:38:58 +0200
From: Jose Blanquicet <[email protected]>
To: "Carl D. Blake" <[email protected]>
Cc: [email protected]
Subject: Re: Raspberry Pi 3 stretch connman V1.33 no p2p
Message-ID:
        <CAFC8iJJ48H59z2fNQfr6Fk96fypvyxZ1Wk2B-kPis=guqob...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

Hi Carl,

On Wed, Aug 23, 2017 at 10:08 PM, Carl D. Blake
<[email protected]> wrote:
> I assume with this command that you want me to run this on each
> interface as listed in the dict entry( string "Interfaces".
> Unfortunately, there are no interfaces listed in this dict entry.  It
> shows:
>       dict entry(
>          string "Interfaces"
>          variant             array [
>             ]
>       )
>
> Thoughts?  Thank you for your detailed help.

That's a problem. Are you even able to perform a wifi scan?

I think the problem here could be your wpa_supplicant configuration.
Check you are compiling wpa_supplicant with
CONFIG_CTRL_IFACE_DBUS_NEW=y and you are adding "-u" option when you
are launching it in order to enable DBus control interface.

Further details are given in "wpa_supplicant configuration" section of
ConnMan's README file.

Best regards,

Jose Blanquicet


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

Message: 4
Date: Wed, 23 Aug 2017 14:23:11 -0700
From: "Carl D. Blake" <[email protected]>
To: Jose Blanquicet <[email protected]>
Cc: [email protected]
Subject: Re: Raspberry Pi 3 stretch connman V1.33 no p2p
Message-ID: <1503523391.26575.358.camel@ironhills>
Content-Type: text/plain; charset="UTF-8"

Hi Jose,

On Wed, 2017-08-23 at 22:38 +0200, Jose Blanquicet wrote:
> Hi Carl,
> 
> On Wed, Aug 23, 2017 at 10:08 PM, Carl D. Blake
> <[email protected]> wrote:
> > I assume with this command that you want me to run this on each
> > interface as listed in the dict entry( string "Interfaces".
> > Unfortunately, there are no interfaces listed in this dict entry.  It
> > shows:
> >       dict entry(
> >          string "Interfaces"
> >          variant             array [
> >             ]
> >       )
> >
> > Thoughts?  Thank you for your detailed help.
> 
> That's a problem. Are you even able to perform a wifi scan?
> 

No I can't do a wifi scan.  The command:
    connmanctl scan wifi
returns 
    Error /net/connman/technology/wifi: No carrier

> I think the problem here could be your wpa_supplicant configuration.
> Check you are compiling wpa_supplicant with
> CONFIG_CTRL_IFACE_DBUS_NEW=y and you are adding "-u" option when you
> are launching it in order to enable DBus control interface.
> 

When I check what's running as wpa_supplicant I see 2 instances.  One
has the flag -u.  The other just has the flag -B.  Looking through the
logs leads me to believe that dhcpcd is running wpa_supplicant with -B
and no -u flag.  I'm checking further.

> Further details are given in "wpa_supplicant configuration" section of
> ConnMan's README file.
> 
> Best regards,
> 
> Jose Blanquicet




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

Message: 5
Date: Wed, 23 Aug 2017 14:45:32 -0700
From: "Carl D. Blake" <[email protected]>
To: Jose Blanquicet <[email protected]>
Cc: [email protected]
Subject: Re: Raspberry Pi 3 stretch connman V1.33 no p2p
Message-ID: <1503524732.26575.362.camel@ironhills>
Content-Type: text/plain; charset="UTF-8"

Hi Jose,

On Wed, 2017-08-23 at 14:23 -0700, Carl D. Blake wrote:
> Hi Jose,
> 
> On Wed, 2017-08-23 at 22:38 +0200, Jose Blanquicet wrote:
> > Hi Carl,
> > 
> > On Wed, Aug 23, 2017 at 10:08 PM, Carl D. Blake
> > <[email protected]> wrote:
> > > I assume with this command that you want me to run this on each
> > > interface as listed in the dict entry( string "Interfaces".
> > > Unfortunately, there are no interfaces listed in this dict entry.  It
> > > shows:
> > >       dict entry(
> > >          string "Interfaces"
> > >          variant             array [
> > >             ]
> > >       )
> > >
> > > Thoughts?  Thank you for your detailed help.
> > 
> > That's a problem. Are you even able to perform a wifi scan?
> > 
> 
> No I can't do a wifi scan.  The command:
>     connmanctl scan wifi
> returns 
>     Error /net/connman/technology/wifi: No carrier
> 
> > I think the problem here could be your wpa_supplicant configuration.
> > Check you are compiling wpa_supplicant with
> > CONFIG_CTRL_IFACE_DBUS_NEW=y and you are adding "-u" option when you
> > are launching it in order to enable DBus control interface.
> > 
> 
> When I check what's running as wpa_supplicant I see 2 instances.  One
> has the flag -u.  The other just has the flag -B.  Looking through the
> logs leads me to believe that dhcpcd is running wpa_supplicant with -B
> and no -u flag.  I'm checking further.
> 

That was it.  dhcpcd had a /lib/dhcpcd/dhcpcd-hooks/10-wpa_supplicant
script which was running wpa_supplicant without -u.  I added the -u flag
to the command line and rebooted.  Now connman sees p2p as a technology,
I can scan wifi without errors, and I can make a p2p connection.

Hurray.  Thank you for your help.

> > Further details are given in "wpa_supplicant configuration" section of
> > ConnMan's README file.
> > 
> > Best regards,
> > 
> > Jose Blanquicet
> 
> 
> _______________________________________________
> connman mailing list
> [email protected]
> https://lists.01.org/mailman/listinfo/connman




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

Message: 6
Date: Thu, 24 Aug 2017 06:35:29 +0000
From: Jose Blanquicet <[email protected]>
To: "Carl D. Blake" <[email protected]>
Cc: [email protected]
Subject: Re: Raspberry Pi 3 stretch connman V1.33 no p2p
Message-ID:
        <cafc8ijjhl2nbtqxas2qjndqvt3astqjdcqch-ktmx3ao6mb...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

Good morning Carl,

On Wed, Aug 23, 2017 at 9:45 PM, Carl D. Blake
<[email protected]> wrote:
>> > I think the problem here could be your wpa_supplicant configuration.
>> > Check you are compiling wpa_supplicant with
>> > CONFIG_CTRL_IFACE_DBUS_NEW=y and you are adding "-u" option when you
>> > are launching it in order to enable DBus control interface.
>> >

I will ask to add this to the documentation.

>> When I check what's running as wpa_supplicant I see 2 instances.  One
>> has the flag -u.  The other just has the flag -B.  Looking through the
>> logs leads me to believe that dhcpcd is running wpa_supplicant with -B
>> and no -u flag.  I'm checking further.
>>
>
> That was it.  dhcpcd had a /lib/dhcpcd/dhcpcd-hooks/10-wpa_supplicant
> script which was running wpa_supplicant without -u.  I added the -u flag
> to the command line and rebooted.

If you are managing all your connections from ConnMan, you do not need
additional DHCP daemons. On the contrary, I would suggest you to not
lunch them or even better remove them from your system to save
resources. Moreover, if you do not need any particular configuration
for wpa_supplicat, you will not need an additional script to launch
it, ConnMan could take care of this, see README for further details.

> Now connman sees p2p as a technology,
> I can scan wifi without errors, and I can make a p2p connection.

Great. We have been working on P2P from a while but it is still
experimental so do not hesitate to share your suggestions,
improvements or report your issues if you have any.

> Hurray.  Thank you for your help.

You are welcome.

Best regards,

Jose Blanquicet


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

Message: 7
Date: Thu, 24 Aug 2017 13:33:25 -0400
From: Jonah Petri <[email protected]>
To: Jose Blanquicet <[email protected]>
Cc: Daniel Wagner <[email protected]>, Sam Nazarko
        <[email protected]>, [email protected]
Subject: Re: When BackgroundScanning = false, connman's Scan() dbus
        method is broken
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8

Hi Jose,

> On Aug 17, 2017, at 2:37 AM, Jose Blanquicet <[email protected]> wrote:
> 
> >> My 2?: If "Active" scanning will indeed only return results for the SSIDs
> >> mentioned in the scan parameters, then I think ConnMan should *always*
> >> schedule a passive scan afterwards, perhaps by just calling
> >> wifi_scan_simple() in the scan_callback() of an active scan.
> >>
> >> Thoughts?
> >
> > That sounds reasonable. You should just take into account the timing, you
> > cannot immediately ask wpa_supplicant for another scan because it could just
> > be discarded due to there is another ongoing. That second passive scan needs
> > to be done once you are sure the active scan has finished. You could try to
> > implement this, I will think if this is the best we can do. Then we can test
> > and discuss the options.
> 
> I was thinking and maybe this is not the best way to solve this issue.
> 
> The active scan is useful in order to perform a fast scan looking for the 
> WiFi networks we have got connected in the past. I think this is particularly 
> helpful to speed up auto-connect procedure at the start-up of the system. 
> Instead, when user asks for scanning I think it should always be a passive 
> scan because users want to see all WiFi networks available in range. 
> Therefore, I propose to make ConnMan ask wpa_supplicant for an active scan 
> only at star-up of the system and passive scan when it is directly asked from 
> users through a Technology.Scan() D-Bus call. Both things no matter 
> BackgroundScanning's value.
> 
> What do all you think?
> 

(Now it was my turn to be on vacation! Sorry for the delay.)

Great idea.  This is fine for my use case, and the behavior you propose is what 
I expected given what Technology.Scan() claims to do.

Jonah



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

Subject: Digest Footer

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


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

End of connman Digest, Vol 22, Issue 17
***************************************

Reply via email to