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: [PATCH 0/5] Add iptables IPv6 support (Daniel Wagner)
2. Re: hidden ssid connection when service path is unknow
(Daniel Wagner)
3. Re: [PATCH] Fix gsupplicant not to fail an active scan on
wpa_supplicant side (Daniel Wagner)
4. Re: [PATCH 1/6] tethering: Add storage where tethering client
can be registered (Daniel Wagner)
5. Re: [PATCH 1/6] tethering: Add storage where tethering client
can be registered (Vasyl Vavrychuk)
6. Re: Configuration file issues (Nuno Gon?alves)
7. Re: Configuration file issues (Daniel Wagner)
----------------------------------------------------------------------
Message: 1
Date: Fri, 23 Nov 2018 06:27:54 +0100
From: Daniel Wagner <[email protected]>
To: Jussi Laakkonen <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH 0/5] Add iptables IPv6 support
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Jussi,
On Thu, Nov 08, 2018 at 03:23:41PM +0200, Jussi Laakkonen wrote:
> This patch set adds support for IPv6 iptables management into iptables.c.
> Managing IPv6 iptables content differs only from the structure definition
> parts so most of the IPv6 support is included into existing code.
>
> For each iptables.c exposed function a type variable has been added, which
> indicates the IP protocol type. Common AF_* definitions are used (AF_INET &
> AF_INET6) as types.
>
> Necessary changes for firewall-iptables.c and iptables-unit.c are applied.
> Also a tool for testing ip6tables functionality is implemented as a copy of
> the existing iptables-test.
>
> NAT tests for IPv6 are not included into unit tests as IPv6 NAT functionality
> is not implemented within this work.
Wow, that is a hugh effort! And also a big thank you for taking the
time write the commit messages.
I've applied the whole series. If there are any problem we fix that in
on top of it. Not that I expect any problems :)
Thanks,
Daniel
------------------------------
Message: 2
Date: Fri, 23 Nov 2018 06:34:30 +0100
From: Daniel Wagner <[email protected]>
To: Alexandre Leblanc <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: hidden ssid connection when service path is unknow
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi,
On Thu, Nov 15, 2018 at 04:10:29PM -0500, Alexandre Leblanc wrote:
> Hello everyone
>
> I'm trying do develop a small wrapper around connmam mostly using dbus and
> python. Everything work fine yet.
> Managing hidden network is a bit of an issue.
That is an understatement from my past experience.
> The wrapper will be use in an environment where there will be a lot of
> hidden network (not for security reason...)
> and only the ssid Name will be known.
> So how would one identity the right service to connect to ?
> Using my wrapper I can already see hidden network path.
> I already know that my agent will handle the ssid Name when a connection
> request is done.
> Should I simply try connect to all of them ?
I haven't done anything for a while with hidden networks. The documentation
says following
service-api.txt:
[...]
void Connect()
[...]
Calling Connect() on a hidden WiFi service entry will
query the missing SSID via the Agent API causing a
WiFi service with the given SSID to be scanned,
created and connected.
IIRC, you should see a service for the hidden networks. Do you provide
an agent for ConnMan to call?
Thanks,
Daniel
------------------------------
Message: 3
Date: Fri, 23 Nov 2018 06:42:55 +0100
From: Daniel Wagner <[email protected]>
To: ????????? ????? <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] Fix gsupplicant not to fail an active scan on
wpa_supplicant side
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi,
On Tue, Nov 20, 2018 at 02:28:46PM -0800, ????????? ????? wrote:
> he issue has been discovered during work on other issue
> https://lists.01.org/pipermail/connman/2018-November/023085.html
>
> If connman does ACTIVE scan without adding a list of SSIDs
> interface_scan_params() in gsupplicant/supplicant.c calls
>
> supplicant_dbus_dict_append_array(&dict, "SSIDs",
> DBUS_TYPE_STRING,
> append_ssids,
> data->scan_params);
>
> which creates an empty entry for "SSIDs" without anything inside.
>
> This dbus msg goes to wpa supplicant to dbus/dbus_new_handles.c to
> wpas_dbus_handler_scan() which calls wpas_dbus_get_scan_ssids() because
> there is an entry "SSIDs".
> Unfortunately wpas_dbus_get_scan_ssids() fails with an error.
>
> Here are my logs:
>
> Nov 17 03:09:10 LogiCircle daemon.debug wpa_supplicant[344]:
> wpas_dbus_get_scan_ssids[dbus]: ssids must be an array of arrays of bytes
> Nov 17 03:09:10 LogiCircle daemon.debug wpa_supplicant[344]:
> wpas_dbus_get_scan_ssids[dbus]: ssids must be an array of arrays of bytes
> Nov 17 03:09:10 LogiCircle daemon.debug wpa_supplicant[344]:
> wpas_dbus_get_scan_ssids[dbus]: ssids must be an array of arrays of bytes
> Nov 17 03:17:06 LogiCircle daemon.debug wpa_supplicant[344]:
> wpas_dbus_get_scan_ssids[dbus]: ssids must be an array of arrays of bytes
> Nov 17 03:17:06 LogiCircle daemon.debug wpa_supplicant[344]:
> wpas_dbus_get_scan_ssids[dbus]: ssids must be an array of arrays of bytes
> Nov 17 03:17:06 LogiCircle daemon.debug wpa_supplicant[344]:
> wpas_dbus_get_scan_ssids[dbus]: ssids must be an array of arrays of bytes
>
> The patch below is very simple. If there is no SSID in scan_parameters do
> not create "SSIDs". The adjacent function supplicant_add_scan_frequency()
> does such verification and does not create any empty "Channels".
Also add which wpa_supplicant version you used to test in the commit
message (see below what I mean with the commit message).
>
>
> ==============================
> diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
> index 0cb621b9..92941c63 100644
> --- a/gsupplicant/supplicant.c
> +++ b/gsupplicant/supplicant.c
> @@ -4241,11 +4241,13 @@ static void interface_scan_params(DBusMessageIter
> *iter, void *user_data)
> supplicant_dbus_dict_append_basic(&dict, "Type",
> DBUS_TYPE_STRING, &type);
>
> - supplicant_dbus_dict_append_array(&dict, "SSIDs",
> - DBUS_TYPE_STRING,
> - append_ssids,
> - data->scan_params);
>
> + if (data->scan_params->ssids) {
> + supplicant_dbus_dict_append_array(&dict, "SSIDs",
> + DBUS_TYPE_STRING,
> + append_ssids,
> + data->scan_params);
> + }
Okay, this looks good (obviously, except the whitespace damage)
> supplicant_add_scan_frequency(&dict, add_scan_frequencies,
> data->scan_params);
> } else
>
> PS. I sent this patch from other unregistered email. I hope there is not
> going to be any duplicate.
No, all fine with this. In just you are sending HTML emails and your
patch can't be processed by me without starting editing myself
(reformating, writing a commit messages etc). Since I am already
pretty slow responding and handling emails from everyone I would like
to ask from you to make my life simpler by following the usual patch
submission processes.
Thanks,
Daniel
------------------------------
Message: 4
Date: Fri, 23 Nov 2018 07:09:06 +0100
From: Daniel Wagner <[email protected]>
To: Vasyl Vavrychuk <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH 1/6] tethering: Add storage where tethering client
can be registered
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Vasyl,
On Fri, Nov 23, 2018 at 01:36:27AM +0200, Vasyl Vavrychuk wrote:
> This list will be exposed to clients of connman.
>
> It is supposed to be filled in connman plugins.
Thanks for the refactoring and splitting the series. Looks good and
and works like a charm for me. All patches applied.
Thanks,
Daniel
------------------------------
Message: 5
Date: Fri, 23 Nov 2018 10:51:49 +0200
From: Vasyl Vavrychuk <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH 1/6] tethering: Add storage where tethering client
can be registered
Message-ID:
<camqc21abnzjlrcsrkhw48g79f1bzaw6+grwkja4d0xgaa3i...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi Daniel,
Thank you for your point regarding splitting patches.
Unfortunately my original version had a memory leak
g_hash_table_remove(clients_table, g_strdup(...
And I was able to notice it as result of this commits splitting.
Thanks,
Vasyl
On Fri, Nov 23, 2018 at 8:09 AM Daniel Wagner <[email protected]> wrote:
>
> Hi Vasyl,
>
> On Fri, Nov 23, 2018 at 01:36:27AM +0200, Vasyl Vavrychuk wrote:
> > This list will be exposed to clients of connman.
> >
> > It is supposed to be filled in connman plugins.
>
> Thanks for the refactoring and splitting the series. Looks good and
> and works like a charm for me. All patches applied.
>
> Thanks,
> Daniel
--
Vasyl Vavrychuk | Software Engineer
GlobalLogic L'viv
Skype: vasyl.vavrychuk
www.globallogic.com
http://www.globallogic.com/email_disclaimer.txt
------------------------------
Message: 6
Date: Fri, 23 Nov 2018 11:47:55 +0100
From: Nuno Gon?alves <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: Configuration file issues
Message-ID:
<caexmxlqflwivaj_zcerieqc6lsgtv6aqwmatvbktvlvx2+d...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Fri, Nov 23, 2018 at 5:30 AM Daniel Wagner <[email protected]> wrote:
> ConnMan does not keep track of which config has been applied already. If
> a Service matches a config it will be used. The current behavior has
> also the upside we don't have a random outcome which service will be
> considered when a config matches (the ordering of the interfaces might
> not be stable). So I tend to say the code is doing the right thing at
> this moment and the documentation is wrong.
>
Looks fine to fix the documentation...
> > The second issue happens when I remove
> /var/lib/connman/010203040506.config,
> >
> > Connman at this time does not reset the interfaces to the default
> > configuration and instead they become unconfigured:
> >
> > $ connmanctl services ethernet_(...1...)_cable
> > ...
> > State = idle
> > Favorite = True
> > Immutable = False
> > AutoConnect = True
> > ...
> > IPv4 = [ ]
> > IPv4.Configuration = [ ]
> > ...
> > $ connmanctl services ethernet_(...2...)_cable
> > ...
> > State = idle
> > Favorite = True
> > Immutable = False
> > AutoConnect = True
> > ...
> > IPv4 = [ ]
> > IPv4.Configuration = [ ]
>
> What you mean with default configuration? I seem to miss the important
> thing in you listing :)
>
I don't known if the confusion is because you think I removed data from
IPv4*. No.
IPv4* fields are empty. Unconfigured.
Default without config file: DHCP
I add a config file: Static
I remove the config file: Unconfigured.
Maybe I missed any relevant field?
Thanks,
Nuno
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20181123/4743949d/attachment-0001.html>
------------------------------
Message: 7
Date: Fri, 23 Nov 2018 12:04:22 +0100
From: Daniel Wagner <[email protected]>
To: Nuno Gon?alves <[email protected]>
Cc: [email protected]
Subject: Re: Configuration file issues
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Nuno,
> > The second issue happens when I remove
> /var/lib/connman/010203040506.config,
> >
> > Connman at this time does not reset the interfaces to the default
> > configuration and instead they become unconfigured:
> >
> > $ connmanctl services ethernet_(...1...)_cable
> > ...
> > ? State = idle
> > ? Favorite = True
> > ? Immutable = False
> > ? AutoConnect = True
> > ...
> > ? IPv4 = [? ]
> > ? IPv4.Configuration = [? ]
> > ...
> > $ connmanctl services ethernet_(...2...)_cable
> > ...
> > ? State = idle
> > ? Favorite = True
> > ? Immutable = False
> > ? AutoConnect = True
> > ...
> > ? IPv4 = [? ]
> > ? IPv4.Configuration = [? ]
>
> What you mean with default configuration? I seem to miss the important
> thing in you listing :)
>
>
> I don't known if the confusion is because you think I removed data from
> IPv4*. No.
>
> IPv4* fields are empty. Unconfigured.
The service is also in idle state. So that is okay. Do you expect that
the autoconnect happens?
> Default without config file: DHCP
> I add a config file: Static
> I remove the config file: Unconfigured.
>
> Maybe I missed any relevant field?
And if you then tell ConnMan to connect given service?
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 37, Issue 12
***************************************
