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: Is there some "Hello GDbus connman World" somewhere ?
(Daniel Wagner)
2. Re: Is there some "Hello GDbus connman World" somewhere ?
(Pierre Couderc)
3. Re: AW: AW: connmand[186]: Online check failed but running
dhclient manually fixes this issue (Christophe Ronco)
----------------------------------------------------------------------
Message: 1
Date: Wed, 26 Jul 2017 14:29:58 +0200
From: Daniel Wagner <[email protected]>
To: Pierre Couderc <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: Is there some "Hello GDbus connman World" somewhere ?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi Pierre,
On 07/26/2017 09:05 AM, Pierre Couderc wrote:
> On 07/25/2017 07:54 PM, Daniel Wagner wrote:
>> Hi Pierre,
>>
>> Please do not drop the CC, because someone else might also be
>> interested in our discussion.
> Sure, sorry. It was a mistake.
No worries.
>> On 07/25/2017 06:40 PM, Pierre Couderc wrote:
>>
>> I can't really help you here, since you didn't tell us what you plan
>> to do.
> My project is MOMradio, a radio for my grandmother. It takes an internet
> radio stream and sends it to a small domestic FM transmitter, so my
> grandmother hears it on its good old FM radio.
> It is packaged in an Orange Pi small ARM 10$ computer ( a brother of
> raspberry Pi).
>
> I need to find an internet stream at power on (ethernet, wifi...)
> preferably the same that when power was down before. MOMradio is piloted
> by a few instructions usually given once for all, by the mean of a small
> http server (nginx). The main interest is to have locally a FM stream
> not provided in your city.
>
> I am studying if connman is the good solution for that.
Maybe you could start your work on the
connman/src/connmand-wait-online.c code. This small helper function is
used to block until ConnMan sends out the 'ONLINE' state.
Thanks,
Daniel
------------------------------
Message: 2
Date: Wed, 26 Jul 2017 15:18:06 +0200
From: Pierre Couderc <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: Is there some "Hello GDbus connman World" somewhere ?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
On 07/26/2017 02:29 PM, Daniel Wagner wrote:
> Hi Pierre,
>
> On 07/26/2017 09:05 AM, Pierre Couderc wrote:
>> On 07/25/2017 07:54 PM, Daniel Wagner wrote:
>>> Hi Pierre,
>>>
>>> Please do not drop the CC, because someone else might also be
>>> interested in our discussion.
>> Sure, sorry. It was a mistake.
> No worries.
>
>>> On 07/25/2017 06:40 PM, Pierre Couderc wrote:
>>>
>>> I can't really help you here, since you didn't tell us what you plan
>>> to do.
>> My project is MOMradio, a radio for my grandmother. It takes an internet
>> radio stream and sends it to a small domestic FM transmitter, so my
>> grandmother hears it on its good old FM radio.
>> It is packaged in an Orange Pi small ARM 10$ computer ( a brother of
>> raspberry Pi).
>>
>> I need to find an internet stream at power on (ethernet, wifi...)
>> preferably the same that when power was down before. MOMradio is piloted
>> by a few instructions usually given once for all, by the mean of a small
>> http server (nginx). The main interest is to have locally a FM stream
>> not provided in your city.
>>
>> I am studying if connman is the good solution for that.
> Maybe you could start your work on the
> connman/src/connmand-wait-online.c code. This small helper function is
> used to block until ConnMan sends out the 'ONLINE' state.
>
> Thanks,
> Daniel
Thnk you I see that.
------------------------------
Message: 3
Date: Wed, 26 Jul 2017 16:45:08 +0200
From: Christophe Ronco <[email protected]>
To: Daniel Wagner <[email protected]>, "Eswaran Vinothkumar
(BEG/PJ-IOT-EL)" <[email protected]>
Cc: "[email protected]" <[email protected]>, [email protected]
Subject: Re: AW: AW: connmand[186]: Online check failed but running
dhclient manually fixes this issue
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 07/26/2017 12:59 PM, Daniel Wagner wrote:
> [added ofono mailing list]
>
> Summery: The qmi modem returns since 475b789f3de9 ("qmi: retrieve GPRS
> context parameters") the IP configuration which is sometimes incorrect.
> If ConnMan gets the IP configuration it doesn't do any DHCP and applies
> the not working IP configuration.
>
> On 07/26/2017 10:11 AM, Eswaran Vinothkumar (BEG/PJ-IOT-EL) wrote:
>> On 07/21/2017 09:31 AM, Daniel Wagner wrote:
>>> The first thing I noticed, is that we do not extract the DNS settings
>>> correctly. oFono sends 10.105.16.254 and 10.105.144.254. I starred at
>>> the oFono code base and also at ConnMan and I don't see what's going
>>> wrong.
>>>
>>> Jul 21 05:47:02 alen-iot-gateway ofonod[176]:
>>> ../ofono-1.20/drivers/qmimodem/gprs-context.c:get_settings_cb()
>>> Jul 21 05:47:02 alen-iot-gateway ofonod[176]:
>>> ../ofono-1.20/drivers/qmimodem/gprs-context.c:get_settings_cb() APN:
>>> internetd.gdsp Jul 21 05:47:02 alen-iot-gateway ofonod[176]:
>>> ../ofono-1.20/drivers/qmimodem/gprs-context.c:get_settings_cb() PDP
>>> type 0 Jul 21 05:47:02 alen-iot-gateway ofonod[176]:
>>> ../ofono-1.20/drivers/qmimodem/gprs-context.c:get_settings_cb() IP
>>> addr: 10.249.97.226 Jul 21 05:47:02 alen-iot-gateway ofonod[176]:
>>> ../ofono-1.20/drivers/qmimodem/gprs-context.c:get_settings_cb()
>>> Gateway: 10.249.97.225 Jul 21 05:47:02 alen-iot-gateway ofonod[176]:
>>> ../ofono-1.20/drivers/qmimodem/gprs-context.c:get_settings_cb()
>>> Gateway netmask: 255.255.255.252 Jul 21 05:47:02 alen-iot-gateway
>>> ofonod[176]:
>>> ../ofono-1.20/drivers/qmimodem/gprs-context.c:get_settings_cb()
>>> Primary DNS: 10.105.16.254 Jul 21 05:47:02 alen-iot-gateway
>>> ofonod[176]:
>>> ../ofono-1.20/drivers/qmimodem/gprs-context.c:get_settings_cb()
>>> Secondary DNS: 10.105.144.254
>>>
>>>
>>> Jul 21 05:47:02 alen-iot-gateway connmand[175]:
>>> ../connman-1.34/plugins/ofono.c:extract_ipv4_settings() Interface
>>> wwan0 Jul 21 05:47:02 alen-iot-gateway connmand[175]:
>>> ../connman-1.34/plugins/ofono.c:extract_ipv4_settings() index 6 Jul 21
>>> 05:47:02 alen-iot-gateway connmand[175]:
>>> ../connman-1.34/plugins/ofono.c:extract_ipv4_settings() Method static
>>> Jul 21 05:47:02 alen-iot-gateway connmand[175]:
>>> ../connman-1.34/plugins/ofono.c:extract_ipv4_settings() Address
>>> 10.249.97.226 Jul 21 05:47:02 alen-iot-gateway connmand[175]:
>>> ../connman-1.34/plugins/ofono.c:extract_ipv4_settings() Netmask
>>> 255.255.255.252 Jul 21 05:47:02 alen-iot-gateway connmand[175]:
>>> ../connman-1.34/plugins/ofono.c:extract_ipv4_settings() Gateway
>>> 10.249.97.225 Jul 21 05:47:02 alen-iot-gateway connmand[175]:
>>> ../connman-1.34/plugins/ofono.c:extract_ipv4_settings() Nameservers
>>> 10.105.144.254 10.105.144.254
>>>
>>> Could you add some printfs to the extract_nameservers() in
>>> plugins/ofono.c? And you might also want to run
>>> ofono/test/monitor-ofono so that you can see what oFono sends to
>>> ConnMan.
>>>
>>>
>>> Address: 10.249.97.226 00001010.11111001.01100001.111000 10
>>> Netmask: 255.255.255.252 = 30 11111111.11111111.11111111.111111 00
>>> Wildcard: 0.0.0.3 00000000.00000000.00000000.000000 11
>>> =>
>>> Network: 10.249.97.224/30 00001010.11111001.01100001.111000 00
>>> (Class A)
>>> Broadcast: 10.249.97.227 00001010.11111001.01100001.111000 11
>>> HostMin: 10.249.97.225 00001010.11111001.01100001.111000 01
>>> HostMax: 10.249.97.226 00001010.11111001.01100001.111000 10
>>> Hosts/Net: 2 (Private Internet)
>>>
>>> Looking through the log, it looks like ConnMan does all the math
>>> correctly.
>>>
>>> One thing which looks inconsistent in your first report is:
>>>
>>> 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
>>>
>>>
>>> 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
>>>
>>> The gateway should be 10.249.29.21 and not 10.166.199.10.
>>> The next three lines are adding a host routing for the DNS server and
>>> maybe timeserver. At least the first line is the DNS server but again
>>> the gateway is wrong.
>>>
>>> dhclient gets set a complete different gateway:
>>>
>>> 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
>>>
>>> 10.166.250.1 with a different netmask!
>>>
>>> First thing I would do is to verify what the oFono modem is doing. If
>>> that one extracts the wrong information and passes that to ConnMan it
>>> would explain your problem. The code in oFono is pretty new
>>>
>>> 475b789f3de9 ("qmi: retrieve GPRS context parameters")
>> Just my 2 cents on this topic.
>> On my setup, I use another QMI modem: MC7304 with ofono 1.20 + a bunch of
>> patches done internally and connman 1.34.
>>
>> I also had problem with this patch (475b789f3de9 ("qmi: retrieve GPRS
>> context parameters")).
>> I have reverted it or to be more precise I commented all calls to functions
>> ofono_gprs_context_set_ipv4* functions.
>> I have done that 3 months ago so I am not completely sure about the why:
>> Here is what I wrote in my patch:
>>
>> The goal is to force connman to use DHCP.
>> When connman don't do that, MC7304 fails to ping.
>> This behavior has been seen by libqmi guys:
>> https://lists.freedesktop.org/archives/libqmi-devel/2016-June/001617.html
>>
>> Maybe you have the same problem with your TELIT modem.
>> I can send my patch if you want but it is not the best way to handle the
>> problem.
> Thanks for your report. So we have at least two independent reports for
> this problem.
>
> Just for the record which ISP are you using? The above is Vodafone.
I am using an Orange SIM card (french operator) and a MC7304 modem.
Software is:
ofono 1.20 + personal patches
connman 1.34
Information returned by Ofono in get_settings_cb (and not transmitted to
Connman due to my patch) says:
Jul 26 13:40:37 klk-lpbs-0504B4 daemon.debug ofonod[938]:
../git/drivers/qmimodem/gprs-context.c:get_settings_cb() APN:
orange.m2m.spec
Jul 26 13:40:37 klk-lpbs-0504B4 daemon.debug ofonod[938]:
../git/drivers/qmimodem/gprs-context.c:get_settings_cb() PDP type 0
Jul 26 13:40:37 klk-lpbs-0504B4 daemon.debug ofonod[938]:
../git/drivers/qmimodem/gprs-context.c:get_settings_cb() IP addr:
10.169.160.216
Jul 26 13:40:37 klk-lpbs-0504B4 daemon.debug ofonod[938]:
../git/drivers/qmimodem/gprs-context.c:get_settings_cb() Gateway:
10.169.160.217
Jul 26 13:40:37 klk-lpbs-0504B4 daemon.debug ofonod[938]:
../git/drivers/qmimodem/gprs-context.c:get_settings_cb() Gateway
netmask: 255.255.255.240
Jul 26 13:40:37 klk-lpbs-0504B4 daemon.debug ofonod[938]:
../git/drivers/qmimodem/gprs-context.c:get_settings_cb() Primary DNS:
192.168.10.110
Jul 26 13:40:37 klk-lpbs-0504B4 daemon.debug ofonod[938]:
../git/drivers/qmimodem/gprs-context.c:get_settings_cb() Secondary DNS:
194.51.3.56
After connman make its DHCP request, I have:
root@klk-lpbs-0504B4:~ # route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.4.4 0.0.0.0 UG 0 0 0 eth0
10.169.160.208 * 255.255.255.240 U 0 0 0 wwan3
10.169.160.217 * 255.255.255.255 UH 0 0 0 wwan3
192.168.4.0 * 255.255.254.0 U 0 0 0 eth0
192.168.4.4 * 255.255.255.255 UH 0 0 0 eth0
192.168.10.110 10.169.160.217 255.255.255.255 UGH 0 0 0 wwan3
194.51.3.56 10.169.160.217 255.255.255.255 UGH 0 0 0 wwan3
root@klk-lpbs-0504B4:~ # ifconfig wwan3
wwan3 Link encap:Ethernet HWaddr B6:2A:D2:26:FB:BC
inet addr:10.169.160.216 Bcast:10.169.160.223
Mask:255.255.255.240
UP BROADCAST RUNNING MULTICAST MTU:1430 Metric:1
RX packets:11 errors:0 dropped:0 overruns:0 frame:0
TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1340 (1.3 KiB) TX bytes:1955 (1.9 KiB)
So information returned by get_settings_cb looks good in my case. But I
am still not able to ping if Ofono give this information to Connman (in
this case connection is said to be up without calling DHCP).
Please find complete log of connection (with Ofono and Connman debug) in
attachment.
Christophe Ronco
>
>> Christophe Ronco
>>
>> I have also fixed the issue by creating a patch for Connman to run DHCP even
>> when network returns static/fixed IP. Its'a not the way to do, but it?s a
>> quick fix like yours.
> If we could find some sort of rule when to ignore the returned values
> from oFono than we can fallback to DHCP.
>
> Thanks,
> Daniel
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: log_extract.tar.gz
Type: application/gzip
Size: 4202 bytes
Desc: not available
URL:
<http://lists.01.org/pipermail/connman/attachments/20170726/7aefdc4f/attachment-0001.bin>
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 21, Issue 18
***************************************
