Need a document describing supported firmware features

[dcbw]

This would save lots of time because, while reading the v5.1 firmware spec, we'd actually know what we can use. For example:

1) We don't have null packet support, would have been nice to know that 2) We don't have some of the new adaptive power control stuff (?) 3) Do we have any WMM/QoS stuff?

We need an annotated firmware specification describing which features are compiled into each firmware version that we get from Marvell.

[jg]

Can we please quickly get a spec that somehow indicates what is or is not actually implemented, and what's actually compiled in?

[dcbw]

Another issue; when doing an adhoc join or associate, there is no documentation in the specification about what bits in the 'capinfo' field of the IEEEtypes_BssDesc_t field need to be masked out before being passed to the firmware. But the driver masks some bits off. Why are certain undefined bits masked out, and what exactly are those bits that the firmware cares about and why does it care about those and not others?

[jg]

Ronak, even printing a spec on paper, checking off what is available in the code base, marking what is currently compiled into the firmware, and dropping it in the mail to Dan would stop wasting our people's time here.

The enemy of the good is the perfect....

[rchokshi]

Replying to dcbw:

Another issue; when doing an adhoc join or associate, there is no documentation in the specification about what bits in the 'capinfo' field of the IEEEtypes_BssDesc_t field need to be masked out before being passed to the firmware. But the driver masks some bits off. Why are certain undefined bits masked out, and what exactly are those bits that the firmware cares about and why does it care about those and not others?

The bits that are not supported in IBSS mode are masked off by the driver in 'capinfo' field of the IEEEtypes_BssDesc_t. These bits are QoS (bit 9), APSD (bit 11), Reserved (bit 12), Delayed/Immediate Block ACK(bits 14,15).

More updates coming up....

[rchokshi]

Replying to dcbw:

This would save lots of time because, while reading the v5.1 firmware spec, we'd actually know what we can use. For example: 1) We don't have null packet support, would have been nice to know that

NULL packet support has been added to the firmware now. We are validating the feature right now. We should be able to post an updated firmware build in a few days on the TechWiki.

2) We don't have some of the new adaptive power control stuff (?)

Per packet TPC is not there.

3) Do we have any WMM/QoS stuff?

WMM/QOS feature is available in infrastructure mode only- not in the mesh mode.

[rchokshi]

Some more information in regards to the WLAN Firmware specification v5.1:

The following is based on firmware specification v 5.1 Doc MV-S 103752-00


COMMANDS NOT SUPPORTED
----------------------
1. [page 25]
Per packet transmission rate will not work in mesh mode due to the fact that
   mesh mode rate adaption overrides TxControl per packet rate field.

2. [page 33 ]
 buildModes_HIF_SPI  is not supported.

3. [page  52]
CMD_802_11_BG_SCAN_CONFIG
CMD_802_11_BG_SCAN_QUERY 

4. [page 59]
CMD_802_11_ASSOCIATE 

5. [page 70]
rate adaptation commands are not supported for per peer MPs in mesh mode.

6. [p 73]
Transmit power control is not supported on per packet/peer basis.

7. [p 87]
CMD_802_11_FW_WAKE_METHOD 

8. [p 86]
CMD_802_11_WAKEUP_CONFIRM 

9
CMD_802_11_PS_MODE 

10 [p 91]
CMD_802_11_DEEP_SLEEP

11. [p 97]
CMD_802_11_BCA_CONFIG_TIMESHARE

12. [p 106]
DFS (Dynamic frequency selection) 802.11h is not supported.



NEW MESH COMMANDS
------------------
 - host_CMD_802_11_HOSTSLEEP_ACTIVE (code 0x0045) added as part of enhanced host
   sleep. Host gets a confirmation from the firmware

 - {set,get}_rreq_costs "cost54 cost36 cost11 cost1"
       Specify the link cost at each rate. Setting a specific cost to
       0 will disable transmitting a RREQ at that rate.

 - mesh_{set,get}bcast_r <n>
       Sets the rate for mesh broadcast data frames. Index <n> is the rate
       index (same as for rateadapt command, see driver README). Without
       arguments, shows the current rate.

 - {set,get}_rreq_delay <ms>
       Sets the delay in ms between the moment an RREQ is
       received and the moment it is forwarded or answered. Without
       arguments, it shows the current delay. 

 - {set,get}_route_expiration <s>
       Sets the route expiration times, in seconds. When expired,
       a route will be refreshed.

  --- monitor mode operation
  echo mode > /sys/class/net/{ethX,mshX}/device/libertas_rtap

   where mode is the hex mask that specifies which frames to sniff (in short, 0x1 for data, 0x2 for all management but beacons, 0x4 for beacons). Any non zero mode will activate the monitor mode, inhibiting transmission in ethX and mshX interfaces and routing all the traffic to a new rtapX interface that will output the packets in 802.11+radiotap headers format.
   CMD_802_11_SNIFFER_MODE

  --- Support for 32 anycast addresses for MPP operation.
Support for up to 32 anycast addresses substituting former MPP_ANYCAST address. The anycast address range is C0:27:C0:27:C0:XX where XX goes from 00 to 1F (or 0 to 31 in dec). The value to write on anycast_mask will specify which addresses the device listens to. Bits in a 32 bit int are numbered from 0 (least significant bit) to 31. A specific address ending in YY will be listened to if bit YY in the value is set to one. Examples:

0x00000000 : do not listen to any anycast address 0xFFFFFFFF : listen to every anycast address from :00 to :1F
0x00000013 : listen to anycast addresses :00, :01 and :04


Mesh autostart control: Allows to enable or disable the mesh autostart feature. It can be configured with  # echo Z > /sys/class/net/mshX/autostart_enabled

where Z is zero to disable the autostart and non-zero to enable it.
It is enabled by default. To support this, two new mesh_access subcommands, mesh_{set,get}_autostart_enabled (0x14 and 0x15).


-- - Mesh TTL 
firmware side integrated (based on previous Sailendra Govardhan work)

Support for per-packet mesh TTL in firmware. The patch was based on Sailendra's work but was modified to work better with Javier driver patch. It will only look for the mesh TTL on the frame coming from the host if the TxPacketOffset indicates that the mesh header part of the wcb_t structure was filled at the driver. Otherwise it will use the default mesh TTL. This is important as offers complete backwards compatibility with previous drivers.

--- New SET_BOOT2_VER commands (for OLPC ticket #1694)


NEW EVENTS
-----------

1. MESH_AUTO_STARTED (23)


OTHER CHANGES
-------------
1. [page 25]
TxControl in TxPD does not define control bit for mesh interface.

2. [p22]
 RxControl In RxPD does not define control bit for mesh frames

[rchokshi]

Further information regarding features incorporated and tested as part of the wireless system:

List of features supported and verified:

Core 802.11abg client (infra mode, adhoc mode) 
Marvell mesh support 
WPA in infra mode 
WEP, TKIP and AES encryption 
USB host i/f 
Enhanced host sleep 
Linux 2.6 only 
Monitor/Sniffer mode 
 
Mesh features:
Marvell Mesh routing which is similar to IEEE 802.11s D1.05 HWMP routing protocol.
Mesh auto start feature, when there is no association for a given time; this feature can be disabled or enabled from the host.
Mesh basic rate adaptation for data frames based on route discovery. However, this rate adaptation mechanism uses same rate for the entire link lifetime –no periodic or dynamic rate adjustment after frame exchange. For a given link its data rate is derived at the time of route discovery.
Support for configuring mesh default TTL for mesh data and RREQ frames. 
Support for mesh per packet TTL. 
Monitor mode operation, which allows all frames, except 802.11 control frames, to be received at the host. 
Enhanced host sleep mode. 
Support for Mesh Port Point MPP. Support for 32 anycast address for MPP. MAC Address C0:27:C0:27:C0:[00-1f] are reserved for anycast addresses. 
Mesh Beacon and probe response containing Marvell mesh IE. 
Mesh visual indicator: LED1 On if associated to infra AP or mesh join/start. LED2 blinks with frames rx/tx. 
Blinding table feature to setup the desired multi-hop topologies. 
APIs to monitor or change mesh mode operation. This include APIs to 
1) get/set mesh routing table
2) get/set mesh neighbour
3) get/set link cost
4) get/set blinding table
5) get/set RREQ broadcast rate.
6) get mesh stats (total forwarded packet, dropped packet, received, tx error etc.)
7) get/set mesh default TTL
8) get/set mesh route properties
9) get/set mesh auto start enable/disable
10) get/set monitor mode 

[kimquirk]

Lowered this priority. If you have the info you need, Dan, please close this bug.

[rchokshi]

Replying to rchokshi:

Further information regarding features incorporated and tested as part of the wireless system: {{{ List of features supported and verified: Core 802.11abg client (infra mode, adhoc mode)

Correction: Core 802.11bg client (infra mode, adhoc mode)

Marvell mesh support WPA in infra mode WEP, TKIP and AES encryption USB host i/f Enhanced host sleep Linux 2.6 only Monitor/Sniffer mode Mesh features: Marvell Mesh routing which is similar to IEEE 802.11s D1.05 HWMP routing protocol. Mesh auto start feature, when there is no association for a given time; this feature can be disabled or enabled from the host. Mesh basic rate adaptation for data frames based on route discovery. However, this rate adaptation mechanism uses same rate for the entire link lifetime –no periodic or dynamic rate adjustment after frame exchange. For a given link its data rate is derived at the time of route discovery. Support for configuring mesh default TTL for mesh data and RREQ frames. Support for mesh per packet TTL. Monitor mode operation, which allows all frames, except 802.11 control frames, to be received at the host. Enhanced host sleep mode. Support for Mesh Port Point MPP. Support for 32 anycast address for MPP. MAC Address C0:27:C0:27:C0:[00-1f] are reserved for anycast addresses. Mesh Beacon and probe response containing Marvell mesh IE. Mesh visual indicator: LED1 On if associated to infra AP or mesh join/start. LED2 blinks with frames rx/tx. Blinding table feature to setup the desired multi-hop topologies. APIs to monitor or change mesh mode operation. This include APIs to 1) get/set mesh routing table 2) get/set mesh neighbour 3) get/set link cost 4) get/set blinding table 5) get/set RREQ broadcast rate. 6) get mesh stats (total forwarded packet, dropped packet, received, tx error etc.) 7) get/set mesh default TTL 8) get/set mesh route properties 9) get/set mesh auto start enable/disable 10) get/set monitor mode }}}

[shirish]

sorry, I don't know what next_action means its a default thing. I just wanted to add my name to the CC so I know where you guys are going.