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 2/2] service: add mDNS support on per-interface
      basis. (Patrik Flykt)
   2. Re: [PATCH 1/2] resolver: add support for systemd-resolved.
      (Patrik Flykt)
   3. Re: [PATCH 1/2] resolver: add support for systemd-resolved.
      (Puustinen, Ismo)
   4. Re: [PATCH 2/2] service: add mDNS support on per-interface
      basis. (Puustinen, Ismo)


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

Message: 1
Date: Mon, 02 Oct 2017 15:57:10 +0300
From: Patrik Flykt <[email protected]>
To: Ismo Puustinen <[email protected]>, [email protected]
Subject: Re: [PATCH 2/2] service: add mDNS support on per-interface
        basis.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"

On Wed, 2017-09-27 at 15:05 +0300, Ismo Puustinen wrote:
> Currently mDNS support requires systemd-resolved. However, there's
> nothing to prevent other mDNS backends. The mDNS state is exposed over
> D-Bus for service objects.
> 
> The mDNS activation is triggered via "Method" key for mDNS.Configuration
> property. Allowed string values are "enabled", "disabled", and
> "resolve_only". Value "enabled" means that mDNS domains are resolved by
> systemd-resolved and current host name is registered. Value "no" means
> that mDNS is turned off for the service. Value "resolve_only" means that
> the hostname is not registered, but mDNS resolving is supported.
> 
> You can test this by enabling mDNS support for service "service_name"
> with the following command:
> 
> ? busctl call net.connman /net/connman/service/service_name \
> ??????net.connman.Service SetProperty sv mDNS.Configuration \
> ??????a{sv} 1 Method s enabled
> ---
> ?doc/config-format.txt |???7 ++
> ?doc/service-api.txt???|??18 +++++
> ?include/service.h?????|???8 +++
> ?src/config.c??????????|??15 ++++
> ?src/connman.h?????????|???3 +
> ?src/resolver.c????????|??49 +++++++++++++
> ?src/service.c?????????| 193 
> ++++++++++++++++++++++++++++++++++++++++++++++++++
> ?7 files changed, 293 insertions(+)
> 
> diff --git a/doc/config-format.txt b/doc/config-format.txt
> index ed3123aa..68e5bf2e 100644
> --- a/doc/config-format.txt
> +++ b/doc/config-format.txt
> @@ -63,6 +63,13 @@ Allowed fields:
> ?- SearchDomains: Comma separated list of DNS search domains
> ?- Timeservers: Comma separated list of timeservers
> ?- Domain: Domain name to be used
> +- mDNS.Method: Supported values are "enabled", "disabled", or
> +??"only_resolve". The "only_resolve" value doesn't register the hostname
> +??for mDNS, but allows resolving of mDNS domains. Value "enabled" means
> +??support for both resolving and hostname registration, and "disabled"
> +??means that mDNS support is disabled. Note that mDNS support requires
> +??at the moment using systemd-resolved for DNS (use -s command line option
> +??for connmand).
> ?
> ?If IPv4 address is missing then DHCP is used. If IPv6 address is missing,
> ?then SLAAC or DHCPv6 is used.
> diff --git a/doc/service-api.txt b/doc/service-api.txt
> index 6cdb0bb5..dbdada59 100644
> --- a/doc/service-api.txt
> +++ b/doc/service-api.txt
> > @@ -500,3 +500,21 @@ Properties     string State [readonly]
> > ?                           Possible values are "half" and "full".
> ?
> > ?                           This information is not available.
> +
> > +           dict mDNS [readonly]
> +
> > +                   string Method [readonly]
> +
> > +                           Possible values are "enabled", "disabled", and
> > +                           "only_resolve".
> +
> > +                           If both mDNS resolving and hostname 
> > registration are needed,
> > +                           "enabled" should be selected. If only mDNS 
> > resolving is
> > +                           required, select "only_resolve". Select 
> > "disabled" if mDNS
> > +                           should be disabled for this service.
> +
> > +           dict mDNS.Configuration [readwrite]
> +
> > +                   Same values as mDNS property. The mDNS represents
> > +                   the actual system configuration while this allows
> +                     user configuration.

Is there any reason why mDNS would not always be "enabled"? It doesn't
sound too useful if ConnMan were only able to resolve and not to
register its hostname for other (ConnMan) hosts to see.


> diff --git a/include/service.h b/include/service.h
> index 958e7fd1..5475b26a 100644
> --- a/include/service.h
> +++ b/include/service.h
> @@ -89,6 +89,13 @@ enum connman_service_proxy_method {
> ?     CONNMAN_SERVICE_PROXY_METHOD_AUTO????????= 3,
> ?};
> ?
> +enum connman_service_mdns_method {
> +     CONNMAN_SERVICE_MDNS_METHOD_UNKNOWN??????= 0,
> +     CONNMAN_SERVICE_MDNS_METHOD_ENABLED??????= 1,
> +     CONNMAN_SERVICE_MDNS_METHOD_ONLY_RESOLVE = 2,
> +     CONNMAN_SERVICE_MDNS_METHOD_DISABLED?????= 3,
> +};
> +
> ?enum connman_service_connect_reason {
> ?     CONNMAN_SERVICE_CONNECT_REASON_NONE     = 0,
> ?     CONNMAN_SERVICE_CONNECT_REASON_AUTO     = 1,
> @@ -96,6 +103,7 @@ enum connman_service_connect_reason {
> ?     CONNMAN_SERVICE_CONNECT_REASON_SESSION  = 3,
> ?};
> ?
> +
> ?struct connman_service;
> ?struct connman_network;
> ?
> diff --git a/src/config.c b/src/config.c
> index a8c3da89..5f6abb19 100644
> --- a/src/config.c
> +++ b/src/config.c
> @@ -72,6 +72,7 @@ struct connman_config_service {
> ?     char *ipv6_gateway;
> ?     char *ipv6_privacy;
> ?     char *mac;
> +     char *mdns;
> ?     char **nameservers;
> ?     char **search_domains;
> ?     char **timeservers;
> @@ -112,6 +113,7 @@ static bool cleanup = false;
> ?#define SERVICE_KEY_PASSPHRASE?????????"Passphrase"
> ?#define SERVICE_KEY_SECURITY???????????"Security"
> ?#define SERVICE_KEY_HIDDEN?????????????"Hidden"
> +#define SERVICE_KEY_MDNS???????????????"mDNS.Method"

The dot '.' is not used in other keys...


Cheers,

        Patrik


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

Message: 2
Date: Mon, 02 Oct 2017 16:08:17 +0300
From: Patrik Flykt <[email protected]>
To: Ismo Puustinen <[email protected]>, [email protected]
Subject: Re: [PATCH 1/2] resolver: add support for systemd-resolved.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"


        Hi,

Actually, if we leave resolver.c as it is, and instead conditionally
compile src/dnsproxy.c or src/systemd-resolved.c, wouldn't that solve
most of the code changes in a cleaner way? The "API" would then be the
connman_dnsproxy_* functions in connman.h, that could then move to
/include instead?

Cheers,

        Patrik


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

Message: 3
Date: Mon, 2 Oct 2017 13:27:51 +0000
From: "Puustinen, Ismo" <[email protected]>
To: "[email protected]" <[email protected]>,
        "[email protected]" <[email protected]>
Subject: Re: [PATCH 1/2] resolver: add support for systemd-resolved.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"

On Mon, 2017-10-02 at 16:08 +0300, Patrik Flykt wrote:
>       Hi,
> 
> Actually, if we leave resolver.c as it is, and instead conditionally
> compile src/dnsproxy.c or src/systemd-resolved.c, wouldn't that solve
> most of the code changes in a cleaner way? The "API" would then be
> the
> connman_dnsproxy_* functions in connman.h, that could then move to
> /include instead?

It might. Originally I was thinking of doing something along these
lines. Then I figured that the third option (writing a /etc/resolv.conf
file) is actually bit closer to my approach, because systemd-resolved
doesn't allow adding the servers or domains one-by-one. You need to add
them all in a single D-Bus call, which meant that I could (re)use the
data structures and logic for managing the /etc/resolv.conf writing.

However, a concept of having different DNS backends (/etc/resolv.conf,
dnsproxy, systemd-resolved) is not a bad one. We could just select one
on connman command line (connmand --dns-backend=dnsproxy). Should this
be a full plugin API with function pointers and all? Stuff like mDNS
handling could then be handled as plugin functions.

Ismo

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

Message: 4
Date: Mon, 2 Oct 2017 13:50:03 +0000
From: "Puustinen, Ismo" <[email protected]>
To: "[email protected]" <[email protected]>,
        "[email protected]" <[email protected]>
Subject: Re: [PATCH 2/2] service: add mDNS support on per-interface
        basis.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"

On Mon, 2017-10-02 at 15:57 +0300, Patrik Flykt wrote:
> Is there any reason why mDNS would not always be "enabled"? It
> doesn't
> sound too useful if ConnMan were only able to resolve and not to
> register its hostname for other (ConnMan) hosts to see.

I think that this might potentially cause confusion if there are
multiple devices with the same hostname in the network. This could
happen for some IoT devices. Also, with DNS-SD, it might make sense for
security reasons not to provide service information to the whole
network.

However, when we have the mechanism in place, it becomes just a connman
policy decision to set the initial value.

> > +#define SERVICE_KEY_MDNS               "mDNS.Method"
> 
> The dot '.' is not used in other keys...

Four lines down it's used in "IPv6.Privacy" though. The configuration
file processing is bit hairy. I'll double-check if "Method" has special
handling somewhere, since it seems to be used in many D-Bus dicts but
it's not referenced in config.c.

Ismo

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

Subject: Digest Footer

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


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

End of connman Digest, Vol 24, Issue 4
**************************************

Reply via email to