Wireless LED usage during use.

[jg]

During a discussion of the leds intended for wireless use (and after much moaning and dislike of "blinkn lights" that are distracting so near the screen, we came up with the following scheme:

1) use one LED (maybe the !), to indicate association *and* connectivity via infrastructure mode. 2) use the other to indicate similar association *and* existence of a mesh portal. 3) if neither is lit, then you are trying to use a mesh that is not connected. 4) if both are lit, then you know you are a mesh portal for a mesh.

This would make both driven by NetworkManager rather than directly from firmware or the OS. Dan thought this was already likely possible.

A further thought occurred to me: it might be that these lights blinking during the attempts to establish connectivity would be one way to indicate progress in the algorithms for establishing connectivity.

[kimquirk]

Moving to next software release, Trial-2.

[sj]

What about turning off the blinking led altogether? cjb felt it would be difficult to run the leds from NM, as being run directly from the marvell chip.

[jg]

There is nothing in my description above that says anything about blinking, is there?

[rchokshi]

Replying to jg:

During a discussion of the leds intended for wireless use (and after much moaning and dislike of "blinkn lights" that are distracting so near the screen, we came up with the following scheme: 1) use one LED (maybe the !), to indicate association *and* connectivity via infrastructure mode. 2) use the other to indicate similar association *and* existence of a mesh portal.

You mean mesh point here, right?

3) if neither is lit, then you are trying to use a mesh that is not connected. 4) if both are lit, then you know you are a mesh portal for a mesh. This would make both driven by NetworkManager rather than directly from firmware or the OS. Dan thought this was already likely possible. A further thought occurred to me: it might be that these lights blinking during the attempts to establish connectivity would be one way to indicate progress in the algorithms for establishing connectivity.

I could not get the precise meaning of “…association *and* connectivity …”. Does connectivity mean assigning IP address to that interface or is connectivity at L2? We are assuming the latter.

[jg]

Can we get this going immediately after Trial-2, by getting it into firmware and then the driver? I'm assigning this to jcardona as a possible start; whomever does the firmware should reassign this to marcelo or dcbw for implementation in the driver. Then it should get reassigned to dcbw for network manager implementation...

[jg]

I think the lights need to be completely under control of NM.

For example, connectivity to the internet is having a mesh portal *and* a DNS server you think exists. Lots of the information is only available at higher levels than the mesh, so let's leave use of the LED's to the layers that have the information.

[jcardona]

The original specification for these two LEDs was captured in ticket #416. This is a valid request, but I would not call it a defect.

[danw]

Replying to jg:

1) use one LED (maybe the !), to indicate association *and* connectivity via infrastructure mode.
2) use the other to indicate similar association *and* existence of a mesh portal.
3) if neither is lit, then you are trying to use a mesh that is not connected.
4) if both are lit, then you know you are a mesh portal for a mesh.

But why would real XO users (ie, not us) care about those states? The network states the kids will care about are (1) are there other XOs around that I can share activities with, (2) is the school server available for content storage/retrieval, (3) is the global internet available? The breakdown of LED functionality suggested above doesn't reliably indicate any of those things.

And given the power consumption issues (#733), is it really necessary to indicate any of this stuff in hardware? Eg, if the user wants to know if there are other XOs around, he can just switch to the Neighborhood view, etc.

[cjb]

I'd like to reassign this to update.1, since I don't think we have any other "turn off the blinking mesh LEDs" bugs open. The infrastructure's there in the kernel and firmware now, as I understand it.

Related to this is turning off or slowing down mesh beacons.

[mbletsas]

Let's not touch the LEDs for the moment, they are invaluable in debugging.

M.

[jg]

I want to be *able* to touch the leds; it's too late to think about actually changing them in update.1 anyway.

How invasive is the driver change?

[jg]

Did this get into the driver, dave?

[dwmw2]

This never made it into the upstream driver; it was one of the private ioctls which existed only in the olpc tree, and thus it disappeared when we merged the new driver. I have resurrected it _temporarily_ in its original form but it is likely to change.

[mikus]

Been reading old tickets. Apparently light_1 was to show "association" (to mesh OR to infrastructure access point) and light_2 was to show traffic (or MPP association). These are good uses for network debugging -- but do they tell the child information that he needs to act on ?

I believe the number of communication_status indicators is more than two. The question then becomes: Which indicators need to be always visible, and which can be relegated to being shown on an appropriate screen view ?

It seems reasonable that the child might "give up" something he is doing with his XO if he sees that communication was lost; or he might initiate doing something with his XO when he sees formerly unavailable communication now established. And it is likely that the most important destinations for the child to communicate with are the mesh (i.e., his "peers") and the school (i.e., his writeable "data repository"). My proposal is that light_1 indicate "connection working to at least one participant who can be shared with", and that light_2 indicate "connection working to the school server". Keeping an eye on the status of these lights will help the child decide what to do next with his XO.

---

That leaves "screen views" as the location of the remaining communications indicators, The Neighborhood view *already* displays many of the destinations reachable by the XO -- it seems a good place to show status information about what those destinations can be used for (e.g., here is how internet connectivity is currently being provided).

• In my opinion, whatever eth0 is connected to ought to be *uniquely* marked in the Neighborhood view. If the XO is serving as a Mesh Portal - that needs to be (separately) indicated in this view.

• If it is important to the network administrator to extract information about eth1, its destination can also be specially marked in this view.

• Notable destinations such as the school server and the jabber server (as specified in sugar-control-panel) should be specially marked.

• Where the icon in the Neighborhood view is the principal indicator of the status of a connection, the appearance of the icon ought to change *noticeably* upon disconnect.

• Flyover ought to list the characteristics of marked destinations.

• Availability of other 'Access Points' is already shown in this view.

To present the "utility" of a connection, 'traffic' information can be added to wherever 'signal strength' is being shown.

---

Serious shortcomings of the existing communication_status indicators:

• Rapid blinking of the XO front panel lights is very distracting. Instead, put in an option to have the software output a description of its transient state ("trying to connect on channel 6") to a log.

• Having the rim of a circle change color when connectivity is lost is not conspicuous enough. Have a light dedicated to showing the connection's status. For connections without such a dedicated light, in Neighborhood view change the entire corresponding icon.

[gnu]

The Wireless LEDs are very much under software control. Unfortunately the documentation for this feature was very well buried. I remembered seeing it and found it via #2384 and this README for the Libertas firmware patch that implements the "iwpriv eth0 ledbhv" command:

https://cozybit1.dnsalias.org/~javier/patches/0003-More-control-on-LED-behavior.patch

You can make either LED be on, off, or blinking when the firmware is in any of ten different states, as well as change the blink duty cycle -- all under software control. In 8.2-759 software:

# /sbin/iwpriv eth0 ledbhv 1

eth0 ledbhv:1 1 2 4 1 2 1 0 1 3 2 4

I still don't know what all those numbers mean, but the command is present and works!

[cscott]

Wow, excellent work, gnu! Can you suggest "better" settings which we should be using?

[mbletsas]

+ledbhv + Command iwpriv mshX ledbhv can be used to change default LEDs behaviors. + A given LED behavior can be on, off or blinking. The duty/cycle can be set + when behavior is programmed as blinking. + + Usage: + + 1. To get default LED behavior + iwpriv mshX ledbhv <firmware state> + + 2. To set or change default LED behavior + iwpriv mshX ledbhv <firmware state> <lednum> <behavior> <arg> + + firmware state: The following are some of the relevant states. + 00: disconnected + 01: firmware is scanning + 02: firmware is connected and awake + 03: firmware is sleeping + 04: connected deep sleep + 06: firmware disconnected link lost + 07: firmware disconnected disassociated + 09: data transfer while firmware is associated and not scanning. + If firmware is already in this state, LED behavior does not change + on this data transfer. + 10: firmware idle, not scanning, not disconnected or disassociated. + + lednum: 1 or 2 for first and second LED. + + behavior: 0 for steady ON, 1 - steady off and 2- blinking. + + arg: It is used when behavior is 2 to set duty and cycle. It is defined as + (duty << 4 | cycle). Here duty could be 0..4 and cycle 0..5 for 34, + 74, 149, 298, 596, 1192 ms respectively. + + Examples: + + 1. To get default behavior for scan + iwpriv mshX ledbhv 1 + + 2. To get default behavior while data transfer + iwpriv mshX ledbhv 9 + + 3. To turn off LED 2 + iwpriv mshX ledbhv 2 2 1 0 + iwpriv mshX ledbhv 10 2 1 0 + + 4. To enable LED 2 and blink LED 1 while data transfer. + iwpriv mshX ledbhv 9 2 0 0 + iwpriv mshX ledbhv 9 1 2 4 + + 5. To change duty cycle of LED 2 during data transfer + iwpriv mshX ledbhv 9 2 2 36 + + 6. To turn ON LED 2 when firmware is disassociated/disconnected. + iwpriv mshX ledbhv 0 2 0 0 + +

[mikus]

What is needed is to have someone actually INSERT the LED-commands in the appropriate spots in the software. [This is probably too intrusive a change to be contemplated for 8.2.0.]

---

Given that "what is happening with the mesh" is now being shown in the Frame, the following are my Sep 2008 recommendations for how those lights should be used:

• Left light: 'Steady On' when a connection exists to the internet (e.g., a public server with an IP address reachable over the internet can respond to a request to that address made by this XO). 'Slow Blinking' between the time when connection to an AP is attempted, and the time when that connection enters a state of "connected", or enters a state of "connection failed, no longer trying to connect". 'Off' when the chips in the XO are not in a state to transmit data to a destination which (barring problems) can be expected to exist on the internet.

• Right light: 'Medium Fast Blinking' while data (but not merely protocol headers) is being transmitted/received over the radio in the XO. 'Off' otherwise.