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: nftables (Daniel Wagner)
2. Re: [RFC] Storage based service retrieval + removal (Patrik Flykt)
3. Re: nftables (Daniel Wagner)
4. R: [RFC] Storage based service retrieval + removal
(MANIEZZO Marco (MM))
----------------------------------------------------------------------
Message: 1
Date: Mon, 22 Feb 2016 10:38:22 +0100
From: Daniel Wagner <[email protected]>
To: "Zheng, Wu" <[email protected]>, Tomasz Bursztyka
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: nftables
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi,
On 02/22/2016 10:30 AM, Zheng, Wu wrote:
> Hi Tomasz Bursztyka and Daniel Wagner,
>
> We want to use nftable in our system.
Yes, it makes sense to abandon iptables.
> Do you have an plan to implement nftable in Connman?
Well, as I said i was playing with the idea to do it as spare time project.
> If so, do you have an plan when do upstream can implement the feature?
I was asking Tomasz on how to use nftables. nftables doesn't enforce any
policies on the chain/table structure such as iptables. So that is first
thing we have to figure out.
Probably, we should also discuss it with the systemd-netwokd guys.
cheers,
daniel
------------------------------
Message: 2
Date: Mon, 22 Feb 2016 11:55:48 +0200
From: Patrik Flykt <[email protected]>
To: "MANIEZZO Marco (MM)" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [RFC] Storage based service retrieval + removal
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
Hi,
On Thu, 2016-02-11 at 08:20 +0000, MANIEZZO Marco (MM) wrote:
> diff --git a/doc/manager-api.txt b/doc/manager-api.txt
> index 31e137c..f2a2267 100644
> --- a/doc/manager-api.txt
> +++ b/doc/manager-api.txt
> @@ -45,6 +45,23 @@ Methodsdict GetProperties()
> and dictionary of peer properties
>
> Possible Errors: [service].Error.InvalidArguments
> +
> +array{object,dict} GetKnownServices() [experimental]
> +
> +Returns a sorted list of tuples with service object
> +path and dictionary of service properties, for the
> +known services (both mutable and immutable).
> +
> +This list will not contain sensitive information
> +like passphrases etc.
> +
> +The objects have a "_stored" appended to the path
We don't want to interpret parts of path names here. Earlier discussions
on the topic concluded that the stored/known configurations should not
be mixed with services nearby that can be connected to.
Also sending all details for all known services is not a good thing. The
D-Bus message will be pretty long for 2000 stored services. Same goes
with ConnMan trying to represent the same 2000 services. Here one needs
to register the object paths to D-Bus, but no more than that. The
details can be looked at with a D-Bus request with the results generated
on demand saving a lot of memory in the process for those 2000 assumed
services. For implementation reasons it were easier if the object path
of the stored services should started off with a prefix of their own,
from a design point of view it also makes sense to have them differently
named.
> +(e.g. wifi_6067208eac78_474f4c5045_managed_psk_stored)
> +and the only available method of this kind of services
> +is currently Remove, while the other Service methods
> +will return error.
> +
> +Possible Errors: [service].Error.InvalidArguments
>
> object ConnectProvider(dict provider)[deprecated]
>
> diff --git a/doc/service-api.txt b/doc/service-api.txt
> index e2e9e84..1e23072 100644
> --- a/doc/service-api.txt
> +++ b/doc/service-api.txt
> @@ -94,11 +94,14 @@ Methodsdict GetProperties() [deprecated]
> service is in the State=failure, this method can
> also be used to reset the service.
>
> -Calling this method on Ethernet devices, hidden WiFi
> -services or provisioned services will cause an error
> -message. It is not possible to remove these kind of
> -services.
> -
> +Calling this method on Ethernet devices and hidden WiFi
> +services will cause an error message. It is not possible
> +to remove these kind ofservices.
> +
> +For the other services the removal will cause the
> +deletion of their folder inSTORAGEDIR. Immutable
> +services .config file will not be deleted.
> +
> Possible Errors: [service].Error.InvalidArguments
>
> void MoveBefore(object service)
This is fine, but actually not really related to the stored services.
Could you spin a separate patch for this behavior and document it?
The rest of the patch looked as eaten alive, all indentations were gone
and as such it wasn't really readable. I don't know what happened here.
Cheers,
Patrik
------------------------------
Message: 3
Date: Mon, 22 Feb 2016 11:04:19 +0100
From: Daniel Wagner <[email protected]>
To: Tomasz Bursztyka <[email protected]>, Tom Gundersen
<[email protected]>
Cc: [email protected], "[email protected]"
<[email protected]>
Subject: Re: nftables
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Tomasz and Tom,
On 02/22/2016 09:54 AM, Tomasz Bursztyka wrote:
>> Hi Tomasz,
>>
>> I just chatted with Patrik and told him about my idea to teach ConnMan
>> to use nftables instead iptables. There are a few things to figure out
>> first though.
>>
>> If I got that right there is no policy from the kernel on how to
>> structure the rule sets. nat/filter tables and input/forward/output
>> chains are userland policies. The question is how would ConnMan fit into
>> this? As you know, ConnMan tries to avoid conflicts with iptables in tip
>> toeing around. Do we have to do the same with nftables?
>
> You are right, when you start bare metal kernel with nftables: there
> is nothing. No tables and no chains. It's a good thing because it
> enables flexibility, but it can also be a burden when it comes to
> integrate with custom table & chains.
Okay, so nothing new :)
> I haven't been following the recent (well... the last ~2 years ^^')
> work on nftables but I believe there are still people using the
> iptables format. The use the iptables- nftables compatible tool, and
> it mimics iptables through nftables. Verify it, but if it's the
> generic way, then it would be as usual in ConnMan.
>
> If not, then you will have to come with a strategy that fits all. And
> that's when it
> might become tricky. As you noticed, ConnMan will have to avoid conflicts.
> I believe it will be a bit easier than with iptables though.
> - you pull the current context:
> -> if there is nothing, it will be easy ConnMan will just push
> whatever it will want.
> -> if something is there, integrating will have to play nice.
> Basically: finding the
> input entry point to jump on a custom ConnMan table (you'll probably
> need that
> for each IP version), get you rules applied or return if nothing.
>
> Problem start to arise when somebody/something else messes up again
> with the context. Like flushing out everything, reinstalling stuff...
> ConnMan will have to follow. It was the same with iptables. It's
> hopefully much easier now: there are proper netlink notification
> messages for it. Well, let's put this problem apart for now.
Lennart posted the headsup on systemd moving from iptables to
nftables [1]. I don't know how far those plans have gotten but I think
it would be good idea to coordinate this with systemd-networkd.
@Tom do you happen to know what the status is on this?
> About coding around, it's a bit messy. There is one library,
> libnftnl. It's not build on top of libnl. I am not entirely sure, but
> I think you can hook your own netlink access functions to it. By
> default it uses libmnl... You'll have to verify that. Ask Marcel what
> he would prefer as well. Afaik, there is still the plan to move
> ConnMan to ell, so keeping it's custom netlink access would make
> sense then, I guess.
I really like to avoid coding directly netlink. The libnftnl doesn't look
too bad.
cheers,
daniel
[1] https://lists.freedesktop.org/archives/systemd-devel/2015-May/032531.html
------------------------------
Message: 4
Date: Mon, 22 Feb 2016 10:52:53 +0000
From: "MANIEZZO Marco (MM)" <[email protected]>
To: Patrik Flykt <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: R: [RFC] Storage based service retrieval + removal
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hello Patrick,
Thank you for your feedback. Sorry for the email problem, I just copied/pasted
the output of git diff in the mail, for the patch. Please find the patch in the
attached txt.
I agree with you that with 2000 services the d-bus message with this
implementation will be big, our was an implementation more related to pc /
mobile devices where the stored services would be two orders of magnitude
smaller. Moreover the single services GetProperties is currently deprecated, I
wasn't sure to go that direction for knownServices. We will think about the
change accordingly to your request, maybe in separate phases: first would be to
provide only the path object and second to implement the GetProperties method.
Related to d-bus path names consider that they are used by the Remove method so
I thought that the easiest way was to use the actual file system path (I mean
service_path in var/lib/connman/<service_path>) plus a postfix; after having
stripped the postfix it is easy to remove the file system data relying on
__connman_storage_remove_service(service->identifier): this is also granting
1) uniqueness
2) relevant information already included in the path itself, like technology,
security methods, SSID
3) for application using connman easy matching with nearby services to
understand if a stored service is also available for connection
I can change it to have "stored" as a prefix instead of postfix but I would
keep the <service_path> especially for point 1, but if you have a different
suggestion it is welcome; please let me know your feedback.
We'll provide the remove patch separated from knowServices one.
Regards,
Marco
-----Messaggio originale-----
Da: Patrik Flykt [mailto:[email protected]]
Inviato: luned? 22 febbraio 2016 10:56
A: MANIEZZO Marco (MM)
Cc: Marcel Holtmann; [email protected]
Oggetto: Re: [RFC] Storage based service retrieval + removal
Hi,
On Thu, 2016-02-11 at 08:20 +0000, MANIEZZO Marco (MM) wrote:
> diff --git a/doc/manager-api.txt b/doc/manager-api.txt index
> 31e137c..f2a2267 100644
> --- a/doc/manager-api.txt
> +++ b/doc/manager-api.txt
> @@ -45,6 +45,23 @@ Methodsdict GetProperties() and dictionary of peer
> properties
>
> Possible Errors: [service].Error.InvalidArguments
> +
> +array{object,dict} GetKnownServices() [experimental]
> +
> +Returns a sorted list of tuples with service object path and
> +dictionary of service properties, for the known services (both
> +mutable and immutable).
> +
> +This list will not contain sensitive information like passphrases
> +etc.
> +
> +The objects have a "_stored" appended to the path
We don't want to interpret parts of path names here. Earlier discussions on the
topic concluded that the stored/known configurations should not be mixed with
services nearby that can be connected to.
Also sending all details for all known services is not a good thing. The D-Bus
message will be pretty long for 2000 stored services. Same goes with ConnMan
trying to represent the same 2000 services. Here one needs to register the
object paths to D-Bus, but no more than that. The details can be looked at with
a D-Bus request with the results generated on demand saving a lot of memory in
the process for those 2000 assumed services. For implementation reasons it were
easier if the object path of the stored services should started off with a
prefix of their own, from a design point of view it also makes sense to have
them differently named.
> +(e.g. wifi_6067208eac78_474f4c5045_managed_psk_stored)
> +and the only available method of this kind of services is currently
> +Remove, while the other Service methods will return error.
> +
> +Possible Errors: [service].Error.InvalidArguments
>
> object ConnectProvider(dict provider)[deprecated]
>
> diff --git a/doc/service-api.txt b/doc/service-api.txt index
> e2e9e84..1e23072 100644
> --- a/doc/service-api.txt
> +++ b/doc/service-api.txt
> @@ -94,11 +94,14 @@ Methodsdict GetProperties() [deprecated] service
> is in the State=failure, this method can also be used to reset the
> service.
>
> -Calling this method on Ethernet devices, hidden WiFi -services or
> provisioned services will cause an error -message. It is not possible
> to remove these kind of -services.
> -
> +Calling this method on Ethernet devices and hidden WiFi services will
> +cause an error message. It is not possible to remove these kind
> +ofservices.
> +
> +For the other services the removal will cause the deletion of their
> +folder inSTORAGEDIR. Immutable services .config file will not be
> +deleted.
> +
> Possible Errors: [service].Error.InvalidArguments
>
> void MoveBefore(object service)
This is fine, but actually not really related to the stored services.
Could you spin a separate patch for this behavior and document it?
The rest of the patch looked as eaten alive, all indentations were gone and as
such it wasn't really readable. I don't know what happened here.
Cheers,
Patrik
________________________________
VISITA IL NOSTRO NUOVO SITO WEB! - VISIT OUR NEW WEB SITE!
www.magnetimarelli.com
Confidential Notice: This message - including its attachments - may contain
proprietary, confidential and/or legally protected information and is intended
solely for the use of the designated addressee(s) above. If you are not the
intended recipient be aware that any downloading, copying, disclosure,
distribution or use of the contents of the above information is strictly
prohibited.
If you have received this communication by mistake, please forward the message
back to the sender at the email address above, delete the message from all
mailboxes and any other electronic storage medium and destroy all copies.
Disclaimer Notice: Internet communications cannot be guaranteed to be safe or
error-free. Therefore we do not assure that this message is complete or
accurate and we do not accept liability for any errors or omissions in the
contents of this message.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diff.txt
URL:
<http://lists.01.org/pipermail/connman/attachments/20160222/90bca111/attachment.txt>
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 4, Issue 27
**************************************
