1. 08 1月, 2015 5 次提交
  2. 05 12月, 2014 1 次提交
  3. 26 11月, 2014 1 次提交
  4. 07 11月, 2014 1 次提交
  5. 06 11月, 2014 1 次提交
  6. 02 11月, 2014 1 次提交
  7. 27 10月, 2014 3 次提交
  8. 26 10月, 2014 1 次提交
  9. 25 10月, 2014 5 次提交
  10. 24 9月, 2014 1 次提交
    • S
      ieee802154: 6lowpan: ensure header compression does not corrupt ipv6 header · f19f4f95
      Simon Vincent 提交于
      The 6lowpan ipv6 header compression was causing problems for other interfaces
      that expected a ipv6 header to still be in place, as we were replacing the
      ipv6 header with a compressed version. This happened if you sent a packet to a
      multicast address as the packet would be output on 802.15.4, ethernet, and also
      be sent to the loopback interface. The skb data was shared between these
      interfaces so all interfaces ended up with a compressed ipv6 header.
      
      The solution is to ensure that before we do any header compression we are not
      sharing the skb or skb data with any other interface. If we are then we must
      take a copy of the skb and skb data before modifying the ipv6 header.
      The only place we can copy the skb is inside the xmit function so we don't
      leave dangling references to skb.
      
      This patch moves all the header compression to inside the xmit function. Very
      little code has been changed it has mostly been moved from lowpan_header_create
      to lowpan_xmit. At the top of the xmit function we now check if the skb is
      shared and if so copy it. In lowpan_header_create all we do now is store the
      source and destination addresses for use later when we compress the header.
      Signed-off-by: NSimon Vincent <simon.vincent@xsilon.com>
      Signed-off-by: NAlexander Aring <alex.aring@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      f19f4f95
  11. 20 8月, 2014 2 次提交
  12. 14 8月, 2014 1 次提交
  13. 08 7月, 2014 1 次提交
  14. 03 6月, 2014 2 次提交
  15. 16 5月, 2014 2 次提交
    • P
      6lowpan: fix fragmentation · d4b2816d
      Phoebe Buckheister 提交于
      Currently, 6lowpan creates one 802.15.4 MAC header for the original
      packet the device was given by upper layers and reuses this header for
      all fragments, if fragmentation is required. This also reuses frame
      sequence numbers, which must not happen. 6lowpan also has issues with
      fragmentation in the presence of security headers, since those may imply
      the presence of trailing fields that are not accounted for by the
      fragmentation code right now.
      
      Fix both of these issues by properly allocating fragment skbs with
      headromm and tailroom as specified by the underlying device, create one
      header for each skb instead of reusing the original header, let the
      underlying device do the rest.
      Signed-off-by: NPhoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d4b2816d
    • P
      ieee802154: change _cb handling slightly · 32edc40a
      Phoebe Buckheister 提交于
      The current mac_cb handling of ieee802154 is rather awkward and limited.
      Decompose the single flags field into multiple fields with the meanings
      of each subfield of the flags field to make future extensions (for
      example, link-layer security) easier. Also don't set the frame sequence
      number in upper layers, since that's a thing the MAC is supposed to set
      on frame transmit - we set it on header creation, but assuming that
      upper layers do not blindly duplicate our headers, this is fine.
      Signed-off-by: NPhoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      32edc40a
  16. 19 3月, 2014 1 次提交
  17. 15 3月, 2014 5 次提交
  18. 13 3月, 2014 1 次提交
  19. 07 3月, 2014 1 次提交
  20. 03 3月, 2014 2 次提交
  21. 01 3月, 2014 2 次提交