#2324 closed bug (Fixed)
deluge and crypto_provide
Reported by: | tristen | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 1.3.7 |
Component: | GTK UI | Version: | 1.3.6 |
Keywords: | Cc: |
Description
deluge gtk appears to be requesting libtorrent to send an incorrect bitfield for crypto_provide on outbound connections.
original forum post: http://forum.deluge-torrent.org/viewtopic.php?f=8&t=43859
libtorrent ticket: https://code.google.com/p/libtorrent/issues/detail?id=474
in a nutshell, deluge gtk is sending via libtorrent:
bitfield 0x00 instead of 0x01 when requesting handshake/plaintext encryption from the outbound peer.
bitfield 0x01 instead of 0x02 when requesting fullstream encryption from the outbound peer.
bitfield 0x02 instead of 0x03 when requesting the outbound peer choose their preferred encryption method.
the implications of this vary depending on which encryption method the user has selected in the gui.
worst case scenario is no outbound peering occurs if the user has selected handshake/plaintext encryption as their encryption method.
outbound peering appears to occur for "fullstream" and "choose" but i suspect the encryption level selected by the peer is actually always "handshake/plaintext" and "fullstream" respectively. however i'm not 100% sure of this, it's a suspicion.
regards tristen
Change History (3)
comment:1 by , 11 years ago
follow-up: 3 comment:2 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Fixed 1.3-stable: 03d5654a1
comment:3 by , 11 years ago
Replying to Cas:
Fixed 1.3-stable: 03d5654a1
heya cas
ok, i've built deluge from source and i can confirm your fix works just fine.
good job!
Ok I understand the issue now, it is due to an assumption that the
enc_level
options are in the range0,1,2
and that is how the clients pass the value to core and then onto libtorrent.Can you verify this will fix it: