)]}'
{
  "commit": "91f44b02992f632ac6c070f985cd58d5acee4199",
  "tree": "2227e620b444c41398e88d2570fd0838dd856bd3",
  "parents": [
    "42ab135fe78025910bed8ff56e00a375f2b04db1"
  ],
  "author": {
    "name": "Tim Harvey",
    "email": "harvey.tim@gmail.com",
    "time": "Thu Dec 09 13:15:45 2010 -0800"
  },
  "committer": {
    "name": "John W. Linville",
    "email": "linville@tuxdriver.com",
    "time": "Mon Dec 13 15:23:29 2010 -0500"
  },
  "message": "mac80211 default tx_last_beacon false (congestion)\n\nThe 802.11 spec states that the STA that generated the last Beacon frame shall\nbe the STA that response to a probe request.  This is important for congestion\nreduction when a probe request is received - only 1 node in an adhoc BSS\nwill transmit a response.  While mac80211 drivers should provide the\ntx_last_beacon function to report if they transmitted the last beacon many\ndo not.  As an attempt to reduce probe response congestion default this\nto 0 such that a node not implementing this capability does not contribute\nto unnecessary congestion.\n\nIn a modern medium sized office environment I see upwards of 100 probe\nrequests per second received at a given node from various hardware/OS/drivers\ndoing zeroconf \u0027active probing\u0027 as opposed to passively listening for beacons.\nWith a modest 10-node adhoc network consisting of drivers that do not implement\nthis tx_last_beacon feature, I have seen this result in the simultaneous xmit\nof probe responses accumulating to 500 probe responses per second because of\ncollisions which brings the adhoc network to its knees as well as causes\nneedless congestion.\n\nSigned-off-by: John W. Linville \u003clinville@tuxdriver.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "4244554d218af687b7ddb236c2edfc91a4d10b8d",
      "old_mode": 33188,
      "old_path": "net/mac80211/driver-ops.h",
      "new_id": "af0c4398ccebd07b19c38128bd6170da4e7983e8",
      "new_mode": 33188,
      "new_path": "net/mac80211/driver-ops.h"
    }
  ]
}