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: Tether WiFi to cellular modem uplink (Patrik Flykt)
2. Re: Connman v1.33 with systemd v230 : experiencing delay in
IP assignment (Daniel Wagner)
3. Re: Connman v1.33 with systemd v230 : experiencing delay in
IP assignment (Patrik Flykt)
4. Re: Tether WiFi to cellular modem uplink (Daniel Wagner)
5. Re: Using connman with multiple active interfaces (Daniel Wagner)
6. Re: [PATCH 2/5] session: add allowed interface config
parameter (Daniel Wagner)
----------------------------------------------------------------------
Message: 1
Date: Wed, 14 Dec 2016 12:50:53 +0200
From: Patrik Flykt <[email protected]>
To: Evade Flow <[email protected]>
Cc: [email protected], Daniel Wagner <[email protected]>
Subject: Re: Tether WiFi to cellular modem uplink
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
Hi,
On Tue, 2016-12-13 at 14:51 -0500, Evade Flow wrote:
> Do you mean that it's not possible for the tether to access the
> cellular link unless I configure oFono?
Yes.
> I'm not opposed to trying this, but... I have no idea where to
> start. How does one 'configure' oFono? Pointers to any available
> docs, tutorials, videos, books, etc. would be much appreciated.
I have a note which says to run the following commands manually from
the ofono source directory:
test/enter-pin pin XXXX
(maybe a test/list-modems to find the modems)
test/enable-modem /XXXXXX
test/online-modem /XXXXXX
(now org.ofono.ConnectionManager Attached=1 should appear, perhaps this
was detected with test/monitor-modem; nevertheless, not important as
such)
test/activate-context
Maybe others can correct me with the above and know if ConnMan can take
care of the last step(s)? Wagi?
I was going to test the above, but realized that my SIM card needs an
adapter which is at home right now...
At minimum you should see a 'cellular' technology in ConnMan, with that
one knows that oFono and ConnMan are communicating. With all of the
above steps, there should be at least one 'cellular_...' service
visible with 'connmanctl services'. Remember that searching and
attaching to the network will take a while.
Cheers,
Patrik
------------------------------
Message: 2
Date: Wed, 14 Dec 2016 14:06:19 +0100
From: Daniel Wagner <[email protected]>
To: Shrikant Bobade <[email protected]>, Patrik Flykt
<[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/09/2016 02:37 PM, Shrikant Bobade wrote:
> Getting connman waiting/stuck at /getrandom
> (_rnd_get_system_entropy_getrandom) (by default gnutls enabled)
Hmm, getrandom is part of gnutls? Maybe post the stack trace, that would
help to understand the situation better.
> 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.. ?
Haven't seen this problem before but that doesn't mean it doesn't exists.
> :~# rngd -r /dev/urandom -o
> /dev/random
>
> :~# cat /proc/sys/kernel/random/entropy_avail
> 3087
>
>
> Please advise, we suppose to use only /dev/random for better security
> 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-dev-random-with-dev-urandom
> http://stackoverflow.com/questions/3690273/did-i-understand-dev-urandom#comment30985465_3709644
I had to read up on the random and urandom. I also checked if any of our
calls to __connman_util_get_random() is a problem (see below [1]).
It looks like that our code base is using urandom correctly. So
it is how we use gnutls. I wonder how this could be a problem in
assigning IP addresses. Could you past a complete log?
Thanks,
Daniel
[1]
** src/config.c: __connman_util_get_random(&rand);
generate_random_string(rstr, 11);
vfile = g_strdup_printf("service_mutable_%s.config", rstr);
** src/dhcpv6.c: __connman_util_get_random(&rand);
/* Initial timeout, RFC 3315, 18.1.5 */
__connman_util_get_random(&rand);
delay = rand % 1000;
RFC 3314 chapter 18.1.5
"""
The first Confirm message from the client on the interface MUST be
delayed by a random amount of time between 0 and CNF_MAX_DELAY.
"""
** src/dhcpv6.c: __connman_util_get_random(&rand);
/* Initial timeout, RFC 3315, 17.1.2 */
__connman_util_get_random(&rand);
delay = rand % 1000;
RFC 3314 chapter 17.1.2
"""
The first Solicit message from the client on the interface MUST be
delayed by a random amount of time between 0 and SOL_MAX_DELAY. In
the case of a Solicit message transmitted when DHCP is initiated by
IPv6 Neighbor Discovery, the delay gives the amount of time to wait
after IPv6 Neighbor Discovery causes the client to invoke the
stateful address autoconfiguration protocol (see section 5.5.3 of RFC
2462). This random delay desynchronizes clients which start at the
same time (for example, after a power outage).
"""
** src/dhcpv6.c: __connman_util_get_random(&rand);
static guint compute_random(guint val)
{
uint64_t rand;
__connman_util_get_random(&rand);
return val - val / 10 +
((guint) rand % (2 * 1000)) * val / 10 / 1000;
}
/* Calculate a random delay, RFC 3315 chapter 14 */
/* RT and MRT are milliseconds */
static guint calc_delay(guint RT, guint MRT)
{
if (MRT && (RT > MRT / 2))
RT = compute_random(MRT);
else
RT += compute_random(RT);
return RT;
}
RFC 3315 chapter 14
"""
Each of the computations of a new RT include a randomization factor
(RAND), which is a random number chosen with a uniform distribution
between -0.1 and +0.1. The randomization factor is included to
minimize synchronization of messages transmitted by DHCP clients.
The algorithm for choosing a random number does not need to be
cryptographically sound. The algorithm SHOULD produce a different
sequence of random numbers from each invocation of the DHCP client.
"""
** src/dnsproxy.c: __connman_util_get_random(&rand);
req->dstid = get_id();
req->altid = get_id();
RFC 5625 chapter 6.1
"""
It has been standard guidance for many years that each DNS query
should use a randomly generated Query ID. However, many proxies have
been observed picking sequential Query IDs for successive requests.
It is strongly RECOMMENDED that DNS proxies follow the relevant
recommendations in [RFC5452], particularly those in Section 9.2
relating to randomisation of Query IDs and source ports. This also
applies to source port selection within any NAT function
"""
RFC 5452 chapter 9.2. Extending the Q-ID Space by Using Ports and Addresses
"""
Resolver implementations MUST:
o Use an unpredictable source port for outgoing queries from the
range of available ports (53, or 1024 and above) that is as large
as possible and practicable;
o Use multiple different source ports simultaneously in case of
multiple outstanding queries;
o Use an unpredictable query ID for outgoing queries, utilizing the
full range available (0-65535).
Resolvers that have multiple IP addresses SHOULD use them in an
unpredictable manner for outgoing queries.
Resolver implementations SHOULD provide means to avoid usage of
certain ports.
Resolvers SHOULD favor authoritative nameservers with which a trust
relation has been established; stub-resolvers SHOULD be able to use
Transaction Signature (TSIG) ([RFC2845]) or IPsec ([RFC4301]) when
communicating with their recursive resolver.
In case a cryptographic verification of response validity is
available (TSIG, SIG(0)), resolver implementations MAY waive above
rules, and rely on this guarantee instead.
Proper unpredictability can be achieved by employing a high quality
(pseudo-)random generator, as described in [RFC4086].
"""
RFC 4086 chapter 7. Randomness Generation Examples and Standards
"""
Several public standards and widely deployed examples are now in
place for the generation of keys or other cryptographically random
quantities. Some, in section 7.1, include an entropy source.
Others, described in section 7.2, provide the pseudo-random number
strong-sequence generator but assume the input of a random seed or
input from a source of entropy.
"""
RFC 4086 chapter 7.1.2. The /dev/random Device
"""
Several versions of the UNIX operating system provide a kernel-
resident random number generator. Some of these generators use
events captured by the Kernel during normal system operation.
For example, on some versions of Linux, the generator consists of a
random pool of 512 bytes represented as 128 words of 4 bytes each.
When an event occurs, such as a disk drive interrupt, the time of the
event is XOR'ed into the pool, and the pool is stirred via a
primitive polynomial of degree 128. The pool itself is treated as a
ring buffer, with new data being XOR'ed (after stirring with the
polynomial) across the entire pool.
Each call that adds entropy to the pool estimates the amount of
likely true entropy the input contains. The pool itself contains a
accumulator that estimates the total over all entropy of the pool.
Input events come from several sources, as listed below.
Unfortunately, for server machines without human operators, the first
and third are not available, and entropy may be added slowly in that
case.
1. Keyboard interrupts. The time of the interrupt and the scan code
are added to the pool. This in effect adds entropy from the human
operator by measuring inter-keystroke arrival times.
2. Disk completion and other interrupts. A system being used by a
person will likely have a hard-to-predict pattern of disk
accesses. (But not all disk drivers support capturing this timing
information with sufficient accuracy to be useful.)
3. Mouse motion. The timing and mouse position are added in.
When random bytes are required, the pool is hashed with SHA-1 [SHA*]
to yield the returned bytes of randomness. If more bytes are
required than the output of SHA-1 (20 bytes), then the hashed output
is stirred back into the pool and a new hash is performed to obtain
the next 20 bytes. As bytes are removed from the pool, the estimate
of entropy is correspondingly decremented.
To ensure a reasonably random pool upon system startup, the standard
startup and shutdown scripts save the pool to a disk file at shutdown
and read this file at system startup.
There are two user-exported interfaces. /dev/random returns bytes
from the pool but blocks when the estimated entropy drops to zero.
As entropy is added to the pool from events, more data becomes
available via /dev/random. Random data obtained from such a
/dev/random device is suitable for key generation for long term keys,
if enough random bits are in the pool or are added in a reasonable
amount of time.
/dev/urandom works like /dev/random; however, it provides data even
when the entropy estimate for the random pool drops to zero. This
may be adequate for session keys or for other key generation tasks
for which blocking to await more random bits is not acceptable. The
risk of continuing to take data even when the pool's entropy estimate
is small in that past output may be computable from current output,
provided that an attacker can reverse SHA-1. Given that SHA-1 is
designed to be non-invertible, this is a reasonable risk.
To obtain random numbers under Linux, Solaris, or other UNIX systems
equipped with code as described above, all an application has to do
is open either /dev/random or /dev/urandom and read the desired
number of bytes.
(The Linux Random device was written by Theodore Ts'o. It was based
loosely on the random number generator in PGP 2.X and PGP 3.0 (aka
PGP 5.0).)
"""
man page on urandom:
A read from the /dev/urandom device will not block waiting
for more entropy. If there is not sufficient entropy, a
pseudorandom number generator is used to create the
requested bytes. As a result, in this case the returned
values are theoretically vulnerable to a cryptographic
attack on the algorithms used by the driver. Knowledge of
how to do this is not available in the current unclassified
literature, but it is theoretically possible that such an
attack may exist. If this is a concern in your application,
use /dev/random instead. O_NONBLOCK has no effect when
opening /dev/urandom. When calling read(2) for the device
/dev/urandom, signals will not be handled until after the
requested random bytes have been generated.
------------------------------
Message: 3
Date: Wed, 14 Dec 2016 15:37:59 +0200
From: Patrik Flykt <[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="UTF-8"
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.
> 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.
> 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.
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?
Cheers,
Patrik
------------------------------
Message: 4
Date: Wed, 14 Dec 2016 14:41:32 +0100
From: Daniel Wagner <[email protected]>
To: Patrik Flykt <[email protected]>, 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
On 12/14/2016 11:50 AM, Patrik Flykt wrote:
> On Tue, 2016-12-13 at 14:51 -0500, Evade Flow wrote:
>> Do you mean that it's not possible for the tether to access the
>> cellular link unless I configure oFono?
>
> Yes.
>
>> I'm not opposed to trying this, but... I have no idea where to
>> start. How does one 'configure' oFono? Pointers to any available
>> docs, tutorials, videos, books, etc. would be much appreciated.
>
> I have a note which says to run the following commands manually from
> the ofono source directory:
>
> test/enter-pin pin XXXX
> (maybe a test/list-modems to find the modems)
> test/enable-modem /XXXXXX
> test/online-modem /XXXXXX
> (now org.ofono.ConnectionManager Attached=1 should appear, perhaps this
> was detected with test/monitor-modem; nevertheless, not important as
> such)
> test/activate-context
>
> Maybe others can correct me with the above and know if ConnMan can take
> care of the last step(s)? Wagi?
You need to do the pin entering but that's all. The rest does the plugin.
You can run monitor-ofono which tells you what ConnMan is seeing.
{Manager} [ModemAdded] /stktest { Emergency = False, Features = [], Type =
test, Online = False, Powered = False, Lockdown = False, Interfaces = [] }
{Manager} [ModemAdded] /hso_0 { Emergency = False, Features = [], Type =
hardware, Online = False, Powered = False, Lockdown = False, Interfaces = [] }
{Modem} [/hso_0] Powered = True
{Modem} [/hso_0] Interfaces = org.ofono.SimManager
{Modem} [/hso_0] Features = sim
{Modem} [/hso_0] Manufacturer = Option N.V.
{Modem} [/hso_0] Model = GlobeTrotter HSUPA Modem
{Modem} [/hso_0] Revision = 2.12.0.0Hd (Date: Oct 29 2009, Time: 09:56:48)
{Modem} [/hso_0] Serial = 351721030157214,PK29997020
{SimManager} [/hso_0] Retries = { pin = 3, puk = 10 }
{SimManager} [/hso_0] SubscriberIdentity = 262011648051223
{SimManager} [/hso_0] MobileCountryCode = 262
{SimManager} [/hso_0] MobileNetworkCode = 01
{Modem} [/hso_0] Interfaces = org.ofono.AllowedAccessPoints org.ofono.SimManager
{Modem} [/hso_0] Features = sim
{Modem} [/hso_0] Online = True
{Modem} [/hso_0] Interfaces = org.ofono.VoiceCallManager
org.ofono.AllowedAccessPoints org.ofono.SimManager
{Modem} [/hso_0] Features = sim
{Modem} [/hso_0] Interfaces = org.ofono.SupplementaryServices
org.ofono.VoiceCallManager org.ofono.AllowedAccessPoints org.ofono.SimManager
{Modem} [/hso_0] Features = ussd sim
{Modem} [/hso_0] Interfaces = org.ofono.RadioSettings
org.ofono.SupplementaryServices org.ofono.VoiceCallManager
org.ofono.AllowedAccessPoints org.ofono.SimManager
{Modem} [/hso_0] Features = rat ussd sim
{Modem} [/hso_0] Interfaces = org.ofono.NetworkRegistration
org.ofono.RadioSettings org.ofono.SupplementaryServices
org.ofono.VoiceCallManager org.ofono.AllowedAccessPoints org.ofono.SimManager
{Modem} [/hso_0] Features = net rat ussd sim
{Modem} [/hso_0] Interfaces = org.ofono.CellBroadcast
org.ofono.NetworkRegistration org.ofono.RadioSettings
org.ofono.SupplementaryServices org.ofono.VoiceCallManager
org.ofono.AllowedAccessPoints org.ofono.SimManager
{Modem} [/hso_0] Features = cbs net rat ussd sim
{NetworkRegistration} [/hso_0] Status = unregistered
{Modem} [/hso_0] Interfaces = org.ofono.ConnectionManager
org.ofono.CellBroadcast org.ofono.NetworkRegistration org.ofono.RadioSettings
org.ofono.SupplementaryServices org.ofono.VoiceCallManager
org.ofono.AllowedAccessPoints org.ofono.SimManager
{Modem} [/hso_0] Features = gprs cbs net rat ussd sim
{Modem} [/hso_0] Interfaces = org.ofono.SmartMessaging
org.ofono.PushNotification org.ofono.MessageManager org.ofono.ConnectionManager
org.ofono.CellBroadcast org.ofono.NetworkRegistration org.ofono.RadioSettings
org.ofono.SupplementaryServices org.ofono.VoiceCallManager
org.ofono.AllowedAccessPoints org.ofono.SimManager
{Modem} [/hso_0] Features = sms gprs cbs net rat ussd sim
{NetworkRegistration} [/hso_0] Status = searching
{NetworkRegistration} [/hso_0] Status = denied
As you can see my SIM card is not valid anymore and the NetworkRegistration
fails. Currently I don't have any data SIM lying around.
> I was going to test the above, but realized that my SIM card needs an
> adapter which is at home right now...
Note some modems are tricky to get working. oFono does a lot to make sure
that all modems just work, though not all modems can be tricked into
working mode.
cheers,
daniel
------------------------------
Message: 5
Date: Wed, 14 Dec 2016 14:42:41 +0100
From: Daniel Wagner <[email protected]>
To: Lukasz Nowak <[email protected]>, Patrik Flykt
<[email protected]>, [email protected]
Subject: Re: Using connman with multiple active interfaces
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 12/13/2016 12:07 PM, Lukasz Nowak wrote:
> Sorry it took a while, but I finally posted a set of patches
> yesterday, which implement the per-interface routing through
> sessions. I added the following:
> 1. A session config field which filters on interface name
> This allows an application to start a session and attach it
> to a specific interface.
> 2. Another session config field enabling source ip address
> rule in iptables, and the required fwmark rule in iproute.
> This allows the application to do a bind before connect
> for each socket, and have the traffic routed through the
> selected interface.
> 3. Fixed a bug where ppp sessions would not create a
> per-session routing table due to having no gateway.
>
> Let me know if this makes sense.
Thanks, will do a review now :)
cheers,
daniel
------------------------------
Message: 6
Date: Wed, 14 Dec 2016 14:54:01 +0100
From: Daniel Wagner <[email protected]>
To: [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
Hi Lukasz,
On 12/12/2016 07:35 PM, [email protected] wrote:
> From: Lukasz Nowak <[email protected]>
>
> In order to be able to bind a session to a specific interface,
> a config option has been added. It is supported through both
> dbus and session policy. Policy always overrides dbus.
>
> This is the first step to implement per-interface routing.
> Next step will be to add src ip rules to iptables, which
> will allow the application to transmit through multiple
> interfaces.
The patch looks fine from the first glance. You need also to update the
documentation on it.
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.
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 14, Issue 19
***************************************
