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: Connman Error wifi: Operation not permitted [HELP please]
(Daniel Wagner)
2. Re: Connman Error wifi: Operation not permitted [HELP please]
(Jared Harvey)
3. Re: [PATCH] technology: Deny P2P finding if technology is
disabled (Jose Blanquicet)
4. Re: Connman Error wifi: Operation not permitted [HELP please]
(Daniel Wagner)
5. Re: [PATCH] technology: Deny P2P finding if technology is
disabled (Daniel Wagner)
6. Re: [PATCH 0/5] Avoid to keep service in list if AP is not
found during scan (Daniel Wagner)
7. Re: [PATCH] technology: Deny P2P finding if technology is
disabled (Jose Blanquicet)
----------------------------------------------------------------------
Message: 1
Date: Sun, 12 Mar 2017 22:24:48 +0100
From: Daniel Wagner <[email protected]>
To: Jared Harvey <[email protected]>
Cc: [email protected]
Subject: Re: Connman Error wifi: Operation not permitted [HELP please]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
On 03/12/2017 10:11 PM, Jared Harvey wrote:
> Looks like this "action 18" happens repeatedly if I repeatedly try to
> enable the wifi.
>
> machinekit@beaglebone:~$ date
> Sun Mar 12 21:08:45 UTC 2017
> machinekit@beaglebone:~$ sudo connmanctl enable wifi
> Error wifi: Operation not permitted
> machinekit@beaglebone:~$ tail /var/log/messages
> Mar 12 20:45:55 beaglebone kernel: [ 341.732483] [<c003086b>]
> (warn_slowpath_common+0x3f/0x4c) from [<c0030895>]
> (warn_slowpath_fmt+0x1d/0x28)
> Mar 12 20:45:55 beaglebone kernel: [ 341.732533] [<c0030895>]
> (warn_slowpath_fmt+0x1d/0x28) from [<c032b6a3>] (usb_submit_urb+0x1cb/0x398)
> Mar 12 20:45:55 beaglebone kernel: [ 341.732964] [<c032b6a3>]
> (usb_submit_urb+0x1cb/0x398) from [<bf86b7ab>]
> (BulkInCmdRspEvent+0x42/0x68 [mt7601Usta])
> Mar 12 20:45:55 beaglebone kernel: [ 341.733377] [<bf86b7ab>]
> (BulkInCmdRspEvent+0x42/0x68 [mt7601Usta]) from [<bf86b8cd>]
> (RTUSBBulkCmdRspEventReceive+0x3 8/0x58 [mt7601Usta])
> Mar 12 20:45:55 beaglebone kernel: [ 341.733930] [<bf86b8cd>]
> (RTUSBBulkCmdRspEventReceive+0x38/0x58 [mt7601Usta]) from [<bf84dabf>]
> (NICInitializeAsic+0xe a/0x3c0 [mt7601Usta])
> Mar 12 20:45:55 beaglebone kernel: [ 341.734137] [<bf84dabf>]
> (NICInitializeAsic+0xea/0x3c0 [mt7601Usta]) from [<e0d8a000>] (0xe0d8a000)
> Mar 12 20:45:55 beaglebone kernel: [ 341.734166] ---[ end trace
> ca65cef3a8e7dd7f ]---
> Mar 12 20:55:25 beaglebone rsyslogd-2007: action 'action 18' suspended,
> next retry is Sun Mar 12 20:55:55 2017 [try http://www.rsyslog.com/e/2007 ]
> Mar 12 21:07:22 beaglebone rsyslogd-2007: action 'action 18' suspended,
> next retry is Sun Mar 12 21:07:52 2017 [try http://www.rsyslog.com/e/2007 ]
> Mar 12 21:08:30 beaglebone rsyslogd-2007: action 'action 18' suspended,
> next retry is Sun Mar 12 21:09:00 2017 [try http://www.rsyslog.com/e/2007 ]
> machinekit@beaglebone:~$
From your report it really looks like your hardware is not really
supported by the kernel. Do you happen to have different USB WiFi dongle
to test? Another option is to ask corresponding kernel mailing list what
the trace means.
------------------------------
Message: 2
Date: Sun, 12 Mar 2017 17:45:34 -0400
From: Jared Harvey <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Subject: Re: Connman Error wifi: Operation not permitted [HELP please]
Message-ID:
<caa1dxcx2kmwknsvj5cxy7oemrydahjpkmcun8wgdg5on5qe...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I had installed the driver from official sources, using aptitude I
installed mt7601u-modules-3.8.13-bone83 so I was hoping it was a proper
driver. I used uname -A to determine I needed bone83.
I have a DWA-121 USB wifi module coming this week. With some luck it will
work out better than this one. It's listed on the BBB's wiki as a supported
device. The UWN100 that I have is listed on that same wiki page but is
listed more as a side comment than on the official list. I guess hopefully
this one will have better support.
Best regards.
.. ..-. / -.-- --- ..- / .-. . .- -.. / - .... .. ...
.-.. . - ... / .... .- ...- . / .- / -... . . .-.
Jared Harvey Operator KB1GTT
e-mail [email protected]
Web page http://jaredharvey.com
On Sun, Mar 12, 2017 at 5:24 PM, Daniel Wagner <[email protected]> wrote:
> On 03/12/2017 10:11 PM, Jared Harvey wrote:
>
>> Looks like this "action 18" happens repeatedly if I repeatedly try to
>> enable the wifi.
>>
>> machinekit@beaglebone:~$ date
>> Sun Mar 12 21:08:45 UTC 2017
>> machinekit@beaglebone:~$ sudo connmanctl enable wifi
>> Error wifi: Operation not permitted
>> machinekit@beaglebone:~$ tail /var/log/messages
>> Mar 12 20:45:55 beaglebone kernel: [ 341.732483] [<c003086b>]
>> (warn_slowpath_common+0x3f/0x4c) from [<c0030895>]
>> (warn_slowpath_fmt+0x1d/0x28)
>> Mar 12 20:45:55 beaglebone kernel: [ 341.732533] [<c0030895>]
>> (warn_slowpath_fmt+0x1d/0x28) from [<c032b6a3>]
>> (usb_submit_urb+0x1cb/0x398)
>> Mar 12 20:45:55 beaglebone kernel: [ 341.732964] [<c032b6a3>]
>> (usb_submit_urb+0x1cb/0x398) from [<bf86b7ab>]
>> (BulkInCmdRspEvent+0x42/0x68 [mt7601Usta])
>> Mar 12 20:45:55 beaglebone kernel: [ 341.733377] [<bf86b7ab>]
>> (BulkInCmdRspEvent+0x42/0x68 [mt7601Usta]) from [<bf86b8cd>]
>> (RTUSBBulkCmdRspEventReceive+0x3 8/0x58 [mt7601Usta])
>> Mar 12 20:45:55 beaglebone kernel: [ 341.733930] [<bf86b8cd>]
>> (RTUSBBulkCmdRspEventReceive+0x38/0x58 [mt7601Usta]) from [<bf84dabf>]
>> (NICInitializeAsic+0xe a/0x3c0 [mt7601Usta])
>> Mar 12 20:45:55 beaglebone kernel: [ 341.734137] [<bf84dabf>]
>> (NICInitializeAsic+0xea/0x3c0 [mt7601Usta]) from [<e0d8a000>] (0xe0d8a000)
>> Mar 12 20:45:55 beaglebone kernel: [ 341.734166] ---[ end trace
>> ca65cef3a8e7dd7f ]---
>> Mar 12 20:55:25 beaglebone rsyslogd-2007: action 'action 18' suspended,
>> next retry is Sun Mar 12 20:55:55 2017 [try http://www.rsyslog.com/e/2007
>> ]
>> Mar 12 21:07:22 beaglebone rsyslogd-2007: action 'action 18' suspended,
>> next retry is Sun Mar 12 21:07:52 2017 [try http://www.rsyslog.com/e/2007
>> ]
>> Mar 12 21:08:30 beaglebone rsyslogd-2007: action 'action 18' suspended,
>> next retry is Sun Mar 12 21:09:00 2017 [try http://www.rsyslog.com/e/2007
>> ]
>> machinekit@beaglebone:~$
>>
>
> From your report it really looks like your hardware is not really
> supported by the kernel. Do you happen to have different USB WiFi dongle to
> test? Another option is to ask corresponding kernel mailing list what the
> trace means.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20170312/6b25eef3/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 13 Mar 2017 08:36:57 +0000
From: Jose Blanquicet <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] technology: Deny P2P finding if technology is
disabled
Message-ID:
<cafc8ijjkpx-1kgu5dcdpzjydw7p9oz3jxst2mijnxtopjak...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi Daniel,
On Sun, Mar 12, 2017 at 7:13 PM, Daniel Wagner wrote:
>> Currently, when a scan is requested, it is only check if device is
>> powered. It
>> prevents to start scanning or finding if WiFi technology is disabled.
>> However,
>> when WiFi technolgy is enabled but P2P technology is not, the P2P finding
>> can be started anyway. This patch prevents it by adding an additional
>> control
>> on the technology status only in case the technology where scan was
>> requested is
>> P2P, doing so the return values for WiFi technology will not change.
>
>
> I re-read this paragraph many times but I don't really understand what the
> problem is you try to fix. From the code I can read that if the technology
> type is p2p and is !enabled (== disabled) return a permission denied... Ah,
> is this check added because we end up at the same D-Bus object for both WiFi
> and P2P? And if WiFi is enabled but not P2P we should just return ENOPERM?
> That would make sense indeed.
No, the D-Bus objects are different. This check is added because P2P
and WiFi scan end up at the same device and at that level there is not
differentiation between WiFi and P2P, they both are WiFi devices.
Therefore, when device's power is checked in device.c:device_scan(),
it is actually checking only if WiFi technology is enabled thus P2P
scan will go ahead even if P2P technology is not enabled.
> I wouldn't mind if you could reword your commit message a bit. It is really
> hard to understand.
Sorry, I will try to explain myself better next time. Is above
explanation better for the commit message?
Regards,
Jose Blanquicet
------------------------------
Message: 4
Date: Mon, 13 Mar 2017 10:12:01 +0100
From: Daniel Wagner <[email protected]>
To: Jared Harvey <[email protected]>
Cc: [email protected]
Subject: Re: Connman Error wifi: Operation not permitted [HELP please]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On 03/12/17 22:45, Jared Harvey wrote:
> I had installed the driver from official sources, using aptitude I
> installed mt7601u-modules-3.8.13-bone83 so I was hoping it was a proper
> driver. I used uname -A to determine I needed bone83.
>
> I have a DWA-121 USB wifi module coming this week. With some luck it
> will work out better than this one. It's listed on the BBB's wiki as a
> supported device. The UWN100 that I have is listed on that same wiki
> page but is listed more as a side comment than on the official list. I
> guess hopefully this one will have better support.
I think you will have more success with the dlink module.
Thanks,
Daniel
------------------------------
Message: 5
Date: Mon, 13 Mar 2017 10:14:45 +0100
From: Daniel Wagner <[email protected]>
To: Jose Blanquicet <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] technology: Deny P2P finding if technology is
disabled
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Good Morning Jose,
On 03/13/17 09:36, Jose Blanquicet wrote:
> No, the D-Bus objects are different. This check is added because P2P
> and WiFi scan end up at the same device and at that level there is not
> differentiation between WiFi and P2P, they both are WiFi devices.
> Therefore, when device's power is checked in device.c:device_scan(),
> it is actually checking only if WiFi technology is enabled thus P2P
> scan will go ahead even if P2P technology is not enabled.
Okay, got it.
>> I wouldn't mind if you could reword your commit message a bit. It is really
>> hard to understand.
>
> Sorry, I will try to explain myself better next time. Is above
> explanation better for the commit message?
Yes, much better ;) Now I was able to follow your thoughts. Can you
resend it with the above explanation.
Thanks,
Daniel
------------------------------
Message: 6
Date: Mon, 13 Mar 2017 10:16:04 +0100
From: Daniel Wagner <[email protected]>
To: Patrik Flykt <[email protected]>
Cc: Jose Blanquicet <[email protected]>, [email protected],
[email protected]
Subject: Re: [PATCH 0/5] Avoid to keep service in list if AP is not
found during scan
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Patrik,
On 03/01/17 15:51, Jose Blanquicet wrote:
> In addition, as you know, that -5 in your log is the mapping ConnMan
> does to wpa_s errors, I think ConnMan should at least print the actual
> wpa_s error in order to find it into the logs later for the analysis.
> For instance, that would be very useful in cases like this, do you
> agree?
>
> diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
> index 36c4dd5..0862e45 100644
> --- a/gsupplicant/supplicant.c
> +++ b/gsupplicant/supplicant.c
> @@ -4987,7 +4987,9 @@ static void interface_disconnect_result(const char
> *error,
> SUPPLICANT_DBG("");
>
> if (error) {
> + SUPPLICANT_DBG("error %s");
> result = -EIO;
> +
> if (g_strcmp0("org.freedesktop.DBus.Error.UnknownMethod",
> error) == 0)
> result = -ECONNABORTED;
>
Any news on this one?
Thanks,
Daniel
------------------------------
Message: 7
Date: Mon, 13 Mar 2017 10:14:59 +0000
From: Jose Blanquicet <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected], Patrik Flykt <[email protected]>
Subject: Re: [PATCH] technology: Deny P2P finding if technology is
disabled
Message-ID:
<cafc8ij+2spi04vtfdkk6it6b5z+sybgwfttur4gwstvlj_e...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Good Morning Daniel,
On Mon, Mar 13, 2017 at 9:14 AM, Daniel Wagner wrote:
> Yes, much better ;) Now I was able to follow your thoughts. Can you
> resend it with the above explanation.
Sure, I will do it.
BTW, From what I understood Patrick was testing this patch together
with "Avoid to keep service in list if AP is not found during scan"
patch set. Does he have comments?
Regards,
Jose Blanquicet
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 17, Issue 11
***************************************
