Re: Connman-1.20 services scan does not return hidden networks.

[Sameer Naik]

Hi,

I have applied this commit and it works.

Thanks
~Sameer


On Wed, Dec 18, 2013 at 2:49 PM, Patrik Flykt
wrote:

>
> Hi,
>
> On Thu, 2013-12-12 at 17:44 +0530, Sameer Naik wrote:
> > Hello,
> >
> > I updated to connman-1.20 and found that hidden wifi networks are not
> > returned when scanning for services. Upon inspection I found that commit
> > #363393cfb1a5f95f8892f40662486c87b80d0091 is where the breakage occurs.
> >
> > For reference, please find the commit message below:
> >
> > commit 363393cfb1a5f95f8892f40662486c87b80d0091
> > Author: Daniel Wagner 
> > Date:   Mon Dec 2 13:50:25 2013 +0100
> >
> > gsupplicant: Fix empty string test
> >
> > The address of an array is never NULL, so the comparison will
> > always evaluate the same way. Instead test for the length
> > of the SSID.
> >
> > Reported by coverity.
>
> This is fixed with commit 91913c40054d9c55c6d38f0c626a78bdbcf4279a,
> please check and report back that latest upstream fixes your problem.
>
> Cheers,
>
> Patrik
>
> ___
> 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-1.20 services scan does not return hidden networks.

[Sameer Naik]

Hello,

I updated to connman-1.20 and found that hidden wifi networks are not
returned when scanning for services. Upon inspection I found that commit
#363393cfb1a5f95f8892f40662486c87b80d0091 is where the breakage occurs.

For reference, please find the commit message below:

commit 363393cfb1a5f95f8892f40662486c87b80d0091
Author: Daniel Wagner 
Date:   Mon Dec 2 13:50:25 2013 +0100

gsupplicant: Fix empty string test

The address of an array is never NULL, so the comparison will
always evaluate the same way. Instead test for the length
of the SSID.

Reported by coverity.

Regards
~Sameer
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman

Requirements for getting Hotspot (Tethering) enabled.

[Sameer Naik]

Hello,

I am using connman-1.12 on my STB that runs linux kernel version 2.6.22.
In my kernel configuration i have enabled the following:

CONFIG_BRIDGE=m
CONFIG_BRIDGE_NETFILTER=y
CONFIG_NF_CONNTRACK_ENABLED=m
CONFIG_NF_CONNTRACK=m
CONFIG_NF_NAT=m
CONFIG_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m

I have iptables-1.4.12.2, wpa_supplicant-1.1 installed.

My wpa_supplicant config contains the following configuration (among other
things):
CONFIG_DRIVER_HOSTAP=y
CONFIG_DRIVER_WEXT=y
CONFIG_WPS=y
CONFIG_AP=y
CONFIG_BGSCAN_SIMPLE=y

The following modules are automatically loaded at boot:
bridge 70144 0 - Live 0xc014f000
llc 8864 1 bridge, Live 0xc011
nf_conntrack_ipv4 11488 0 - Live 0xc001d000
nf_conntrack 68816 1 nf_conntrack_ipv4, Live 0xc0123000
iptable_filter 3008 0 - Live 0xc001b000
ip_tables 14544 1 iptable_filter, Live 0xc0057000
x_tables 18448 1 ip_tables, Live 0xc0051000

I am using a rtl8192c wifi dongle for the wifi and works with the Wext
interface.

When i try to enable tethering in connman i get an error message saying
"wlan0 does not support AP mode".
Are there any additional requirements for getting hotspot feature working?
Do i need to install hostapd or something?
I would like to debug and get the hotspot feature enabled. But at the
moment, I am not sure how to.

Please find the connman and wpa_supplicant logs attached.

For the purpose of testing, i installed connman-1.12 on my ubuntu 12.10
laptop and tried creating a hotspot using the enable-tethering script. The
script indicates that it has enabled tethering on the wifi dongle. But when
i scan for wifi networks (on my mobile) i do not see the hotspot created.

Please advise.

Regards
~Sameer
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: [PATCH v2] wifi: Preliminary fix for autoscanning known hidden SSIDs

[Sameer Naik]

Hello Tomasz,

I tested your patch and it works when there is only one provisioned hidden
service (as expected).
I will use this patch for now.

Thanks and Regards
~Sameer


On Fri, Mar 1, 2013 at 4:47 PM, Tomasz Bursztyka <
tomasz.burszt...@linux.intel.com> wrote:

> Currently, it relies on max_ssids to know how many SSIDs it can provide as
> paremeters. However, patch 6af0579c434058536fb40480f40f5e9895cfe863, which
> fixes an issue about fast scanning, affects such feature.
>
> Therefore, as a default, it will fallback to 1 if given max_ssids is 0.
>
> There is still the issue that it will autoscan only max_ssid (1 or more)
> known hidden SSIDs. This need to be fixed.
>
> Reported by Sameer Naik
> ---
>
> Dumb test to change, sorry.
>
>  plugins/wifi.c | 31 +++
>  1 file changed, 15 insertions(+), 16 deletions(-)
>
> diff --git a/plugins/wifi.c b/plugins/wifi.c
> index 4b097fc..d5a20b3 100644
> --- a/plugins/wifi.c
> +++ b/plugins/wifi.c
> @@ -530,7 +530,8 @@ static void scan_callback_hidden(int result,
>  {
> struct connman_device *device = user_data;
> struct wifi_data *wifi = connman_device_get_data(device);
> -   int driver_max_ssids;
> +   GSupplicantScanParams *scan_params;
> +   int driver_max_ssids, ret;
>
> DBG("result %d wifi %p", result, wifi);
>
> @@ -539,32 +540,30 @@ static void scan_callback_hidden(int result,
>
> /*
>  * Scan hidden networks so that we can autoconnect to them.
> +* We will assume 1 as a default number of ssid to scan.
>  */
> driver_max_ssids = g_supplicant_interface_get_max_scan_ssids(
> wifi->interface);
> -   DBG("max ssids %d", driver_max_ssids);
> +   if (driver_max_ssids == 0)
> +   driver_max_ssids = 1;
>
> -   if (driver_max_ssids > 0) {
> -   GSupplicantScanParams *scan_params;
> -   int ret;
> +   DBG("max ssids %d", driver_max_ssids);
>
> -   scan_params = g_try_malloc0(sizeof(GSupplicantScanParams));
> -   if (scan_params == NULL)
> -   goto out;
> +   scan_params = g_try_malloc0(sizeof(GSupplicantScanParams));
> +   if (scan_params == NULL)
> +   goto out;
>
> -   if (get_hidden_connections(driver_max_ssids,
> -   scan_params) > 0) {
> -   ret = g_supplicant_interface_scan(wifi->interface,
> +   if (get_hidden_connections(driver_max_ssids, scan_params) > 0) {
> +   ret = g_supplicant_interface_scan(wifi->interface,
> scan_params,
> scan_callback,
> device);
> -   if (ret == 0)
> -   return;
> -   }
> -
> -   g_supplicant_free_scan_params(scan_params);
> +   if (ret == 0)
> +   return;
> }
>
> +   g_supplicant_free_scan_params(scan_params);
> +
>  out:
> scan_callback(result, interface, user_data);
>  }
> --
> 1.8.1.4
>
> ___
> connman mailing list
> connman@connman.net
> http://lists.connman.net/listinfo/connman
>
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: Autoconnect to a hidden wifi service.

[Sameer Naik]

I am looking into the connman plugin/wifi.c to figure out the issue.
so far i have found that in  scan_callback_hidden  function,
g_supplicant_interface_get_max_scan_ssids(wifi->interface), returns 0 and
therefore no attempt to connect to provisioned hidden wifi networks is
performed.

Will trace the calls further to figure out why
g_supplicant_interface_get_max_scan_ssids returns 0.

Regards
~Sameer


On Fri, Mar 1, 2013 at 2:23 PM, Sameer Naik <
sameer.subscripti...@damagehead.com> wrote:

>
> Hello,
>
> I have been checking the autoconnect to hidden network feature.
> For far no luck.
>
> For your reference, following is my wpa_supplicant-1.1 config
> CONFIG_DRIVER_HOSTAP=y
> CONFIG_DRIVER_ATMEL=y
> CONFIG_DRIVER_WEXT=y
> CONFIG_DRIVER_WIRED=y
> CONFIG_IEEE8021X_EAPOL=y
> CONFIG_EAP_MD5=y
> CONFIG_EAP_MSCHAPV2=y
> CONFIG_EAP_TLS=y
> CONFIG_EAP_PEAP=y
> CONFIG_EAP_TTLS=y
> CONFIG_EAP_GTC=y
> CONFIG_EAP_OTP=y
> CONFIG_EAP_LEAP=y
> CONFIG_WPS=y
> CONFIG_WPS2=y
> CONFIG_AP=y
> CONFIG_PKCS12=y
> CONFIG_CTRL_IFACE=y
> CONFIG_BACKEND=file
> CONFIG_PEERKEY=y
> CONFIG_CTRL_IFACE_DBUS_NEW=y
> CONFIG_CTRL_IFACE_DBUS_INTRO=y
> CONFIG_DEBUG_FILE=n
> CONFIG_BGSCAN_SIMPLE=y
> CONFIG_BGSCAN_LEARN=y
> CONFIG_OS=unix
> CONFIG_L2_PACKET=linux
>
> My wpa_supplicant.conf file contains the following:
> ap_scan=1
> ctrl_interface=/var/run/wpa_supplicant
>
> I generated the connmand and wpa_supplicant debug logs over a period of 10
> minutes (attached).
> Please let me know if you find anything.
>
> Thanks and Regards
> ~Sameer
>
>
> On Fri, Mar 1, 2013 at 2:08 AM, Sameer Naik <
> sameer.subscripti...@damagehead.com> wrote:
>
>> Hello Tomasz,
>>
>> Please find attached.
>>
>> Regards
>> ~Sameer
>>
>>
>> On Fri, Mar 1, 2013 at 12:15 AM, Tomasz Bursztyka <
>> tomasz.burszt...@linux.intel.com> wrote:
>>
>>> Hi Sameer,
>>>
>>>
>>>  I am wondering whether connman is supposed to be able to autoconnect to
>>>> this hidden wifi service or is this the expected behaviour.
>>>>
>>>>
>>> It should autoconnect also with hidden service. Works perfectly with my
>>> config but there is maybe an issue with yours.
>>> Could you provide the logs of connman (run it like:
>>> CONNMAN_SUPPLICANT_DEBUG=1 connmand -n -d &> connman_log.txt)
>>>
>>> Tomasz
>>> __**_
>>> connman mailing list
>>> connman@connman.net
>>> http://lists.connman.net/**listinfo/connman<http://lists.connman.net/listinfo/connman>
>>>
>>
>>
>
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: Understanding connman's ONLINE state change.

[Sameer Naik]

Got it.
Will try to hack the source. Will let you guys know if i get anywhere.

Thanks and Regards
~Sameer


On Fri, Mar 1, 2013 at 12:26 AM, Tomasz Bursztyka <
tomasz.burszt...@linux.intel.com> wrote:

> Hi Sameer,
>
>
>  I guess this is the expected behaviour.
>>
>
> You guess right.
>
>
>  I would like to know if it is possible to instruct connman to connect all
>> available technologies, so that at startup it connects to the wired as
>> well
>> as the wireless services and then decides which one to setup as the
>> default
>> route.
>>
>
> As far as I know it cannot. Should not be too complex to patch I think.
>
>
>  Lastly, i would also like to know if connman performs periodic checks to
>> see if the service can go in the online state. i.e. when the state of the
>> manager is in the "ready", does connman periodically check if it can go
>> online?
>>
>
> The idea has been around for a while but no patches yet.
> Looks trivial on the surface, but actually it implies things around user's
> moving services before/after another one, (moving the online one after a
> ready one) etc...
>
>
> Patches are welcome of course ;)
>
> Tomasz
> __**_
> connman mailing list
> connman@connman.net
> http://lists.connman.net/**listinfo/connman
>
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Understanding connman's ONLINE state change.

[Sameer Naik]

Hello,

I was trying to understand the state change of services from READY to
ONLINE state.
>From what i can gather a service state will change from READY to ONLINE
once connman is able to fetch
Hidden=true(for ipv4).

In my system i have a wired service and a wireless service configured, and
in the main.conf i have the config line
Preferred = ethernet

In the test setup i have configured that wired and wireless networks such
that the wired network has not internet connection available so it will not
be able to reach http://ipv4.connman.net/online/status.html. While the
wireless network as full internet access.

Now when i start connman, it connects to the wired network and stays in the
ready state forever. It does not try to connect to the wireless network to
see if it can go online and set it up as the default service.

On the other hand if i unplug the lan cable from the device, connman
connects to the wireless service and goes in the online state. After that
if i plug in the lan cable, connman connects to the wired service, see's
that it cannot go online and so keeps the wireless service as the default
service and hence connman stays in the online state.

I guess this is the expected behaviour.

I would like to know if it is possible to instruct connman to connect all
available technologies, so that at startup it connects to the wired as well
as the wireless services and then decides which one to setup as the default
route.

Lastly, i would also like to know if connman performs periodic checks to
see if the service can go in the online state. i.e. when the state of the
manager is in the "ready", does connman periodically check if it can go
online?

Looking forward to your reply.

Thanks and Regards
~Sameer
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Autoconnect to a hidden wifi service.

[Sameer Naik]

Hello,

I am using connman-1.12 on a STB platform.
I have implemented a connman client and agent to handle connecting to wired
and wireless services via connman.

I am currently testing connections to hidden wireless services. Right now i
am able to connect to hidden wifi services after responding to the
RequestInput method of the agent.

What i have noticed is that once i connect to a hidden network the
configuration file is created. But when i restart the device or restart
connman for that matter, the system will not automatically connect to the
(already configured) hidden service. Even when the service configuration is
saved.

I am wondering whether connman is supposed to be able to autoconnect to
this hidden wifi service or is this the expected behaviour.

Thanks and Regards
~Sameer
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: [PATCH] doc: Update overview-api.txt

[Sameer Naik]

Works for me, but i think you should address it from the point of view of
Hidden networks and then expand it to say that the grouping also applies to
networks with the same SSID / Authentication methods. Since it is more
likely that a user is going to encounter this situation with hidden
networks, than with named networks.

Regards
~Sameer


On Tue, Feb 26, 2013 at 12:45 PM, Tomasz Bursztyka <
tomasz.burszt...@linux.intel.com> wrote:

> Hi Sameer,
>
>  Hello Tomasz,
>>
>> In the patch you have mentioned that:
>> A hidden service will be named as "Hidden".
>>
>> In my tests i have found that a hidden network does not have a Name
>> dictionary entry at all.
>>
>
> Indeed, was too keen on trusting what my UI tells ;-)
>
> Will change that. Thanks for the notice.
>
> Btw, is the rest clear enough or should it be rephrased/detailed?
>
> Tomasz
>
>
> __**_
> connman mailing list
> connman@connman.net
> http://lists.connman.net/**listinfo/connman
>
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: [PATCH] doc: Update overview-api.txt

[Sameer Naik]

For example:
struct {
 object path
"/net/connman/service/wifi_00e04c06dc8e_hidden_managed_wep"
 array [
dict entry(
   string "Type"
   variant   string "wifi"
)
dict entry(
   string "Security"
   variant   array [
 string "wep"
  ]
)
dict entry(
   string "State"
   variant   string "idle"
)
dict entry(
   string "Strength"
   variant   byte 53
)
dict entry(
   string "Favorite"
   variant   boolean false
)
dict entry(
   string "Immutable"
   variant   boolean false
)
dict entry(
   string "AutoConnect"
   variant   boolean false
)
dict entry(
   string "Ethernet"
   variant   array [
 dict entry(
string "Method"
variantstring "auto"
 )
 dict entry(
string "Interface"
variantstring "wlan0"
 )
 dict entry(
string "Address"
variantstring
"00:E0:4C:06:DC:8E"
 )
 dict entry(
string "MTU"
variantuint16 1500
 )
  ]
)
dict entry(
   string "IPv4"
   variant   array [
  ]
)
dict entry(
   string "IPv4.Configuration"
   variant   array [
 dict entry(
string "Method"
variantstring "dhcp"
 )
  ]
)
dict entry(
   string "IPv6"
   variant   array [
  ]
)
dict entry(
   string "IPv6.Configuration"
   variant   array [
 dict entry(
string "Method"
variantstring "off"
 )
  ]
)
dict entry(
   string "Nameservers"
   variant   array [
  ]
)
dict entry(
   string "Nameservers.Configuration"
   variant   array [
  ]
)
dict entry(
   string "Timeservers"
   variant   array [
  ]
)
dict entry(
   string "Timeservers.Configuration"
   variant   array [
  ]
)
dict entry(
   string "Domains"
   variant   array [
  ]
)
dict entry(
   string "Domains.Configuration"
   variant   array [
  ]
)
dict entry(
   string "Proxy"
   variant   array [
  ]
)
    dict entry(
   string "Proxy.Configuration"
   variant   array [
  ]
)
dict entry(
   string "Provider"
   variant   array [
  ]
)
 ]
  }


On Tue, Feb 26, 2013 at 9:29 AM, Sameer Naik <
sameer.subscripti...@damagehead.com> wrote:

> Hello Tomasz,
>
> In the patch you have mentioned that:
> A hidden service will be named as "Hidden".
>
> In my tests i have found that a hidden network does not have a Name
> dictionary entry at all.
>
> Regards
> ~Sameer
>
>
> On Mon, Feb 25, 2013 at 7:56 PM, Tomasz Bursztyka <
> tomasz.burszt...@linux.intel.com> wrote:
>
>> - Introduce the user t

Re: [PATCH] doc: Update overview-api.txt

[Sameer Naik]

Hello Tomasz,

In the patch you have mentioned that:
A hidden service will be named as "Hidden".

In my tests i have found that a hidden network does not have a Name
dictionary entry at all.

Regards
~Sameer


On Mon, Feb 25, 2013 at 7:56 PM, Tomasz Bursztyka <
tomasz.burszt...@linux.intel.com> wrote:

> - Introduce the user to per SSID/Security Wifi networks grouping
> - Agent is no longer a future feature and user should be aware of how he
> can provide required information when connecting to a service.
> ---
>
> Please review,
>
> Is it sufficiently understandable for non-connman maintainers?
>
>  doc/overview-api.txt | 25 +
>  1 file changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/doc/overview-api.txt b/doc/overview-api.txt
> index 14fec14..32b8894 100644
> --- a/doc/overview-api.txt
> +++ b/doc/overview-api.txt
> @@ -197,7 +197,7 @@ included in this list. They will only show up once a
> carrier is detected.
>
>  The service interface is not meant for basic device configuration task. So
>  switching a device on and off (via RFKILL for example) should be done via
> -the device interface.
> +the technology interface.
>
>  Due to limited screen size of small devices and the big amount of WiFi
>  access points that are deployed right now it might be sensible to not show
> @@ -219,6 +219,18 @@ In case of WiFi this will be the SSID value. The SSID
> is a binary array and
>  will be converted into printable form. Unprintable characters are replaced
>  with spaces.
>
> +In addition to WiFi naming, a specific grouping policy is performed per
> SSID
> +and security type. Which means, for n wifi networks providing the same
> SSID
> +and the same security: this will be seen under one and only one service.
> For
> +instance, if 5 AP servicing SSID TEST with WPA2 authentication method and
> 2
> +AP servicing the same SSID with open authentication method are present,
> the
> +user will see only 2 services listed with the same name TEST but
> differentiated
> +by their security type: psk and none. Such policy is also applied to
> hidden
> +networks, at that point the user has to connect to the right listed
> security
> +typed hidden service, so the agent will be requested for the name of the
> +network to connect to (See "Application basics" below). A hidden service
> will
> +be named as "Hidden".
> +
>  For Bluetooth the device alias is used. The alias is different since it
>  can be overwritten by the user via the Bluetooth service. The
> identification
>  is still done based on its address, but the display name might change. In
> @@ -376,9 +388,14 @@ will result in an error if no cable is plugged in.
> All connection attempts
>  can fail for one reason or another. Application should be able to handle
>  such errors and will also be notified of changes via signals.
>
> -In future versions Connection Manager will interact with an agent to
> confirm
> -certain transactions with the user. This functionality is currently not
> -implemented.
> +Connection Manager will interact with an agent to confirm certain
> transactions
> +with the user. If ConnMan needs extra information, ConnMan will ask the
> user
> +for exactly the information it requires: passphrase, network's name (for
> hidden
> +ones) and more depending on the use case (WPS, EAP, ...).
> +So all the request from the agent are 1:1 question that a user should
> answer.
> +Therefore, all application dealing with ConnMan might implement an agent
> +following the right API (see agent-api.txt) to interactively answer to
> +ConnMan's requests.
>
>  To monitor the current status of a service the state property can be
> used. It
>  gives detailed information about the current progress.
> --
> 1.8.1.2
>
> ___
> connman mailing list
> connman@connman.net
> http://lists.connman.net/listinfo/connman
>
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: Unable to get the gateway of a service that is not the default route.

[Sameer Naik]

Thanks for your responses.
Really appreciate it.

Regards
~Sameer


On Mon, Feb 25, 2013 at 7:38 PM, Daniel Wagner  wrote:

> On 25.02.2013 14:59, Patrik Flykt wrote:
>
>> On Mon, 2013-02-25 at 14:29 +0100, Marcel Holtmann wrote:
>>
>>> I am getting the feeling that we might really need to start setting
>>> all
>>> gateways all the time, but have different metrics attached to them.
>>>
>>
>> That we probably could do, provided it'd work to some degree of "as
>> expected".
>>
>>  One case that bugs me a little bit is the fact if we have a 3G
>>> connection and want to switch to WiFi, but that needs to external page
>>> outside the IP range of the hotspot. A dedicated application or
>>> browser
>>> for logging into that hotspot should be able to use that gateway from
>>> that network interface if it chooses to.
>>>
>>> How this can be done best and if routing metrics would actually work,
>>> I
>>> do not know for sure actually. Something we might need to try.
>>>
>>
>> IIRC the routing metrics are there just to order between the default
>> routes. I can't remember which way binding to an interface was biased,
>> did it anyway follow the first route out or did it obey the default
>> route for the interface in question. A quick test should expose it's
>> inner workings.
>>
>> Wagi/Jukka were seen to be working on multiple routing table support for
>> sessions a longer time ago.
>>
>
> FWIW, I have a patches which allow per app routing now. I am working on
> some more iptables fixes and then I can resend them.
>
> cheers,
> daniel
>
> __**_
> connman mailing list
> connman@connman.net
> http://lists.connman.net/**listinfo/connman
>
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: UI implemetation for connecting to a hidden network

[Sameer Naik]

Thanks for all the responses.
This was really helpful.

~Cheers
Sameer


On Mon, Feb 25, 2013 at 7:11 PM, Tomasz Bursztyka <
tomasz.burszt...@linux.intel.com> wrote:

> Hi Marcel,
>
>  Maybe we can improve the documentation then, you are not the first one
>>> who asks about that.
>>>
>> we should do exactly that. Explain in the agent documentation how hidden
>> WiFi networks are handled. Can you take care of this?
>>
>>
>>
> Sure.
>
> Tomasz
>
> __**_
> connman mailing list
> connman@connman.net
> http://lists.connman.net/**listinfo/connman
>
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: Unable to get the gateway of a service that is not the default route.

[Sameer Naik]

On Mon, Feb 25, 2013 at 7:17 PM, Patrik Flykt
wrote:

> On Mon, 2013-02-25 at 18:24 +0530, Sameer Naik wrote:
> > 192.168.1.1 * 255.255.255.255 UH0  00 eth0
> > 192.168.6.1 * 255.255.255.255 UH0  00 wlan0
>
> These are individual host routes to the DNS servers. In normal
> circumstances the DNS server is co-located to the DHCP server box, at
> least with normal home networking.
>
> > By looking up the service that is currently in the online state, i
> > would be
> > able to tell which is the default route (provided that only one
> > service is
> > in the online at any given time,
>
> The first service in the service list is the one with the default route
> and also the only one which can be online. Otherwise...
>
> >  which right now is not always the case).
>
> ...you have found a bug, I believe.
>
> I may be wrong about this... i will need to recheck.

>
> Cheers,
>
> Patrik
>
> ___
> connman mailing list
> connman@connman.net
> http://lists.connman.net/listinfo/connman
>
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: UI implemetation for connecting to a hidden network

[Sameer Naik]

Thanks Tomasz,

That was really helpful. The pieces of the puzzle seem to be coming
together for me.

On Mon, Feb 25, 2013 at 6:13 PM, Tomasz Bursztyka <
tomasz.burszt...@linux.intel.com> wrote:

> Hi Sameer,
>
>  Now, this is fine if there is only one hidden network listed. Say for
>> example there are 2 hidden networks, user would have a difficult time
>> figuring out the networks they are suppposed to connect to. Of course you
>> can take a best guess based on the security being used, the signal
>> strength, etc. Once you start having a lot more hidden wifi networks
>> listed
>> it becomes a lot more difficult to figure out the network the user needs
>> to
>> select.
>>
>>
> There cannot be more hidden services than handled security i.e.: psk, wep,
> open.
>
> Services are grouped by security. You could have 100 hidden service, if
> all are wpa/wpa2 --> you will see only 1 hidden service on security psk.
>

I had no idea about this. I imagined that each hidden service would be
listed. Your response makes a lot of send to me now.


> It works exactly the same for non-hidden services.
>
> Now for you issue, of course you can specify the name of the hidden
> network you are trying to connect to. For such thing you need to implement
> the agent API.
> Take a look at doc/agent-api.txt
>

I have implemented the agent api and have been testing the same.

Thanks again. Your reply was really helpful.

Regards
~Sameer

>
> Br,
>
> Tomasz
> __**_
> connman mailing list
> connman@connman.net
> http://lists.connman.net/**listinfo/connman
>
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: Unable to get the gateway of a service that is not the default route.

[Sameer Naik]

Hello Patrik,

But shouldn't the gateway returned for each service be the route setup for
the interface on which the service is running (at least display purposes)

ie.
192.168.1.1 *   255.255.255.255 UH0  00 eth0
192.168.6.1 *   255.255.255.255 UH0  00
wlan0

By looking up the service that is currently in the online state, i would be
able to tell which is the default route (provided that only one service is
in the online at any given time, which right now is not always the case).

Of course, i should be able to get the gateway information using socket
api's or something for my display purposes. But i believe connman would do
a better job at it ;)

Regards
~Sameer



On Mon, Feb 25, 2013 at 6:03 PM, Patrik Flykt
wrote:

>
> Hi,
>
> On Mon, 2013-02-25 at 17:32 +0530, Sameer Naik wrote:
> > I found that when i connect both the wired and wifi technologies (i.e.
> > connect to a service for each), only one of them goes in the online
> > state.
> > Both will be never enter the online state under normal circumstances.
> >
> > eg.
> > 1. Start connman with lan cable connected
> >   Connman connects to the lan network and enter the online state
> > 2. Connect to a wireless service
> >   Connman connects to the wireless service, and the service
> > remains in
> > the offline state until the ethernet cable is disconnected.
> >
> > This is probably a behaviour by design and i can understand why it is
> > this
> > way. One of the reason being that only one interface can
> > serve as the default route at a time, etc.
>
> Your observation is correct, only one default route is set at a time. As
> a default route is defined as matching every packet and sending the
> packets to the gateway, only one gateway is set at any time. So only the
> service which has the default route will contain gateway information.
> Thus the network information provided by all services is identical to
> what can be read from the routing table.
>
> Cheers,
>
> Patrik
>
> ___
> connman mailing list
> connman@connman.net
> http://lists.connman.net/listinfo/connman
>
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

UI implemetation for connecting to a hidden network

[Sameer Naik]

Hello,

I am using connman-1.11 on a STB platform.
I have some general questions regarding the UI implementation for
connecting to hidden wifi networks.

Currently in connman, i can list all the wifi services and filter out the
hidden services and let the user select the service that he/she may want to
connect to.
When the user selects the service, the connect method is called on the
service and connman then asks the user to input the Name/SSID and the
passphrase, etc.

Now, this is fine if there is only one hidden network listed. Say for
example there are 2 hidden networks, user would have a difficult time
figuring out the networks they are suppposed to connect to. Of course you
can take a best guess based on the security being used, the signal
strength, etc. Once you start having a lot more hidden wifi networks listed
it becomes a lot more difficult to figure out the network the user needs to
select.

So my question is...
Is it possible to specify the network we want to connect to by specifying
the Name/SSID of the network and connman figures out the rest. Something
along the lines of http://screencloud.net/v/Qcu

Thanks and Regards
~Sameer
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: Unable to get the gateway of a service that is not the default route.

[Sameer Naik]

I forgot to mention one thing, i have
PreferredTechnologies = ethernet
in my main.conf.


On Mon, Feb 25, 2013 at 5:32 PM, Sameer Naik <
sameer.subscripti...@damagehead.com> wrote:

> Hello,
>
> I am using connman-1.11 on an STB platform that has an inbuilt LAN port.
> For WIFI i am using a wifi dongle.
>  So far i have got every thing working fine. I am able to connect to wired
> and wireless networks. I am currently testing the stuff out and
> understanding some connman behaviour patterns along the way.
>
> I found that when i connect both the wired and wifi technologies (i.e.
> connect to a service for each), only one of them goes in the online state.
> Both will be never enter the online state under normal circumstances.
>
> eg.
> 1. Start connman with lan cable connected
>   Connman connects to the lan network and enter the online state
> 2. Connect to a wireless service
>   Connman connects to the wireless service, and the service remains in
> the offline state until the ethernet cable is disconnected.
>
> This is probably a behaviour by design and i can understand why it is this
> way. One of the reason being that only one interface can
> serve as the default route at a time, etc.
>
> But what i noticed is that, if i get the ipv4 configuration for each of
> the technologies, only the service that is on currently serving as the
> default route return the gateway.
> To make my point clearer, please refer to the output of GetServices method
> at http://pastebin.com/DVkXJiNB. You will notice that of the 2 connected
> services, only the wired service returns the gateway address.
>
> Is this by design? Is possible to get the gateway for services that are in
> READY state??
>
> Thanks and Regards
> ~Sameer
>
>
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Unable to get the gateway of a service that is not the default route.

[Sameer Naik]

Hello,

I am using connman-1.11 on an STB platform that has an inbuilt LAN port.
For WIFI i am using a wifi dongle.
So far i have got every thing working fine. I am able to connect to wired
and wireless networks. I am currently testing the stuff out and
understanding some connman behaviour patterns along the way.

I found that when i connect both the wired and wifi technologies (i.e.
connect to a service for each), only one of them goes in the online state.
Both will be never enter the online state under normal circumstances.

eg.
1. Start connman with lan cable connected
  Connman connects to the lan network and enter the online state
2. Connect to a wireless service
  Connman connects to the wireless service, and the service remains in
the offline state until the ethernet cable is disconnected.

This is probably a behaviour by design and i can understand why it is this
way. One of the reason being that only one interface can
serve as the default route at a time, etc.

But what i noticed is that, if i get the ipv4 configuration for each of the
technologies, only the service that is on currently serving as the default
route return the gateway.
To make my point clearer, please refer to the output of GetServices method
at http://pastebin.com/DVkXJiNB. You will notice that of the 2 connected
services, only the wired service returns the gateway address.

Is this by design? Is possible to get the gateway for services that are in
READY state??

Thanks and Regards
~Sameer
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: Unable to connect to open wireless networks

[Sameer Naik]

Here is the driver download link if required:
http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PFid=48&Level=5&Conn=4&ProdID=277&DownTypeID=3&GetDown=false&Downloads=true


On Tue, Feb 12, 2013 at 6:08 PM, Sameer Naik <
sameer.subscripti...@damagehead.com> wrote:

> Hello Patrik,
>
> I am using a wireless USB dongle that has a realtek 8291cu chipset. The
> driver in use was realtek's 8192cu driver and the version is
> v3.4.4_4749.20120730. The driver is downloadable from the following
> location:
>
> http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PFid=48&Level=5&Conn=4&ProdID=277&DownTypeID=3&GetDown=false&Downloads=true
>
> I am using linux-2.6.22, the newer kernels have this driver within the
> kernel (i think).
> The wpa_supplicant i am using is version 1.1, but the issue existed with
> wpa_supplicant version 1.0 and 0.7.3 as well.
>
> The connman version in use is 1.11 release version.
>
> Regards
> ~Sameer
>
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: Unable to connect to open wireless networks

[Sameer Naik]

Hello Patrik,

I am using a wireless USB dongle that has a realtek 8291cu chipset. The
driver in use was realtek's 8192cu driver and the version is
v3.4.4_4749.20120730. The driver is downloadable from the following
location:
http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PFid=48&Level=5&Conn=4&ProdID=277&DownTypeID=3&GetDown=false&Downloads=true

I am using linux-2.6.22, the newer kernels have this driver within the
kernel (i think).
The wpa_supplicant i am using is version 1.1, but the issue existed with
wpa_supplicant version 1.0 and 0.7.3 as well.

The connman version in use is 1.11 release version.

Regards
~Sameer
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: Unable to connect to open wireless networks

[Sameer Naik]

Hi Patrik and Tomasz,

I just downgraded my wireless device driver to the older version and
suddenly i am able to connect to open wireless networks.
With the newer driver I was not able to connect to open wireless networks
using connman, but was able to do so using the wpa_cli tool.
I will be switching to the older driver for now. However do let me know if
need me to perform any tests.

Thanks and Regards
~Sameer


On Mon, Feb 11, 2013 at 7:03 PM, Sameer Naik <
sameer.subscripti...@damagehead.com> wrote:

> Hello Tomasz,
>
> Please find attached connman.log and wpa_supplicant.log file generated in
> the same run.
>
> Regards
> ~Sameer
>
>
> On Mon, Feb 11, 2013 at 6:00 PM, Tomasz Bursztyka <
> tomasz.burszt...@linux.intel.com> wrote:
>
>> Hi Sameer,
>>
>> Could you send wpa_supplicant's log as well? run it with -dd option so
>> you get a lot of debug.
>>
>> From what I saw in your connman's log, the state transition went from
>> associtating/connecting to disconnected.
>> So we will get more clues from wpa_supplicant logs about the reasons why
>> you've got such transition.
>>
>> Thanks,
>>
>> Tomasz
>>
>> __**_
>> connman mailing list
>> connman@connman.net
>> http://lists.connman.net/**listinfo/connman<http://lists.connman.net/listinfo/connman>
>>
>
>
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: Unable to connect to open wireless networks

[Sameer Naik]

Hello Patrik,

Even after removing -W wext switch from the connmand command line the issue
persists.
Right now i am using wpa_supplicant-1.1.

Regards
~Sameer


On Mon, Feb 11, 2013 at 1:02 PM, Patrik Flykt
wrote:

> On Sun, 2013-02-10 at 22:41 +0530, Sameer Naik wrote:
> > $ connmand -W wext -I eth0 -n -d
>
> Does it help if you omit the -W switch? With a fairly recent
> wpa_supplicant, this switch isn't necessary.
>
> Cheers,
>
> Patrik
> ___
> connman mailing list
> connman@connman.net
> http://lists.connman.net/listinfo/connman
>
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: DNS caching probably not working in dnsproxy.

[Sameer Naik]

Please ignore this.


On Fri, Feb 1, 2013 at 6:38 PM, Sameer Naik <
sameer.subscripti...@damagehead.com> wrote:

> Hi,
>
> I am testing connman-1.10 and i get the following warnings when i try to
> resolve a dns address.
>
>  START OF LOG
> connmand[2815]: src/dnsproxy.c:udp_listener_event() Received 32 bytes (id
> 0x090c)
> connmand[2815]: src/dnsproxy.c:parse_request() id 0x090c qr 0 opcode 0
> qdcount 1 arcount 0
> connmand[2815]: src/dnsproxy.c:parse_request() query www.google.com.
> connmand[2815]: src/dnsproxy.c:resolv() server 192.168.1.1 enabled 1
>
> GLib-CRITICAL **: g_hash_table_lookup: assertion `hash_table != NULL'
> failed
> connmand[2815]: src/dnsproxy.c:forward_dns_reply() Received 196 bytes (id
> 0x1629)
> connmand[2815]: src/dnsproxy.c:forward_dns_reply() req 0x4daba8 dstid
> 0x1629 altid 0xe285 rcode 0
> connmand[2815]: src/dnsproxy.c:cache_update() offset 0 hdr 0x7fa9fb68 msg
> 0x7fa9fb68 rcode 0
> connmand[2815]: src/dnsproxy.c:parse_response() qr 1 qdcount 1
>
> GLib-CRITICAL **: g_hash_table_lookup: assertion `hash_table != NULL'
> failed
>
> GLib-CRITICAL **: g_hash_table_insert_internal: assertion `hash_table !=
> NULL' failed
> connmand[2815]: src/dnsproxy.c:cache_update() cache 5 new question
> "wwwgooglecom" type 28 ttl 293 size 125 packet 62 dns len 62
> connmand[2815]: src/dnsproxy.c:forward_dns_reply() proto 17 sent 196 bytes
> to 9
> connmand[2815]: src/dnsproxy.c:udp_listener_event() Received 32 bytes (id
> 0x9f96)
> connmand[2815]: src/dnsproxy.c:parse_request() id 0x9f96 qr 0 opcode 0
> qdcount 1 arcount 0
> connmand[2815]: src/dnsproxy.c:parse_request() query www.google.com.
> connmand[2815]: src/dnsproxy.c:resolv() server 192.168.1.1 enabled 1
>
> GLib-CRITICAL **: g_hash_table_lookup: assertion `hash_table != NULL'
> failed
> connmand[2815]: src/dnsproxy.c:forward_dns_reply() Received 248 bytes (id
> 0x6ebe)
> connmand[2815]: src/dnsproxy.c:forward_dns_reply() req 0x4daba8 dstid
> 0x6ebe altid 0x5fc0 rcode 0
> connmand[2815]: src/dnsproxy.c:cache_update() offset 0 hdr 0x7fa9fb68 msg
> 0x7fa9fb68 rcode 0
> connmand[2815]: src/dnsproxy.c:parse_response() qr 1 qdcount 1
>
> GLib-CRITICAL **: g_hash_table_lookup: assertion `hash_table != NULL'
> failed
>
> GLib-CRITICAL **: g_hash_table_insert_internal: assertion `hash_table !=
> NULL' failed
> connmand[2815]: src/dnsproxy.c:cache_update() cache 6 new question
> "wwwgooglecom" type 1 ttl 293 size 177 packet 114 dns len 114
> connmand[2815]: src/dnsproxy.c:forward_dns_reply() proto 17 sent 248 bytes
> to 9
>  END OF LOG
>
> It looks like there is some problem in DNS caching. Maybe the cache
> GHashTable is not initialized.
> Earlier i had glib assertion checks disabled due to which connman ended by
> crashing.
>
> Regards
> ~Sameer
>
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

DNS caching probably not working in dnsproxy.

[Sameer Naik]

Hi,

I am testing connman-1.10 and i get the following warnings when i try to
resolve a dns address.

 START OF LOG
connmand[2815]: src/dnsproxy.c:udp_listener_event() Received 32 bytes (id
0x090c)
connmand[2815]: src/dnsproxy.c:parse_request() id 0x090c qr 0 opcode 0
qdcount 1 arcount 0
connmand[2815]: src/dnsproxy.c:parse_request() query www.google.com.
connmand[2815]: src/dnsproxy.c:resolv() server 192.168.1.1 enabled 1

GLib-CRITICAL **: g_hash_table_lookup: assertion `hash_table != NULL' failed
connmand[2815]: src/dnsproxy.c:forward_dns_reply() Received 196 bytes (id
0x1629)
connmand[2815]: src/dnsproxy.c:forward_dns_reply() req 0x4daba8 dstid
0x1629 altid 0xe285 rcode 0
connmand[2815]: src/dnsproxy.c:cache_update() offset 0 hdr 0x7fa9fb68 msg
0x7fa9fb68 rcode 0
connmand[2815]: src/dnsproxy.c:parse_response() qr 1 qdcount 1

GLib-CRITICAL **: g_hash_table_lookup: assertion `hash_table != NULL' failed

GLib-CRITICAL **: g_hash_table_insert_internal: assertion `hash_table !=
NULL' failed
connmand[2815]: src/dnsproxy.c:cache_update() cache 5 new question
"wwwgooglecom" type 28 ttl 293 size 125 packet 62 dns len 62
connmand[2815]: src/dnsproxy.c:forward_dns_reply() proto 17 sent 196 bytes
to 9
connmand[2815]: src/dnsproxy.c:udp_listener_event() Received 32 bytes (id
0x9f96)
connmand[2815]: src/dnsproxy.c:parse_request() id 0x9f96 qr 0 opcode 0
qdcount 1 arcount 0
connmand[2815]: src/dnsproxy.c:parse_request() query www.google.com.
connmand[2815]: src/dnsproxy.c:resolv() server 192.168.1.1 enabled 1

GLib-CRITICAL **: g_hash_table_lookup: assertion `hash_table != NULL' failed
connmand[2815]: src/dnsproxy.c:forward_dns_reply() Received 248 bytes (id
0x6ebe)
connmand[2815]: src/dnsproxy.c:forward_dns_reply() req 0x4daba8 dstid
0x6ebe altid 0x5fc0 rcode 0
connmand[2815]: src/dnsproxy.c:cache_update() offset 0 hdr 0x7fa9fb68 msg
0x7fa9fb68 rcode 0
connmand[2815]: src/dnsproxy.c:parse_response() qr 1 qdcount 1

GLib-CRITICAL **: g_hash_table_lookup: assertion `hash_table != NULL' failed

GLib-CRITICAL **: g_hash_table_insert_internal: assertion `hash_table !=
NULL' failed
connmand[2815]: src/dnsproxy.c:cache_update() cache 6 new question
"wwwgooglecom" type 1 ttl 293 size 177 packet 114 dns len 114
connmand[2815]: src/dnsproxy.c:forward_dns_reply() proto 17 sent 248 bytes
to 9
 END OF LOG

It looks like there is some problem in DNS caching. Maybe the cache
GHashTable is not initialized.
Earlier i had glib assertion checks disabled due to which connman ended by
crashing.

Regards
~Sameer
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: Connman does not automatically switch to Wired LAN

[Sameer Naik]

Thanks Jeff and Patrik.

I was missing the main.conf file. After adding it as per your suggestions
its working.
As suggested by Patrik i have set
PreferredTechnologies = ethernet
SingleConnectedTechnology = false
in main.conf

First impression is that it works.
But i am facing a really weird issue that the /dev/null device gets deleted
when the lan cable is plugged out. When the lan cable is plugged in a
regular file named /dev/null is created which also vanishes after a while,
then it reappears again after some time as a regular file and finally
vanishes again, never to return. Then again if i unplug the lan cable and
plug it back in the same vanishing act takes place, i.e. it appears as a
regular file -> dissapears -> reappears -> dissapears.

I am not sure what to make of this.

If i stop connman, and use ifconfig to configure the lan interface the same
thing happens. So it should have something to do with connman. A bug in the
kernel maybe??? I you guys have any ideas please share..

Thanks and Regards
~Sameer


On Thu, Jan 31, 2013 at 1:12 PM, Patrik Flykt
wrote:

> On Thu, 2013-01-31 at 01:40 +, Zheng, Jeff wrote:
> > SingleConnectedTechnology = true
>
> That one is not recommended and should not be used in normal devices. It
> only lets the _last_ connected connection to be used and thus prevents
> the detection and usage of another technolgy that could go online.
> Definitely do not use this, you get a much worse connectivity experience
> from ConnMan.
>
> It's enough to define PreferredTechnologies = ethernet in main.conf if
> there is no difference between the other network technologies.
>
> Cheers,
>
> Patrik
>
>
> ___
> connman mailing list
> connman@connman.net
> http://lists.connman.net/listinfo/connman
>
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: [PATCH 0/2] DNS proxy removal - take two

[Sameer Naik]

Hello Patrik,

I applied the two patches and found the issue is gone. dnsproxy is
able to resolve DNS addresses between wifi dongle hotplugs.
I have attached the log generated of the whole sequence in case it is
of any use.

Regards
~Sameer

On Wed, Nov 21, 2012 at 7:55 PM,   wrote:
> From: Patrik Flykt 
>
> Hi,
>
> From one of the logs submitted (thanks!), I picked up the following debug
> output sequence:
>
> connmand[3519]: src/service.c:service_indicate_state() service 0x92a8548 old 
> association - new disconnect/disconnect => disconnect
> connmand[3519]: src/session.c:service_state_changed() service 0x92a8548 state 
> 6
> connmand[3519]: src/provider.c:provider_service_changed() service 0x92a8548 
> cellular_255030604034779_context1 state 6 index 14/-1
> ...
> connmand[3519]: src/wispr.c:__connman_wispr_stop() service 0x92a8548
> connmand[3519]: src/wispr.c:free_connman_wispr_portal()
> connmand[3519]: src/wispr.c:free_connman_wispr_portal_context() context (nil)
> connmand[3519]: src/wispr.c:free_connman_wispr_portal_context() context (nil)
> connmand[3519]: src/wpad.c:__connman_wpad_stop() service 0x92a8548
> connmand[3519]: src/notifier.c:__connman_notifier_disconnect() type 6
>
> From the code in service.c, the following function calls are made:
>
> service->state = new_state;
> state_changed(service);
> ...
> } else if (new_state == CONNMAN_SERVICE_STATE_DISCONNECT) {
> def_service = __connman_service_get_default();
>
> if (__connman_notifier_is_connected() == FALSE &&
> def_service != NULL &&
> def_service->provider != NULL)
> __connman_provider_disconnect(def_service->provider);
>
> default_changed();
>
> __connman_wispr_stop(service);
>
> __connman_wpad_stop(service);
>
> update_nameservers(service);
> dns_changed(service);
> domain_changed(service);
>
> __connman_notifier_disconnect(service->type);
>
> After stopping wispr and wpad, nameservers are updated next. But as
> can be seen from the logs, no nameserver related information is printed
> and no nameservers removed. In update_nameservers(), the interface
> name is fetched with __connman_ipconfig_get_ifname(). This function in
> turn looks up the ipconfig, but if the interface itself is already down,
> no such info is available.
>
> The same happens with the earlier patch I sent. When trying to get
> the interface name using connman_inet_ifname(), the debug output
> stated that the interface name is NULL:
>
> connmand[1251]: src/service.c:update_nameservers() service 0x4d2778 index 5 
> ifname (null) ipconfig ipv4 0x4d26b8 ipv6 0x4d2730
>
> This happens when the interface already removed.
>
> It appears to be fixed by changing the code to use interface indexes
> instead of interface names in all places. With this kind of change
> there is no dependency on the already removed/cleared ipconfig structure
> nor the need to look up the interface name using an ioctl which fails
> with the interface being removed already.
>
> To test, apply both patches and see if the problem persists. The second
> patch is just there to help with any further debugging.
>
>
> Cheers,
>
> Patrik
>
>
> Patrik Flykt (2):
>   core: Use interface index instead of interface name
>   service: Add debug messages to see the network index
>
>  include/resolver.h |8 +--
>  src/connman.h  |   14 ++---
>  src/dnsproxy.c |  160 
> 
>  src/resolver.c |  133 ---
>  src/rtnl.c |   17 ++
>  src/service.c  |   75 +++-
>  src/tethering.c|7 ++-
>  7 files changed, 203 insertions(+), 211 deletions(-)
>
> --
> 1.7.10.4
>
> ___
> connman mailing list
> connman@connman.net
> http://lists.connman.net/listinfo/connman


connman.log.tar.xz
Description: Binary data
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: [PATCH] Temporary failure in name resolution

[Sameer Naik]

Hello,

Let me know if i can be of any help.

Regards
~Sameer

On Tue, Nov 20, 2012 at 2:53 PM, Patrik Flykt
 wrote:
> On Mon, 2012-11-19 at 20:56 +0530, Sameer Naik wrote:
>> I took the latest git (86f2151)
>
> Thanks!
>
>> and applied
>> "service-Look-up-interface-name-from-index.patch" on top of it.
>> The problem still exists.
>
> Yep. That patch doesn't work any better than the original code in
> upstream. Have to have a better look on what's going on.
>
> Cheers,
>
> Patrik
>
>
> ___
> connman mailing list
> connman@connman.net
> http://lists.connman.net/listinfo/connman
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: [PATCH] Temporary failure in name resolution

[Sameer Naik]

Hello,

This is connman-1.9 with following patches applied
 1. supplicant-Handle-race-condition-on-WiFi-dongle-remo.patch
 2. wifi-Handle-D-Bus-method-call-failure.patch
 3. service-Look-up-interface-name-from-index.patch

Regards
~Sameer
On Mon, Nov 19, 2012 at 5:12 PM, Patrik Flykt
 wrote:
>
> Hi,
>
> On Fri, 2012-11-16 at 19:32 +0530, Sameer Naik wrote:
>
>> I tested the patch, but the issue still exists.
>
> From the longer log I notice that the issue is not the same. Which
> version of ConnMan is this actually?
>
> Cheers,
>
> Patrik
>
> ___
> connman mailing list
> connman@connman.net
> http://lists.connman.net/listinfo/connman
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: Connman 1.9 won't attempt connecting to wifi service

[Sameer Naik]

Hi,

On Mon, Nov 12, 2012 at 1:07 PM, Patrik Flykt
 wrote:
> On Mon, 2012-11-12 at 11:31 +0530, Sameer Naik wrote:
>> Passphrase="my psk password"

I used to specify the password without the quote before. But i made a
mistake, i mistook the connect-failed error to be related to
wpa-supplicant-1.0 upgrade. Frequent "connect-failed" errors lead me
to believe that it was because of the wpa_supplicant update. Its
sorted now, ASCII pass phrases do work after the wpa_supplicant
update. Earlier, the invalid-key error was due to a wpa_supplicant
config option.

I also updated the wifi driver with the latest sources. I have not
noticed any changes in the behaviour ATM. However there were a _LOT_
of changes in the driver.

Regarding the frequent 'connect-failed' error at observed, i have the
following observations:

Test Procedure:
1. Start connmand with wifi plugged in
2. Check if connection established or failed
3. Disconnect wifi dongle
4. Connect wifi dongle
5. repeat 2.

1. If i launch connmand with the -d option, i.e.
# connmand -W wext -I eth0 -n -d
, then the connection works 90% of the time. Rarely there is a
connect-failed error.

2. If i launch connmand without the -d option, i.e.
# connmand -W wext -I eth0 -n
, then the connection works 50% of the time.

Attached is the log generated for Case 2. In this log you will notice
that every alternate connection attempt fails.
Typically connman is launched at boot time without the '-n -d' options
which more or less is represented by Case 2.

Could there be a race condition occurring for this issue to show up?
which occurs less frequently due to the large number of debugs printed
when -d is specified.

Hopefully these test results will throw some light on the cause of this issue.

Thanks and Regards
~Sameer

>
> With the quotation marks attached, ConnMan will think the quotation
> marks are part of the passphrase. Just try with:
>
> Passphrase=my psk password
>
> Does that fix the problem?
>
> Cheers,
>
> Patrik
>
> ___
> connman mailing list
> connman@connman.net
> http://lists.connman.net/listinfo/connman


connmand.log
Description: Binary data
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: Connman 1.9 won't attempt connecting to wifi service

[Sameer Naik]

Hi,

They means the wifi chip manufacturer, Realtek.

Regards
~Sameer

On Mon, Nov 12, 2012 at 12:55 PM, Patrik Flykt
 wrote:
>
> Hi,
>
> On Fri, 2012-11-09 at 21:37 +0530, Sameer Naik wrote:
>> They actually have an updated driver released for the chip.
>
> When you say "they" here, do you mean some particular vendor (which
> one?) or a newer version of the Linux kernel?
>
> Cheers,
>
> Patrik
>
> ___
> connman mailing list
> connman@connman.net
> http://lists.connman.net/listinfo/connman
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: DNS problem

[Sameer Naik]

Hello All,

I am also noticing the same issue. Except in my case, i am using a USB
wifi dongle.
If i unplug the usb dongle and plug it back in, dnsproxy is no longer
able to perform DNS resolutions.

Yevhen, my _TEMPORARY_ workaround for this is to disable use of
dnsproxy until this is fixed. This done by specifying the --nodnsproxy
option to the connmand command line.

Regards
~Sameer

On Sun, Nov 11, 2012 at 7:47 AM, Yevhen Kyriukha  wrote:
> Hi!
>
> I connect to internet using 3G modem.
> For that purpose I use connman and ofono.
> I set "auto connect" property for my 3G connection, so that connman
> reconnects if connection is lost.
>
> The problem is when I connect to internet second and further times (after
> reconnection), I can't access any host by its name (only by IP address).
>
> I'm getting "Temprary failure in name resolution" error when I execute
> "wget ya.ru" command in console and the following messages in connman logs:
> 
> connmand[3519]: src/dnsproxy.c:udp_listener_event() Received 23 bytes (id
> 0xc19a)
> connmand[3519]: src/dnsproxy.c:parse_request() id 0xc19a qr 0 opcode 0
> qdcount 1 arcount 0
> connmand[3519]: src/dnsproxy.c:parse_request() query ya.ru.
> connmand[3519]: src/dnsproxy.c:resolv() server 193.41.63.162 enabled 1
> connmand[3519]: src/dnsproxy.c:ns_resolv() Cannot send message to server
> 193.41.63.162 sock 17 protocol 17 (Invalid argument/22)
> connmand[3519]: src/dnsproxy.c:resolv() server 193.41.60.18 enabled 1
> connmand[3519]: src/dnsproxy.c:ns_resolv() Cannot send message to server
> 193.41.60.18 sock 18 protocol 17 (Invalid argument/22)
> connmand[3519]: src/dnsproxy.c:request_timeout() id 0xc19a
> 
>
> I attached debug logs of connman and ofono to this message.
>
> --
> Best regards,
> Yevhen
>
> ___
> connman mailing list
> connman@connman.net
> http://lists.connman.net/listinfo/connman
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: Connman 1.9 won't attempt connecting to wifi service

[Sameer Naik]

Hello Patrik,

On Fri, Nov 9, 2012 at 1:38 PM, Patrik Flykt
 wrote:
>
> Hi,
>
> On Fri, 2012-11-09 at 11:38 +0530, Sameer Naik wrote:
>> I noticed that connman had appended
>> a line 'Failure=invalid-key' in the settings file of the saved wifi
>> profile due to which the connection was not happening even after
>> restarting connman multiple times.
>
> ConnMan won't autoconnect to a network that has been marked failed. One
> option is to successfully connect manually for example from the command
> line to get the failure mark removed.
>
>> I had to remove that line for it to
>> start working again.
>
> That works also. In general it is advisable not to edit any files
> in /var/lib/connman/*/* as their format can change without any notice.
>
> Any /var/lib/connman/*.config file is another matter, those are used for
> WiFi provisioning. If you had provisioned the WiFi network, simply
> removing the .config file and adding it back would make ConnMan first to
> remove the failed service and then to recreate a new service for it. The
> new service would not have the baggage of invalid keys failure attached.
>
>> I would have expected that connman would attempt connecting to the
>> service at least once and figure out whether the key was invalid or
>> not and then stop connection attempts to the service if the key was
>> found to be invalid.
>
> Yep, exactly this happened.
>
>> At the moment I don't have an agent registered,
>> so i don't know if there is something more that occurs in this case.
>
> The agent is needed should ConnMan need a passphrase or any other input
> from the user. If everything is preprovisioned
> in /var/lib/connman/*.config files, ConnMan needs nothing from the
> Agent.
>
>> The condition that occured in my case was purely a side effect of
>> being in developer mode. I am not sure if this could occur in
>> production mode.
>
> ConnMan does not know about the product being in developer of production
> mode, thus it thought the invalid key was a valid reason.
>
>> One last thing, Is connman compatible with wpa_supplicant-1.0?
>
> Yes, up and running here at the moment.

I think i found out why connman would not work after upgrading to
wpa_supplicant-1.0. What i noticed is that connections will not happen
if the passphrase is specified in ASCII format. For example i created
a config file named aircrack.conf with the following config.

[service_aircrack]
Type=wifi
Name=aircrack
Passphrase="my psk password"

I put quotes around the passphrase to indicate that is was specified
in ASCII (but i dont think connman cares about the quotes). With this
config, the connection would always fail. So i used wpa_passphrase to
generate coded passphrase and changed the above config to the
following:

[service_aircrack]
Type=wifi
Name=aircrack
Passphrase=025f1e0cf5b394d09c35e8e47c0da00346b8a9a4450d001b7952070f623ad804

After this connman was able to connect to the wifi network. With
wpa-supplicant-0.7.3 i was able to use ASCII passphrases in connman
configs. But after the update it does not seem to work.

I also checked if i was able to specify ASCII passphrases using
wpa_cli (wpa_supplicant was configured to use the file interface) and
ASCII passphrases worked just fine with wpa_supplicant and wpa_cli.

>From the above it looks like connman is not able to work with ASCII
passwords when used with wpa_supplicant-1.0 or i am missing some
configuration.

Regards
~Sameer

>
> Cheers,
>
> Patrik
>
> ___
> connman mailing list
> connman@connman.net
> http://lists.connman.net/listinfo/connman
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: Connman 1.9 won't attempt connecting to wifi service

[Sameer Naik]

Hello,

On Fri, Nov 9, 2012 at 6:37 PM, Patrik Flykt
 wrote:
>
> Hi,
>
> On Fri, 2012-11-09 at 14:55 +0530, Sameer Naik wrote:
>
>> 1. Read about /var/lib/connman/*.config files.
>
> The .config files would be a good place to set up networks which should
> work unattended. Much better than editing the settings files directly.
I was playing around with the settings file because i don't have a
client app implemented yet. I was not aware of the .config files.

>
>> 2. Figure out what wpa_supplicant-1.0 won't work for me.
>>
>> There is one other issue i am seeing:
>> I have setup connman to start at boot up using init scripts and have
>> some saved wifi connection profiles to which an automatic connection
>> is expected. But almost always the connection fails at start up and
>> the line 'Failure=connect-failed' appears in the settings file.
>
> These two seem to be the same thing. wpa_supplicant works ok, but the
> wifi kernel driver might be doing something else. What WiFi driver are
> you using, it seems to be something not-so-standard, since you have
> explicitely specified '-W wext' in the previous mails? Which kernel
> driver is in use if there are more than one option?
The wext driver is the one in use. The command that i specified is the
actual command in use without the '-n -d' options.

>
>> I have
>> to restart connman for the connection to happen or unplug and plug the
>> usb wifi device for the connection to occur (which frequently crashes,
>> reported earlier).
>
> Did you check if the patches I sent to the mailing list will fix this?
>
I had not noticed the patch. Applied now and the crash issue is fixed.
But i noticed an issue with the dnsproxy that i have mentioned in
response to the patch.

>> I have generated a log of this (please find attached). In the log the
>> service i should auto connect is located in
>> /etc/connman/wifi_00e04c06dc8e_77656c636f6d652e746f2e6e62636c_managed_psk,
>> but for some reason the connection is not happening.
>
> It starts to connect, but ends up with
> CONNMAN_SERVICE_ERROR_CONNECT_FAILED:
>
> connmand[948]: src/network.c:connman_network_set_error() network 0x4cef70 
> error 4
> connmand[948]: src/service.c:connman_service_lookup_from_network() network 
> 0x4cef70
> connmand[948]: src/service.c:__connman_service_indicate_error() service 
> 0x4c6d78 error 4
> connmand[948]: src/service.c:__connman_service_ipconfig_indicate_state() 
> service 0x4c6d78 
> (wifi_00e04c06dc8e_77656c636f6d652e746f2e6e62636c_managed_psk) state 7 
> (failure) type 1 (IPv4)
>
> This is the Failure=connect-failed you saw in the saved settings. What
> wifi chip does that USB dongle actually have?
The Wifi chip has a RTL8192cu chip. They actually have an updated
driver released for the chip. Will see if there are any improvements
after updating the driver to the latest version. However i am not
completely sure if this is an issue with the wifi chip. What i have
noticed is that there is not problem connecting to my home wifi
network at boot up. But the wifi there is some issue while connecting
to the test wifi network i setup at work. Maybe something to do with
the router.

Regards
~Sameer

>
> Cheers,
>
> Patrik
>
> ___
> connman mailing list
> connman@connman.net
> http://lists.connman.net/listinfo/connman
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: [PATCH 0/2] Connman 1.9 crashes when wifi dongle is unplugged.

[Sameer Naik]

Hello Patrik,

I can confirm that this patchset fixes the issue for me.
But i think unplugging and plugging back the wifi usb dongle causes
some issue in the dnsproxy. After the unplug -> plug cycle the
dnsproxy is no longer able to resolve hostnames and requires a
connmand restart. Please take a look at the log below. Let me know if
you need the full log to analyse this issue.

connmand[1790]: src/dnsproxy.c:parse_request() id 0xb6d6 qr 0 opcode 0
qdcount 1 arcount 0
connmand[1790]: src/dnsproxy.c:parse_request() query www.google.com.
connmand[1790]: src/dnsproxy.c:resolv() server 192.168.2.1 enabled 1
connmand[1790]: src/dnsproxy.c:ns_resolv() Cannot send message to
server 192.168.2.1 sock 16 protocol 17 (No such device/19)
connmand[1790]: src/dnsproxy.c:resolv() server 8.8.8.8 enabled 1
connmand[1790]: src/dnsproxy.c:ns_resolv() Cannot send message to
server 8.8.8.8 sock 17 protocol 17 (No such device/19)
connmand[1790]: src/dnsproxy.c:udp_listener_event() Received 32 bytes
(id 0xb6d6)
connmand[1790]: src/dnsproxy.c:parse_request() id 0xb6d6 qr 0 opcode 0
qdcount 1 arcount 0
connmand[1790]: src/dnsproxy.c:parse_request() query www.google.com.
connmand[1790]: src/dnsproxy.c:resolv() server 192.168.2.1 enabled 1
connmand[1790]: src/dnsproxy.c:ns_resolv() Cannot send message to
server 192.168.2.1 sock 16 protocol 17 (No such device/19)
connmand[1790]: src/dnsproxy.c:resolv() server 8.8.8.8 enabled 1
connmand[1790]: src/dnsproxy.c:ns_resolv() Cannot send message to
server 8.8.8.8 sock 17 protocol 17 (No such device/19)
connmand[1790]: src/dnsproxy.c:request_timeout() id 0xb6d6
connmand[1790]: src/dnsproxy.c:udp_listener_event() Received 32 bytes
(id 0x432a)
connmand[1790]: src/dnsproxy.c:parse_request() id 0x432a qr 0 opcode 0
qdcount 1 arcount 0
connmand[1790]: src/dnsproxy.c:parse_request() query www.google.com.
connmand[1790]: src/dnsproxy.c:resolv() server 192.168.2.1 enabled 1
connmand[1790]: src/dnsproxy.c:ns_resolv() Cannot send message to
server 192.168.2.1 sock 16 protocol 17 (No such device/19)
connmand[1790]: src/dnsproxy.c:resolv() server 8.8.8.8 enabled 1
connmand[1790]: src/dnsproxy.c:ns_resolv() Cannot send message to
server 8.8.8.8 sock 17 protocol 17 (No such device/19)
connmand[1790]: src/dnsproxy.c:request_timeout() id 0xb6d6


Thanks & Regards
~Sameer

On Fri, Nov 9, 2012 at 2:24 PM,   wrote:
> From: Patrik Flykt 
>
> Hi,
>
> It seems there is a race condition between rtnl and wpa_supplicant.
>
> The registered object path is gone when ConnMan tries to disconnect and
> remove the network from wpa_supplicant. Thus look out for D-Bus telling
> that the intended objec path is gone.
>
> The real problem behind this is that the struct wifi_data is given to the
> callback and is freed while either of the D-Bus method calls are in
> progress. But that takes some more time to fix.
>
> While testing, can you please export the CONNMAN_SUPPLICANT_DEBUG=1
> environment variable so we get the needed logging from the wifi plugin
> and the gsupplicant support code also?
>
> Thanks,
>
> Patrik
>
>
> Patrik Flykt (2):
>   supplicant: Handle race condition on WiFi dongle removal
>   wifi: Handle D-Bus method call failure
>
>  gsupplicant/supplicant.c |   25 +
>  plugins/wifi.c   |8 
>  2 files changed, 29 insertions(+), 4 deletions(-)
>
> --
> 1.7.10.4
>
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Connman 1.9 won't attempt connecting to wifi service

[Sameer Naik]

Hello,

Today i noticed one issue. I am not sure whether this is a bug or this
is by design.

I have a saved wifi profile with Autoconnect turned on and was able to
connect to that profile without any problems. Yesterday  i updated
wpa_supplicant to version 1.0 and found that connman was no longer
able to connect to by saved profile. So i reverted back to
wpa_supplicant-0.7.3 and noticed that connman was still not able to
connect to my saved wifi profile. I noticed that connman had appended
a line 'Failure=invalid-key' in the settings file of the saved wifi
profile due to which the connection was not happening even after
restarting connman multiple times. I had to remove that line for it to
start working again.

I would have expected that connman would attempt connecting to the
service at least once and figure out whether the key was invalid or
not and then stop connection attempts to the service if the key was
found to be invalid. At the moment I don't have an agent registered,
so i don't know if there is something more that occurs in this case.

The condition that occured in my case was purely a side effect of
being in developer mode. I am not sure if this could occur in
production mode.

One last thing, Is connman compatible with wpa_supplicant-1.0?
Lemme know.

Thanks and Regards
~Sameer
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: Connman 1.9 crashes when wifi dongle is unplugged.

[Sameer Naik]

Thanks Patrik.

On Thu, Nov 8, 2012 at 11:51 AM, Patrik Flykt
 wrote:
> On thu, 2012-11-08 at 11:37 +0530, Sameer Naik wrote:
>
>> I am trying file the bug, but bugs.meego.com freaked out while
>> registering a bugzilla account.
>> At the end of the registration it said that it was unable to send the
>> confirmation email and asked to contact the admin.
>> But i don't have the email address of the bugzilla admin and i could
>> not find it on bugs.meego.com either.
>>
>> So i am kinda stuck.
>
> Don't worry, Jeff can probably proxy the bug to bugzilla. I'll take a
> look at your email.
>
> Patrik
>
> ___
> connman mailing list
> connman@connman.net
> http://lists.connman.net/listinfo/connman
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: [PATCH 00/10] NTP overhaul

[Sameer Naik]

Hello,

I have a question regarding your latest work:

If user changes "TimeUpdates" to "manual" will the NTP sync be
stopped? If yes, then when user sets "TimeUpdates" to "auto", will NTP
sync be restarted?

Regards
~Sameer

On Wed, Mar 21, 2012 at 4:38 PM, Alok Barsode  wrote:
> From: Alok Barsode 
>
> Hi,
>
> The following set of patches rectify NTP behaviour. Here is the list
> of modifications/additions done.
>
> Patch1: Modify the behaviour of global timeservers. We now replace the
> older global timeservers with the new ones, instead of appending.
> Fixes bug #24997.
>
> Patch2: Instead of triggering NTP sync only on ONLINE state we trigger
> it when the default service changes. We also stop NTP sync when there
> is no default service, rather than when we are in DiSCONNECT state.This
> is helpful in a local ntp server setup, where we do not need to go ONLINE
> for a ntp sync.
>
> Patch3-6: Add Timeservers.Configuration Property to the service. We can
> override system timeservers using this property. Timeserver sync creates
> a list of timeservers to query, which consists of Timeservers.Configuration,
> service timeservers (via dhcp), the gateway and then the global timeservers,
> in that order. If any of these values changes, the timeserver sync is 
> reinvoked.
>
> patch:7-8: Add the Timeserves.Configuration documentation and unit test.
>
> patch:9: Trigger timeserver sync when the user sets the timezone.
>
> patch10: Reduce the NTP server failuer timer from 16 to 5 seconds.
> If the current ntp sync fails, connman waits for 16 seconds untill it
> tries the next server. shorteing this delay makes sense in the case of
> timezone settings, as the user does not have to wait for a long time (16 sec)
> for the timing updates, if the current NTP server fails.
>
>
> Cheers,
> Alok.
>
> Alok Barsode (10):
>  timeserver: Replace older system timeserver values with new ones
>    instead of appending
>  timeserver: Trigger ntp on default changed notifier
>  timeserver: Create timeserver list
>  timeserver: Add service gateway to timeserver list
>  service: Add Timeservers.Configuration Property.
>  timeserver: Add Timeservers.Configuration to timeserver list
>  doc: Add Timeserves.Configuration service property
>  test: Add set-timeservers
>  clock: Sync timeserver after timezone change
>  ntp: Shorten NTP failure delay
>
>  doc/service-api.txt  |   15 +++
>  include/service.h    |    1 +
>  include/timeserver.h |    3 +-
>  plugins/meego.c      |    4 +-
>  src/clock.c          |   18 +++-
>  src/connman.h        |    1 -
>  src/ntp.c            |    4 +-
>  src/service.c        |   72 +++-
>  src/timeserver.c     |  309 
> +-
>  test/set-timeservers |   20 
>  10 files changed, 277 insertions(+), 170 deletions(-)
>  create mode 100755 test/set-timeservers
>
> --
> 1.7.5.4
>
> ___
> connman mailing list
> connman@connman.net
> http://lists.connman.net/listinfo/connman
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: State of net.connman.Clock Timeservers

[Sameer Naik]

Hi,

Things i have noticed in the clock API.

1. If a timeserver is specified, using Timeservers property, that is
already in the global timeservers list. The time sync is not
restarted.
2. If the TimeUpdates property is set to manual and then back to auto,
the NTP sync is not started/restarted.

Regards
~Sameer

On Mon, Mar 5, 2012 at 10:18 AM, Marcel Holtmann  wrote:
> Hi Jeff,
>
>> > please refrain from top-posting here. No exceptions.
>> >
>> Oops, sorry.
>> >> I tried timeserver with latest connman and it seems to work for me. I can 
>> >> get time updated from timeserver.
>> >>
>> >> Could you please try connman test script set-global-timeservers?
>> >>
>> >> Though there is a small difference than old ntp plugin: It will append 
>> >> the new timerservers instead of override old ones.
>> > what does this mean? The global ones are just the default servers that
>> > will be used if DHCP does not provide NTP servers or if they are not
>> > working.
>> Here is the command list:
>> [root@localhost ~]# test-clock
>> Timeservers = [ ntp.meego.com ]
>> [root@localhost ~]# set-global-timeservers ntp.connman.net
>> Setting timeserver to ['ntp.connman.net']
>> [root@localhost ~]# test-clock
>> Timeservers = [ ntp.meego.com ntp.connman.net ]
>>
>> With old ntp plugin, Timeservers was just 'ntp.connman.net'
>
> and the old behavior was correct. This is a bug.
>
> Regards
>
> Marcel
>
>
> ___
> connman mailing list
> connman@connman.net
> http://lists.connman.net/listinfo/connman
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: ntp synchronization in READY state.

[Sameer Naik]

Hello Marcel,

Thanks for your response.

Is there a hard and fast way i can get this behaviour changed. If
required, can do away with the WISPr/online check so that it always
returns SUCCESS. You see the NTP sync is extremely important in my
case.

Regards
~Sameer

On Mon, Feb 27, 2012 at 10:42 PM, Marcel Holtmann  wrote:
> Hi Naik,
>
>> According to my understanding NTP synchronization will occur in
>> connman once service state is CONNMAN_SERVICE_STATE_ONLINE. Further
>> service will enter the online state once connman can communicate with
>> http://ipv4.connman.net/online/status.html.
>>
>> However in my case, generally an NTP server announced via dhcp and is
>> present on the local network. My device may not necessarily be
>> connected to the internet. So i need to start the ntp synchronization
>> before connman enters the ONLINE state.
>
> it is actually not that simple. If the NTP server is announced via DHCP
> and is in your local network, then we should do this in READY state.
>
> If it not announced via DHCP, we should try the router in READY state.
>
> In case we have a static NTP server list and it is in your local network
> (either DHCP or static configuration), we should try it in READY state.
>
> If both are failing and the NTP server is not local, we should be doing
> NTP just before going into ONLINE. Meaning after WISPr/online check
> declared this connection online.
>
> Just to be clear here, the ONLINE state that ConnMan announces we are
> really online and we tried all possible methods to synchronize the time
> for you first. So right now, this is a bug actually. We need to wait NTP
> success (or failure) before we go ONLINE.
>
> Regards
>
> Marcel
>
>
> ___
> connman mailing list
> connman@connman.net
> http://lists.connman.net/listinfo/connman
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: [PATCH v3 0/4] Implement ServicesAdded and ServicesRemoved

[Sameer Naik]

Got it.. thanks for the fix.

On Mon, Feb 27, 2012 at 10:45 PM, Marcel Holtmann  wrote:
> Hi Sameer,
>
>> I am running the git version of connman and have the updates from this 
>> thread.
>> I have noticed that when the ServicesRemoved signal is emitted i see
>> the following message throw.
>>
>> (process:780): GLib-GIO-WARNING **: Dropping signal ServicesRemoved of type 
>> (ao)
>>  since the type from the expected interface is (a{o})
>
> that is a clear but in our introspection data. Fixed that now. The
> signal itself was correct with (ao).
>
> Regards
>
> Marcel
>
>
> ___
> connman mailing list
> connman@connman.net
> http://lists.connman.net/listinfo/connman
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

ntp synchronization in READY state.

[Sameer Naik]

Hello,

According to my understanding NTP synchronization will occur in
connman once service state is CONNMAN_SERVICE_STATE_ONLINE. Further
service will enter the online state once connman can communicate with
http://ipv4.connman.net/online/status.html.

However in my case, generally an NTP server announced via dhcp and is
present on the local network. My device may not necessarily be
connected to the internet. So i need to start the ntp synchronization
before connman enters the ONLINE state.

For this i made the following change:

 src/service.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/service.c b/src/service.c
index a21ee3f..e093340 100644
--- a/src/service.c
+++ b/src/service.c
@@ -4052,9 +4052,6 @@ static int service_indicate_state(struct
connman_service *service)
}
}

-   if (new_state == CONNMAN_SERVICE_STATE_ONLINE)
-   __connman_timeserver_sync(service);
-
if (new_state == CONNMAN_SERVICE_STATE_IDLE) {
connman_bool_t reconnect;

@@ -4157,6 +4154,9 @@ static int service_indicate_state(struct
connman_service *service)
if (new_state == CONNMAN_SERVICE_STATE_ONLINE)
default_changed();

+   if (new_state == CONNMAN_SERVICE_STATE_READY)
+   __connman_timeserver_sync(service);
+
return 0;
 }

That is to say, start  __connman_timeserver_sync once we are in the
READY state and dont wait for connman to go to ONLINE state.

But after this change, while trying to scan a wifi technology i
receiving the  error "GDBus.Error:net.connman.Error.NoCarrier: No
carrier" very frequently and i am required to stop connman and start
it again after which it is fine. I am finding it difficult to
understand why this is happening. I had made a similar edit for
connman-0.78 and it was working fine. Please find the attached
connman.log

Looking forward to your response.

Regards
~Sameer
$ connmand -n -d -W wext
connmand[743]: Connection Manager version 0.78
connmand[743]: src/dbus.c:__connman_dbus_init() 
connmand[743]: src/storage.c:storage_load() Loading /opt/resource/etc/connman/settings
connmand[743]: src/technology.c:__connman_technology_init() 
connmand[743]: src/storage.c:storage_load() Loading /opt/resource/etc/connman/settings
connmand[743]: src/notifier.c:__connman_notifier_init() 
connmand[743]: src/service.c:__connman_service_init() 
connmand[743]: src/provider.c:__connman_provider_init() 
connmand[743]: src/notifier.c:connman_notifier_register() notifier 0x4987e0 name provider
connmand[743]: src/network.c:__connman_network_init() 
connmand[743]: src/device.c:__connman_device_init() 
connmand[743]: src/agent.c:__connman_agent_init() 
connmand[743]: src/ippool.c:__connman_ippool_init() 
connmand[743]: src/iptables.c:__connman_iptables_init() 
connmand[743]: src/nat.c:__connman_nat_init() 
connmand[743]: src/notifier.c:connman_notifier_register() notifier 0x498b50 name nat
connmand[743]: src/iptables.c:__connman_iptables_command() command -t nat -F POSTROUTING argc 5
connmand[743]: src/iptables.c:iptables_init() nat
connmand[743]: src/iptables.c:iptables_command() Flush chain POSTROUTING
connmand[743]: src/iptables.c:__connman_iptables_commit() nat
connmand[743]: src/tethering.c:__connman_tethering_init() 
connmand[743]: src/counter.c:__connman_counter_init() 
connmand[743]: src/manager.c:__connman_manager_init() 
connmand[743]: src/notifier.c:connman_notifier_register() notifier 0x498480 name manager
connmand[743]: src/config.c:__connman_config_init() 
connmand[743]: src/config.c:read_configs() 
connmand[743]: src/stats.c:__connman_stats_init() 
connmand[743]: src/clock.c:__connman_clock_init() 
connmand[743]: src/timezone.c:__connman_timezone_init() 
connmand[743]: src/timezone.c:__connman_timezone_lookup() sysconfig zone (null)
connmand[743]: src/timezone.c:__connman_timezone_lookup() localtime zone (null)
connmand[743]: src/resolver.c:__connman_resolver_init() dnsproxy 1
connmand[743]: src/dnsproxy.c:__connman_dnsproxy_init() 
connmand[743]: src/dnsproxy.c:__connman_dnsproxy_add_listener() interface lo
connmand[743]: src/dnsproxy.c:create_dns_listener() interface lo
connmand[743]: No IPv6 support; DNS proxy listening only on Legacy IP
connmand[743]: Failed to bind UDP listener interface
connmand[743]: src/dnsproxy.c:create_dns_listener() interface lo
connmand[743]: No IPv6 support; DNS proxy listening only on Legacy IP
connmand[743]: Failed to bind TCP listener interface
connmand[743]: src/resolver.c:__connman_resolvfile_append() interface lo server 127.0.0.1
connmand[743]: src/notifier.c:connman_notifier_register() notifier 0x498b20 name dnsproxy
connmand[743]: src/ipconfig.c:__connman_ipconfig_init() 
connmand[743]: src/rtnl.c:__connman_rtnl_init() 
connmand[743]: src/task.c:__connman_task_init() 
connmand[743]: src/proxy.c:__connman_proxy_init() 
connmand[743]: src/detect.c:__connman_detect_init() 
connmand[743]: src/rtnl.c:connman_rtnl_register() rtnl 0x498810 

Re: Powered stated on on board ethernet technology is false.

[Sameer Naik]

Hello,

I can confirm that the patch patch fixes the issue.

Thanks
~Sameer

On Fri, Feb 24, 2012 at 4:50 PM, alok barsode  wrote:
> Hi,
>
> NACK for the patch.
>
> __connman_technology_enabled() should not create a technology if there isnt
> one. the device should land up in techless_device_list and must be later
> picked up by the technology when the tech _driver registers it.
>
> Here is my guess: from the logs i can see that
> connman_technology_add_device() calls __connman_device_enable() but since
> the device is already enabled, the calls does not propagate through to
> connman_device_set_powered.
>
> Can u apply the following patch and check if this solves the issue? I will
> will then post it on the ML for review.
>
>
> Thanks!
> Alok.
>
> On Fri, Feb 24, 2012 at 12:46 PM, Sameer Naik <
> sameer.subscripti...@damagehead.com> wrote:
>
>> Please review.
>>
>>
>> On Fri, Feb 24, 2012 at 3:56 PM, Sameer Naik
>>  wrote:
>> > Apparently the technology is being enabled before it is even in the
>> > technology_list. Since the technology cannot be found in the
>> > technology list, its enabled flag remains unset.
>> >
>> > On Fri, Feb 24, 2012 at 1:35 AM, Sameer Naik
>> >  wrote:
>> >> Hi,
>> >>
>> >> Have been trying to figure out what the issue is. No leads yet.
>> >>
>> >> One thing though is that the "Powered" state response to the dbus call
>> >> depends on whether the technology is enabled.
>> >>
>> >> if (technology->enabled > 0)
>> >>    powered = TRUE;
>> >>  else
>> >>    powered = FALSE;
>> >>
>> >> The logs show that the device is powered (as you pointed out). The
>> >> code flow shows that the technology is disabled.
>> >>
>> >> Regards
>> >> ~Sameer
>> >>
>> >> On Thu, Feb 23, 2012 at 10:38 PM, Sameer Naik
>> >>  wrote:
>> >>> Hello,
>> >>>
>> >>> Yes, this happens every single time. One thing worth noting is that i
>> >>> have my rootfs mounted over NFS. So the ethernet interface is already
>> >>> connected before connman starts up. Maybe this is causing the issue.
>> >>>
>> >>> I launch connman via boot scripts with the following command
>> >>>
>> >>> $ connmand -W wext
>> >>>
>> >>> Technologies enabled are: ethernet, wifi
>> >>> Plugins enabled are: ether google loopback wifi
>> >>>
>> >>> My settings file contains the following.
>> >>>
>> >>> [global]
>> >>> OfflineMode=false
>> >>> Timeservers=0.pool.ntp.org;1.pool.ntp.org;2.pool.ntp.org;
>> 3.pool.ntp.org
>> >>>
>> >>> [WiFi]
>> >>> Enable=true
>> >>>
>> >>> [Bluetooth]
>> >>> Enable=false
>> >>>
>> >>> [Wired]
>> >>> Enable=true
>> >>>
>> >>> [3G]
>> >>> Enable=false
>> >>>
>> >>> [WiMAX]
>> >>> Enable=false
>> >>>
>> >>> Regards
>> >>> ~Sameer
>> >>>
>> >>> On Thu, Feb 23, 2012 at 5:09 PM, alok barsode 
>> wrote:
>> >>>> Hi,
>> >>>>
>> >>>> On Thu, Feb 23, 2012 at 11:11 AM, Sameer Naik <
>> >>>> sameer.subscripti...@damagehead.com> wrote:
>> >>>>
>> >>>>> Hello Alok,
>> >>>>>
>> >>>>> Please find attached connman.log file.
>> >>>>> Do let me know if you need me to generate logs for specific modules.
>> >>>>>
>> >>>>>
>> >>>> Thanks for the log. I can see connman_device_set_powered() powered 1
>> called
>> >>>> on the ethernet device. so i dont know why it shows powered=false.
>> >>>> I am not able to repordude this problem. Do u see this every time ?
>>  How
>> >>>> can i reproduce this? any specific setup? what does ur
>> >>>> /var/lib/connman/settings
>> >>>> say?
>> >>>>
>> >>>>
>> >>>> Cheers,
>> >>>> Alok.
>> >>>>
>> >>>>
>> >>>> Regards
>> >>>>> ~Sameer
>> >&g

Re: Powered stated on on board ethernet technology is false.

[Sameer Naik]

Please review.


On Fri, Feb 24, 2012 at 3:56 PM, Sameer Naik
 wrote:
> Apparently the technology is being enabled before it is even in the
> technology_list. Since the technology cannot be found in the
> technology list, its enabled flag remains unset.
>
> On Fri, Feb 24, 2012 at 1:35 AM, Sameer Naik
>  wrote:
>> Hi,
>>
>> Have been trying to figure out what the issue is. No leads yet.
>>
>> One thing though is that the "Powered" state response to the dbus call
>> depends on whether the technology is enabled.
>>
>> if (technology->enabled > 0)
>>    powered = TRUE;
>>  else
>>    powered = FALSE;
>>
>> The logs show that the device is powered (as you pointed out). The
>> code flow shows that the technology is disabled.
>>
>> Regards
>> ~Sameer
>>
>> On Thu, Feb 23, 2012 at 10:38 PM, Sameer Naik
>>  wrote:
>>> Hello,
>>>
>>> Yes, this happens every single time. One thing worth noting is that i
>>> have my rootfs mounted over NFS. So the ethernet interface is already
>>> connected before connman starts up. Maybe this is causing the issue.
>>>
>>> I launch connman via boot scripts with the following command
>>>
>>> $ connmand -W wext
>>>
>>> Technologies enabled are: ethernet, wifi
>>> Plugins enabled are: ether google loopback wifi
>>>
>>> My settings file contains the following.
>>>
>>> [global]
>>> OfflineMode=false
>>> Timeservers=0.pool.ntp.org;1.pool.ntp.org;2.pool.ntp.org;3.pool.ntp.org
>>>
>>> [WiFi]
>>> Enable=true
>>>
>>> [Bluetooth]
>>> Enable=false
>>>
>>> [Wired]
>>> Enable=true
>>>
>>> [3G]
>>> Enable=false
>>>
>>> [WiMAX]
>>> Enable=false
>>>
>>> Regards
>>> ~Sameer
>>>
>>> On Thu, Feb 23, 2012 at 5:09 PM, alok barsode  wrote:
>>>> Hi,
>>>>
>>>> On Thu, Feb 23, 2012 at 11:11 AM, Sameer Naik <
>>>> sameer.subscripti...@damagehead.com> wrote:
>>>>
>>>>> Hello Alok,
>>>>>
>>>>> Please find attached connman.log file.
>>>>> Do let me know if you need me to generate logs for specific modules.
>>>>>
>>>>>
>>>> Thanks for the log. I can see connman_device_set_powered() powered 1 called
>>>> on the ethernet device. so i dont know why it shows powered=false.
>>>> I am not able to repordude this problem. Do u see this every time ?  How
>>>> can i reproduce this? any specific setup? what does ur
>>>> /var/lib/connman/settings
>>>> say?
>>>>
>>>>
>>>> Cheers,
>>>> Alok.
>>>>
>>>>
>>>> Regards
>>>>> ~Sameer
>>>>>
>>>>> On Thu, Feb 23, 2012 at 1:18 PM, alok barsode 
>>>>> wrote:
>>>>> > Hi Sameer,
>>>>> >
>>>>> > On Thu, Feb 23, 2012 at 7:47 AM, Sameer Naik <
>>>>> > sameer.subscripti...@damagehead.com> wrote:
>>>>> >
>>>>> >> Hi,
>>>>> >>
>>>>> >> I have a system with on board ethernet and using connman git head.
>>>>> >> When i query the technology it says Powered state is "false" and at
>>>>> >> the same time "Connected" state is "true."
>>>>> >>
>>>>> >> $ dbus-send --system --print-reply --dest=net.connman /net/c
>>>>> >> onnman/technology/ethernet net.connman.Technology.GetProperties
>>>>> >> method return sender=:1.0 -> dest=:1.27 reply_serial=2
>>>>> >>   array [
>>>>> >>      dict entry(
>>>>> >>         string "Name"
>>>>> >>         variant             string "Wired"
>>>>> >>      )
>>>>> >>      dict entry(
>>>>> >>         string "Type"
>>>>> >>         variant             string "ethernet"
>>>>> >>      )
>>>>> >>      dict entry(
>>>>> >>         string "Powered"
>>>>> >>         variant             boolean false
>>>>> >>      )
>>>>> >>      dict entry(
>>>>> >>         

Re: Powered stated on on board ethernet technology is false.

[Sameer Naik]

Apparently the technology is being enabled before it is even in the
technology_list. Since the technology cannot be found in the
technology list, its enabled flag remains unset.

On Fri, Feb 24, 2012 at 1:35 AM, Sameer Naik
 wrote:
> Hi,
>
> Have been trying to figure out what the issue is. No leads yet.
>
> One thing though is that the "Powered" state response to the dbus call
> depends on whether the technology is enabled.
>
> if (technology->enabled > 0)
>    powered = TRUE;
>  else
>    powered = FALSE;
>
> The logs show that the device is powered (as you pointed out). The
> code flow shows that the technology is disabled.
>
> Regards
> ~Sameer
>
> On Thu, Feb 23, 2012 at 10:38 PM, Sameer Naik
>  wrote:
>> Hello,
>>
>> Yes, this happens every single time. One thing worth noting is that i
>> have my rootfs mounted over NFS. So the ethernet interface is already
>> connected before connman starts up. Maybe this is causing the issue.
>>
>> I launch connman via boot scripts with the following command
>>
>> $ connmand -W wext
>>
>> Technologies enabled are: ethernet, wifi
>> Plugins enabled are: ether google loopback wifi
>>
>> My settings file contains the following.
>>
>> [global]
>> OfflineMode=false
>> Timeservers=0.pool.ntp.org;1.pool.ntp.org;2.pool.ntp.org;3.pool.ntp.org
>>
>> [WiFi]
>> Enable=true
>>
>> [Bluetooth]
>> Enable=false
>>
>> [Wired]
>> Enable=true
>>
>> [3G]
>> Enable=false
>>
>> [WiMAX]
>> Enable=false
>>
>> Regards
>> ~Sameer
>>
>> On Thu, Feb 23, 2012 at 5:09 PM, alok barsode  wrote:
>>> Hi,
>>>
>>> On Thu, Feb 23, 2012 at 11:11 AM, Sameer Naik <
>>> sameer.subscripti...@damagehead.com> wrote:
>>>
>>>> Hello Alok,
>>>>
>>>> Please find attached connman.log file.
>>>> Do let me know if you need me to generate logs for specific modules.
>>>>
>>>>
>>> Thanks for the log. I can see connman_device_set_powered() powered 1 called
>>> on the ethernet device. so i dont know why it shows powered=false.
>>> I am not able to repordude this problem. Do u see this every time ?  How
>>> can i reproduce this? any specific setup? what does ur
>>> /var/lib/connman/settings
>>> say?
>>>
>>>
>>> Cheers,
>>> Alok.
>>>
>>>
>>> Regards
>>>> ~Sameer
>>>>
>>>> On Thu, Feb 23, 2012 at 1:18 PM, alok barsode 
>>>> wrote:
>>>> > Hi Sameer,
>>>> >
>>>> > On Thu, Feb 23, 2012 at 7:47 AM, Sameer Naik <
>>>> > sameer.subscripti...@damagehead.com> wrote:
>>>> >
>>>> >> Hi,
>>>> >>
>>>> >> I have a system with on board ethernet and using connman git head.
>>>> >> When i query the technology it says Powered state is "false" and at
>>>> >> the same time "Connected" state is "true."
>>>> >>
>>>> >> $ dbus-send --system --print-reply --dest=net.connman /net/c
>>>> >> onnman/technology/ethernet net.connman.Technology.GetProperties
>>>> >> method return sender=:1.0 -> dest=:1.27 reply_serial=2
>>>> >>   array [
>>>> >>      dict entry(
>>>> >>         string "Name"
>>>> >>         variant             string "Wired"
>>>> >>      )
>>>> >>      dict entry(
>>>> >>         string "Type"
>>>> >>         variant             string "ethernet"
>>>> >>      )
>>>> >>      dict entry(
>>>> >>         string "Powered"
>>>> >>         variant             boolean false
>>>> >>      )
>>>> >>      dict entry(
>>>> >>         string "Connected"
>>>> >>         variant             boolean true
>>>> >>      )
>>>> >>      dict entry(
>>>> >>         string "Tethering"
>>>> >>         variant             boolean false
>>>> >>      )
>>>> >>   ]
>>>> >>
>>>> >> We definitely need more info that this, connman logs, setup details.
>>>> > Its very tough to say what the problem is just from a dbus-send output.
>>>> >
>>>> >
>>>> >
>>>> >> Regards
>>>> >> ~Sameer
>>>> >>
>>>> >
>>>> > Cheers,
>>>> > Alok.
>>>> >
>>>> >> ___
>>>> >> connman mailing list
>>>> >> connman@connman.net
>>>> >> http://lists.connman.net/listinfo/connman
>>>> >>
>>>> > ___
>>>> > connman mailing list
>>>> > connman@connman.net
>>>> > http://lists.connman.net/listinfo/connman
>>>>
>>>> ___
>>>> connman mailing list
>>>> connman@connman.net
>>>> http://lists.connman.net/listinfo/connman
>>>>
>>> ___
>>> connman mailing list
>>> connman@connman.net
>>> http://lists.connman.net/listinfo/connman
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: Powered stated on on board ethernet technology is false.

[Sameer Naik]

Hi,

Have been trying to figure out what the issue is. No leads yet.

One thing though is that the "Powered" state response to the dbus call
depends on whether the technology is enabled.

if (technology->enabled > 0)
powered = TRUE;
  else
powered = FALSE;

The logs show that the device is powered (as you pointed out). The
code flow shows that the technology is disabled.

Regards
~Sameer

On Thu, Feb 23, 2012 at 10:38 PM, Sameer Naik
 wrote:
> Hello,
>
> Yes, this happens every single time. One thing worth noting is that i
> have my rootfs mounted over NFS. So the ethernet interface is already
> connected before connman starts up. Maybe this is causing the issue.
>
> I launch connman via boot scripts with the following command
>
> $ connmand -W wext
>
> Technologies enabled are: ethernet, wifi
> Plugins enabled are: ether google loopback wifi
>
> My settings file contains the following.
>
> [global]
> OfflineMode=false
> Timeservers=0.pool.ntp.org;1.pool.ntp.org;2.pool.ntp.org;3.pool.ntp.org
>
> [WiFi]
> Enable=true
>
> [Bluetooth]
> Enable=false
>
> [Wired]
> Enable=true
>
> [3G]
> Enable=false
>
> [WiMAX]
> Enable=false
>
> Regards
> ~Sameer
>
> On Thu, Feb 23, 2012 at 5:09 PM, alok barsode  wrote:
>> Hi,
>>
>> On Thu, Feb 23, 2012 at 11:11 AM, Sameer Naik <
>> sameer.subscripti...@damagehead.com> wrote:
>>
>>> Hello Alok,
>>>
>>> Please find attached connman.log file.
>>> Do let me know if you need me to generate logs for specific modules.
>>>
>>>
>> Thanks for the log. I can see connman_device_set_powered() powered 1 called
>> on the ethernet device. so i dont know why it shows powered=false.
>> I am not able to repordude this problem. Do u see this every time ?  How
>> can i reproduce this? any specific setup? what does ur
>> /var/lib/connman/settings
>> say?
>>
>>
>> Cheers,
>> Alok.
>>
>>
>> Regards
>>> ~Sameer
>>>
>>> On Thu, Feb 23, 2012 at 1:18 PM, alok barsode 
>>> wrote:
>>> > Hi Sameer,
>>> >
>>> > On Thu, Feb 23, 2012 at 7:47 AM, Sameer Naik <
>>> > sameer.subscripti...@damagehead.com> wrote:
>>> >
>>> >> Hi,
>>> >>
>>> >> I have a system with on board ethernet and using connman git head.
>>> >> When i query the technology it says Powered state is "false" and at
>>> >> the same time "Connected" state is "true."
>>> >>
>>> >> $ dbus-send --system --print-reply --dest=net.connman /net/c
>>> >> onnman/technology/ethernet net.connman.Technology.GetProperties
>>> >> method return sender=:1.0 -> dest=:1.27 reply_serial=2
>>> >>   array [
>>> >>      dict entry(
>>> >>         string "Name"
>>> >>         variant             string "Wired"
>>> >>      )
>>> >>      dict entry(
>>> >>         string "Type"
>>> >>         variant             string "ethernet"
>>> >>      )
>>> >>      dict entry(
>>> >>         string "Powered"
>>> >>         variant             boolean false
>>> >>      )
>>> >>      dict entry(
>>> >>         string "Connected"
>>> >>         variant             boolean true
>>> >>      )
>>> >>      dict entry(
>>> >>         string "Tethering"
>>> >>         variant             boolean false
>>> >>      )
>>> >>   ]
>>> >>
>>> >> We definitely need more info that this, connman logs, setup details.
>>> > Its very tough to say what the problem is just from a dbus-send output.
>>> >
>>> >
>>> >
>>> >> Regards
>>> >> ~Sameer
>>> >>
>>> >
>>> > Cheers,
>>> > Alok.
>>> >
>>> >> ___
>>> >> connman mailing list
>>> >> connman@connman.net
>>> >> http://lists.connman.net/listinfo/connman
>>> >>
>>> > ___
>>> > connman mailing list
>>> > connman@connman.net
>>> > http://lists.connman.net/listinfo/connman
>>>
>>> ___
>>> connman mailing list
>>> connman@connman.net
>>> http://lists.connman.net/listinfo/connman
>>>
>> ___
>> connman mailing list
>> connman@connman.net
>> http://lists.connman.net/listinfo/connman
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: Powered stated on on board ethernet technology is false.

[Sameer Naik]

Hello,

Yes, this happens every single time. One thing worth noting is that i
have my rootfs mounted over NFS. So the ethernet interface is already
connected before connman starts up. Maybe this is causing the issue.

I launch connman via boot scripts with the following command

$ connmand -W wext

Technologies enabled are: ethernet, wifi
Plugins enabled are: ether google loopback wifi

My settings file contains the following.

[global]
OfflineMode=false
Timeservers=0.pool.ntp.org;1.pool.ntp.org;2.pool.ntp.org;3.pool.ntp.org

[WiFi]
Enable=true

[Bluetooth]
Enable=false

[Wired]
Enable=true

[3G]
Enable=false

[WiMAX]
Enable=false

Regards
~Sameer

On Thu, Feb 23, 2012 at 5:09 PM, alok barsode  wrote:
> Hi,
>
> On Thu, Feb 23, 2012 at 11:11 AM, Sameer Naik <
> sameer.subscripti...@damagehead.com> wrote:
>
>> Hello Alok,
>>
>> Please find attached connman.log file.
>> Do let me know if you need me to generate logs for specific modules.
>>
>>
> Thanks for the log. I can see connman_device_set_powered() powered 1 called
> on the ethernet device. so i dont know why it shows powered=false.
> I am not able to repordude this problem. Do u see this every time ?  How
> can i reproduce this? any specific setup? what does ur
> /var/lib/connman/settings
> say?
>
>
> Cheers,
> Alok.
>
>
> Regards
>> ~Sameer
>>
>> On Thu, Feb 23, 2012 at 1:18 PM, alok barsode 
>> wrote:
>> > Hi Sameer,
>> >
>> > On Thu, Feb 23, 2012 at 7:47 AM, Sameer Naik <
>> > sameer.subscripti...@damagehead.com> wrote:
>> >
>> >> Hi,
>> >>
>> >> I have a system with on board ethernet and using connman git head.
>> >> When i query the technology it says Powered state is "false" and at
>> >> the same time "Connected" state is "true."
>> >>
>> >> $ dbus-send --system --print-reply --dest=net.connman /net/c
>> >> onnman/technology/ethernet net.connman.Technology.GetProperties
>> >> method return sender=:1.0 -> dest=:1.27 reply_serial=2
>> >>   array [
>> >>      dict entry(
>> >>         string "Name"
>> >>         variant             string "Wired"
>> >>      )
>> >>      dict entry(
>> >>         string "Type"
>> >>         variant             string "ethernet"
>> >>      )
>> >>      dict entry(
>> >>         string "Powered"
>> >>         variant             boolean false
>> >>      )
>> >>      dict entry(
>> >>         string "Connected"
>> >>         variant             boolean true
>> >>      )
>> >>      dict entry(
>> >>         string "Tethering"
>> >>         variant             boolean false
>> >>      )
>> >>   ]
>> >>
>> >> We definitely need more info that this, connman logs, setup details.
>> > Its very tough to say what the problem is just from a dbus-send output.
>> >
>> >
>> >
>> >> Regards
>> >> ~Sameer
>> >>
>> >
>> > Cheers,
>> > Alok.
>> >
>> >> ___
>> >> connman mailing list
>> >> connman@connman.net
>> >> http://lists.connman.net/listinfo/connman
>> >>
>> > ___
>> > connman mailing list
>> > connman@connman.net
>> > http://lists.connman.net/listinfo/connman
>>
>> ___
>> connman mailing list
>> connman@connman.net
>> http://lists.connman.net/listinfo/connman
>>
> ___
> connman mailing list
> connman@connman.net
> http://lists.connman.net/listinfo/connman
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Powered stated on on board ethernet technology is false.

[Sameer Naik]

Hi,

I have a system with on board ethernet and using connman git head.
When i query the technology it says Powered state is "false" and at
the same time "Connected" state is "true."

$ dbus-send --system --print-reply --dest=net.connman /net/c
onnman/technology/ethernet net.connman.Technology.GetProperties
method return sender=:1.0 -> dest=:1.27 reply_serial=2
   array [
  dict entry(
 string "Name"
 variant string "Wired"
  )
  dict entry(
 string "Type"
 variant string "ethernet"
  )
  dict entry(
 string "Powered"
 variant boolean false
  )
  dict entry(
 string "Connected"
 variant boolean true
  )
  dict entry(
 string "Tethering"
 variant boolean false
  )
   ]

Regards
~Sameer
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: Wifi Technology says its offline when wifi dongle is unplugged and plugged back in

[Sameer Naik]

Nevermind. I have updated to git version. Apparently the API of the
git version is much refined (and does not suffer from the issues
present in the stable version).

On Wed, Feb 22, 2012 at 10:20 AM, Sameer Naik
 wrote:
> Hello,
>
> I am using the current stable version 0.78.
>
> Regards
> ~Sameer
>
> On Wed, Feb 22, 2012 at 1:15 AM, alok barsode  wrote:
>> Hi Sameer,
>>
>> On Tue, Feb 21, 2012 at 8:14 PM, Sameer Naik <
>> sameer.subscripti...@damagehead.com> wrote:
>>
>>> Hello,
>>>
>>> I seems that the technology state is not updated correctly.
>>> When i start connman and by ethernet connection is up and system is
>>> online, The ethernet technology says "enabled". I think it should be
>>> saying connected.
>>>
>>> For wifi, when the dongle is removed the State goes to offline. But on
>>> plugging it back in, it never goes to the enabled or connected states.
>>> This is until connman is relaunched.
>>>
>>> Is this a bug? or am i not understanding it right!
>>>
>>> what version of connman are u using ? we have moved to Powered and
>> Connected properties for technology. I think you seem to be using a older
>> version by what you are reporting.
>> here is what i get when I do a GetPropreties on wifi
>>
>> dbus-send --system --print-reply --dest=net.connman
>> /net/connman/technology/wifi net.connman.Technology.GetProperties
>> method return sender=:1.101 -> dest=:1.153 reply_serial=2
>>   array [
>>      dict entry(
>>         string "Name"
>>         variant             string "WiFi"
>>      )
>>      dict entry(
>>         string "Type"
>>         variant             string "wifi"
>>      )
>>      dict entry(
>>         string "Powered"
>>         variant             boolean true
>>      )
>>      dict entry(
>>         string "Connected"
>>         variant             boolean true
>>      )
>>      dict entry(
>>         string "Tethering"
>>         variant             boolean false
>>      )
>>   ]
>>
>>
>>
>>
>>> Regards
>>> ~Sameer
>>>
>>>
>>> Cheers,
>> Alok.
>>
>>> On Sun, Feb 19, 2012 at 1:10 PM, Sameer Naik
>>>  wrote:
>>> > Hi,
>>> >
>>> > if i connect a usb wifi dongle and start connman and query the wifi
>>> > technology as so:
>>> >
>>> > --
>>> > $ dbus-send --system --print-reply --dest=net.connman /net
>>> > /connman/technology/wifi net.connman.Technology.GetProperties.
>>> > $ dbus-send --system --print-reply --dest=net.connman /net
>>> > /connman/technology/wifi net.connman.Technology.GetProperties
>>> > method return sender=:1.172 -> dest=:1.174 reply_serial=2
>>> >   array [
>>> >      dict entry(
>>> >         string "State"
>>> >         variant             string "enabled"
>>> >      )
>>> >      dict entry(
>>> >         string "Name"
>>> >         variant             string "WiFi"
>>> >      )
>>> >      dict entry(
>>> >         string "Type"
>>> >         variant             string "wifi"
>>> >      )
>>> >      dict entry(
>>> >         string "Tethering"
>>> >         variant             boolean false
>>> >      )
>>> >   ]
>>> > -
>>> >
>>> > It lists that the state of the wifi technology is "enabled".  When i
>>> > remove the wifi dongle the Technology it says its "offline"
>>> >
>>> > But when i plug the dongle back in, it remains "offline" and does not
>>> > go to "enabled". However, if i get the manager properties using:
>>> >
>>> > $ dbus-send --system --print-reply --dest=net.connman  /
>>> > net.connman.Manager.GetProperties, wifi is listed under enabled
>>> > technologies.
>>> >
>>> > so in short, Manager says technology is "enabled", while Technology
>>> > says its "offline". Is this the expected behaviour?
>>> >
>>> > Regards
>>> > ~Sameer
>>> ___
>>> connman mailing list
>>> connman@connman.net
>>> http://lists.connman.net/listinfo/connman
>>>
>> ___
>> connman mailing list
>> connman@connman.net
>> http://lists.connman.net/listinfo/connman
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: Wifi Technology says its offline when wifi dongle is unplugged and plugged back in

[Sameer Naik]

Hello,

I am using the current stable version 0.78.

Regards
~Sameer

On Wed, Feb 22, 2012 at 1:15 AM, alok barsode  wrote:
> Hi Sameer,
>
> On Tue, Feb 21, 2012 at 8:14 PM, Sameer Naik <
> sameer.subscripti...@damagehead.com> wrote:
>
>> Hello,
>>
>> I seems that the technology state is not updated correctly.
>> When i start connman and by ethernet connection is up and system is
>> online, The ethernet technology says "enabled". I think it should be
>> saying connected.
>>
>> For wifi, when the dongle is removed the State goes to offline. But on
>> plugging it back in, it never goes to the enabled or connected states.
>> This is until connman is relaunched.
>>
>> Is this a bug? or am i not understanding it right!
>>
>> what version of connman are u using ? we have moved to Powered and
> Connected properties for technology. I think you seem to be using a older
> version by what you are reporting.
> here is what i get when I do a GetPropreties on wifi
>
> dbus-send --system --print-reply --dest=net.connman
> /net/connman/technology/wifi net.connman.Technology.GetProperties
> method return sender=:1.101 -> dest=:1.153 reply_serial=2
>   array [
>      dict entry(
>         string "Name"
>         variant             string "WiFi"
>      )
>      dict entry(
>         string "Type"
>         variant             string "wifi"
>      )
>      dict entry(
>         string "Powered"
>         variant             boolean true
>      )
>      dict entry(
>         string "Connected"
>         variant             boolean true
>      )
>      dict entry(
>         string "Tethering"
>         variant             boolean false
>      )
>   ]
>
>
>
>
>> Regards
>> ~Sameer
>>
>>
>> Cheers,
> Alok.
>
>> On Sun, Feb 19, 2012 at 1:10 PM, Sameer Naik
>>  wrote:
>> > Hi,
>> >
>> > if i connect a usb wifi dongle and start connman and query the wifi
>> > technology as so:
>> >
>> > --
>> > $ dbus-send --system --print-reply --dest=net.connman /net
>> > /connman/technology/wifi net.connman.Technology.GetProperties.
>> > $ dbus-send --system --print-reply --dest=net.connman /net
>> > /connman/technology/wifi net.connman.Technology.GetProperties
>> > method return sender=:1.172 -> dest=:1.174 reply_serial=2
>> >   array [
>> >      dict entry(
>> >         string "State"
>> >         variant             string "enabled"
>> >      )
>> >      dict entry(
>> >         string "Name"
>> >         variant             string "WiFi"
>> >      )
>> >      dict entry(
>> >         string "Type"
>> >         variant             string "wifi"
>> >      )
>> >      dict entry(
>> >         string "Tethering"
>> >         variant             boolean false
>> >      )
>> >   ]
>> > -
>> >
>> > It lists that the state of the wifi technology is "enabled".  When i
>> > remove the wifi dongle the Technology it says its "offline"
>> >
>> > But when i plug the dongle back in, it remains "offline" and does not
>> > go to "enabled". However, if i get the manager properties using:
>> >
>> > $ dbus-send --system --print-reply --dest=net.connman  /
>> > net.connman.Manager.GetProperties, wifi is listed under enabled
>> > technologies.
>> >
>> > so in short, Manager says technology is "enabled", while Technology
>> > says its "offline". Is this the expected behaviour?
>> >
>> > Regards
>> > ~Sameer
>> ___
>> connman mailing list
>> connman@connman.net
>> http://lists.connman.net/listinfo/connman
>>
> ___
> connman mailing list
> connman@connman.net
> http://lists.connman.net/listinfo/connman
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: Wifi Technology says its offline when wifi dongle is unplugged and plugged back in

[Sameer Naik]

Hello,

I seems that the technology state is not updated correctly.
When i start connman and by ethernet connection is up and system is
online, The ethernet technology says "enabled". I think it should be
saying connected.

For wifi, when the dongle is removed the State goes to offline. But on
plugging it back in, it never goes to the enabled or connected states.
This is until connman is relaunched.

Is this a bug? or am i not understanding it right!

Regards
~Sameer


On Sun, Feb 19, 2012 at 1:10 PM, Sameer Naik
 wrote:
> Hi,
>
> if i connect a usb wifi dongle and start connman and query the wifi
> technology as so:
>
> --
> $ dbus-send --system --print-reply --dest=net.connman /net
> /connman/technology/wifi net.connman.Technology.GetProperties.
> $ dbus-send --system --print-reply --dest=net.connman /net
> /connman/technology/wifi net.connman.Technology.GetProperties
> method return sender=:1.172 -> dest=:1.174 reply_serial=2
>   array [
>      dict entry(
>         string "State"
>         variant             string "enabled"
>      )
>      dict entry(
>         string "Name"
>         variant             string "WiFi"
>      )
>      dict entry(
>         string "Type"
>         variant             string "wifi"
>      )
>      dict entry(
>         string "Tethering"
>         variant             boolean false
>      )
>   ]
> -
>
> It lists that the state of the wifi technology is "enabled".  When i
> remove the wifi dongle the Technology it says its "offline"
>
> But when i plug the dongle back in, it remains "offline" and does not
> go to "enabled". However, if i get the manager properties using:
>
> $ dbus-send --system --print-reply --dest=net.connman  /
> net.connman.Manager.GetProperties, wifi is listed under enabled
> technologies.
>
> so in short, Manager says technology is "enabled", while Technology
> says its "offline". Is this the expected behaviour?
>
> Regards
> ~Sameer
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Wifi Technology says its offline when wifi dongle is unplugged and plugged back in

[Sameer Naik]

Hi,

if i connect a usb wifi dongle and start connman and query the wifi
technology as so:

--
$ dbus-send --system --print-reply --dest=net.connman /net
/connman/technology/wifi net.connman.Technology.GetProperties.
$ dbus-send --system --print-reply --dest=net.connman /net
/connman/technology/wifi net.connman.Technology.GetProperties
method return sender=:1.172 -> dest=:1.174 reply_serial=2
   array [
  dict entry(
 string "State"
 variant string "enabled"
  )
  dict entry(
 string "Name"
 variant string "WiFi"
  )
  dict entry(
 string "Type"
 variant string "wifi"
  )
  dict entry(
 string "Tethering"
 variant boolean false
  )
   ]
-

It lists that the state of the wifi technology is "enabled".  When i
remove the wifi dongle the Technology it says its "offline"

But when i plug the dongle back in, it remains "offline" and does not
go to "enabled". However, if i get the manager properties using:

$ dbus-send --system --print-reply --dest=net.connman  /
net.connman.Manager.GetProperties, wifi is listed under enabled
technologies.

so in short, Manager says technology is "enabled", while Technology
says its "offline". Is this the expected behaviour?

Regards
~Sameer
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

[PATCH] gweb: set session->host to the parsed proxy hostname.

[Sameer Naik]

If the proxy is specified then we should set the session->host to the
parsed proxy hostname. The proxy hostname was instead being set in the
session->address variable.

Since session->address is not being resolved, specifying the http_proxy
variable in the scheme http_proxy=proxy.example.com:3128 would not work.
From a6446d8d9c3dd00864204a2352e66415743e6329 Mon Sep 17 00:00:00 2001
From: Sameer Naik 
Date: Mon, 13 Feb 2012 17:40:31 +0530
Subject: [PATCH 2/2] gweb: set session->host to the parsed proxy hostname.

If the proxy is specified then we should set the session->host to the
parsed proxy hostname. The proxy hostname was instead being set in the
session->address variable.

Since session->address is not being resolved, specifying the http_proxy
variable in the scheme http_proxy=proxy.example.com:3128 would not work.
---
 gweb/gweb.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/gweb/gweb.c b/gweb/gweb.c
index 6d9e7ad..da2ab0a 100644
--- a/gweb/gweb.c
+++ b/gweb/gweb.c
@@ -1125,7 +1125,9 @@ static int parse_url(struct web_session *session,
 		}
 	}
 
-	session->address = g_strdup(host);
+	if (session->host)
+		g_free(session->host);
+	session->host = g_strdup(host);
 
 	g_free(scheme);
 
-- 
1.7.6.5

___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

[PATCH] gweb: fix typo in parse_url function while processing http_proxy proxy setting.

[Sameer Naik]

Lookup for the proxy scheme and host should be performed on the recently
duplicated proxy string. As a result of this issue proxies specified by
the scheme http_proxy=http://192.168.1.1:3128, would not work.
From 71b2d26867227d9e4d5c67fea081ee30b3d1ac39 Mon Sep 17 00:00:00 2001
From: Sameer Naik 
Date: Mon, 13 Feb 2012 17:32:01 +0530
Subject: [PATCH 1/2] gweb: fix typo in parse_url function while processing
 http_proxy proxy setting.

Lookup for the proxy scheme and host should be performed on the recently
duplicated proxy string. As a result of this issue proxies specified by
the scheme http_proxy=http://192.168.1.1:3128, would not work.
---
 gweb/gweb.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/gweb/gweb.c b/gweb/gweb.c
index 365f67c..6d9e7ad 100644
--- a/gweb/gweb.c
+++ b/gweb/gweb.c
@@ -1098,7 +1098,7 @@ static int parse_url(struct web_session *session,
 	if (scheme == NULL)
 		return -EINVAL;
 
-	host = strstr(proxy, "://");
+	host = strstr(scheme, "://");
 	if (host != NULL) {
 		*host = '\0';
 		host += 3;
-- 
1.7.6.5

___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman