Jump to content

uTorrent Port-Mapping Error (possible)


pete99

Recommended Posts

I noticed earlier today that the green light had switched to yellow, but it does toggle sometimes so I never gave it much thought. I've been busy with other things, so I just left it transferring a 1.8GB file. When I looked at it this evening, I was being switched from Active to Inactive, with only one seed and a couple of peers - usually not a good sign - but everything else looked okay apart from the yellow light.

When I was active UL speeds were operational at my current limit. I checked the firewall.log and noticed a load of stealth mode connection attempts. So I thought I better check my port status, and scanned it with Network Utility - Open - okay. Next I checked it with http://www.canyouseeme.org and it couldn't. Well I'd manually set the port open in my router before I started the file transfer so I thought it might be a port-mapping error.

I checked in uTorrent>preferences>network and it just showed yellow; no connections. I un-checked/re-checked the automatic port mapping option and it went back to green straight away. I confirmed it with http://www.canyouseeme.org and now it could. I was immediately rewarded by loads of new peers and the firewall.log indicated uTorrent could now make connections to peers again.

I didn't pause the file transfer whilst I did this and everything just carried on as normal as far as I could see. It happened too far back in the day for me to remember anything coincident or to find it in the console log files, but I'll keep an eye on yellow light activity in future.

Mac OS X 10.5.8; uTorrent 0.9.2(beta)

Cheers

==============================================================================================

It happened again overnight so I just re-mapped it as described above. Couldn't find anything in the console logs.

Cheers

==============================================================================================

And again about half an hour later - re-mapped as described above, now okay.

Cheers

==============================================================================================

The tracker was shuffling the pack of peers and this kept happening, so I just kept re-mapping it okay, about 5 or 6 times. Then my router dropped off-line. I re-booted it, re-mapped port, green light, all seems to be running okay again. Over the period of yellow/green port re-mapping, the tracker established 16 new connections, as evidenced in the Console firewall.log. Nothing else I could see in the logs of any significance. Oh, I should add I'd been online file transferring for 48 hours continuously with no other errors that I could see.

Cheers

==============================================================================================

This has been running okay now for the last 3 hours, without needing re-mapping. Checking my router security log I've a number of SYN Flood errors and UDP Flood Stops, at the same time-stamp that I was having this problem. So maybe something going on that my router didn't like.

Cheers

==============================================================================================

Nearly 7 hours running since last router power re-boot and port closed again (went to yellow from green) whilst tracker was shuffling the peers pack. Re-mapped port with autio-map as described above, okay. Checked router security log; empty for time-stamp of incident. uTorrent shows new connections established in firewall.log at same time of incident.

Cheers

Link to comment
Share on other sites

Yo!

I am unsure if I am getting the same problem as you ... but here's something to check.

I am running uTorrent Version 0.9.1.2 (15399) on OSX 10.5.2 and I have noticed that the port number in uTorrent now has to be set one greater than the port number previously set to match the port forwarded setting in the router service.

For example, I was using port 31415 and the router was using 31415 until the problem appeared (quite recently). Since then I have had to set uTorrent to use 31416 to match the router's 31415 and get the green light. Entering the old value 31415 does not work.

In all cases Randomise at launch is set UNchecked.

In all cases Auto map port is set to UNchecked.

Flag this up somebody, there's a little problemette with your counting somewhere ;-D

Cheers,

Lightpourer

Professional developer and software tester (among other things)

.

Link to comment
Share on other sites

Thanks. I think this problem may have been my fault, actually. I kept losing my open port - without the green light changing status to yellow - as tested with http://www.canyouseeme.org/ . I was also still getting UDP Floods in my router and a stack of: mDNSResponder[24]: setsockopt - IP_MULTICAST_IF error 169.254.128.26 -1 errno 49 (Can't assign requested address) in the SYS.log - and console>all messages.

I set the router port to TCP only, and now, apart form my log on/log off, its empty. I had to set a Static IP address to cure the other problems: http://corz.org/comms/hardware/router/static.ip.address.php but that seems to have cured the port closing with no visible indication. I'll see how that goes, but thanks for the tips anyway.

Cheers

===============================================================================================

A bit more on this problem. With the auto-map port option enabled, a green light only provides reliable port open status for your Mac. If you get a SYN error with your router the router can drop the port open status and the green light stays green, even though you cannot be seen from the internet with http://www.canyouseeme.org/ because you're now behind the router firewall again. uT knows its getting synchronisation errors with your router but provides no indication that full port-forwarding to the internet is no longer present. It just gives a green light to show your Mac port is open.

If you get this problem, which can be detected by http://www.canyouseeme.org/ and if not checking your router run log for SYN errors, you need to synchronise the two again by clearing and re-entering the port data in your router virtual server window, then click apply settings. Then check again with http://www.canyouseeme.org/ and if necessary check/uncheck the auto-map port option in uT again. Then check your router log to make sure the SYN errors have cleared. And periodic checks thereafter with http://www.canyouseeme.org/ to make sure its not closed again. If your router is being swamped with UDP errors you may also need to cap your UL speeds with Throttle Pro: http://www.intrarts.com/throttled.html or similar third-party software to regulate router throughput and stop it getting swamped and closing your port.

Cheers

Link to comment
Share on other sites

  • 2 weeks later...

Thanks, I've made a bit more progress on this too. I've found that external readers of port status can give bum results if pages are a little slow to load when you press the 'check' button - ping, without the pong you could say. So you need to ping a couple of times to be sure if Safari is slow to load pages.

The next point on this is that Safari can slow down on page loading, not so much because of ISP traffic and slow line speeds (although my ISP is doing its best to choke P2P uploads), but if you find your router clogging with UDP floods and Smurfs. Most of these can be cleared by loading the latest blis bad IP file into IPfilter.dat http://blocklistpro.com/download-center/ip-filters/ and http://blocklistpro.com/download-center/view-details/p2p-ip-filters/1592-nipfilter.dat.gz.html

and also PeerGuardian http://phoenixlabs.org/pgosx/ for mac.

I find a lot less Smurfs and UPD floods bombarding my router with these two filter programmes installed and running. I don't think all the rubbish was actually closing my port, just making Safari slow to load pages, which gave a ping time-out error and a 'fail' reading when it was not really true. So I think I've been chasing a few red-herrings myself, too. But its working really well now.

Cheers

Link to comment
Share on other sites

Those blocklists are useless. (and PeerGuardian isn't too good to load on OS X; it needs to be loaded into the kernel to work — very bad). Please don't recommend people use them. Especially when it has nothing to do with the topic at had (port mapping).

And Safari not loading means you had too many connections open. Blocking them from being made isn't a valid fix, even if it appears to be. Its, as you said, a red herring.

Link to comment
Share on other sites

Thanks. I have only reported my own experience using this application (uTorrent) and the problems I encountered with my port status. As I explained the UDP floods and Smurfs were denial of service interrupts that affected the operation of my Belkin router, and caused Safari to be slow loading pages giving bad readings by remote port readers such as 'can you see me'.

I loaded the IPfilter.dat block-list first, as the programme author felt it necessary to include this facility and other users here posted that they used them. This did improve the performance I got with uTorrent, but when I added other addresses to the block-list from peers who were issuing smurfs I had to close uTorrent for it to update the filter list on re-launch. This led to me getting the self-reformatting window problem with uTorrent. So I looked for an alternative blocking programme that could be updated without uTorrent falling to bits.

PeerGuardian was recommended by others on the internet so I tried it and it works fine for me. Its shareware and it allows me to manage blocks on specific IPs, and ports, and I'm happy with how it works - thank you. And as I explained the lack of denial-of-service interrupts such as smurfs and UDP floods has meant that uTorrent runs okay, and I'm not fooled into thinking my port has closed again when using external testers that load in Safari. So it directly relates to the problem I was experiencing using uTorrent and had reported here.

I have changed the number of connections to match current line speeds, in line with those recommended in the set-up table that I'd linked to elsewhere. I'd agree this can have a bearing on Safari page-loading speeds if you swamp your router with too many connections, but this is not the problem I reported in this case.

I've cross-checked what Peer Guardian does with XPNetMonitorX and reviewed the console logs and have not seen it do anything other than what I've asked it to. I've seen no kernal calls to PeerGuardian either. I'm not saying you're not right to be cautious, just that I've not seen anything that has caused me concern with any of the other programmes I've found useful and mentioned on here.

Everything you say may well be true, but I've only reported my own experience trying to use uTorrent. Apple recently auto-upgraded my Safari, as I mentioned in another post, and although it has more features it does seem more prone to hang than before. I can say that a number of causes have been eliminated, or so it seems, by the steps I have taken, because its not hanging now. I recently downloaded a 4.8GB file with uTorrent, ipfilter.dat loaded, and PeerGuardian, and had the best performance for a file transfer I've ever had using uTorrent. My router wasn't stuffed with smurfs and UDP floods and the only syn floods occurred when changing UL speed in uTorrent, and these quickly stabilised.

I'm still having problems with my ISP, that I've also posted about elsewhere, but they assure me this is related to installing new packet-switching technology at the exchange and that the technical problems will be overcome shortly. Hopefully then I will be able to test uTorrent at decent line speeds, although even at slow speeds bittorrent protocol seems to produce quite a lot of duplicate message packets and failures to acknowledge leading to retransmits. I suppose these could be network propagation delays, rather than issues with bittorrent protocal itself, which could be a characteristic of too many connections, as you say. Still I'm only set to 60 globally and 35 per-torrent which, doesn't seem excessive.

Cheers

Link to comment
Share on other sites

Thanks, but to perform the program can make kernel calls for resources or i/o, and I've not seen any suspicious kernel calls for other resource or i/o usage. There is always a risk that security may be compromised with any kernel extension programme, but at some point it must attempt to transport data, and I've not seen any evidence that PeerGuardian does anything other than call pploader to auto-update its own block files. But I will keep an eye on it and if it does anything it shouldn't or affects normal operation in any way i'll update this post to that effect. Its not hogging memory or cpu either, but I think you're right to urge caution with any kernel extension programme, as I said earlier.

Cheers

================================================

Oh, one other point. As the bad peer block-lists do work for me, and other users who post here and elsewhere, is there any chance of updating the in built ipfilter.dat accessibility to match that currently available in PC format for mac? For example, I understand single IPs may be entered and the list updated without having to close uTorrent to get it to pick up the new list. The more useful this feature is in uTorrent itself, the less need to use a third-party programme to perform the same function. Thanks again.

Cheers

================================================

I have had a problem with PeerGuardian, which I did say I'd report back on here. It was blocking access to my ISPs VHS core server from its own bad IP p2p list. I ran a Who-Is check on the IP and a trace-route to confirm. So I've had to un-install it for now. Fortunately, when loaded with the blis block-list ipfilter.dat works quite well under uTorrent, it's just updating the list during an active file transfer that I've found problematic, as reported above. Hopefully this is something the uT developers can address.

Cheers

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...