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: Connman v1.33 with systemd v230 : experiencing delay in
IP assignment (Shrikant Bobade)
2. Re: Connman v1.33 with systemd v230 : experiencing delay in
IP assignment (Shrikant Bobade)
3. Re: Connman v1.33 with systemd v230 : experiencing delay in
IP assignment (Daniel Wagner)
4. Re: Tether WiFi to cellular modem uplink (Daniel Wagner)
5. Re: [PATCH 2/5] session: add allowed interface config
parameter (Daniel Wagner)
6. Re: [PATCH 4/5] session: add source ip rule (Daniel Wagner)
----------------------------------------------------------------------
Message: 1
Date: Thu, 15 Dec 2016 18:25:45 +0530
From: Shrikant Bobade <[email protected]>
To: Patrik Flykt <[email protected]>
Cc: [email protected]
Subject: Re: Connman v1.33 with systemd v230 : experiencing delay in
IP assignment
Message-ID:
<CALwQEroqn-=Q1rH3-oB2XcQC2wT5RvqJiM=daj4uhsslzem...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Patrik,
On Wed, Dec 14, 2016 at 7:07 PM, Patrik Flykt <[email protected]>
wrote:
>
> Hi,
>
> On Fri, 2016-12-09 at 19:07 +0530, Shrikant Bobade wrote:
> > Checked with connman incrementally from v1.30 to v1.33, found out the
> > delay behaviour almost similar on my setup.
> > Also ensured systemd-networkd is not running on my setup.
> >
> > Further observed with less available entropy.. on the setup causing
> > the delay. So continuing with v1.33.
>
> What system was this again? Sounds like there is not enough entropy
> when the system has booted.
>
> Just for the sake of testing it, I see a number about 3-4k in
> /proc/sys/kernel/random/entropy_avail.
>
>
It is yocto based embedded target..
Yes, the setup with almost no entropy available..
So using rngd
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-support/rng-tools/rng-tools_5.bb?h=morty
to get the enough entropy available.
> > Please advise, we suppose to use only /dev/random for better security
>
> Better security, yes. But randomness is exhausted far more easily, and
> there wasn't enough entropy on your system in the first place. So it
> doesn't help at all in your case.
>
> yes, with almost no entropy at first getting the entropy is priority.
> > reasons and not /dev/urandom ? thoughts if any for other ways to deal
> > with less/no entropy available with /dev/random?
>
> Daniel posted a man page snippet describing urandom. Reading the man
> page convinces me that /dev/urandom is decent enough for our purposes.
> Besides it does not run out in the same way /dev/random does.
>
>
yes, Daniel's post was helpful, thanks for details.
> ConnMan uses /dev/urandom by default, that file should always provide
> "randomness" from the kernel. I didn't understand what you meant with
> gnutls being involved in /dev/urandom.
>
> > Any pointers or references will be a great help..
>
> I haven't heard of this kind of problem before. I do have a
> urandom.service enabled and started on my system. It saves and restores
> a random seed over reboot. You might not have a service like this
> running at bootup, and with a userless device it might take a while for
> the device to generate enough randomness?
>
>
> On similar lines.. using rngd.service w.r.to rng-tools at bootup, serving
enough entropy ~3-4k, & then observed getrandom hang.
> Cheers,
>
> Patrik
>
Thanks for the response.
-thanks
Shrikant
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20161215/b8ada178/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 15 Dec 2016 18:29:45 +0530
From: Shrikant Bobade <[email protected]>
To: Andr? Draszik <[email protected]>
Cc: [email protected], Patrik Flykt <[email protected]>
Subject: Re: Connman v1.33 with systemd v230 : experiencing delay in
IP assignment
Message-ID:
<calwqerrtlzrnqclamxe7dxg5zd2wyw522bhzc2osqveqx41...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Andre,
On Wed, Dec 14, 2016 at 7:49 PM, Andr? Draszik <[email protected]> wrote:
> Hi,
>
> On Fri, 2016-12-09 at 19:07 +0530, Shrikant Bobade wrote:
> >
> [...]
> > Further observed with less available entropy.. on the setup causing the
> > delay. So continuing with v1.33.
> >
> > e.g.
> >
> >
> > *:~# cat
> > /proc/sys/kernel/random/entropy_avail
> > 0*
> >
> > Getting connman waiting/stuck at
> > *getrandom (_rnd_get_system_entropy_getrandom) (by default gnutls
> > enabled)*
> > So tried to increase entropy with help of /dev/urandom & and with
> > sufficient ~3k+ entropy count observed the getrandom call completed
> > successfully.
> > Is this know behaviour Or experienced by anyone.. ?
>
> I think I have seen something similar here, but never investigated in
> depth as of yet.
>
ok.
>
> >
> > [...]
>
> > reasons and not /dev/urandom ? thoughts if any for other ways to deal
> with
> > less/no entropy available with /dev/random?
> > http://security.stackexchange.com/questions/122155/how-bad-
> it-is-to-feed-d
> > ev-random-with-dev-urandom
> > http://stackoverflow.com/questions/3690273/did-i-
> understand-dev-urandom#co
> > mment30985465_3709644
> >
> > Any pointers or references will be a great help..
>
> For me, the combination of removing GnuTLS usage in ConnMan (disable wispr)
> as well as switching all applications to use OpenSSL rather than GnuTLS
> (wpa-supplicant in particular) was sufficient to work around this for the
> time being. Probably because OpenSSL handles /dev/random & /dev/urandom
> differently than GnuTLS.
>
> thanks for pointers..
but may be replacing gnutls may not be possible in short term on my setup.
> I had also considered adding timer-entropyd https://www.vanheusden.com/te/
> but didn't need to in the end.
>
ok
>
>
> Cheers,
> Andre'
>
>
Thanks for the response.
-thanks
Shrikant
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20161215/713711ac/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 15 Dec 2016 17:06:50 +0100
From: Daniel Wagner <[email protected]>
To: Shrikant Bobade <[email protected]>
Cc: [email protected]
Subject: Re: Connman v1.33 with systemd v230 : experiencing delay in
IP assignment
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Shrikant,
On 12/15/2016 01:47 PM, Shrikant Bobade wrote:
> Reading symbols from /usr/sbin/connmand...Reading symbols from
> /usr/sbin/.debug/connmand...done.
> done.
> (gdb) r -d -n
> Starting program: /usr/sbin/connmand -d -n
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/libthread_db.so.1".
> ^C
> Program received signal SIGINT, Interrupt.
> 0x76c3193c in syscall () from /lib/libc.so.6
> (gdb) bt
> #0 0x76c3193c in syscall () from /lib/libc.so.6
> #1 0x76e272a8 in force_getrandom (flags=0, buflen=<optimized out>,
> buf=<optimized out>) at ../../../gnutls-3.5.3/lib/nettle/rnd-linux.c:80
> #2 _rnd_get_system_entropy_getrandom (_rnd=<optimized out>, size=<optimized
> out>) at ../../../gnutls-3.5.3/lib/nettle/rnd-linux.c:98
> #3 0x76e24344 in do_device_source (init=init@entry=1,
> event=event@entry=0x7efffcdc, ctx=0x76e62a38 <rnd_ctx>) at
> ../../../gnutls-3.5.3/lib/nettle/rnd.c:132
> #4 0x76e244ac in wrap_nettle_rnd_init (ctx=<optimized out>) at
> ../../../gnutls-3.5.3/lib/nettle/rnd.c:234
> #5 0x76d72a28 in _gnutls_rnd_init () at ../../gnutls-3.5.3/lib/random.c:49
> #6 0x76d64dfc in _gnutls_global_init (constructor=constructor@entry=1) at
> ../../gnutls-3.5.3/lib/global.c:307
> #7 0x76d3d948 in lib_init () at ../../gnutls-3.5.3/lib/global.c:504
> #8 0x76fdf2dc in call_init.part () from /lib/ld-linux-armhf.so.3
> #9 0x76fdf438 in _dl_init () from /lib/ld-linux-armhf.so.3
> #10 0x76fcfac4 in _dl_start_user () from /lib/ld-linux-armhf.so.3
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb)
Unfortunately, the ConnMan part is missing. But from our discussion I
expect gnutls is involved doing the wispr stuff. Though as I said, I
don't understand why this blocks the IP address assignment.
> The particular delay of assigning IP addresses was in term of getrandom
> hang,
> when connmon.service get multiple attempts...during these attempts
> minimal entropy available ranging from 10 to 30.. to moved ahead of
> getrandom..
I think I don't really understand what you describe here. Does 'attempt'
mean the user/application tries to tell ConnMan establish a connection
and this is done using the D-Bus API. Or do you mean the auto connect
state machine?
Thanks,
Daniel
------------------------------
Message: 4
Date: Thu, 15 Dec 2016 17:10:59 +0100
From: Daniel Wagner <[email protected]>
To: Evade Flow <[email protected]>
Cc: [email protected]
Subject: Re: Tether WiFi to cellular modem uplink
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
> I really wish I knew what I was doing wrong here. Any advice?
I suggest you ask on the oFono mailing list. Denis has usually some good
advice.
Thanks,
Daniel
------------------------------
Message: 5
Date: Thu, 15 Dec 2016 17:25:14 +0100
From: Daniel Wagner <[email protected]>
To: Lukasz Nowak <[email protected]>, [email protected]
Subject: Re: [PATCH 2/5] session: add allowed interface config
parameter
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 12/14/2016 06:32 PM, Lukasz Nowak wrote:
>> I just wonder if the D-Bus API is necessary. From the description I
>> got the impression this is a more static setup in the sense that
>> the interface do not change at all.
> I assumed that we do not want to automatically create the
> per-interface routing tables and rules for all interfaces. Hence the
> API for an application to enable that feature. Would you rather have
> it enabled all the time?
My question is mainly how the D-Bus API should look like. Usually there
is some discussion before we agree on extending it. The reason is we
try to keep it as simple as possible and try not adding random bits and
pieces which might make our life hard in the future.
So I would like to ask from you to write up some documentation on this
feature, how to use etc. so that we can agree on the API. Currently, I
feel I do not really grok the use case(s?). It could also be that I am
just too ignorant :)
Overall, the patches aren't that intrusive or complex and we can fix
things below the API later too. But as soon we extend the API we should
really try hard to avoid changing it.
Thanks,
Daniel
------------------------------
Message: 6
Date: Thu, 15 Dec 2016 17:43:29 +0100
From: Daniel Wagner <[email protected]>
To: Lukasz Nowak <[email protected]>, [email protected]
Subject: Re: [PATCH 4/5] session: add source ip rule
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 12/14/2016 06:56 PM, Lukasz Nowak wrote:
>> Could you write a small document for doc/ which explains how
>> everything is supposed to work. For example I am not sure why you want
>> this additional boolean. It isn't clear to me when you define
>> allowed_interface (from patch #2) that you need to enable it via this bool?
>
> I will write a doc and update man pages.
Excellent. Thanks!
> I decided to have the AllowedInterface and SrcIpRule as independent
> config options. You can have either one of them enabled without the other.
> We could group them into one (e.g. setting AllowedInterface
> automatically enables creation of the source ip rule in iptables). Do
> you have a preference?
I don't know it yet. I think I am confused what is possible with this
patch set. I'll wait for you documentation. BTW, if you have some links
to share so that I read up on it would also work.
>> Obviously, you need to add this nftables implementation as well.
> I can commit to that, although I would need to set up nftables in our system,
> and learn how to use it.
> Realistically it would be mid-January before I can provide that
> implementation.
> Would it be acceptable to provide it as a separate patch in a few weeks time?
Glad to hear that. Sure, that is fine for me.
>>> - if (session->policy_config->id_type == CONNMAN_SESSION_ID_TYPE_UNKNOWN)
>>> + if (session->policy_config->id_type == CONNMAN_SESSION_ID_TYPE_UNKNOWN
>>> &&
>>> + !session->info->config.source_ip_rule)
>>> return 0;
>>
>> So you don't need to identify your application? The test is here
>> because the firewall didn't make to start if there is no rule to
>> install. I was tempted to suggest to define a new
>> CONNMAN_SESSION_ID_TYPE for this use case but I think it would be good
>> to stay as generic as possible and still allow application
>> identification and source routing.
>
> I have added the source ip rule independent of the policy.
> Technicallyit could go straight into iproute rules, but I thought that
> re-using the
> fwmark and firewall would make the rules easier to see from outside of
> ConnMan. But this choice meant that the firewall could become enabled
> without any policy being active. Would you do it in some other way?
I see. That makes sense. If we need to enable the firewall for source ip
rule or policing than this what we should do. Gluing it artificially
together seems rather a bad decision. So I agree with your approach.
>> At least I would say you should add a small helper for test which tells us
>> what is tested.
>>
>> static bool firewall_needed() {}
>>
>> or a something with a better name.
and than add some comment to this function, maybe something like
"the firewall needs to be enabled for either applying the policing or
source ip routing"
or in any better wording :)
>> BTW, I think now I get why you want to expose the interface name via D-Bus.
>> The application use this information to bind to the interface, no?
> Yes, the application binds each session to one of the required interfaces via
> the D-Bus config.
Ah, the application tells ConnMan to bind to the interface, right? For
some reason I though it was exactly the opposite. Well, see, I am confused.
>> I don't think you handle on-off-on toggling for routing initializtion and
>> the firewall session setup.
> I do (if I understand the scenario you are asking about, correctly).
> On every change of this boolean, firewall will first be cleaned up
> by cleanup_firewall_session(session), but then it will only be re-created
> if SourceIPRule is true. Otherwise init_routing_table() returns without
> doing anything (unless there is a policy in operation, but then it will
> not create the source ip firewall rule).
>
> Do you have any specific combinations of calls/events which you
> think are not handled correctly?
No, I misread than the code. It seems you have tested this. Excellent!
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 14, Issue 24
***************************************
