Opened 7 years ago

Closed 9 months ago

#6854 closed defect (fixed)

Firmware release - 5.110.22.p8

Reported by: carrano Owned by: ashish
Priority: normal Milestone:
Component: distro Version:
Keywords: Cc: mstone, mbletsas, carrano, jcardona
Blocked By: Blocking:
Deployments affected: Action Needed: no action
Verified: no

Description

FW release W8388-5.110.22.p8

New Features

  1. Dynamic MAC contention window adaptation.

Based on number of neighbors MAC contention window is adjusted.
Current implementation relies on beacons received, with assumption
of 100ms beacon interval, and active neighbors.

Bug Fixes

  1. OLPC ticket 4616: Mesh doesn't resume from suspend on receipt of multicast packets.

http://dev.laptop.org/ticket/4616
Multicast filter in firmware also filtering broadcast packets.
Modified the filter so that filter will not process broadcast packets.

  1. OLPC ticket 6709: Stop beacon transmission during monitor mode.

http://dev.laptop.org/ticket/6709

  1. OLPC ticket 4927: [firmware] beacon interval gets reset by other operations

http://dev.laptop.org/ticket/4927
Preserve beacon setting during scan.

Binary file

Can be found at:
http://www.laptop.org/teamwiki/images/6/60/Libertas-firmware.tgz

Attachments (1)

mesh_mcast_v2.patch (7.8 KB) - added by carrano 7 years ago.
A new driver patch version for the multicast filter

Download all attachments as: .zip

Change History (13)

comment:1 Changed 7 years ago by mstone

  • Cc mstone added

comment:2 Changed 7 years ago by carrano

  • Resolution set to wontfix
  • Status changed from new to closed

This firmware should be skipped in favor of version 5.110.22.p9 (#6869), which is based on 5.110.22.p8 but fixes an important blocker bug (#6589).

I suggest putting effort tests in 22.p9 version and remind that release 5.110.22.p6 (#6706) passed initial tests and is more than ready to be included in builds.

I am closing this ticket. If someone objects, please reopen.

comment:3 Changed 7 years ago by carrano

  • Cc mbletsas added
  • Resolution wontfix deleted
  • Status changed from closed to reopened

I am reopening this ticket, since the strategy of going directly to 22.p9 failed.

comment:4 follow-up: Changed 7 years ago by carrano

  • Cc carrano jcardona added
  • Owner changed from dgilmore to ashish
  • Status changed from reopened to new

In tests with build 702 and this firmware it happens that neighbors are not being displayed in the mesh view.

This seems related to the fact that avahi-browse in the failing node does not return the expected data. It only returns entries related to the failing node itself.

Maybe as a consequence of the above telepathy-salut crashes.

It is established that the failing XO is still able to send out and receive unicast and multicast frames.

comment:5 in reply to: ↑ description Changed 7 years ago by carrano

  1. OLPC ticket 6709: Stop beacon transmission during monitor mode.

http://dev.laptop.org/ticket/6709


  1. OLPC ticket 4927: [firmware] beacon interval gets reset by other operations

http://dev.laptop.org/ticket/4927
Preserve beacon setting during scan.

I confirm that this firmware fixes both bugs (above). Although I am keeping respective tickets open until we have an approved firmware release with these fixes.

comment:6 in reply to: ↑ description Changed 7 years ago by carrano

New Features

  1. Dynamic MAC contention window adaptation.

Based on number of neighbors MAC contention window is adjusted.
Current implementation relies on beacons received, with assumption
of 100ms beacon interval, and active neighbors.

Do we need to rely on beacons for that?

The beacon interval can be changed and beacons can even be disabled (this very firmware implements this).

What is the source for the neighbor information on "iwpriv msh0 fwt_list_neigh"?

comment:7 in reply to: ↑ 4 Changed 7 years ago by carrano

Replying to carrano:

In tests with build 702 and this firmware it happens that neighbors are not being displayed in the mesh view.

Note: this does not affect firmware version 22p6.

comment:8 Changed 7 years ago by carrano

Ashish pointed out that, "22.p8/p9 has software based multicast filtering in the firmware, and
therefore, in mesh only mode, firmware drops all multicast frames as current driver does not populate multicast MAC address".

I believe that if the driver has to explicit inform the firmware that it should accept frames for 01:00:5e:00:00:fb and it's not doing this (I am assuming it is not, but did not check the code), this seems an explanation, or at least a good direction.

For this theory to be consistent, we should explain why the filter for 01:00:5e:00:00:01 is implemented (we know that this is true, because the node replies to pings at 224.0.0.1). I believe this is an accepted mac address by default but there may be another explanation.

We also know that if an application explicitly asks for a binding, the filter will be dynamically created (we know that because I tested with an application I've written that relies on multicast).

In short, I believe that this is a possible explanation for the mesh/view problem.

comment:9 follow-up: Changed 7 years ago by carrano

Tests with the patch in http://dev.laptop.org/attachment/ticket/6818/mesh_mcast.patch confirmed that the root cause for the mesh view problem (#6818) is the multicast filter not being populated by the driver.

comment:10 in reply to: ↑ 9 Changed 7 years ago by carrano

Replying to carrano:

Tests with the patch in http://dev.laptop.org/attachment/ticket/6818/mesh_mcast.patch confirmed that the root cause for the mesh view problem (#6818) is the multicast filter not being populated by the driver.

After some unknown time (I was not looking but it is less than 1 hour) the mesh view was again displaying no XOs. We have to keep investigating #6818.

Changed 7 years ago by carrano

A new driver patch version for the multicast filter

comment:11 Changed 6 years ago by gregorio

  • Milestone Never Assigned deleted

Milestone Never Assigned deleted

comment:12 Changed 9 months ago by Quozl

  • Action Needed set to no action
  • Resolution set to fixed
  • Status changed from new to closed

Long since fixed, closing.

Note: See TracTickets for help on using tickets.