Re: Broadcom's proprietary wl driver detected as ethernet
"Raghavendra. S" writes: > [Raghu]: I too met with this some time back. Assuming you enbled wifi > during compilation, following was the issue in my case. When I killed > connman. for some reason plugins directory (/usr/lib/connman/ > plugins/*) was getting deleted. So next time when I started connman it > started without throwing any error. Because of this connman detected > wifi interface as ethernet interface and all wifi functionalities were > disabled for the interface. > > So you better check once whether you have /usr/lib/connman/plugins/*. > Otherwise reinstall and try. Thanks but this wasn't the issue because wifi was working with an usb stick using ar9170. -- Kalle Valo ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: Broadcom's proprietary wl driver detected as ethernet
Samuel Ortiz writes: > Hi Kalle, Hi Samuel, > On Thu, Oct 14, 2010 at 08:25:17PM +0300, Kalle Valo wrote: >> >> I noticed that with the latest connman git version Broadcom's >> proprietary wl driver is detected as an ethernet device, not a wifi >> device. This was working few weeks back and my main suspect is the udev >> removal. > > Could you please pull the latest ConnMan bits and check if it's working with > the wl crap^Wdriver ? Yes, it's working now. Thanks a lot for fixing this. -- Kalle Valo ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: Service provisioning interface. Was: [PATCH] Add support for EAP configuration via service-api
Hi Lucio, > Back to service provisioning (EAP configuration on the fly). > > So now I'll have some time to work on this. > > I think the easiest way to do this, is to add support for inotify for > .config dir, and then add a Method to upload .config files that will > be read on the fly. in simple terms speaking, yes inotify and a D-Bus API to load and remove provisioning information is a good idea. > My plan is to: > 1. Add support to inotify, to read provisioning files on the fly. Yes, that is a good idea. > 2. (What do you think???) Convert the provisioning file to XML?? Don't think this is a good idea since the INI style keyfiles are so simple that it is pretty nice. What benefit would XML give over key files. > 3. Add new methods to the Manager Interface to Upload and Export > services configuration. Yes, please send a proposal that can be discussed in a separate thread when you are starting this. Also adding TODO items with your owner to the TODO file is a good idea. Please send a patch for it. > 4. Add support for other service types as well (today only wifi is > supported) for ipv4/6 configuration options, APN setting, etc. I am fine with this. Currently we only do WiFi and VPN, but we are not limited to others. Regards Marcel ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: Suspend/Resume indications
Hi, > As you might be aware modem, supports suspend/resume indications in case > of cellular networks. > > Whether connman supports these? that is something that needs to be done inside oFono first. Regards Marcel ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [PATCH 1/1] pacrunner: Protect shared data between pacrunner threads.
Hi Mohamed, > This more to start discussion on protect shared data. I am > not really familiar with js data so what this patch tried > to protect is the js object, if thread is running hold > the main thread to wait until the js thread finish. mean thread > only block once want to destroy and create new js object. I looked at this and I don't think we need it. I am protecting the proxy configuration with a reference count. And the locking inside D-Bus library is enough for sending out the pending D-Bus result when the JS execution finished. Regards Marcel ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
[PATCH 1/1] pacrunner: Protect shared data between pacrunner threads.
This more to start discussion on protect shared data. I am
not really familiar with js data so what this patch tried
to protect is the js object, if thread is running hold
the main thread to wait until the js thread finish. mean thread
only block once want to destroy and create new js object.
---
src/mozjs.c |9 -
src/pacrunner.h |3 +++
src/proxy.c | 31 +++
3 files changed, 42 insertions(+), 1 deletions(-)
diff --git a/src/mozjs.c b/src/mozjs.c
index de40c3f..015108e 100644
--- a/src/mozjs.c
+++ b/src/mozjs.c
@@ -214,8 +214,12 @@ const char *__pacrunner_mozjs_execute(const char *url,
const char *host)
DBG("url %s host %s", url, host);
- if (jsctx == NULL)
+ pacrunner_proxy_lock(current_proxy);
+
+ if (jsctx == NULL){
+ pacrunner_proxy_unlock(current_proxy);
return "DIRECT";
+ }
tmpurl = JS_strdup(jsctx, url);
tmphost = JS_strdup(jsctx, host);
@@ -223,6 +227,7 @@ const char *__pacrunner_mozjs_execute(const char *url,
const char *host)
if (tmpurl == NULL || tmphost == NULL) {
JS_free(jsctx, tmphost);
JS_free(jsctx, tmpurl);
+ pacrunner_proxy_unlock(current_proxy);
return NULL;
}
@@ -242,8 +247,10 @@ const char *__pacrunner_mozjs_execute(const char *url,
const char *host)
if (result) {
answer = JS_GetStringBytes(JS_ValueToString(jsctx, rval));
+ pacrunner_proxy_unlock(current_proxy);
return answer;
}
+ pacrunner_proxy_unlock(current_proxy);
return NULL;
}
diff --git a/src/pacrunner.h b/src/pacrunner.h
index 0dce86d..429174b 100644
--- a/src/pacrunner.h
+++ b/src/pacrunner.h
@@ -81,6 +81,9 @@ void pacrunner_proxy_unref(struct pacrunner_proxy *proxy);
const char *pacrunner_proxy_get_interface(struct pacrunner_proxy *proxy);
const char *pacrunner_proxy_get_script(struct pacrunner_proxy *proxy);
+void pacrunner_proxy_lock(struct pacrunner_proxy *proxy);
+void pacrunner_proxy_unlock(struct pacrunner_proxy *proxy);
+
int pacrunner_proxy_set_method(struct pacrunner_proxy *proxy,
enum pacrunner_proxy_method method);
int pacrunner_proxy_set_direct(struct pacrunner_proxy *proxy);
diff --git a/src/proxy.c b/src/proxy.c
index 1838eba..7b91187 100644
--- a/src/proxy.c
+++ b/src/proxy.c
@@ -35,6 +35,7 @@ struct pacrunner_proxy {
char *url;
char *script;
char *server;
+ GMutex *mutex;
};
struct pacrunner_proxy *pacrunner_proxy_create(const char *interface)
@@ -51,6 +52,7 @@ struct pacrunner_proxy *pacrunner_proxy_create(const char
*interface)
proxy->interface = g_strdup(interface);
proxy->method = PACRUNNER_PROXY_METHOD_UNKNOWN;
+ proxy->mutex = g_mutex_new();
DBG("proxy %p", proxy);
@@ -93,10 +95,17 @@ void pacrunner_proxy_unref(struct pacrunner_proxy *proxy)
if (g_atomic_int_dec_and_test(&proxy->refcount) == FALSE)
return;
+ g_mutex_lock(proxy->mutex);
+
__pacrunner_mozjs_set_proxy(NULL);
reset_proxy(proxy);
+ g_mutex_unlock(proxy->mutex);
+
+ g_mutex_free(proxy->mutex);
+ proxy->mutex = NULL;
+
g_free(proxy->interface);
g_free(proxy);
}
@@ -160,11 +169,15 @@ static void download_callback(char *content, void
*user_data)
goto done;
}
+ g_mutex_lock(proxy->mutex);
+
g_free(proxy->script);
proxy->script = content;
__pacrunner_mozjs_set_proxy(proxy);
+ g_mutex_unlock(proxy->mutex);
+
done:
pacrunner_proxy_unref(proxy);
}
@@ -182,11 +195,13 @@ int pacrunner_proxy_set_auto(struct pacrunner_proxy
*proxy, const char *url)
if (err < 0)
return err;
+ g_mutex_lock(proxy->mutex);
g_free(proxy->url);
proxy->url = g_strdup(url);
g_free(proxy->script);
proxy->script = NULL;
+ g_mutex_unlock(proxy->mutex);
pacrunner_proxy_ref(proxy);
@@ -220,10 +235,12 @@ int pacrunner_proxy_set_script(struct pacrunner_proxy
*proxy,
g_free(proxy->url);
proxy->url = NULL;
+ g_mutex_lock(proxy->mutex);
g_free(proxy->script);
proxy->script = g_strdup(script);
__pacrunner_mozjs_set_proxy(proxy);
+ g_mutex_unlock(proxy->mutex);
return 0;
}
@@ -245,14 +262,28 @@ int pacrunner_proxy_set_server(struct pacrunner_proxy
*proxy,
if (err < 0)
return err;
+ g_mutex_lock(proxy->mutex);
g_free(proxy->server);
proxy->server = g_strdup(server);
__pacrunner_mozjs_set_proxy(proxy);
+ g_mutex_lock(proxy->mutex);
return 0;
}
+void pacrunner_proxy_lock(struct pacrunner_proxy *proxy)
+{
+ if (proxy!= NULL)
+ g_mutex_lock(proxy->mutex);
+}
+
+void pacr
Suspend/Resume indications
Hi, As you might be aware modem, supports suspend/resume indications in case of cellular networks. Whether connman supports these? -- Regards & Thanks Raghavendra. S 9880329621 ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
[PATCH 1/1] Extract content from HTTP response.
This patch add HTTP parsing to gweb, it will parse the HTTP
response then send the body to caller. This patch also add
support to chunk encoding.
---
gweb/gweb.c | 314 +-
gweb/gweb.h |3 +
tools/web-test.c | 18 +++-
3 files changed, 332 insertions(+), 3 deletions(-)
diff --git a/gweb/gweb.c b/gweb/gweb.c
index 39f8ecf..c3990c8 100644
--- a/gweb/gweb.c
+++ b/gweb/gweb.c
@@ -35,6 +35,39 @@
#include "gresolv.h"
#include "gweb.h"
+#define MAX_LINE_LEN 600
+#define MAX_CHUNK_LEN 17
+
+enum chunk_state {
+ CHUNK_SIZE,
+ CHUNK_R,
+ CHUNK_R_BODY,
+ CHUNK_N,
+ CHUNK_N_BODY,
+ CHUNK_DATA,
+};
+
+struct web_chunk_data {
+ enum chunk_state chunck_state;
+ int chunk_size;
+ int chunk_left;
+};
+
+struct web_data {
+ char line_buf[MAX_LINE_LEN];
+ int line_index;
+
+ unsigned long int total_len;
+ unsigned long int content_len;
+ unsigned long int http_status;
+
+ gboolean use_chunk;
+ gboolean header_ready;
+ gboolean done;
+
+ struct web_chunk_data chunk;
+};
+
struct web_session {
GWeb *web;
@@ -49,8 +82,11 @@ struct web_session {
guint resolv_action;
char *request;
+ GWebReceivedFunc received_func;
GWebResultFunc result_func;
gpointer result_data;
+
+ struct web_data data;
};
struct _GWeb {
@@ -191,12 +227,267 @@ gboolean g_web_add_nameserver(GWeb *web, const char
*address)
return TRUE;
}
+static void init_chunk_data(struct web_session *session)
+{
+ memset(session->data.line_buf, 0, MAX_LINE_LEN);
+ session->data.line_index = 0;
+
+ session->data.chunk.chunck_state = CHUNK_SIZE;
+ session->data.chunk.chunk_size = 0;
+ session->data.chunk.chunk_left = 0;
+}
+
+static void init_download_data(struct web_session *session)
+{
+
+ init_chunk_data(session);
+
+ session->data.http_status = 0;
+ session->data.total_len = 0;
+ session->data.content_len = 0;
+
+ session->data.use_chunk = FALSE;
+ session->data.header_ready = FALSE;
+ session->data.done = FALSE;
+}
+
+static int append_to_line(struct web_session *session, char *buf, int len)
+{
+ char *ptr;
+
+ if ((session->data.line_index + len) >= MAX_LINE_LEN)
+ return -EXFULL;
+
+ ptr = session->data.line_buf + session->data.line_index;
+ memcpy(ptr, buf, len);
+
+ session->data.line_index += len;
+ session->data.line_buf[session->data.line_index] = '\0';
+
+ return 0;
+}
+
+static int append_to_chunk_size(struct web_session *session, char *buf, int
len)
+{
+ if ((session->data.line_index + len) >= MAX_CHUNK_LEN)
+ return -EXFULL;
+
+ return append_to_line(session, buf, len);
+}
+
+static void send_client_payload(struct web_session *session, char *buf, int
len)
+{
+ if (session->received_func != NULL)
+ session->received_func(buf, len, session->result_data);
+}
+
+static int decode_chunked(struct web_session *session, char *buf, int len)
+{
+ int ret;
+ unsigned int counter;
+ struct web_data *data;
+
+ data = &session->data;
+ while (len > 0) {
+ switch (data->chunk.chunck_state) {
+ case CHUNK_SIZE:
+ if (g_ascii_isxdigit(*buf) == TRUE) {
+ ret = append_to_chunk_size(session, buf, 1);
+ if (ret != 0)
+ return ret;
+ } else {
+ ret = sscanf(session->data.line_buf,
+ "%x", &counter);
+ if (ret != 1)
+ return -EILSEQ;
+
+ data->chunk.chunk_size = counter;
+ data->chunk.chunk_left = counter;
+
+ data->chunk.chunck_state = CHUNK_R;
+ break;
+ }
+ buf++;
+ len--;
+ break;
+ case CHUNK_R:
+ case CHUNK_R_BODY:
+ if (*buf == ' ') {
+ buf++;
+ len--;
+ break;
+ }
+
+ if (*buf != '\r')
+ return -EILSEQ;
+
+ if (data->chunk.chunck_state == CHUNK_R)
+ data->chunk.chunck_state = CHUNK_N;
+ else
+ data->chunk.chunck_state = CHUNK_N_BODY;
+ buf++;
+ len--;
+ break;
+ case CHUNK_N:
+ case CHUNK_N_BODY:
+
mmap error
Hi, I often get below error from connman. This occurs for cellular and wifi profiles also. Can any body tell me what is the issue? Is it ok to ignore this error? connmand[11654]: mmap error Cannot allocate memory for /usr/var/lib/connman/stats/ethernet_62477ed418ee_cable-roaming.data -- Regards & Thanks Raghavendra. S 9880329621 ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: Broadcom's proprietary wl driver detected as ethernet
Hi, I noticed that with the latest connman git version Broadcom's proprietary wl driver is detected as an ethernet device, not a wifi device. This was working few weeks back and my main suspect is the udev removal. [Raghu]: I too met with this some time back. Assuming you enbled wifi during compilation, following was the issue in my case. When I killed connman. for some reason plugins directory (/usr/lib/connman/plugins/*) was getting deleted. So next time when I started connman it started without throwing any error. Because of this connman detected wifi interface as ethernet interface and all wifi functionalities were disabled for the interface. So you better check once whether you have /usr/lib/connman/plugins/*. Otherwise reinstall and try. -- Kalle Valo ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: Broadcom's proprietary wl driver detected as ethernet
Hi Kalle, On Thu, Oct 14, 2010 at 08:25:17PM +0300, Kalle Valo wrote: > Hi, > > I noticed that with the latest connman git version Broadcom's > proprietary wl driver is detected as an ethernet device, not a wifi > device. This was working few weeks back and my main suspect is the udev > removal. Could you please pull the latest ConnMan bits and check if it's working with the wl crap^Wdriver ? Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [PATCH] Probe element when a connman device driver register
Hi Joey,
On Wed, Oct 13, 2010 at 09:58:14AM -0600, Joey Lee wrote:
> Hi Sameul,
>
> 於 三，2010-10-13 於 16:07 +0200，Samuel Ortiz 提到：
> > Hi guys,
> >
> > On Wed, Oct 13, 2010 at 10:33:04AM +0800, ying.an.d...@intel.com wrote:
> > > From: Lee, Chun-Yi
> > >
> > > There have a race condition issue in connman between wifi driver object
> > > with
> > > element->driver reference.
> > > On some machine, the wifi driver object doesn't generate before we try to
> > > register a element. It causes element->driver is NULL, and will not do
> > > driver->remove when remove element.
> > Do you mean that the wifi device is not probed when the wifi device driver
> > is
> > probed ?
> > That is to say, connman_device_register() for the wifi device was not called
> > yet when connman_device_driver_register() is called for the wifi driver ?
> >
> > I suppose you're running a pre 0.62 ConnMan release. In that case, udev.c
> > enumerates all devices and registers them. For all available network
> > devices,
> > add_net_device() eventually calls connman_device_register(). Only after that
> > happens, all plugins init routines are called and e.g.
> > connman_device_driver_register() is called from the wifi-legacy plugin.
> >
> > Could you please send a complete connman.log with full debug of your failure
> > case, from when connmand starts up until you stop it ?
>
> The attached file is the fail case connman log:
>
> Log line description:
>
> 1168: boot until stable
> - WiFi APs list show up
> 1174: press Fn+F11 wifi key to turn off wifi
> 1329: press Fn+F11 wifi key to turn on wifi until stable
> - WiFi switch still show enabled on carrick GUI, but APs list removed.
> 1331: press Fn+F11 wifi key to turn on wifi
> 1437: press Fn+F11 wifi key to turn on wifi until stable
>
> I also attached it on
> http://bugs.meego.com/show_bug.cgi?id=8075
So I've been looking at this issue and this race condition is indeed real, and
not related to your specific hardware. It will be visible to HW that is either
removable (e.g. a US dongle) or completely removed from the bus upon rfkill
commands (e.g. pcie hotpluggable devices).
When the device shows up through udev/rtnl before wpa_supplicant is started,
the corresponding element->driver pointer will not be set, and we'll be left
with a stale connman_device upon removal of the physical device..
Although your patch is correct and does fix the issue, I don't really like
exporting the whole element probing routine, that should be kept internal to
the element code.
What I propose is to create a simple __connman_element_set_driver() routine
that will just set the right driver for a given element. The patch below works
fine for me, could you please give it a try (It may not apply cleanly
depending on the ConnMan version you're using) ?
diff --git a/src/connman.h b/src/connman.h
index 5c17a68..8aaac3a 100644
--- a/src/connman.h
+++ b/src/connman.h
@@ -190,6 +190,8 @@ gboolean __connman_element_device_isfiltered(const char
*devname);
int __connman_detect_init(void);
void __connman_detect_cleanup(void);
+void __connman_element_set_driver(struct connman_element *element);
+
#include
int __connman_ipconfig_init(void);
diff --git a/src/device.c b/src/device.c
index 373eb5f..1b721ee 100644
--- a/src/device.c
+++ b/src/device.c
@@ -586,6 +586,8 @@ static void probe_driver(struct connman_element *element,
gpointer user_data)
element->device->driver = driver;
+ __connman_element_set_driver(element);
+
setup_device(element->device);
}
diff --git a/src/element.c b/src/element.c
index 74383cc..a5700f2 100644
--- a/src/element.c
+++ b/src/element.c
@@ -1322,6 +1322,28 @@ void connman_element_set_error(struct connman_element
*element,
__connman_service_indicate_error(service, convert_error(error));
}
+void __connman_element_set_driver(struct connman_element *element)
+{
+ GSList *list;
+
+ DBG("element %p name %s driver %p", element, element->name,
+ element->driver);
+
+ if (element->driver)
+ return;
+
+ for (list = driver_list; list; list = list->next) {
+ struct connman_driver *driver = list->data;
+
+ if (match_driver(element, driver) == FALSE)
+ continue;
+
+ element->driver = driver;
+
+ break;
+ }
+}
+
int __connman_element_init(const char *device, const char *nodevice)
{
struct connman_element *element;
--
Intel Open Source Technology Centre
http://oss.intel.com/
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman
Service provisioning interface. Was: [PATCH] Add support for EAP configuration via service-api
Hello... Back to service provisioning (EAP configuration on the fly). So now I'll have some time to work on this. I think the easiest way to do this, is to add support for inotify for .config dir, and then add a Method to upload .config files that will be read on the fly. My plan is to: 1. Add support to inotify, to read provisioning files on the fly. 2. (What do you think???) Convert the provisioning file to XML?? 3. Add new methods to the Manager Interface to Upload and Export services configuration. 4. Add support for other service types as well (today only wifi is supported) for ipv4/6 configuration options, APN setting, etc. Sounds reasonable? Regards Lucio Maciel. ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Broadcom's proprietary wl driver detected as ethernet
Hi, I noticed that with the latest connman git version Broadcom's proprietary wl driver is detected as an ethernet device, not a wifi device. This was working few weeks back and my main suspect is the udev removal. -- Kalle Valo ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: connman crash with ofono
Hi Samuel, On Thu, Oct 14, 2010 at 11:59 AM, Samuel Ortiz wrote: > Hi Cristiano, > > On Thu, Oct 14, 2010 at 10:54:03AM -0300, Cristiano Fernandes wrote: >> Last mail was too long, sorry :-) >> >> This is probably happening when a null netmask send to >> __connman_ipconfig_netmask_prefix_len, crashing at inet_network with >> null parameter. >> I will reproduce the crash and send a fix asap. > I pushed a fix for it already. > > Cheers, > Samuel. > > >> Regards, >> >> Cristiano Fernandes >> ___ >> connman mailing list >> connman@connman.net >> http://lists.connman.net/listinfo/connman > > -- > Intel Open Source Technology Centre > http://oss.intel.com/ > ___ > connman mailing list > connman@connman.net > http://lists.connman.net/listinfo/connman > Thanks for the fix. Regards, Cristiano ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: few doubts
Hi Raghavendra, On Thu, Oct 14, 2010 at 05:04:15AM -0700, Raghavendra. S wrote: > Hi, > > I have few doubts about connman and profile management. > > >1. Does connman supports MMS profiles? No, this is not ConnMan's business. You will get more details about MMS support from the oFono folks. >2. meego/moblin which uses connman, will they support add/delete profile? >if yes, can any body please tell me how this is done? We will eventually support those but right now we don't. >3. I have scanned, saved passphrase and connected to an AP(say ssid - >linksys). Since connection is successfull, this will be saved in connman >profile. Now say for next 6-7 months I go to various places and I >connect/disconnect with many APs. Once again I am back to my old place and >want to connect to same AP (linksys). In this case will connman once again >ask for passphrase to connect with linksys AP? No it won't ask for a passphrase for this AP. It doesn't matter for how long you haven't connected to this AP, as long as you use the same default.profile file. >4. since connman does not support wifi driver load/unload. And wifi >consumes power even when driver loaded and interface is down. How this is >handled in devices like mobiles which use meego/moblin? This is not ConnMan's job to load or unload driver modules. ConnMan, through wpa_supplicant, brings the WiFi interfaces up and down. If your mobile platform's wifi HW is so bad that it still consumes a significant amount of power while the driver's interface is down, then you're having fundamental issues lower in the SW stack (driver, kernel, device's firmware). Cheers, Samuel. > > -- > Regards & Thanks > Raghavendra. S > 9880329621 > ___ > connman mailing list > connman@connman.net > http://lists.connman.net/listinfo/connman -- Intel Open Source Technology Centre http://oss.intel.com/ ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: connman crash with ofono
Hi Cristiano, On Thu, Oct 14, 2010 at 10:54:03AM -0300, Cristiano Fernandes wrote: > Last mail was too long, sorry :-) > > This is probably happening when a null netmask send to > __connman_ipconfig_netmask_prefix_len, crashing at inet_network with > null parameter. > I will reproduce the crash and send a fix asap. I pushed a fix for it already. Cheers, Samuel. > Regards, > > Cristiano Fernandes > ___ > connman mailing list > connman@connman.net > http://lists.connman.net/listinfo/connman -- Intel Open Source Technology Centre http://oss.intel.com/ ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: connman crash with ofono
Hi Daniel, On Thu, Oct 14, 2010 at 9:19 AM, Daniel Wagner wrote: > Samuel here is the log and the description I did: > > - started up connman > - started ofono > - ofono/test/enter-pin > - connected to ethernet (using carrick) > - connected to vodafone (using carrick) > > connman connected then successfuly to vodafone > > after a while connman crased. I didn't do anyhting with connman or ofono. > > > [w...@candlejack src]$ sudo ./connmand -n -d > connmand[10359]: Enabling DNS server 192.168.100.4 > connmand[10359]: src/ondemand.c:ondemand_default_changed() service 0x91aec0 > connmand[10359]: src/wpad.c:__connman_wpad_stop() service 0x91c1b0 > connmand[10359]: src/notifier.c:__connman_notifier_disconnect() type 6 > connmand[10359]: src/notifier.c:technology_connected() type 6 connected 0 > connmand[10359]: src/profile.c:__connman_profile_changed() > connmand[10359]: src/service.c:__connman_service_lookup_from_network() > network 0x924000 > connmand[10359]: src/service.c:__connman_service_lookup_from_network() > network 0x928c10 > connmand[10359]: src/connection.c:find_active_gateway() > connmand[10359]: src/element.c:connman_element_update() element 0x932cf0 name > connection > connmand[10359]: src/connection.c:connection_remove() gateway (null) > connmand[10359]: src/element.c:connman_element_unref() element 0x932cf0 name > connection refcount 1 > connmand[10359]: src/element.c:remove_element() element 0x92ea80 name ipv4 > connmand[10359]: src/ipv4.c:ipv4_remove() element 0x92ea80 name ipv4 > connmand[10359]: src/timeserver.c:connman_timeserver_remove() server (null) > connmand[10359]: src/ipv4.c:ipv4_remove() address (null) > connmand[10359]: src/ipv4.c:ipv4_remove() netmask (null) > connmand[10359]: src/ipv4.c:ipv4_remove() broadcast (null) > connmand[10359]: Aborting (signal 11) > connmand[10359]: backtrace > connmand[10359]: [0]: /lib64/libpthread.so.0() [0x3efc20f0f0] > connmand[10359]: [1]: /lib64/libc.so.6(inet_network+0x19) [0x3efbaf7af9] > connmand[10359]: [2]: ./connmand() [0x442103] > connmand[10359]: [3]: ./connmand() [0x445f19] > connmand[10359]: [4]: ./connmand() [0x42a869] > connmand[10359]: [5]: /lib64/libglib-2.0.so.0() [0x3efde44187] > connmand[10359]: [6]: /lib64/libglib-2.0.so.0() [0x3efde44141] > connmand[10359]: [7]: /lib64/libglib-2.0.so.0(g_node_traverse+0x211) > [0x3efde44cc1] > connmand[10359]: [8]: ./connmand(connman_element_unregister_children+0x97) > [0x42aac1] > connmand[10359]: [9]: ./connmand() [0x42f87f] > connmand[10359]: [10]: ./connmand(connman_network_set_connected+0x101) > [0x42fa00] > connmand[10359]: [11]: ./connmand() [0x420fa9] > connmand[10359]: [12]: ./connmand() [0x421158] > connmand[10359]: [13]: ./connmand() [0x40c8e8] > connmand[10359]: [14]: ./connmand() [0x40cd27] > connmand[10359]: [15]: /lib64/libdbus-1.so.3(dbus_connection_dispatch+0x336) > [0x3f01a109d6] > connmand[10359]: [16]: ./connmand() [0x40b4ea] > connmand[10359]: [17]: /lib64/libglib-2.0.so.0() [0x3efde3994b] > connmand[10359]: [18]: /lib64/libglib-2.0.so.0(g_main_context_dispatch+0x22e) > [0x3efde3923e] > connmand[10359]: [19]: /lib64/libglib-2.0.so.0() [0x3efde3cc28] > connmand[10359]: [20]: /lib64/libglib-2.0.so.0(g_main_loop_run+0x1a5) > [0x3efde3d075] > connmand[10359]: [21]: ./connmand() [0x4265c3] > connmand[10359]: [22]: /lib64/libc.so.6(__libc_start_main+0xfd) [0x3efba1eb1d] > connmand[10359]: [23]: ./connmand() [0x40b3b9] > connmand[10359]: +++ > > >> backtrace >> [0]: __connman_ipconfig_netmask_prefix_len() [ipconfig.c:121] >> [1]: ipv4_remove() [ipv4.c:164] >> [2]: remove_element() [element.c:1153] >> [3]: connman_element_unregister_children() [element.c:1224] >> [4]: set_connected() [network.c:946] >> [5]: connman_network_set_connected() [network.c:999] >> [6]: set_connected() [ofono.c:1498] >> [7]: context_changed() [ofono.c:1545] >> [8]: signal_filter() [watch.c:403] >> [9]: message_filter() [watch.c:530] >> [10]: message_dispatch() [mainloop.c:80] >> [11]: main() [main.c:260] >> [12]: _start() [dbus.c:0] >> --- > ___ > connman mailing list > connman@connman.net > http://lists.connman.net/listinfo/connman > Last mail was too long, sorry :-) This is probably happening when a null netmask send to __connman_ipconfig_netmask_prefix_len, crashing at inet_network with null parameter. I will reproduce the crash and send a fix asap. Regards, Cristiano Fernandes ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
few doubts
Hi, I have few doubts about connman and profile management. 1. Does connman supports MMS profiles? 2. meego/moblin which uses connman, will they support add/delete profile? if yes, can any body please tell me how this is done? 3. I have scanned, saved passphrase and connected to an AP(say ssid - linksys). Since connection is successfull, this will be saved in connman profile. Now say for next 6-7 months I go to various places and I connect/disconnect with many APs. Once again I am back to my old place and want to connect to same AP (linksys). In this case will connman once again ask for passphrase to connect with linksys AP? 4. since connman does not support wifi driver load/unload. And wifi consumes power even when driver loaded and interface is down. How this is handled in devices like mobiles which use meego/moblin? -- Regards & Thanks Raghavendra. S 9880329621 ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: stats: reduce number of open files
Hi Marcel, On Thu, Oct 14, 2010 at 11:02:05AM +0300, Marcel Holtmann wrote: > Hi Daniel, > > > > > $ sudo lsof +p 7061 | grep stats > > > > connmand 7061 root memREG 8,18 4096 927984 > > > > /var/lib/connman/stats/ethernet_028037ec0200_cable.data > > > > connmand 7061 root memREG 8,18 4096 927988 > > > > /var/lib/connman/stats/cellular_262029903630655_context1.data > > > > connmand 7061 root memREG 8,18 4096 916554 > > > > /var/lib/connman/stats/ethernet_002481c57c73_cable.data > > > > connmand 7061 root 11u REG 8,18 4096 927988 > > > > /var/lib/connman/stats/cellular_262029903630655_context1.data > > > > connmand 7061 root 12u REG 8,18 4096 916554 > > > > /var/lib/connman/stats/ethernet_002481c57c73_cable.data > > > > connmand 7061 root 18u REG 8,18 4096 927984 > > > > /var/lib/connman/stats/ethernet_028037ec0200_cable.data > > > > > > > Which connman version are you using ? With connman trunk, I'm no longer > > > seeing > > > the fake MBM ethernet device, only the cellular one. > > > > Here is a couple of infos for you. > > > > $ lspci -v | grep Dell: > > > > Bus 002 Device 004: ID 413c:8184 Dell Computer Corp. > > > > The label on the hardware says it's a F3607gw > > > > $ ls -lR > > .: > > total 0 > > lrwxrwxrwx 1 root root 0 2010-10-14 08:15 eth0 -> > > ../../devices/pci:00/:00:1c.5/:3f:00.0/net/eth0 > > lrwxrwxrwx 1 root root 0 2010-10-14 10:15 lo -> ../../devices/virtual/net/lo > > lrwxrwxrwx 1 root root 0 2010-10-14 08:15 usb0 -> > > ../../devices/pci:00/:00:1d.7/usb2/2-5/2-5:1.6/net/usb0 > > lrwxrwxrwx 1 root root 0 2010-10-14 08:15 wlan0 -> > > ../../devices/pci:00/:00:1a.7/usb1/1-6/1-6:1.0/net/wlan0 > > > > $ cat usb0/uevent > > INTERFACE=usb0 > > IFINDEX=3 > > why is DEVTYPE missing here? And why is this not named wwan0. Are you > running on a really old kernel? Yep, good guess. It's a 2.6.32 kernel. I'll try with a newer one. Do you happen to know which version do I need at least? thanks, daniel ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: connman crash with ofono
Hi Daniel, > connman trunk just crashed on my (no local modifications). I was using > ofono with my MBM and it looks like the connection was lost in > ofono... they are caused by the netlink based IP setting patches. I have seen the same crash. Regards Marcel ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
connman crash with ofono
connman trunk just crashed on my (no local modifications). I was using ofono with my MBM and it looks like the connection was lost in ofono... connmand[10359]: Aborting (signal 11) connmand[10359]: backtrace connmand[10359]: [0]: /lib64/libpthread.so.0() [0x3efc20f0f0] connmand[10359]: [1]: /lib64/libc.so.6(inet_network+0x19) [0x3efbaf7af9] connmand[10359]: [2]: ./connmand() [0x442103] connmand[10359]: [3]: ./connmand() [0x445f19] connmand[10359]: [4]: ./connmand() [0x42a869] connmand[10359]: [5]: /lib64/libglib-2.0.so.0() [0x3efde44187] connmand[10359]: [6]: /lib64/libglib-2.0.so.0() [0x3efde44141] connmand[10359]: [7]: /lib64/libglib-2.0.so.0(g_node_traverse+0x211) [0x3efde44cc1] connmand[10359]: [8]: ./connmand(connman_element_unregister_children+0x97) [0x42aac1] connmand[10359]: [9]: ./connmand() [0x42f87f] connmand[10359]: [10]: ./connmand(connman_network_set_connected+0x101) [0x42fa00] connmand[10359]: [11]: ./connmand() [0x420fa9] connmand[10359]: [12]: ./connmand() [0x421158] connmand[10359]: [13]: ./connmand() [0x40c8e8] connmand[10359]: [14]: ./connmand() [0x40cd27] connmand[10359]: [15]: /lib64/libdbus-1.so.3(dbus_connection_dispatch+0x336) [0x3f01a109d6] connmand[10359]: [16]: ./connmand() [0x40b4ea] connmand[10359]: [17]: /lib64/libglib-2.0.so.0() [0x3efde3994b] connmand[10359]: [18]: /lib64/libglib-2.0.so.0(g_main_context_dispatch+0x22e) [0x3efde3923e] connmand[10359]: [19]: /lib64/libglib-2.0.so.0() [0x3efde3cc28] connmand[10359]: [20]: /lib64/libglib-2.0.so.0(g_main_loop_run+0x1a5) [0x3efde3d075] connmand[10359]: [21]: ./connmand() [0x4265c3] connmand[10359]: [22]: /lib64/libc.so.6(__libc_start_main+0xfd) [0x3efba1eb1d] connmand[10359]: [23]: ./connmand() [0x40b3b9] connmand[10359]: +++ backtrace [0]: __connman_ipconfig_netmask_prefix_len() [ipconfig.c:121] [1]: ipv4_remove() [ipv4.c:164] [2]: remove_element() [element.c:1153] [3]: connman_element_unregister_children() [element.c:1224] [4]: set_connected() [network.c:946] [5]: connman_network_set_connected() [network.c:999] [6]: set_connected() [ofono.c:1498] [7]: context_changed() [ofono.c:1545] [8]: signal_filter() [watch.c:403] [9]: message_filter() [watch.c:530] [10]: message_dispatch() [mainloop.c:80] [11]: main() [main.c:260] [12]: _start() [dbus.c:0] --- ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: stats: reduce number of open files
Hi Daniel, > > > $ sudo lsof +p 7061 | grep stats > > > connmand 7061 root memREG 8,18 4096 927984 > > > /var/lib/connman/stats/ethernet_028037ec0200_cable.data > > > connmand 7061 root memREG 8,18 4096 927988 > > > /var/lib/connman/stats/cellular_262029903630655_context1.data > > > connmand 7061 root memREG 8,18 4096 916554 > > > /var/lib/connman/stats/ethernet_002481c57c73_cable.data > > > connmand 7061 root 11u REG 8,18 4096 927988 > > > /var/lib/connman/stats/cellular_262029903630655_context1.data > > > connmand 7061 root 12u REG 8,18 4096 916554 > > > /var/lib/connman/stats/ethernet_002481c57c73_cable.data > > > connmand 7061 root 18u REG 8,18 4096 927984 > > > /var/lib/connman/stats/ethernet_028037ec0200_cable.data > > > > > Which connman version are you using ? With connman trunk, I'm no longer > > seeing > > the fake MBM ethernet device, only the cellular one. > > Here is a couple of infos for you. > > $ lspci -v | grep Dell: > > Bus 002 Device 004: ID 413c:8184 Dell Computer Corp. > > The label on the hardware says it's a F3607gw > > $ ls -lR > .: > total 0 > lrwxrwxrwx 1 root root 0 2010-10-14 08:15 eth0 -> > ../../devices/pci:00/:00:1c.5/:3f:00.0/net/eth0 > lrwxrwxrwx 1 root root 0 2010-10-14 10:15 lo -> ../../devices/virtual/net/lo > lrwxrwxrwx 1 root root 0 2010-10-14 08:15 usb0 -> > ../../devices/pci:00/:00:1d.7/usb2/2-5/2-5:1.6/net/usb0 > lrwxrwxrwx 1 root root 0 2010-10-14 08:15 wlan0 -> > ../../devices/pci:00/:00:1a.7/usb1/1-6/1-6:1.0/net/wlan0 > > $ cat usb0/uevent > INTERFACE=usb0 > IFINDEX=3 why is DEVTYPE missing here? And why is this not named wwan0. Are you running on a really old kernel? Regards Marcel ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: stats: reduce number of open files
Good Morning Samuel, On Wed, Oct 13, 2010 at 04:30:46PM +0200, Samuel Ortiz wrote: > > $ sudo lsof +p 7061 | grep stats > > connmand 7061 root memREG 8,18 4096 927984 > > /var/lib/connman/stats/ethernet_028037ec0200_cable.data > > connmand 7061 root memREG 8,18 4096 927988 > > /var/lib/connman/stats/cellular_262029903630655_context1.data > > connmand 7061 root memREG 8,18 4096 916554 > > /var/lib/connman/stats/ethernet_002481c57c73_cable.data > > connmand 7061 root 11u REG 8,18 4096 927988 > > /var/lib/connman/stats/cellular_262029903630655_context1.data > > connmand 7061 root 12u REG 8,18 4096 916554 > > /var/lib/connman/stats/ethernet_002481c57c73_cable.data > > connmand 7061 root 18u REG 8,18 4096 927984 > > /var/lib/connman/stats/ethernet_028037ec0200_cable.data > > > Which connman version are you using ? With connman trunk, I'm no longer seeing > the fake MBM ethernet device, only the cellular one. Here is a couple of infos for you. $ lspci -v | grep Dell: Bus 002 Device 004: ID 413c:8184 Dell Computer Corp. The label on the hardware says it's a F3607gw $ ls -lR .: total 0 lrwxrwxrwx 1 root root 0 2010-10-14 08:15 eth0 -> ../../devices/pci:00/:00:1c.5/:3f:00.0/net/eth0 lrwxrwxrwx 1 root root 0 2010-10-14 10:15 lo -> ../../devices/virtual/net/lo lrwxrwxrwx 1 root root 0 2010-10-14 08:15 usb0 -> ../../devices/pci:00/:00:1d.7/usb2/2-5/2-5:1.6/net/usb0 lrwxrwxrwx 1 root root 0 2010-10-14 08:15 wlan0 -> ../../devices/pci:00/:00:1a.7/usb1/1-6/1-6:1.0/net/wlan0 $ cat usb0/uevent INTERFACE=usb0 IFINDEX=3 $ ip a 1: lo: mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc mq state UP qlen 1000 link/ether 00:24:81:c5:7c:73 brd ff:ff:ff:ff:ff:ff inet 192.168.101.27/16 brd 192.168.255.255 scope global eth0 inet6 fe80::224:81ff:fec5:7c73/64 scope link valid_lft forever preferred_lft forever 3: usb0: mtu 1500 qdisc pfifo_fast state DOWN qlen 1000 link/ether 02:80:37:ec:02:00 brd ff:ff:ff:ff:ff:ff 4: wlan0: mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 00:22:3f:0e:de:6e brd ff:ff:ff:ff:ff:ff hth, daniel ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
