Re: searchdns does not work in connman 1.30
On 27.10.2015 15:49, Pasi Sjöholm wrote: > On 27.10.2015 15:00, SpiderX wrote: >> This was fixed once (see commit >> http://git.kernel.org/cgit/network/connman/connman.git/commit/src/dnsproxy.c?h=1.30=0439194ed0c5a90f61dbef86d9a51307764da2d7), >> but then was refactored in later commits Technically that commit is still working but the thing is that the uncompress() and forward_dns_reply() are not able to handle few special cases. > I'm able to reproduce the issue. However it seems that connman's > dnsproxy properly caches the response, so if I do "host -v -t a bz" > immediately after the first query there will be a proper response. Ok, it's not ConnMan's cache from where the response comes correctly on the next time. The issue is: 1) Some upstream DNS-servers add details in the Authority and additional sections of the reply when being queried. Eg. dnsmasq does this on this on replies not coming from it's cache but for ones coming from the cache it replies only the asked records. First query: host -t a -v bz.siirappi.com --cut-- ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31498 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3 ;; QUESTION SECTION: ;bz.siirappi.com. IN A ;; ANSWER SECTION: bz.siirappi.com.60 IN A 1.2.3.4 ;; AUTHORITY SECTION: siirappi.com. 3367IN NS ns2.afraid.org. siirappi.com. 3367IN NS ns1.siirappi.com. ;; ADDITIONAL SECTION:http://git.kernel.org/cgit/network/connman/connman.git/tree/src/dnsproxy.c#n2056 ns1.siirappi.com. 60 IN 2001:41d0:8:196a::2 ns2.afraid.org. 67 IN A 208.43.71.243 ns2.afraid.org. 67 IN 2607:f0d0:3001:92::2 --cut-- Second query (from cache): --cut-- ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53006 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;bz.siirappi.com. IN A ;; ANSWER SECTION: bz.siirappi.com.53 IN A 1.2.3.4 --cut-- 2) As a workaround Google's public DNS-servers seem not to have any authority / additional sections in their replies. Those should work ok. 3) For me the uncompress() returns null when being asked to uncompress nscount from the replies and that's enough for it to bail out. (http://git.kernel.org/cgit/network/connman/connman.git/tree/src/dnsproxy.c#n2056) --cut-- connmand[10470]: src/dnsproxy.c:forward_dns_reply() req 0x18c02b0 dstid 0x8fe0 altid 0x0865 rcode 0 connmand[10470]: src/dnsproxy.c:uncompress() count 1 ptr 0xbe9d2575 end 0xbe9d260b uptr 0xbe9d2128 connmand[10470]: src/dnsproxy.c:uncompress() pos 2 ulen 16 left 1017 name bsiirappicom connmand[10470]: src/dnsproxy.c:uncompress() count 2 ptr 0xbe9d2585 end 0xbe9d260b uptr 0xbe9d2147 connmand[10470]: src/dnsproxy.c:uncompress() pos 2 ulen 13 left 986 namesiirappicom connmand[10470]: src/dnsproxy.c:uncompress() pos 6 ulen 17 left 962 name nssiirappicom connmand[10470]: src/dnsproxy.c:uncompress() failed dns_class != ns_c_in --cut-- So I guess the bug itself is in the uncompress()-function. JukkaR: can you please help me with this one as you know how the uncompress() should work? Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] wifi: Reset device->scanning if scan has not returned in 15 secs
On 28.10.2015 11:32, Patrik Flykt wrote: >> From: Pasi Sjöholm <pasi.sjoh...@jollamobile.com> >> >> Due unknown reason sometimes device->scanning is not set to false after >> wifi scanning (connman 1.30 and wpa_supplicant 2.5). >> This is probably due callback-function not being called after wifi scan >> and therefore it needs to have a timer to prevent deadlock. >> --- > > You probably have evidence that the callback is not called, right? > Please state that in the commit message. I don't have logs stored anymore on my disk but I'm rather sure that wifi.c:scan_callback() is not being called when this happens as all attemps to scan by connman are blocked by device->scanning being true (I usually get bored after waiting for couple of hours ;)). When the deadlock happens and I can manually ask wpa_supplicant to scan available networks from the commandline. After doing this ConnMan will survive from the deadlock through NetworkAdded being signaled and autoconnectable network being available as ConnMan gets connected and autoscan will be stopped. The problem is hard to reproduce (no known steps) but it has happened to me around 4 times within last few weeks. > What will happen if wpa_supplicant will call the callback after 16 > seconds, i.e. after ConnMan has triggered scan_fail_timeout? Will there > be any artefacts if this happens? By quickly looking at the code there shouldn't be any issues but I can't be 100% sure. In theory one could stop autoscan after scan has been started and restart it immediately before the scan_callback gets called to have the same effect and ConnMan must be able to handle it. Currently the TIMEOUT defined in the dbus.c seems to be 30 secs and after that the callback-function should be called if no reply has been received (if I read and understand the code correctly). So having 60 seconds timeout should be ok as there should not be any calls coming from wpa_supplicant after that. I will modify the timeout and edit the commit message a bit. Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: searchdns does not work in connman 1.30
On 27.10.2015 15:00, SpiderX wrote: > ~ $ host -v nefrit1 > Trying "nefrit1" > Host nefrit1 not found: 3(NXDOMAIN) > Received 100 bytes from 127.0.0.1#53 in 0 ms > > So, we have two queries to two nameservers. Two of them have returned > NXDomain, and this result was sent back to a client. > I think this behaviour is wrong, client shouldn't get NXDomain when > other non-nxdomain replies from nameservers exist. > > This was fixed once (see commit > http://git.kernel.org/cgit/network/connman/connman.git/commit/src/dnsproxy.c?h=1.30=0439194ed0c5a90f61dbef86d9a51307764da2d7), > but then was refactored in later commits I'm able to reproduce the issue. However it seems that connman's dnsproxy properly caches the response, so if I do "host -v -t a bz" immediately after the first query there will be a proper response. Though, it would be nice if it would work also when the response is not in the cache. I will try to check what broke it.. First try: host -v -t a bz Trying "bz" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44260 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;bz.IN A Received 20 bytes from 127.0.0.1#53 in 122 ms Second try: host -v -t a bz Trying "bz" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26675 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;bz.IN A ;; ANSWER SECTION: bz. 49 IN A 1.2.3.4 Received 38 bytes from 127.0.0.1#53 in 7 ms Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: connman online test
Hi, we (Jolla) did something like that earlier: https://lists.connman.net/pipermail/connman/2014-April/017033.html https://lists.connman.net/pipermail/connman/2014-April/017034.html I'm willing to rebase the patch if upstream wants to get it merged. Br, Pasi On 09.07.2015 11:05, Jussi Kukkonen wrote: Hi, Now that we're talking about the online check... I've talked to people who considered this behaviour calling home and thought it unreasonable that a) it's not possible to prevent the online check from happening via configuration and b) it's not possible to set the checked URL in the configuration Would you guys be willing to change the above (or at least willing to take patches)? - Jussi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] wifi: disconnect if wpa_s state changes from completed to scanning
Hi Tomasz,
Will still need to modify the patch a bit because start_autoscan()
checks for wifi-connected and will not start if it's true. Therefore
moving start_autoscan() after the wifi-connected has been set to false
in the end of the interface_state()-function.
Br,
Pasi
On 06.05.2015 11:51, Tomasz Bursztyka wrote:
Hi Pasi,
Nice catch!
ACK from me.
Tomasz
From: Pasi Sjöholm pasi.sjoh...@jollamobile.com
It's possible from wpa_s to change the state from completed to
scanning without going through disconnected state if interface
signals that the carrier went off and on (IFF_LOWER_UP flag).
This will cause dead lock similar in
c810464828d6764bea304de3e9b6b151aa05e313 if the wifi gets into
associating state as the network-connected is still true but
wifi-connected is not. --- plugins/wifi.c | 5 + 1 file
changed, 5 insertions(+)
diff --git a/plugins/wifi.c b/plugins/wifi.c index
d0d7917..47df08e 100755 --- a/plugins/wifi.c +++
b/plugins/wifi.c @@ -2341,6 +2341,11 @@ static void
interface_state(GSupplicantInterface *interface) switch (state)
{ case G_SUPPLICANT_STATE_SCANNING: +if (wifi-connected)
{ +connman_network_set_connected(network, false); +
start_autoscan(device); +} + break; case
G_SUPPLICANT_STATE_AUTHENTICATING:
___ connman mailing
list connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH v2] wifi: disconnect if wpa_s state changes from completed to scanning
Hi Tomasz,
On 06.05.2015 13:46, Tomasz Bursztyka wrote:
+case G_SUPPLICANT_STATE_SCANNING: +if
(wifi-connected) { +wifi-connected = false; +
start_autoscan(device); +} else { +
wifi-connected = false; +}
You could remove the else { } (but keep the inner statement)
Done.
With a unique wifi device, once connected, it is still possible to
do a scan (and it stays connected of course). Can you check if your
patch does not break this?
Yes, scanning still works (nothing gets disconnected) and wpa_s does
not change the interface state from completed to anything else while
doing extra scans while being connected.
Br,
Pasi
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH v3] wifi: disconnect if wpa_s state changes from completed to scanning
Hi Jukka,
+case G_SUPPLICANT_STATE_SCANNING: + if (wifi-connected) { +
wifi-connected = false; + start_autoscan(device); +
} else +
wifi-connected = false; + break;
or you could just say
+ if (wifi-connected) + start_autoscan(device);
+ +
wifi-connected = false; +break;
Not really, because that was the original problem why I did the
version 2 of the patch. This is due wifi-connected needs to be false
before start_autoscan() can actually happen as there is if
(wifi-connected) return; check on the start_autoscan().
Br,
Pasi
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH 1/3] wifi: Introduce PassiveWiFiScan option
Hi Tomasz,
-} else if (wifi-connected) { +} else if
(wifi-connected || connman_setting_get_bool(PassiveWiFiScan))
{ g_supplicant_free_scan_params(scan_params); return
wifi_scan_simple(device);
If you use PassiveWiFiScan only here, then you are still using
active scan for auto-connection - so still leaking SSIDs - when not
connected.
Yes, for hidden networks but not for anything else.
Is this a wanted behavior? Because then PassiveWiFiScan is
semantically wrong as it does not really completely avoid active
scan.
Well, I would say yes because the hidden networks are just
fundamentally broken. I can rename PassiveWifiScan into something else.
Br,
Pasi
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: How does connman handle scan_ssid?
On 17.03.2015 17:57, Sven Schwedas wrote: On 2015-03-17 16:47, Pasi Sjöholm wrote: On 17.03.2015 14:04, Tomasz Bursztyka wrote: There is an issue however: the hidden SSIDs. These ones, to autoconnect, definitely need an active scan. We could run it if only a hidden service is created for instance. But that means we could still leak some SSIDs - the hidden ones - if we are not located where these could be found. This is exactly what we (Jolla) been doing in the Sailfish OS with ConnMan since July 2014 per customer request. No huge or minor issues experienced. Can this patch be mainlined? Yes I guess so, didn't have the time to send the patch this week but will try to do it on the next week. Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [RFC] service: Let service error indicate invalid WiFi PSK passphrase
On 23.03.2015 13:40, Patrik Flykt wrote: On Thu, 2015-02-26 at 13:43 +0200, Patrik Flykt wrote: Deleting a WiFi PSK passphrase in response to an invalid key error causes the passphrase disappear from the save file. This results in a discovered WiFi network with identical SSID and security method to remove the saved passphrase of the actual network. Instead of always removing the passphrase, use service error to keep track of the passphrase validity. Do this by unsetting service error only when the service enters ready or disconnect states or when the passphrase is supplied by the agent. In all other states the service error is not modified and the error is used to detect and invalid key upon service connection. Reported by Pasi Sjöholm. Didn't see any immediate breakage while testing so this one is now applied. Was just about to reply that this is ok, and working. My original problems were due applying the patch into wrong branch. :) Thanks! Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: How does connman handle scan_ssid?
On 17.03.2015 13:02, Sven Schwedas wrote: Cf. http://blog.viraptor.info/post/your-wifi-shows-me-where-you-live-work-and-travel How does connman handle this? There don't seem to be configuration options for it. ConnMan will actively scan any previously connected network(s) (or networks which have been configured as hidden) when not connected, but uses passive scanning when being connected. Yes, this will make your device as track-able but its relatively easy to patch the ConnMan to only use passive scanning for networks which are not hidden. Another option would be to randomize the MAC-address of the used interface for each scan but it is easier said than done. ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: How does connman handle scan_ssid?
On 17.03.2015 14:04, Tomasz Bursztyka wrote: There is an issue however: the hidden SSIDs. These ones, to autoconnect, definitely need an active scan. We could run it if only a hidden service is created for instance. But that means we could still leak some SSIDs - the hidden ones - if we are not located where these could be found. This is exactly what we (Jolla) been doing in the Sailfish OS with ConnMan since July 2014 per customer request. No huge or minor issues experienced. Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [RFC] service: Let service error indicate invalid WiFi PSK passphrase
Hi,
this seems to work, and passwords are not getting flushed into thin air
anymore.
However there is a one problem still left in
__connman_service_connect()-function. It has a call
__connman_service_clear_error(service); at line 5973
(https://git.kernel.org/cgit/network/connman/connman.git/tree/src/service.c#n5973)
which then again has a call to set_error(service,
CONNMAN_SERVICE_ERROR_UNKNOWN).
That will cause err = service_connect(service); to never return
NOKEY-error.
(https://git.kernel.org/cgit/network/connman/connman.git/tree/src/service.c#n5975)
So, I guess set_error(service, CONNMAN_SERVICE_ERROR_UNKNOWN) needs to
be removed from __connman_service_clear_error as well to keep the track
of the error.
Br,
Pasi
On 26.02.2015 13:43, Patrik Flykt wrote:
Deleting a WiFi PSK passphrase in response to an invalid key error
causes the passphrase disappear from the save file. This results in
a discovered WiFi network with identical SSID and security method
to remove the saved passphrase of the actual network.
Instead of always removing the passphrase, use service error to keep
track of the passphrase validity. Do this by unsetting service error
only when the service enters ready or disconnect states or when the
passphrase is supplied by the agent. In all other states the service
error is not modified and the error is used to detect and invalid key
upon service connection.
Reported by Pasi Sjöholm.
---
src/service.c | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/src/service.c b/src/service.c
index 3ed98ed..fdec83e 100644
--- a/src/service.c
+++ b/src/service.c
@@ -5308,6 +5308,8 @@ static int service_indicate_state(struct
connman_service *service)
break;
case CONNMAN_SERVICE_STATE_READY:
+ set_error(service, CONNMAN_SERVICE_ERROR_UNKNOWN);
+
if (service-new_service
__connman_stats_service_register(service) == 0)
{
/*
@@ -5374,6 +5376,7 @@ static int service_indicate_state(struct
connman_service *service)
break;
case CONNMAN_SERVICE_STATE_DISCONNECT:
+ set_error(service, CONNMAN_SERVICE_ERROR_UNKNOWN);
reply_pending(service, ECONNABORTED);
@@ -5418,9 +5421,6 @@ static int service_indicate_state(struct
connman_service *service)
break;
}
- if (new_state != CONNMAN_SERVICE_STATE_FAILURE)
- set_error(service, CONNMAN_SERVICE_ERROR_UNKNOWN);
-
service_list_sort();
__connman_connection_update_gateway();
@@ -5448,14 +5448,16 @@ int __connman_service_indicate_error(struct
connman_service *service,
if (!service)
return -EINVAL;
+ if (service-state == CONNMAN_SERVICE_STATE_FAILURE)
+ return -EALREADY;
+
set_error(service, error);
/*
* Supplicant does not always return invalid key error for
* WPA-EAP so clear the credentials always.
*/
- if (service-error == CONNMAN_SERVICE_ERROR_INVALID_KEY ||
- service-security == CONNMAN_SERVICE_SECURITY_8021X)
+ if (service-security == CONNMAN_SERVICE_SECURITY_8021X)
clear_passphrase(service);
__connman_service_set_agent_identity(service, NULL);
@@ -5852,6 +5854,9 @@ static int service_connect(struct connman_service
*service)
case CONNMAN_SERVICE_SECURITY_PSK:
case CONNMAN_SERVICE_SECURITY_WPA:
case CONNMAN_SERVICE_SECURITY_RSN:
+ if (service-error == CONNMAN_SERVICE_ERROR_INVALID_KEY)
+ return -ENOKEY;
+
if (!service-passphrase) {
if (!service-network)
return -EOPNOTSUPP;
@@ -5878,9 +5883,10 @@ static int service_connect(struct connman_service
*service)
* missing. Agent provided credentials can be used as
* fallback if needed.
*/
- if ((!service-identity
+ if (((!service-identity
!service-agent_identity) ||
- !service-passphrase)
+ !service-passphrase) ||
+ service-error ==
CONNMAN_SERVICE_ERROR_INVALID_KEY)
return -ENOKEY;
break;
@@ -5975,16 +5981,15 @@ int __connman_service_connect(struct connman_service
*service,
err = service_connect(service);
service-connect_reason = reason;
- if (err = 0) {
- set_error(service, CONNMAN_SERVICE_ERROR_UNKNOWN);
+
+ if (err = 0)
return 0;
- }
if (err == -EINPROGRESS) {
if (service-timeout
Re: [RFC v2] network: Merge identical ipconfig code paths
Hi, tested this also with jolla's fork and seems to be working (played with it only 10min). Br, Pasi On 11.02.2015 13:54, Patrik Flykt wrote: Configure IPv4 and IPv6 configurations only once in __connman_network_enable_ipconfig() and use this function when setting the network connected. Remove obsolete function and rework the rest to centralise configuration state and error reporting. The variable network-connecting is true as long as the IPv4 or IPv6 address configuration phase is ongoing. --- Hi, This is a fairly large patch that removes duplicate code in set_connected() in favor of using the one in __connman_network_set_ipconfig(). There is no change in functionality in this patch. v2 fixes a glitch with variable naming wrt rebasing Please test, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] ipconfig: use only settings related to configuration method
Hi, On 12.02.2015 15:28, Patrik Flykt wrote: From: Pasi Sjöholm pasi.sjoh...@jollamobile.com If service is ever being configured with manual ip-address, netmask and gateway and later changed to dhcp, the related settings must not be read if configuration method is not manual or fixed. Otherwise they can possible collide with the settings got from dhcp-server if they are exactly the same (eg. dhcp.c: lease_available_cb()). This could lead network interface not being configured correctly. --- Hi, I made the switch statement a bit more explicit, please check this is still how it is inteded and doesn't break anything by accident. Seems to be working as expected. :) Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH 2/3] network: fix eternal associating/connecting with IPv6-only
On 10.02.2015 16:56, Patrik Flykt wrote:
if (service) {
connman_service_create_ip6config(service, network-index);
+network-connecting = false;
+
+connman_network_set_associating(network, false);
+
__connman_service_ipconfig_indicate_state(service,
CONNMAN_SERVICE_STATE_CONFIGURATION,
CONNMAN_IPCONFIG_TYPE_IPV6);
We're not connected yet at this point, network-connecting can go false
starting with dhcpv6_callback().
The network-connected is set to true already on set_connected(),
meaning it's done before connecting is changed to false (which is done
on autoconf_ipv6_set()).
Therefore doing network-connecting = false here does not do anything as
it is already false. Will update the PR.
Br,
Pasi
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH 1/2] ofono: always set configuration method when connected
Hi,
On 11.02.2015 13:34, Patrik Flykt wrote:
--- a/plugins/ofono.c
+++ b/plugins/ofono.c
@@ -277,12 +277,11 @@ static void set_connected(struct modem_data *modem)
if (!service)
return;
-if (method == CONNMAN_IPCONFIG_METHOD_FIXED ||
-method == CONNMAN_IPCONFIG_METHOD_DHCP) {
-connman_service_create_ip4config(service, index);
-
-connman_network_set_ipv4_method(modem-network, method);
+connman_service_create_ip4config(service, index);
+connman_network_set_ipv4_method(modem-network, method);
So if method is off or unknown, we'd unnecessarily create and ipconfig
here, right?
connman_service_create_ip4/6config() will not create ipconfig if it
already exists, and we can't set method unless we have existing ipconfig
for a service. So it is necessary even when method is OFF or UNKNOWN.
Br,
Pasi
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: [RFC] ofono: Set ipconfig off if indicated that the protocol is not used
On 09.02.2015 10:00, Pasi Sjöholm wrote: Otherwise everything else looks ok, but Protocol-message will never happen when modem-active is true. At least I don't have a modem which would allow changing protocol when modem is connected. And by this I mean the two lines below could be removed. :) +if (modem-active) +set_connected(modem); ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [RFC] ofono: Set ipconfig off if indicated that the protocol is not used
On 06.02.2015 15:43, Patrik Flykt wrote:
@@ -1261,6 +1312,17 @@ static gboolean context_changed(DBusConnection *conn,
remove_network(modem);
}
+
+ } else if (g_str_equal(key, Protocol)
+ dbus_message_iter_get_arg_type(value) == DBUS_TYPE_STRING ) {
+ const char *ip_protocol;
+
+ dbus_message_iter_get_basic(value, ip_protocol);
+
+ set_context_ipconfig(modem-context, ip_protocol);
+
+ if (modem-active)
+ set_connected(modem);
Otherwise everything else looks ok, but Protocol-message will never
happen when modem-active is true. At least I don't have a modem which
would allow changing protocol when modem is connected.
Br,
Pasi
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
RE: [PATCH 2/3] [connman] ofono: Set CONNMAN_IPCONFIG_METHOD_AUTO/DHCP if not _FIXED
Hi, oFono ConnectionContext does not have a 'Method' property specified in the IPv6.Settings dict and it is also specified in RFC 6459 that IPv6 uses autoconfiguration. Therefore I rather make CONNMAN_IPCONFIG_METHOD_AUTO mandatory with patch ofono: IPv6 contexts use stateless autoconfiguration and/or DHCPv6 and go forward with that solution. Was it the IPv6 only context that broke after this? Yes. However I will still want part of this patch to be applied: 1) connman_network_set_index(modem-network, index); ^ Should be called for IPv6 too, and preferably only one time. 2) If modem-context-ipv4_method is not CONNMAN_IPCONFIG_METHOD_FIXED we need to call connman_network_set_ipv4_method(modem-network, CONNMAN_IPCONFIG_METHOD_DHCP); so that with IPv6-only context (or missing IPv4-settings in dual-context) we will not set the old fixed IP-address configuration for the interface. Will send patch soon. Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] counter: fix possible memory leak
Hi,
Patrik, you have probably missed this one?-)
Br,
Pasi
On 08.01.2015 23:56, pasi.sjoh...@jolla.com wrote:
From: Pasi Sjöholm pasi.sjoh...@jollamobile.com
DBusMessage message leaks memory if not cleaned when
counter is not found.
---
src/counter.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/counter.c b/src/counter.c
index 06e5daf..8ea6205 100644
--- a/src/counter.c
+++ b/src/counter.c
@@ -133,8 +133,11 @@ void __connman_counter_send_usage(const char *path,
struct connman_counter *counter;
counter = g_hash_table_lookup(counter_table, path);
- if (!counter)
+ if (!counter) {
+ if (message)
+ dbus_message_unref(message);
return;
+ }
dbus_message_set_destination(message, counter-owner);
dbus_message_set_path(message, counter-path);
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH 3/3] [connman] ofono: Call set_connected if new configuration received while connected
On 28.01.2015 14:13, Patrik Flykt wrote: I meant that why isn't the whole message parsed through first, i.e. why is set_connected() called immediately after extracting IPv4/IPv6 settings and not after all the properties have been handled. /* * oFono guarantees the ordering of Settings and * Active. Settings will always be send before Active = True. * That means we don't have to order here. */ set_connected never gets called before we have received Active = True-signal. After that we do not get anymore Active = True if context is changed, so from where would we know that all properties are handled/sent? And yes.. the both IPv4- and IPv6-settings are sent in separate messages as well as the other properties. Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
RE: [PATCH 3/3] [connman] ofono: Call set_connected if new configuration received while connected
3) IMO, the changes from signaled changes from ofono should be taken in use. Sorry, people interrupting me.. :D 3) IMO, the changes signaled from ofono to already active connection should be taken in use. Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
RE: [PATCH 3/3] [connman] ofono: Call set_connected if new configuration received while connected
Hi,
Ofono can signal new configuration while context is active and therefore
set_connected needs to be called.
--- a/plugins/ofono.c
+++ b/plugins/ofono.c
+
+ if (modem-active modem-context-index -1)
+ set_connected(modem);
} else if (g_str_equal(key, IPv6.Settings)) {
DBG(%s IPv6.Settings, modem-path);
extract_ipv6_settings(value, modem-context);
+
+ if (modem-active modem-context-index -1)
+ set_connected(modem);
Why does set_connected() not wait until all properties are checked?
1) RIL signals to ofono that the context is active.
2) ofono can't know if there will be additional signals or not, how long to to
wait for?
3) IMO, the changes from signaled changes from ofono should be taken in use.
Br,
Pasi
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
RE: [PATCH] Add setting: UpdateResolvConf
Hi Martin, This patch adds a new setting to main.conf, `UpdateResolvConf' (default true), which controls the updating of /etc/resolv.conf. If set to False, /etc/resolv.conf will not be updated. You know there is --nodnsproxy option when starting connman? Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
RE: [PATCH 3/6] ofono: Old nameservers need to be cleared
Let's start from the basics. Please explain the following: - When there is an IPv4 only bearer, which are the possible IPv4 configuration methods? CONNMAN_IPCONFIG_METHOD_FIXED CONNMAN_IPCONFIG_METHOD_DHCP - When there is an IPv6 only bearer, which are the possible IPv6 configuration methodos? CONNMAN_IPCONFIG_METHOD_FIXED CONNMAN_IPCONFIG_METHOD_AUTO (code supports it but I have not seen it happenning) - When there is a dual IPv4/IPv6 bearer, which are the possible IPv4 and IPv6 configuration methods? ipv4: CONNMAN_IPCONFIG_METHOD_FIXED CONNMAN_IPCONFIG_METHOD_DHCP ipv6 CONNMAN_IPCONFIG_METHOD_AUTO CONNMAN_IPCONFIG_METHOD_FIXED (supported by the code, but AUTO is the official way according to 3gpp) There can not be any old nameservers left hanging around, as the code goes like this: char *nameservers = NULL; ... while (...) ... g_free(context-ipv4_nameservers); context-ipv4_nameservers = nameservers; So if oFono provided no nameservers, they are unset after exiting this function as far as I can see. If oFono provided nameservers without giving an IP address, the nameservers are currently remembered. Once DHCP is run, any DHCP provided nameservers replace the old ones. If there are no nameservers available via DHCP, the best thing one can do is to keep the ones provided by oFono earlier with this message. What I've seen while testing this is that dhcpv6 does not replace the old nameservers when doing this: 1) First connect with ipv6-pdp and you will get nameservers 2001::1 and 2001::2 as fixed from ofono. 2) Disconnect and change the configuration from ofono to dual/ipv4v6. 3) Connect and query service from connman and you will see 2001::1 and 2001::2 plus slaacdhcpv6 provided nameservers 2001::3 and 2001::4. With the patch applied, the nameservers at point 3 will be only the slaacdhcpv6 provided 2001::3 and 2001::4. and yes, I have not had this happening with ipv4 because I have no sim from a operator which would use CONNMAN_IPCONFIG_METHOD_DHCP with ipv4 but for sure it happens with ipv6. If oFono is sending outdated information it is not supposed to send when no IP address is present (in the DHCP case, I assume), please fix oFono. It is not ofono but connman using the outdated information. Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
RE: [PATCH 3/6] ofono: Old nameservers need to be cleared
Hi, If the nameservers indeed are not attached to the message from oFono while ConnMan keeps on using them, some other part of the code needs fixing. Patch 3/6 may seem to work simply because some other patch in the series causes nameservers to be removed later on. This especially if all of them are tested at the same time. Nope, they are not removed anywhere else, the modem-context-ipv4_nameservers and ipv6 are not cleared after disconnection. They are only cleared if the context is completely removed. Sure I could move the freeing of the dns-servers to the set_disconnected(); but it is still the same fix. Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
RE: [PATCH 3/6] ofono: Old nameservers need to be cleared
Sounds like disconnection part is where this needs to be fixed. Will update the patchset, and include following code to set_connected(): + if (!modem-context) + return; + + connman_ipaddress_free(modem-context-ipv4_address); + modem-context-ipv4_address = NULL; + modem-context-index = -1; + g_free(modem-context-ipv4_nameservers); + modem-context-ipv4_nameservers = NULL; + + connman_ipaddress_free(modem-context-ipv6_address); + modem-context-ipv6_address = NULL; + modem-context-index = -1; + g_free(modem-context-ipv6_nameservers); + modem-context-ipv6_nameservers = NULL; The ip-address freeing from extract_ipv4/6 should be part of set_disconnected() as well. Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
RE: [PATCH 3/6] ofono: Old nameservers need to be cleared
What I've seen while testing this is that dhcpv6 does not replace the old
nameservers when doing this:
1) First connect with ipv6-pdp and you will get nameservers 2001::1 and
2001::2 as fixed from ofono.
2) Disconnect and change the configuration from ofono to dual/ipv4v6.
3) Connect and query service from connman and you will see 2001::1 and
2001::2 plus slaacdhcpv6 provided nameservers 2001::3 and 2001::4.
Maybe you should provide an ofono-monitor log (or similar) of what oFono
actually sends? Since it is still unclear from this discussion whether
the fault is with connman or oFono.
If you insist.. (I've cutted pieces off from the ipv6-addresses) ;)
{ConnectionContext} [/ril_0/context1] Protocol = ip
{ConnectionContext} [/ril_0/context1] Settings = { Gateway = 10.233.105.246,
Address = 10.233.105.245, Method = static, Netmask = 255.255.255.0, Interface =
rmnet0, DomainNameServers = 62.241.198.245 62.241.198.246 }
{ConnectionContext} [/ril_0/context1] Active = True
{ConnectionContext} [/ril_0/context1] Settings = {}
{ConnectionContext} [/ril_0/context1] Active = False
{ConnectionContext} [/ril_0/context1] Protocol = ipv6
{ConnectionContext} [/ril_0/context1] IPv6.Settings = { Gateway = 2001::1223,
Address = 2001::8a0f, Interface = rmnet0, DomainNameServers = 2001::0001
2001::0002 }
{ConnectionContext} [/ril_0/context1] Active = True
{ConnectionContext} [/ril_0/context1] IPv6.Settings = {}
{ConnectionContext} [/ril_0/context1] Active = False
{ConnectionContext} [/ril_0/context1] Protocol = dual
{ConnectionContext} [/ril_0/context1] Settings = { Gateway = 10.233.105.246,
Address = 10.233.105.245, Method = static, Netmask = 255.255.255.0, Interface =
rmnet0, DomainNameServers = 62.241.198.245 62.241.198.246 }
{ConnectionContext} [/ril_0/context1] IPv6.Settings = { Interface = rmnet0 }
{ConnectionContext} [/ril_0/context1] Active = True
{ConnectionContext} [/ril_0/context1] Settings = {}
{ConnectionContext} [/ril_0/context1] IPv6.Settings = {}
{ConnectionContext} [/ril_0/context1] Active = False
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
RE: [PATCH 3/6] ofono: Old nameservers need to be cleared
{ConnectionContext} [/ril_0/context1] Protocol = ipv6
{ConnectionContext} [/ril_0/context1] IPv6.Settings = { Gateway =
2001::1223, Address = 2001::8a0f, Interface = rmnet0, DomainNameServers =
2001::0001 2001::0002 }
{ConnectionContext} [/ril_0/context1] Active = True
{ConnectionContext} [/ril_0/context1] IPv6.Settings = {}
{ConnectionContext} [/ril_0/context1] Active = False
{ConnectionContext} [/ril_0/context1] Protocol = dual
{ConnectionContext} [/ril_0/context1] Settings = { Gateway = 10.233.105.246,
Address = 10.233.105.245, Method = static, Netmask = 255.255.255.0,
Interface = rmnet0, DomainNameServers = 62.241.198.245 62.241.198.246 }
{ConnectionContext} [/ril_0/context1] IPv6.Settings = { Interface = rmnet0 }
Interesting that in dual-mode the IPv6 settings are different than in
IPv6 only mode. Is this supposed to be this way?
Yes, basicly slaac (+dhcpv6 for dns) is the only supported way of configuration
of ipv6-addresses in dual-mode (tried to find some documentation about plain
ipv6-pdp which would be available in public but did not succeed in 5mins).
Anyway, https://tools.ietf.org/html/rfc6459
5.2 IPv6 Address Configuration
IPv6 Stateless Address Autoconfiguration (SLAAC), as specified in
[RFC4861] and [RFC4862], is the only supported address configuration
mechanism. Stateful DHCPv6-based address configuration [RFC3315] is
not supported by 3GPP specifications.
{ConnectionContext} [/ril_0/context1] Active = True
{ConnectionContext} [/ril_0/context1] Settings = {}
{ConnectionContext} [/ril_0/context1] IPv6.Settings = {}
{ConnectionContext} [/ril_0/context1] Active = False
Otherwise seems like oFono is doing everything just fine.
Yes, and everything is working with the patchset unlike without it only
ip(v4)-pdp works ok.
Another operator (Three.co.uk):
{ConnectionContext} [/ril_0/context1] Protocol = dual
{ConnectionContext} [/ril_0/context1] Settings = { Method = static, Interface =
rmnet0, DomainNameServers = 217.171.132.1 217.171.132.1, Netmask =
255.255.255.0, Address = 92.41.159.199, Gateway = 92.41.159.193 }
{ConnectionContext} [/ril_0/context1] IPv6.Settings = { Interface = rmnet0 }
{ConnectionContext} [/ril_0/context1] Active = True
{ConnectionContext} [/ril_0/context1] Settings = {}
{ConnectionContext} [/ril_0/context1] IPv6.Settings = {}
{ConnectionContext} [/ril_0/context1] Active = False
Br,
Pasi
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
RE: [PATCH 2/6] ofono: Implement protocol-message handling for context_changed
Hi,
extract_ipv6_settings(value, modem-context);
+ } else if (g_str_equal(key, Protocol)) {
+ DBG(%s Protocol, modem-path);
+
+ modem-context-ipv4_method = CONNMAN_IPCONFIG_METHOD_UNKNOWN;
+ modem-context-ipv6_method = CONNMAN_IPCONFIG_METHOD_UNKNOWN;
} else if (g_str_equal(key, Active)) {
Why isn't the value of the oFono 'Protocol' property considered above?
1) Protocol can be only set on ofono when context is not active (connected).
2) We just want to reset the ipv4/6_method to UNKNOWN-state so that both will
have to be reconsidered next time when getting online as we do not want to
reuse the old configuration from connman side (ip-addres, gateway..) when
running set_connected(). E.g. connman setting up (saved) fixed ipv6-address
while doing ipv4-only.
3) I don't see any point doing unnecessary comparisation like:
if (ip) modem-context-ipv6_method = CONNMAN_IPCONFIG_METHOD_UNKNOWN;
else if (ipv6) modem-context-ipv4_method = CONNMAN_IPCONFIG_METHOD_UNKNOWN;
when we are going to setup the correct method in extract_ipv4_settings and
extract_ipv6_settings but as those are only run when correct message is
received therefore we need to reset the methods beforehand.
Br,
Pasi
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
RE: [PATCH 3/6] ofono: Old nameservers need to be cleared
Hi, At the start of both functions, nameservers is set to NULL. If the 'DomainNameServers' property is set in the message, the nameservers take the value supplied. At the end of both functions there are these two lines which appear to remove the old values from the context like so: g_free(context-ipv6_nameservers); context-ipv6_nameservers = nameservers; Are you sure the extra freeing is needed? I will modify it a bit so that the freeing is done only if (address) fails.. as the new addresses will come through dhcp/dhcpv6 in that case. Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
RE: [PATCH 3/6] ofono: Old nameservers need to be cleared
I think most of the problem solved by this patch set revolves around the problem that incomplete information is suddenly received from oFono. What is the minimum acceptable configuration from oFono? At least missing 'Address' and perhaps also 'Interface' property should ring alarm bells, is the whole setup faulty in this case? E.g. should most of the patches be fixed by a strategic check of if (index 0 || !address || !...) goto out; If ipv4_method is dhcp there will be no address, and neither there will an address with ipv6 when dual-mode (slaac dhcpv6) is used. So we just can jump into conlusions.. Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
RE: [PATCH 4/6] ofono: Do not set address or nameservers with invalid configuration
With 'invalid configuration' you mean that the 'Address' property was
not found?
Yes, it is invalid in case static-method and with dhcp there will be no address.
- if (context-ipv4_method != CONNMAN_IPCONFIG_METHOD_FIXED)
- goto out;
+ if (address) {
How about writing this as 'if (!address)' goto out; instead? Or can
partial IPv4/IPv6 settings be extracted so that it is ok to only update
for example nameservers? Currently this part of the code frees the
current context address and sets it to NULL at the top of this file.
We still need to clean up the old nameservers in case we go from static to dhcp,
please check v3-patchset: [PATCH 5/6] ofono: Old nameservers need to be
cleared.
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
RE: [PATCH 3/6] ofono: Old nameservers need to be cleared
If ipv4_method is dhcp there will be no address, and neither there will an address with ipv6 when dual-mode (slaac dhcpv6) is used. So we just can jump into conlusions.. So this all is about DHCP then...? and SLAAC.. which does not provide any method to configure the DNS-servers and we can/should not use the old values from any previous configuration/active context. Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
RE: [PATCH 6/6] ofono: make sure valid addresses/methods are used in set_connected
This patch also fixes a potential crash:
#0 connman_network_set_ipaddress (network=0x1aade90, ipaddress=0x0) at
src/network.c:1744
#1 0x000302a4 in set_connected (modem=0x1aa30e0) at plugins/ofono.c:306
#2 0x000321a0 in context_changed (conn=optimized out, message=0x1aae7e0,
user_data=optimized out) at plugins/ofono.c:1294
#3 0x00083ed0 in signal_filter (connection=0x1a71448, message=0x1aae7e0,
user_data=0x1aa5458) at gdbus/watch.c:407
#4 0x00083d24 in message_filter (connection=0x1a71448, message=0x1aae7e0,
user_data=optimized out) at gdbus/watch.c:556
#5 0x4038ff50 in dbus_connection_dispatch (connection=0x1a71448) at
dbus-connection.c:4658
#6 0x00082be4 in message_dispatch (data=0x1a71448) at gdbus/mainloop.c:72
#7 0x4028ba8c in g_idle_dispatch (source=optimized out, callback=0x82bd4
message_dispatch, user_data=optimized out) at gmain.c:5251
#8 0x4028fb20 in g_main_dispatch (context=0x1a70500) at gmain.c:3066
#9 g_main_context_dispatch (context=0x1a70500) at gmain.c:3642
#10 0x4028fe24 in g_main_context_iterate (context=0x1a70500, block=1,
dispatch=1, self=optimized out) at gmain.c:3713
#11 0x4029048c in g_main_loop_run (loop=0x1a6f208) at gmain.c:3906
#12 0x00014b5c in main (argc=563596, argv=0x906b8) at src/main.c:740
Br,
Pasi
From: connman [connman-boun...@connman.net] on behalf of pasi.sjoh...@jolla.com
[pasi.sjoh...@jolla.com]
Sent: Thursday, December 18, 2014 16:02
To: connman@connman.net
Subject: [PATCH 6/6] ofono: make sure valid addresses/methods are used in
set_connected
From: Pasi Sjöholm pasi.sjoh...@jollamobile.com
When connection is set connected, method needs to be set
CONNMAN_IPCONFIG_METHOD_UNKNOWN so that no old configuration
is used in case only ipv4/ipv6-configuration is set.
IPv6 can be also CONNMAN_IPCONFIG_METHOD_AUTO with dual/ipv4v6.
---
plugins/ofono.c | 55 +++
1 file changed, 39 insertions(+), 16 deletions(-)
diff --git a/plugins/ofono.c b/plugins/ofono.c
index 94c6536..5afaa50 100644
--- a/plugins/ofono.c
+++ b/plugins/ofono.c
@@ -266,10 +266,8 @@ static void set_connected(struct modem_data *modem)
index = modem-context-index;
- method = modem-context-ipv4_method;
- if (index 0 || (!modem-context-ipv4_address
- method == CONNMAN_IPCONFIG_METHOD_FIXED)) {
- connman_error(Invalid index and/or address);
+ if (index 0 ) {
+ connman_error(Invalid index);
return;
}
@@ -277,28 +275,48 @@ static void set_connected(struct modem_data *modem)
if (!service)
return;
- if (method == CONNMAN_IPCONFIG_METHOD_FIXED ||
- method == CONNMAN_IPCONFIG_METHOD_DHCP) {
+ method = modem-context-ipv4_method;
+ if (method == CONNMAN_IPCONFIG_METHOD_DHCP) {
connman_service_create_ip4config(service, index);
- connman_network_set_index(modem-network, index);
-
connman_network_set_ipv4_method(modem-network, method);
setip = true;
- }
-
- if (method == CONNMAN_IPCONFIG_METHOD_FIXED) {
- connman_network_set_ipaddress(modem-network,
+ } else if (method == CONNMAN_IPCONFIG_METHOD_FIXED) {
+ if (modem-context-ipv4_address) {
+ connman_service_create_ip4config(service, index);
+ connman_network_set_ipv4_method(modem-network, method);
+ connman_network_set_ipaddress(modem-network,
modem-context-ipv4_address);
+ setip = true;
+ } else {
+ connman_error(Invalid ipv4-address);
+ return;
+ }
+ } else {
+ connman_service_create_ip4config(service, index);
+ connman_network_set_ipv4_method(modem-network,
CONNMAN_IPCONFIG_METHOD_UNKNOWN);
}
method = modem-context-ipv6_method;
- if (method == CONNMAN_IPCONFIG_METHOD_FIXED) {
+ if (method == CONNMAN_IPCONFIG_METHOD_AUTO) {
connman_service_create_ip6config(service, index);
connman_network_set_ipv6_method(modem-network, method);
- connman_network_set_ipaddress(modem-network,
- modem-context-ipv6_address);
+
setip = true;
+ } else if (method == CONNMAN_IPCONFIG_METHOD_FIXED) {
+ if (modem-context-ipv6_address) {
+ connman_service_create_ip6config(service, index);
+ connman_network_set_ipv6_method(modem-network, method);
+ connman_network_set_ipaddress(modem-network,
+ modem-context-ipv6_address);
+ setip = true;
+ } else
RE: [PATCH 2/2] network: index needs to be set also for ip6config
Fixes the issue that network index was not set for ipv6-connections. Which issue do you see if this is not set? SLAAC/DHCPv6 will not work with dual/ipv4v6-pdp when this is not done. Plain ipv6-pdp will work with fixed addresses just fine. Is this a pre-requisite for patch 1/1? If so, send this patch before the ones that need it. Yes, will resend the patches. Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
RE: [PATCH 2/2] network: index needs to be set also for ip6config
On Tue, 2014-12-16 at 11:04 +, Pasi Sjöholm wrote:
SLAAC/DHCPv6 will not work with dual/ipv4v6-pdp when this is not done.
From this I try to decipher that something does not work if IPv4 is
present. What is this something?
Connman does not see service ipv6-configuration (ip-address/nameservers) even
it exists on interface etc.. with patch applied it does.
[ /net/connman/service/cellular_24412269985_context1 ]
Strength = 83
Nameservers = [ 62.241.198.245 62.241.198.246 ]
State = online
Provider = { }
Type = cellular
Security = [ ]
AutoConnect = true
Immutable = false
Proxy = { Method=direct }
Roaming = 0
IPv4.Configuration = { Netmask=255.255.255.0 Gateway=10.233.245.9
Method=fixed Address=10.233.245.8 }
IPv6.Configuration = { Method=auto Privacy=disabled }
Name = dna
Favorite = true
Timeservers = dbus.Array([dbus.String(u'10.233.245.9'),
dbus.String(u'0.pool.ntp.org'), dbus.String(u'1.pool.ntp.org'),
dbus.String(u'2.pool.ntp.org'), dbus.String(u'3.pool.ntp.org')],
signature=dbus.Signature('s'), variant_level=1)
Domains = [ ]
Ethernet = { Interface=rmnet0 MTU=1280 Method=auto
Address=00:00:00:00:00:00 }
Nameservers.Configuration = [ ]
Proxy.Configuration = { }
Domains.Configuration = [ ]
Timeservers.Configuration = dbus.Array([], signature=dbus.Signature('s'),
variant_level=1)
IPv4 = { Netmask=255.255.255.0 Gateway=10.233.245.9 Method=fixed
Address=10.233.245.8 }
IPv6 = { }
rmnet0Link encap:UNSPEC HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.233.245.8 Mask:255.0.0.0
inet6 addr: 2001:14bb:10:3:c38b:89f:3ca1:d79f/64 Scope:Global
inet6 addr: fe80::c38b:89f:3ca1:d79f/64 Scope:Link
inet6 addr: 2001:14bb:10:3:c56c:ed7c:9f8e:e911/64 Scope:Global
UP RUNNING MTU:1280 Metric:1
Did it stop working after patch 1/2 got applied?
No, without 1/2 it does not get even that far as plugins/ofono.c will try to
set the interface as fixed-method.
Br,
Pasi
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
RE: Error reconnecting to a hidden AP.
I think ConnMan's README advises to enable it but it's a mistake. ConnMan's fallback autoscan is better since it handles properly the hidden SSIDs. Could we have a patch to that documentation and not enable it by default if we are? I wouldn't say that ConnMan's autoscan is always better than using autoscan through wpa_s for every device. In real life experiment we did enable the CONFIG_AUTOSCAN_EXPONENTIAL after founding out that it behaves better on our device. So it varies.. Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
RE: [PATCH] gweb: Enable TLSv1.2 and TLSv1.1
Hi Jukka, As the web servers are migrating away from SSLv3 more secure protocols need to be enabled. I just wonder should we just disable sslv3 support all together? I thought about it but was bit afraid there are still systems which only support sslv3 (even it is broken++). On the other hand mozilla and google are dropping sslv3 from their browsers within next 3 months, so I guess it wouldn't hurt so much in the end. I can do v2 of that patch which would remove sslv3-support if you want. Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
RE: [PATCH] ofono: Bring device attached to modem down and up if IMSI has really changed
if (g_str_equal(key, SubscriberIdentity)) {
- sim_update_imsi(modem, value);
+ dbus_message_iter_get_basic(value, new_imsi);
+
+ if (g_strcmp0(modem-imsi,new_imsi) != 0) {
What is the benefit of checking the existing imsi against the new one?
Isn't it known already that the sim is tied to this particular modem, as
the modem is looked using the sending D-Bus path?
+ sim_update_imsi(modem, value);
+
+ if (modem-device)
+ destroy_device(modem);
+ }
Shouldn't this then be run unconditionally?
For some reason (didn't dig it further) the sim_changed is called multiple
times with the SubscriberIdentity as key when hot-swapping the sim card and the
connman already has the new IMSI so we should not destroy the device in that
case to get service identier corrected as it is already correct. It can lead to
connman missing the cellular context if it's done (yes, I tried.. and it seems
to occur when the sim has a pin set but not when it does not).
BTW, the sim_* functions are in need of better checking that the
messages contain the desired properties.
Noticed that also when discussing with Hannu Mallat. :)
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
RE: [PATCH 2/2] dhcpv6: Reset last_request to current time with renew and rebind
It would seem that the last_request is also updated on timed out renew/rebind,
so need to rework this patch.
From: connman [connman-boun...@connman.net] on behalf of pasi.sjoh...@jolla.com
[pasi.sjoh...@jolla.com]
Sent: Thursday, September 11, 2014 01:03
To: connman@connman.net
Subject: [PATCH 2/2] dhcpv6: Reset last_request to current time with renew and
rebind
From: Pasi Sjöholm pasi.sjoh...@jollamobile.com
last_request needs to be set current time also with renew and
rebind or otherwise the values set by
g_dhcpv6_client_get_timeouts will not be changed.
This fixes the issues with __connman_dhcpv6_start_renew and
check_restart comparing incorrect started,expired-values to current
time after successful renew/rebind.
---
src/dhcpv6.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/dhcpv6.c b/src/dhcpv6.c
index 00dba3a..96bfb38 100644
--- a/src/dhcpv6.c
+++ b/src/dhcpv6.c
@@ -1119,6 +1119,7 @@ static void rebind_cb(GDHCPClient *dhcp_client, gpointer
user_data)
{
DBG();
+ g_dhcpv6_client_reset_request(dhcp_client);
g_dhcpv6_client_clear_retransmit(dhcp_client);
re_cb(REQ_REBIND, dhcp_client, user_data);
@@ -1306,6 +1307,7 @@ static void renew_cb(GDHCPClient *dhcp_client, gpointer
user_data)
{
DBG();
+ g_dhcpv6_client_reset_request(dhcp_client);
g_dhcpv6_client_clear_retransmit(dhcp_client);
re_cb(REQ_RENEW, dhcp_client, user_data);
--
1.9.1
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
RE: [PATCH 1/2] dhcpv6: Do not let rebind and renew go crazy due too low T1 and T2
This problem does not actually exist. RFC 3315 says In a message sent by a server to a client, the client MUST use the values in the T1 and T2 fields for the T1 and T2 parameters... unless they are zero. Yes, this patch can be dropped. No need for it really.. Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
RE: [PATCH] dhcpv6: Do solicitation instead of confirm if ipv6.privacy is true
This one is obsole due [PATCH] dhcpv6: Remove CONFIRM message sending when
connecting a link.
Br,
Pasi
From: connman [connman-boun...@connman.net] on behalf of pasi.sjoh...@jolla.com
[pasi.sjoh...@jolla.com]
Sent: Wednesday, September 10, 2014 12:58
To: connman@connman.net
Subject: [PATCH] dhcpv6: Do solicitation instead of confirm if ipv6.privacy is
true
From: Pasi Sjöholm pasi.sjoh...@jollamobile.com
Confirm should not be used with ipv6 temporary addresses (IA_TA) as
dhcp server might ignore it. Eg. isc-dhcp-server does so.
---
src/dhcpv6.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/dhcpv6.c b/src/dhcpv6.c
index dee2d81..e3f6e67 100644
--- a/src/dhcpv6.c
+++ b/src/dhcpv6.c
@@ -1944,6 +1944,7 @@ int __connman_dhcpv6_start(struct connman_network
*network,
last_address = __connman_ipconfig_get_dhcp_address(ipconfig_ipv6);
if (prefixes last_address
+ !__connman_ipconfig_ipv6_privacy_enabled(ipconfig_ipv6)
check_ipv6_addr_prefix(prefixes,
last_address) != 128) {
/*
--
1.9.1
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
RE: [PATCH v2] device: Make sure the device is up and running before enabling it
Hi Tomasz, connmand[2510]: src/device.c:__connman_device_enable() device 0x1cc9d10 connmand[2510]: src/device.c:__connman_device_enable() device 0x1cc9d10, err -19 Can you print also the device index to see it's value? connmand[21072]: src/device.c:__connman_device_enable() device 0x1326e98, err -19, index: 0 So I guess it could be sufficient to check if index != 0? Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
RE: [PATCH v2] device: Make sure the device is up and running before enabling it
Hi,
this patch will break cellular connectivity when coming out of flight mode as
the modem is still powered off and will lead to ENODEV-error (19). Therefore it
should not try to bring cellular-interfaces up or accept ENODEV as valid
response.
--cut--
connmand[2510]: plugins/ofono.c:modem_probe() /ril_0 device 0x1cc9d10
connmand[2510]: src/technology.c:__connman_technology_add_device() device
0x1cc9d10 type Cellular
connmand[2510]: src/technology.c:technology_get() type 5
connmand[2510]: src/technology.c:technology_find() type 5
connmand[2510]: src/technology.c:technology_get() technology (nil) driver
0xacf38
connmand[2510]: src/technology.c:technology_load() technology 0x1cdef58
connmand[2510]: src/storage.c:storage_load() Loading /var/lib/connman/settings
connmand[2510]: src/technology.c:technology_get() technology 0x1cdef58
connmand[2510]: src/device.c:__connman_device_enable() device 0x1cc9d10
connmand[2510]: src/device.c:__connman_device_enable() device 0x1cc9d10, err -19
connmand[2510]: src/storage.c:storage_load() Loading /var/lib/connman/settings
connmand[2510]: plugins/ofono.c:modem_set_online() /ril_0 online 1
connmand[2510]: plugins/ofono.c:set_property() /ril_0 path /ril_0
org.ofono.Modem.Online
connmand[2510]: src/device.c:connman_device_set_powered() driver 0x1cc9d10
powered 0
connmand[2510]: plugins/ofono.c:modem_changed() /ril_0 Interfaces 0x05
connmand[2510]: plugins/ofono.c:modem_update_interfaces() /ril_0
connmand[2510]: plugins/ofono.c:api_added() cm added
connmand[2510]: plugins/ofono.c:get_properties() /ril_0 path /ril_0
org.ofono.ConnectionManager
connmand[2510]: plugins/ofono.c:cm_get_contexts() /ril_0
connmand[2510]: plugins/ofono.c:modem_changed() /ril_0 Serial 359745050002549
connmand[2510]: src/service.c:connman_service_create() service 0x1cdb8d0
connmand[2510]: src/service.c:service_initialize() service 0x1cdb8d0
connmand[2510]: src/service.c:service_load() service
cellular_244919750451136_context1
connmand[2510]: src/storage.c:storage_load() Loading
/var/lib/connman/cellular_244919750451136_context1/settings
connmand[2510]: src/service.c:connman_service_create() service 0x1cdb8d0
connmand[2510]: src/service.c:service_initialize() service 0x1cdb8d0
--cut--
Br,
Pasi
From: connman [connman-boun...@connman.net] on behalf of Tomasz Bursztyka
[tomasz.burszt...@linux.intel.com]
Sent: Thursday, August 07, 2014 12:05
To: connman@connman.net
Subject: [PATCH v2] device: Make sure the device is up and running before
enabling it
It can happen that, after a unproper ConnMan exit, a device is still up.
Once ConnMan is restarted cleanup_devices() will put this device down.
But then, it will never set it up again.
04:08:45 connmand[254]: src/device.c:__connman_device_init()
04:08:45 connmand[254]: src/inet.c:__connman_inet_get_address_netmask() index 2
04:08:45 connmand[254]: src/device.c:cleanup_devices() cleaning up wlan0 index 2
(...)
04:08:45 connmand[254]: wlan0 {newlink} index 2 operstate 2 DOWN
(...)
04:08:45 connmand[254]: plugins/wifi.c:wifi_newlink() index 2 flags 36866
change 0
04:08:45 connmand[254]: src/technology.c:__connman_technology_add_device()
device 0x35e8a8 type WiFi
04:08:45 connmand[254]: src/technology.c:technology_get() type 3
04:08:45 connmand[254]: src/technology.c:technology_find() type 3
04:08:45 connmand[254]: src/device.c:__connman_device_enable() device 0x35e8a8
Reported by Richard Röjfors richard.rojf...@gmail.com
---
src/device.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/device.c b/src/device.c
index a97d790..1a5f0e6 100644
--- a/src/device.c
+++ b/src/device.c
@@ -185,6 +185,10 @@ int __connman_device_enable(struct connman_device *device)
if (device-powered_pending == PENDING_NONE device-powered)
return -EALREADY;
+ err = connman_inet_ifup(device-index);
+ if (err 0 err != -EALREADY)
+ return err;
+
device-powered_pending = PENDING_ENABLE;
err = device-driver-enable(device);
--
1.8.5.5
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
RE: [PATCH] wispr: request browser with status_url if redirect_url is not set
It's not a good idea to expose the status url. It's an internal url used for testing the connection status, the fact it's also related to wispr is only because both process were easier to be implemented together rather than separately. Most of these captive portals do not even care about the URL you are requesting as they will just show some ad with accept/reject-buttons for the EULA. If you accept the EULA you don't even get redirected to the URL requested but a another page which has more ads. ;) Maybe we could change the documentation of RequestBrowser() Agent method so that if the url is null, browser will have to use whatever default url it wants. The null url is set to -string in the __connman_agent_request_browser on agent-connman.c. So it's not really a null anymore when it gets to the browser, and neither it's valid http-url but a request to open -named file. So maybe connman should have start up page which would be requested in case of url being null if status_url is not ok. Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
RE: [PATCH] dnsproxy: Prefer results with domain name while domain_append is true
--- a/src/dnsproxy.c +++ b/src/dnsproxy.c @@ -2068,7 +2068,8 @@ static int forward_dns_reply(unsigned char *reply, int reply_len, int protocol, } out: - if (hdr-rcode 0 req-numresp req-numserv) + if ((hdr-rcode 0 || (hdr-rcode == 0 hdr-ancount == 0 + req-append_domain)) req-numresp req-numserv) return -EINVAL; request_list = g_slist_remove(request_list, req); Looks good, couple of comments I did the modifications requested, both the commit message and the patch itself should look more clear now. Revised patch has subject [PATCH] dnsproxy: Prefer responses with ancount0 if append_domain is true. Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
RE: [PATCH] dnsproxy: Prefer results with domain name while domain_append is true
Hi Jukka, If domain_append is set and forward_dns_reply() processes the response for query without the domain name earlier than the response for one with the domain name set we need to make sure that the response is not sent back to the client if rcode and ancount are zero until the last nameserver response is processed. This use case is not handled properly: - there are multiple DNS servers defined, some of them from ISP, user has also set his own DNS server that responds to some internal data - user queries a host without domain name that is only found in his own network - all the ISP name servers return not found - user's own dns server does not respond for some reason or the dns reply is lost What now happens is that the request timeouts and the user is given an error instead of more proper not found result. My initial analysis on this bug was bit wrong. This patch does not change the current way of connman dnsproxy timeouting if the user's own nameserver reply gets lost or does not respond and other servers will send NXDomain-reply. However my patch resolves an issue when dnsproxy query is a valid domain tld. eg. com, bz, net, org or any other valid tld. Example: User wants to resolve A/-record for bz.domain.tld therefore connman queries first for bz and then for bz.domain.tld and it should prefer bz.domain.tld answer over the bz if domain.tld is set as a search path. However currently on 99% certainty the reply for bz will come earlier than bz.domain.tld and as it is rcode=0 and most probably with ancount=0 (tld's don't usually have A or -record) it will be sent to the client which is not what user probably wanted. My patch makes sure that on those cases the reply will not be sent to the client as it does not provide any valid records. Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
RE: BUG: dnsproxy.c does not strip domain name-part from search-queries correctly and all dns-servers should not queried at the same time.
If I do that, I can see that the current way of stripping the domain name from reply is broken in forward_dns_reply() as it does not really strip out the domain name part: tcpdump (lo): IP (tos 0x0, ttl 64, id 36270, offset 0, flags [DF], proto UDP (17), length 48) 127.0.0.1.33898 127.0.0.1.53: 10971+ A? bz. (20) IP (tos 0x0, ttl 64, id 36271, offset 0, flags [DF], proto UDP (17), length 82) 127.0.0.1.53 127.0.0.1.33898: 10971 1/0/0 bz.siirappi.com. A 1.2.3.4 (54) We could optimize the resolver a bit so that if the DNS server returns not found for a query, we could wait until we get a name found response before returning something to the client. Would you like to investigate this more and send a patch? As stated on the other thread my analysis was bit wrong, however the patch which I sent fixes the problems when hostname queried is a valid domain tld. However the other problem still exists, forward_dns_reply() does not strip the domain name part away from the answer-block (as discussed on IRC) which will lead to fails. Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
RE: BUG: dnsproxy.c does not strip domain name-part from search-queries correctly and all dns-servers should not queried at the same time.
Hi Jukka, However the other problem still exists, forward_dns_reply() does not strip the domain name part away from the answer-block (as discussed on IRC) which will lead to fails. With fa7141ae55aadbe8faacb0cba2b1f864a2f20bf9: IP (tos 0x0, ttl 64, id 45410, offset 0, flags [DF], proto UDP (17), length 51) 127.0.0.1.56035 127.0.0.1.53: [bad udp cksum 0xfe32 - 0x607b!] 63156+ A? warez. (23) IP (tos 0x0, ttl 64, id 45411, offset 0, flags [DF], proto UDP (17), length 85) 127.0.0.1.53 127.0.0.1.56035: [bad udp cksum 0xfe54 - 0xa79d!] 63156 q: A? warez. 1/0/0 warez.siirappi.com. A 127.0.0.1 (57) Reverted fa7141ae55aadbe8faacb0cba2b1f864a2f20bf9: IP (tos 0x0, ttl 64, id 43076, offset 0, flags [DF], proto UDP (17), length 51) 127.0.0.1.41718 127.0.0.1.53: [bad udp cksum 0xfe32 - 0x890e!] 1551+ A? warez. (23) IP (tos 0x0, ttl 64, id 43077, offset 0, flags [DF], proto UDP (17), length 67) 127.0.0.1.53 127.0.0.1.41718: [bad udp cksum 0xfe42 - 0xf11f!] 1551 q: A? warez. 1/0/0 warez. A 127.0.0.1 (39) So I would suggest reverting fa7141ae55aadbe8faacb0cba2b1f864a2f20bf9 or fixing it. Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
BUG: dnsproxy.c does not strip domain name-part from search-queries correctly and all dns-servers should not queried at the same time.
Hi, (ip-addresses and domains have been modified) it seems that the current dnsproxy.c implementation queries all the available dns-servers as soon as possible and only uses the first response as a result, normally this would be ok but when doing search-query for domains it will not work correctly. Let's have service with these settings: Nameservers = [ 193.229.0.40 193.229.0.42 ] Domains = [ siirappi.com ] Query for bz.siirappi.com will success correctly, but when querying for plain bz this happens: On public interface all the nameservers are queried at same time and not by first querying nameservers for interface which has a default route (one by one and requiring timeout to expire before querying next one) and then the other available dns-servers as a backups. tcpdump (public interface): IP 10.1.0.175.44256 193.229.0.42.53: 62449+ A? bz. (20) IP 10.1.0.175.44256 193.229.0.42.53: 60823+ A? bz.siirappi.com. (36) IP 10.1.0.175.40848 193.229.0.40.53: 62449+ A? bz. (20) IP 10.1.0.175.40848 193.229.0.40.53: 60823+ A? bz.siirappi.com. (36) IP 193.229.0.40.53 10.1.0.175.40848: 62449 0/1/0 (85) IP 193.229.0.40.53 10.1.0.175.40848: 60823 1/0/0 A 1.2.3.4 (52) IP 193.229.0.42.53 10.1.0.175.44256: 62449 0/1/0 (85) IP 193.229.0.42.53 10.1.0.175.44256: 60823 1/0/0 A 1.2.3.4 (52) tcpdump (lo): IP 127.0.0.1.60262 127.0.0.1.53: 50453+ A? bz. (20) IP 127.0.0.1.53 127.0.0.1.60262: 50453 0/1/0 (85) connmand log: src/dnsproxy.c:udp_listener_event() Received 20 bytes (id 0x7410) src/dnsproxy.c:parse_request() id 0x7410 qr 0 opcode 0 qdcount 1 arcount 0 src/dnsproxy.c:parse_request() query bz. src/dnsproxy.c:resolv() server 193.229.0.42 enabled 1 src/dnsproxy.c:append_query() query bz. domain siirappi.com src/dnsproxy.c:ns_resolv() req 0x1207780 dstid 0x3940 altid 0xbc28 src/dnsproxy.c:resolv() server 193.229.0.40 enabled 1 src/dnsproxy.c:append_query() query bz. domain siirappi.com src/dnsproxy.c:ns_resolv() req 0x1207780 dstid 0x3940 altid 0xbc28 src/dnsproxy.c:forward_dns_reply() Received 85 bytes (id 0x3940) src/dnsproxy.c:forward_dns_reply() req 0x1207780 dstid 0x3940 altid 0xbc28 rcode 0 src/dnsproxy.c:cache_update() offset 0 hdr 0xbe832ba4 msg 0xbe832ba4 rcode 0 src/dnsproxy.c:parse_response() qr 1 qdcount 1 src/dnsproxy.c:forward_dns_reply() proto 17 sent 85 bytes to 9 src/dnsproxy.c:forward_dns_reply() Received 52 bytes (id 0xbc28) src/dnsproxy.c:forward_dns_reply() Received 85 bytes (id 0x3940) src/dnsproxy.c:forward_dns_reply() Received 52 bytes (id 0xbc28) Only the first reply gets handled and that's the reply for plain bz.-query, rest of the responses get ignored by forward_dns_reply(). Therefore the user will not get value for bz.siirappi.com as expected, or he might get if the UDP-response for it gets back to connman faster thant the reply for bz.-query. The query order can be fixed easily in ns_resolv() by prioritizing the append_domain-query but it still does not guarantee that the reply for it get back first. If I do that, I can see that the current way of stripping the domain name from reply is broken in forward_dns_reply() as it does not really strip out the domain name part: tcpdump (lo): IP (tos 0x0, ttl 64, id 36270, offset 0, flags [DF], proto UDP (17), length 48) 127.0.0.1.33898 127.0.0.1.53: 10971+ A? bz. (20) IP (tos 0x0, ttl 64, id 36271, offset 0, flags [DF], proto UDP (17), length 82) 127.0.0.1.53 127.0.0.1.33898: 10971 1/0/0 bz.siirappi.com. A 1.2.3.4 (54) Only way to fix this: 1. Query the search-domain (bz.siirappi.com.) first and only after the connman will get either NXDomain-reply or the valid record for the query it should continue. (In case of timeout - query next nameserver). 2. With NXDomain it should query the original search (bz.) and with valid record it should return it to the client. OR Remove the domains search-functionality from connman and count on operating system's domains search-functionality (eg. by defining search-patterns to /etc/resolv.conf in linux). Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
RE: [PATCH] wispr: Handle status codes 505 and 000 by the browser
Hi Tomasz, + case 505: + DBG(HTTP version not supported, hand over to the browser); Anyway, though handling this status 505 like you propose is fine, it would be great to know what/where/how made this status to fix gweb then (if there is something to be fixed there). I need to have a decent debug session with that particular hotspot-environment but there is something weird as querying with the curl causes the same response if querying the redirection url directly, but if doing curl -L for the connman status-url (http://ipv4..) it will get to the portal sign in-page by going the full-path within the same session. I will re-send the patch without signed-off and DBG's. Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH] wispr: Handle status codes 505 and 000 by the browser
Sometimes captive portal system might return these status codes
when continuing with g_web_request_get after the initial 302 status
code. Let the browser handle these cases.
000 is seen with http://www.hotspotsystem.com/
505 is seen with http://nextmesh.net/
Special thanks to Lorn Potter.
---
src/wispr.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/wispr.c b/src/wispr.c
index dcce93c..c4fcd60 100644
--- a/src/wispr.c
+++ b/src/wispr.c
@@ -711,6 +711,11 @@ static bool wispr_portal_web_result(GWebResult *result,
gpointer user_data)
DBG(status: %03u, status);
switch (status) {
+ case 000:
+ __connman_agent_request_browser(wp_context-service,
+ wispr_portal_browser_reply_cb,
+ wp_context-status_url, wp_context);
+ break;
case 200:
if (wp_context-wispr_msg.message_type = 0)
break;
@@ -755,6 +760,11 @@ static bool wispr_portal_web_result(GWebResult *result,
gpointer user_data)
}
break;
+ case 505:
+ __connman_agent_request_browser(wp_context-service,
+ wispr_portal_browser_reply_cb,
+ wp_context-status_url, wp_context);
+ break;
default:
break;
}
--
1.9.1
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH] wispr: Handle status codes 505 and 000 by the browser
Sometimes captive portal system might return these status codes
when continuing with g_web_request_get after the initial 302 status
code. Let the browser handle these cases.
000 is seen with http://www.hotspotsystem.com/
505 is seen with http://nextmesh.net/
Special thanks to Lorn Potter.
Signed-off-by: Pasi Sjöholm pasi.sjoh...@jollamobile.com
---
src/wispr.c | 12
1 file changed, 12 insertions(+)
diff --git a/src/wispr.c b/src/wispr.c
index dcce93c..4b60c69 100644
--- a/src/wispr.c
+++ b/src/wispr.c
@@ -711,6 +711,12 @@ static bool wispr_portal_web_result(GWebResult *result,
gpointer user_data)
DBG(status: %03u, status);
switch (status) {
+ case 000:
+ DBG(Status code 000 (proxy?), handling over to the browser);
+ __connman_agent_request_browser(wp_context-service,
+ wispr_portal_browser_reply_cb,
+ wp_context-status_url, wp_context);
+ break;
case 200:
if (wp_context-wispr_msg.message_type = 0)
break;
@@ -755,6 +761,12 @@ static bool wispr_portal_web_result(GWebResult *result,
gpointer user_data)
}
break;
+ case 505:
+ DBG(HTTP version not supported, hand over to the browser);
+ __connman_agent_request_browser(wp_context-service,
+ wispr_portal_browser_reply_cb,
+ wp_context-status_url, wp_context);
+ break;
default:
break;
}
--
1.9.1
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
RE: [PATCH] Change the threshold for background scanning, -45 is actually very good RSSI.
How did you evaluated that -65dbm is better than -45dbm? On scanning events amount? -65 is usually already low signal. (relatively to the noise however) 3 meters away from 5GHz access point and my laptop shows -47dBm, with 2.4GHz ap 5m away -54dBm, I really don't want to scan every 30secs. With quite many Qualcomm based Android devices WCNSS settings have: gNeighborLookupThreshold=76 gNeighborReassocThreshold=81 So having -65dBm instead of -45dBm should be still reasonable. Depends on what you are trying to achieve, a better user experience (better connectivity) or better battery life. I bet such background scans are not that power greedy (it's all passive anyway). Though it would require a proper physical measurement to know about that. It's not really passive as the device is told to scan every 30secs and bg_simple will go through all channels and not just particular ones like bg_learn. When you say scanning will block other operations, this is a bit scary: bg_scan in wpa_supplicant handles concurrent scan requests and others properly. It should not block anything really. Scanning itself blocks all other operations as the wlan-chip will need to go through all available channels and it can't handle data transmit/receive during that time. See: QoS-Aware Channel Scanning for IEEE 802.11 Wireless LAN, http://w3.antd.nist.gov/pubs/1569105587.pdf Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
RE: [PATCH] Change the threshold for background scanning, -45 is actually very good RSSI.
-#define BGSCAN_DEFAULT simple:30:-45:300 +#define BGSCAN_DEFAULT simple:30:-65:300 On which devices has this been tested? Do you know whether the reported threshold is reported equally across these devices? I've several laptops and phones which seem to report the same RSSI levels by running wpa_cli scan wpa_cli scan_result but in the end the wpa_s trusts the data coming from the wlan-driver. To be honest this setting does not affect devices in which the wlan-driver is responsible for roaming as then wpa_s will not do bgscan with those (you will see wpa_s reporting nl80211: Using driver-based roaming then). The main point is that the -45dBm is considered very good RSSI-value and we should not be scanning unnecessarily as scanning will block other operations. Can't say if -65dBm is the _correct_ value but it's better than -45dBm. Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH] Change the threshold for background scanning, -45 is actually very good RSSI.
Background scanning is done too often per default as RSSI -45 for WLAN is actually very good. Changing it to -65 makes it behave better (same value is used by NetworkManager). Signed-off-by: Pasi Sjöholm pasi.sjoh...@jollamobile.com --- plugins/wifi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/plugins/wifi.c b/plugins/wifi.c index ef4dd95..d867584 100644 --- a/plugins/wifi.c +++ b/plugins/wifi.c @@ -61,7 +61,7 @@ #define INACTIVE_TIMEOUT 12 /* in seconds */ #define FAVORITE_MAXIMUM_RETRIES 2 -#define BGSCAN_DEFAULT simple:30:-45:300 +#define BGSCAN_DEFAULT simple:30:-65:300 #define AUTOSCAN_DEFAULT exponential:3:300 #define P2P_FIND_TIMEOUT 30 -- 1.9.1 ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
RE: [PATCH 2/2] Support for online check based on HTTP-status code 204.
Unfortunately there are numerous of ISP's or organizations which want to modify/strip X-ConnMan-Status-header away from the http-responses even the connection is otherwise just fine (eg. no portals). However they do not modify http-status response codes and that's when the 204 comes in handy. With this patch ConnMan-users can use alternative way to check whether their devices are actually online So the ISP is doing dirty tricks with the HTTP reply, I just wonder why they strip away the headers in this case. Well you never know what they do in between, sometimes they even modify user-agent-header. (Yes, I've seen this). Your solution to return 204 sounds quite an ugly hack to me. How can we be sure that the return code is really from your server if we do not have the X-ConnMan-Status in the header? Are you really sure that 204 is never returned by any proxy or other network element? You can't be 100% sure of it but there is no reason why would any proxy or anything else return 204 as it's required by RFC2616 that it can't have any message-body in the response. [1] The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields. It also means that client should not update the current view - no gain to send 204 as a reply. Actually Android-devices are using the same method to detect the captive portal through http://clients3.google.com/generate_204;. [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH 1/2] Support for configurable ipv4/6 status urls.
Ipv4StatusUrl and Ipv6StatusUrl can be defined to main.conf to
use other than ConnMan's default online check server(s).
---
include/setting.h | 3 +++
src/6to4.c| 9 +
src/main.c| 36
src/main.conf | 5 +
src/wispr.c | 9 -
5 files changed, 53 insertions(+), 9 deletions(-)
diff --git a/include/setting.h b/include/setting.h
index a882021..32ccf56 100644
--- a/include/setting.h
+++ b/include/setting.h
@@ -28,6 +28,9 @@
extern C {
#endif
+#define CONF_STATUS_URL_IPV6Ipv6StatusUrl
+#define CONF_STATUS_URL_IPV4Ipv4StatusUrl
+
bool connman_setting_get_bool(const char *key);
char **connman_setting_get_string_list(const char *key);
unsigned int *connman_setting_get_uint_list(const char *key);
diff --git a/src/6to4.c b/src/6to4.c
index 0e3a7a1..0c880e9 100644
--- a/src/6to4.c
+++ b/src/6to4.c
@@ -53,8 +53,6 @@ static unsigned int newlink_watch;
static unsigned int newlink_flags;
static int newlink_timeout_id;
-#define STATUS_URL http://ipv6.connman.net/online/status.html;
-
#ifndef IP_DF
#define IP_DF 0x4000 /* Flag: Don't Fragment */
#endif
@@ -317,8 +315,11 @@ static void tun_newlink(unsigned flags, unsigned change,
void *user_data)
if (getenv(CONNMAN_WEB_DEBUG))
g_web_set_debug(web, web_debug, 6to4);
- web_request_id = g_web_request_get(web, STATUS_URL,
- web_result, NULL, NULL);
+ const char *url = connman_option_get_string(
+ CONF_STATUS_URL_IPV6);
+
+ web_request_id = g_web_request_get(web, url,
+ web_result, NULL, NULL);
newlink_timeout(NULL);
}
diff --git a/src/main.c b/src/main.c
index 4f635de..8b93ece 100644
--- a/src/main.c
+++ b/src/main.c
@@ -73,6 +73,8 @@ static struct {
bool single_tech;
char **tethering_technologies;
bool persistent_tethering_mode;
+ char *ipv6_status_url;
+ char *ipv4_status_url;
} connman_settings = {
.bg_scan = true,
.pref_timeservers = NULL,
@@ -86,6 +88,8 @@ static struct {
.single_tech = false,
.tethering_technologies = NULL,
.persistent_tethering_mode = false,
+ .ipv4_status_url = NULL,
+ .ipv6_status_url = NULL,
};
#define CONF_BG_SCANBackgroundScanning
@@ -100,6 +104,8 @@ static struct {
#define CONF_SINGLE_TECHSingleConnectedTechnology
#define CONF_TETHERING_TECHNOLOGIES TetheringTechnologies
#define CONF_PERSISTENT_TETHERING_MODE PersistentTetheringMode
+#define CONF_STATUS_URL_IPV6Ipv6StatusUrl
+#define CONF_STATUS_URL_IPV4Ipv4StatusUrl
static const char *supported_options[] = {
CONF_BG_SCAN,
@@ -114,6 +120,8 @@ static const char *supported_options[] = {
CONF_SINGLE_TECH,
CONF_TETHERING_TECHNOLOGIES,
CONF_PERSISTENT_TETHERING_MODE,
+ CONF_STATUS_URL_IPV4,
+ CONF_STATUS_URL_IPV6,
NULL
};
@@ -236,6 +244,7 @@ static void parse_config(GKeyFile *config)
char **interfaces;
char **str_list;
char **tethering;
+ char *status_url;
gsize len;
int timeout;
@@ -354,6 +363,27 @@ static void parse_config(GKeyFile *config)
connman_settings.persistent_tethering_mode = boolean;
g_clear_error(error);
+
+status_url = __connman_config_get_string(config, General,
+ CONF_STATUS_URL_IPV4, error);
+if (!error)
+connman_settings.ipv4_status_url = status_url;
+else
+connman_settings.ipv4_status_url =
+ http://ipv4.connman.net/online/status.html;;
+
+g_clear_error(error);
+
+status_url = __connman_config_get_string(config, General,
+ CONF_STATUS_URL_IPV6, error);
+if (!error)
+connman_settings.ipv6_status_url = status_url;
+else
+connman_settings.ipv6_status_url =
+ http://ipv6.connman.net/online/status.html;;
+
+g_clear_error(error);
+
}
static int config_init(const char *file)
@@ -511,6 +541,12 @@ const char *connman_option_get_string(const char *key)
return option_wifi;
}
+ if (g_str_equal(key, CONF_STATUS_URL_IPV4) == TRUE)
+ return connman_settings.ipv4_status_url;
+
+ if (g_str_equal(key, CONF_STATUS_URL_IPV6) == TRUE)
+ return connman_settings.ipv6_status_url;
+
return NULL;
}
diff --git a/src/main.conf b/src/main.conf
index 93c7a50..0247d0f 100644
--- a/src/main.conf
+++ b/src/main.conf
@@ -95,3 +95,8 @@
# re-enabling a technology, and after restarts and reboots.
# Default value is false.
#
[PATCH 0/2] Configurable IPv4/6-status urls support for http-status response code 204 for online checks.
here are the reworked patches which provide configurable IPv4/6-status urls for ConnMan together with support for using http-status response code 204 instead of the default X-ConnMan-Status: online-check. Pasi Sjöholm (2): Support for configurable ipv4/6 status urls. Support for online check based on HTTP-status code 204. include/setting.h | 3 +++ src/6to4.c| 9 + src/main.c| 36 src/main.conf | 6 ++ src/wispr.c | 14 +- 5 files changed, 59 insertions(+), 9 deletions(-) -- 1.8.3.2 ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH 2/2] Support for online check based on HTTP-status code 204.
Unfortunately there are numerous of ISP's or organizations which want to modify/strip X-ConnMan-Status-header away from the http-responses even the connection is otherwise just fine (eg. no portals). However they do not modify http-status response codes and that's when the 204 comes in handy. With this patch ConnMan-users can use alternative way to check whether their devices are actually online --- src/main.conf | 5 +++-- src/wispr.c | 5 + 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/src/main.conf b/src/main.conf index 0247d0f..0c6720e 100644 --- a/src/main.conf +++ b/src/main.conf @@ -96,7 +96,8 @@ # Default value is false. # PersistentTetheringMode = false -# Set the online status url which returns at least X-ConnMan-Status: -# online HTTP-header. +# Set the online status url which either returns at least +# X-ConnMan-Status: online HTTP-header or HTTP-status +# code 204. Ipv4StatusUrl = http://ipv4.connman.net/online/status.html Ipv6StatusUrl = http://ipv6.connman.net/online/status.html diff --git a/src/wispr.c b/src/wispr.c index 4ba2b28..5e8912f 100644 --- a/src/wispr.c +++ b/src/wispr.c @@ -257,6 +257,8 @@ static const char *response_code_to_string(int response_code) return Proxy detection/repeat operation; case 201: return Authentication pending; + case 204: + return Walled garden check; case 255: return Access gateway internal error; } @@ -722,6 +724,9 @@ static bool wispr_portal_web_result(GWebResult *result, gpointer user_data) wp_context-redirect_url, wp_context); break; + case 204: + portal_manage_status(result, wp_context); + return false; case 302: if (!g_web_supports_tls() || !g_web_result_get_header(result, Location, -- 1.8.3.2 ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH] Configurable IPv4/6-status urls support for http-status response code 204 for online checks.
Hi,
here is a patch which provides configurable IPv4/6-status urls for ConnMan
together with support for using http-status response code 204 instead of the
default X-ConnMan-Status: online-check.
Why? Unfortunately there are numerous of ISP's or organizations which want to
modify/strip X-ConnMan-Status-header away from the http-responses even the
connection is otherwise just fine (eg. no portals). However they do not modify
http-status response codes and that's when the 204 comes in handy. With this
patch ConnMan-users can use alternative way to check whether their devices are
actually online.
Until ipv4.connman.net and ipv6.connman.net provides urls which return 204, you
can try this with these two:
http://ipv4.jolla.com/return_204
http://ipv6.jolla.com/return_204
Br,
Pasi Sjöholm
---
diff --git a/include/setting.h b/include/setting.h
index a882021..32ccf56 100644
--- a/include/setting.h
+++ b/include/setting.h
@@ -28,6 +28,9 @@
extern C {
#endif
+#define CONF_STATUS_URL_IPV6Ipv6StatusUrl
+#define CONF_STATUS_URL_IPV4Ipv4StatusUrl
+
bool connman_setting_get_bool(const char *key);
char **connman_setting_get_string_list(const char *key);
unsigned int *connman_setting_get_uint_list(const char *key);
diff --git a/src/6to4.c b/src/6to4.c
index 0e3a7a1..c32cef9 100644
--- a/src/6to4.c
+++ b/src/6to4.c
@@ -53,8 +53,6 @@ static unsigned int newlink_watch;
static unsigned int newlink_flags;
static int newlink_timeout_id;
-#define STATUS_URL http://ipv6.connman.net/online/status.html;
-
#ifndef IP_DF
#define IP_DF 0x4000 /* Flag: Don't Fragment */
#endif
@@ -317,7 +315,9 @@ static void tun_newlink(unsigned flags, unsigned change,
void *user_data)
if (getenv(CONNMAN_WEB_DEBUG))
g_web_set_debug(web, web_debug, 6to4);
- web_request_id = g_web_request_get(web, STATUS_URL,
+ const char *url =
connman_option_get_string(CONF_STATUS_URL_IPV6);
+
+ web_request_id = g_web_request_get(web, url,
web_result, NULL, NULL);
newlink_timeout(NULL);
diff --git a/src/main.c b/src/main.c
index 4f635de..0151d39 100644
--- a/src/main.c
+++ b/src/main.c
@@ -73,6 +73,8 @@ static struct {
bool single_tech;
char **tethering_technologies;
bool persistent_tethering_mode;
+ char *ipv6_status_url;
+ char *ipv4_status_url;
} connman_settings = {
.bg_scan = true,
.pref_timeservers = NULL,
@@ -86,6 +88,8 @@ static struct {
.single_tech = false,
.tethering_technologies = NULL,
.persistent_tethering_mode = false,
+ .ipv4_status_url = NULL,
+ .ipv6_status_url = NULL,
};
#define CONF_BG_SCANBackgroundScanning
@@ -98,8 +102,10 @@ static struct {
#define CONF_BLACKLISTED_INTERFACES NetworkInterfaceBlacklist
#define CONF_ALLOW_HOSTNAME_UPDATES AllowHostnameUpdates
#define CONF_SINGLE_TECHSingleConnectedTechnology
-#define CONF_TETHERING_TECHNOLOGIES TetheringTechnologies
+#define CONF_TETHERING_TECHNOLOGIES TetheringTechnologies
#define CONF_PERSISTENT_TETHERING_MODE PersistentTetheringMode
+#define CONF_STATUS_URL_IPV6Ipv6StatusUrl
+#define CONF_STATUS_URL_IPV4Ipv4StatusUrl
static const char *supported_options[] = {
CONF_BG_SCAN,
@@ -114,6 +120,8 @@ static const char *supported_options[] = {
CONF_SINGLE_TECH,
CONF_TETHERING_TECHNOLOGIES,
CONF_PERSISTENT_TETHERING_MODE,
+ CONF_STATUS_URL_IPV4,
+ CONF_STATUS_URL_IPV6,
NULL
};
@@ -236,6 +244,8 @@ static void parse_config(GKeyFile *config)
char **interfaces;
char **str_list;
char **tethering;
+ char *ipv4url;
+ char *ipv6url;
gsize len;
int timeout;
@@ -354,6 +364,23 @@ static void parse_config(GKeyFile *config)
connman_settings.persistent_tethering_mode = boolean;
g_clear_error(error);
+
+ipv4url = __connman_config_get_string(config, General,
CONF_STATUS_URL_IPV4, error);
+if (!error)
+connman_settings.ipv4_status_url = ipv4url;
+else
+connman_settings.ipv4_status_url =
http://ipv4.connman.net/online/status.html;;
+
+g_clear_error(error);
+
+ipv6url = __connman_config_get_string(config, General,
CONF_STATUS_URL_IPV6, error);
+if (!error)
+connman_settings.ipv6_status_url = ipv6url;
+else
+connman_settings.ipv6_status_url =
http://ipv6.connman.net/online/status.html;;
+
+g_clear_error(error);
+
}
static int config_init(const char *file)
@@ -510,6 +537,11 @@ const char *connman_option_get_string(const char *key)
else
return option_wifi;
}
+ if (g_str_equal(key, CONF_STATUS_URL_IPV4) == TRUE
