1. 01 11月, 2005 1 次提交
  2. 29 10月, 2005 1 次提交
    • Y
      [MCAST] IPv6: Fix algorithm to compute Querier's Query Interval · f12baeab
      Yan Zheng 提交于
      5.1.3.  Maximum Response Code
      
         The Maximum Response Code field specifies the maximum time allowed
         before sending a responding Report.  The actual time allowed, called
         the Maximum Response Delay, is represented in units of milliseconds,
         and is derived from the Maximum Response Code as follows:
      
         If Maximum Response Code < 32768,
            Maximum Response Delay = Maximum Response Code
      
         If Maximum Response Code >=32768, Maximum Response Code represents a
         floating-point value as follows:
      
             0 1 2 3 4 5 6 7 8 9 A B C D E F
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |1| exp |          mant         |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      
         Maximum Response Delay = (mant | 0x1000) << (exp+3)
      
      
      5.1.9.  QQIC (Querier's Query Interval Code)
      
         The Querier's Query Interval Code field specifies the [Query
         Interval] used by the Querier.  The actual interval, called the
         Querier's Query Interval (QQI), is represented in units of seconds,
         and is derived from the Querier's Query Interval Code as follows:
      
         If QQIC < 128, QQI = QQIC
      
         If QQIC >= 128, QQIC represents a floating-point value as follows:
      
             0 1 2 3 4 5 6 7
            +-+-+-+-+-+-+-+-+
            |1| exp | mant  |
            +-+-+-+-+-+-+-+-+
      
         QQI = (mant | 0x10) << (exp + 3)
      
                                                      -- rfc3810
      
      #define MLDV2_QQIC(value) MLDV2_EXP(0x80, 4, 3, value)
      #define MLDV2_MRC(value) MLDV2_EXP(0x8000, 12, 3, value)
      
      Above macro are defined in mcast.c. but 1 << 4 == 0x10 and 1 << 12 == 0x1000.
      So the result computed by original Macro is larger.
      Signed-off-by: NYan Zheng <yanzheng@21cn.com>
      Acked-by: NDavid L Stevens <dlstevens@us.ibm.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>
      f12baeab
  3. 06 10月, 2005 1 次提交
  4. 15 9月, 2005 1 次提交
  5. 09 7月, 2005 3 次提交
  6. 22 6月, 2005 2 次提交
    • P
      [NETFILTER]: Restore netfilter assumptions in IPv6 multicast · e9823185
      Patrick McHardy 提交于
      Netfilter assumes that skb->data == skb->nh.ipv6h
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e9823185
    • D
      [IPV6]: multicast join and misc · c9e3e8b6
      David L Stevens 提交于
      Here is a simplified version of the patch to fix a bug in IPv6
      multicasting. It:
      
      1) adds existence check & EADDRINUSE error for regular joins
      2) adds an exception for EADDRINUSE in the source-specific multicast
              join (where a prior join is ok)
      3) adds a missing/needed read_lock on sock_mc_list; would've raced
              with destroying the socket on interface down without
      4) adds a "leave group" in the (INCLUDE, empty) source filter case.
              This frees unneeded socket buffer memory, but also prevents
              an inappropriate interaction among the 8 socket options that
              mess with this. Some would fail as if in the group when you
              aren't really.
      
      Item #4 had a locking bug in the last version of this patch; rather than
      removing the idev->lock read lock only, I've simplified it to remove
      all lock state in the path and treat it as a direct "leave group" call for
      the (INCLUDE,empty) case it covers. Tested on an MP machine. :-)
      
      Much thanks to HoerdtMickael <hoerdt@clarinet.u-strasbg.fr> who
      reported the original bug.
      Signed-off-by: NDavid L Stevens <dlstevens@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c9e3e8b6
  7. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4