Active antenna mesh parameters cannot be changed

[carrano]

The way it is now, active antennas mesh parameters cannot be tweaked.

But this is possible with proper driver and firmware (attached to this ticket).

[carrano]

The attached patch can be applied to kernel Source:

olpc-2.6-a985ba6d19d39ccf665a43674c72540be17d6111.tar.gz

This is available on:

http://dev.laptop.org/git?p=olpc-2.6;a=shortlog;h=stable

(Date: 2008-01-18 Signature: a985ba6d19d39ccf665a43674c72540be17d6111)

[bcavagnolo]

Test script for persistent mesh settings in the active antenna

[bcavagnolo]

I implemented iwprivs to access the new extensions to the CMD_MESH_CONFIG firmware command. The patch is posted here: http://lists.laptop.org/pipermail/devel/2008-May/014199.html

The iwprivs are documented here: http://www.laptop.org/teamwiki/index.php/Tech:Wireless

I tested the new functionality using the tests implemented in the attached activeant.sh script. Note that it only tests the iwprivs against the firmware 5.126.0.p5. I also did some casual testing against other firmware versions. I've reassigned to John Watlington for acceptance. The following details may be interesting to future driver maintainers and firmware maintainers:

-- To enable the mesh, the driver formerly sent a string representing the mesh SSID to the firmware. Now, in place of this string, it sends a custom Marvell mesh information element. This change is inspired by the 0002-Flash_Mesh_Parameters.patch from Shailendra. I would have expected this change to break the mesh start/stop functionality in older versions of the firmware. Specifically, I would have expected this to cause the older firmware to put a garbled Marvell mesh IE in the mesh beacon frames. However, I did not observe this. Instead, beacons from versions 5.110.22.p9 and 5.110.22.p14 appear correct and identical. I cannot explain this.

-- I expected the new extended CMD_MESH_CONFIG actions to fail on hardware that does not implement the persistent defaults. This is the behavior with the 5.126.0.p5 firmware. However, with the 5.110.22.pX firmware, they new actions succeed but return all 0s. I would consider this a bug that should be addressed in the 5.110.22.pX firmware. I would recommend fixing the 5.110.22.pX to properly set/get the persistent settings IF it is running on hardware that supports those settings (i.e., an active antenna). This would eliminate the need for the special 5.126.0.p5 firmware.

-- The mesh functionality in the 5.126.0.p5 firmware appears to be broken. In particular, when I set up a mesh network on two XOs using this firmware and the following commands:

$ ifconfig eth1 down $ iwconfig eth1 channel 1 $ iwconfig msh0 essid foobar $ ifconfig msh0 192.168.4.X

They cannot ping each other and a sniffer reveals that no traffic is transmitted from either node. This may or may not be a bug.

-- After much time staring at 0002-Flash_Mesh_Parameters.patch, I realized that the CMD_MESH_CONFIG is extensible using two parameters: type and action. For the mesh start and mesh stop commands, the type comes from the IEEE802.11 proprietary TLV space and the action is either start or stop. For the new getters and setters, the action is either get or set and the type represents the parameter to be getted or setted. OPINION: This is confusing. The types should all come from one space, and the actions should all come from another. I wouldn't call this a bug per se, but it is confusing and messier to maintain, especially if the CMD_MESH_CONFIG command is to be extended further.

[jcardona]

Ashish,

We are testing the new commands to store non-volatile configuration. All seems to work as expected except setting the Mesh Information Element.

To reproduce:

0. Get an active antenna and build a kernel from here http://git.infradead.org/users/dwmw2/olpc-stable-mcast.git

1. Confirm firmware and boot2 versions:

# lsusb -v | grep 31
  bcdDevice           31.1b
# ethtool -i msh0
firmware-version: 5.126.0.p5

2. Change mesh_id

# echo foobar > /sys/class/net/msh0/mesh_ie/mesh_id 
<removed dongle, reinsert>
# cat /sys/class/net/msh0/mesh_ie/mesh_id
foobar

3. Boot into standalone mode (e.g. apply 5V via USB) and sniff. The new mesh ID should appear in the beacon and it does not:

Cimsys_33:44:55       Broadcast             IEEE 802.11 Beacon 

Frame 326 (98 bytes on wire, 98 bytes captured)
Radiotap Header v0, Length 25
IEEE 802.11
IEEE 802.11 wireless LAN management frame
    Fixed parameters (12 bytes)
    Tagged parameters (37 bytes)
        SSID parameter set: Broadcast
        Supported Rates: 1.0(B) 2.0(B) 5.5(B) 11.0(B)
        DS Parameter set: Current Channel: 11
        Extended Supported Rates: 6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0
        Vendor Specific: MarvellS

0000  00 00 19 00 6f 08 00 00 00 00 00 00 00 00 00 00   ....o...........
0010  00 02 9e 09 a0 00 ba 00 02 80 00 00 00 ff ff ff   ................
0020  ff ff ff 00 11 22 33 44 55 00 00 00 00 00 00 90   ....."3DU.......
0030  e8 14 a2 7d e7 60 03 00 00 90 01 00 00 00 00 01   ...}.`..........
0040  04 82 84 8b 96 03 01 0b 32 08 0c 12 18 24 30 48   ........2....$0H
0050  60 6c dd 0e 00 50 43 04 00 00 00 00 00 04 6d 65   `l...PC.......me
                                             ^^^^^^^^                 ^^ 
0060  73 68                                             sh
      ^^^^^                                             ^^

I'm attaching to this ticket the debug logs obtained with libertas_debug=0x206000 which show the commands being sent to the wireless module. It all looks correct to me.

[jcardona]

Replying to jcardona:

3. Boot into standalone mode (e.g. apply 5V via USB) and sniff.

Hmmm, I was improperly executing step 3 above, and the mesh was being configured by the host, not from flash. Retested and all works as expected.

Wad, can you close this once you verify that it works for you?

[gregorio]

Milestone Never Assigned deleted