Getting random popups saying it cant bind to IPv4 Address and UDP Port.


[10:22:50 PM]  error listening on udp:10.0.1.1:11002 : Address not available (10049)
[10:22:54 PM]  Listening on udp:10.0.1.1:11002
[10:24:51 PM]  error listening on udp:10.0.1.1:11002 : Address not available (10049)
[10:24:55 PM]  Listening on udp:10.0.1.1:11002
[10:26:53 PM]  error listening on udp:10.0.1.1:11002 : Address not available (10049)
 *** 10/13/2015 ***
[12:18:32 AM]  Listening on udp:10.0.1.1:11002
[12:49:14 AM]  error listening on udp:10.0.1.1:11002 : Address not available (10049)
[12:49:20 AM]  Listening on udp:10.0.1.1:11002

Same config worked with 2.16 and 2.17a2 I believe.

weird

is that 10.0.1.1 address one you entered in your settings?  does this still happen if you leave it blank?

your LAN could be going down momentarily every now and then

the devs should make that bind error window auto-retry after a timeout

Yes 10.0.1.1 is forced in the settings as this system has many IPs.

It also has a IPv6 address forced in the same way, that does not have an issue, so it is unlikely a NIC/Network problem.

Note this is happening in 2.18 as well.

To add, exactly when this pop happens, all UDP transfers (at least via IPv4) stop, TCPs are unaffected.

quirky windows strikes again...

have not seen this prob myself, even when entering my machine's IP in the connection settings, but I'm running Win7

i think the older versions did some automatic retries in the background, so this problem with your machine closing the port might have already existed yet just not been noticeable.

keep in mind, just because the IPv6 port stays up doesn't mean much.  IPv4 traffic is much more frequent so it is plausible that your interface could go down for a second or two and not have any IPv6 traffic trigger the port closure.

regardless, this would be solved by an auto-retry

But if the Interface as a whole was having an issue, TCP would be affected too whether its IPv4 or IPv6, but TCP connection continue through it without a hiccup.

And if it was happening (I don't think so as I watch the client very carefully during submit/seeding operations) there was no evidence with peer connection dropping/resetting nor any messages in the main log.


Also note, other "Servers" on this systems that bind to UDP and even TCP ports are having no issues with any kind of connection resets or anything.

To add even more, the DHT log is also showing the evidence of the IPv4 UDP issues

1:22:06 PM]  IPv6 socket ready
[1:22:33 PM]  IPv4 socket not ready
[1:23:03 PM]  IPv4 socket ready
[1:24:37 PM]  IPv4 socket not ready
[1:30:42 PM]  IPv4 socket ready
[1:31:06 PM]  IPv4 socket ready
[1:31:06 PM]  IPv6 socket ready
[1:31:44 PM]  IPv4 socket not ready
[1:31:47 PM]  IPv4 socket ready
[1:36:45 PM]  IPv4 socket not ready
[1:38:31 PM]  IPv4 socket ready

And in 2.16 the client would run for days with nothing there except the startup info.

By the way, this is fixed in 2.19, thanks.