Re: service state transition to failure

[Patrik Flykt]

Hi,

On Fri, 2015-10-09 at 10:52 -0700, Naveen Singh wrote:
> This may not happen at all. My understanding is that wpa_supplicant would
> time out only if the AP is not seen in subsequent scans. But the AP is
> always found in scan as there is nothing wrong at 802.11 level. The user
> found that WAN cable was not connected so he went ahead and fixed it. And
> now the connection to DHCP server is established but connection will still
> not happen. Is user supposed to power off the AP so that it disappears from
> scan list.

wpa_s will time out wifi networks in 2 minutes if no scans have been
done to refresh them. For ConnMan it will take ~6 min 20 sec to get
fresh results with a new scan after the 2 minute expiry time.

If the user is connected to the system, nothing prevents the user from
connecting manually and immediately after said WAN cable is reattached.

Cheers,

Patrik

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

net.connman.Service setProperty

[Francesco Bruno]

Dear All, 

I'm trying to set the Ipv4 configuration using the setProperty in the intefarce 
net.connman.Service.

The documentation says that the the data passed to the interface must be a dict 
with same values as IPv4 property.
So I've created a GVariant of type a{sv}  i.e. an array of dict entries made of 
a string and a variance.

Calling setProperty on  services ( not connected  ) do not change the 
configuration as expected.

What am I doing wrong? I suspect wrong data definition for the configuration.  

Thanks in advance

Below some code


GVariant * iResVar = NULL;
GVariant * iVarArr[4];
iVarArr[0] = g_variant_new_dict_entry( g_variant_new_string( "Method" 
),g_variant_new_variant( g_variant_new_string( "manual" ) ) );
iVarArr[1] = g_variant_new_dict_entry( g_variant_new_string( "Address 
), g_variant_new_variant( g_variant_new_string( "127.0.0.1" ) ) );
iVarArr[2] = g_variant_new_dict_entry( g_variant_new_string( "Netmask" 
), g_variant_new_variant( g_variant_new_string( "255.255.255.0" ) ) );
iVarArr[3] = g_variant_new_dict_entry( g_variant_new_string( "Gateway" 
), g_variant_new_variant( g_variant_new_string( "1.2.3.4" ) ) );
iResVar = g_variant_new_variant( g_variant_new_array ( ((const 
GVariantType *) "{sv}"), iVarArr, 4 ) );


    net_connman_service_call_set_property_sync(
NET_CONNMAN_SERVICE ( pServiceProxy ),
"IPv4.Configuration", iResVal, NULL,  ); 
  
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman

How to provide DHCP on a technology

[John Ernberg]

Hi,

I'm using Connman in an embedded environment where a device will connect 
to us over USB, this device will provide an ethernet interface on the 
USB port, and the device will be in gadget mode.
Thus when they connect to us we load the cdc_ether driver and create an 
Ethernet interface over the USB port.

Being completely new to tethering in Connman and how it works, I'm 
having some issues setting up Connman to provide a DHCP server on this 
interface so the other device will receive an IP automatically once it 
starts a DHCP client.
I have googled and read the documentation but I cannot figure out how to 
do this properly.
The current method on the server side is to enable the gadget-technology 
when it shows up, configure an IP, netmask and gateway, and then enable 
tethering on it. Which results in the services not being listable, and 
no IP being given to the other side. If I run ifconfig on my side, the 
interface is up, but unconfigured.
How is this supposed to be done?

Doing this using Connman 1.29 on my side.

Thank you in advance for any assistance, and best regards // John Ernberg

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

Re: service state transition to failure

[Naveen Singh]

On Mon, Oct 12, 2015 at 6:31 AM, Patrik Flykt 
wrote:

>
> Hi,
>
> On Fri, 2015-10-09 at 10:52 -0700, Naveen Singh wrote:
> > This may not happen at all. My understanding is that wpa_supplicant would
> > time out only if the AP is not seen in subsequent scans. But the AP is
> > always found in scan as there is nothing wrong at 802.11 level. The user
> > found that WAN cable was not connected so he went ahead and fixed it. And
> > now the connection to DHCP server is established but connection will
> still
> > not happen. Is user supposed to power off the AP so that it disappears
> from
> > scan list.
>
> wpa_s will time out wifi networks in 2 minutes if no scans have been
> done to refresh them. For ConnMan it will take ~6 min 20 sec to get
> fresh results with a new scan after the 2 minute expiry time.
>
> If the user is connected to the system, nothing prevents the user from
> connecting manually and immediately after said WAN cable is reattached.
>

This certainly is an issue because of following reasons:
1. User could be initiating scan for it to get connected back to network so
there will never be a 2 minute expiry.
2. WAN detachment was just an example, it could very well be an
intermittent problem which does not require any intervention from user and
problem auto-corrects itself.
3. Expecting user to connect manually is not an option all the time. User
rely on their devices to get connected on their own so that they can
control these devices from anywhere.
4. I tested multiple devices in the same environment and each and every
device auto-connected on its own once the problem vansihes. This seems to
me as a use case that we have not considered and it surely requires some
fix in the connman.

>
> 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

Re: net.connman.Service setProperty

[Adam Moore]

I¹m not sure if this will do it, but in my agent¹s RequestInput method
implementation, which expects a dictionary, I had to wrap it in a tuple.
This might be worth a quick try:

GVariant *set_property_with_me =  g_variant_new_tuple(, 1);   //
Now returning ({sv})


On 10/12/15, 6:30 AM, "connman on behalf of Francesco Bruno"
 wrote:

>Dear All,
>
>I'm trying to set the Ipv4 configuration using the setProperty in the
>intefarce net.connman.Service.
>
>The documentation says that the the data passed to the interface must be
>a dict with same values as IPv4 property.
>So I've created a GVariant of type a{sv}  i.e. an array of dict entries
>made of a string and a variance.
>
>Calling setProperty on  services ( not connected  ) do not change the
>configuration as expected.
>
>What am I doing wrong? I suspect wrong data definition for the
>configuration.
>
>Thanks in advance
>
>Below some code
>
>
>   GVariant * iResVar = NULL;
>   GVariant * iVarArr[4];
>   iVarArr[0] = g_variant_new_dict_entry( g_variant_new_string( "Method"
>), g_variant_new_variant( g_variant_new_string( "manual" ) ) );
>   iVarArr[1] = g_variant_new_dict_entry( g_variant_new_string( "Address ),
>g_variant_new_variant( g_variant_new_string( "127.0.0.1" ) ) );
>   iVarArr[2] = g_variant_new_dict_entry( g_variant_new_string( "Netmask"
>), g_variant_new_variant( g_variant_new_string( "255.255.255.0" ) ) );
>   iVarArr[3] = g_variant_new_dict_entry( g_variant_new_string( "Gateway"
>), g_variant_new_variant( g_variant_new_string( "1.2.3.4" ) ) );
>   iResVar = g_variant_new_variant( g_variant_new_array ( ((const
>GVariantType *) "{sv}"), iVarArr, 4 ) );
>
>
>net_connman_service_call_set_property_sync(
>   NET_CONNMAN_SERVICE ( pServiceProxy ),
>   "IPv4.Configuration", iResVal, NULL,  );
>___
>connman mailing list
>connman@connman.net
>https://lists.connman.net/mailman/listinfo/connman


Statement of Confidentiality

The contents of this e-mail message and any attachments are confidential and 
are intended solely for the addressee. The information may also be legally 
privileged. This transmission is sent in trust, and the sole purpose of 
delivery to the intended recipient. If you have received this transmission in 
error, any use, reproduction or dissemination of this transmission is strictly 
prohibited. If you are not the intended recipient, please immediately notify 
the sender by reply e-mail or at 508.683.2500 and delete this message and its 
attachments, if any.

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

Re: service state transition to failure

[Naveen Singh]

In my previous email when I meant *"**User could be initiating scan" *I
actually meant "*Application could be initiating scan".*

On Mon, Oct 12, 2015 at 10:38 AM, Naveen Singh  wrote:

>
>
> On Mon, Oct 12, 2015 at 6:31 AM, Patrik Flykt <
> patrik.fl...@linux.intel.com> wrote:
>
>>
>> Hi,
>>
>> On Fri, 2015-10-09 at 10:52 -0700, Naveen Singh wrote:
>> > This may not happen at all. My understanding is that wpa_supplicant
>> would
>> > time out only if the AP is not seen in subsequent scans. But the AP is
>> > always found in scan as there is nothing wrong at 802.11 level. The user
>> > found that WAN cable was not connected so he went ahead and fixed it.
>> And
>> > now the connection to DHCP server is established but connection will
>> still
>> > not happen. Is user supposed to power off the AP so that it disappears
>> from
>> > scan list.
>>
>> wpa_s will time out wifi networks in 2 minutes if no scans have been
>> done to refresh them. For ConnMan it will take ~6 min 20 sec to get
>> fresh results with a new scan after the 2 minute expiry time.
>>
>> If the user is connected to the system, nothing prevents the user from
>> connecting manually and immediately after said WAN cable is reattached.
>>
>
> This certainly is an issue because of following reasons:
> 1. User could be initiating scan for it to get connected back to network
> so there will never be a 2 minute expiry.
> 2. WAN detachment was just an example, it could very well be an
> intermittent problem which does not require any intervention from user and
> problem auto-corrects itself.
> 3. Expecting user to connect manually is not an option all the time. User
> rely on their devices to get connected on their own so that they can
> control these devices from anywhere.
> 4. I tested multiple devices in the same environment and each and every
> device auto-connected on its own once the problem vansihes. This seems to
> me as a use case that we have not considered and it surely requires some
> fix in the connman.
>
>>
>> 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

Re: net.connman.Service setProperty

[francobruno77]

Thanks.

Are you able to change IPv4 configuration? I'm getting not supported error.

It doesn't work even with python test application. The service stucks in 
configuraton state and the method cannot be changed in anything but off.


Any idea?


Thanks.


Francesco Bruno





On Mon, Oct 12, 2015 at 12:28 PM -0700, "Adam Moore" 
 wrote:
I¹m not sure if this will do it, but in my agent¹s RequestInput method
implementation, which expects a dictionary, I had to wrap it in a tuple.
This might be worth a quick try:

GVariant *set_property_with_me =  g_variant_new_tuple(, 1);   //
Now returning ({sv})


On 10/12/15, 6:30 AM, "connman on behalf of Francesco Bruno"
 wrote:

>Dear All,
>
>I'm trying to set the Ipv4 configuration using the setProperty in the
>intefarce net.connman.Service.
>
>The documentation says that the the data passed to the interface must be
>a dict with same values as IPv4 property.
>So I've created a GVariant of type a{sv}  i.e. an array of dict entries
>made of a string and a variance.
>
>Calling setProperty on  services ( not connected  ) do not change the
>configuration as expected.
>
>What am I doing wrong? I suspect wrong data definition for the
>configuration.
>
>Thanks in advance
>
>Below some code
>
>
>   GVariant * iResVar = NULL;
>   GVariant * iVarArr[4];
>   iVarArr[0] = g_variant_new_dict_entry( g_variant_new_string( "Method"
>), g_variant_new_variant( g_variant_new_string( "manual" ) ) );
>   iVarArr[1] = g_variant_new_dict_entry( g_variant_new_string( "Address ),
>g_variant_new_variant( g_variant_new_string( "127.0.0.1" ) ) );
>   iVarArr[2] = g_variant_new_dict_entry( g_variant_new_string( "Netmask"
>), g_variant_new_variant( g_variant_new_string( "255.255.255.0" ) ) );
>   iVarArr[3] = g_variant_new_dict_entry( g_variant_new_string( "Gateway"
>), g_variant_new_variant( g_variant_new_string( "1.2.3.4" ) ) );
>   iResVar = g_variant_new_variant( g_variant_new_array ( ((const
>GVariantType *) "{sv}"), iVarArr, 4 ) );
>
>
>net_connman_service_call_set_property_sync(
>   NET_CONNMAN_SERVICE ( pServiceProxy ),
>   "IPv4.Configuration", iResVal, NULL,  );
>___
>connman mailing list
>connman@connman.net
>https://lists.connman.net/mailman/listinfo/connman


Statement of Confidentiality

The contents of this e-mail message and any attachments are confidential and 
are intended solely for the addressee. The information may also be legally 
privileged. This transmission is sent in trust, and the sole purpose of 
delivery to the intended recipient. If you have received this transmission in 
error, any use, reproduction or dissemination of this transmission is strictly 
prohibited. If you are not the intended recipient, please immediately notify 
the sender by reply e-mail or at 508.683.2500 and delete this message and its 
attachments, if any.

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