1. 17 Jul, 2014 36 commits
  2. 16 Jul, 2014 4 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