[TRANSIENT] Peer XOs NOT shown in Neighborhood view when Power Management is enabled

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[TRANSIENT] Peer XOs NOT shown in Neighborhood view when Power Management is enabled

nitika.mail
Hi All,

   Peer XOs are NOT shown in Neighborhood view  when Power Management is enabled.

Tested on 31016o2 OLPC Image (Build 16) on two XO-1.75's... one Touch and the other Non-Touch. Following observations were made:

1. Having connected both the XO's to a network, when neighborhood view was seen on both the XO's, only one XO displayed the other in its neighborhood view. The second XO was all alone in the neighborhood view.

2. At some point, due to suspending an XO (or network re-connect), same thing can be observed on either of the XO's

3. When Power management was disabled and system rebooted, this issue was not observed.

4. This has yet been observed only on XO-1.75's.

If anyone has observed this issue, please do advise.

Also, does this call for raising a bug?

Thanks and Regards,

Nitika Mangal
QA Manager
Activity Central: http://activitycentral.com

_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [TRANSIENT] Peer XOs NOT shown in Neighborhood view when Power Management is enabled

Samuel Greenfeld
It sounds like you are having issues with multicast packet wakeups, which have always been a bit of a sore spot.

I presume you are using ad-hoc networking, and have not left the XOs idling to the point they shutdown their screen turns black and the wifi card is turned off (~20 minutes?).  If this is with a schoolserver it still could be a known issue but might be worth raising again.

Wake-on-LAN behavior with the 8686 wireless card is not as reliable at it should be.  XOs need to wake up on multicast events to receive data (multicast DNS) about the network neighborhood, but need to clearly hear such announcements {i.e. no collisions with another data packet}, and sometimes don't get them even if the XO is awake.  In crowded cities where there are lots of access points and other computers nearby this becomes more of a problem.

And since updates are only sent every few minutes, it could take quite a while for everything to get synched up, with things lost along the way.

Schoolservers/Jabber servers use TCP connections, should be retrying at the TCP level, and should not run into these issues unless a XO went fully into suspend (black screen/etc.) with the wifi card off.  If a XO is connected to a schoolserver/Jabber it will not show ad-hoc users even if they are on the same network.

The ad-hoc networking model definitely could be improved but I do not know if anyone has ever taken up that task.

There are several tickets on the subject; I do not recall filing any against 13.1.0 yet though.


On Tue, Dec 18, 2012 at 12:40 PM, nitika.mail <[hidden email]> wrote:
Hi All,

   Peer XOs are NOT shown in Neighborhood view  when Power Management is enabled.

Tested on 31016o2 OLPC Image (Build 16) on two XO-1.75's... one Touch and the other Non-Touch. Following observations were made:

1. Having connected both the XO's to a network, when neighborhood view was seen on both the XO's, only one XO displayed the other in its neighborhood view. The second XO was all alone in the neighborhood view.

2. At some point, due to suspending an XO (or network re-connect), same thing can be observed on either of the XO's

3. When Power management was disabled and system rebooted, this issue was not observed.

4. This has yet been observed only on XO-1.75's.

If anyone has observed this issue, please do advise.

Also, does this call for raising a bug?

Thanks and Regards,

Nitika Mangal
QA Manager
Activity Central: http://activitycentral.com

_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel



_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [TRANSIENT] Peer XOs NOT shown in Neighborhood view when Power Management is enabled

nitika.mail
Hi Samuel,

   Thanks for the clarification!

Would it be ok to raise a ticket for this issue?

Thanks and Regards,

Nitika Mangal
QA Manager
Activity Central: http://activitycentral.com

On Tue, Dec 18, 2012 at 11:46 PM, Samuel Greenfeld <[hidden email]> wrote:
It sounds like you are having issues with multicast packet wakeups, which have always been a bit of a sore spot.

I presume you are using ad-hoc networking, and have not left the XOs idling to the point they shutdown their screen turns black and the wifi card is turned off (~20 minutes?).  If this is with a schoolserver it still could be a known issue but might be worth raising again.

Wake-on-LAN behavior with the 8686 wireless card is not as reliable at it should be.  XOs need to wake up on multicast events to receive data (multicast DNS) about the network neighborhood, but need to clearly hear such announcements {i.e. no collisions with another data packet}, and sometimes don't get them even if the XO is awake.  In crowded cities where there are lots of access points and other computers nearby this becomes more of a problem.

And since updates are only sent every few minutes, it could take quite a while for everything to get synched up, with things lost along the way.

Schoolservers/Jabber servers use TCP connections, should be retrying at the TCP level, and should not run into these issues unless a XO went fully into suspend (black screen/etc.) with the wifi card off.  If a XO is connected to a schoolserver/Jabber it will not show ad-hoc users even if they are on the same network.

The ad-hoc networking model definitely could be improved but I do not know if anyone has ever taken up that task.

There are several tickets on the subject; I do not recall filing any against 13.1.0 yet though.


On Tue, Dec 18, 2012 at 12:40 PM, nitika.mail <[hidden email]> wrote:
Hi All,

   Peer XOs are NOT shown in Neighborhood view  when Power Management is enabled.

Tested on 31016o2 OLPC Image (Build 16) on two XO-1.75's... one Touch and the other Non-Touch. Following observations were made:

1. Having connected both the XO's to a network, when neighborhood view was seen on both the XO's, only one XO displayed the other in its neighborhood view. The second XO was all alone in the neighborhood view.

2. At some point, due to suspending an XO (or network re-connect), same thing can be observed on either of the XO's

3. When Power management was disabled and system rebooted, this issue was not observed.

4. This has yet been observed only on XO-1.75's.

If anyone has observed this issue, please do advise.

Also, does this call for raising a bug?

Thanks and Regards,

Nitika Mangal
QA Manager
Activity Central: http://activitycentral.com

_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel




_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [TRANSIENT] Peer XOs NOT shown in Neighborhood view when Power Management is enabled

Jerry Vonau
In reply to this post by Samuel Greenfeld
On Tue, 2012-12-18 at 13:16 -0500, Samuel Greenfeld wrote:
> It sounds like you are having issues with multicast packet wakeups,
> which have always been a bit of a sore spot.
>
> I presume you are using ad-hoc networking, and have not left the XOs
> idling to the point they shutdown their screen turns black and the
> wifi card is turned off (~20 minutes?).  If this is with a
> schoolserver it still could be a known issue but might be worth
> raising again.

Think I found the problem, in powerd we're setting WOL based on this
string:

if grep -qi ": 00000000:14B2" /proc/net/tcp

but that string is not present in /proc/net/tcp so WOL is not set
according to ethtool, but that string can be found in /proc/net/tcp6

avahi is bound to tcp6 when viewed with 'netstat -nat'

This is reproducible in 12.1.0 and 13.1.0

Jerry

_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [TRANSIENT] Peer XOs NOT shown in Neighborhood view when Power Management is enabled

Martin Langhoff
On Wed, Dec 19, 2012 at 5:14 AM, Jerry Vonau <[hidden email]> wrote:

> Think I found the problem, in powerd we're setting WOL based on this
> string:
>
> if grep -qi ": 00000000:14B2" /proc/net/tcp
>
> but that string is not present in /proc/net/tcp so WOL is not set
> according to ethtool, but that string can be found in /proc/net/tcp6
>
> avahi is bound to tcp6 when viewed with 'netstat -nat'
>
> This is reproducible in 12.1.0 and 13.1.0

Arghhh. Ouch.

Does it behave better with:

  if grep -qi ": 00000000:14B2" /proc/net/tcp*

?



m
--
 [hidden email]
 [hidden email] -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [TRANSIENT] Peer XOs NOT shown in Neighborhood view when Power Management is enabled

James Cameron-2
In reply to this post by nitika.mail
On Tue, Dec 18, 2012 at 11:10:25PM +0530, nitika.mail wrote:
> Peer XOs are NOT shown in Neighborhood view when Power Management
> is enabled.

As has already been said, there are known causes of this.  There is
also another cause not mentioned; damage to a single antenna.

When no school server is used, the peer XOs are shown in Neighbourhood
View as a result of broadcast network packets.  These packets are
transmitted by the access point without negotiation, and this forces
the wireless card to skip choosing the best receiving antenna.

If the right antenna is damaged, or the coax cable is twisted, then
this can show up as conflicting symptoms: (a) good downloads and
browsing, but (b) peer XOs not shown.

To exclude this possible cause, test both antennas.  If both antennas
are working correctly, then this is not a cause of the problem.

http://wiki.laptop.org/go/Antenna_testing describes antenna test
tools.  You must reflash to Open Firmware Q4D25 first, given that
31016O2 contains only Q4D24.

Always test antennas of an unknown laptop before testing
collaboration.

--
James Cameron
http://quozl.linux.org.au/
_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [TRANSIENT] Peer XOs NOT shown in Neighborhood view when Power Management is enabled

Jerry Vonau
In reply to this post by Martin Langhoff
On Wed, 2012-12-19 at 09:48 -0500, Martin Langhoff wrote:

> On Wed, Dec 19, 2012 at 5:14 AM, Jerry Vonau <[hidden email]> wrote:
> > Think I found the problem, in powerd we're setting WOL based on this
> > string:
> >
> > if grep -qi ": 00000000:14B2" /proc/net/tcp
> >
> > but that string is not present in /proc/net/tcp so WOL is not set
> > according to ethtool, but that string can be found in /proc/net/tcp6
> >
> > avahi is bound to tcp6 when viewed with 'netstat -nat'
> >
> > This is reproducible in 12.1.0 and 13.1.0
>
> Arghhh. Ouch.
>
> Does it behave better with:
>
>   if grep -qi ": 00000000:14B2" /proc/net/tcp*
>

Sadly no, but what does work for me is:

if netstat -l -n | grep -q ':5298 '

Jerry




_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [TRANSIENT] Peer XOs NOT shown in Neighborhood view when Power Management is enabled

Samuel Greenfeld


On Tue, Jan 1, 2013 at 7:34 PM, Jerry Vonau <[hidden email]> wrote:
On Wed, 2012-12-19 at 09:48 -0500, Martin Langhoff wrote:
> On Wed, Dec 19, 2012 at 5:14 AM, Jerry Vonau <[hidden email]> wrote:
> > Think I found the problem, in powerd we're setting WOL based on this
> > string:
> >
> > if grep -qi ": 00000000:14B2" /proc/net/tcp
> >
> > but that string is not present in /proc/net/tcp so WOL is not set
> > according to ethtool, but that string can be found in /proc/net/tcp6
> >
> > avahi is bound to tcp6 when viewed with 'netstat -nat'
> >
> > This is reproducible in 12.1.0 and 13.1.0
>
> Arghhh. Ouch.
>
> Does it behave better with:
>
>   if grep -qi ": 00000000:14B2" /proc/net/tcp*

This does not work because IPv6 addresses are longer (and therefore have more octets).

The variant I came up with (if we want to support both v4 and v6 listeners) is

if grep -qiE ": 00000000+:14B2" /proc/net/tcp?

Simply removing the ": " check on its own might be sufficient for our purposes but could falsely return true in a few cases.

If IPv4 backward compatibility on the listener check is not a concern, then you should just match on the longer string of zeros:14B6 in /proc/net/tcp6 and not check both files for speed.



_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [TRANSIENT] Peer XOs NOT shown in Neighborhood view when Power Management is enabled

Paul Fox-2
samuel wrote:
 > On Tue, Jan 1, 2013 at 7:34 PM, Jerry Vonau <[hidden email]> wrote:
 >
 > > On Wed, 2012-12-19 at 09:48 -0500, Martin Langhoff wrote:
 > > > On Wed, Dec 19, 2012 at 5:14 AM, Jerry Vonau <[hidden email]> wrote:
 > > > > Think I found the problem, in powerd we're setting WOL based on this
 > > > > string:
 > > > >
 > > > > if grep -qi ": 00000000:14B2" /proc/net/tcp
 > > > >
 > > > > but that string is not present in /proc/net/tcp so WOL is not set
 > > > > according to ethtool, but that string can be found in /proc/net/tcp6
 > > > >
 > > > > avahi is bound to tcp6 when viewed with 'netstat -nat'
 > > > >
 > > > > This is reproducible in 12.1.0 and 13.1.0
 > > >
 > > > Arghhh. Ouch.
 > > >
 > > > Does it behave better with:
 > > >
 > > >   if grep -qi ": 00000000:14B2" /proc/net/tcp*
 > >
 >
 > This does not work because IPv6 addresses are longer (and therefore have
 > more octets).
 >
 > The variant I came up with (if we want to support both v4 and v6 listeners)
 > is
 >
 > if grep -qiE ": 00000000+:14B2" /proc/net/tcp?
 >
 > Simply removing the ": " check on its own might be sufficient for our
 > purposes but could falsely return true in a few cases.
 >
 > If IPv4 backward compatibility on the listener check is not a concern, then
 > you should just match on the longer string of zeros:14B6 in /proc/net/tcp6
 > and not check both files for speed.

why would ipv4 backward compatibility not be a concern?

paul
=---------------------
 paul fox, [hidden email]
_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [TRANSIENT] Peer XOs NOT shown in Neighborhood view when Power Management is enabled

Samuel Greenfeld
On Wed, Jan 2, 2013 at 10:21 AM, Paul Fox <[hidden email]> wrote:
samuel wrote:
 > On Tue, Jan 1, 2013 at 7:34 PM, Jerry Vonau <[hidden email]> wrote:
 >
 > > On Wed, 2012-12-19 at 09:48 -0500, Martin Langhoff wrote:
 > > > On Wed, Dec 19, 2012 at 5:14 AM, Jerry Vonau <[hidden email]> wrote:
 > > > > Think I found the problem, in powerd we're setting WOL based on this
 > > > > string:
 > > > >
 > > > > if grep -qi ": 00000000:14B2" /proc/net/tcp
 > > > >
 > > > > but that string is not present in /proc/net/tcp so WOL is not set
 > > > > according to ethtool, but that string can be found in /proc/net/tcp6
 > > > >
 > > > > avahi is bound to tcp6 when viewed with 'netstat -nat'
 > > > >
 > > > > This is reproducible in 12.1.0 and 13.1.0
 > > >
 > > > Arghhh. Ouch.
 > > >
 > > > Does it behave better with:
 > > >
 > > >   if grep -qi ": 00000000:14B2" /proc/net/tcp*
 > >
 >
 > This does not work because IPv6 addresses are longer (and therefore have
 > more octets).
 >
 > The variant I came up with (if we want to support both v4 and v6 listeners)
 > is
 >
 > if grep -qiE ": 00000000+:14B2" /proc/net/tcp?
 >
 > Simply removing the ": " check on its own might be sufficient for our
 > purposes but could falsely return true in a few cases.
 >
 > If IPv4 backward compatibility on the listener check is not a concern, then
 > you should just match on the longer string of zeros:14B6 in /proc/net/tcp6
 > and not check both files for speed.

why would ipv4 backward compatibility not be a concern?

The ::0 (0.0.0.0 in IPv4 netstat speak) listener for telepathy-salut is bound on the IPv6 socket, but still handles IPv4 requests.  So just /proc/net/tcp6 can be looked at in 13.1.0/Fedora 18 as we ship it.

But if there is an option to tell telepathy-salut to bind to 0.0.0.0 instead of ::0 and force the listener to use IPv4 binding, then both /proc/net/tcp and /proc/net/tcp6 have to be checked if we wanted to be backward-compatible, or just paranoid in case something we don't know or don't expect can tell telepathy-salut to do that.




_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel