Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • gajim gajim
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Graph
    • Compare revisions
  • Issues 209
    • Issues 209
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 8
    • Merge requests 8
  • Deployments
    • Deployments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • gajimgajim
  • gajimgajim
  • Issues
  • #9784
Closed
Open
Issue created Aug 06, 2019 by hrxi@hrxi

Jingle SOCKS5 fallback does not work correctly if Gajim is the initiator

This is similar, but different from #9692 (closed), where a different problem happens if Gajim is the responder for a SOCKS5 to IBB fallback.

Versions

  • OS: Arch Linux
  • Gajim version: 1.1.3
  • GTK version: 3.24.10
  • Python-nbxmpp version: 0.6.10

Steps to reproduce the problem

  1. Inititate a file transfer to an entity.
  2. (Ensure that all SOCKS5 candidates fail.)
  3. Observe the outgoing transport-replace for IBB by Gajim.
  4. Observe the incoming transport-accept by another client (e.g. Dino after https://github.com/dino/dino/pull/592 is merged).

Expected behavior

Gajim opens the in-band bytestream (as it is the initiator).

Actual behavior

Nothing happens after the transport-accept is acknowledged by Gajim.

Assignee
Assign to
Time tracking