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 - DHCP client for cellular networks (Daniel Wagner)
2. Re: [PATCH] service: Fix loose mode routing not enabled with
EnableOnlineCheck option (Daniel Wagner)
3. Re: connmand[186]: Online check failed but running dhclient
manually fixes this issue (Daniel Wagner)
4. Re: Using NTP To Set System Time (Daniel Wagner)
----------------------------------------------------------------------
Message: 1
Date: Thu, 20 Jul 2017 19:22:51 +0200
From: Daniel Wagner <[email protected]>
To: "Eswaran Vinothkumar (BEG/PJ-IOT-EL)"
<[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: Connman - DHCP client for cellular networks
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Vinothkumar,
On 07/14/2017 02:11 PM, Eswaran Vinothkumar (BEG/PJ-IOT-EL) wrote:
> Hello,
>
> I am currently working on an embedded project where we are using TELIT
> 910 EUG Modem chip. We are using Yocto as the build system.
>
> Versions Used: Connman:1.34 and Ofono:1.20
>
> To establish the internet connection I am using the python scripts
> within the ofono/test directory as follows:
>
> /usr/lib/ofono/test/enable-modem
>
> /usr/lib/ofono/test/online-modem
>
> /usr/lib/ofono/test/set-roaming-allowed
>
> /usr/lib/ofono/test/register-auto
>
> /usr/lib/ofono/test/enable-gprs
>
> /usr/lib/ofono/test/create-internet-context web.vodafone.de vodafone
> vodafone
>
> /activate-context
>
> /process-context-settings
>
> After this I could see that the device gets the IP address, gateway and
> nameserver as shown below,
>
> ofono_start_gsm.sh[192]: Interface is wwan0
>
> ofono_start_gsm.sh[192]: IP address is 10.249.29.20
>
> ofono_start_gsm.sh[192]: Gateway is 10.249.29.21
>
> ofono_start_gsm.sh[192]: Nameserver is 10.105.144.254
That looks good.
> At this point I excepted Connman to connect to the internet but it
> doesn?t. I am seeing the following error message from Connman:
Not really. With the test scripts above you have controlled oFono
directly. That means you have run it standalone. ConnMan should all
those steps you did with the scripts itself.
> connmand[176]: Online check failed for 0x1ce7c80 Vodafone.
I think we need to figure out first why ConnMan doesn't drive oFono.
This might be an problem which be depended on the previous steps.
> Also ping and wget didn?t work. The output of ip route and
> /etc/resolv.conf are as follows:
>
> route -n
>
> Kernel IP routing table
>
> Destination Gateway Genmask
> Flags Metric Ref Use Iface
>
> 0.0.0.0 10.166.199.10 0.0.0.0
> UG 0 0 0 wwan0
>
> 10.105.144.254 10.166.199.10 255.255.255.255
> UGH 0 0 0 wwan0
>
> 10.166.199.8 0.0.0.0 255.255.255.252
> U 0 0 0 wwan0
>
> 10.166.199.10 0.0.0.0 255.255.255.255
> UH 0 0 0 wwan0
>
> 192.168.1.0 0.0.0.0 255.255.255.0
> U 0 0 0 eth0
>
> 192.168.1.255 0.0.0.0 255.255.255.255
> UH 0 0 0 eth0
It is hard to tell how this routing table came about without the logs.
If ConnMan is not controlling the modem, then the default gateway is not
added by ConnMan.
> cat /etc/resolv-conf.connman
>
> # Generated by Connection Manager
>
> nameserver ::1
>
> nameserver 127.0.0.1
These entries are there because ConnMan does provide a complete DNS
proxy. You can also disable it via the command line, please check the
documentation on the impact of this option.
> The contents of ip route and resolv.conf looked strange for me. I looked
> into Connman documents and the mailing list discussions, it seems like
> expected behavior from connman.
Yes, it's the DNS proxy settings.
> As a test case, I manually started the DHCP client on wwan0. After that
> I could see that the device is connected to the internet. I checked
> with ping and wget. Also have downloaded some files to test the internet
> connection.
Okay, at least we know now it supposed to work :)
> The output of ip route and /etc/resolv.conf are as follows:
>
> route -n
>
> Kernel IP routing table
>
> Destination Gateway Genmask Flags
> Metric Ref Use Iface
>
> 0.0.0.0 10.166.250.1 0.0.0.0
> UG 0 0 0 wwan0
>
> 10.166.250.0 0.0.0.0 255.255.255.240 U
> 0 0 0 wwan0
>
> 192.168.1.0 0.0.0.0 255.255.255.0
> U 0 0 0 eth0
>
> 192.168.1.255 0.0.0.0 255.255.255.255 UH
> 0 0 0 eth0
>
> cat /etc/resolv.conf
>
> nameserver 10.105.16.254
>
> nameserver 10.105.144.254
dhclient overwrites resolv.conf.
> I have the following question. Is this the expected behavior?
If ConnMan doesn't steer oFono, I would say yes.
> Do I need
> to run dhclient or missing some configuration in Connman?
No, you don't need dhclient or any other standalone networking tools.
ConnMan has built in support for these setups.
> I have read in
> the mailing list that the connman has internet DHCP client and running
> another might cause confusion.
Yes, it's basically the problem of a global resource (/etc/resolv.conf).
Only one entity should control this file. There are some use cases where
it makes sense to disable the DNS proxy and run your own DNS proxy. But
you should make this decision with proper consideration what the impact is.
> After running connmanctl services I could see the connection is listed
> as AR (Ready state). I expected it to be in AO(online state)
>
> *AR Wired ethernet_0001c01df20b_cable
>
> *AR Vodafone cellular_204046850339628_context1
That is strange, it looks like ConnMan controls the modem. So that is
good. Hmm, so the first routing table is from ConnMan I suppose. It's a
bit hard to tell without the logs.
> I tried disconnecting the service and connecting it back.
>
> connmanctl disconnect cellular_204046850339628_context1 ?successfully
> disconnects the connection
>
> connmanctl connect cellular_204046850339628_context1 ?again the connman
> fails with the message Online check failed for 0x1ce7c80 Vodafone.
> Running dhclient manually again fixes this issue.
Okay, maybe we get the routing information from oFono wrong.
> I am puzzled about the issue here. Let me know if you need some more log
> messages. Any help on the topic is appreciated.
Yes, the oFono logs and ConnMan logs would help. I suspect that we
somehow read the IP configuration from oFono wrong.
Thanks,
Daniel
ps: Please send plain text messages. Much appreciated.
------------------------------
Message: 2
Date: Thu, 20 Jul 2017 19:39:44 +0200
From: Daniel Wagner <[email protected]>
To: "Deroire, Guillaume" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [PATCH] service: Fix loose mode routing not enabled with
EnableOnlineCheck option
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Guillaume,
On 07/14/2017 04:20 PM, Deroire, Guillaume wrote:
> When EnableOnlineCheck option is enabled, the rp_filter is not updated
> if there are more than one service available. The result is that some
> packets are blocked.
I looked at the initial commit of the service_rp_filter: cb3e78500a25
("service: Activate loose mode routing"). And now I am bit confused with
'When EnabledOnlineCheck options is _enabled_'? Shouldn't that be a
'disabled'?
> ---
> src/service.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/service.c b/src/service.c
> index aff800c..292ed88 100644
> --- a/src/service.c
> +++ b/src/service.c
> @@ -5992,7 +5992,6 @@ int __connman_service_ipconfig_indicate_state(struct
> connman_service *service,
> if (connman_setting_get_bool("EnableOnlineCheck"))
> if (type == CONNMAN_IPCONFIG_TYPE_IPV4) {
> check_proxy_setup(service);
> - service_rp_filter(service, true);
> } else {
> service->online_check_count = 1;
> __connman_wispr_start(service, type);
> @@ -6000,6 +5999,9 @@ int __connman_service_ipconfig_indicate_state(struct
> connman_service *service,
> else
> connman_info("Online check disabled. "
> "Default service remains in READY state.");
> + if (type == CONNMAN_IPCONFIG_TYPE_IPV4) {
> + service_rp_filter(service, true);
> + }
> break;
> case CONNMAN_SERVICE_STATE_ONLINE:
> break;
The change looks good but it is whitespace damaged. We use tabs for
indention and this looks like 4 spaces.
Can you please send an updated version?
Thanks,
Daniel
------------------------------
Message: 3
Date: Thu, 20 Jul 2017 19:47:46 +0200
From: Daniel Wagner <[email protected]>
To: "Eswaran Vinothkumar (BEG/PJ-IOT-EL)"
<[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: connmand[186]: Online check failed but running dhclient
manually fixes this issue
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Vinothkumar,
On 07/17/2017 04:39 PM, Eswaran Vinothkumar (BEG/PJ-IOT-EL) wrote:
> Hello,
>
> I am trying to use connman+ofono to connect to internet using TELIT 910
> EUG modem chip.
>
> Versions Used: Connman:1.34 and Ofono:1.20
>
> To establish the internet connection I am using the python scripts
> within the ofono/test directory as follows:
>
> /usr/lib/ofono/test/enable-modem
>
> /usr/lib/ofono/test/online-modem
>
> /usr/lib/ofono/test/set-roaming-allowed
>
> /usr/lib/ofono/test/register-auto
>
> /usr/lib/ofono/test/enable-gprs
>
> /usr/lib/ofono/test/create-internet-context web.vodafone.de vodafone
> vodafone
>
> /activate-context
>
> /process-context-settings
>
> After this I could see that the device gets the IP address, gateway and
> nameserver as shown below,
>
> ofono_start_gsm.sh[192]: Interface is wwan0
>
> ofono_start_gsm.sh[192]: IP address is 10.249.29.20
>
> ofono_start_gsm.sh[192]: Gateway is 10.249.29.21
>
> ofono_start_gsm.sh[192]: Nameserver is 10.105.144.254
>
> At this point I excepted Connman to connect to the internet but it doesn't.
Indeed, now it should be online. What does ConnMan say about the service:
./test/list-services
?
> I am seeing the following error message from Connman, >
> connmand[186]: Online check failed for 0x50db78 Vodafone.
If the routes would be setup correctly I assume this online check would
also work. So we get the routing somehow wrong.
> From the debug message I understood that connman is not able to connect to
> the internet(status 400).
Yes, there is a section on the online check in the README.
> But if I run manually dhclient on wwan0 interface, I could connect to
> the internet. It puzzles me, why it is not working with connman. Any
> help on this topic would be great J
Sure, glad to help. Just a bit limited bandwidth on my side. If you
could post the logs of oFono and ConnMan we maybe identify what is going
wrong. At least we can compare what dhclient is doing.
Thanks,
Danie.
------------------------------
Message: 4
Date: Thu, 20 Jul 2017 20:14:36 +0200
From: Daniel Wagner <[email protected]>
To: Jeff Gray <[email protected]>
Cc: [email protected]
Subject: Re: Using NTP To Set System Time
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi Jeff,
On 07/18/2017 09:04 AM, Jeff Gray wrote:
> I am trying to use NTP in Connman to set the time for my embedded
> Linux system. NTP is working, but it is not setting the system time. I
> have read the docs, trying to see what I'm missing, but can't work it
> out.
So far I haven't played with the NTP bits in ConnMan, so please bear with
me if I don't know all the stuff by heart.
> My domain has an NTP server at 10.16.1.4, which is correctly passed
> via DHCP. Connman adds the default route as a timeserver, but this is
> not active.
> The only service is Ethernet (summarised for brevity):
> /net/connman/service/ethernet_XXXXXXXXXXXX_cable
> State = online
> Ethernet = [ Method=auto, Interface=eth0, Address=XX:XX:XX:XX:XX:XX,
> MTU=1500 ]
> IPv4 = [ Method=dhcp, Address=10.16.1.31, Netmask=255.255.255.0,
> Gateway=10.16.1.254 ]
> IPv4.Configuration = [ Method=dhcp ]
> Nameservers = [ 10.16.1.4, 10.16.1.5 ]
> Timeservers = [ 10.16.1.4, 10.16.1.254]
> Timeservers.Configuration = [ ]
>
> When the connection goes online, NTP does activate:
> ntp: adjust (jump): +616745865.307993 sec
That is a huge jump. Unfortunately, I don't have setup a timeserver
here so I can't verify it.
I just checked the code and ConnMan uses adjtimex() with ADJ_SETOFFSET
and followed them into the kernel. In kernel/time/ntp.c I see that
the range is checked if it is valid:
int ntp_validate_timex(struct timex *txc)
{
[...]
if (txc->modes & ADJ_SETOFFSET) {
/* In order to inject time, you gotta be super-user! */
if (!capable(CAP_SYS_TIME))
return -EPERM;
if (txc->modes & ADJ_NANO) {
struct timespec ts;
ts.tv_sec = txc->time.tv_sec;
ts.tv_nsec = txc->time.tv_usec;
if (!timespec_inject_offset_valid(&ts))
return -EINVAL;
} else {
if (!timeval_inject_offset_valid(&txc->time))
return -EINVAL;
}
}
[...]
return 0;
}
and
static inline bool timespec_inject_offset_valid(const struct timespec *ts)
{
/* We don't check the tv_sec as it can be positive or negative */
/* Can't have more nanoseconds then a second */
if (ts->tv_nsec < 0 || ts->tv_nsec >= NSEC_PER_SEC)
return false;
return true;
}
So even though the jump is large, it should still be okay. At least we would
see the EINVAL. Anyway, this was just an excursion to check that all
is supposed to work :)
> And I can see the internal NTP time using test-clock:
> TimeUpdates = auto
> Timeservers = [ ]
> TimezoneUpdates = auto
> Time = 883612967
>
> I have enabled debugging for timeserver.c & clock.c, but can't see any
> errors on the log.
Okay.
> How do I get Connman to set the system time?
adjtimex() should do the work, suppose we use it correctly. I have seen
it in the past work. So it might be that the kernel is not accepting
the values. Are their any message in the kernel log?
> Another question - Timeservers in net.connman.Clock is empty, does
> this matter?
Hmm, don't know. Need to check what the code says :)
> What is the significance of Timeservers defined here
> versus in a Service? (Just trying to understand how this all fits
> together)
IIRC, the Clock API is exposing the gathered timeserver information.
But I need to recheck this.
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 21, Issue 9
**************************************
