Follow-up Comment #2, patch #8482 (project mldonkey):
You're right, i don'use the right option here. But the bug remains, the right
option not correctly handled is client_bind_addr
# /usr/local/bin/mlnet -client_bind_addr 46.246.55.11 -client_ip 46.246.55.11
# sudo netstat -nlp | grep mlnet
tcp 0 0 46.246.61.5:6881 0.0.0.0:* LISTEN
20034/mlnet
tcp 0 0 46.246.61.5:6882 0.0.0.0:* LISTEN
20034/mlnet
tcp 0 0 46.246.61.5:16771 0.0.0.0:* LISTEN
20034/mlnet
tcp 0 0 127.0.0.1:4080 0.0.0.0:* LISTEN
20034/mlnet
tcp 0 0 46.246.61.5:3504 0.0.0.0:* LISTEN
20034/mlnet
udp 0 0 46.246.61.5:16775 0.0.0.0:*
20034/mlnet
udp 0 0 0.0.0.0:16911 0.0.0.0:*
20034/mlnet
udp 0 0 46.246.61.5:13112 0.0.0.0:*
20034/mlnet
udp 0 0 46.246.61.5:3504 0.0.0.0:*
20034/mlnet
The DHT port is the only port not correctly binded on the given address.
In my case it results in an unwanted behavior, i uses different routing tables
depending if the process is binded on a VPN ip address or not, and here
packets went outside the vpn.
In attachment you will have the fixed using client_bind_addr instead of
client_ip
(file #31599)
_______________________________________________________
Additional Item Attachment:
File name: 0001-DHT-fix-missing-client_bind_address-on-DHT-port.patch Size:3
KB
_______________________________________________________
Reply to this item at:
<http://savannah.nongnu.org/patch/?8482>
_______________________________________________
Message posté via/par Savannah
http://savannah.nongnu.org/
_______________________________________________
Mldonkey-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/mldonkey-users
