Opened 8 years ago

Last modified 2 years ago

#1931 new bug

No warning when binding to configured listening port fails

Reported by: OmegaPhil Owned by:
Priority: minor Milestone: 2.x
Component: GTK UI Version: master
Keywords: Cc:

Description

If deluge is configured to bind to a listening port in a fixed range, and the bind attempt fails, a random port is chosen and no user feedback is given (although you can see there is a problem as the 'no incoming connections' warning in the status bar doesn't go away).

This can happen both for a valid (another program is listening on the port) or invalid reason (deluge was restarted and the network stack still considers the previous instance to hold the port??). For the latter, see notes on SO_REUSEADDR in the two following links:

http://www.microhowto.info/howto/listen_on_a_tcp_port_with_connections_in_the_time_wait_state.html http://www.wlug.org.nz/EADDRINUSE

For reference, with version 0.16.0.0 of libtorrent, SO_REUSEADDR can be enabled.

During testing with active torrents I can trigger the latter error trivially with restarting deluge (first discovered during developing a separate change).

Without feedback, the user will trust that the listening port is honoured and assume something else is broken unless they specifically check - I originally thought this meant deluge couldn't detect my real public IP address.

Attachments (1)

listening_port_warning.patch (4.2 KB) - added by OmegaPhil 8 years ago.
GTKUI warning when listening port not honoured

Download all attachments as: .zip

Change History (7)

Changed 8 years ago by OmegaPhil

GTKUI warning when listening port not honoured

comment:1 Changed 8 years ago by OmegaPhil

Patch added to intercept this issue when the client connects to the daemon and when relevant preferences are updated, for the gtkui.

This is the first draft of the patch - the details part of the ErrorDialog? I'm using is not intelligently wrapped by pygtk, so I have had to hack in linefeeds - is there a proper way to do this?

Also please say if there is a better place to put this code.

The warning is a bit verbose (it needs to properly inform the user how to solve the problem though), so probably needs rewording.

comment:2 Changed 8 years ago by andar

Good work.

Unfortunately I don't think I'd accept this patch as-is. There is too much repetition that needs to be re-factored.

I think that we should probably add some sort of ListenOnEvent? that gets sent when the associated libtorrent alert happens. We could have the gtkui watch for this event and do its checks to see if the port is within the desired range. This, however, does not solve the need to check upon start of the gtkui. I suppose this could happen roughly the same way you're doing it directly from gtkui.py but it should probably call out to some shared code to do the check and the popup message so that the code is not duplicated.

comment:3 Changed 8 years ago by OmegaPhil

OK, I think a bit of discussion about the design is then needed before I do some more work on this.

For the shared code, do you think both the checking logic + the dialog should be enclosed in a function in gtkui.py, or these should be separated with the logic in client.py?

I am currently looking into why the listening port binding failure never causes an alert to be logged.

comment:4 Changed 8 years ago by andar

You shouldn't being touching client.py.

I think you might want to create a new object Warnings for the gtkui. It could handle various other warnings too that we may want in the future. Then all you need to do is check on the start() of Warnings and also when the ListenOn? event is received. You could have all your code in Warnings.

comment:5 Changed 8 years ago by OmegaPhil

OK, I was intending that I would implement the shared code so that all interfaces could in theory report on this issue - hence adding a 'listen_port_valid' function to something that sounds like 'shared client code' (client.py), or failing that, core.py.

I plan to get back on this this week.

comment:6 Changed 2 years ago by Cas

  • Milestone changed from 2.0.x to 2.x

Milestone renamed

Note: See TracTickets for help on using tickets.