)]}'
{
  "commit": "444fc8fc3a1f926fa224655b8950bd853368c1a3",
  "tree": "f6359721fc50ac3802b30d705e2c7c06b983c5f8",
  "parents": [
    "496a22b08fa326bf17c11eb900e0505aa9da3506"
  ],
  "author": {
    "name": "Herbert Xu",
    "email": "herbert@gondor.apana.org.au",
    "time": "Mon Oct 03 14:18:10 2005 -0700"
  },
  "committer": {
    "name": "David S. Miller",
    "email": "davem@davemloft.net",
    "time": "Mon Oct 03 14:18:10 2005 -0700"
  },
  "message": "[IPV4]: Fix \"Proxy ARP seems broken\"\n\nMeelis Roos \u003cmroos@linux.ee\u003e wrote:\n\u003e RK\u003e My firewall setup relies on proxyarp working.  However, with 2.6.14-rc3,\n\u003e RK\u003e it appears to be completely broken.  The firewall is 212.18.232.186,\n\u003e \n\u003e Same here with some kernel between 14-rc2 and 14-rc3 - no reposnse to\n\u003e ARP on a proxyarp gateway. Sorry, no exact revison and no more debugging\n\u003e yet since it\u0027a a production gateway.\n\nThe breakage is caused by the change to use the CB area for flagging\nwhether a packet has been queued due to proxy_delay.  This area gets\ncleared every time arp_rcv gets called.  Unfortunately packets delayed\ndue to proxy_delay also go through arp_rcv when they are reprocessed.\n\nIn fact, I can\u0027t think of a reason why delayed proxy packets should go\nthrough netfilter again at all.  So the easiest solution is to bypass\nthat and go straight to arp_process.\n\nThis is essentially what would\u0027ve happened before netfilter support\nwas added to ARP.\n\nSigned-off-by: Herbert Xu \u003cherbert@gondor.apana.org.au\u003e \nSigned-off-by: David S. Miller \u003cdavem@davemloft.net\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "8bf312bdea13c50f48291df5481affb6cfc10f4a",
      "old_mode": 33188,
      "old_path": "net/ipv4/arp.c",
      "new_id": "ec0e36893b013fa3c044fc04e9ba71839b5d3c01",
      "new_mode": 33188,
      "new_path": "net/ipv4/arp.c"
    }
  ]
}