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 v3] gsupplicant: Optimize AddNetwork Handler by
avoiding DBUS call. (Patrik Flykt)
2. Re: Manual DNS configuration with DHCP services (Patrik Flykt)
3. Re: [PATCH] bluetooth: Remove Bluez 4.x support (Patrik Flykt)
4. Re: [PATCH v3] gsupplicant: Optimize AddNetwork Handler by
avoiding DBUS call. (Naveen Singh)
----------------------------------------------------------------------
Message: 1
Date: Thu, 24 Mar 2016 10:36:58 +0200
From: Patrik Flykt <[email protected]>
To: Naveen Singh <[email protected]>
Cc: [email protected], Naveen Singh <[email protected]>
Subject: Re: [PATCH v3] gsupplicant: Optimize AddNetwork Handler by
avoiding DBUS call.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Tue, 2016-03-22 at 12:25 -0700, Naveen Singh wrote:
> I think this patch standalone would break things. This patch needs to
> be applied with the other patch "Do Not disable network on
> Disconnect".
> What would happen now with just this patch is that on disconnect
> notification, we will disable the network. This will cause
> wpa_supplicant to stop trying to connect. But at this point
> network_path is still valid. Any further connect attempt with the same
> network would not go through because we do this additional check if it
> is same SSID. And since in this case SSID is same, AddNetwork will be
> dropped. Now this is a complete deadlock until we have a different
> SSID to attempt to.
>
>
> It was my bad that I split this patch in two but when I did it, it was
> supposed to answer two different issues and later on i realized that
> there is dependency. Can you revert back this patch. I am really very
> sorry for this.
> I can create another patch with other changes and you can review it.
Darn. As a dependency was discovered, please in the future send a patch
set so that it is clear that the patches depend on each other. Meanwhile
I can revert the patch.
Cheers,
Patrik
------------------------------
Message: 2
Date: Thu, 24 Mar 2016 11:02:36 +0200
From: Patrik Flykt <[email protected]>
To: "Moberg, Patrik" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: Manual DNS configuration with DHCP services
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
Hi,
On Wed, 2016-03-23 at 14:23 +0000, Moberg, Patrik wrote:
> What is the best practise when using Connman to achieve manual
> configuration of DNS when using DHCP based services? The goal is to
> regardless of which service that is online always use a manual DNS.
Each service that needs to use different nameservers than what can be
obtained from DHCP needs to have its Nameservers.Configuration attribute
set via D-Bus at runtime or have the 'Nameservers' attribute specified
in its provisioned .config file. There is no global override for all
services as that is a very special case not necessarily applicable to
the majority of users.
> With auto connect disabled, I have tried to set
> ?Nameservers.Configuration? (via d-bus) to an IP address prior to the
> service being connected (connect done via d-bus as well). The service
> then looks ok with the proper IP address in ?Nameservers? for the
> service.
This can be done at runtime via D-Bus. If it doesn't work as expected,
there's a bug and we'll fix it.
> However the routing table is then unexpectedly populated. For
> example, the default gateway entry has destination set to IP in
> ?Nameservers.Configuration?, with gateway set to DHCP DNS IP address,
> and netmask 255.255.255.255.
A host route entry is created for all nameservers and the DHCP server.
This to ensure there exists is a route to the nameservers even without a
default gateway assigned, and also that the DHCP server can be reached
should DHCP proxies be used in the network so that the DHCP server can
be located outside of the subnet. One or more of these functions can
then again be handled by the default gateway.
Check the IP addresses involved for these functions and post the routing
table here if it still looks weird. In that case please also state which
version of ConnMan this is.
Cheers,
Patrik
------------------------------
Message: 3
Date: Thu, 24 Mar 2016 11:34:39 +0200
From: Patrik Flykt <[email protected]>
To: [email protected]
Subject: Re: [PATCH] bluetooth: Remove Bluez 4.x support
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Tue, 2015-12-29 at 14:01 +0200, Patrik Flykt wrote:
> Remove Bluez 4.x support as the 4.x versions have been discontinued
> for quite some time already. Bluez 5.x versions have been supported
> since ConnMan 1.11 and are actively maintained.
> ---
Updated commit message and applied. Bluez 4.x support is now removed.
Any vendor wishing to still use Bluez 4.x can revert this patch but
neither ConnMan nor Bluez upstream are committed to support Bluez 4.x.
Cheers,
Patrik
------------------------------
Message: 4
Date: Thu, 24 Mar 2016 10:43:49 -0700
From: Naveen Singh <[email protected]>
To: Patrik Flykt <[email protected]>
Cc: [email protected], Naveen Singh <[email protected]>
Subject: Re: [PATCH v3] gsupplicant: Optimize AddNetwork Handler by
avoiding DBUS call.
Message-ID:
<cafk1zravdccqeueaed0ps4l4+yerpxur8nstfe774zymcpm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Thu, Mar 24, 2016 at 1:36 AM, Patrik Flykt <[email protected]>
wrote:
> On Tue, 2016-03-22 at 12:25 -0700, Naveen Singh wrote:
> > I think this patch standalone would break things. This patch needs to
> > be applied with the other patch "Do Not disable network on
> > Disconnect".
> > What would happen now with just this patch is that on disconnect
> > notification, we will disable the network. This will cause
> > wpa_supplicant to stop trying to connect. But at this point
> > network_path is still valid. Any further connect attempt with the same
> > network would not go through because we do this additional check if it
> > is same SSID. And since in this case SSID is same, AddNetwork will be
> > dropped. Now this is a complete deadlock until we have a different
> > SSID to attempt to.
> >
> >
> > It was my bad that I split this patch in two but when I did it, it was
> > supposed to answer two different issues and later on i realized that
> > there is dependency. Can you revert back this patch. I am really very
> > sorry for this.
> > I can create another patch with other changes and you can review it.
>
> Darn. As a dependency was discovered, please in the future send a patch
> set so that it is clear that the patches depend on each other. Meanwhile
> I can revert the patch.
>
> Cheers,
>
> Patrik
>
Thanks Patrik. I will take care of this in future.
Regards
Naveen
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20160324/1e931a74/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 5, Issue 30
**************************************
