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. a question about dhcp-failed service error property (Xiaodong Sun)
2. Re: [PATCH v2] Replace g_timeout_add_seconds() with 0 as
timeout to g_idle_add() (Daniel Wagner)
3. Re: [PATCH v2] Replace g_timeout_add_seconds() with 0 as
timeout to g_idle_add() (Daniel Wagner)
4. Re: [PATCH v2 2/7] session: add allowed interface config
parameter (Daniel Wagner)
5. Re: [PATCH v2 7/7] doc: session multi-interface routing
(Daniel Wagner)
6. Re: [PATCH v2 0/7] session: add per-interface routing
(Daniel Wagner)
7. Re: a question about dhcp-failed service error property
(Daniel Wagner)
8. Re: HTTP GET usage for Ready to Online state transition
(Slava Monich)
9. Re: HTTP GET usage for Ready to Online state transition
(Marcel Holtmann)
10. Re: HTTP GET usage for Ready to Online state transition
(Lukasz Nowak)
----------------------------------------------------------------------
Message: 1
Date: Mon, 23 Jan 2017 14:12:30 -0800
From: Xiaodong Sun <[email protected]>
To: [email protected]
Subject: a question about dhcp-failed service error property
Message-ID:
<CAEoBSRog8VrAE3zN72_P6VbxqShJg4n2dfxiY9ABs=nbqac...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I looked at connman source code. The "dhcp-failed" service error property
is defined, but is NOT actually plugged. Should this be a bug? or this
property need to be removed? I am looking for this service dhcp-failed
property as part of collecting network telemetry data. I hope this is a bug
so that I can change the code to make it plugged. Thanks!
BR
Xiaodong
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20170123/d9be7be3/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 24 Jan 2017 07:34:21 +0100
From: Daniel Wagner <[email protected]>
To: Saurav Babu <[email protected]>, [email protected]
Cc: [email protected]
Subject: Re: [PATCH v2] Replace g_timeout_add_seconds() with 0 as
timeout to g_idle_add()
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Saurav,
On 01/23/2017 10:27 AM, Saurav Babu wrote:
> Passing 0 as timeout to g_timeout_add()/g_timeout_add_seconds() is equivalent
> to g_idle_add(). According to glib documentation "the first call of the timer
> may not be precise for timeouts of one second."
Excellent work! Note: I have spitted the patch up for each of the
subdirectories and applied them. No other changes.
Thanks,
Daniel
------------------------------
Message: 3
Date: Tue, 24 Jan 2017 07:37:03 +0100
From: Daniel Wagner <[email protected]>
To: Saurav Babu <[email protected]>, [email protected]
Cc: [email protected]
Subject: Re: [PATCH v2] Replace g_timeout_add_seconds() with 0 as
timeout to g_idle_add()
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Saurav,
On 01/23/2017 10:27 AM, Saurav Babu wrote:
> Passing 0 as timeout to g_timeout_add()/g_timeout_add_seconds() is equivalent
> to g_idle_add(). According to glib documentation "the first call of the timer
> may not be precise for timeouts of one second."
Excellent work! I've splitted the patch into 3 parts, each for the
subdirectories and applied them.
Thanks,
Daniel
------------------------------
Message: 4
Date: Tue, 24 Jan 2017 07:40:57 +0100
From: Daniel Wagner <[email protected]>
To: Lukasz Nowak <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH v2 2/7] session: add allowed interface config
parameter
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Good Morning Lukasz,
On 01/23/2017 01:30 PM, Lukasz Nowak wrote:
>> For AllowedBearer we have 'any' as match any available bearer. If
>> the string is empty it means no bearer is allowed. I wonder if we
>> should follow the AllowedBearer approach to keep it more
>> consistent.
>
> I am not sure if this is the case. "any" is used for ConnectionType,
> but there is no equivalent for AllowedBearers - user has to explicitly
> provide an array of strings. There is no way to specify any/all as far
> as I can see. For AllowedInterface, I chose an empty string, as an
> interface can have an arbitrary name. So in theory you could have a real
> interface named "any".
You are right, I confused ConnectionType with AllowedBearers.
AllowedBearers has the '*' for the meaning match any bearer type.
Wouldn't '*' also work for AllowedInterface?
Thanks,
Daniel
------------------------------
Message: 5
Date: Tue, 24 Jan 2017 07:43:43 +0100
From: Daniel Wagner <[email protected]>
To: Lukasz Nowak <[email protected]>, [email protected]
Subject: Re: [PATCH v2 7/7] doc: session multi-interface routing
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Good Morning Lukasz,
On 01/23/2017 01:35 PM, Lukasz Nowak wrote:
>> nitpick s/ip/IP ?
>
> I am not sure if I follow - would you like to change the "SourceIPRule" name?
> Or "source ip" in the description text?
I tried to say use IP instead of ip in the text. The idea is to stay
consistent with the use of abbreviations.
>> And if I read it correctly it is only IPv4, correct? Hmm, the
>> whole firewall code is not IPv6 ready... another todo on my list...
>
> Yes, the whole thing is IPv4. It is not just firewall - session
> itself has several places without IPv6 as well. I don't think that the
> per-session routing tables would set up IPv6.
That is probably a bigger project :)
Thanks,
Daniel
------------------------------
Message: 6
Date: Tue, 24 Jan 2017 07:44:55 +0100
From: Daniel Wagner <[email protected]>
To: Lukasz Nowak <[email protected]>, 'Marcel Holtmann'
<[email protected]>
Cc: [email protected]
Subject: Re: [PATCH v2 0/7] session: add per-interface routing
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Lukasz,
On 01/23/2017 01:37 PM, Lukasz Nowak wrote:
> Hi Daniel,
>
> I will change the capitals.
> I am hoping to have nftables implementation finished in the next few
> days. I will provide a v3 with all the small changes then.
Excellent! Looking forward to your patches.
Thanks,
Daniel
------------------------------
Message: 7
Date: Tue, 24 Jan 2017 07:47:59 +0100
From: Daniel Wagner <[email protected]>
To: [email protected], [email protected]
Subject: Re: a question about dhcp-failed service error property
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi,
On 01/23/2017 11:12 PM, Xiaodong Sun wrote:
> I looked at connman source code. The "dhcp-failed" service error
> property is defined, but is NOT actually plugged. Should this be a bug?
> or this property need to be removed? I am looking for this service
> dhcp-failed property as part of collecting network telemetry data. I
> hope this is a bug so that I can change the code to make it plugged. Thanks!
I just checked: the dhcp-failed will be propagated via
service.c:append_properties().
Maybe I misunderstood you: what do you mean with 'NOT actually plugged'?
Thanks,
Daniel
------------------------------
Message: 8
Date: Tue, 24 Jan 2017 11:37:52 +0200
From: Slava Monich <[email protected]>
To: [email protected]
Subject: Re: HTTP GET usage for Ready to Online state transition
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Lukasz,
> Hi,
>
> Currently, ConnMan uses an http get operation to transition a service from
> Ready to Online state.
> This is implemented in the wispr module, where a hard-coded http url is used:
>
> #define STATUS_URL_IPV4 "http://ipv4.connman.net/online/status.html";
> #define STATUS_URL_IPV6 "http://ipv6.connman.net/online/status.html";
>
> Additionally, the http server must return a custom header in the reply:
> "X-ConnMan-Status"
>
> This is a problem for us, as we are planning to release a product, which must
> not depend on the ConnMan's http server.
>
> I think we need to make a change to add a config field, which allows the user
> to:
> - provide a custom http URL
> - disable http get - automatically transition from Ready to Online state -
> let the application detect the end-to-end connectivity
>
> I am not sure what to do with the "X-ConnMan-Status" http reply header.
> Should checking of it be disabled in case the config provides a URL from the
> user?
> I realise that this functionality is also used to detect proxies, so I would
> keep the current code as default, and provide an optional config field to
> change wispr URL or disable it.
>
> Does this make sense?
>
> It is an issue we definitely have to address to use ConnMan. I would like to
> make changes, which would be usable by others too.
We did a similar thing a few years ago:
https://git.merproject.org/mer-core/connman/commit/f3c9364c
If that looks sane to you and upstream is willing to take it, I could
submit it as a patch.
Cheers,
-Slava
------------------------------
Message: 9
Date: Tue, 24 Jan 2017 11:40:04 +0100
From: Marcel Holtmann <[email protected]>
To: Lukasz Nowak <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: HTTP GET usage for Ready to Online state transition
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Lukasz,
> Currently, ConnMan uses an http get operation to transition a service from
> Ready to Online state.
> This is implemented in the wispr module, where a hard-coded http url is used:
>
> #define STATUS_URL_IPV4 "http://ipv4.connman.net/online/status.html";
> #define STATUS_URL_IPV6 "http://ipv6.connman.net/online/status.html";
>
> Additionally, the http server must return a custom header in the reply:
> "X-ConnMan-Status"
>
> This is a problem for us, as we are planning to release a product, which must
> not depend on the ConnMan's http server.
>
> I think we need to make a change to add a config field, which allows the user
> to:
> - provide a custom http URL
> - disable http get - automatically transition from Ready to Online state -
> let the application detect the end-to-end connectivity
>
> I am not sure what to do with the "X-ConnMan-Status" http reply header.
> Should checking of it be disabled in case the config provides a URL from the
> user?
> I realise that this functionality is also used to detect proxies, so I would
> keep the current code as default, and provide an optional config field to
> change wispr URL or disable it.
>
> Does this make sense?
>
> It is an issue we definitely have to address to use ConnMan. I would like to
> make changes, which would be usable by others too.
what is wrong with --disable-wispr configure switch? After that everything goes
via the agent.
Regards
Marcel
------------------------------
Message: 10
Date: Tue, 24 Jan 2017 11:00:38 +0000
From: Lukasz Nowak <[email protected]>
To: Marcel Holtmann <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: HTTP GET usage for Ready to Online state transition
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Marcel,
On 24/01/17 10:40, Marcel Holtmann wrote:
> Hi Lukasz,
>
>> Currently, ConnMan uses an http get operation to transition a service from
>> Ready to Online state.
>> This is implemented in the wispr module, where a hard-coded http url is used:
>>
>> #define STATUS_URL_IPV4 "http://ipv4.connman.net/online/status.html";
>> #define STATUS_URL_IPV6 "http://ipv6.connman.net/online/status.html";
>>
>> Additionally, the http server must return a custom header in the reply:
>> "X-ConnMan-Status"
>>
>> This is a problem for us, as we are planning to release a product, which
>> must not depend on the ConnMan's http server.
>>
>> I think we need to make a change to add a config field, which allows the
>> user to:
>> - provide a custom http URL
>> - disable http get - automatically transition from Ready to Online state -
>> let the application detect the end-to-end connectivity
>>
>> I am not sure what to do with the "X-ConnMan-Status" http reply header.
>> Should checking of it be disabled in case the config provides a URL from the
>> user?
>> I realise that this functionality is also used to detect proxies, so I would
>> keep the current code as default, and provide an optional config field to
>> change wispr URL or disable it.
>>
>> Does this make sense?
>>
>> It is an issue we definitely have to address to use ConnMan. I would like to
>> make changes, which would be usable by others too.
>
> what is wrong with --disable-wispr configure switch? After that everything
> goes via the agent.
I have --disable-wispr defined. That only disables tools/wispr.c. The
src/wispr.c is always compiled and it always makes the HTTP GET call to the
hard-coded URL to transition any service to Online state.
>
> Regards
>
> Marcel
>
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 15, Issue 25
***************************************
