Is there any way to listen at 0.0.0.0 and [::]

[SeaHOH]

qBittorrent version and Operating System

qBittorrten v4.2.5 64-bit Windows 7 SP1 64-bit

If on linux, libtorrent-rasterbar and Qt version

(type here)

What is the problem

I tried every "Network interface" and "Optional IP Address to bind to" pairs in "Advanced" page, listen port only bind to the configuration, loopback and link-local IPs.

What is the expected behavior

I hope that setting "Any interface" and "All address" will bind listen port to 0.0.0.0 and [::], not 127.0.0.1, [::1] and others.

Steps to reproduce

(type here)

Extra info(if any)

If more informations is needed, please tell me.

[SeaHOH]

I said "socket", you said "stacks", they are not same things. Stacks accept, but sockets are not necessarily accept.

[arvidn]

sockets are parts of stacks, if the whole stack discards a packet, it implies it will not make it to the socket. But this distinction doesn't seem important anyway.

[SeaHOH]

Stacks accept, but sockets are not necessarily accept.

[arvidn]

@SeaHOH is it normal or common for sockets bound to 0.0.0.0 to accept packets whose destination IP does not match one of the IPs configured for the host?

[SeaHOH]

Not "destination IP", it is "original destination IP". NAT rewrite destination IP for every incoming packets, they are always match host's IP configuration, but the original IP does not match. So, this is normal and common, for home users (with NAT) that is almost all packets.

[arvidn]

Not "destination IP", it is "original destination IP"

What about it?

NAT rewrite destination IP for every incoming packets, they are always match host's IP configuration, but the original IP does not match. So, this is normal and common, for home users (with NAT) that is almost all packets.

It seems we are in agreement then.

Why would it make a difference to bind the socket to 0.0.0.0. As far as I can tell, we just established that it won't accept any more packets than binding it to the specific IP configured for the host.

[SeaHOH]

I said that I does not use UPnP or NAT-PMP at all, of course use them will be work, but I use DMZ.

What about it?

The rewrote incoming original destination IP, your wording is inaccurate.

[SeaHOH]

I think you can make a test that in without UPnP and NAT-PMP, no packet will be accepted.

[chauhansarthakiitd]

Actually there's a Raspberry Pi DNS server that routes to this IP (it can be changed, but that's another app settings so pointing it out is unfair) we should be able to port to it. For consistency’s sake

[xxxsen]

I also encountered problems related to binding addresses. In my current network, ipv6 is dynamic and will be reassigned every once in a while. Although I have set the configuration to any interface and any addresses, qbittorrent It will not be bind to [::], which will cause the inability to receive external requests when ipv6 is refreshed.

[OpenGG]

@SeaHOH can you be more specific about how the behaviour does not conform to BEP 45?

There is no way to make libtorrent bind to INADDR_ANY.

I don't quite understand your scenario, why can't you bind to a specific interface or IP? Does the IP change over time and you would need to re-bind?

To accommodate my ISP's timely rotation of IPv6 prefixes, I am required to access the advanced options in qbittorrent and click on the save button every few days. This triggers the enumerate mechanics necessary to determine the current IPv6 address that needs to be bound.

The introduction of automatically detecting address changes and rebinding, or the ability to bind to INADDR_ANY, would be immensely helpful.

[arvidn]

The introduction of automatically detecting address changes and rebinding

I would expect this to happen if you bind to an interface rather than an IP address. Have you tried that? On windows interface names are GUIDs, so it might be a bit combersome

[xxxsen]

The introduction of automatically detecting address changes and rebinding

I would expect this to happen if you bind to an interface rather than an IP address. Have you tried that? On windows interface names are GUIDs, so it might be a bit combersome

it seems not work as expect, i bind an interface rather than an ip, after ip changed, qb don't rebind to new addr.

current binding(an old ipv6):

my ipv6 addr at this time:

[SeaHOH]

On windows interface names are GUIDs, so it might be a bit combersome

There also have human readable named interfaces on Windows. There is another client who support bind to both interfaces and INADDR_ANY. I use INADDR_ANY with IPv4 and interface with IPv6, so fine so free.

[OpenGG]

The introduction of automatically detecting address changes and rebinding

I would expect this to happen if you bind to an interface rather than an IP address. Have you tried that? On windows interface names are GUIDs, so it might be a bit combersome

@arvidn

Tried it and still, the process bind to enumerated IP addresses, instead of INADDR_ANY.

See netstat -an|grep -i listen

And when IP changes (DHCP renew or IPv6 RA event), it won't detect new addresses and bind.

@SeaHOH

What client are you using? I can't seem to find the input boxes where INADDR_ANY could be filled.

[SeaHOH]

@OpenGG A closed source software, most people here may not like it.