1. 19 Nov, 2018 1 commit
  2. 16 Nov, 2018 1 commit
  3. 31 Oct, 2018 4 commits
    • Jakub Adam's avatar
      agent: check message length before extracting RFC4571 frame size · 5496500b
      Jakub Adam authored
      nice_socket_recv_messages() may return a NiceInputMessage of length = 0,
      so before attempting to read the RFC4571 header check the message really
      has at least sizeof (guint16) bytes of data.
      The bug's always been there, the previous commit only made it more
    • Jakub Adam's avatar
      udp-turn: handle multiple RFC4571 frames received in a TCP-TURN message · d79d1179
      Jakub Adam authored
      There might be multiple RFC4571-framed messages (or fragments thereof)
      within a single TCP-TURN message. Make sure each NiceInputMessage
      passed by the user into socket_recv_messages() gets exactly one RFC4571
      frame, or remains empty if there aren't any messages to receive.
      We should keep any data that doesn't fit into the user buffers for
      the next time socket_recv_messages() gets called with the socket.
    • Jakub Adam's avatar
      udp-turn: don't re-iterate incoming TURN control messages · 5aa49920
      Jakub Adam authored
      After being parsed, a TURN control message turns into a NiceInputMessage
      with zero length. Such message doesn't increment the iteration counter i
      and so is re-processed in the next iteration, which detects right away
      that message->length == 0 and continues to the next element in
      Thus, n_valid_messages variable serves no real purpose and to achieve
      the same result we can simply increment the iteration counter after each
    • Olivier Crête's avatar
  4. 28 Oct, 2018 7 commits
  5. 21 Oct, 2018 10 commits
  6. 21 Jun, 2018 1 commit
  7. 19 Jun, 2018 2 commits
  8. 18 Jun, 2018 3 commits
  9. 12 Jun, 2018 1 commit
    • Nicolas Dufresne's avatar
      Fix cast-function-type warning introduced in GCC 8 · 23b59268
      Nicolas Dufresne authored
      This is new warning introduced with GCC 8. This is being fixed by using appropriate function, like g_queue_free_full/g_list_free_full or by casting to GCallback before casting to the target function signature.
      Closes: #46
  10. 06 Jun, 2018 4 commits
  11. 04 May, 2018 3 commits
  12. 23 Mar, 2018 3 commits
    • Jakub Adam's avatar
      agent: don't require "reliable" be TRUE in order to use "ice-tcp" · 922ee4e6
      Jakub Adam authored
      Setting writable socket callbacks doesn't have to be limited to reliable
      agents. TCP sockets need the callback in any case for correct operation
      and calling nice_socket_set_writable_callback() on a NiceSocket that has
      UDP as its base has no effect.
      Differential Revision: https://phabricator.freedesktop.org/D1726
    • Jakub Adam's avatar
      discovery: ignore bogus Skype for Business srflx addresses · 54fb0342
      Jakub Adam authored
      If main SfB TURN server sends our allocation request to an alternate
      server, the response will have XOR_MAPPED_ADDRESS containing the IP
      address of the turn server that proxied the message instead of our own
      actual external IP.
      Before we create server reflexive candidates upon receiving an allocate
      response, check that the TURN port got assigned on the same server we
      sent out allocate request to. Otherwise, the request was proxied and
      XOR_MAPPED_ADDRESS contains a bogus value we should ignore.
      Issue introduced by 59fcf95d.
      Differential Revision: https://phabricator.freedesktop.org/D1949
    • Fabrice Bellet's avatar
      agent: make candidate username and password immutable · 5a644f45
      Fabrice Bellet authored
      With this patch we prevent the username and the password of a candidate
      to be modified during a session, as required by the RFC, sect 9.1.2.
      This is also needed from a memory management point of view, because the
      password string pointer may be recorded in the components stun agent
      sent_ids[] struct key member, and freeing these values there may cause
      an use-after-free condition, when an inbound stun is received from this
      candidate. This behavior has been observed with pidgin, xmpp, and
      farstream when a same remote candidates are "updated" several times,
      even if the credentials don't change in this case.
      Reviewed-by: Olivier Crête's avatarOlivier Crête <olivier.crete@collabora.com>
      Differential Revision: https://phabricator.freedesktop.org/D1917