Re: Regd. using two WPA Supplicant in ConnMan
Hi, As long as you don't explain exactly the use case (the frequencies, the modes...), I won't be convinced you really need 2 wpa_supplicant. Usually, this is because people use it from command line and that is quite painful to make it work for multiple cards yes. (ConnMan uses it's DBus interface, which works pretty differently than the unix socket interface etc... it's more flexible) Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Regd. using two WPA Supplicant in ConnMan
That's quite a dirty hack actually. And you still did not tell what is the use case, what's the context etc... Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Regd. using two WPA Supplicant in ConnMan
Hi, For one of our project we have to use two WPA Supplicants for some specific use cases, now I would like to know what would be the better approach, using single ConnMan with two Supplicant or two Connman with two Supplicant? What I have understood by going through the Connman source code that using two Supplicants with single ConnMan will need modification of ConnMan design as currently it is very specific to one Wi-Fi interface. Do you foresee any such changes in ConnMan in near future? Also will you accept this kind of change in ConnMan if we implement this? ConnMan has always been able to handle multiple wifi interface at the same time, through one wpa_supplicant. What kind of use-case are you thinking about? Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Regd. using two WPA Supplicant in ConnMan
Hi, Just now got the go ahead about disclosing the use cases. Our requirement is having two P2P GO, one at 2.4 Ghz and another 5 Ghz in parallel, and our chip vendor confirmed that will only be possible by using two Supplicants. This should work with one wpa_supplicant, unless the chip vendor's driver is weirdly done. Afaik, intel or atheros work properly, but if it's none of those... ;) In ConnMan side that's another story, you would need to tweak still quite some stuff to enable that. In any case, having ConnMan in the picture brings some work: if you have 2 wpa_s, you will need to change some stuff to make it work (and it's ugly as hell), if you have 2 wpa_s and 2 connman... same thing (and it's ugly too). The very best solution would be one wpa_s and one connman, as usual. In connman repository, there is a qd test script for wpa_supplicant dbus interface, for P2P named p2p-on-supplicant Try playing with it, creating more than 1 GO. Then you will know what's needed (well, mostly) to do in ConnMan. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Regd. using two WPA Supplicant in ConnMan
Hi Marcel, There should be no need to modify ConnMan in this case. Besides the ugly hack they have been told to investigate, I don't think ConnMan supports being 2 GO at same time on the same phy, not to say about being on 2.4 on one, and 5 on the other. A the time things were implemented, the hw barely worked on 1:1 context... It would be just a missing feature in ConnMan. Thus my advice to verify wpa_supplicant's behavior through the test script about creating 2 GO on same PHY. If it does not work, it will be definitely a bug in wpa_s (since it's supposed to support it...) If it works, it will give hints on what to improve in ConnMan and how. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH v2 0/6] Strip whitespace and empty strings from DBus input
Hi Jaakko, Ack from me too. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: connecting to an open wifi network with wps push button
Hi James, I don't think it's exactly the same thing, please correct me if I am wrong. The WPS PBC can be initiated by either the AP or the device. It does not need to be started on the AP side. If you cannot initiate the button press without first selecting a service to connect to, there is no way to start the WPS sequence from device side because you have already chosen which AP you want to connect to. You must be able to have the device advertising the WPS PBC before you select the AP to connect to. That way the AP can see the advertisements. wpa_supplicant / wpa_cli allow the button to be pressed before choosing the network to connect to. We support AP to client. Not the other way. We want to ensure the user connects to the service he really wants. So he first has to press the button on the AP and only then to select the proper service on his side. Misused, WPS can let the user being connected to the wrong network. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: connecting to an open wifi network with wps push button
Hi James, Thanks for the clarification. It sounds like there is no way to pass WFA WPS certification with the current connman code base, since this behavior makes it impossible to connect to an open network via WPS. Honestly, it doesn't make a lot of sense to use WPS on an open network if you can display a list of networks for the user to choose from. It makes a lot of sense for a headless unit, where the only way to connect is by WPS push button. Indeed, but that's a certification: it's not meant to make sense :) Do you have recommendations for how to modify connman to support a scenario where the button can be pushed before selecting a network to connect to? And a level of effort required? There would be 2 ways: 1) if you have a physical wps pbc button on your device, this can be tight to wpa_supplicant (how? I don't know. Could be an event directly handled form the wifi chip, or a gpio event?). Anyway, the remaining work would be to make connman following wpa_supplicant's decision on the following connection once WPS ran successfully. Afaik, wpa_supplicant's DBus API should tell that wps is running. Once it connects, I believe it also tells about it. So you would need to verify first such behavior and see if ConnMan follows (run connman lime: CONNMAN_SUPPLICANT_DEBUG=1 connmand -nd for the proper logs) If it just works, then fine. If not, it would probably require some work on plugins/wifi.c probably not much. A 1 man week of work at most? 2) You add an function to ConnMan's DBus API to run such WPS PBC. So this would create a pure software button. However, since it again does not get along with the usual connecton procedure you would have a bit more work than 1) here as you would need to call wpa_supplicant's wps process to start (so you probably need to make the right interface function in gsupplicant's part) and then again to handle the results properly as in 1). However, form design point of view, you'll have a hard time to make it clean, since ConnMan's DBus API has its logic: I guess the easiest way is to add such feature through technology.c, on wifi only. In any case, 1) is by far the best option here. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH 1/5] service: Add function to remove empty strings
Hi Jaakko,
Make the whole change it one loop. No need to check if there is, empty
strings, at first.
It's greedy and, if there 1+ empty lines, you will anyway loop all over
again.
Tomasz
This helper function takes in a heap-allocated buffer of heap-allocated
strings. If no strings should be removed, return the buffer. Else, free
all empty strings, place nonempty strings to a new container and return
it, freeing the old container.
---
src/service.c | 32
1 file changed, 32 insertions(+)
diff --git a/src/service.c b/src/service.c
index 2d8245e..1723586 100644
--- a/src/service.c
+++ b/src/service.c
@@ -2926,6 +2926,38 @@ static DBusMessage *get_properties(DBusConnection *conn,
return reply;
}
+static char **remove_empty_strings(char **strv)
+{
+ int amount, length, index;
+ char **iter, **out;
+
+ amount = 0;
+ length = g_strv_length(strv);
+ iter = strv;
+
+ while (*iter)
+ if (strlen(*iter++))
+ amount++;
+
+ if (amount == length - 1)
+ return strv;
+
+ out = g_new0(char *, amount+1);
+ index = 0;
+ iter = strv;
+
+ while (*iter) {
+ if (strlen(*iter))
+ out[index++] = *iter;
+ else
+ g_free(*iter);
+ iter++;
+ }
+
+ g_free(strv);
+ return out;
+}
+
static int update_proxy_configuration(struct connman_service *service,
DBusMessageIter *array)
{
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: connecting to an open wifi network with wps push button
Hi, Is there any way to accomplish using connman? I don't see a way to send a WPS push button without first connecting to a service and having the user agent request the WPS pin or push button. That's the software WPS push button you want. There is no other way. When the user physically press a real button: it means he wants to connect. So here, that's exactly the same thing: he needs first to request a connection and then connman (since it detects the service as WPS ready) asks you about which method you want to use. Note that WPS is usually badly implemented in AP side. So depending on those, you may see connman no requesting you the method through the agent if the AP does its job well, i.e.: advertizing properly it's running a WPS PBC sequence. (thus connman detects it, and then do not ask the user about the method and uses PBC automatically) Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: RFC: D-Bus access to all configured services
Hi Slava, All D-Bus calls (except for Connect obviously) would work for unavailable service just as they do for available services. The main use case is wifi. The user has to be able to see the list of configured wifi networks, edit their properties, remove them etc. For other types of services it probably doesn't make sense but who knows. Isn't it the same behavior as Jolla's phone has? I still don't get the usefulness of that feature. Why annoying the user with service he cannot connect to, at a time T? (why would he feel the need to tweak the parameters if the network is not even present?!) Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: RFC: D-Bus access to all configured services
Hi Slava, All D-Bus calls (except for Connect obviously) would work for unavailable service just as they do for available services. The main use case is wifi. The user has to be able to see the list of configured wifi networks, edit their properties, remove them etc. For other types of services it probably doesn't make sense but who knows. Isn't it the same behavior as Jolla's phone has? Not quite. The user gets to see the list of saved networks but their properties are not editable (and not even available in the current UI but that's purely a UI issue). That's why I asked this question. Ok, could make a bit of sense if the user wants to do some manual cleanups. Though I guess most of users just don't care probably. I still don't get the usefulness of that feature. Why annoying the user with service he cannot connect to, at a time T? (why would he feel the need to tweak the parameters if the network is not even present?!) Two scenarios off the top of my head: 1. To see the password (if you have forgotten it) or proxy configuration (to copy/paste it into the new configuration) 2. To set Favourite to false so that it doesn't get automatically connected when it becomes available And generally, if these properties are there and changing them doesn't break anything, why not to provide access to them, especially if there's mechanism already in place for it. More code to maintain. It's already hard to provide clean and concise API, so providing more functions, opens even more problems: people tend to use the API wrongly :) The more you expose, the more they will mess with. connman is a piece of middleware, its job is to provide the functionality and leave it to UI designers to decide what to show, what not to show and how to present it to the user. That's a debate on its own. Actually, I don't think UI designers should be the only responsible for what to expose on the UI. It then creates a top-to-bottom dependency, without a proper understanding of the lower layers, which tend to generate more problem with time (from maintaining the API to properly architecture the service etc...). Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: connman online test
Hi Jussi, 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 Why would you prevent it to happen? This check is something extra anyway, being ready means you are connected. In a way, people should not care too much not seeing there service being set to online, since such check can't be bullet-proof. b) it's not possible to set the checked URL in the configuration Passi from Jolla already sent a patch last year: https://lists.connman.net/pipermail/connman/2014-April/017033.html Cheers, Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] service: Reset state to idle when disassociating service from the network.
Hi Slava, It only does the job for the networks that have been connected: if (network-connected) set_disconnected(network); Why not adding there a test on network-associating/network-connecting as well? Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] agent-connman: read SSID as byte array
Hi Adam,
Eh eh, indeed! Looks like nobody ever tried this code.
I guess people are fine with Name and never use the SSID alternative.
So your patch looks good, just remove the Signed-off-by, we don't apply
this rule in connman's tree.
Tomasz
Read Agent provided SSID as an array of bytes and recurse where needed
Signed-off-by: Adam Moore adam.mo...@savantsystems.com
---
src/agent-connman.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/agent-connman.c b/src/agent-connman.c
index 8440451..1b6f8a3 100644
--- a/src/agent-connman.c
+++ b/src/agent-connman.c
@@ -141,17 +141,20 @@ static void request_input_passphrase_reply(DBusMessage
*reply, void *user_data)
name_len = strlen(name);
} else if (g_str_equal(key, SSID)) {
dbus_message_iter_next(entry);
+ DBusMessageIter *array_iter = NULL;
if (dbus_message_iter_get_arg_type(entry)
!= DBUS_TYPE_VARIANT)
break;
dbus_message_iter_recurse(entry, value);
if (dbus_message_iter_get_arg_type(value)
- != DBUS_TYPE_VARIANT)
+ != DBUS_TYPE_ARRAY)
break;
- if (dbus_message_iter_get_element_type(value)
- != DBUS_TYPE_VARIANT)
+
+ dbus_message_iter_recurse(value, array_iter);
+ if (dbus_message_iter_get_arg_type(array_iter)
+ != DBUS_TYPE_BYTE)
break;
- dbus_message_iter_get_fixed_array(value, name,
+ dbus_message_iter_get_fixed_array(array_iter, name,
name_len);
}
dbus_message_iter_next(dict);
--
1.9.1
Statement of Confidentiality
The contents of this e-mail message and any attachments are confidential and
are intended solely for the addressee. The information may also be legally
privileged. This transmission is sent in trust, and the sole purpose of
delivery to the intended recipient. If you have received this transmission in
error, any use, reproduction or dissemination of this transmission is strictly
prohibited. If you are not the intended recipient, please immediately notify
the sender by reply e-mail or at 508.683.2500 and delete this message and its
attachments, if any.
___
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 4/4] wifi: Remove unused pending_network
Hi Patrik,
stop_autoscan(device);
if (wifi-p2p_find_timeout) {
@@ -2066,7 +2062,6 @@ static int network_connect(struct connman_network
*network)
ssid_init(ssid, network);
if (wifi-disconnecting) {
- wifi-pending_network = network;
From here
g_free(ssid);
} else {
wifi-network = connman_network_ref(network);
@@ -2099,11 +2094,6 @@ static void disconnect_callback(int result,
GSupplicantInterface *interface,
wifi-disconnecting = false;
- if (wifi-pending_network) {
- network_connect(wifi-pending_network);
- wifi-pending_network = NULL;
and there
This looks like there was a logic about it.
(Not sure this would be hit anyway though)
Tomasz
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: Disable Firewall support in connman
Hi, Could you please let us know how we can disable firewall support in connman. There is no firewall in ConnMan. ConnMan might use iptables to setup nating (when tethering) and some other accounting stuff. But besides that, it does not use iptables for firewalling. What is the issue you are facing? Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] gsupplicant: Remove unused net_mapping hash table
Hi,
static void interface_network_removed(DBusMessageIter *iter, void *user_data)
{
- GSupplicantInterface *interface = user_data;
- GSupplicantNetwork *network;
- const char *path = NULL;
-
- dbus_message_iter_get_basic(iter, path);
- if (!path)
- return;
-
- network = g_hash_table_lookup(interface-net_mapping, path);
- if (!network)
- return;
-
- g_hash_table_remove(interface-net_mapping, path);
+ /* Function can be removed? */
Keep the function, for debug. So remove this comment.
+ SUPPLICANT_DBG();
+ return;
}
Rest is fine.
Tomasz
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: Does connman support p2p Concurrent roles ?
Hi, Does connman support concurrent device role ? No. Is it possible via connman that one P2P device operates on 2.4GHz band and another operates on 5GHz band ? No. P2P Api would still need quite some work to do that, and anyway, most of the work is on how to interface wpa_supplicant properly for that. When you see the amount of code just to do the simplest thing with it... you can imagine how much work it represents to add such nicer behaviors. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Why and where does connman disables wpa_supplicant networks ?
Hi Pedro, After a disconnection I see the following on wpa_cli + list_networks: So basically here you are accessing wpa_supplicant through the unix socket interface which means your instance of wpa_supplicant is started with that unix socket interface in addition of the DBus one connman uses, so you probably load a conf file for wpa_supplicant on the way. All in all this is wrong. Only DBus interface should be there and connman should be the only one in charge. network id / ssid / bssid / flags 0 dlink any [DISABLED] 1 dlink any As there is a network, wpa_supplicant keeps scanning and connects succesfully, but after several reconnect-disconnect loops we get the following: network id / ssid / bssid / flags 0 dlink any [DISABLED] 1 dlink any [DISABLED] 2 dlink any [DISABLED] 3 dlink any [DISABLED] 4 dlink any [DISABLED] So wpa_supplicant does not reconnects automatically since there are no networks enabled. ConnMan, while connecting, adds the network in wpa_supplicant, and once it disconnects: it removes it. What you are seeing is due to how you run wpa_supplicant. I've not seen this behaviour when using only wpa_supplicant. In that case the network simply appears as this. Using only wpa_supplicant is a totally different thing versus using ConnMan. When using ConnMan, then it is the only one in charge of connecting/disconnecting and all the control should go through its dbus interface only, and nothing else. 0 dlink any So my questions are, 1) why connman disables the networks and 2) how can we disable that behaviour, since it is causing us great problems with several customers. 1) ConnMan is in charge, thus does not care of any networks pre-configured in wpa_supplicant. The ones loaded from wpa_supplicant.conf I guess, which should not be loaded ever (since it means you enable the unix socket interface as well then.) 2) You cannot disable this behavior. The problem you are experiencing is actually not this. It's connman not reconnecting automatically to any networks, am I right? In that case let's review how you built connman and wpa_supplicant, how you configured connman (and not wpa_supplicant) etc... Because ConnMan is smart enough to drive wpa_supplicant in auto-scan, autoconnect, roam, and so on. Br, Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Why and where does connman disables wpa_supplicant networks ?
Hi Pedro, Getting all the logs would help me, do like this: - stop wpa_supplicant and connman - start wpa_supplicant this way: wpa_supplicant -udddt wpa_s.log - start connman this way:CONNMAN_SUPPLICANT_DEBUG=1 connmand -dn connman.log Paste them on pasteall.org, for instance, and give the links. Btw, when you get disconnected: is it because you loose the connection or because you as a user requested a disconnect? When you disconnect by yourself, then connman will not autoconnect on that one (as long as it is present in the scan results) since it thinks you don't want to be connected anymore on that service. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Input/output error
Hi, So I guess you could start connman (it would be nice if you replied to your other mails telling if it went well or not btw) I/O error is usually because the connection misses some information. Do you run the agent in connmanctl? (again, please read connman's documentation) connmanctl agent on That will request you the info which might be needed when connecting (the passphrase for instance). If it's not the problec, then we will need logs: Without logs, it won't be easy to tell what's happening. - stop wpa_supplicant and connman - start wpa_supplicant this way: wpa_supplicant -udddt wpa_s.log - start connman this way:CONNMAN_SUPPLICANT_DEBUG=1 connmand -dn connman.log Paste them on pasteall.org (for instance) and tell us about it. Br, Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: How to test P2P or Wi-Fi Direct Functionality using Connman ??
Hi, ConnMan won't tell you unless: - the chip supports it - and the driver too - and finally wpa_supplicant is built to support it. So if technology p2p does not show up on ConnMan this means at least one this 3 reason might be true. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: How to test P2P or Wi-Fi Direct Functionality using Connman ??
Hum: ConnMan won't tell you unless: - the chip supports it - and the driver too - and finally wpa_supplicant is built to support it. So if technology p2p does not show up on ConnMan this means at least one this 3 reason might be true. s/true/false ;) Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: connman Digest, Vol 77, Issue 1
Please, can you use Reply to to a mail, or then we loose the track about which mail thread your are talking. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] gsupplicant: fix finding matching group
Hi Michael,
ACK from me.
Tomasz
g_slist_find_custom() expects a function that return 0 when the arguments
are equal. g_str_equal() returns TRUE, so any not matching group is found.
---
gsupplicant/supplicant.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index 81fcadc639bd..8c49c1ee8c99 100755
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -2678,7 +2678,7 @@ static void peer_groups_relation(DBusMessageIter *iter,
void *user_data)
if (!group)
return;
- elem = g_slist_find_custom(data-old_groups, str, g_str_equal);
+ elem = g_slist_find_custom(data-old_groups, str,
(GCompareFunc)g_strcmp0);
if (elem) {
data-old_groups = g_slist_remove_link(data-old_groups, elem);
peer-groups = g_slist_concat(elem, peer-groups);
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] peer: stop dhcp client when switching to CONNMAN_PEER_STATE_DISCONNECT state
Hi Michael, ACK from me. Tomasz Otherwise __connman_dhcp_stop() is never called when the disconnect is triggered by the peer. peer_disconnect() already handles this correctly for locally triggered disconnects. --- src/peer.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/peer.c b/src/peer.c index 206b799b2a18..8a380c96d2a4 100644 --- a/src/peer.c +++ b/src/peer.c @@ -909,6 +909,8 @@ int connman_peer_set_state(struct connman_peer *peer, case CONNMAN_PEER_STATE_DISCONNECT: if (peer-connection_master) stop_dhcp_server(peer); + else + __connman_dhcp_stop(peer-ipconfig); peer-connection_master = false; peer-sub_device = NULL; ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Facing issues with connMan
Hi, Is your wifi card un-rfkilled? (a hardware switch maybe present if it's a laptop). What about wpa_supplicant: is it running, and if so: with what options? Br, Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Facing issue with connmanctl in ARM platform
Hi, dbus service is not started ? Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] wifi: fix device type category/sub_category endianess
Hi Michael,
I remember Jussi had a patch for that already when he found out such
issue. We may have missed it.
Verify anyway in wpa_supplicant, afaik the dbus part does not use
wps_dev_type_str2bin()
Tomasz
category and sub_category must be big-endian in the device-type string.
---
I could not find a explicit endianess for this in the spec, however
wpa_supplicant (see wps_dev_type_str2bin()), wireshark and various devices
all use big-endian here, so I'm pretty sure that this is correct.
plugins/wifi.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/plugins/wifi.c b/plugins/wifi.c
index 1f90a311a2a1..8246c45f974b 100644
--- a/plugins/wifi.c
+++ b/plugins/wifi.c
@@ -2446,24 +2446,24 @@ static void interface_removed(GSupplicantInterface
*interface)
static void set_device_type(const char *type, char dev_type[17])
{
const char *oui = 0050F204;
- const char *category = 0100;
+ const char *category = 0001;
const char *sub_category = ;
if (!g_strcmp0(type, handset)) {
- category = 0A00;
- sub_category = 0500;
+ category = 000A;
+ sub_category = 0005;
} else if (!g_strcmp0(type, vm) || !g_strcmp0(type, container))
- sub_category = 0100;
+ sub_category = 0001;
else if (!g_strcmp0(type, server))
- sub_category = 0200;
+ sub_category = 0002;
else if (!g_strcmp0(type, laptop))
- sub_category = 0500;
+ sub_category = 0005;
else if (!g_strcmp0(type, desktop))
- sub_category = 0600;
+ sub_category = 0006;
else if (!g_strcmp0(type, tablet))
- sub_category = 0900;
+ sub_category = 0009;
else if (!g_strcmp0(type, watch))
- category = FF00;
+ category = 00FF;
snprintf(dev_type, 17, %s%s%s, category, oui, sub_category);
}
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: follow-up
Ah you did actually get the wpa_supplicant logs in the other mail, ok. Ok try to update wpa_supplicant. It's definitely not a connman bug. It might be related to the regulatory domain update once you get associated somehow. I have seen such bug passing by before on wpa_s. Let us know Tomasz Hi Thomas, Could you grab all connman and wpa_supplicant logs this way: - wpa_supplicant -u -dddt wpa_supp.log - CONNMAN_SUPPLICANT_DEBUG=1 CONNMAN_DHCP_DEBUG=1 connmand -n -d connman.log Also, try to upgrade to latest wpa_supplicant, a huge amount of fixes went in (and ssl related ones, might be worth being up to date with openssl as well) Tomasz ___ 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: Reconciling autoscan/bgscan intervals and default bss expiration age
Hi Adam, I’m trying to understand the the bgscan and autoscan parameters in plugins/wifi.c - specifically the maximum/long intervals of 300 seconds. With the supplicant’s default BSS Expiration Age of 180 seconds, this results in premature aging of the BSSs, resulting in an empty services list or perhaps worse, an inability to roam or recover from a lost association. I could always tweak these settings or increase the age in the supplicant - but I’m curious why I would need to change something like this out of the box - perhaps I’m missing something. The point of autoscan is not to keep alive the list of BSS. It is to be able to find a service at some point, if you were moving around, while being disconnected. Scanning is expensive from power consumption point of view, thus an exponential delay with a limit of 300 seconds of automatic scanning. If you reach this limit of 300 seconds without being connected this means there is no know service around, so no need to pursue expensive scanning. That said, this is relevant as long as you - as the user - do not request a scan by yourself. If you do so, this will reset the autoscan counter back. About bgscan: this one is in use when you are connected, to roam if the AP setup supports it. I may also ask the supplicant mailing list why they use these configurations in their examples as well, but I thought I’d start here. autoscan is now connman-based only. As the wpa_supplicant's module does not handle hidden services. bgscan is ran in wpa_supplicant, the parameters we give are the default one which are usually ok. But it might depend on the wifi card and its driver (sometime the signal threshold is wrongly calculated there, so it only triggers when you are out of reach already) Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [help] Implementation of 2 internet contexts
Hi Mylene, I understand and see (in outline) how adapt the code. Thank you for the tips, it will help me a lot if the Frederik solution's did not work for me. Looks like Frederik's solution works with either context A or context B, not both at same time. Anyway, if you get a patch that works, you will be welcomed to send it on this ML. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] gsupplicant: Add interface DisconnectReason Property
Hi Saurav,
+ } else if (g_strcmp0(key, DisconnectReason) == 0) {
+ int reason = 0;
+
+ dbus_message_iter_get_basic(iter, reason);
+ SUPPLICANT_DBG(Disconnect Reason %d, reason);
+ interface-disconnect_reason = reason;
If it's only for debugging reason, one will take a look at
wpa_supplicant's log actually.
This has not been used in ConnMan because it does not need it.
Tomasz
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: [help] Implementation of 2 internet contexts
Hi Mylene, That would need to be fixed yes. My best bet would be to revert the logic when it comes to context and network: instead of modem-context = ... you could have: context-modem = modem and modem-contexts would be a list of those context (a simple GSList). Yes, this is what I have done so far. I did not create a GSList but a HashTable to have the context_path, but it is pretty the same logic. Unless you get dozens of contexts, go for a GSList. GHashTable does not have tiny memory footprint. (well, the current code is not perfect either. With an hashtable storing context path/data pairs is also overkill. I guess we would need to cleanup this also one day) Then you would create the network with the context as data. For the network, try to get a name made of the modem's name, and something that identifies the context (is there such thing? I don't know) In fact, the network is created with the context path as identifier. So I have the information but since it is the identifier, should I create a list of networks ? do you think it could work ? If I implement a list of network, the add_network and connman_network_create would be called twice (for the two contexts). I think you have more distance than me about the code : do you think it could work like this ? Actually I missed this last time. But you seem to be on the right track. Since you are moving towards a network per context, remove the network pointer and put it network_context structure. You will thus get in a modem: a list of context as you did, each context will point to its proper network structure. So indeed you will call add_network and connman_network_create as many times as context your modem provides. You will have to change many functions which works on modem basis instead of context. (like set_connected, or netreg_update_strength where you would need to loop on each context from the modem, etc...) Basically, whatever exists around modem-network, you will have to adapt the code to the new logic. I have never touched that plugin myself, so I might miss some stuff there. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: No more IP adress when switching from dhcp to manual
Hi Thierry, I have an issue using connman when switching from dhcp to manual configuration, and coming back to dhcp configuration. With the particularity that in the manual configuration I am using the address given by the dhcp. Do you disconnect and re-connect in between? Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Essentials/Dependencies for P2P from Laptop to Mobile Device
Hi, I wanted to know what are the dependencies like 1) Wifi Driver 2) Chip support Atheros (ath9k and ath10k driver based) and intel's (only 7260!) are known to work. Nothing special on kernel side afaik. Verify you chip from lspci 3) Correct procedure to do this Verify Connman's README file, wpa_supplicant needs to be built with proper options. Most of the work is done by wpa_supplicant (Connman is only piloting it) The later version the better. (2.4-r1) 4) Or Anything else which is required. connmanctl on the laptop side agent on scan p2p -- to scan for p2p peers peers --- results connect peer id Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [help] Implementation of 2 internet contexts
Hi Mylene, I haven't worked on this plugin but it looks like the issue a network is added per-modem only, not really per-modem-context. And, in general, how would be the best way to implement a list of context ? Why connman, currently, handles only one internet context ? I think there was a reason to implement it like this. What is it ? Yep you saw the comment on add_cm_context(). That would need to be fixed yes. My best bet would be to revert the logic when it comes to context and network: instead of modem-context = ... you could have: context-modem = modem and modem-contexts would be a list of those context (a simple GSList). Then you would create the network with the context as data. For the network, try to get a name made of the modem's name, and something that identifies the context (is there such thing? I don't know) This require to change the structures and logic accordingly, could be quite some work. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Essentials/Dependencies for P2P from Laptop to Mobile Device
Hi, WI-FI chip Intel Centrino Advanced N-6205 this confirmed from lshw and lspci. I have already compiled the wpa_supplicant with options related to P2P from documentation. Because when I run - scan p2p - I get an error - FAIL. Same is the case if I by-pass connman and check with wpa_cli utility. But According to Intel's Centrino Advanced N-6205 - it says - it does support WIFI-Direct - But I am not sure how to get it to work. Nah too old, if such support have been made then maybe once and on windows only. The only intel chip which is known to work properly with p2p is 7260. I also have a Ubuntu 12.10 on a Lenovo T540p which has Atheros chip for wifi. On this laptop - When I run scan p2p from connmand or wpa_cli I do get a success. But p2p connect and other connect functionalities do not work. Could this be something related to wpa_supplicant or still a driver or firmware issue ? Most probably. Ath9k started to work reliably only recently (a year or so), if you can upgrade all (kernel and firmwar), in addition of wpa_supplicant, this could fix you issue. So from both ends Connmand and wpa_cli I get same results for Atheros based Laptop . Of course yes. Wpa_supplicant is the one that deals with the kernel/driver. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: No more DNS with latest patches
Hi Olivier, Hello, I have tried to take latest patches (commits until service: Remove duplicate functionhttp://git.kernel.org/cgit/network/connman/connman.git/commit/?id=f29bcdfd266224d3c9c03f89f297f7f44d46cd2c) and I am now facing a DNS issue. A time on 2 after reboot, my resolv.conf file is not filled correctly. I don’t have name server line anymore. I have attached traces. Which are missing ;) So you cold really bisect that this patch is the culprit? Tomasz ___ 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
Did not check thoroughly, I though setting network connected to false
would do.
Ok then.
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
___
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 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
Re: [PATCH v3] wifi: disconnect if wpa_s state changes from completed to scanning
Ok ACK from me then.
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 | 10 ++
1 file changed, 10 insertions(+)
diff --git a/plugins/wifi.c b/plugins/wifi.c
index d0d7917..a22faae 100755
--- a/plugins/wifi.c
+++ b/plugins/wifi.c
@@ -2341,6 +2341,9 @@ static void interface_state(GSupplicantInterface
*interface)
switch (state) {
case G_SUPPLICANT_STATE_SCANNING:
+ if (wifi-connected)
+ connman_network_set_connected(network, false);
+
break;
case G_SUPPLICANT_STATE_AUTHENTICATING:
@@ -2435,6 +2438,13 @@ static void interface_state(GSupplicantInterface
*interface)
else
wifi-connected = false;
break;
+ case G_SUPPLICANT_STATE_SCANNING:
+ if (wifi-connected) {
+ wifi-connected = false;
+ start_autoscan(device);
+ } else
+ wifi-connected = false;
+ break;
case G_SUPPLICANT_STATE_COMPLETED:
wifi-connected = true;
break;
___
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 Pasi,
+ 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)
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?
Tomasz
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: re-connecting to enterprise network
Hi Thomas, It would seem as if the failed attempt did not send the proper identity and passphrase. Is it possible to tell exactly what is being passed on the association phase? Best for that is to start both wpa_supplicant and connman manually this way (on their own console or screen terminal): wpa_supplicant -u -dddt wpa_supplicant.log CONNMAN_SUPPLICANT_DEBUG=1 connmand -nd connman.log connman's log won't probably tell much, as the error is surely on wpa_supplicant's side, but having both does not harm. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH 1/3] wifi: Introduce PassiveWiFiScan option
Hi Pasi,
- } 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.
Is this a wanted behavior? Because then PassiveWiFiScan is semantically
wrong as it does
not really completely avoid active scan.
Tomasz
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH 2/3] doc: Update connman.conf.5 about PassiveWiFiScan
Hi Pasi, +.B PassiveWiFiScan=\fPtrue|false\fP +Enable passive only scanning for WiFi in case of +one does not want to reveal SSIDs for currently configured +services. Only exception being that with hidden networks +the initial connection will still do an active scan. +Default value is false. Add also that if enabled, this will prevent auto-connecting to know hidden network. Thus forcing the user to always connect manually to an hidden network. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: supplicant.c memory leak etc.
Hi Slava, This looks really suspicious. Such functions are always used to agglomerate BSS into networks. Which networks are then pushed to the wifi plugins through callbacks. Some of these exist because of different behaviors of wpa_supplicant and its different versions (from 0.7.3 If I remember well). This code path is used during wifi operation, so a leak should have been found long ago. What are the steps followed to get such leak? What patches do you have on top? Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: traffic counting, iptables and connman
Hi Thiemo, Is there a reason why connman does not use libiptc to change the iptables but has its own code to communicate with the kernel? I am asking because I was looking into the fact that the iptables counters are reset when connman starts. I also looked into how the counters are handled by iptables-restore / iptables, which both use libiptc. Libiptc seems to contain quite some code to manage the counter values properly and it feels a bit like reinventing the wheel when doing pretty much the same in connman. libiptc has been done with iptables tools in mind, so it does thing for those use-case. It's a glue on top libxtables, which libxtables connman uses anyway. There were issues about libiptc, I can't remember what (the asserts are not nice for instance etc..). And today's libptc has also change quite a lot I think. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] gsupplicant: Remove unused networks
Hi Slava, It appears that the client is responsible for removing network configurations it has created, which makes sense to me. In an environment with unstable wifi reception, connman may end up creating hundreds of those in just one day of normal usage. Well this is true if it always fail connecting to hundreds different networks yes (and only at SelectNetwork). That's the only possibility. So indeed there is a bug, but unlikely to happen. Your patch is fine but it is not removing the network at the right place then. You should do it in interface_select_network_result() if that one returns an error. So the network is removed as soon as possible. I don't think there is any other case matching this situation: when we disconnect, we remove the network. If AddNetwork fails, no need to remove anything. I think it should be fine then. Also, try reusing existing code: network_remove() does what you want already. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] gsupplicant: Remove unused networks
Hi Slava, It appears that the client is responsible for removing network configurations it has created, which makes sense to me. In an environment with unstable wifi reception, connman may end up creating hundreds of those in just one day of normal usage. Well this is true if it always fail connecting to hundreds different networks yes (and only at SelectNetwork). That's the only possibility. So indeed there is a bug, but unlikely to happen. Try this: connect to wifi, walk out of the wifi range, wait for connman to realize that, return back into the range, wait for connman to re-connect and compare 'wpa_cli list_net' before and after the exercise. What do you get? Ah, That's another bug then! If we detect that we got disconnected, the wifi plugins will need to cleanup. Actually, it cleanups if the user disconnects, but not this way round. Check interface_state() in wifi_plugins. This will need a separate patch. Your patch is fine but it is not removing the network at the right place then. You should do it in interface_select_network_result() if that one returns an error. So the network is removed as soon as possible. As soon as possible is where I put it. By the time it gets to interface_select_network_result() the previous path is lost. In the context I was thinking, the SelectNetwork that fails, this is the place to go. If you handle this non-user disconnection properly, there will be no need to run anything in interface_add_network_result(). Actually, gsupplicant should not run AddNetwork if interface-network_path is a valid pointer. If this pointer is already set, it means we are doing something wrong elsewhere, which we are obviously. I don't think there is any other case matching this situation: when we disconnect, we remove the network. If AddNetwork fails, no need to remove anything. I think it should be fine then. Also, try reusing existing code: network_remove() does what you want already. network_remove() requires allocation of another interface_data which in this case was unnecessary and would require writing more code than I wanted to. That's true. Now that might be an occasion to factorize the code: make network_remove() generic so it would allocate or not some data (for instance if there is a callback/user data, then allocate. If not: NULL). As you want, but that could avoid duplicate routines. Just looked at the code, network_remove(GSupplicantInterface *interface, struct interface_data *data); could be the solution. Use the interface pointer (not the one that might be in data). If data is valid, use that one to add the path parameter, if not use your function objpath_params() which you could rename as network_remove_append_objpath() for instance. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] gsupplicant: Remove unused networks
Hi Slava, Ah, That's another bug then! If we detect that we got disconnected, the wifi plugins will need to cleanup. Actually, it cleanups if the user disconnects, but not this way round. Check interface_state() in wifi_plugins. This will need a separate patch. Well, it actually kind of works. When wifi signal is lost, wifi plugin does some sort of cleanup like this: #1 0x0003d8cc in free_network () at src/device.c:378 #2 0x4031b1e8 in g_hash_table_remove_node () at ghash.c:448 #3 0x4031b9d4 in g_hash_table_remove_internal () at ghash.c:1276 #4 0x0003ea20 in connman_device_remove_network () at src/device.c:905 #5 0x000201c4 in network_removed () at plugins/wifi.c:2064 #6 0x0002388c in callback_network_removed () at gsupplicant/supplicant.c:445 #7 remove_network () at gsupplicant/supplicant.c:523 Ok, yes is removes the gsupplicant's network entity, but does not remove the wpa_supplicant's side of it, if it has been added there. And that happens only when the ssid cannot be found from scan result. I'll check, but I am sure we are missing a cleanup at the point where we get disconnected in interface_state(). (actually, and that's a kind of design mistake, gsupplicant's network entity does not know anything about itself being added or not in wpa_supplicant... only interface knows) There are some corner cases that I have been unable to catch so far, which result in connman_service holding a reference to connman_network in connecting/associating state (albeit with driver pointer being NULL) but those are quite rare. That sort of things happens once in a new weeks of normal usage (which involves periodic switching between mobile data and various wifi networks) but once it does happen, connman is unable to recover and needs to be restarted. That's quite annoying for the end-users of the device. Yup, looks like a critical bug. If by chance you get the connman logs of such issue, it will be welcomed. But normally things get cleaned up all right, except that wpa_supplicant configuration doesn't get removed, which is the problem that I addressed in this patch. Since I'm not the one who designed this thing, I prefer small fixes that don't affect the overall architecture which at times is pretty hard to grasp. If you are not happy with this approach, you are quite welcome to fix it the right way. gsupplicant/wifi plugins is indeed probably the most complicated part, and for a good reason: have a look at wpa_supplicant DBus API ;( plus some design issues (maybe the gsupplicant's network part could have been avoided at least. The thing is: you patch at this stage is not going to make it upstream. Up to you. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: How does connman handle scan_ssid?
ConnMan does a known networks scan, so indeed it leaks the known SSIDs. We could easily add a main.conf parameter to prevent that. Sounds good. What would be the trade-offs? More time needed to authenticate? More time to autoconnect on known-networks basically. For instance, one passive scan might miss some results (the time frame just missed some beacons etc...). But fortunately in ConnMan handles automatic scans, as long as the user has not disabled it from main.conf of course. Maybe some seconds more to autoconnect on worst cases. 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. The best ever solution would be to get ConnMan knows always its location and could then run active scans relevantly (i.e. running an active scan for the home AP since it knows this AP is located there and it is where we are currently etc...). Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: How does connman handle scan_ssid?
Hi Sven, ConnMan does a known networks scan, so indeed it leaks the known SSIDs. We could easily add a main.conf parameter to prevent that. Tomasz 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 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: Network state is ready instead of online after getting a DHCP address
Hi, The online is found while checking for internet connectivity. The issue is it's done right away after ConnMan gets the ip/dns/routes configured. At this exact moment, the network might not be fully ready, for some reasons. We are talking of micro-seconds here. On the other end, the network infrastructure behind the connection might not be ready itself (for instance in nating is used, and the nat rule has not been established yet etc...) And also, if the distant servers which are used to check the connectivity are down (very rare though). So as you can see, it's not bullet proof. Thus you should not assume too much about this state. ready might just be totally fine as well. As long as you are in state ready, you should assume the network connectivity is fine. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] Add setting: UpdateResolvConf
Hi, It makes sense to me to not use every random DNS server out there... Sure, but your ubound does not magically resolve names by itself: it does forward the DNS queries to whatever has been configured (check /etc/unbound/unbound.conf keyword forward-zone) and cache the results relevantly. DNSSEC should ensure I get responses that haven't been tampered with... Sure, as long as the configured DNS you use to forward to support it. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] Add setting: UpdateResolvConf
Hi, You might be able to configure connman to use your 127.0.0.53 server by configuring it to each service you are using (have not tested this thou). Example: connmanctl config your_service_id --nameservers 127.0.0.53 and then running connman with dnsproxy enabled. No, afaik you need to disable dnsproxy. Or then you will end up with: dnsproxy configured to use 127.0.0.53 as nameserver, and resolv.conf with 127.0.0.1 as nameserver. Duplicated local dns cache/forwarder. If dnsproxy is disable, resolv.conf will directly get the 127.0.0.53 Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Issue found in service connman ordering
Hi, You are assuming the ordering based on the online state taking over the ready state. However that's flawed, because there is no way you can guaranty for a service to get such online state all the time. There is quite a lot of logic behind the internet connectivity check, and it's not 100% bullet proof. (if you dns servers fails, if the distant connectivity check website is down, etc etc...) After all, being ready does not mean you cannot access the internet. If you want to order service, you will have to order them by yourself through Service.MoveAfetr() or Service.MoveBefore() methods. And, anyway, as pointed previously, switching to the latest and greatest version of ConnMan (1.27 now) is always a good idea! Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH] wifi: Remove entirely the support for wpa_supplicant autoscan
ConnMan's own autoscan mechanism has proven to work properly than
wpa_supplicant's one which does not support hidden SSIDs. Thus removing
its support entirely.
---
gsupplicant/gsupplicant.h | 5
gsupplicant/supplicant.c | 66 ---
plugins/wifi.c| 21 +--
3 files changed, 1 insertion(+), 91 deletions(-)
diff --git a/gsupplicant/gsupplicant.h b/gsupplicant/gsupplicant.h
index 97c804a..187dc65 100644
--- a/gsupplicant/gsupplicant.h
+++ b/gsupplicant/gsupplicant.h
@@ -225,11 +225,6 @@ int g_supplicant_interface_scan(GSupplicantInterface
*interface,
GSupplicantInterfaceCallback callback,
void *user_data);
-int g_supplicant_interface_autoscan(GSupplicantInterface *interface,
- const char *autoscan_data,
- GSupplicantInterfaceCallback callback,
- void *user_data);
-
int g_supplicant_interface_p2p_find(GSupplicantInterface *interface,
GSupplicantInterfaceCallback callback,
void *user_data);
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index 3bdf0dc..dd9a525 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -3443,14 +3443,6 @@ struct interface_scan_data {
void *user_data;
};
-struct interface_autoscan_data {
- GSupplicantInterface *interface;
- char *path;
- GSupplicantInterfaceCallback callback;
- const char *autoscan_params;
- void *user_data;
-};
-
static void interface_create_data_free(struct interface_create_data *data)
{
g_free(data-ifname);
@@ -3967,64 +3959,6 @@ int g_supplicant_interface_scan(GSupplicantInterface
*interface,
return ret;
}
-static void interface_autoscan_result(const char *error,
- DBusMessageIter *iter, void *user_data)
-{
- struct interface_autoscan_data *data = user_data;
- int err = 0;
-
- if (error) {
- SUPPLICANT_DBG(error %s, error);
- err = -EIO;
- }
-
- g_free(data-path);
-
- if (data-callback)
- data-callback(err, data-interface, data-user_data);
-
- dbus_free(data);
-}
-
-static void interface_autoscan_params(DBusMessageIter *iter, void *user_data)
-{
- struct interface_autoscan_data *data = user_data;
-
- dbus_message_iter_append_basic(iter, DBUS_TYPE_STRING,
-data-autoscan_params);
-}
-
-int g_supplicant_interface_autoscan(GSupplicantInterface *interface,
- const char *autoscan_data,
- GSupplicantInterfaceCallback callback,
- void *user_data)
-{
- struct interface_autoscan_data *data;
- int ret;
-
- data = dbus_malloc0(sizeof(*data));
- if (!data)
- return -ENOMEM;
-
- data-interface = interface;
- data-path = g_strdup(interface-path);
- data-callback = callback;
- data-autoscan_params = autoscan_data;
- data-user_data = user_data;
-
- ret = supplicant_dbus_method_call(interface-path,
- SUPPLICANT_INTERFACE .Interface, AutoScan,
- interface_autoscan_params,
- interface_autoscan_result, data,
- interface);
- if (ret 0) {
- g_free(data-path);
- dbus_free(data);
- }
-
- return ret;
-}
-
static int parse_supplicant_error(DBusMessageIter *iter)
{
int err = -ECANCELED;
diff --git a/plugins/wifi.c b/plugins/wifi.c
index e081f8a..1f90a31 100644
--- a/plugins/wifi.c
+++ b/plugins/wifi.c
@@ -1399,22 +1399,8 @@ static void setup_autoscan(struct wifi_data *wifi)
start_autoscan(wifi-device);
}
-static void interface_autoscan_callback(int result,
- GSupplicantInterface *interface,
- void *user_data)
-{
- struct wifi_data *wifi = user_data;
-
- if (result 0) {
- DBG(Could not enable Autoscan, falling back...);
- setup_autoscan(wifi);
- }
-}
-
static void finalize_interface_creation(struct wifi_data *wifi)
{
- GSupplicantInterface *interface = wifi-interface;
-
DBG(interface is ready wifi %p tethering %d, wifi, wifi-tethering);
if (!wifi-device) {
@@ -1430,12 +1416,7 @@ static void finalize_interface_creation(struct wifi_data
*wifi)
if (wifi-p2p_device)
return;
- /* Setting up automatic scanning */
- if (g_supplicant_interface_autoscan(interface, AUTOSCAN_DEFAULT,
-
[PATCH 3/3] peer: Get the dhcp server address relevantly for IPv4 settings
The dhcp server address is the one to consider as remote address if
there is no gateway set.
---
src/peer.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/peer.c b/src/peer.c
index f48fb03..206b799 100644
--- a/src/peer.c
+++ b/src/peer.c
@@ -285,6 +285,7 @@ static void append_ipv4(DBusMessageIter *iter, void
*user_data)
char trans[INET_ADDRSTRLEN+1] = {};
const char *local = ;
const char *remote = ;
+ char *dhcp = NULL;
if (!is_connected(peer))
return;
@@ -299,13 +300,22 @@ static void append_ipv4(DBusMessageIter *iter, void
*user_data)
remote = trans;
} else if (peer-ipconfig) {
local = __connman_ipconfig_get_local(peer-ipconfig);
+
remote = __connman_ipconfig_get_gateway(peer-ipconfig);
+ if (!remote) {
+ remote = dhcp = __connman_dhcp_get_server_address(
+ peer-ipconfig);
+ if (!dhcp)
+ remote = ;
+ }
}
connman_dbus_dict_append_basic(iter, Local,
DBUS_TYPE_STRING, local);
connman_dbus_dict_append_basic(iter, Remote,
DBUS_TYPE_STRING, remote);
+ if (dhcp)
+ g_free(dhcp);
}
static void append_peer_service(DBusMessageIter *iter,
--
2.0.5
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH 1/3] gdhcp: Add an helper function to get the dhcp server address
This will be useful later on for the Peer API.
---
gdhcp/client.c | 8
gdhcp/gdhcp.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/gdhcp/client.c b/gdhcp/client.c
index ec61731..49d6351 100644
--- a/gdhcp/client.c
+++ b/gdhcp/client.c
@@ -2989,6 +2989,14 @@ int g_dhcp_client_get_index(GDHCPClient *dhcp_client)
return dhcp_client-ifindex;
}
+char *g_dhcp_client_get_server_address(GDHCPClient *dhcp_client)
+{
+ if (!dhcp_client)
+ return NULL;
+
+ return get_ip(dhcp_client-server_ip);
+}
+
char *g_dhcp_client_get_address(GDHCPClient *dhcp_client)
{
return g_strdup(dhcp_client-assigned_ip);
diff --git a/gdhcp/gdhcp.h b/gdhcp/gdhcp.h
index 7525eb2..0ed7fa5 100644
--- a/gdhcp/gdhcp.h
+++ b/gdhcp/gdhcp.h
@@ -150,6 +150,7 @@ GDHCPClientError g_dhcp_client_set_send(GDHCPClient *client,
unsigned char option_code,
const char *option_value);
+char *g_dhcp_client_get_server_address(GDHCPClient *client);
char *g_dhcp_client_get_address(GDHCPClient *client);
char *g_dhcp_client_get_netmask(GDHCPClient *client);
GList *g_dhcp_client_get_option(GDHCPClient *client,
--
2.0.5
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH] README: Remove bogus advice on wpa_supplicant building setting
The autoscan module in wpa_supplicant cannot handle hidden SSIDs, where connman's autoscan policy does it properly so let's use this later one only. --- README | 7 --- 1 file changed, 7 deletions(-) diff --git a/README b/README index b1367dd..531f396 100644 --- a/README +++ b/README @@ -312,13 +312,6 @@ CONFIG_BGSCAN_SIMPLE=y This last option will enable the support of background scanning while being connected, which is necessary when roaming on wifi. -and finally: - -CONFIG_AUTOSCAN_EXPONENTIAL=y - -This will enable the exact same function as bgscan but while being -disconnected. - It is recommended to use wpa_supplicant 2.x or later. If wpa_supplicant is configured to D-Bus autostart, then ConnMan will -- 2.0.5 ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH 2/3] dhcp: Add an helper function to get the dhcp server address
This will be useful for the Peer API.
---
src/connman.h | 1 +
src/dhcp.c| 11 +++
2 files changed, 12 insertions(+)
diff --git a/src/connman.h b/src/connman.h
index 2524f07..8d4a692 100644
--- a/src/connman.h
+++ b/src/connman.h
@@ -451,6 +451,7 @@ typedef void (* dhcpv6_cb) (struct connman_network *network,
typedef void (* dhcp_cb) (struct connman_ipconfig *ipconfig,
struct connman_network *opt_network,
bool success, gpointer data);
+char *__connman_dhcp_get_server_address(struct connman_ipconfig *ipconfig);
int __connman_dhcp_start(struct connman_ipconfig *ipconfig,
struct connman_network *network, dhcp_cb callback,
gpointer user_data);
diff --git a/src/dhcp.c b/src/dhcp.c
index 841b0c7..09f462b 100644
--- a/src/dhcp.c
+++ b/src/dhcp.c
@@ -582,6 +582,17 @@ static int dhcp_release(struct connman_dhcp *dhcp)
return 0;
}
+char *__connman_dhcp_get_server_address(struct connman_ipconfig *ipconfig)
+{
+ struct connman_dhcp *dhcp;
+
+ dhcp = g_hash_table_lookup(ipconfig_table, ipconfig);
+ if (!dhcp)
+ return NULL;
+
+ return g_dhcp_client_get_server_address(dhcp-dhcp_client);
+}
+
int __connman_dhcp_start(struct connman_ipconfig *ipconfig,
struct connman_network *network, dhcp_cb callback,
gpointer user_data)
--
2.0.5
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH 0/3] Peer's remote IP fix
In a context where our local peer ends up as the GC, the GO is the dhcp server. If for some reason there is a gateway, it will get the priority over the dhcp server ip. Tomasz Bursztyka (3): gdhcp: Add an helper function to get the dhcp server address dhcp: Add an helper function to get the dhcp server address peer: Get the dhcp server address relevantly for IPv4 settings gdhcp/client.c | 8 gdhcp/gdhcp.h | 1 + src/connman.h | 1 + src/dhcp.c | 11 +++ src/peer.c | 10 ++ 5 files changed, 31 insertions(+) -- 2.0.5 ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Connecting to hidden networks only by chance
Hi Timo, I am a bit confused. In http://git.kernel.org/cgit/network/connman/connman.git/tree/README; the AUTOSCAN is recommended for wpa_supplicant. Yep, let's send a patch to remove this advice. Another point is, that roaming does not work properly. I enabled CONFIG_BGSCAN_SIMPLE as proposed for wpa_supplicant. Is this also not recommended by you? That one is indeed mandatory to get roaming working (and is working well). Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Connecting to hidden networks only by chance
Hi Tim, we are using connman with a hidden network which actually works, but there occurs the following strange behavior: Connman finds the hidden network only by chance, so if we start the system, connman may or may not connect. If we run connmanctl services the non-hidden networks are always found, and even the hidden network is displayed if (and only if) connman connected to it. If connman haven't connected to it, connman just does nothing until we scan explicitly for the network by using the following command: # iwlist wlan0 scanning essid myHiddenNetwork What if you run a scan wifi in connmanctl? Actually, sometimes we have to scan multiple times with the upper command. So if (and only if) the following command has an output, connman connects to the network immediately: # iwlist wlan0 scanning essid myHiddenNetwork | grep myHiddenNetwork We think that this is NOT a bug of connman, but some strange effect of our infrastructure. So our question is: Is there a way to tell connman to permanently scan for hidden networks, until it is connected? No, but connman does autoscan for a while. And actually, you might have a wrong build configuration of wpa_supplicant: check if you have enabled CONFIG_AUTOSCAN(*), just disable this: it does not handle hidden networks. If you disable this, connman will run its own fallback mechanism for autoscan and this one handles properly hidden networks. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] wifi: fix autoscan interval limit
Hi Jason, ACK on this patch. Thanks, Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH 1/2] peer: Refactor when IPv4 settings changed should be notified
This fixes inconcistant behavior in signaling IPv4 changes when
connected or disconnected happen.
---
src/peer.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/peer.c b/src/peer.c
index 5e9006f..99252f9 100644
--- a/src/peer.c
+++ b/src/peer.c
@@ -911,6 +911,10 @@ int connman_peer_set_state(struct connman_peer *peer,
peer-state = new_state;
state_changed(peer);
+ if (peer-state == CONNMAN_PEER_STATE_READY ||
+ peer-state == CONNMAN_PEER_STATE_DISCONNECT)
+ settings_changed(peer);
+
return 0;
}
@@ -1002,7 +1006,8 @@ static void peer_ip_bound(struct connman_ipconfig
*ipconfig,
DBG(%s ip bound, ifname);
- settings_changed(peer);
+ if (peer-state == CONNMAN_PEER_STATE_READY)
+ settings_changed(peer);
connman_peer_set_state(peer, CONNMAN_PEER_STATE_READY);
}
@@ -1013,7 +1018,8 @@ static void peer_ip_release(struct connman_ipconfig
*ipconfig,
DBG(%s ip release, ifname);
- settings_changed(peer);
+ if (peer-state == CONNMAN_PEER_STATE_READY)
+ settings_changed(peer);
}
static const struct connman_ipconfig_ops peer_ip_ops = {
--
2.0.5
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH 2/2] peer: Reset the lease when dhcp server is stopped.
This prevent to get a former valid IP in a new connection. --- src/peer.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/peer.c b/src/peer.c index 99252f9..6d3f460 100644 --- a/src/peer.c +++ b/src/peer.c @@ -84,6 +84,7 @@ static void stop_dhcp_server(struct connman_peer *peer) if (peer-ip_pool) __connman_ippool_unref(peer-ip_pool); peer-ip_pool = NULL; + peer-lease_ip = 0; } static void dhcp_server_debug(const char *str, void *data) -- 2.0.5 ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH 0/2] Peer State and IPv4 signals fixups
Hi, This patch-set fixes 2 issues about IPv4 settigns updated through PropertyChanged signal. - first patch fixes the order and reliability of the signal - second patch cleans up the lease when relevant Tomasz Bursztyka (2): peer: Refactor when IPv4 settings changed should be notified peer: Reset the lease when dhcp server is stopped. src/peer.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) -- 2.0.5 ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH] gsupplicant: Find the peer properly in the group when disconnected
This fixes the issue when signal_peer_disconnected() does not propagate
the nominal event to plugins/wifi.c thus letting the peer as ready in
src/peer.c when it should be set to idle (and properly disconnected).
---
gsupplicant/supplicant.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index 060a4df..3bdf0dc 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -3086,7 +3086,11 @@ static void signal_group_peer_disconnected(const char
*path, DBusMessageIter *it
if (!peer_path)
return;
- elem = g_slist_find_custom(group-members, peer_path, g_str_equal);
+ for (elem = group-members; elem; elem = elem-next) {
+ if (!g_strcmp0(elem-data, peer_path))
+ break;
+ }
+
if (!elem)
return;
--
2.0.5
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: Connman network refcount
Hi Naveen, Again you don't seem to have the latest upstream version of ConnMan (1.27) network_connect() has no ret variable. It either returns g_supplicant_interface_connect() status directly or returns -EINPROGRESS. Which version of ConnMan are you using? With what patches on top, if any? We won't be able to help you if you don't answer these questions. Br, Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Connman network refcount
Hi Naveen, *Could it be because I am not using the version of wpa_supplicant that is required for working with latest connman (1.27). * 2.0 is fine, but latest and greatest it always the best (so 2.3 here). However, I already pin pointed out that you don't seem to have ConnMan 1.27, at least not from the logs you provided earlier, or the network_connect() snippet of code you gave. Br, Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: unable to access internet with manual proxy by connman
Hi, I use connman to set proxy, and could get proxy configuration correctly by pacrunner(use proxy and pacrunner test script to verify it), and when I access network, the proxy server could not get IP packages from IVI device. but if I use http_proxy system environment variable, the IVI device could access network by proxy correctly. Don't set http_proxy env variable. Whatever program which tries to access the network here needs to request the proxy configuration to pacrunner. (here you program find the http_proxy env variable and thus uses it, but that's a crappy way) This is usually done via using libproxy. Check this on Fedora for instance, pacrunner and libproxy are very well integrated there. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Connman network refcount
Hi, So Looks like decrementing the ref count from network removed was not correct. So either we add the network ref count from network_added function in supplicant or remove it from the network_removed function. Any thoughts? I am sorry, but what your are experiencing is really unclear. Connecting/Disconnecting hasn't brought any bugs for quite a long time. Don't try to explain the code, we know it. Please provide your logs. Br, Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: multiple scan_callback_hidden for a single wifi scan request making ref count to go to 0
Hi, You don't seem to have the connman from upstream. There have never been such wifi_data_ref and wifi_data_unref functions. Looks like your version has some additional patches on top. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: connman vs networkmanager today
Hi, Hello. I need to choose network application for my notebook, I need to have ability to connect to VPN and ipsec network, WiFi and wired. ConnMan does not support ipsec yet. What is the benefits in connman vs network manager? ConnMan lacks a proper and integrated UI in major DM. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Regd. Connman features
Hi, It would be very much appreciated, if anyone can provide answers of the below queries: * Apart from WLAN STA support, does connman supports Wi Fi AP role? If yes, is it communicates with hostapd? ConnMan supports wifi tethering (through wpa_supplicant) it's a lightweight AP mode. No hostapd involved. This feature is meant for connection sharing. (and it works with bt, ethernet etc... not only wifi) * Does connman supports P2P feature? Yes * Both IPv4 and IPv6 are supported in Connman? Yes * Does connman spawn DHCP client or server based on the interface, i.e DHCP server for AP interface, DHCP server for Supplicant? ConnMan does not spawn any process. It embeds a dhcp client and server directly and it all works much better than any spawn based solution. * Whether auto-configuration is also supported in connman. IPv6 autoconf? If so, then yes. * If packet filtering is supported in connnman? No. It uses a bit of xtables features for nating (for the tethering feature), and some other specific uses, but ConnMan is not a packet filtering frontend. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH v2 0/6] Peer API change: Local and Remote IP
2 Bugs were found in v1 and fixed. Each Peer object, once connected, will provide its local and remote IPv4 addresses through the IPv4 dict. Tomasz Bursztyka (6): doc: Improve Peer's API about local and remote IP address gdhcp: Call a function to tell about the given IP for a MAC gsupplicant: Add a getter for the Peer's interface address peer: Add a holder for peer's distant MAC address wifi: Set the MAC address of the distant peer peer: Changed IPv4 property to provide local and remote IP address doc/peer-api.txt | 10 --- gdhcp/gdhcp.h | 5 gdhcp/server.c| 13 gsupplicant/gsupplicant.h | 1 + gsupplicant/supplicant.c | 9 +- include/peer.h| 2 ++ plugins/wifi.c| 5 ++-- src/peer.c| 76 +++ 8 files changed, 88 insertions(+), 33 deletions(-) -- 2.0.4 ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH 6/6] peer: Changed IPv4 property to provide local and remote IP address
Thus it is possible to know our local IP as well as the Peer's remote IP
to start contacting it directly.
---
src/peer.c | 67 +++---
1 file changed, 42 insertions(+), 25 deletions(-)
diff --git a/src/peer.c b/src/peer.c
index 81fc1d2..5e9006f 100644
--- a/src/peer.c
+++ b/src/peer.c
@@ -66,9 +66,12 @@ struct connman_peer {
bool connection_master;
struct connman_ippool *ip_pool;
GDHCPServer *dhcp_server;
+ uint32_t lease_ip;
GSList *services;
};
+static void settings_changed(struct connman_peer *peer);
+
static void stop_dhcp_server(struct connman_peer *peer)
{
DBG();
@@ -88,6 +91,24 @@ static void dhcp_server_debug(const char *str, void *data)
connman_info(%s: %s\n, (const char *) data, str);
}
+static void lease_added(unsigned char *mac, uint32_t ip)
+{
+ GList *list, *start;
+
+ start = list = g_hash_table_get_values(peers_table);
+ for (; list; list = list-next) {
+ struct connman_peer *temp = list-data;
+
+ if (!memcmp(temp-iface_address, mac, ETH_ALEN)) {
+ temp-lease_ip = ip;
+ settings_changed(temp);
+ break;
+ }
+ }
+
+ g_list_free(start);
+}
+
static gboolean dhcp_server_started(gpointer data)
{
struct connman_peer *peer = data;
@@ -148,6 +169,8 @@ static int start_dhcp_server(struct connman_peer *peer)
g_dhcp_server_set_option(peer-dhcp_server, G_DHCP_DNS_SERVER, NULL);
g_dhcp_server_set_ip_range(peer-dhcp_server, start_ip, end_ip);
+ g_dhcp_server_set_lease_added_cb(peer-dhcp_server, lease_added);
+
err = g_dhcp_server_start(peer-dhcp_server);
if (err 0)
goto error;
@@ -255,39 +278,33 @@ static bool allow_property_changed(struct connman_peer
*peer)
return true;
}
-static void append_dhcp_server_ipv4(DBusMessageIter *iter, void *user_data)
+static void append_ipv4(DBusMessageIter *iter, void *user_data)
{
struct connman_peer *peer = user_data;
- const char *str = dhcp;
- const char *gateway;
- const char *subnet;
+ char trans[INET_ADDRSTRLEN+1] = {};
+ const char *local = ;
+ const char *remote = ;
- if (!peer-ip_pool)
+ if (!is_connected(peer))
return;
- gateway = __connman_ippool_get_gateway(peer-ip_pool);
- subnet = __connman_ippool_get_subnet_mask(peer-ip_pool);
+ if (peer-connection_master) {
+ struct in_addr addr;
- connman_dbus_dict_append_basic(iter, Method, DBUS_TYPE_STRING, str);
- connman_dbus_dict_append_basic(iter, Address,
- DBUS_TYPE_STRING, gateway);
- connman_dbus_dict_append_basic(iter, Netmask,
- DBUS_TYPE_STRING, subnet);
- connman_dbus_dict_append_basic(iter, Gateway,
- DBUS_TYPE_STRING, gateway);
-}
+ addr.s_addr = peer-lease_ip;
+ inet_ntop(AF_INET, addr, trans, INET_ADDRSTRLEN);
-static void append_ipv4(DBusMessageIter *iter, void *user_data)
-{
- struct connman_peer *peer = user_data;
-
- if (!is_connected(peer))
- return;
+ local = __connman_ippool_get_gateway(peer-ip_pool);
+ remote = trans;
+ } else if (peer-ipconfig) {
+ local = __connman_ipconfig_get_local(peer-ipconfig);
+ remote = __connman_ipconfig_get_gateway(peer-ipconfig);
+ }
- if (peer-connection_master)
- append_dhcp_server_ipv4(iter, peer);
- else if (peer-ipconfig)
- __connman_ipconfig_append_ipv4(peer-ipconfig, iter);
+ connman_dbus_dict_append_basic(iter, Local,
+ DBUS_TYPE_STRING, local);
+ connman_dbus_dict_append_basic(iter, Remote,
+ DBUS_TYPE_STRING, remote);
}
static void append_peer_service(DBusMessageIter *iter,
--
2.0.4
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH 1/6] doc: Improve Peer's API about local and remote IP address
ConnMan will ensure to provide the local and remote addresses of the
connected peer.
---
doc/peer-api.txt | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/doc/peer-api.txt b/doc/peer-api.txt
index e29eb6e..cc094ff 100644
--- a/doc/peer-api.txt
+++ b/doc/peer-api.txt
@@ -50,13 +50,15 @@ Properties string State [readonly] [experimental]
dict IPv4 [readonly] [experimental]
- string Address [readonly]
+ string Local [readonly]
- The current configured IPv4 address.
+ The current peer's local configured IPv4
+ address.
- string Netmask [readonly]
+ string Remote [readonly]
- The current configured IPv4 netmask.
+ The current peer's remote configured IPv4
+ address.
array{dict} Services [readonly] [experimental]
--
2.0.4
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH 3/6] gsupplicant: Add a getter for the Peer's interface address
This will get the distant MAC address of the Peer.
---
gsupplicant/gsupplicant.h | 1 +
gsupplicant/supplicant.c | 9 -
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/gsupplicant/gsupplicant.h b/gsupplicant/gsupplicant.h
index e49aaa6..97c804a 100644
--- a/gsupplicant/gsupplicant.h
+++ b/gsupplicant/gsupplicant.h
@@ -326,6 +326,7 @@ GSupplicantInterface
*g_supplicant_peer_get_interface(GSupplicantPeer *peer);
const char *g_supplicant_peer_get_path(GSupplicantPeer *peer);
const char *g_supplicant_peer_get_identifier(GSupplicantPeer *peer);
const void *g_supplicant_peer_get_device_address(GSupplicantPeer *peer);
+const void *g_supplicant_peer_get_iface_address(GSupplicantPeer *peer);
const char *g_supplicant_peer_get_name(GSupplicantPeer *peer);
const unsigned char *g_supplicant_peer_get_widi_ies(GSupplicantPeer *peer,
int *length);
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index 909a617..060a4df 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -1079,6 +1079,14 @@ const void
*g_supplicant_peer_get_device_address(GSupplicantPeer *peer)
return peer-device_address;
}
+const void *g_supplicant_peer_get_iface_address(GSupplicantPeer *peer)
+{
+ if (!peer)
+ return NULL;
+
+ return peer-iface_address;
+}
+
const char *g_supplicant_peer_get_name(GSupplicantPeer *peer)
{
if (!peer)
@@ -2838,7 +2846,6 @@ static void group_sig_property(const char *key,
DBusMessageIter *iter,
if (len == ETH_ALEN)
memcpy(data-iface_address, dev_addr, len);
-
} else if (g_strcmp0(key, role) == 0) {
const char *str = NULL;
--
2.0.4
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH 5/6] wifi: Set the MAC address of the distant peer
This will be useful in the core to relate the peer and its dhcp lease, in case the local peer ends up as the dhcp server. --- plugins/wifi.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/plugins/wifi.c b/plugins/wifi.c index 9357b92..68ed5d0 100644 --- a/plugins/wifi.c +++ b/plugins/wifi.c @@ -2787,9 +2787,8 @@ static void peer_changed(GSupplicantPeer *peer, GSupplicantPeerState state) p_state = CONNMAN_PEER_STATE_IDLE; break; case G_SUPPLICANT_PEER_GROUP_JOINED: - if (!g_supplicant_peer_is_in_a_group(peer)) - break; - p_state = CONNMAN_PEER_STATE_READY; + connman_peer_set_iface_address(connman_peer, + g_supplicant_peer_get_iface_address(peer)); break; case G_SUPPLICANT_PEER_GROUP_DISCONNECTED: p_state = CONNMAN_PEER_STATE_IDLE; -- 2.0.4 ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH 2/6] gdhcp: Call a function to tell about the given IP for a MAC
Once a lease is offered, tell about its IP/MAC through a callback. This
will be useful in peer.c to know about distant peer's IP when our local
one ends up as the dhcp server.
---
gdhcp/gdhcp.h | 5 +
gdhcp/server.c | 13 +
2 files changed, 18 insertions(+)
diff --git a/gdhcp/gdhcp.h b/gdhcp/gdhcp.h
index ac24454..7525eb2 100644
--- a/gdhcp/gdhcp.h
+++ b/gdhcp/gdhcp.h
@@ -201,6 +201,9 @@ typedef enum {
typedef void (*GDHCPSaveLeaseFunc) (unsigned char *mac,
unsigned int nip, unsigned int expire);
+
+typedef void (*GDHCPLeaseAddedCb) (unsigned char *mac, uint32_t ip);
+
struct _GDHCPServer;
typedef struct _GDHCPServer GDHCPServer;
@@ -223,6 +226,8 @@ void g_dhcp_server_set_lease_time(GDHCPServer *dhcp_server,
unsigned int lease_time);
void g_dhcp_server_set_save_lease(GDHCPServer *dhcp_server,
GDHCPSaveLeaseFunc func, gpointer user_data);
+void g_dhcp_server_set_lease_added_cb(GDHCPServer *dhcp_server,
+ GDHCPLeaseAddedCb cb);
int dhcp_get_random(uint64_t *val);
void dhcp_cleanup_random(void);
diff --git a/gdhcp/server.c b/gdhcp/server.c
index aa40488..8561dd3 100644
--- a/gdhcp/server.c
+++ b/gdhcp/server.c
@@ -65,6 +65,7 @@ struct _GDHCPServer {
GHashTable *nip_lease_hash;
GHashTable *option_hash; /* Options send to client */
GDHCPSaveLeaseFunc save_lease_func;
+ GDHCPLeaseAddedCb lease_added_cb;
GDHCPDebugFunc debug_func;
gpointer debug_data;
};
@@ -213,6 +214,9 @@ static struct dhcp_lease *add_lease(GDHCPServer
*dhcp_server, uint32_t expire,
g_hash_table_insert(dhcp_server-nip_lease_hash,
GINT_TO_POINTER((int) lease-lease_nip), lease);
+ if (dhcp_server-lease_added_cb)
+ dhcp_server-lease_added_cb(lease-lease_mac, yiaddr);
+
return lease;
}
@@ -814,6 +818,15 @@ void g_dhcp_server_set_save_lease(GDHCPServer *dhcp_server,
dhcp_server-save_lease_func = func;
}
+void g_dhcp_server_set_lease_added_cb(GDHCPServer *dhcp_server,
+ GDHCPLeaseAddedCb cb)
+{
+ if (!dhcp_server)
+ return;
+
+ dhcp_server-lease_added_cb = cb;
+}
+
GDHCPServer *g_dhcp_server_ref(GDHCPServer *dhcp_server)
{
if (!dhcp_server)
--
2.0.4
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH 4/6] peer: Add a holder for peer's distant MAC address
Wifi plugin will be able to set it through a simple function. This will
be useful to match the dhcp server lease with the distant peer.
---
include/peer.h | 2 ++
src/peer.c | 9 +
2 files changed, 11 insertions(+)
diff --git a/include/peer.h b/include/peer.h
index 8a690f5..8066393 100644
--- a/include/peer.h
+++ b/include/peer.h
@@ -64,6 +64,8 @@ void connman_peer_unref_debug(struct connman_peer *peer,
const char *connman_peer_get_identifier(struct connman_peer *peer);
void connman_peer_set_name(struct connman_peer *peer, const char *name);
+void connman_peer_set_iface_address(struct connman_peer *peer,
+ const unsigned char *iface_address);
void connman_peer_set_device(struct connman_peer *peer,
struct connman_device *device);
struct connman_device *connman_peer_get_device(struct connman_peer *peer);
diff --git a/src/peer.c b/src/peer.c
index caff70c..81fc1d2 100644
--- a/src/peer.c
+++ b/src/peer.c
@@ -27,6 +27,7 @@
#include ctype.h
#include gdbus.h
#include gdhcp/gdhcp.h
+#include netinet/if_ether.h
#include connman/agent.h
@@ -54,6 +55,7 @@ struct connman_peer {
int refcount;
struct connman_device *device;
struct connman_device *sub_device;
+ unsigned char *iface_address[ETH_ALEN];
char *identifier;
char *name;
char *path;
@@ -725,6 +727,13 @@ void connman_peer_set_name(struct connman_peer *peer,
const char *name)
peer-name = g_strdup(name);
}
+void connman_peer_set_iface_address(struct connman_peer *peer,
+ const unsigned char *iface_address)
+{
+ memset(peer-iface_address, 0, ETH_ALEN);
+ memcpy(peer-iface_address, iface_address, ETH_ALEN);
+}
+
void connman_peer_set_device(struct connman_peer *peer,
struct connman_device *device)
{
--
2.0.4
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH 2/6] gdhcp: Call a function to tell about the given IP for a MAC
Once a lease is offered, tell about its IP/MAC through a callback. This
will be useful in peer.c to know about distant peer's IP when our local
one ends up as the dhcp server.
---
gdhcp/gdhcp.h | 5 +
gdhcp/server.c | 13 +
2 files changed, 18 insertions(+)
diff --git a/gdhcp/gdhcp.h b/gdhcp/gdhcp.h
index ac24454..7525eb2 100644
--- a/gdhcp/gdhcp.h
+++ b/gdhcp/gdhcp.h
@@ -201,6 +201,9 @@ typedef enum {
typedef void (*GDHCPSaveLeaseFunc) (unsigned char *mac,
unsigned int nip, unsigned int expire);
+
+typedef void (*GDHCPLeaseAddedCb) (unsigned char *mac, uint32_t ip);
+
struct _GDHCPServer;
typedef struct _GDHCPServer GDHCPServer;
@@ -223,6 +226,8 @@ void g_dhcp_server_set_lease_time(GDHCPServer *dhcp_server,
unsigned int lease_time);
void g_dhcp_server_set_save_lease(GDHCPServer *dhcp_server,
GDHCPSaveLeaseFunc func, gpointer user_data);
+void g_dhcp_server_set_lease_added_cb(GDHCPServer *dhcp_server,
+ GDHCPLeaseAddedCb cb);
int dhcp_get_random(uint64_t *val);
void dhcp_cleanup_random(void);
diff --git a/gdhcp/server.c b/gdhcp/server.c
index aa40488..8561dd3 100644
--- a/gdhcp/server.c
+++ b/gdhcp/server.c
@@ -65,6 +65,7 @@ struct _GDHCPServer {
GHashTable *nip_lease_hash;
GHashTable *option_hash; /* Options send to client */
GDHCPSaveLeaseFunc save_lease_func;
+ GDHCPLeaseAddedCb lease_added_cb;
GDHCPDebugFunc debug_func;
gpointer debug_data;
};
@@ -213,6 +214,9 @@ static struct dhcp_lease *add_lease(GDHCPServer
*dhcp_server, uint32_t expire,
g_hash_table_insert(dhcp_server-nip_lease_hash,
GINT_TO_POINTER((int) lease-lease_nip), lease);
+ if (dhcp_server-lease_added_cb)
+ dhcp_server-lease_added_cb(lease-lease_mac, yiaddr);
+
return lease;
}
@@ -814,6 +818,15 @@ void g_dhcp_server_set_save_lease(GDHCPServer *dhcp_server,
dhcp_server-save_lease_func = func;
}
+void g_dhcp_server_set_lease_added_cb(GDHCPServer *dhcp_server,
+ GDHCPLeaseAddedCb cb)
+{
+ if (!dhcp_server)
+ return;
+
+ dhcp_server-lease_added_cb = cb;
+}
+
GDHCPServer *g_dhcp_server_ref(GDHCPServer *dhcp_server)
{
if (!dhcp_server)
--
2.0.4
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH 3/6] gsupplicant: Add a getter for the Peer's interface address
This will get the distant MAC address of the Peer.
---
gsupplicant/gsupplicant.h | 1 +
gsupplicant/supplicant.c | 9 -
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/gsupplicant/gsupplicant.h b/gsupplicant/gsupplicant.h
index e49aaa6..97c804a 100644
--- a/gsupplicant/gsupplicant.h
+++ b/gsupplicant/gsupplicant.h
@@ -326,6 +326,7 @@ GSupplicantInterface
*g_supplicant_peer_get_interface(GSupplicantPeer *peer);
const char *g_supplicant_peer_get_path(GSupplicantPeer *peer);
const char *g_supplicant_peer_get_identifier(GSupplicantPeer *peer);
const void *g_supplicant_peer_get_device_address(GSupplicantPeer *peer);
+const void *g_supplicant_peer_get_iface_address(GSupplicantPeer *peer);
const char *g_supplicant_peer_get_name(GSupplicantPeer *peer);
const unsigned char *g_supplicant_peer_get_widi_ies(GSupplicantPeer *peer,
int *length);
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index 909a617..060a4df 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -1079,6 +1079,14 @@ const void
*g_supplicant_peer_get_device_address(GSupplicantPeer *peer)
return peer-device_address;
}
+const void *g_supplicant_peer_get_iface_address(GSupplicantPeer *peer)
+{
+ if (!peer)
+ return NULL;
+
+ return peer-iface_address;
+}
+
const char *g_supplicant_peer_get_name(GSupplicantPeer *peer)
{
if (!peer)
@@ -2838,7 +2846,6 @@ static void group_sig_property(const char *key,
DBusMessageIter *iter,
if (len == ETH_ALEN)
memcpy(data-iface_address, dev_addr, len);
-
} else if (g_strcmp0(key, role) == 0) {
const char *str = NULL;
--
2.0.4
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH 4/6] peer: Add a holder for peer's distant MAC address
Wifi plugin will be able to set it through a simple function. This will
be useful to match the dhcp server lease with the distant peer.
---
include/peer.h | 2 ++
src/peer.c | 9 +
2 files changed, 11 insertions(+)
diff --git a/include/peer.h b/include/peer.h
index 8a690f5..8066393 100644
--- a/include/peer.h
+++ b/include/peer.h
@@ -64,6 +64,8 @@ void connman_peer_unref_debug(struct connman_peer *peer,
const char *connman_peer_get_identifier(struct connman_peer *peer);
void connman_peer_set_name(struct connman_peer *peer, const char *name);
+void connman_peer_set_iface_address(struct connman_peer *peer,
+ const unsigned char *iface_address);
void connman_peer_set_device(struct connman_peer *peer,
struct connman_device *device);
struct connman_device *connman_peer_get_device(struct connman_peer *peer);
diff --git a/src/peer.c b/src/peer.c
index caff70c..81fc1d2 100644
--- a/src/peer.c
+++ b/src/peer.c
@@ -27,6 +27,7 @@
#include ctype.h
#include gdbus.h
#include gdhcp/gdhcp.h
+#include netinet/if_ether.h
#include connman/agent.h
@@ -54,6 +55,7 @@ struct connman_peer {
int refcount;
struct connman_device *device;
struct connman_device *sub_device;
+ unsigned char *iface_address[ETH_ALEN];
char *identifier;
char *name;
char *path;
@@ -725,6 +727,13 @@ void connman_peer_set_name(struct connman_peer *peer,
const char *name)
peer-name = g_strdup(name);
}
+void connman_peer_set_iface_address(struct connman_peer *peer,
+ const unsigned char *iface_address)
+{
+ memset(peer-iface_address, 0, ETH_ALEN);
+ memcpy(peer-iface_address, iface_address, ETH_ALEN);
+}
+
void connman_peer_set_device(struct connman_peer *peer,
struct connman_device *device)
{
--
2.0.4
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH 5/6] wifi: Set the MAC address of the distant peer
This will be useful in the core to relate the peer and its dhcp lease, in case the local peer ends up as the dhcp server. --- plugins/wifi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/plugins/wifi.c b/plugins/wifi.c index 9357b92..ddb07e0 100644 --- a/plugins/wifi.c +++ b/plugins/wifi.c @@ -2789,6 +2789,8 @@ static void peer_changed(GSupplicantPeer *peer, GSupplicantPeerState state) case G_SUPPLICANT_PEER_GROUP_JOINED: if (!g_supplicant_peer_is_in_a_group(peer)) break; + connman_peer_set_iface_address(connman_peer, + g_supplicant_peer_get_iface_address(peer)); p_state = CONNMAN_PEER_STATE_READY; break; case G_SUPPLICANT_PEER_GROUP_DISCONNECTED: -- 2.0.4 ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH 1/6] doc: Improve Peer's API about local and remote IP address
ConnMan will ensure to provide the local and remote addresses of the
connected peer.
---
doc/peer-api.txt | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/doc/peer-api.txt b/doc/peer-api.txt
index e29eb6e..cc094ff 100644
--- a/doc/peer-api.txt
+++ b/doc/peer-api.txt
@@ -50,13 +50,15 @@ Properties string State [readonly] [experimental]
dict IPv4 [readonly] [experimental]
- string Address [readonly]
+ string Local [readonly]
- The current configured IPv4 address.
+ The current peer's local configured IPv4
+ address.
- string Netmask [readonly]
+ string Remote [readonly]
- The current configured IPv4 netmask.
+ The current peer's remote configured IPv4
+ address.
array{dict} Services [readonly] [experimental]
--
2.0.4
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH 6/6] peer: Changed IPv4 property to provide local and remote IP address
Thus it is possible to know our local IP as well as the Peer's remote IP
to start contacting it directly.
---
src/peer.c | 67 +++---
1 file changed, 42 insertions(+), 25 deletions(-)
diff --git a/src/peer.c b/src/peer.c
index 81fc1d2..8a9844b 100644
--- a/src/peer.c
+++ b/src/peer.c
@@ -66,9 +66,12 @@ struct connman_peer {
bool connection_master;
struct connman_ippool *ip_pool;
GDHCPServer *dhcp_server;
+ uint32_t lease_ip;
GSList *services;
};
+static void settings_changed(struct connman_peer *peer);
+
static void stop_dhcp_server(struct connman_peer *peer)
{
DBG();
@@ -88,6 +91,24 @@ static void dhcp_server_debug(const char *str, void *data)
connman_info(%s: %s\n, (const char *) data, str);
}
+static void lease_added(unsigned char *mac, uint32_t ip)
+{
+ GList *list, *start;
+
+ start = list = g_hash_table_get_values(peers_table);
+ for (; list; list = list-next) {
+ struct connman_peer *temp = list-data;
+
+ if (!memcmp(temp-iface_address, mac, ETH_ALEN)) {
+ temp-lease_ip = ip;
+ settings_changed(temp);
+ break;
+ }
+ }
+
+ g_list_free(start);
+}
+
static gboolean dhcp_server_started(gpointer data)
{
struct connman_peer *peer = data;
@@ -148,6 +169,8 @@ static int start_dhcp_server(struct connman_peer *peer)
g_dhcp_server_set_option(peer-dhcp_server, G_DHCP_DNS_SERVER, NULL);
g_dhcp_server_set_ip_range(peer-dhcp_server, start_ip, end_ip);
+ g_dhcp_server_set_lease_added_cb(peer-dhcp_server, lease_added);
+
err = g_dhcp_server_start(peer-dhcp_server);
if (err 0)
goto error;
@@ -255,39 +278,33 @@ static bool allow_property_changed(struct connman_peer
*peer)
return true;
}
-static void append_dhcp_server_ipv4(DBusMessageIter *iter, void *user_data)
+static void append_ipv4(DBusMessageIter *iter, void *user_data)
{
struct connman_peer *peer = user_data;
- const char *str = dhcp;
- const char *gateway;
- const char *subnet;
+ const char *local = ;
+ const char *remote = ;
- if (!peer-ip_pool)
+ if (!is_connected(peer))
return;
- gateway = __connman_ippool_get_gateway(peer-ip_pool);
- subnet = __connman_ippool_get_subnet_mask(peer-ip_pool);
+ if (peer-connection_master) {
+ char trans[INET_ADDRSTRLEN+1] = {};
+ struct in_addr addr;
- connman_dbus_dict_append_basic(iter, Method, DBUS_TYPE_STRING, str);
- connman_dbus_dict_append_basic(iter, Address,
- DBUS_TYPE_STRING, gateway);
- connman_dbus_dict_append_basic(iter, Netmask,
- DBUS_TYPE_STRING, subnet);
- connman_dbus_dict_append_basic(iter, Gateway,
- DBUS_TYPE_STRING, gateway);
-}
+ addr.s_addr = peer-lease_ip;
+ inet_ntop(AF_INET, addr, trans, INET_ADDRSTRLEN);
-static void append_ipv4(DBusMessageIter *iter, void *user_data)
-{
- struct connman_peer *peer = user_data;
-
- if (!is_connected(peer))
- return;
+ local = __connman_ippool_get_gateway(peer-ip_pool);
+ remote = trans;
+ } else if (peer-ipconfig) {
+ local = __connman_ipconfig_get_local(peer-ipconfig);
+ remote = __connman_ipconfig_get_gateway(peer-ipconfig);
+ }
- if (peer-connection_master)
- append_dhcp_server_ipv4(iter, peer);
- else if (peer-ipconfig)
- __connman_ipconfig_append_ipv4(peer-ipconfig, iter);
+ connman_dbus_dict_append_basic(iter, Local,
+ DBUS_TYPE_STRING, local);
+ connman_dbus_dict_append_basic(iter, Remote,
+ DBUS_TYPE_STRING, remote);
}
static void append_peer_service(DBusMessageIter *iter,
--
2.0.4
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: WiFi can connect with wrong WEP64 and allocate invalid IP (CM-343)
Hi Olivier, Yes your assumption is right, this is how WEP is supposed to behave. The people who opened this bug have no clue how WEP works obviously. There is no proper (aka: specified) way to know if a connection has successfully worked or not with WEP. And if there would be a way, it would be up to wpa_supplicant to tell that to ConnMan. The given IP is not invalid, it's a link local IP. That's the fallback IP given by DHCP when this one does not get any lease: which could happen if the network does not provide any DHCP server. In the bug context, it's just an indirect relation with the wrong WEP settings. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] service: Send changed type signal
Hi,
NACK.
From: Chengyi Zhao chengyi1.z...@archermind.com
---
src/service.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/src/service.c b/src/service.c
index 9bba227..6c8b2a2 100644
--- a/src/service.c
+++ b/src/service.c
@@ -183,7 +183,7 @@ const char *__connman_service_type2string(enum
connman_service_type type)
{
switch (type) {
case CONNMAN_SERVICE_TYPE_UNKNOWN:
- break;
+ return unknown;
No, if a service type is unknown this functions returns NULL, and that's it.
You will never ever get a service through service list which owns a type
unknown.
Or if it is, there will be serious bug around.
case CONNMAN_SERVICE_TYPE_SYSTEM:
return system;
case CONNMAN_SERVICE_TYPE_ETHERNET:
@@ -1423,9 +1423,30 @@ bool __connman_service_index_is_default(int index)
return __connman_service_get_index(service) == index;
}
+static void type_changed(struct connman_service *service)
+{
+ const char *str;
+
+ if (!service)
+ return;
+
+ if (!allow_property_changed(service))
+ return;
+
+ str = __connman_service_type2string(service-type);
+ if (!str)
+ return;
+
+ connman_dbus_property_changed_basic(service-path,
+ CONNMAN_SERVICE_INTERFACE, Type,
+ DBUS_TYPE_STRING, str);
+}
The type of a service never changes, this signal is useless.
+
static void default_changed(void)
{
struct connman_service *service = __connman_service_get_default();
+ enum connman_service_type old_type = CONNMAN_SERVICE_TYPE_UNKNOWN;
+ enum connman_service_type new_type = CONNMAN_SERVICE_TYPE_UNKNOWN;
if (service == current_default)
return;
@@ -1436,6 +1457,11 @@ static void default_changed(void)
__connman_service_timeserver_changed(current_default, NULL);
+ if (current_default)
+ old_type = current_default-type;
+ if (service)
+ new_type = service-type;
+
current_default = service;
if (service) {
@@ -1448,6 +1474,9 @@ static void default_changed(void)
}
__connman_notifier_default_changed(service);
+
+ if (old_type != new_type)
+ type_changed(service);
}
This does not make any sense.
The type of the previous default service or the new one has not changed.
Sure, the previous service could have a different type than the new one,
but themselves
they haven't changed their type.
Tomasz
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: Error reconnecting to a hidden AP.
Hi Joaquim, In wpa_supplicant, you're referring the option CONFIG_BGSCAN_SIMPLE, isn't it? No, that one is fine and useful for roaming. I was referring to CONFIG_AUTOSCAN_EXPONENTIAL If you don't have it, then it will be fine on that level. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Error reconnecting to a hidden AP.
Hi Joaquim, Finally We've fixed the issue that connman was not reconnecting to hidden wifi's. These are the list of changes that we've done: 1 - When compiling wpa_supplicant, in the config file disable the options: CONFIG_AUTOSCAN_EXPONENTIAL CONFIG_AUTOSCAN_PERIODIC CONFIG_BGSCAN_SIMPLE From wpa_supplicant config documentation, if any module of autoscan is enabled (periodic or exponential) autoscan is enabled. (suggested by Tomasz). Keep CONFIG_BGSCAN_SIMPLE, that one is something you want if you are roaming. In your case, only the 2 first ones are the one you need to disable. 2 - Change the contents of /etc/wpa_supplicant.conf file to file ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=0 file/ IMO, in the connman documentation, It should also be specified the contents of wpa_supplicant.conf file. No because there is no need of any wpa_supplicant.conf when wpa_supplicant runs with DBus. This configuration file is relevant only when wpa_supplicant is running with its own unix socket interface used for IPC, usually for stand-alone usage via wpa_cli or others. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Error reconnecting to a hidden AP.
Hi Joaquim, Which version of ConnMan are your using? Also, do you have wpa_supplicant built with autoscan support? If so, rebuild it without that option. 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. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Does ConnMan API suport WiFi Active scan passive scan?
Hi, When I use both connman APIs and wpe_supplicant APIs, is connman designed not to cause contradiction? As long as you don't mess up with anything else but scanning in wpa_supplicant, it should be fine. Doing more won't work. wpa_supplicant does not know who's right to do A when another wants B, thus connman in our case is supposed to be the only one handling all. However, as I said above, playing with wpa_supplicant's API directly for scanning only should not affect ConnMan: it will get the results, so once done you will be able to use those results through ConnMan. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: crash while cancelling an in-progress connection
Hi, I have a situation where the user has sent a connection to an open AP. Before connman returns that the connection has completed, the user attempts to cancel the connection. According to the documentation the net.connman.Service.Disconnect can also be used to abort a previous connection attempt via the Connect method. The issue is that when I attempt this, that after I make the dbus call to disconnect, and before the disconnect call returns I get a segmentation fault. The stack is hammered enough that the only traceback information is that it happens in libdbus-1.so.3. This only happens when I try to cancel a connection on an open AP. Cancelling all other attempts have worked to this point. Is there something that I need to set a guard around so this doesn't happen? What version of connman and wpa_supplicant are you using? Also, please provide any relevant logs you could have (the backtrace and so on). Try running connman this way: CONNMAN_SUPPLICANT_DEBUG=1 connmand -n -d connman_log.txt and paste the logs somewhere. Thanks, Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: How to Identify the chosen association type of Wifi AP
Hi Frederic, Is there such information about WPS sequence initiated by user on the remote AP ? The theory: In case of WPS PBC, ConnMan is supposed to handle that automatically, which means if the AP - related to the service the user wants to connect to - has started a WPS PBC sequence, ConnMan will detect it and silently go with it, without requesting anything through the Agent. In case of WPS PIN, we don't do anything but doing the usual Agent call, which lets the user doing the right thing. We don't provide details. That's something we should/could fix in a futur rewrite of the API (ConnMan 2.0?) The practice: It's unfortunately not unusual to get buggy AP on WPS. Like during the WPS process, some tend to forget to advertize it - through the IEs - in all of their frames (so if we catch and analyze a wrong one: our logic does not apply). And of course, wpa_supplicant or ConnMan could have a bug. Depends on what you are experiencing. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Does ConnMan API suport WiFi Active scan passive scan?
Hi, For our automotive embedded project , we are trying to use ConnMan to take care of all the basic networking. Does ConnMan API support Active scan Passive scan? Would that be possible to execute only Active scan? ConnMan itself does not run any scan, it requests wpa_supplicant to do so. And it actually requests active or passive scan depending on the context: On the Scan() method it exposes through Technology API: - if there is no known networks configured, it will do only passive scans - if there is 1+ known networks configured, it will first do an active scan on the last connected one, and then a passive scan. Exception: if there is known hidden networks, it will do an active scan for those before the passive one. There are also behaviors on automatic scans for which I don't give details here. Afaik we don't plan to add parameters to Scan() to it would be possible for the user to do a specific active scan. Scanning policies are already quite complicated, to fit all uses-cases, proposing such feature would just bring a bit of this complexity above ConnMan. This would go against the idea, where ConnMan is here to simplify such things for the user and not just wrap wifi features in an API. Br, Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
