Avast WEBforum
Consumer Products => Avast Free Antivirus / Premium Security (legacy Pro Antivirus, Internet Security, Premier) => Topic started by: billman1037 on February 05, 2009, 09:10:52 PM
-
I noticed on my port explorer, after I close my firefox browser. ashwebsv.exe will stay connected until I actually go into webshield, terminate it and then restart it again.
I tested this a few times. Went to some websites, closed firefox and let it sit for over 24hrs. and ashwebsv.exe stayed connected to the sites the entire time. Any ideas on what is going on??
-
Does your port explorer go to the lengths to say exactly what this connection is as the web shield is always listening on its localhost port 12080 and not actually connected externally.
See image, example of my firewall used ports and you can see the web shield and the internet mail, note they are listening on the localhost:loopback not physically connected. I am obviously on-line but there still isn't a connection as my activity is static whilst posting this.
-
Do you have any URLs we can test this on? Does that happen regularly or just from time to time ?
-
It's not loopback 127.0.0.1 It has the actual ip address and say established. I just did it with Ebay. I will do again and see if can post a pic of the activity.
-
I can replicate this to some extent but I should say that I am currently using the avast beta release.
Normal case:
I open Firefox and go to the ebay site. Using Current Ports I see the connections to ebay from ashWebSv.exe.
I close Firefox - Current Ports shows the connections instantly come down and go to Close Wait state.
Partial replication:
I open Firefox and view the avast site.
I open another instance of Firefox and in that instance of Firefox I go to the ebay site. Using Current Ports I see the connections to ebay from ashWebSv.exe.
I close the instance of Firefox that is viewing the ebay site (the other instance of Firefox viewing the avast site is still open). In this case the ashWebSv.exe connections to the ebay site are maintained in Established status for a number of minutes (5-10) before they close. If, during the period, I terminate the instance of Firefox browsing the avast site then all the connections (including the lingering ebay ones) instantly close.
-
billman1037,
do you use the Firefox Preloader on your system?
The same problem can also be seen if the Firefox Preloader is used. In this case when the user terminates a Firefox session the Firefox process remains loaded. So in this case:
I open Firefox and go to the ebay site. Using Current Ports I see the connections to ebay from ashWebSv.exe.
I close Firefox but the ashWebSv.exe connections to the ebay site are maintained in Established status for a number of minutes (5-10) before they close.
Later edit: I just repeated the test and timed the delay in connection termination in my system - it is 4 minutes.
-
Nope...I don't use firefox preloader.
-
Ok no pic..but here is one that has been active for over an hour after shutting down firefox:
209.62.180.191 - which I looked up on coolwhois and shows it to be double click, inc.
-
Ok...same deal....209.62.180.191 still connected.
-
Well no it isn't ... here is the file you just posted and then withdrew from your post ...
--------------------------------------------------------------------------------------------------------------------------------------------------
| NAME | CREATION | PID | PROTOCOL | LOCAL ADDRESS | LOCAL PORT | REMOTE ADDRESS | REMOTE PORT | PORT STATUS | SENT | RECVD |
--------------------------------------------------------------------------------------------------------------------------------------------------
| SYSTEM | --- | 4 | TCP | 0.0.0.0 | 445 | 0.0.0.0 | 0 | LISTENING | --- | --- |
| SYSTEM | --- | 4 | TCP | 192.168.1.7 | 139 | 0.0.0.0 | 0 | LISTENING | --- | --- |
| SYSTEM | --- | 4 | UDP | 192.168.1.7 | 137 | *.*.*.* | * | LISTENING | --- | --- |
| SYSTEM | --- | 4 | UDP | 0.0.0.0 | 445 | *.*.*.* | * | LISTENING | --- | --- |
| SYSTEM | --- | 4 | UDP | 192.168.1.7 | 138 | *.*.*.* | * | LISTENING | --- | --- |
| alg.exe | 12:25 05/02/2009 | 240 | TCP | 127.0.0.1 | 1025 | 0.0.0.0 | 0 | LISTENING | 0/0 | 0/0 |
| lsass.exe | 12:25 05/02/2009 | 728 | UDP | 0.0.0.0 | 500 | *.*.*.* | * | LISTENING | 0/0 | 0/0 |
| lsass.exe | 12:25 05/02/2009 | 728 | UDP | 0.0.0.0 | 4500 | *.*.*.* | * | LISTENING | 0/0 | 0/0 |
| svchost.exe | 12:25 05/02/2009 | 992 | UDP | 192.168.1.7 | 123 | *.*.*.* | * | LISTENING | 0/0 | 0/0 |
| svchost.exe | 12:25 05/02/2009 | 992 | UDP | 127.0.0.1 | 123 | *.*.*.* | * | LISTENING | 0/0 | 0/0 |
| svchost.exe | 13:39 05/02/2009 | 1040 | UDP | 0.0.0.0 | 49659 | 4.2.2.2 | 53 | LISTENING | 1/40 | 1/70 |
| svchost.exe | 15:24 05/02/2009 | 1040 | UDP | 0.0.0.0 | 51426 | 4.2.2.2 | 53 | LISTENING | 1/36 | 1/76 |
| svchost.exe | 15:51 05/02/2009 | 1040 | UDP | 0.0.0.0 | 57518 | 4.2.2.2 | 53 | LISTENING | 1/33 | 1/80 |
| vsmon.exe | 12:25 05/02/2009 | 1684 | Other | 0.0.0.0 | 0 | 192.168.1.1 | 0 | LISTENING | 1/40 | 0/0 |
| ashwebsv.exe | 16:35 05/02/2009 | 3364 | TCP | 127.0.0.1 | 12080 | 0.0.0.0 | 0 | LISTENING | 0/0 | 0/0 |
| ashwebsv.exe | 17:01 05/02/2009 | 3364 | TCP | 192.168.1.7 | 3681 | 8.14.104.66 | 80 | TIME_WAIT | 1/506 | 1/1 |
| ashwebsv.exe | 17:01 05/02/2009 | 3364 | TCP | 127.0.0.1 | 12080 | 127.0.0.1 | 3745 | TIME_WAIT | 2/1109 | 1/1 |
| ashwebsv.exe | 17:02 05/02/2009 | 3364 | TCP | 192.168.1.7 | 3998 | 8.14.104.67 | 80 | TIME_WAIT | 2/957 | 2/1161 |
| ashwebsv.exe | 17:04 05/02/2009 | 3364 | TCP | 127.0.0.1 | 12080 | 127.0.0.1 | 4143 | TIME_WAIT | 2/374 | 1/1 |
| ashwebsv.exe | 17:05 05/02/2009 | 3364 | TCP | 192.168.1.7 | 4252 | 74.125.242.25 | 80 | CLOSE_WAIT | 1/573 | 1/417 |
| ashwebsv.exe | 17:05 05/02/2009 | 3364 | TCP | 192.168.1.7 | 4255 | 76.13.218.11 | 80 | CLOSE_WAIT | 1/507 | 1/717 |
| ashwebsv.exe | 17:21 05/02/2009 | 3364 | TCP | 127.0.0.1 | 12080 | 127.0.0.1 | 1384 | LISTENING | 5/1385 | 2/2 |
| ashwebsv.exe | 17:22 05/02/2009 | 3364 | TCP | 192.168.1.7 | 1535 | 209.62.180.191 | 80 | LISTENING | 1/505 | 1/737 |
| ashwebsv.exe | 17:22 05/02/2009 | 3364 | TCP | 127.0.0.1 | 12080 | 127.0.0.1 | 1624 | ESTABLISHED | 3/19900 | 3/3 |
--------------------------------------------------------------------------------------------------------------------------------------------------
If the connection was being maintained then the port status would be ESTABLISHED - it clearly is not. I am not sure what PORT EXPLORER is reporting here with a LISTENING status.
-
thanks...I was trying to post my log like you did and screwed it up...that's why it was removed.
Listening is maintaining the connection...if you look at the packet information being transfered, you can see this.
-
Listening - all TCP sockets that have a status of LISTENING, showing all listening ports.
Established - all TCP sockets that have a status of ESTABLISHED, showing all current connections.
So, the port is open and not closed. Normal behavior would be like my firefox connections. When I close firefox, the connections are closed and you don't see anything in port explorer. So, still the same problem remains that ashwebsv.exe is not closing.
-
Agreed there is an issue.
The avast team has just issued a new release of the program - as you can see from a few posts down. I am using that new release. I rather suspect that someone will suggest that you establish that the problem continues for you with the new release (even though I rather doubt it will change the condition you are seeing).
You will note from the table you posted that a number of the connections that had been made by avast are in the proper closing status.
Is there any consistency about the connections that do not close properly (like for doubleclick or for ebay)?
For now I cannot replicate the "LISTENING" issue.
-
I have had this problem with other sites but I didn't note the particular ip's. The doubleclick was within Ebay. I will have to keep note of more instances.
I just updated to the new release. So, we will see. I'll post back with more info.
-
If you are using firefox I would suggest that you use adblock plus and NoScript as that kills the likes of doubleclick.net stone dead.
-
I'm a bit confused - is this all about the connections in the TIME_WAIT and CLOSE_WAIT states?
In any case, I'd recommend the OP to update to the latest avast program version (4.8.1335) and post a new capture from port explorer.
Thanks
Vlk
-
I'm a bit confused - is this all about the connections in the TIME_WAIT and CLOSE_WAIT states?
In any case, I'd recommend the OP to update to the latest avast program version (4.8.1335) and post a new capture from port explorer.
Thanks
Vlk
I updated to avast program version (4.8.1335)...and no go
It's random IP addresses that are listening through ashwebsv.exe...I really don't think it has anything to do with one particular IP because as I remember from the past several days it has been various ones. I could be here forever trying to list each one cause it's different everytime.
Thats part of the problem TIME_WAIT and CLOSE_WAIT states because they never close. The main problem is having open ports as you can see port 80 through ashwebsv.exe.
As stated before, normal behavior on all programs is once they are closed the connections are closed.
Here is another capture:
-
also, that screen capture was an hour after I had already closed firefox.
-
billman1037,
in the address bar of Firefox can you please enter:
about:config
and then tell us the value of your Firefox setting network.http.keep-alive.timeout?
-
Firefox setting network.http.keep-alive.timeout is the default setting as with my other pc. I have not touched that.
I spoke wrong earlier that it's not a particular ip...cause i think that could be the problem. Though it's probably many ip's (ones that avast considers harmful).
I went to Facebook, closed firefox , and everything closed in ashwebsv.exe except one instance of 127.0.0.1 which is normal cause I have it running.
Now, as far as Ebay and certain other sites (I don't remember the ones from the past several days). I'm thinking for some reason ashwebsv.exe gets stuck on a particular ip for example the 2 shown earlier:
209.62.180.191 (Double Click) and 66.235.132.145 (stat.esomniture.com)
....and when I close out firefox, ashwebsv.exe will sit on the IP it considers trouble and won't close. Unless I terminate the webshield and start it again.
-
Ah,
now I think that we may really be getting somewhere ...
Is Facebook something that you tend to keep open all the time?
-
Vlk
I'm a bit confused - is this all about the connections in the TIME_WAIT and CLOSE_WAIT states?
Yes, you are confused and no it has nothing whatsoever to do with those states.
I hope that I may be right in saying as Agatha Christie's great creation, Hercule Poirot, might ... "the little grey cells ... they work ... and they tell me the answer".
But we shall all have to be gathered in the cabin or the drawing room for the revelation (or to put it another way ... give me time to marshall my thoughts and put it in a way that might make some sense).
-
The problem is not my web browser. Once that is closed it is closed. It is ashwebsv.exe that continues to stay open even after firefox closes. If you look at my logs, you can see that there is no instance of firefox because it was closed.
However, you can see ashwebsv.exe in the logs because it continues to remain open to the previous IP's that I was previously viewing with firefox.
ashwebsv.exe will continue to remain open until I terminate it by terminating the web shield and restarting it again. I left ashwebsv.exe alone for over 24hours after I had closed firefox (as per my intial post) and it never closed itself.
-
billman1037 ,
thanks for your speculation ... but you, noticeably, failed to answer my question ... please answer it.
I went to Facebook, closed firefox , and everything closed in ashwebsv.exe except one instance of 127.0.0.1 which is normal cause I have it running.
As I asked you before ...
Is Facebook something that you tend to keep open all the time?
-
billman1037 ,
thanks for your speculation ... but you, noticeably, failed to answer my question ... please answer it.
I went to Facebook, closed firefox , and everything closed in ashwebsv.exe except one instance of 127.0.0.1 which is normal cause I have it running.
As I asked you before ...
Is Facebook something that you tend to keep open all the time?
NO....Sorry, I thought that was obvious from my previous explanation. Since I said that firefox was closed.
-
I went to Facebook, closed firefox , and everything closed in ashwebsv.exe except one instance of 127.0.0.1 which is normal cause I have it running
.
Can you explain this post then please?
-
Ok...I am not sure where you are going with this.
I was naming an example of an instance where ashwebsv.exe did work properly. That is when I used firefox to go to the site facebook.com. Then I closed firefox and ashwebsv.exe closed properly. The way it should.
Now as far as everthing I have described before..that would be my problem.
-
Let's be clear please ...
you have told us that there are ashWebSv.exe connections that have been maintained for many hours (to quote you more than 24 hours) ... so one has to presume it is not hard to reproduce these conditions and then, after a visit to Facebook, all these long lived connections disappeared?
If I have mis-quoted you please accept my apology and correct the mis-interpretation I have.
I am trying my best to understand this problem and, if in my power, to reproduce it and support you ... so I seek your help.
-
I think I have made myself very clear in the previous posts.
but I will try again. There are some instances where ashwebsv.exe does work correctly and others where it does not.
Now, if I go to ebay and click around in the site yes the problem will be replicated. However, some sites do work correctly as per my example with facebook.com.
You should be able to see the problem in the logs that were posted.
-
do you have diamondcs port explorer? or some sort of port scanner?
-
I have downloaded and installed diamondcs port explorer on my system as part of trying to assist you. Though there are free products that are its equal I have no reason to believe that it is mis-reporting any information.
I personally prefer a free product "Current Ports".
-
While not wanting to appear rude this was your first post...
I noticed on my port explorer, after I close my firefox browser. ashwebsv.exe will stay connected until I actually go into webshield, terminate it and then restart it again.
I tested this a few times. Went to some websites, closed firefox and let it sit for over 24hrs. and ashwebsv.exe stayed connected to the sites the entire time. Any ideas on what is going on??
This differs somewhat from you most recent comment.
There are some instances where ashwebsv.exe does work correctly and others where it does not.
The first seemed to suggest a consistent action by avast ... your most recent suggests a ... maybe it does ... maybe it does not ... effect.
Where do you think it really appears to you?
-
not taken rude..no problem
My statements don't really conflict. They were and are some instances where ashwebsv.exe stays connected even after closing firefox...and some where it does work properly.
I don't want to seem rude either...but I can't go out to every website and list if ashwebsv.exe stays connected or not after closing firefox.
I am simply just bringing it to the attention of the makers of avast that I have experienced a problem.
Like I said before you can see "the proof in the pudding" from my logs.
-
Well ... again for a quotation "two swallows do not a summer make" and just two logs is what we have seen.
I think that, rather than muddy the waters of this thread I should start a new thread to discuss some of my thoughts about what may, in part, be happening here with Firefox and that may have contributed to the the issues in this tread and in a number of others that have preceded it. I hope that those thoughts may help my fellow toilers in assisting others in this forum. However, I will say that I do not have a comprehensive answer to the the issues raised here but that they are certainly not the "simple" issue referred to by Vlk.
Nevertheless, I cannot find a logical path that will allow me to believe that, after the chosen browser (in this case Firefox) has finally been unloaded from memory, avast will maintain any connection initiated on behalf of the browser.
-
Hi,
thanks for the report. I will try to investigate this issue more thoroughly.
What I want to say now is, that the connections are definitely NOT in the LISTENING state. This is pure nonsense. Most probably your port monitoring tool is not working properly.
The connection either has some relationship with remote IP address, then it is connected (ESTABLISHED) in the process of connecting or in the process of closing (FIN_WAIT, CLOSE_WAIT, TIME_WAIT, etc.).
Or the connections is closed, without any relationship with remote peers, then it might be in a LISTENING state, waiting for now connection to be created on the port it is listening at. (also referred to as "opened port") THIS IS NOT THE CASE HERE.
WebShield surely listens on TCP port 12080, so that it can accept connections. It does that during startup and only listens on localhost:12080. During the lifetime of the connection, it does not change from ordinary connection, to the unconnected listening port - it is not even a supported operation, to listen on connected sockets.
I am not saying, that you don't have the connections opened, but they are not in the LISTENING state. It would be somewhat interresting to know what is their actual state. I suggest trying some other utility, either excellent "TcpView" from Microsoft (now), or the "Current Ports" app alanrf has mentioned, which I saw many people here using.
Thanks.
Lukas
-
If you are using firefox I would suggest that you use adblock plus and NoScript as that kills the likes of doubleclick.net stone dead.
The use of a HOSTS file kills the likes of doubleclick.net stone dead for all browsers. 8)
Blocking Unwanted Parasites with a Hosts File
http://www.mvps.org/winhelp2002/hosts.htm
-
But I don't have to maintain/update the HOSTS file whilst using adblock plus, I appreciate the HOSTS files works with all browsers, but I won't touch IE if I can avoid it. But our personal opinions on the HOSTS file doesn't help the OP.
-
Hi, blocking umwanted sites via HOSTS file, No-Scirpt or other means is somewhat different topic. Please don't hijack this thread :P
-
The HOSTS file is totally independent of IE :P
It is easy to keep updated with HostsMan:
http://www.abelhadigital.com <== I use 3.2.70 Beta6 without problems on my systems.
In HostsMan go to Hosts then Check for updates.
The proxy in HostsServer assists in speeding up the browser.
Start HostsServer then Start Server then go to Preferences then Enable log and Log referrer to keep a log of what is being blocked by the HOSTS file.
I also use hpHosts HOSTS file as well:
http://hosts-file.net/?s=Download
Please move this discussion into its own thread.
-
Thanks for the help I appreciate it.
I have used hosts file before but really it isn't just doubleclick that is causing this. It's various other ips. Problem is that it is kinda of involved to go hopping around the internet picking out specific ip's that are causing ashwebsv.exe to hang on them. I will try to produce more logs if needed.
My problem is in the 5years that I have used port explorer. I have never had a problem like this. I have used and tested many/various programs including AVG and none gave me this problem. So, it is not normal behavior (at least on my pc).
I really don't care if it is listening or not. The main point is why is it not closing?
-
Ok..I thought some screen captures might explain the problem a little better.
#1 Here is ashwebsv.exe running normally before starting Firefox
#2 Here is ashwebsv.exe running conjointly with Firefox
#3 Here is ashwebsv.exe (normal behavior) after closing Firefox
#4 Here is ashwebsv.exe with the Problem (ashwebsv.exe will not close). It will stay in that state until I terminate webshield and start it again. Then it will go to #1.
-
sigh :(...for some reason the slider bar only works on the last pic. To see the full pics you will have open the attachment.
-
The slider works for 'all' opened images, it is just that it appears at the bottom of the 4 images.
-
I must still insist that the connection is not in the listening state!
Do you use any personal firewall? Which one? Thanks.
-
Lukas,
if you go back to rely #9 in this thread I think you will see indication the OP uses Zone Alarm (vsmon.exe). Since I use only the default XP firewall (behind a router - though I doubt it is an issue) this may explain my inability to reproduce the condition reported by the OP.
It may help if the poster were to check if there were any difference in results with the avast Webshield terminated; by this I mean a thorough test of the connections from start to end without the Webshield activated.
-
Hi,
thanks alan. I have checked this in the code. There are situations where the outgoing connection may be kept alive even after the browser is closed. It is somewhat rare, the server must stop responding (sending data) during parsing of the response headers. However these connections are terminated by timeout thread (by default after 15 minutes of inactivity). I have tested this pretty thoroughly and I was able to simulate the situation where the connection is left behind, but it will eventually vanish after 15 minutes. This interval can be shorten down by INI setting ConnectionTimeout (in seconds).
Currently I don't think it makes much sense to analyze this issue further until we know what is the state of the forgotten connection.
Lukas.
-
Lukas,
I do not want to "muddy the waters" in this thread but I might as well post my observations here since I have already done so somewhat earlier.
We have seen a number of earlier posters report that "avast maintains connections after I have terminated Firefox".
Let me say in regard to my earlier postings in this thread I now understand what I was seeing - that, whether avast is used or not there is a significant difference in connection handling between Firefox and IE in connection maintenance that may lead users to believe avast is involved when all they are seeing is the effect of the design differences between the IE and Firefox browsers.
To the best of my ability to test in the past few days the situation is this:
With IE(7) connections that are not actively used are terminated by IE by default after (I believe) 60 seconds - I have not tested rigorously - it may be as long as 90 seconds but no longer
With Firefox(3) connections that are not actively used are terminated by Firefox after 300 seconds (the default setting).
Let's be clear, in the case of both browsers the connections are usually terminated earlier if the browser itself is terminated. With the Firefox browser there is an exception.
Due to the sluggish start up of the Firefox browser a number of Firefox users avail themselves of the Firefox Preloader function. This start up loads Firefox at start up and makes it permanently resident in memory to speed up subsequent use. A side effect of this action is that any connections made by (or on behalf of) the Firefox browser will live for the full 300 seconds (of the Firefox default) even when the user believes that a Firefox session has been terminated ... but, in fact, has not because Firefox is still resident. Even without the use of the Firefox Preloader the same situation prevails if the user maintains multiple instances of the Firefox browser and connections will only be disconnected after 300 seconds or the final termination of the last Firefox session, whichever is earlier.
Anyone care to explain this to the "average user"?
BTW this post is not intended to explain or ignore the issue raised by billman1037 but to provide some clearer explanation of my earlier postings and some insight into the postings of earlier contributors in the forum. This research shows that I cannot despite my efforts, in any way, reproduce the problem that is the subject of this thread.