)]}'
{
  "commit": "64bf3ab7291cc5c39c5add0dc1a7de447914248b",
  "tree": "d5ae874814083d89815e6c521b42d0f3eaaec69c",
  "parents": [
    "2eb445e1c22e36d07e2dbfd302ff438c4190b9fe"
  ],
  "author": {
    "name": "Ondrej Zajicek",
    "email": "santiago@crfreenet.org",
    "time": "Mon Dec 07 12:33:20 2009 +0300"
  },
  "committer": {
    "name": "Denis Ovsienko",
    "email": "infrastation@yandex.ru",
    "time": "Mon Dec 07 12:33:20 2009 +0300"
  },
  "message": "ospf6d: review LSA sequence number comparison\n\nIt seems that there is a bug in ospf6d in ospf6_lsa_compare(): If LSA A\nhas sequence number smaller than 0x80000000 and LSA B has sequence\nnumber larger than 0x80000000, ospf6_lsa_compare() returns that B is\nmore recent than A, although RFC says that sequence numbers should be\ncompared as signed numbers (0x8000001 smallest and 0x7FFFFFFF largest).\n\nIn ospfd, the function ospf_lsa_more_recent() has it right.\n\nThe problem appears when Quagga is used together with OSPFv3 in\ndevelopment version of BIRD daemon ( http://bird.network.cz/ ),\nwhich creates LSAs with maximum sequence number (0x7FFFFFFF)\nas a part of flushing/premature aging LSA from OSPF area.\n\nBecause both daemons has different idea of which LSA instance\nis more recent, it would lead to LSA storm.\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "07d9f91eb6336422528910d28f9fef10a69d810d",
      "old_mode": 33188,
      "old_path": "ospf6d/ospf6_lsa.c",
      "new_id": "c1db3741bab58c7206ef17d4ae0aeee2e0390ee8",
      "new_mode": 33188,
      "new_path": "ospf6d/ospf6_lsa.c"
    }
  ]
}