eliot_cougar Posted February 2, 2010 Report Share Posted February 2, 2010 Hi all!..We are lucky to have p2p-friendy ISP... Recently I cooperated with one of our admins, and we made local retracker... Now it works only for some torrents which have retracker.local/announce in them... We were trying to make isp.bep22 option to work, but it seems that uTorrent (at least 2.0 RC5) fails to find local retracker using reverse DNS lookups and SRV record... Hovewer, if I do all DNS requests manually, as it is described in BEP22 specs, it seems to work... Moreover, uTorrent does not seem to treat peers obtained from retracker.local/announce as Local...What I request at the moment is handy indicator or logging option in 2.0 RC6+ to troubleshoot whether uTorrent fails to find local retracker or not...PS: there was a lot of topics concerning local peer prioritization... I completely agree with them... Even if uTorrent have local retracker with 1-5 very fast seeds, if it also have 10+ trackers with thousands of peers, it often does not use local peers advantage and clugs the link with non-local traffic at slow speed... Link to comment Share on other sites More sharing options...
Firon Posted February 2, 2010 Report Share Posted February 2, 2010 This is not going to be touched for 2.0. 2.0 has already gone gold. In a future release, it will get fixed though. Link to comment Share on other sites More sharing options...
eliot_cougar Posted February 20, 2010 Author Report Share Posted February 20, 2010 I'd like to up this thread... I see that you've done some fixes in BEP22, but it doesn't seem to work here... Indicator or log option is still needed... Link to comment Share on other sites More sharing options...
GTHK Posted February 21, 2010 Report Share Posted February 21, 2010 > 217.26.__._Name: myhostname.itaec.ruAddress: 217.26.__._> _bittorrent-tracker._tcp.itaec.ru_bittorrent-tracker._tcp.itaec.ru SRV service location: priority = 5 weight = 0 port = 80 svr hostname = retracker.local> retracker.localretracker.local internet address = 217.26.__._Your first query is wrong. It looks like you did an "A" type lookup and used a bare IP address instead of doing a proper rDNS using PTR. A proper set of queries would be done like this, using 69.107.0.14 as in the specs:Default Server: google-public-dns-a.google.comAddress: 8.8.8.8> set type=PTR> 14.0.107.69.in-addr.arpaServer: google-public-dns-a.google.comAddress: 8.8.8.8Non-authoritative answer:14.0.107.69.in-addr.arpa name = adsl-69-107-0-14.dsl.pltn13.pacbell.net> set type=SRV> _bittorrent-tracker._tcp.adsl-69-107-0-14.dsl.pltn13.pacbell.netServer: google-public-dns-a.google.comAddress: 8.8.8.8*** google-public-dns-a.google.com can't find _bittorrent-tracker._tcp.adsl-69-107-0-14.dsl.pltn13.pacbell.net: Non-existent domain> _bittorrent-tracker._tcp.dsl.pltn13.pacbell.netServer: google-public-dns-a.google.comAddress: 8.8.8.8*** google-public-dns-a.google.com can't find _bittorrent-tracker._tcp.dsl.pltn13.pacbell.net: Non-existent domain> _bittorrent-tracker._tcp.pltn13.pacbell.netServer: google-public-dns-a.google.comAddress: 8.8.8.8*** google-public-dns-a.google.com can't find _bittorrent-tracker._tcp.pltn13.pacbell.net: Non-existent domain> _bittorrent-tracker._tcp.pacbell.netServer: google-public-dns-a.google.comAddress: 8.8.8.8*** google-public-dns-a.google.com can't find _bittorrent-tracker._tcp.pacbell.net: Non-existent domain> _bittorrent-tracker._tcp.netServer: google-public-dns-a.google.comAddress: 8.8.8.8*** google-public-dns-a.google.com can't find _bittorrent-tracker._tcp.net: Non-existent domainIf you Wireshark uT you can see it performs queries in this manner, as in the spec: http://bittorrent.org/beps/bep_0022.htmlUse Wireshark as logging to see if uTorrent succeeds in getting a response, and also perform your test query in this manner. Link to comment Share on other sites More sharing options...
eliot_cougar Posted February 21, 2010 Author Report Share Posted February 21, 2010 no prob, that works too:> _.__.26.217.in-addr.arpa_.__.26.217.in-addr.arpa name = myhostname.itaec.ruI'll try Wireshark later...UPD:Wireshark tells me that uTorrent makes THIS Query!!! (Eliotbook is simply my NETBIOS name, don't know why it was used to do SRV query)And there were no PTR query...Standard query SRV _bittorrent-tracker._tcp.Eliotbook Link to comment Share on other sites More sharing options...
GTHK Posted February 21, 2010 Report Share Posted February 21, 2010 The PTR might be cached and unneeded by the time you try to run your test, I had to ipconfig /flushdns to see it. More importantly thought the SRV queries should be performed iteratively..Shutdown µTorrent, start port 53 capture, flushdns, start µTorrent. If you could post the capture this time as well it'd be helpful to us and the devs if a problem does exist. If you don't want to make the cap public you could use forum mail. Link to comment Share on other sites More sharing options...
eliot_cougar Posted February 21, 2010 Author Report Share Posted February 21, 2010 I flushed DNS Cache, it doesn't change anything... uTorrent still trying to get SRV record for my NETBIOS name...uTorrent does no PTR requests for my _.__.26.217.in-addr.arpa...There should be only one iterative SRV query in my case...I send you .pcap of what's going on on DNS channel...I flushed DNS Cache and started uTorrent with only one torrent active without trackers... Link to comment Share on other sites More sharing options...
GTHK Posted February 21, 2010 Report Share Posted February 21, 2010 Bleh. Alright I think a dev will have to take a look at this issue. It's just doing the one query using your NetBIOS name and nothing else? Link to comment Share on other sites More sharing options...
eliot_cougar Posted February 21, 2010 Author Report Share Posted February 21, 2010 It checks for updates, then connects to DHT, then doing that only stupid DNS request that fails... And nothing else... Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.