For all of you having problems with P2P programs (E-mule, bittorrent, etc)

Hello.

I have been out of the forum for some time but I would like to tell you what I have found about P2P apps and NOD32 (in the networking part). I like to point before starting that this is not only a problem with NOD32, but there are other applications that can be affected by this.

The main problem here is the way P2P programs like E-Mule or Azureus (or any other bittorrent client like bittornado, shareaza...) work. The users of these programs have noticed that having IMON / AMON running while running these P2P apps can develop conflicts. You can get slowdowns of your system, totally or partially hang in network activity or simply the things can go to the crashing level (application, windows or both).

What I have seen after investigating a lot on the net (different webforums specialized in these kind of apps) is that P2P programs put a lot of stress over a network connection and any program that is monitoring traffic. It is very easy and common for a program that uses the bittorrent protocol or E-mule to make hundreds of connections at the same time with a lots peers. It is common when downloading a popular torrent with a big swamp that your system is connected to around 1000 machines or more at the same time. Here is where the application that is monitoring the traffic starts to have problems. An example of this is if you start a Emule or Azureus and start the download of some popular files (a good movie), after some minutes you can check netstat and you will be surprised with the number of actual connections been made. After some time (it can be some minutes or hours, it depends entirely of the number of concurrent connections been established) it is not uncommon that the P2P program stops to work, or that you completely lose network activity(even if the windows icon shows that the connection is OK) and cannot even surf the web.

One of the ways to solve this problem while the developers find a way to fix this compatibility issues is to make sure you configure your P2P client in a special way, limiting the number of global concurrent connections possible. Not all the programs let you do this, and there is not a magic number for solving every problem out there. A number between 256-512 can work with Azureus for example. Another factor that you have to have in mind is that if you run a software firewall too, there are going to be 2 programs (NOD32 and the firewall) monitoring your network traffic at the same time, so the risk of a conflict is higher.

These are some programs and situations that I have learned that have difficulties with P2P apps, (I like to point that programs like Kazaa don't fall well in this category because the way they work, Kazaa doesn't establish a so high number of concurrent connections like bittorrent or Emule do):

-NOD32
-Zone Alarm (specially version 5)
-Hardware routers/firewalls: These have special problems with P2P so if you have one of these and are having problems (the router hangs) here is your possible answer.

I like to finish saying this: I love NOD32 and I don't blame the developers, this phenomenon was maybe not contemplated by them and this kind of stress in the network connection is maybe not common for everybody, but I would like to see a solution (turning off AMON(IMON is not in my solution list). P2P programs like Emule and bittorrent driven ones are becoming more popular everyday, so it is smart to look into this issue. Zonelabs is having a nightmare due to the same problem and they have a lot of unhappy customers for this reason. There is just to go to their forums and type "bittorrent" in the search field to find that the ZL stuff has not given the amount of attention that the problem deserves.

 

I don't have any troubles with eMule and NOD .11b (just only testing eMule, not big using)...

 

P2P has come a long way and many reputable sites like http://filerush.com/ and http://www.3dgamers.com/ use it to distribute huge game demos, movies and mods. http://www.gamespot.com/ use their own P2P client and Valve have hired the Bittorent creator to investigate how P2P might help their distribution system. It helps them keep their costs down and stops users having to queue or pay for services like Fileplanet.

In the case of bittorent if you download the torrent from a reputable site you can be sure of what you're getting as the system has built in checks.

I'm just saying P2P like most things has the potential to be illegal if you use it to do illegal things, but it also has the potential to be legal and useful, so efforts should be made to accommodate it with NOD32. Having said that I haven't had any conflicts so far

 

That's all right, and more: cut your internet connection! )
If 80% of download on p2p networks was bad files, people would not use p2p any more I think.

But the question is not about you like or not p2p but about to know if nod32 support it.

 

I respect your point of view but don't agree with it. This post was not about if we like or don't like P2P networks, this post was about possible problems of P2P applications and NOD32. Technology can be used in a good way or in an evil way, this has been demostrated always during history. P2P networks like bittorrent are a great contribution to the bandwidth problems that were killing web providers as explained very well by sard. I am happy to hear that there are NOD32 users that are not having problems with bittorrent or E-mule. I am going to try the last release and will post with my findings.

 

This discussion will continue in this Forum with the understanding that it remains....about possible problems of P2P applications and NOD32.

Also as is customary in some of my posts....I will offer the below link....just as a courtesy and it is NOT to be construed as anything more than a reminder to no one in particular.

This link---> Wilders Security Forums - Terms Of Service

 

Actually, Windows XP, being based on the NT platform, can handle tens of thousands of concurrent connections in a barebones config. Many independent stress tests have been done to confirm this. One thing that does seem to cause instability on NT is the number of connections spawned per second; limiting this in your P2P program can really help. In any case, lot's of people use P2P, there's no excuse for NOD32 not functioning properly when the computer it's on makes a lot of internet connections and transfers a lot of data.

Exactly, it shouldn't. But when slowly writing large CD/DVD ROM files to the hard drive, memory consumption can balloon. NOD32 isn't so bad about this, but McAfee 7 would often be using over 500MB of memory because of this. Not only will the P2P program have problems, your whole system can become unstable!

I disabled IMON because it was causing problems, not sure exactly what was the cause, but it goes to show that not just the new beta internet monitoring is problematic.

Basically, one small concurrency or memory error, compounded over tens of thousands of connections, millions of packets, etc. and you wind up with a very instable system. The fact that you won't notice the error unless you leave your system up for many days and run some form of a server is no excuse for the behavior. Let's hope Eset does some heavy testing of their new internet monitor with some P2P programs before it goes final!

 

I've read on other forums that XP Service Pack 2 has a new feature that limits the number of connections per second, this might be causing some of the problems people are attributing to NOD32. I'm still using Windows 2000 so haven't looked into it much.

http://www.warp2search.net/modules..../modules.php?name=News&file=article&sid=19021
http://www.warp2search.net/modules.php?name=News&file=article&sid=19049

 

I have also been seeing various bittorrent clients: ABC, Azureus and BT++ seize ~99% of system resources, since replacing NAV 2004 with Nod32. Not immediately ,but consistently within 5-10 minutes of starting a torrent client.

This was before installing SP2 for win XP. Now, after installing SP2, the situation has not improved, even though sp2 reportedly limits the number of connections per port very severely. (and registry patches are available all over the place to change this back again...)

I understand there is as yet no solution to this NOD32 issue?

Kind regards, CuriousXP

 

Couple fixes...

http://support.microsoft.com/default.aspx?kbid=314053

http://www.lvllord.de/

 

Thanks tazdevl,


those fixes for SP2 are great, BUT unless I am very mistaken they don't solve the problem discussed here, as you can see from my post.




CuriousXP

 

I just installed the latest NOD32 (XP) and noticed the same thing, my ABC client hanging after X amount of time. NOD32 is doing it, since it wasn't happening with NAV. I'm not even using HTTP scanning.

Surely there's a workaround by now?

 

yes there is a workaround, i had teh exact same problem before, and it's IMON thats causing it.

goto IMON->Setup->Miscellaneous, then under "Exclusion" press "Edit" button and add the location of abc.exe to the list.

 

OK, I just did that and will see how it goes. But doesn't that exclusion area pertain to those using IMON's HTTP checking? I'm only using the POP3 component of IMON, so how would network traffic not on port 110, let alone abc.exe, become involved?

 

Ok, leaving aside the legality and security risk issues posed by the vast majority of P2P clients and the use they are put to... I have a serious problem with the ones that are designed around the concept of opening up hundreds of concurrent sessions. I don't care what their authors and designers say, that is just poor and wasteful engineering design and, in my eyes at least, an abuse of the network protocols.

In regards to SP2, I believe there is a slight misunderstanding that is floating around out there. As I understand it, WinXP always had the potential to use the "TcpNumConnections" registry parameter and that is easily changed. That's not what's new in SP2. What I'm told is new is that SP2 has put in hard-coded limits on how many concurrent initiated-but-unacknowledged or what might be called half-open connections are made. I believe that this was put in to limit various mischevious behavior like certain types of SYN flooding. It is proving problematic to P2P clients, as well, because many of the P2P endpoints are transient and therefore these high session count P2P clients often end up trying to communicate with lots of other P2P endpoints that aren't there any longer, along with the ones that are still there.

NOD32 should work ok, I would think, if you turn off IMON. Otherwise, you will probably blow through a lot of system resources having IMON work through all of those concurrent sessions. As you say, Zone Alarm should have it even worse. High concurrent session count are always problematic for pretty much any firewall (software or hardware), since modern stateful packet filtering firewalls have to maintain a state-table which contains info on every active session; and then when new packets come in they have to scan the same, now enormous, session-table for any pre-existing sessions which would allow the packet through as part of an already existing and approved conversation.

 

All I can say is :Amen.

 

Perhaps I'm misunderstanding something about IMON then: I have HTTP checking deselected and POP3 selected. Therefore, I would expect IMON to only be looking at port 110. Is this correct? If not, why not? This would have repercussions beyond just Bittorrent, since if it's looking at and processing everything, then I'd have to start thinking about all my other Winsock apps too and what problems they might be experiencing and if they should be excluded or not.

 

Amen? An alternative viewpoint would be that this is ridiculous. Lots of things have been "suggested," but that doesn't make them true. And to be lumping in "ALL" P2P programs together, as if they're all in the same boat, is also ridiculous. Even the network that Kazaa uses, which is where this reputation of files not being what they seem to be comes from (not torrent), doesn't approach 80%. On the torrent network, I've never seen either issue at all, and there are relatively few non-media files on torrent networks anyway, and infection is impossible for media files.

 

well i think unchecking HTTP scanning only stop it from scanning traffic coming from http ports ie. 80, 8080 etc..... but it still scan other ports other than http? But i'm pretty sure adding the abc.exe to the exclusion list will resolve ur problem....whether http scanning is enabled or not....

 

I have no problems with Emule and NOd32 nor ANY other AV, firewall, ect. - I just thought I would throw in a useless "WFM" for the heck of it. - because I have other bad issues with windows that are posted in this board - with no solutions yet.

 

Well, I think you are partly correct in the case of NOD32, my earlier comments were sort of directed more at ZA and hardware firewalls. You have to remember that when a packet comes in, IMON still has to process it long enough to detect that it is or is not: an IP packet, that it is IP protocol 6 for TCP, and that its source port is TCP port 110 for the POP3 protocol. So there is some decode that has to take place on every packet, even before the actual AV scanning of the data portion. Of course that processing should be pretty minimal and shouldn't really change whether you are talking hundreds of sessions of low bandwidth or one session of high bandwidth.

However, in the case of a firewall, things are somewhat different. NOD32's IMON doesn't really care too much where or how a connection occurred, it's just worrying about whether the packet is part of an email POP3 connection or not. However, a firewall has to precisely worry about where packet is coming from. For example, most firewalls will by default block all incoming packets. How then does the firewall know to let an HTTP response packet back in from a web server? Well, first your PC had to create an outbound TCP session to the web server's IP for the initial HTTP request. The firewall likely permitted this because by default it permits most outbound traffic. But the firewall doesn't stop there at allowing the outbound packet through; rather it also records that specific TCP session information (source IP, dest IP, protocol, source port, dest port, etc.) in a session table somewhere. Then when a packet comes in, it can compare the incoming packet's properties to what's already in the session table. If there is a match, it basically knows that the packet is part of an authorized conversation and lets it back through. If there is no match, then it has to process the firewall rules to see if there is any other reason to let it through.

Generally, these session tables aren't overly burdensome. But just think about corporate hardware firewalls where you may have 2000 end-users sitting behind them. In general, most PC users only generate a handful of sessions in normal use... so maybe that corporate firewall only has to keep track of, on average, say about 10000 concurrent sessions. But, if a decent sized number of these users start using P2P in an unrestricted setting and/or if they get compromised with a trojan or virus that generates SYN flooding or mass worm traffic or something... then you could easily have session counts sky-rocket into the hundreds of thousands. Even some of the biggest of enterprise or service provider hardware firewalls will start to crater once you start going much further beyond, say, 500,000 or 700,000 concurrent sessions. It takes tons of memory to keep track of those sessions and, moreover, basically every incoming packet forces a session table scan... and this all has to be done basically at wire speed so that end-users won't encounter latency issues.

 

Same here, no problems at all with NOD and P2P programs.
and as for security, an uptodate NOD will do the trick, i think it is safe enough if you know what you are doing and what you are d/l.

sure i always see suspect files on P2P, so i don't d/l them.

 

Im running:

Nod32
ZAP 5.5 beta

I use Kazaa lite and WinMX P2P programs with absolutely no problems.
In fact Nod32 has protected me from hundreds of viruses while using kazaa lite.

Torrent software has always had conflicts with other apps.