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 v5 0/8] session: Add per-interface routing
(Daniel Wagner)
2. Re: Service remains on service list even if it is not longer
available (Daniel Wagner)
3. Re: Wi-Fi specific information in connman (Daniel Wagner)
4. Re: [PATCH] session: Maintain bearer priority in policy file
and check for other services when service lost (Daniel Wagner)
----------------------------------------------------------------------
Message: 1
Date: Sat, 4 Feb 2017 19:04:59 +0100
From: Daniel Wagner <[email protected]>
To: Lukasz Nowak <[email protected]>, [email protected]
Subject: Re: [PATCH v5 0/8] session: Add per-interface routing
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Lukasz,
On 02/03/2017 11:43 AM, Lukasz Nowak wrote:
> From: Lukasz Nowak <[email protected]>
>
> changes from v4:
> - replaced "0 == g_strcmp0" with "!g_strcmp0"
> - fixed the last compiler warning
>
> changes from v3:
> - fixed compiler warnings
> - marked new session config fields as experimental
>
> changes from v2:
> - implemented source IP rule in firewall-nftables
> - using "*" or "" for AllowedInterface allows any interface
>
> changes from v1:
> - added documentation
> - split firewall and session changes into separate commits
> - cosmetic updates after v1 review
>
> Adding a new feature to the sessions, which allows applications to direct
> routed traffic to a specific network interface.
>
> This requires that multiple default routes with gateways are set up, one
> for each interface. And then iproute and iptables rules need to be added
> to direct traffic based on source ip address, to the correct routing table.
> Applications can use bind before connect mechanism, to bind sockets to
> required interfaces.
>
> The application side can be tested with:
> ping -I <interface_ip> <target_ip>
>
> Use case for this is to have multiple network interfaces available for
> external traffic at the same time. It can be used to validate that a full
> path to an external server is working properly, by maintaining multiple
> tcp connections, one for each interface.
All patches applied.
Thanks,
Daniel
------------------------------
Message: 2
Date: Sat, 4 Feb 2017 19:08:37 +0100
From: Daniel Wagner <[email protected]>
To: Jose Blanquicet <[email protected]>, [email protected],
"MANIEZZO Marco (MM)" <[email protected]>
Subject: Re: Service remains on service list even if it is not longer
available
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Jose,
On 02/03/2017 09:20 AM, Jose Blanquicet wrote:
> On Fri, Jan 27, 2017 at 4:28 PM, Jose Blanquicet <[email protected]> wrote:
>> When we get disconnected because of AP we are connected to goes out of
>> range. ConnMan keeps showing such AP in the services list even though
>> it is not longer available (We cannot connect to it). In addition,
>> such AP will continue in our service list even if we connect to a new
>> one. What is the propose of keeping that AP in the services list? From
>> our point of view it creates confusion to the user. We would prefer to
>> not do that, what do people think?
>
> Ping? Is it how it supposed to be?
Sorry, somehow your question fall through the cracks. If I am not
complete mistaken, ConnMan will show all AP which wpa_s lists. So if
wpa_s is not removing the AP than you still will see it listed.
Obviously, that is not what should happen. I suggest to check what wpa_s
is doing by monitoring it.
Thanks,
Daniel
------------------------------
Message: 3
Date: Sat, 4 Feb 2017 19:45:07 +0100
From: Daniel Wagner <[email protected]>
To: Saurav Babu <[email protected]>, [email protected]
Cc: [email protected]
Subject: Re: Wi-Fi specific information in connman
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Saurav,
On 02/03/2017 10:57 AM, Saurav Babu wrote:
>> On 01/11/2017 02:04 PM, Patrik Flykt wrote:
>>> On Wed, 2017-01-11 at 16:43 +0530, Saurav Babu wrote:
>>>> There are few applications which require Wi-Fi specific informations
>>>> like MAC Address, Frequency/Channel of AP. Is there any specific
>>>> reason that these informations are not stored by connman?
>
>> Can you elaborate a bit on your use case? I'd like to understand why you
>> want that information. One thing which comes to my mind is that you want
>> to show it to the user.
>
> For WPS PBC and PIN connection wpa_supplicant allows BSSID to be passed as
> argument. If BSSID is passed as argument to WPS Connection and any other
> device
> tries to use PBC then negotiation is rejected by wpa_supplicant.
And the wifi plugin doesn't set the BSSID when doing WPS? If so, is that
something ConnMan can't figure out itself? I tried to understand what
happens in the supplicant.c file but well... hard to read.
> Currently ConnMan doesn't provide any way to perform channel based scan. It
> always performs full channel scan which takes more time compared to single
> channel scan. With knowledge of frequency application can decide to trigger
> full channel or channel based scan for greater authority in connection
> mechanism.
Instead a global scan you just want to scan for a service, is this correct?
And if I am get that right we would need to change the
net.connman.Technologly.Scan() API in the end. The Technology API has a
generic API without any device specific parts in. So adding there some
sort of channel information etc is breaking this. That would be a sad
thing to do :(
The only thing I can see is to pass in the Service D-Bus object path, e.g.
net.connman.Technology.Scan('/net/connman/service/wifi_XXXX_YYYY_managed_psk')
In this case you wouldn't even need to expose the channel and frequency
information because we could do the booking keeping inside ConnMan.
Thanks,
Daniel
------------------------------
Message: 4
Date: Sat, 4 Feb 2017 19:51:23 +0100
From: Daniel Wagner <[email protected]>
To: Daryl Nebrich <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] session: Maintain bearer priority in policy file
and check for other services when service lost
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 02/03/2017 03:22 PM, Daryl Nebrich wrote:
> Ok, thanks for your patience. First time doing this. Will resubmit shortly.
It is not easy to get all those patch formatting and submitting correct.
At least not in the first go. Everybody went through that. And you're
skills are clearly improving. So no worries :)
> Btw, I didn't get any list emails during the day ET yesterday. They
> all came in overnight. Someone else mentioned seeing delays also.
Haven't noticed anything like this but than I am not monitoring it all
the time. There were some hickups in the past. But all of them
disappeared after a while. Let us know if this problem persists.
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 16, Issue 9
**************************************
