An error occurred fetching the project authors.
  1. 22 Sep, 2015 1 commit
    • Alexander Aring's avatar
      ieee802154: change needed headroom/tailroom · 87a93e4e
      Alexander Aring authored
      This patch cleanups needed_headroom, needed_tailroom and hard_header_len
      fields for wpan and lowpan interfaces.
      
      For wpan interfaces the worst case mac header len should be part of
      needed_headroom, currently this is set as hard_header_len, but
      hard_header_len should be set to the minimum header length which xmit
      call assumes and this is the minimum frame length of 802.15.4.
      The hard_header_len value will check inside send callbacl of AF_PACKET
      raw sockets.
      
      For lowpan interfaces, if fragmentation isn't needed the skb will
      call dev_hard_header for 802154 layer and queue it afterwards. This
      happens without new skb allocation, so we need the same headroom and
      tailroom lengths like 802154 inside 802154 6lowpan layer. At least we
      assume as minimum header length an ipv6 header size.
      Signed-off-by: default avatarAlexander Aring <alex.aring@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      87a93e4e
  2. 17 Sep, 2015 4 commits
  3. 18 Aug, 2015 1 commit
  4. 15 Aug, 2015 1 commit
  5. 11 Aug, 2015 1 commit
  6. 10 Aug, 2015 1 commit
  7. 23 May, 2015 2 commits
  8. 14 Mar, 2015 1 commit
    • Alexander Aring's avatar
      ieee802154: 6lowpan: fix ARPHRD to ARPHRD_6LOWPAN · 965e613d
      Alexander Aring authored
      Currently there exists two interface types with ARPHRD_IEEE802154. These
      are the 802.15.4 interfaces and 802.15.4 6LoWPAN interfaces. This is
      more a bug because some userspace applications checks on this value like
      wireshark. This occurs that wireshark will always try to parse a lowpan
      interface as 802.15.4 frames. With ARPHRD_6LOWPAN wireshark will parse
      it as IPv6 frames which is correct.
      
      Much applications checks on this value to readout the EUI64 mac address
      which should be the same for ARPHRD_6LOWPAN. BTLE 6LoWPAN and ieee802154
      6LoWPAN will share now the same ARPHRD.
      Signed-off-by: default avatarAlexander Aring <alex.aring@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      965e613d
  9. 14 Feb, 2015 1 commit
  10. 08 Jan, 2015 5 commits
  11. 05 Dec, 2014 1 commit
  12. 26 Nov, 2014 1 commit
  13. 06 Nov, 2014 1 commit
  14. 05 Nov, 2014 1 commit
  15. 02 Nov, 2014 1 commit
  16. 27 Oct, 2014 3 commits
  17. 25 Oct, 2014 6 commits
  18. 24 Sep, 2014 1 commit
    • Simon Vincent's avatar
      ieee802154: 6lowpan: ensure header compression does not corrupt ipv6 header · f19f4f95
      Simon Vincent authored
      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: default avatarSimon Vincent <simon.vincent@xsilon.com>
      Signed-off-by: default avatarAlexander Aring <alex.aring@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      f19f4f95
  19. 19 Aug, 2014 2 commits
  20. 14 Aug, 2014 1 commit
  21. 08 Jul, 2014 1 commit
  22. 02 Jun, 2014 2 commits
  23. 15 May, 2014 1 commit
    • Phoebe Buckheister's avatar
      6lowpan: fix fragmentation · d4b2816d
      Phoebe Buckheister authored
      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: default avatarPhoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d4b2816d