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: [systemd-devel] nftables (Daniel Wagner)
2. Re: R: [RFC] Storage based service retrieval + removal
(Patrik Flykt)
3. R: R: [RFC] Storage based service retrieval + removal
(MANIEZZO Marco (MM))
4. Connman FallbackNameservers problem (Viliam Lejcik)
----------------------------------------------------------------------
Message: 1
Date: Mon, 22 Feb 2016 12:10:43 +0100
From: Daniel Wagner <[email protected]>
To: Daniel Mack <[email protected]>, Tomasz Bursztyka
<[email protected]>, Tom Gundersen <[email protected]>
Cc: "[email protected]" <[email protected]>,
[email protected]
Subject: Re: [systemd-devel] nftables
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Daniel,
On 02/22/2016 11:39 AM, Daniel Mack wrote:
> On 02/22/2016 11:04 AM, Daniel Wagner wrote:
>> On 02/22/2016 09:54 AM, Tomasz Bursztyka wrote:
>>> 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.
>
> It aims for that, yes, but in my tests there were quite some uncovered
> corner cases when it comes to command line compatibility. But I wonder
> why this is related to ConnMan - does it call out to the binary?
We are using libxtables direcly which is a huge pain as it was never
design to be used as we do it. We didn't want to call iptables via shell
all the time.
>>> 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 haven't followed the discussions. What kind of conflicts is this about?
For iptables, we are maintaining our own input and output chain and
insert into the main chain. And than we hope no one is killing the
chain. It gets tricky after crash or restart to sync up correctly.
In short we toetipping around trying to avoid to mess with other
iptables rules.
>>> 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.
>
> IMO, ConnMan, or any other tool for that matter, should never mess with
> rules it hasn't created itself.
Yes, completely agree.
> nftables makes this easy, as it allows
> for namespaces in the rule sets, through custom tables.
Ah, so that sounds like I was looking. This is the answer to my initial
question :)
> If any other
> tool installs other tables with conflicting rules, I don't think ConnMan
> should care really.
That is the plan.
> With iptables, this is just a bit trickier due to
> the custom jump label that you have to install in the INPUT and OUTPUT
> chains.
Yep.
> Right now, there are two parts of systemd that touch packet filter
> configurations, nspawn and networkd, and the code already takes care of
> not touching any rule that it has no business with.
>
>> 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?
>
> It was me who worked on this, and I postponed the branch a while ago
> until we know how the kernel APIs look like that we want to use for a
> per-unit packet filtering mechanism. Back then, it looked like this
> could only be achieved with nftables, which is why I reworked all the
> code in systemd.
Ah, I though Tom was working on this. Sorry about that.
> Now, things are not that clear anymore, so the decision was postponed. I
> hope to catch up with this soon, but eventually, I think we should move
> to nftables as well. Note, however, that iptables and nftables may
> coexist on a system.
My hope is that if ConnMan just uses nftables, the kernel needs to sort
out the problems. I know I live in a naive world. :)
>>> 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.
>
> You can have a look at the outdated branch of mine here:
>
> https://github.com/zonque/systemd/commits/nftnl
Thanks for the pointer.
cheers,
daniel
------------------------------
Message: 2
Date: Mon, 22 Feb 2016 13:21:21 +0200
From: Patrik Flykt <[email protected]>
To: "MANIEZZO Marco (MM)" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: R: [RFC] Storage based service retrieval + removal
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
Hi,
On Mon, 2016-02-22 at 10:52 +0000, MANIEZZO Marco (MM) wrote:
> 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
Point 2) works only if the service ID is interpreted, by default this
should not be the case (except for giving sane clues for developers, but
that's another story).
> 3) for application using connman easy matching with nearby services to
> understand if a stored service is also available for connection
I think there needs to be a service object path property that explicitly
tells what the corresponding service object path is, if any. The other
question from a long time ago was the life cycle of these stored
services, were they going to disappear when they are detected and
created as services or how was the situation supposed to be resolved.
> 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.
I'd appreciate that the intended changes were to be documented in ./doc
first so that the API can be discussed and agreed on. Then the
implementation won't be dragged through all discussions and changes.
> We'll provide the remove patch separated from knowServices one.
Thanks.
Patrik
------------------------------
Message: 3
Date: Mon, 22 Feb 2016 13:44:29 +0000
From: "MANIEZZO Marco (MM)" <[email protected]>
To: Patrik Flykt <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: R: R: [RFC] Storage based service retrieval + removal
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hello Patrick,
Sorry I was not clear, I'll try to explain better with the help of connmanctl:
Suppose to have connected the ethernet and mutable service WiFi AP named
Digicom; current information provided by "services" is like:
connmanctl> services
*AR Wired ethernet_c8cbb8564ae1_cable
*AR Digicom wifi_6067208eac78_44696769636f6d_managed_psk
FG-WiFi wifi_6067208eac78_46472d57694669_managed_ieee8021x
This corresponds to the following data in /var/lib/connman:
drwx------ 2 root root 4096 Feb 22 13:53 ethernet_c8cbb8564ae1_cable/
-rw------- 1 root root 142 Feb 22 13:53 settings
drwx------ 2 root root 4096 Feb 22 13:55
wifi_6067208eac78_44696769636f6d_managed_psk/
the folder wifi_6067208eac78_44696769636f6d_managed_psk is created for Digicom
AP and contains files settings and data. The "Remove" method of Service is
currently deleting some data (passphrase included) in ram and setting file, but
it is not deleting folder and files.
With the proposed RFC using know-services in connmanctl that calls
Manager/GetKnownServices method will give:
connmanctl> known-services
*AR Digicom wifi_6067208eac78_44696769636f6d_managed_psk_stored
*AR Wired ethernet_c8cbb8564ae1_cable_stored
At this point on the d-bus the following are available:
1. wifi_6067208eac78_44696769636f6d_managed_psk_stored
2. ethernet_c8cbb8564ae1_cable_stored
3. ethernet_c8cbb8564ae1_cable
4. wifi_6067208eac78_44696769636f6d_managed_psk
5. wifi_6067208eac78_46472d57694669_managed_ieee8021x
(1) and (2) will be available on the d-bus (currently only with Remove method)
regardless of (3) and (4) that would disappear if ethernet is unplugged or
Digicom disappear. Ethernet Service type does not support remove, but Digicom
can be removed so the user can do:
connmanctl> config wifi_6067208eac78_44696769636f6d_managed_psk_stored --remove
or if still nearby
connmanctl> config wifi_6067208eac78_44696769636f6d_managed_psk --remove
(but I would deprecate this)
and
- the service is disconnected (if it was connected)
- its data in ram is cleared (if available, maybe it is not visible), like
before (passphrase, identity ..)
- d-bus object wifi_6067208eac78_44696769636f6d_managed_psk_stored disappears
- /var/lib/connman/wifi_6067208eac78_44696769636f6d_managed_psk folder and its
content is deleted
and the new situation is:
connmanctl> services
*AR Wired ethernet_c8cbb8564ae1_cable
Digicom wifi_6067208eac78_44696769636f6d_managed_psk
FG-WiFi wifi_6067208eac78_46472d57694669_managed_ieee8021x
connmanctl> known-services
*AR Wired ethernet_c8cbb8564ae1_cable_stored
The Manager/GetKnownServices method provides path objects + properties of each,
like GetServices. We'll provide only the path to save memory in case of
thousands services stored.
Regards,
Marco
-----Messaggio originale-----
Da: Patrik Flykt [mailto:[email protected]]
Inviato: luned? 22 febbraio 2016 12:21
A: MANIEZZO Marco (MM)
Cc: Marcel Holtmann; [email protected]
Oggetto: Re: R: [RFC] Storage based service retrieval + removal
Hi,
On Mon, 2016-02-22 at 10:52 +0000, MANIEZZO Marco (MM) wrote:
> 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
Point 2) works only if the service ID is interpreted, by default this should
not be the case (except for giving sane clues for developers, but that's
another story).
> 3) for application using connman easy matching with nearby services to
> understand if a stored service is also available for connection
I think there needs to be a service object path property that explicitly tells
what the corresponding service object path is, if any. The other question from
a long time ago was the life cycle of these stored services, were they going to
disappear when they are detected and created as services or how was the
situation supposed to be resolved.
> 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.
I'd appreciate that the intended changes were to be documented in ./doc first
so that the API can be discussed and agreed on. Then the implementation won't
be dragged through all discussions and changes.
> We'll provide the remove patch separated from knowServices one.
Thanks.
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.
------------------------------
Message: 4
Date: Mon, 22 Feb 2016 19:55:15 +0000
From: Viliam Lejcik <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Connman FallbackNameservers problem
Message-ID:
<d13610e838836d488558653194c1806982f...@kihagwinex02.int.kistler.com>
Content-Type: text/plain; charset="us-ascii"
Hi,
I have a problem with connman. I have a board with static IP set and fallback
name servers defined in the /etc/connman/main.conf file (8.8.8.8,8.8.4.4 in my
case). With connmanctl I see that the specified nameservers are in use:
connmanctl> services ethernet_...
...
Nameservers = [ 8.8.8.8, 8.8.4.4 ]
However trying to ping e.g. google.com fails. When I change the nameservers
with connmanctl even with the same name server IP addresses, then the
resolution works.
As log says, connman is trying to add fallback name servers, what initially
fails:
daemon.debug connmand[710]: resolver.c:__connman_resolver_init() server 8.8.8.8
daemon.debug connmand[710]: resolver.c:append_resolver() index -1 domain (null)
server 8.8.8.8 lifetime 0 flags 1 daemon.debug connmand[710]:
dnsproxy.c:__connman_dnsproxy_append() index -1 server 8.8.8.8 daemon.debug
connmand[710]: dnsproxy.c:find_server() index -1 server 8.8.8.8 proto 17
daemon.debug connmand[710]: dnsproxy.c:create_server() index -1 server 8.8.8.8
daemon.debug connmand[710]: dnsproxy.c:server_create_socket() index -1 server
8.8.8.8 proto 17 daemon.debug connmand[710]: dnsproxy.c:server_create_socket()
sk 16 daemon.err connmand[710]: Failed to connect to server 8.8.8.8
It fails in connect() with errno 101 (network is unreachable). This is ok,
because before entering the main loop network is unreachable. Later the log
says:
daemon.debug connmand[710]: service.c:append_dns() append fallback nameservers
daemon.debug connmand[710]: service.c:append_nameservers() servers[0] 8.8.8.8
available 1 daemon.debug connmand[710]: service.c:append_nameservers()
servers[1] 8.8.4.4 available 1
Now the nameservers should be ready to use. Trying to ping google.com, ping
fails with bad address error, and the log says:
daemon.debug connmand[710]: dnsproxy.c:udp_listener_event() Received 28 bytes
(id 0x3034) daemon.debug connmand[710]: dnsproxy.c:parse_request() id 0x3034 qr
0 opcode 0 qdcount 1 arcount 0 daemon.debug connmand[710]:
dnsproxy.c:parse_request() query google.com.
daemon.debug connmand[710]: dnsproxy.c:send_response() sk 12 daemon.debug
connmand[710]: dnsproxy.c:send_response() id 0x3034 qr 0 opcode 0
This is because server_list in udp_listener_event() is empty. Ok, let's go
further. With connmanctl I set the same nameserver IPs, log proves that they
are in use:
daemon.debug connmand[710]: service.c:set_property() service 0xdf390
daemon.debug connmand[710]: inet.c:connman_inet_compare_subnet() host 8.8.8.8
daemon.debug connmand[710]: inet.c:connman_inet_add_network_route() index 3
host 8.8.8.8 gateway 192.168.192.254 netmask (null) ...
In this case the name servers have positive index (fallback ones have -1). Now
resolution works perfectly well.
connmand[710]: dnsproxy.c:resolv() server 8.8.8.8 enabled 1 ...
However, resetting nameservers back to the empty value with connmanctl,
connmand should use ones from the config file. Now the name resolution stopped
working because these servers are disabled:
connmand[710]: dnsproxy.c:resolv() server 8.8.8.8 enabled 0
connmand[710]: dnsproxy.c:resolv() server 8.8.4.4 enabled 0
Temporarily I can fix this problem with setting nameservers explicitly with
connmanctl, but I think this is not the the intended way. Maybe I am doing
something wrong. Any help/suggestions will be appreciated, thanks.
Cheers,
Viliam
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 4, Issue 28
**************************************
