1. 17 Jul, 2014 33 commits
  2. 16 Jul, 2014 7 commits
    • Christoph Schulz's avatar
      net: ppp: access ppp->nextseq only if CONFIG_PPP_MULTILINK is defined · a9f559c3
      Christoph Schulz authored
      Commit d762d038 resets the counter holding the
      next sequence number for multilink PPP fragments to zero whenever the
      SC_MULTILINK flag is set. However, this counter only exists if
      CONFIG_PPP_MULTILINK is defined. Consequently, the new code has to be enclosed
      within #ifdef CONFIG_PPP_MULTILINK ... #endif.
      Signed-off-by: default avatarChristoph Schulz <develop@kristov.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a9f559c3
    • David S. Miller's avatar
      Merge branch 'sctp-next' · ed410ecf
      David S. Miller authored
      Daniel Borkmann says:
      
      ====================
      SCTP updates
      
      This set improves the SCTP socket API to be more in line with RFC6458,
      Geir and myself have finalized it eventually. While at it, the first
      patch also fixes two possible information leaks that should go to net
      tree as well (therefore the change is already here in net-next via a
      merge of the 'net' tree -DaveM). For more details, I refer you to the
      patches themselves.
      
      Thanks a lot.
      
      v1 -> v2:
       - Added 6th patch to deprecate SCTP_SNDRCV, rest unchanged
      ====================
      
      CC: Jay Vosburgh <j.vosburgh@gmail.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      Signed-off-by: default avatarVeaceslav Falico <vfalico@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ed410ecf
    • Daniel Borkmann's avatar
      net: sctp: deprecate rfc6458, 5.3.2. SCTP_SNDRCV support · bbbea41d
      Daniel Borkmann authored
      With support of SCTP_SNDINFO/SCTP_RCVINFO as described in RFC6458,
      5.3.4/5.3.5, we can now deprecate SCTP_SNDRCV. The RFC already
      declares it as deprecated:
      
        This structure mixes the send and receive path. SCTP_SNDINFO
        (described in Section 5.3.4) and SCTP_RCVINFO (described in
        Section 5.3.5) split this information. These structures should
        be used, when possible, since SCTP_SNDRCV is deprecated.
      
      So whenever a user tries to subscribe to sctp_data_io_event via
      setsockopt(2) which triggers inclusion of SCTP_SNDRCV cmsg_type,
      issue a warning in the log.
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bbbea41d
    • Geir Ola Vaagland's avatar
      net: sctp: implement rfc6458, 8.1.31. SCTP_DEFAULT_SNDINFO support · 6b3fd5f3
      Geir Ola Vaagland authored
      This patch implements section 8.1.31. of RFC6458, which adds support
      for setting/retrieving SCTP_DEFAULT_SNDINFO:
      
        Applications that wish to use the sendto() system call may wish
        to specify a default set of parameters that would normally be
        supplied through the inclusion of ancillary data. This socket
        option allows such an application to set the default sctp_sndinfo
        structure. The application that wishes to use this socket option
        simply passes the sctp_sndinfo structure (defined in Section 5.3.4)
        to this call. The input parameters accepted by this call include
        snd_sid, snd_flags, snd_ppid, and snd_context. The snd_flags
        parameter is composed of a bitwise OR of SCTP_UNORDERED, SCTP_EOF,
        and SCTP_SENDALL. The snd_assoc_id field specifies the association
        to which to apply the parameters. For a one-to-many style socket,
        any of the predefined constants are also allowed in this field.
        The field is ignored for one-to-one style sockets.
      
      Joint work with Daniel Borkmann.
      Signed-off-by: default avatarGeir Ola Vaagland <geirola@gmail.com>
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6b3fd5f3
    • Geir Ola Vaagland's avatar
      net: sctp: implement rfc6458, 5.3.6. SCTP_NXTINFO cmsg support · 2347c80f
      Geir Ola Vaagland authored
      This patch implements section 5.3.6. of RFC6458, that is, support
      for 'SCTP Next Receive Information Structure' (SCTP_NXTINFO) which
      is placed into ancillary data cmsghdr structure for each recvmsg()
      call, if this information is already available when delivering the
      current message.
      
      This option can be enabled/disabled via setsockopt(2) on SOL_SCTP
      level by setting an int value with 1/0 for SCTP_RECVNXTINFO in
      user space applications as per RFC6458, section 8.1.30.
      
      The sctp_nxtinfo structure is defined as per RFC as below ...
      
        struct sctp_nxtinfo {
          uint16_t nxt_sid;
          uint16_t nxt_flags;
          uint32_t nxt_ppid;
          uint32_t nxt_length;
          sctp_assoc_t nxt_assoc_id;
        };
      
      ... and provided under cmsg_level IPPROTO_SCTP, cmsg_type
      SCTP_NXTINFO, while cmsg_data[] contains struct sctp_nxtinfo.
      
      Joint work with Daniel Borkmann.
      Signed-off-by: default avatarGeir Ola Vaagland <geirola@gmail.com>
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2347c80f
    • Geir Ola Vaagland's avatar
      net: sctp: implement rfc6458, 5.3.5. SCTP_RCVINFO cmsg support · 0d3a421d
      Geir Ola Vaagland authored
      This patch implements section 5.3.5. of RFC6458, that is, support
      for 'SCTP Receive Information Structure' (SCTP_RCVINFO) which is
      placed into ancillary data cmsghdr structure for each recvmsg()
      call.
      
      This option can be enabled/disabled via setsockopt(2) on SOL_SCTP
      level by setting an int value with 1/0 for SCTP_RECVRCVINFO in user
      space applications as per RFC6458, section 8.1.29.
      
      The sctp_rcvinfo structure is defined as per RFC as below ...
      
        struct sctp_rcvinfo {
          uint16_t rcv_sid;
          uint16_t rcv_ssn;
          uint16_t rcv_flags;
          <-- 2 bytes hole  -->
          uint32_t rcv_ppid;
          uint32_t rcv_tsn;
          uint32_t rcv_cumtsn;
          uint32_t rcv_context;
          sctp_assoc_t rcv_assoc_id;
        };
      
      ... and provided under cmsg_level IPPROTO_SCTP, cmsg_type
      SCTP_RCVINFO, while cmsg_data[] contains struct sctp_rcvinfo.
      An sctp_rcvinfo item always corresponds to the data in msg_iov.
      
      Joint work with Daniel Borkmann.
      Signed-off-by: default avatarGeir Ola Vaagland <geirola@gmail.com>
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0d3a421d
    • Geir Ola Vaagland's avatar
      net: sctp: implement rfc6458, 5.3.4. SCTP_SNDINFO cmsg support · 63b94938
      Geir Ola Vaagland authored
      This patch implements section 5.3.4. of RFC6458, that is, support
      for 'SCTP Send Information Structure' (SCTP_SNDINFO) which can be
      placed into ancillary data cmsghdr structure for sendmsg() calls.
      
      The sctp_sndinfo structure is defined as per RFC as below ...
      
        struct sctp_sndinfo {
          uint16_t snd_sid;
          uint16_t snd_flags;
          uint32_t snd_ppid;
          uint32_t snd_context;
          sctp_assoc_t snd_assoc_id;
        };
      
      ... and supplied under cmsg_level IPPROTO_SCTP, cmsg_type
      SCTP_SNDINFO, while cmsg_data[] contains struct sctp_sndinfo.
      An sctp_sndinfo item always corresponds to the data in msg_iov.
      
      Joint work with Daniel Borkmann.
      Signed-off-by: default avatarGeir Ola Vaagland <geirola@gmail.com>
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      63b94938