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: [PATCH 2/2] doc: Update IPv4 method values for services
(Daniel Wagner)
2. Re: [PATCH 1/2] wifi: Do not allow scan/autoscan on p2p
connected interface (Daniel Wagner)
3. Re: Cellular connection doesn't go online even if
ipv4.connman.net is reachable ? (Daniel Wagner)
4. Re: [PATCH 0/4] RTNL dellink handling (Daniel Wagner)
5. Re: [PATCH 2/2] doc: Update IPv4 method values for services
(Jose Blanquicet)
6. Re: Cellular connection doesn't go online even if
ipv4.connman.net is reachable ? (snorky snorky)
----------------------------------------------------------------------
Message: 1
Date: Thu, 8 Jun 2017 21:38:01 +0200
From: Daniel Wagner <[email protected]>
To: [email protected], [email protected]
Subject: Re: [PATCH 2/2] doc: Update IPv4 method values for services
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Jose,
On 05/30/2017 12:14 PM, [email protected] wrote:
> From: Jose Blanquicet <[email protected]>
>
> ---
> doc/service-api.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/doc/service-api.txt b/doc/service-api.txt
> index 712627a..1b2b488 100644
> --- a/doc/service-api.txt
> +++ b/doc/service-api.txt
> @@ -311,6 +311,12 @@ Properties string State [readonly]
> Possible values are "dhcp", "manual"
> and "off".
I've added the "auto" also to list above and applied the patches. I
tested a bit with my simple setup and everything still seems to work.
Let's see if someone gets unhappy :)
Anyway, could you take care to update also our test script and
connmanctl to support the 'auto' property?
Thanks,
Daniel
------------------------------
Message: 2
Date: Thu, 8 Jun 2017 21:40:27 +0200
From: Daniel Wagner <[email protected]>
To: Tomasz Bursztyka <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: [PATCH 1/2] wifi: Do not allow scan/autoscan on p2p
connected interface
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Tomasz,
On 06/01/2017 05:15 PM, [email protected] wrote:
> From: Jose Blanquicet <[email protected]>
>
> In eed27a6e1d1 was introduced the concept of p2p_device to identify the
> dedicated P2P-Group interface created by wpa_supplicant when a P2P
> connection is established. This concept is used to deny Scan and Autoscan
> (Introduced in b584447dde1) on P2P connected interfaces.
>
> However, if wpa_supplicant is configured to not create such dedicated
> P2P-Group interface and instead use directly the same one, then ConnMan
> needs a way to continue denying Scan/Autoscan on that P2P connected
> interface and that is the scope if this patch. With this modification,
> the p2p_device flag is also used to temporally mark the current interface
> connected with P2P.
Could you comment on this series? I looks good to me but I haven't
really worked with P2P.
Thanks,
Daniel
>
> ---
> plugins/wifi.c | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/plugins/wifi.c b/plugins/wifi.c
> index a49031c..551cfea 100644
> --- a/plugins/wifi.c
> +++ b/plugins/wifi.c
> @@ -402,8 +402,10 @@ static int peer_disconnect(struct connman_peer *peer)
> &peer_params);
> g_free(peer_params.path);
>
> - if (ret == -EINPROGRESS)
> + if (ret == -EINPROGRESS) {
> peer_cancel_timeout(wifi);
> + wifi->p2p_device = false;
> + }
>
> return ret;
> }
> @@ -2981,6 +2983,14 @@ static void peer_changed(GSupplicantPeer *peer,
> GSupplicantPeerState state)
> connman_peer_set_as_master(connman_peer,
> !g_supplicant_peer_is_client(peer));
> connman_peer_set_sub_device(connman_peer, g_wifi->device);
> +
> + /*
> + * If wpa_supplicant didn't create a dedicated p2p-group
> + * interface then mark this interface as p2p_device to avoid
> + * scan and auto-scan are launched on it while P2P is connected.
> + */
> + if (!g_list_find(p2p_iface_list, g_wifi))
> + wifi->p2p_device = true;
> }
>
> connman_peer_set_state(connman_peer, p_state);
>
------------------------------
Message: 3
Date: Thu, 8 Jun 2017 21:43:47 +0200
From: Daniel Wagner <[email protected]>
To: snorky snorky <[email protected]>, [email protected]
Subject: Re: Cellular connection doesn't go online even if
ipv4.connman.net is reachable ?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
On 06/02/2017 12:04 PM, snorky snorky wrote:
> Hello,
>
> I have experienced a strange behavior with cellular connections.
>
> I'm using two SIM from the same provider. One goes in Online state,
> but not the other.
>
> I have spied the DNS request and no response is received with the
> failing SIM, but a manual nslookup on ipv4.connman.net through the
> proper DNS (when the connection is up) successfully returns the proper
> IP and a curl on http://ipv4.connman.net/online/status.html succeed.
>
> I'm using 1.30.
>
> Did someone experience similar behavior? Can it be related to the ISP
> and a delay to wait before doing DNS request?
I had problem getting DHCP response from a ISP via normal DSL modem.
Something on our request seemed to upset the server and no response was
sent. One thing you could try is to record with tcpdump/wireshark the
handshake and post the result (or post a link to the files). Maybe there
is something to see.
Thanks,
Daniel
------------------------------
Message: 4
Date: Thu, 8 Jun 2017 21:48:24 +0200
From: Daniel Wagner <[email protected]>
To: Patrik Flykt <[email protected]>, [email protected]
Subject: Re: [PATCH 0/4] RTNL dellink handling
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Patrik,
On 06/02/2017 02:07 PM, Patrik Flykt wrote:
>
> Hi,
>
> wpa_supplicant sometimes deconfigures its link, with the kernel deleting
> all addresses associated with the network. Unfortunately RTNL dellinks
> are not handled very well in this case, causing ConnMan to miss all of
> them and believing that the service is still in state ready or online.
>
> In addition, IPv6 will stay in configuration state if no Router
> Advertisements are received. Fix this by properly disconnecting IPV6
> when enough Router Solicitations have been received.
>
> Both of these in combination with someone removing IP addresses with
> 'ip addr del' will disconnect the service after all addresses have been
> deleted.
>
>
> Please test,
Nothing exploded here on my side so far. I'll try them a bit longer over
the weekend.
Thanks,
Daniel
------------------------------
Message: 5
Date: Fri, 9 Jun 2017 08:03:26 +0000
From: Jose Blanquicet <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH 2/2] doc: Update IPv4 method values for services
Message-ID:
<cafc8ij++hkyfxfug2a8cmd4nkp0+qa1rhdj_821_scmlbr5...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Good morning Daniel,
On Thu, Jun 8, 2017 at 7:38 PM, Daniel Wagner <[email protected]> wrote:
> I've added the "auto" also to list above and applied the patches.
You are right, I forgot to add it to the list. Thanks!
> I tested a
> bit with my simple setup and everything still seems to work. Let's see if
> someone gets unhappy :)
>
> Anyway, could you take care to update also our test script and connmanctl to
> support the 'auto' property?
Well, even after this patch "auto" for IPv4 cannot be set by user, it
will be automatically set by ConnMan only in case DHCP fails and
IPv4LL was used to get the address. Therefore, connmanclt is still
fine as it is:
Modify:
static struct connman_option config_options[] = {
...
{"ipv4", 'i', "off|dhcp|manual <address> <netmask> <gateway>"},
...
}
Receive new properties:
connmnactl> wifi_xxxxx
...
Service wifi_xxxxx State = association
Service wifi_xxxxx State = configuration
Service wifi_xxxxx Ethernet = [ ... ]
Service wifi_xxxxx Ethernet = [ ... ]
Service wifi_xxxxx Domains = [ ]
Service wifi_xxxxx IPv4.Configuration = [ Method=auto ]
Service wifi_xxxxx State = ready
Service wifi_xxxxx Favorite = True
Connected wifi_xxxxx
Service wifi_xxxxx Domains = [ ]
Service wifi_xxxxx Proxy = [ ]
Technology wifi Connected = True
Service wifi_xxxxx IPv4 = [ Method=auto, Address=169.254.120.28,
Netmask=255.255.0.0 ]
Regarding test script, I guess you mean dhcp-test; I never used it
before so it will require some time, also because I am not sure how I
should modify it to test this patch because the actual aim here is to
align the IPv4 properties with the method that was really used.
Suggestions/Comments regarding this?
Regards,
Jose Blanquicet
------------------------------
Message: 6
Date: Fri, 9 Jun 2017 11:52:57 +0200
From: snorky snorky <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Subject: Re: Cellular connection doesn't go online even if
ipv4.connman.net is reachable ?
Message-ID:
<caozg-aouwmwanmyc3+foqdxn0wlb9dgfecgc5+kw9b9enpa...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi Daniel,
Here is a record of udp port 53 when my ppp0 connection is created
with the faulty SIM (tcpdump -s 0 -U -n -i any udp port 53):
https://filebin.ca/3PMlNuV1uKf4/export.pcapng
I have compared it with a working SIM and it seems similar. Only
timestamps or packet number are different.
Regards
On Thu, Jun 8, 2017 at 9:43 PM, Daniel Wagner <[email protected]> wrote:
> Hi,
>
> On 06/02/2017 12:04 PM, snorky snorky wrote:
>>
>> Hello,
>>
>> I have experienced a strange behavior with cellular connections.
>>
>> I'm using two SIM from the same provider. One goes in Online state,
>> but not the other.
>>
>> I have spied the DNS request and no response is received with the
>> failing SIM, but a manual nslookup on ipv4.connman.net through the
>> proper DNS (when the connection is up) successfully returns the proper
>> IP and a curl on http://ipv4.connman.net/online/status.html succeed.
>>
>> I'm using 1.30.
>>
>> Did someone experience similar behavior? Can it be related to the ISP
>> and a delay to wait before doing DNS request?
>
>
> I had problem getting DHCP response from a ISP via normal DSL modem.
> Something on our request seemed to upset the server and no response was
> sent. One thing you could try is to record with tcpdump/wireshark the
> handshake and post the result (or post a link to the files). Maybe there is
> something to see.
>
> Thanks,
> Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 20, Issue 5
**************************************
