Display External IP sooner in log

[ciaobaby]

Wireshark will see all the packet data,  because that is it's function, libtorrent does not have any packet inspection functions, it does not need any. it 'talks' to the "Application layer" of the networking system  and the application layer "talks" back.

[AsaRossoff]

Bittorrent needs to know it's external IP to report to trackers who will redistribute to other peers, or to advertise it over DHT or peer exchange,

No it does not, all it needs to 'know' is how to 'talk' to the operating system networking components

I was imprecise, and also talking a bit beyond my expertise.
I shouldn't have said "need"; but reporting of the IP is part of the primary BitTorrent protocol spec, for reporting to trackers, and commonly implemented, even though it is optional (which I think I did indicate).  I also commented that trackers commonly ignore it when it is specified.  I actually don't know a lot about the DHT and peer exchange extensions -- I shouldn't have brought them up.

ciaobaby, I see what you are saying in than libtorrent does not control the return error message. However the return must be coming back from a specific IP address or the packet could not be routed back to libtorrent. How can the return packets carrying the status message be coming from my 192.168.n.n address as you state? I will fire up wireshark when I return home from work to confirm what you are saying.

MrGreg, you're right that incoming IP packets (containing TCP or UDP datagrams) will preserve the internet IP source address on incoming packets.  A NAT (Network Address Translation) router changes the source IP (and often/if needed the source port of the TCP/UDP datagram, using Port Address Translation) of outgoing packets from the internal/private network.  It does not change the destination IP or port for outgoing packets.  The opposite is true for incoming packets.  Incoming packets have their source IP and port number preserved, and only the destination IP and possibly port number are changed (back to what the computer on the internal/private network expects).  Optionally, packets can contain routing information including the IP addresses of routers in addition to the source and destination IP addresses.  If that is missing, then the "default route" router for the current subnet will handle the packet according to its own routing table rules.

Although technically if the router did not preserve the source IP, your computer would still receive the packet, it would probably reject it because it wasn't expecting communication from the gateway router's IP address.

* In short, a NAT router (as home routers generally are), only changes the IPs and possibly port numbers of internal network devices as reported in packet source and destination.  It never changes the IP or port number of external network devices (i.e. internet).

Higher layer protocols that including network routing information within the payload of TCP or UDP datagrams usually have to learn their external IP addresses or ports if they need to communicate that information.  Modern NAT routers handle some types of connections like these in some cases nowadays, such as traditional/active FTP connections (which use two communication channels in a manner that both the uploading and downloading peer have to accept incoming connections, with the one requesting a download specifying the port on its end to send data to, transmitting that information above the TCP networking laying in its own protocol).  Bittorrent is an example of a protocol that can (if perhaps it is not required to) including routing information (e.g. its external IP) in the data payload of packets (at least I know this can apply to tracker communication).

[MrGreg]

ciaobaby and AsaRossoff, Thank you both for your participation in this discussion. I have learned allot from both of you...

[quote="ciaobaby"]
Wireshark will see all the packet data,  because that is it's function, libtorrent does not have any packet inspection functions, it does not need any. it 'talks' to the "Application layer" of the networking system  and the application layer "talks" back.
[/quote]

I did fire up wireshark and it clearly preserves the ip of my proxy as the source ip in the return packets. You say that libtorrent does not have packet inspection functions. I will go along with that. However I do wonder how qB is displaying my correct External IP after a successful connection/authentication is made with the proxy. How is libtorrent retrieving the External IP that qB displays? Is this done by a query to the application layer of the networking system?

AsaRossoff, it seems that ciaobaby does not think that libtorrent has the ability to display the proxy External IP address used in a failed connection/authentication attempt. Do you share the same opinion?

[arvidn]

Is the request that proxy errors should also include the IP address the proxy address was resolved to?

[MrGreg]

Yes Arvid. In failure.jpg, it would be very helpful to have the error contain the actual IP address that was used in the connection attempt. Would it be possible to replace 0.0.0.0 with the resolved IP address? In success.jpg, I can also see no harm in replacing 0.0.0.0 with the resolved IP address even though the external IP is displayed in the next line as soon as DHT peers start processing. BTW I assume that in success.jpg the "access is denied" error is generated because a socks5 proxy address can not accept incoming connections. Is this correct? If so then should the code even be trying to listen on an external proxy address?

I have another thread in this forum regarding using a socks5 proxy. It has been reported in issue 613. Can you please have a look? Thanks for your support...

[ciaobaby]

I assume that in success.jpg the "access is denied" error is generated because a socks5 proxy address can not accept incoming connections. Is this correct?

If a proxy could not accept incoming connections it would be spectacularly useless as a proxy server. what "interface 0.0.0.0" means is a "non-routable address" (Wikipedia on IF 0.0.0.0) which indicates that the request was to a 'unknown address' which obviously is going to fail, "Access denied" is the operating system equivalent of:
"Something fooked up, no idea what, so we'll blame you."

Error messages are rarely accurate, try disconnecting your router from the internet, then try to use Outlook, ... It WILL tell you that "the username or password must be incorrect"

[MrGreg]

ciaobaby, Once again thanks for the education on 0.0.0.0. I seems this can be used in several scenarios according to the wiki page you sent me.

[AsaRossoff]

[quote="MrGreg"]
AsaRossoff, it seems that ciaobaby does not think that libtorrent has the ability to display the proxy External IP address used in a failed connection/authentication attempt. Do you share the same opinion?
[/quote]
I agree.
With a proxy (as with a VPN), there are two layers of networking.
1. Your computer->proxy server (via your router).  The external IP of that connection is your router's IP when NAT is in use (as it typically is at home).
2. Your computer->final internet destination (via your proxy server or VPN).  The external IP of that connection is the external IP of the proxy server or a unique VPN/VPN-network assigned IP (for a VPN).

Some proxy configurations additionally signal what your true originating internet IP is (e.g. external IP of your router) for HTTP and HTTP-like connections.  An "anonymous" proxy shouldn't.  VPNs are pseudonymous (you have a unique IP reported, but only the VPN's servers know who it belongs to).  Some VPNs have been found to have bugs in IPv6 handling that can allow an "attacker" to determine your original IP.  Hopefully they have all fixed those problems.


If the first first layer connection (to your proxy server) does not successfully connect, authenticate, and initiate a connection to the destination server, neither you nor you final internet destination knows the external IP of that proxy server.  It was never used in the connection, because the second layer connection did not complete.

It sounds like all this is outside the scope of your actual request though, which I think Arvid identified: you want to know the proxy server's IP address (not necessarily the same as its external IP) as used in a failed connection attempt.  He's the first line developer who would be involved in bringing that reporting to bear.

[ciaobaby]

With a proxy (as with a VPN), there are two layers of networking.
1. Your computer->proxy server (via your router).  The external IP of that connection is your router's IP when NAT is in use (as it typically is at home).
2. Your computer->final internet destination (via your proxy server or VPN).  The external IP of that connection is the external IP of the proxy server or a unique VPN/VPN-network assigned IP (for a VPN).

Ermm ... ... No.

I seems this can be used in several scenarios

True, but has only one meaning. Run  'route <enter>' in a command window (windows) or a console/terminal (linux/mac) to show the initial destination for packets routed for/to 0.0.0.0

[AsaRossoff]

[quote="ciaobaby"]
Ermm ... ... No.
[/quote]
Feel free to elucidate for MrGreg if you wish.  I don't need to study the topic in this thread myself.  My comments were intended as a hopefully useful conceptual description for MrGreg, not as a complete technical description.  There are other networking layers at work, for example.

[ciaobaby]

Routing with a proxy (simplified)

Computer NiC -> Local Router -> ISP Gateway -> Internet  -> Proxy -> Destination

VPN

Computer NiC (IP provided by VPN) -> Router -> Gateway -> Internet -> -> VPN server -> Internet Destination

But with a VPN the connections between NiC and VPN server (coloured orange) are encrypted and in a 'tunnel' so cannot be intercepted and read.