From: nasingh
Current NTP code is written with an assumption that timeserver is
always an IPv4 address. If there is an IPv6 timeserver then the socket
operation would fail with error as Permission denied (13). This change
in ntp.c ensures that code works fine with both IPv4 and IPv6 address.
---
On Mon, Oct 26, 2015 at 12:46 AM, Patrik Flykt wrote:
> On Fri, 2015-10-23 at 06:28 -0700, Naveen Singh wrote:
> > > I didn't notice sin_port being used anywhere, so this is not needed?
> > >
> > This is being used in current code so I decided to follow the curre
Hi Patrik
I had to move some functions in the file for the compilation to go through.
Regards
Naveen
On Mon, Oct 26, 2015 at 8:41 PM, Naveen Singh
wrote:
> From: nasingh
>
> It is been seen that if the service state has transitioned to failure
> there is no way for it to get it
From: nasingh
Change the overview-api.txt to do the service transition from
failure state to idle.
---
doc/overview-api.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/overview-api.txt b/doc/overview-api.txt
index f126887..0a5996e 100644
--- a/doc/overview-api.txt
From: nasingh
It is been seen that if the service state has transitioned to failure
there is no way for it to get it back to idle. This fix allows the
state to be transitioned back to idle as part of handling clear_property
handler for error event.
Refer Patrik's commit 251d95755dd144c8bd6d3e3bd5
Hi,
>
> On Tue, 2015-10-06 at 23:50 -0700, Naveen Singh wrote:
> > From: Naveen Singh
> >
> > Current NTP code is written with an assumption that timeserver is
> > always an IPv4 address. If there is an IPv6 timeserver then the socket
> > operation would fail
From: nasingh
It is been seen that if the service state has transitioned to failure
there is no way for it to get it back to idle. This fix allows the
state to be transitioned back to idle as part of handling clear_property
handler for error event.
Refer Patrik's commit 251d95755dd144c8bd6d3e3bd5
On Tue, Oct 13, 2015 at 1:00 AM, Patrik Flykt
wrote:
>
> Hi,
>
> On Mon, 2015-10-12 at 21:46 -0700, Naveen Singh wrote:
> > In my previous email when I meant *"**User could be initiating scan" *I
> > actually meant "*Application could be init
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.i
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.
Hi Patrik,
On Fri, Oct 9, 2015 at 1:13 AM, Patrik Flykt
wrote:
> On Thu, 2015-10-08 at 13:30 -0700, Naveen Singh wrote:
> > 5. Now it is in failure state and will never be able to connect.
>
> It will be autoconnected once its state is no longer failure. The
> failure state i
From: Naveen Singh
It is been seen that if the service state has transitioned to failure
there is no way for it to get it back to idle. This fix allows the state
to be transitioned back to idle as part of handling clear_property handler
for error event. Since there is no guarantee that error
On Thu, Oct 8, 2015 at 6:20 AM, Patrik Flykt
wrote:
>
> Hi,
>
> On Wed, 2015-10-07 at 21:21 -0700, Naveen Singh wrote:
> > I have few questions about service state transition to failure:
> >
> > 1. Can service state transition to Failure w/o generating an
Hi Patrik
Thanks for your response.
On Thu, Oct 8, 2015 at 6:20 AM, Patrik Flykt
wrote:
>
> Hi,
>
> On Wed, 2015-10-07 at 21:21 -0700, Naveen Singh wrote:
> > I have few questions about service state transition to failure:
> >
> > 1. Can service s
Hi
I have few questions about service state transition to failure:
1. Can service state transition to Failure w/o generating an error event? I
am seeing that WiFi connection is not going through even if the AP is found
in scan. I dumped the service properties and I see that state is Failure
but Ev
Hi
This is the current code of get_lease in client.c file:
lease_seconds = get_be32(option);
/* paranoia: must not be prone to overflows */
lease_seconds &= 0x0fff;
If first 28 bits are a small number (but lease_seconds is larger than
0xfff) this would make lease_s
On Tue, Oct 6, 2015 at 11:50 PM, Naveen Singh
wrote:
> From: Naveen Singh
>
> Current NTP code is written with an assumption that timeserver is
> always an IPv4 address. If there is an IPv6 timeserver then the socket
> operation would fail with error as Permission denied (13).
From: Naveen Singh
Current NTP code is written with an assumption that timeserver is
always an IPv4 address. If there is an IPv6 timeserver then the socket
operation would fail with error as Permission denied (13). This change in
ntp.c ensures that code works fine with both IPv4 and IPv6 address
Hi Jukka,
On Fri, Oct 2, 2015 at 12:29 AM, Jukka Rissanen <
jukka.rissa...@linux.intel.com> wrote:
> Hi Naveen,
>
> On to, 2015-10-01 at 23:00 -0700, Naveen Singh wrote:
> > On Thu, Oct 1, 2015 at 6:26 AM, Patrik Flykt <
> patrik.fl...@linux.intel.com>
> &g
On Thu, Oct 1, 2015 at 6:26 AM, Patrik Flykt
wrote:
>
> Hi,
>
> On Wed, 2015-09-30 at 22:08 -0700, Naveen Singh wrote:
> > From: Naveen Singh
> >
> > Current NTP code is written with an assumption that timeserver is
> > always an IPv4 address. If
Hi
We have been seeing a hang in connman regularly while running a wifi
disconnect-connect test. The last log line we see is a connman error log:
"*Invalid packet timestamp from time server*"
After that we do not see any log messages from connman. I debugged this by
doing following:
1. Dump the pa
On Thu, Oct 1, 2015 at 6:26 AM, Patrik Flykt
wrote:
>
> Hi,
>
> On Wed, 2015-09-30 at 22:08 -0700, Naveen Singh wrote:
> > From: Naveen Singh
> >
> > Current NTP code is written with an assumption that timeserver is
> > always an IPv4 address. If
From: Naveen Singh
Current NTP code is written with an assumption that timeserver is
always an IPv4 address. If there is an IPv6 timeserver then the socket
operation would fail with error as Permission denied (13). This change in
ntp.c ensures that code works fine with both IPv4 and IPv6 address
Sorry for a delayed reply. Somehow this email went to a different folder.
On Fri, Sep 25, 2015 at 12:15 AM, Patrik Flykt wrote:
> On Thu, 2015-09-24 at 15:38 -0700, Naveen Singh wrote:
> > Isn't the IPv4 or IPv6 address passed as an argument to
> > __connman_ntp_start a
On Thu, Sep 24, 2015 at 3:02 AM, Patrik Flykt
wrote:
> On Thu, 2015-09-24 at 11:14 +0300, Patrik Flykt wrote:
> > > +
> > > + if (ret) {
> > > + connman_error("cannot get the server info");
> > > + return -1;
> > > + }
> > > +
> > > + family = info->ai_family;
Hi,
On Thu, Sep 24, 2015 at 1:14 AM, Patrik Flykt
wrote:
>
> Hi,
>
> On Wed, 2015-09-23 at 21:22 -0700, Naveen Singh wrote:
> > From: Naveen Singh
> >
> > Current NTP code is written with an assumption that timeserver is
> > always an IPv4 address.
From: Naveen Singh
Current NTP code is written with an assumption that timeserver is
always an IPv4 address. If there is an IPv6 timeserver then the socket
operation would fail with error as Permission denied (13). This change in
ntp.c ensures that code works fine with both IPv4 and IPv6 address
On Tue, Sep 1, 2015 at 1:05 AM, Patrik Flykt
wrote:
> On Mon, 2015-08-31 at 22:49 -0700, Naveen Singh wrote:
>
> > Further to my first question, I see that even if we getting multiple time
> > servers (as a part of DHCP ACK) options, we move to the second server
> only
>
connmand[4417]: Connection Manager
version 1.29
On Thu, Sep 17, 2015 at 7:03 PM, Naveen Singh wrote:
> We have been seeing a very weird connmand lockup where connman gets
> unresponsive and is not able to process any events from its main loop. I
> have enabled complete logging in the
first one is an IPv6 address?
Regards
Naveen
On Mon, Aug 31, 2015 at 10:41 PM, Naveen Singh wrote:
> Hi All
> It looks like connman's NTP implementation only support IPv4 timeserver.
> We have found that if we get an IPv6 address as the time server , sendto
> function in send_pack
Hi All
It looks like connman's NTP implementation only support IPv4 timeserver. We
have found that if we get an IPv6 address as the time server , sendto
function in send_packet function fails. Here is the log that we see from
devices with an IPv6 timeserver address:
We get to see following errors
On Wed, Jul 22, 2015 at 12:54 AM, Peter Meerwald wrote:
>
> > > "2015-07-17 01:35:20.00 daemon.err connmand[321]: Invalid packet
> > > timestamp from time server"
> > >
> > > After this print we see that we are not able to communicate to connman
> at
> > > all. All the DBUS messages to connma
On Wed, Jul 22, 2015 at 12:54 AM, Peter Meerwald wrote:
>
> > > "2015-07-17 01:35:20.00 daemon.err connmand[321]: Invalid packet
> > > timestamp from time server"
> > >
> > > After this print we see that we are not able to communicate to connman
> at
> > > all. All the DBUS messages to connma
Hi All
In our testing of new connman (version 1.29) we do see following error
print sometimes (This is happening very rarely and I do not have any easy
way to reproduce it at will):
"2015-07-17 01:35:20.00 daemon.err connmand[321]: Invalid packet
timestamp from time server"
After this print w
Hi
We found that for connman to offer dnsproxy the resolver init needs to be
called after the plugin_init. This is because as a part of plugin_init, the
loopback plugin init would be called and would set up 127.0.0.1 and ::1
address to "lo" interface. Since in the current code these functions are
On Mon, Jun 22, 2015 at 5:46 AM, Patrik Flykt
wrote:
> On Fri, 2015-06-19 at 19:22 -0700, Naveen Singh wrote:
> > I realized that timers used in dhcp plugin use monotonic timers which
> does
> > not progress during suspend duration of device. Because of this the
> devices
&g
I realized that timers used in dhcp plugin use monotonic timers which does
not progress during suspend duration of device. Because of this the devices
which are sleepy in nature never get to renew IP address and causes lot of
communication failures.
I have an implementation which in stead of using
Hi
Thanks for the response. Is there a way currently for it to change the
condition from OR to AND.
Regards
Naveen
On Tue, May 19, 2015 at 1:25 AM, Patrik Flykt
wrote:
>
> Hi,
>
> On Sun, 2015-05-17 at 04:40 -0700, Naveen Singh wrote:
> > I have a link local ipv6 addr
I have a link local ipv6 address for my service (method is Auto for IPV6).
For IPV4 the method is DHCP. I see that service state is transitioning to
ready w/o a valid IPv4 address. So I am not sure what is triggering the
state transition to ready w/o a valid IP address. Is it IPv6 auto method
makin
ur prompt help.
Regards
Naveen
On Thu, Jan 15, 2015 at 12:08 AM, Patrik Flykt wrote:
> On Wed, 2015-01-14 at 19:40 -0800, Naveen Singh wrote:
> > Do you guys think if the following make sense:
> >
> > diff --git a/plugins/wifi.c b/plugins/wifi.c
> > index 97f7144.
ant_interface_**connect. There are other failure cases in that
function like system_not_available or running out of memory. *
*Regards*
*Naveen*
On Wed, Jan 14, 2015 at 5:08 PM, Naveen Singh wrote:
> Thanks Guys for the replies.
>
> I am using *supplicant version 2.0 and connman 1.27.
gt; From: Patrik Flykt
> To: connman@connman.net
> Subject: Re: Connman network refcount
> Message-ID: <1421221645.16297.73.ca...@linux.intel.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Tue, 2015-01-13
I did a simple test of connecting to a WiFi AP and then doing a disconnect
using connmanctl. I found that the connman crashed while trying to
decrement the network ref count from network_removed() function in
plugins/wifi.c
static void network_removed(GSupplicantNetwork *network){
GSupplic
Found this issue which caused connman crash on 1.27. From connman log it
looks like scan done call back (scan_callback_hidden) is called twice for
the same scan causing the ref count to go to zero and wifi memory to be
freed.
This is the sequence in which functions in plugins/wifi.c are called:
1
I was trying to use the latest connman and I found that it was crashing
during the very first wifi scan and is to do with newly introduced
functions *wifi_data_ref* and *wifi_data_unref*. This is the scenario:
After wpa_supplicant has created the interface it is gonna call connman
supplied callbac
45 matches
Mail list logo
