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&id=0439194ed0c5a90f61dbef86d9a51307764da2d7),
>> but then was re
On 28.10.2015 11:32, Patrik Flykt wrote:
>> From: Pasi Sjöholm
>>
>> 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 wi
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 thin
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
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->con
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 ke
.2015 11:51, Tomasz Bursztyka wrote:
> Hi Pasi,
>
> Nice catch!
>
> ACK from me.
>
> Tomasz
>
>> From: Pasi Sjöholm
>>
>> It's possible from wpa_s to change the state from completed to
>> scanning without going through disconnecte
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
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
&
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
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
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
tting 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.
>
> Repo
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. Re
Hi,
On 12.02.2015 15:28, Patrik Flykt wrote:
> From: Pasi Sjöholm
>
> 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.
>
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 ||
>> -
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_servic
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 lin
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)
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
DBusMessage message leaks memory if not cleaned when
counter is not found.
---
src/counter.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff
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
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 S
>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
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);
>> } el
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
_
>> IPv6 configuration method is either CONNMAN_IPCONFIG_METHOD_FIXED
>> (ipv6-pdp) or CONNMAN_IPCONFIG_METHOD_AUTO (SLAAC/DHCPv6,
>> dual/ipv4v6-pdp).
>RFC 6459, Section 5.2, "IPv6 Address Configuration" says:
>So only CONNMAN_IPCONFIG_METHOD_AUTO is allowed for IPv6 configuration,
>right?
It wou
>> {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
>> {Connecti
>> 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) Co
>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 = NUL
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 t
>> - context->ipv6_method = CONNMAN_IPCONFIG_METHOD_FIXED;
>> + if (address) {
>For the IPv4 case ipconfig method is set according to the "Method"
>attribute. Why is the same not done for IPv6?
Ofono does not set it in context_settings_append_ipv6() in src/gprs.c. Maybe it
should, but it
On Fri, 2014-12-19 at 10:12 +, Pasi Sjöholm wrote:
>> 3) Connect and query service from connman and you will see 2001::1 and
>> 2001::2 plus slaac&dhcpv6 provided nameservers 2001::3 and 2001::4.
>> With the patch applied, the nameservers at point 3 will be only the
&g
>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 met
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
>> 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
w
>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 wri
>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
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
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_metho
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 (i
>> 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, s
>> 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
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
>> 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 n
Hi Arjuna,
>We are currently investigating an issue with IPv6 getting disabled during a
>sequence when a user switches WIFi networks.
Noticed the same thing yesterday and was about to look into it today. ;)
>The sequence of events from the client perspective is:
>2. The user disconnects from Net
>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
___
renew() renew after 15 secs
--cut--
Br,
Pasi
From: Pasi Sjöholm
Sent: Thursday, September 11, 2014 12:42
To: connman@connman.net
Subject: RE: [PATCH 2/2] dhcpv6: Reset last_request to current time with renew
and rebind
It would seem that the last_request is
To: connman@connman.net
Subject: [PATCH 2/2] dhcpv6: Reset last_request to current time with renew and
rebind
From: Pasi Sjöholm
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
4 12:58
To: connman@connman.net
Subject: [PATCH] dhcpv6: Do solicitation instead of confirm if ipv6.privacy is
true
From: Pasi Sjöholm
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
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 0x13
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_pro
>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
>> --- 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->an
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 (
>> 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)
>> 12
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
>>
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 corr
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.
---
sr
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)
.
Signed-off-by: Pasi Sjöholm
---
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
>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.
W
>> -#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
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
---
plugins/wifi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
>>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
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
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. Wit
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 |
heck 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
68 matches
Mail list logo
