Ticket #6854 (new defect)

Opened 5 years ago

Last modified 5 years ago

Firmware release - 5.110.22.p8

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

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.

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

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

3. 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

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

Change History

  Changed 5 years ago by mstone

  • cc mstone added

  Changed 5 years ago by carrano

  • status changed from new to closed
  • resolution set to wontfix

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.

  Changed 5 years ago by carrano

  • cc mbletsas added
  • status changed from closed to reopened
  • resolution deleted

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

follow-up: ↓ 7   Changed 5 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.

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

2. OLPC ticket 6709: Stop beacon transmission during monitor mode. http://dev.laptop.org/ticket/6709

3. 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.

in reply to: ↑ description   Changed 5 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"?

in reply to: ↑ 4   Changed 5 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.

  Changed 5 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.

follow-up: ↓ 10   Changed 5 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.

in reply to: ↑ 9   Changed 5 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 5 years ago by carrano

A new driver patch version for the multicast filter

  Changed 5 years ago by gregorio

  • milestone deleted

Milestone Never Assigned deleted

Note: See TracTickets for help on using tickets.