A peer is added only when it gets registered to dbus, and is said to be
removed if only it is already registered to dbus.
---
src/peer.c | 111 +
1 file changed, 111 insertions(+)
diff --git a/src/peer.c b/src/peer.c
index 77a71f2..b949d
This is currently used only in service.c to signal ServicesChanged() but
it will be useful also in peer.c to signal PeersChanged(), thus
factorizing this code.
---
src/connman.h | 4 +++-
src/dbus.c| 19 +++
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/src/co
Just handling properly peer_found and peer_lost callbacks accordingly,
creating or destroying peers. The core logic will know when and what to
signal through Manager API's PeersChanged().
---
plugins/wifi.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/
Handle PeersChanged() signal and GetPeers() method from Manager API
relevantly.
---
Makefile.am | 1 +
client/commands.c | 140 --
client/peers.c| 123 +++
client/peers.h| 39 ++
Hi,
ConnMan itself does not provide any means to solve this, and
afaik there is no plan to do so.
But it can be actually fixed easily from outside, with a script in a
cron-job.
I believe Patrik has made such a script, which removes old networks based
on their timestamps (so it's tweakable).
Hi,
But Ossama has some ideas:
--
Patrik's comment assumes that automatic time updates are enabled in Connman
and/or NTP is configured. I don't believe his comment applies when
automatic updates are*disabled*. In that case, the user will set the time
manuall
New version of the patchset, changes against:
v1:
- Jukka and Patrik comments applied.
- corner case of p2p enabling/disabling fixed
- proper scan stopped given to technology: by type rather than
by device.
Please review,
Tomasz Bursztyka (24):
doc: Add an
This document explains how to access such feature in ConnMan and quickly
how the nasty details are hidden from application point of view and
silently handled by ConnMan itself.
---
doc/wifi-p2p-overview.txt | 54 +++
1 file changed, 54 insertions(+)
cre
In order to differentiate P2P technology and wifi by their types, let's
add a new service type.
This is not very clean since P2P technology is never ever going to
generate any service (as struct connman_service), but there is currently
no other way since technology type is tight to a CONNMAN_SERVI
P2P technology driver registration will create the technology on the
fly, thus will need to use technology_get().
Useless function comments are removed as well.
---
src/technology.c | 158 +--
1 file changed, 72 insertions(+), 86 deletions(-)
d
P2P technology is specific in a way it will not own any device due to
the fact it is a child technology of wifi technology: wifi technology
will own the devices then.
Thus, when registering the P2P technology driver, it actually means: a
wifi device supports P2P, leading to create directly the P2P
If this works for any kind of driver, it will be useful in case of P2P
driver mostly.
---
src/technology.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/technology.c b/src/technology.c
index 76f936a..e2de923 100644
--- a/src/technology.c
+++ b/src/technology.c
@@ -141,6 +141,11 @@ i
By default, support is false but if P2P "Flush()" method gets a
non-erroneous reply: it will be set to true.
This tests at once if:
- wpa_supplicant has been built with p2p support, then Flush() should
exist so no error should come as a reply.
- the device supports p2p, then Flush() should not r
In case of P2P technology - since this one is not tight to any devices -
when enabling/disabling it from DBus, the signal about Powered being
changed will be raised automatically.
---
src/technology.c | 134 +++
1 file changed, 67 insertions(+),
Since P2P is dependent over wifi technology, it will get its technology
registered by this one if only one of the interface supports it.
Following the same logic, once an interface is removed the wifi
technology will check if the P2P technology is still supported by - at
least one of - the other in
It will be up to the wifi plugin to decide when to stop such process.
---
gsupplicant/gsupplicant.h | 6 +++
gsupplicant/supplicant.c | 107 +++---
2 files changed, 106 insertions(+), 7 deletions(-)
diff --git a/gsupplicant/gsupplicant.h b/gsupplicant/gs
Since p2p technology does not own any devices, but wifi does, when wifi
devices delcare a "scan done", it will check relevantly if it's not a
p2p scan which ended.
---
include/device.h | 2 +-
plugins/bluetooth_legacy.c | 6 --
plugins/wifi.c | 25 +++---
P2P is not tight to any devices, thus the need of automatically
triggering the proper enabling/disabling function which will in turn
send the signal about Powered being changed accordingly.
---
src/technology.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/
Once started, wifi plugin will run a timeout to trigger a stop by
itself.
---
plugins/wifi.c | 88 ++
1 file changed, 88 insertions(+)
diff --git a/plugins/wifi.c b/plugins/wifi.c
index cbb2dd8..85e4400 100644
--- a/plugins/wifi.c
+++ b/plug
It's actually about differentiating the technology, which will be
useful when requesting a scan from P2P technology. Since this technology
is the child of wifi technology, it will get a scan triggered through
the same scanning method. It will be up to the wifi plugin to
differentiate what to do acc
Handle PeersChanged() signal and GetPeers() method from Manager API
relevantly.
---
Makefile.am | 1 +
client/commands.c | 115 +-
client/peers.c| 122 ++
client/peers.h| 38 +++
A peer is added only when it gets registered to dbus, and is said to be
removed if only it is already registered to dbus.
---
src/peer.c | 111 +
1 file changed, 111 insertions(+)
diff --git a/src/peer.c b/src/peer.c
index 77a71f2..b949d
Basic peer structure and attributes.
---
Makefile.am| 4 +-
include/dbus.h | 1 +
include/peer.h | 45 +
src/connman.h | 5 ++
src/main.c | 2 +
src/peer.c | 150 +
6 files changed, 205 insertions(+), 2 d
PeersChanged() signal is declared but not implemented thus will
currently never be fired up at this point.
---
src/manager.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/src/manager.c b/src/manager.c
index 803f6ce..b31ab4c 100644
--- a/src/manager.c
+++ b/src/mana
Listen to DeviceFound and DeviceLost. From there it gets the Peer path
and properties, store it into the interface object and call relevant
peer_found/peer_lost callbacks provided by the wifi plugin.
Due to the fact wpa_supplicant might not (it's a bug) send the device
address, the peer identifier
Such helper will be used also in for peer.c
---
src/service.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/src/service.c b/src/service.c
index 2bdfc61..54790a4 100644
--- a/src/service.c
+++ b/src/service.c
@@ -4324,10 +4324,14 @@ static void append_remov
This will be useful for the Manager API GetPeers() method and
PeersChanged() signal.
Note that State and IPv4 are provided, but as disconnected for the
first, and empty for the second.
---
src/connman.h | 2 ++
src/peer.c| 36
2 files changed, 38 insertio
This is currently used only in service.c to signal ServicesChanged() but
it will be useful also in peer.c to signal PeersChanged(), thus
factorizing this code.
---
src/connman.h | 4 +++-
src/dbus.c| 19 +++
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/src/co
Just handling properly peer_found and peer_lost callbacks accordingly,
creating or destroying peers. The core logic will know when and what to
signal through Manager API's PeersChanged().
---
plugins/wifi.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/
With the logic of connmanctl, this requires GetProperties() method to be
supported on Peer API side.
---
client/commands.c | 66 ++-
1 file changed, 56 insertions(+), 10 deletions(-)
diff --git a/client/commands.c b/client/commands.c
index 7881c
GetProperties() is declared as obsolete but might be useful in certain
occasion.
---
doc/peer-api.txt | 12 +++-
src/peer.c | 20
2 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/doc/peer-api.txt b/doc/peer-api.txt
index c54d785..e38066f 100644
---
Hi,
Due to the fact wpa_supplicant might not (it's a bug) send the device
address, the peer identifier will be constructed on its name in this
case.
I have a suggestion that maybe we can get the device address from the
obj_path temporarily.
You know, name is not unique to distinguish the diffe
Hi,
I have an another question, this patch only use a remote device
address as a identifier,
it may doesn't work well when mutli-p2p interface. maybe this question
is too
early this time, but the case about mutli-p2p interface is a reasonable.
so what I mean is that using a combination of lo
Indeed, I did not notice it since patch 12 add proper include, since I
have reworked the full patchset and not one by one.
Have to fix patch 7 (other issue)
Tomasz
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo
Hi,
There
was some initial work on Advanced Channel Selection in wpa_supplicant,
s/Advanced/Automatic
Currently, only hostapd supports it. I did a q&d patch to support it
into wpa_supplicant as well
however ACS feature has an asynchronous logic, which does not fit into
wpa_s's AP logic curr
P2P is not tight to any devices, thus the need of automatically
triggering the proper enabling/disabling function which will in turn
send the signal about Powered being changed accordingly.
---
src/technology.c | 32
1 file changed, 32 insertions(+)
diff --git a/s
.
- corner case of p2p enabling/disabling fixed
- proper scan stopped given to technology: by type rather than
by device.
Please review,
Tomasz Bursztyka (24):
doc: Add an overview documentation about WiFi P2P in ConnMan
src: Add a new service type for P2P but only
P2P technology driver registration will create the technology on the
fly, thus will need to use technology_get().
Useless function comments are removed as well.
---
src/technology.c | 158 +--
1 file changed, 72 insertions(+), 86 deletions(-)
d
If this works for any kind of driver, it will be useful in case of P2P
driver mostly.
---
src/technology.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/technology.c b/src/technology.c
index 76f936a..e2de923 100644
--- a/src/technology.c
+++ b/src/technology.c
@@ -141,6 +141,11 @@ i
Since p2p technology does not own any devices, but wifi does, when wifi
devices delcare a "scan done", it will check relevantly if it's not a
p2p scan which ended.
---
include/device.h | 3 ++-
plugins/bluetooth_legacy.c | 6 --
plugins/wifi.c | 25 +++--
In case of P2P technology - since this one is not tight to any devices -
when enabling/disabling it from DBus, the signal about Powered being
changed will be raised automatically.
---
src/technology.c | 134 +++
1 file changed, 67 insertions(+),
Since P2P is dependent over wifi technology, it will get its technology
registered by this one if only one of the interface supports it.
Following the same logic, once an interface is removed the wifi
technology will check if the P2P technology is still supported by - at
least one of - the other in
P2P technology is specific in a way it will not own any device due to
the fact it is a child technology of wifi technology: wifi technology
will own the devices then.
Thus, when registering the P2P technology driver, it actually means: a
wifi device supports P2P, leading to create directly the P2P
This document explains how to access such feature in ConnMan and quickly
how the nasty details are hidden from application point of view and
silently handled by ConnMan itself.
---
doc/wifi-p2p-overview.txt | 54 +++
1 file changed, 54 insertions(+)
cre
By default, support is false but if P2P "Flush()" method gets a
non-erroneous reply: it will be set to true.
This tests at once if:
- wpa_supplicant has been built with p2p support, then Flush() should
exist so no error should come as a reply.
- the device supports p2p, then Flush() should not r
In order to differentiate P2P technology and wifi by their types, let's
add a new service type.
This is not very clean since P2P technology is never ever going to
generate any service (as struct connman_service), but there is currently
no other way since technology type is tight to a CONNMAN_SERVI
Basic peer structure and attributes.
---
Makefile.am| 4 +-
include/dbus.h | 1 +
include/peer.h | 45 +
src/connman.h | 5 ++
src/main.c | 2 +
src/peer.c | 150 +
6 files changed, 205 insertions(+), 2 d
It's actually about differentiating the technology, which will be
useful when requesting a scan from P2P technology. Since this technology
is the child of wifi technology, it will get a scan triggered through
the same scanning method. It will be up to the wifi plugin to
differentiate what to do acc
It will be up to the wifi plugin to decide when to stop such process.
---
gsupplicant/gsupplicant.h | 6 +++
gsupplicant/supplicant.c | 107 +++---
2 files changed, 106 insertions(+), 7 deletions(-)
diff --git a/gsupplicant/gsupplicant.h b/gsupplicant/gs
This is currently used only in service.c to signal ServicesChanged() but
it will be useful also in peer.c to signal PeersChanged(), thus
factorizing this code.
---
src/connman.h | 4 +++-
src/dbus.c| 19 +++
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/src/co
Listen to DeviceFound and DeviceLost. From there it gets the Peer path
and properties, store it into the interface object and call relevant
peer_found/peer_lost callbacks provided by the wifi plugin.
Due to the fact wpa_supplicant might not (it's a bug) send the device
address, the peer identifier
This will be useful for the Manager API GetPeers() method and
PeersChanged() signal.
Note that State and IPv4 are provided, but as disconnected for the
first, and empty for the second.
---
src/connman.h | 2 ++
src/peer.c| 36
2 files changed, 38 insertio
Such helper will be used also in for peer.c
---
src/service.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/src/service.c b/src/service.c
index 2bdfc61..54790a4 100644
--- a/src/service.c
+++ b/src/service.c
@@ -4324,10 +4324,14 @@ static void append_remov
Once started, wifi plugin will run a timeout to trigger a stop by
itself.
---
plugins/wifi.c | 88 ++
1 file changed, 88 insertions(+)
diff --git a/plugins/wifi.c b/plugins/wifi.c
index cbb2dd8..85e4400 100644
--- a/plugins/wifi.c
+++ b/plug
A peer is added only when it gets registered to dbus, and is said to be
removed if only it is already registered to dbus.
---
src/peer.c | 111 +
1 file changed, 111 insertions(+)
diff --git a/src/peer.c b/src/peer.c
index 77a71f2..b949d
PeersChanged() signal is declared but not implemented thus will
currently never be fired up at this point.
---
src/manager.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/src/manager.c b/src/manager.c
index 803f6ce..b31ab4c 100644
--- a/src/manager.c
+++ b/src/mana
With the logic of connmanctl, this requires GetProperties() method to be
supported on Peer API side.
---
client/commands.c | 66 ++-
1 file changed, 56 insertions(+), 10 deletions(-)
diff --git a/client/commands.c b/client/commands.c
index 7881c
Just handling properly peer_found and peer_lost callbacks accordingly,
creating or destroying peers. The core logic will know when and what to
signal through Manager API's PeersChanged().
---
plugins/wifi.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/
Handle PeersChanged() signal and GetPeers() method from Manager API
relevantly.
---
Makefile.am | 1 +
client/commands.c | 115 +-
client/peers.c| 122 ++
client/peers.h| 38 +++
GetProperties() is declared as obsolete but might be useful in certain
occasion.
---
doc/peer-api.txt | 12 +++-
src/peer.c | 20
2 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/doc/peer-api.txt b/doc/peer-api.txt
index c54d785..e38066f 100644
---
This document explains how to access such feature in ConnMan and quickly
how the nasty details are hidden from application point of view and
silently handled by ConnMan itself.
---
doc/wifi-p2p-overview.txt | 54 +++
1 file changed, 54 insertions(+)
cre
Hi Cliff,
Got to see you logs and something is weird: there is no messages coming
from plugins/wifi.c
You did not filtered out the logs, did you?
Would be interesting to see gsupplicant's output as well.
Could you retest and get the log this way:
CONNMAN_SUPPLICANT_DEBUG=1 connmand -n -d &> c
Identify which part does not support P2P: wpa_supplicant or the
interface itself.
---
gsupplicant/supplicant.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index 39ff2f1..da33aed 100644
--- a/gsupplicant/supplicant.
Identify which part does not support P2P: wpa_supplicant or the
interface itself.
---
gsupplicant/supplicant.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index cd35012..9734e48 100644
--- a/gsupplicant/supplican
Hi Cliff,
>Got to see you logs and something is weird: there is no messages coming
>from plugins/wifi.c
>You did not filtered out the logs, did you?
No, not at all, but what is strange is that I have no plugins dir and hence no
wifi.c!
Maybe you built all as builtin. But in your case I don't
Hi Eduardo,
+ struct connman_technology *technology;
Useless var, see below.
for (list = driver_list; list; list = list->next) {
if (list->data == driver)
@@ -1254,8 +1255,11 @@ int connman_technology_driver_register(struct
connman_technology_driver *driver)
P2P technology exists if only wifi technology exists and does not own
any devices. Thus it's unnecessary to refcount it more than once.
Reported by Eduardo Abinader
---
src/technology.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/technology.c b/src/technology.c
inde
Hi Cliff,
>Do you have a wifi technology appearing in connmanctl ? (technologies
>command)
Yes, 'connmanctl technologies' gives:
/net/connman/technology/wifi
Name = WiFi
Type = wifi
Powered = True
Connected = False
Tethering = False
ConnMan should not show up wifi technology
Ok then it's really weird: ConnMan should not show up the wifi
technology in this case.
Let's revisit this from scratch:
- give me your hardware specification of the wifi card
- what kernel version?
- get the latest version of ConnMan from git (1.23), built it with
bootstrap-configure (adapt
Hi,
I'm sending four attachments to your email to avoid mailing to the list. But I
think I have the reason why I had no wifi; Connman is soft blocking
the card when it starts.
If I unblock using rfkill, I can scan and connect! Log 1 is with card blocked,
Log 2 after I unblock.
So how is thi
Hi Cliff,
But if I run 'wpa_supplicant -Dnl80211 -iwlan0 -c/etc/wpa_supplicant.conf' and
then 'connmand -n -d' from the connman source, I get the familiar
'Error /net/connman/technology/wifi: Not supported'
Again there is no soft blocking anymore - why I don't know.
Never run wpa_supplicant
Hi Cliff,
No, but if I start supplicant manually, then I can connect, otherwise I get the
error.
For some reason connman is not requesting supplicant. Still starting connman
from source dir.
ConnMan does not request supplicant, it requests its dbus interface.
And if wpa_supplicant is proper
Hi Michael,
Sorry for the late answer
Can you point me to your patch in wpa_supplicant?
Here: http://lists.shmoo.com/pipermail/hostap/2013-September/028460.html
But it probably does not apply anymore.
And there had been a lot more patches around ACS recently, and one disabling
the interface
Hi Cliff,
Okay, so let's get this right. Supplicant is started by D-bus when Connman
contacts D-bus? So there is no need for start up files
for supplicant or any of that? Is there anyway Connman could be at fault here
by not contacting D-bus properly?
No it works properly.
There is surely
Hi,
so what can I do if client device want to connect the AP using WPS
>method(both PBC and PIN)?
WPS is not supported on the tethering interface. It requires some amount
of planning and work to implement.
wpa_supplicant's AP mode exposes the necessary parameters to set this up.
It would requ
Hi Cliff,
As you're aware one can install four .service files with supplicant.
/lib/systemd/system/wpa_supplicant.service has to be enabled if D-Bus interface
was built into wpa_supplicant, so that wpa_supplicant D-Bus interface can be
started at boot instead of being automatically activated
Hi Pasi,
Could you resend the patch, through git send-email, so it's under the
proper format?
With a proper commit message and so on.
My comments below. Mostly code style issues but also one fix that should
be in another patch:
---
diff --git a/include/setting.h b/include/setting.h
index a
Hi Eduardo,
Network unreference is already being done by free_network,
called by g_hash_table_remove. This patche prevents from
an invalid read during nework removal.
I would be curious to see your valgrind output.
The reference ethernet.c is removing is the one which is set when the
network
Hi Eduardo,
As you mentioned, the network reference device is freeing is the the one it
creates, in this case, it is created in eth_newlink. I could not see any
network referenced by eth which is not via device, so that's the reason I
patched by removing network_unref and letting device manage i
Thanks,
Now it's possible to pin point which part is bogus:
- connman_network_create() network 0x749d890
- connman_network_ref_debug() 0x749d890 name Wired ref 2 by
src/device.c:858:connman_device_add_network()
- connman_network_ref_debug() 0x749d890 name Wired ref 3 by
src/service.c:6670:upda
Fixes this issue:
connmand[3288]: src/ntp.c:__connman_ntp_stop()
(connmand:3288): GLib-CRITICAL **: Source ID 144 was not found when
attempting to remove it
---
src/ntp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/ntp.c b/src/ntp.c
index c3bef65..e72bc1a 100644
---
Fixes this issue:
connmand[3288]: src/ntp.c:__connman_ntp_stop()
(connmand:3288): GLib-CRITICAL **: Source ID 144 was not found when
attempting to remove it
---
src/ntp.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/ntp.c b/src/ntp.c
index c3bef65..b4fe63a 10064
Reported by Daniel Wagner
---
plugins/wifi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/plugins/wifi.c b/plugins/wifi.c
index e169692..2dd5dc4 100644
--- a/plugins/wifi.c
+++ b/plugins/wifi.c
@@ -2025,8 +2025,8 @@ static void p2p_support(GSupplicantInterface *interfac
Reported by Daniel Wagner
---
gsupplicant/supplicant.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index 2be773e..b8c89ad 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -2427,10 +2427,12 @@ sta
Thanks to Daniel Wagner and his Coverity report, here are 3 fixes on P2P support
Tomasz Bursztyka (3):
gsupplicant: Fix an emptyness test on an array
technology: Fix a false positive null dereference
wifi: Check the returned code when registering the P2P technology
driver
gsupplicant
P2P technology cannot exist without wifi technology, so if P2P is
present, wifi is present as well. Thus what coverity thinks is a null
dereference is a false positive here.
Reported by Daniel Wagner
---
src/technology.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/tec
- Provide a device name for the local p2p device
- join or negociate for a group according to distant peer
- GroupFinished signal handler added by
Eduardo Abinader
---
test/p2p-on-supplicant | 175 +++--
1 file changed, 156 insertions(+), 19 deletion
Hi Eduardo,
Minor issue:
@@ -100,37 +105,33 @@ class Wpa_s:
bus.add_signal_receiver(self.__InterfaceRemoved, path=WPA_PATH,
signal_name='InterfaceRemoved')
self.__reset()
+
+self.debug = False
unnecessary since it's done below alre
Reported by Daniel Wagner
---
gsupplicant/supplicant.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index 8a16663..b483f9b 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -2411,10 +2411,12 @@ sta
My first version of the patchset was made on top of up-coming patches...
Tomasz Bursztyka (3):
gsupplicant: Fix an emptyness test on an array
technology: Fix a false positive null dereference
wifi: Check the returned code when registering the P2P technology
driver
gsupplicant
Reported by Daniel Wagner
---
plugins/wifi.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/plugins/wifi.c b/plugins/wifi.c
index 7c412ef..988ca1a 100644
--- a/plugins/wifi.c
+++ b/plugins/wifi.c
@@ -1885,8 +1885,11 @@ static void p2p_support(GSupplicantInterface *inte
P2P technology cannot exist without wifi technology, so if P2P is
present, wifi is present as well. Thus what coverity thinks is a null
dereference is a false positive here.
Reported by Daniel Wagner
---
src/technology.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/tec
Hi Julien,
Often they think they remove all the favorite networks in the UI list,
and they don't understand that some networks are still stored.
What do they want to do? Selectively removing some known networks, or
removing all known ones?
If it's the later, a small script could just do that
Hi Marcel,
I narrowed the problem down to this.
In function handle_multi_line (gweb.c:809) a call is made to g_hash_table_lookup
but session->result.last_key is NULL.
(gdb) print session->result.last_key
$1 = (gchar *) 0x0
Is there anything I can do to help you guys further?
Interesting. It
At this position, no key might have been provided yet.
Reported by Marcel Mulder
---
Hi Marcel,
Does that helps?
Btw the logs you provided are missing the gweb parts.
Could you run connman like: CONNMAN_WEB_DEBUG=1 connmnand
Thanks,
gweb/gweb.c | 3 +++
1 file changed, 3 insertions(+)
dif
Hi Marcel,
connmand[30944]: WEB: gweb/gweb.c:received_data() web 0xd5ae0 [header]
connmand[30944]: WEB: gweb/gweb.c:received_data() web 0xd5ae0 [header]
connmand[30944]: WEB: gweb/gweb.c:received_data() web 0xd5ae0 [header]
connmand[30944]: WEB: gweb/gweb.c:received_data() web 0xd5ae0 [header
Hi Marcel,
Your patch works but that basically skips all multi line headers, so I think
you have some coding to do;-) If you want to support multi line headers of
course.
Sure, the patch was just to verify the crash origin.
There is indeed a bit of work to get it right now.
Thanks for repo
Hi Pasi,
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)
Depends on what you are trying to achieve, a better user experience (better
connectivity) or better battery life.
I bet such backgro
Hi Pasi,
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 the chip, antenna, driver... It's really particular to all hw.
Myself at 3m, I have
Hi,
Have you built connman with dnsproxy support?
Tomasz
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
401 - 500 of 1218 matches
Mail list logo
