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: [RFC] wifi: make max connection retries configurable
(M?ns Rullg?rd)
2. Re: [RFC] wifi: make max connection retries configurable
(Daniel Wagner)
3. Re: [RFC] wifi: make max connection retries configurable
(M?ns Rullg?rd)
4. Re: [PATCH v3 5/8] session: Add source ip rule (Daniel Wagner)
5. Re: [PATCH v3 4/8] firewall: Add fwmark based on source ip
address (Daniel Wagner)
6. Re: [PATCH v3 8/8] doc: Session multi-interface routing
(Daniel Wagner)
7. Re: [PATCH v3 0/8] session: Add per-interface routing
(Daniel Wagner)
8. Re: connman multiple IP address support? (Daniel Wagner)
9. Re: [RFC] wifi: make max connection retries configurable
(Daniel Wagner)
10. Re: [RFC] wifi: make max connection retries configurable
(M?ns Rullg?rd)
----------------------------------------------------------------------
Message: 1
Date: Sun, 29 Jan 2017 19:01:34 +0000
From: M?ns Rullg?rd <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Subject: Re: [RFC] wifi: make max connection retries configurable
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-1
Daniel Wagner <[email protected]> writes:
> On 01/29/2017 07:38 PM, M?ns Rullg?rd wrote:
>>>>>> Now that's my reason for adding this setting. I can certainly imagine
>>>>>> it being useful to someone else for different reasons. Is this somehow
>>>>>> a bad idea? There is no change in behaviour unless users explicitly
>>>>>> set a non-default value.
>>>>>
>>>>> I think you need to find an way to address also the point I mentioned.
>>>>
>>>> The lock-out thing? Don't change the default if that's a concern.
>>>
>>> That is not my point.
>>
>> Then what is your point?
>
> I was referring to the default settings.
I don't want to change the default. The default is good for most users.
>>>>> Having such an option in the main.conf is just too confusing in my
>>>>> opinion.
>>>>
>>>> Frankly, I find all of connman too confusing. Feel free to suggest a
>>>> better way.
>>>
>>> Exactly, adding another low level option to connman.conf is not
>>> helping. That is why I ask if you find a way to address the lock-out
>>> and the bad-signal-stop-retry thingy without adding a configuration
>>> option.
>>
>> How do you propose to divine the real reason for a connection failure?
>> As far as I can tell, that information simply doesn't exist.
>
> Yes you are right, but changing the default value to infinity is also
> not helping.
I repeat, I do not want to change the default. I'm quite happy to edit
the setting on the affected systems.
> I was just wondering if it would be possible to come up with an
> algorithm which tells if it is okay to retry or not using signal
> strength and protocol state (e.g. frame sent, no response,
> timeout)... I guess something like this doesn't exist.
Sounds complicated and error-prone.
--
M?ns Rullg?rd
------------------------------
Message: 2
Date: Sun, 29 Jan 2017 20:12:28 +0100
From: Daniel Wagner <[email protected]>
To: M?ns Rullg?rd <[email protected]>
Cc: [email protected]
Subject: Re: [RFC] wifi: make max connection retries configurable
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 01/29/2017 08:01 PM, M?ns Rullg?rd wrote:
> I don't want to change the default. The default is good for most users.
I looks like we are talking Sure, and I don't want to offer the option
to change the default. Looks like we talking cross purposes.
>> I was just wondering if it would be possible to come up with an
>> algorithm which tells if it is okay to retry or not using signal
>> strength and protocol state (e.g. frame sent, no response,
>> timeout)... I guess something like this doesn't exist.
>
> Sounds complicated and error-prone.
Yes, and offering the option in the connman.conf section is also a
source for errors. That is what I try to avoid.
Do you happen to know what NetworkManager does in this situation? Or
Windows, MacOS?
Thanks,
Daniel
------------------------------
Message: 3
Date: Sun, 29 Jan 2017 19:14:46 +0000
From: M?ns Rullg?rd <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Subject: Re: [RFC] wifi: make max connection retries configurable
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-1
Daniel Wagner <[email protected]> writes:
> On 01/29/2017 08:01 PM, M?ns Rullg?rd wrote:
>> I don't want to change the default. The default is good for most users.
>
> I looks like we are talking Sure, and I don't want to offer the option
> to change the default. Looks like we talking cross purposes.
>
>>> I was just wondering if it would be possible to come up with an
>>> algorithm which tells if it is okay to retry or not using signal
>>> strength and protocol state (e.g. frame sent, no response,
>>> timeout)... I guess something like this doesn't exist.
>>
>> Sounds complicated and error-prone.
>
> Yes, and offering the option in the connman.conf section is also a
> source for errors. That is what I try to avoid.
OK, so you basically don't want to solve my problem. I guess we can
stop debating this then.
> Do you happen to know what NetworkManager does in this situation? Or
> Windows, MacOS?
No.
--
M?ns Rullg?rd
------------------------------
Message: 4
Date: Sun, 29 Jan 2017 20:18:31 +0100
From: Daniel Wagner <[email protected]>
To: [email protected], [email protected]
Subject: Re: [PATCH v3 5/8] session: Add source ip rule
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 01/25/2017 07:13 PM, [email protected] wrote:
> From: Lukasz Nowak <[email protected]>
>
> Implement an option for a session to enable packet filtering
> based on interfce source ip address. This allows an application
> to create a session, and direct traffic to a specific network
> interface, on which the session is connected.
>
> Applications can use bind before connect on a socket to specify
> the source ip address.
>
> This mechanism re-uses the routing table created by the session,
> iproute fwmark rule, and adds a new iptables source ip rule.
gcc is not completely happy with this one:
src/session.c: In function ?init_routing_table?:
src/session.c:334:3: error: ?return? with no value, in function returning
non-void [-Werror]
return;
^~~~~~
src/session.c:325:12: note: declared here
static int init_routing_table(struct connman_session *session)
^~~~~~~~~~~~~~~~~~
src/session.c: In function ?init_firewall_session?:
src/session.c:296:8: error: ?ipconfig? may be used uninitialized in this
function [-Werror=maybe-uninitialized]
addr = __connman_ipconfig_get_local(ipconfig);
~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/session.c: In function ?__connman_session_create?:
src/session.c:1583:9: error: ?err? may be used uninitialized in this function
[-Werror=maybe-uninitialized]
return err;
Thanks,
Daniel
------------------------------
Message: 5
Date: Sun, 29 Jan 2017 20:19:21 +0100
From: Daniel Wagner <[email protected]>
To: [email protected], [email protected]
Subject: Re: [PATCH v3 4/8] firewall: Add fwmark based on source ip
address
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Lukasz,
> +static int build_rule_src_ip(const char *src_ip, uint32_t mark, struct
> nftnl_rule **res)
> +{
> + struct nftnl_rule *rule;
> + struct nftnl_expr *expr;
> + int err;
> + in_addr_t s_addr;
> +
> + /*
> + * # nft --debug netlink add rule connman route-output \
> + * ip saddr 192.168.10.31 mark set 1234
> + *
> + * ip connman route-output
> + * [ payload load 4b @ network header + 12 => reg 1 ]
> + * [ cmp eq reg 1 0x1f0aa8c0 ]
> + * [ immediate reg 1 0x000004d2 ]
> + * [ meta set mark with reg 1 ]
> + */
Applying: firewall: Add fwmark based on source ip address
.git/rebase-apply/patch:75: trailing whitespace.
* ip connman route-output
Thanks,
Daniel
------------------------------
Message: 6
Date: Sun, 29 Jan 2017 20:22:22 +0100
From: Daniel Wagner <[email protected]>
To: [email protected], [email protected]
Subject: Re: [PATCH v3 8/8] doc: Session multi-interface routing
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Lukasz,
On 01/25/2017 07:13 PM, [email protected] wrote:
> From: Lukasz Nowak <[email protected]>
>
> Update session overview and API documents to demonstrate how sessions
> can be used to maintain multiple connections in parallel.
> ---
> doc/session-api.txt | 23 +++++++++++++++++++++++
> doc/session-overview.txt | 31 +++++++++++++++++++++++++++++++
> 2 files changed, 54 insertions(+)
>
> diff --git a/doc/session-api.txt b/doc/session-api.txt
> index 3aac535..f089c56 100644
> --- a/doc/session-api.txt
> +++ b/doc/session-api.txt
> @@ -182,3 +182,26 @@ Settings string State [readonly]
> (This setting will be removed when the unique process
> identification problem is solved.)
>
> + string AllowedInterface [readwrite]
> +
> + This field is used to bind a session to a specific
> + network interface. If this field is empty, the first
> + interface from a list of available ones will be used.
> + Also "*" string matches any interface.
> +
> + Only one interface may be specified.
> +
> + If a specified network interface is not available
> + (e.g. because AllowedBearers filters it out), the
> + session will not go online.
> +
> + boolean SourceIPRule [readwrite]
> +
> + If set to true the session will create source IP
> + address rule in the firewall, which redirects traffic
> + to that session's routing table.
> +
> + Each session maintains a dedicated routing table, with
> + a default route. When the source IP rule is enabled,
> + an application can select which session/interface to
> + send traffic on, using bind-before-connect mechanism.
Sorry I missed this last time. Could you also add the [experimental] tag
to both properties? There is still the discussion ongoing with the
source IP routing and maybe we need to touch these here again. Let's
mark them as not stable.
Thanks,
Daniel
------------------------------
Message: 7
Date: Sun, 29 Jan 2017 20:23:40 +0100
From: Daniel Wagner <[email protected]>
To: [email protected], [email protected]
Subject: Re: [PATCH v3 0/8] session: Add per-interface routing
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Lukasz,
On 01/25/2017 07:13 PM, [email protected] wrote:
> From: Lukasz Nowak <[email protected]>
>
> 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
Looks pretty good. I would have applied them if gcc didn't complained.
So I started to nitpick a bit. Sorry about that :)
Thanks,
Daniel
------------------------------
Message: 8
Date: Sun, 29 Jan 2017 20:31:04 +0100
From: Daniel Wagner <[email protected]>
To: Paul Bieganski <[email protected]>, [email protected]
Subject: Re: connman multiple IP address support?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Paul,
On 01/25/2017 11:29 PM, Paul Bieganski wrote:
> It appears that connman does not support multiple IP addresses on the
> same interface (wired or wifi) - this is what is sometimes referred to
> as "IP aliasing".
>
> Can anyone please confirm if that's indeed the case and if there are any
> plans to support it. This is a key function for us (and many embedded
> devices) and seems like an unfortunate oversight.
Unfortunately, your analysis is correct. Correctly, ConnMan handles only
one IP address per interface:
struct connman_ipaddress {
int family;
unsigned char prefixlen;
char *local;
char *peer;
char *broadcast;
char *gateway;
};
struct connman_ipconfig {
[...]
struct connman_ipaddress *address;
struct connman_ipaddress *system;
[...]
};
struct connman_ipdevice {
[...]
struct connman_ipconfig *config_ipv4;
struct connman_ipconfig *config_ipv6;
[...]
};
Are you planing to work on this?
Thanks,
Daniel
------------------------------
Message: 9
Date: Sun, 29 Jan 2017 20:36:26 +0100
From: Daniel Wagner <[email protected]>
To: M?ns Rullg?rd <[email protected]>
Cc: [email protected]
Subject: Re: [RFC] wifi: make max connection retries configurable
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 01/29/2017 08:14 PM, M?ns Rullg?rd wrote:
> Daniel Wagner <[email protected]> writes:
>> On 01/29/2017 08:01 PM, M?ns Rullg?rd wrote:
>>> I don't want to change the default. The default is good for most users.
>>
>> I looks like we are talking Sure, and I don't want to offer the option
>> to change the default. Looks like we talking cross purposes.
>>
>>>> I was just wondering if it would be possible to come up with an
>>>> algorithm which tells if it is okay to retry or not using signal
>>>> strength and protocol state (e.g. frame sent, no response,
>>>> timeout)... I guess something like this doesn't exist.
>>>
>>> Sounds complicated and error-prone.
>>
>> Yes, and offering the option in the connman.conf section is also a
>> source for errors. That is what I try to avoid.
>
> OK, so you basically don't want to solve my problem. I guess we can
> stop debating this then.
Heh, don't jump to conclusion so fast. I just stated that exposing this
to connman.conf needs proper considerations. This is a slippery road.
>> Do you happen to know what NetworkManager does in this situation? Or
>> Windows, MacOS?
>
> No.
If NM or the others would do the same as you propose, it would be an
excellent argument.
Thanks
Daniel
------------------------------
Message: 10
Date: Sun, 29 Jan 2017 19:42:45 +0000
From: M?ns Rullg?rd <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Subject: Re: [RFC] wifi: make max connection retries configurable
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-1
Daniel Wagner <[email protected]> writes:
> On 01/29/2017 08:14 PM, M?ns Rullg?rd wrote:
>> Daniel Wagner <[email protected]> writes:
>>> On 01/29/2017 08:01 PM, M?ns Rullg?rd wrote:
>>>> I don't want to change the default. The default is good for most users.
>>>
>>> I looks like we are talking Sure, and I don't want to offer the option
>>> to change the default. Looks like we talking cross purposes.
>>>
>>>>> I was just wondering if it would be possible to come up with an
>>>>> algorithm which tells if it is okay to retry or not using signal
>>>>> strength and protocol state (e.g. frame sent, no response,
>>>>> timeout)... I guess something like this doesn't exist.
>>>>
>>>> Sounds complicated and error-prone.
>>>
>>> Yes, and offering the option in the connman.conf section is also a
>>> source for errors. That is what I try to avoid.
>>
>> OK, so you basically don't want to solve my problem. I guess we can
>> stop debating this then.
>
> Heh, don't jump to conclusion so fast. I just stated that exposing
> this to connman.conf needs proper considerations. This is a slippery
> road.
What about making it a per-connection setting stored along with ssid and
psk?
--
M?ns Rullg?rd
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 15, Issue 37
***************************************
