Opened 13 years ago

Last modified 21 months ago

#1453 new bug

If binding to specified network adress fails, daemon defaults back to 0.0.0.0

Reported by: Sian Owned by:
Priority: minor Milestone: 2.1.1
Component: libtorrent Version: 1.3.0
Keywords: Cc: Hiro, bro

Description

Observed behaviour:

If binding to the specified network adress fails, the dæmon silently ignores the setting and binds to 0.0.0.0, thus using any available network interface.

Problem: In certain use cases, this behavior is not preferable. Quote from the forums:

This is a problem because I (and I guess, many people who might want to use it) want my p2p traffic to go exclusively through my VPN. Another use case is people with a 3G connection; you might want to bind to wlan0 when you're at home and traffic is free, but definitely don't want it to go through the cell interface.

Related to this: Would it be possible to allow not only IP adress as valid input in the specified network adress input field, but either interface names (ath0, eth1, etc.) or host names? Combined with some sort of internal check and update mechanism, deluge could bind dynamically to IP adresses. So users wouldn't need to really on an external script to update the adress to bind to (as tried in the forum thread linked above).

Change History (14)

comment:1 Changed 13 years ago by Sian

  • Summary changed from If binding to specified network adress fails, dæmon defaults back to 0.0.0.0 to If binding to specified network adress fails, daemon defaults back to 0.0.0.0

comment:2 follow-up: Changed 9 years ago by Stephen304

I'm sure many other people also torrent over VPN and would like to ensure that deluge stays on ppp1 or whatever their VPN interface is.

comment:3 in reply to: ↑ 2 Changed 9 years ago by Hiro

Replying to Stephen304:

I'm sure many other people also torrent over VPN and would like to ensure that deluge stays on ppp1 or whatever their VPN interface is.

+1 Here! Would be a great feature!

Version 0, edited 9 years ago by Hiro (next)

comment:4 Changed 9 years ago by Hiro

  • Cc Hiro added

comment:5 Changed 8 years ago by bro

  • Cc bro added

Add bro to cc

comment:6 Changed 8 years ago by bro

  • Milestone changed from Future to needs verified

I couldn't reproduce this with libtorrent 1.0.7. Is this still a problem or has libtorrents behavior changed?

comment:7 Changed 8 years ago by firewing1

I've observed this behavior on my roommate's machine. I believe it has to do with the default interface being 0.0.0.0. When an interface has been specified in the preferences, the default should be to fallback to 127.0.0.1 instead of 0.0.0.0.

We fixed the issue without modifying deluge source code by altering the startup of deluged to bind to 127.0.0.1 on boot, and later re-bind to the intended interface as it becomes available.

Looking at the source code, I see 0.0.0.0 is the default interface in server.py line 56.

In case it is helpful, qBittorent (also based on libtorrent) experiences the same issue: https://github.com/qbittorrent/qBittorrent/issues/2741.

comment:8 Changed 7 years ago by Cas

  • Component changed from Unknown to Core
  • Type changed from feature-request to bug

comment:9 Changed 7 years ago by Cas

  • Component changed from Core to libtorrent
  • Milestone changed from needs verified to 2.0

comment:10 Changed 6 years ago by Cas

  • Milestone changed from 2.0 to 2.0.0

Milestone renamed

comment:11 Changed 5 years ago by Cas

  • Milestone changed from 2.0.0 to 2.1.x

Ticket retargeted after milestone closed

comment:12 Changed 4 years ago by whereupon

interface names

👍

comment:13 Changed 2 years ago by Cas

  • Milestone changed from 2.1.x to 2.1.0

Milestone renamed

comment:14 Changed 21 months ago by Cas

  • Milestone changed from 2.1.0 to 2.1.1

Ticket retargeted after milestone closed

Note: See TracTickets for help on using tickets.