I accept your point however all I can say is that my problem has been solved and I suspect it was via a further patch which Symantec issued yesterday morning, or that the DNS servers caught up with whatever change they previously made. I am using OpenDNS (abd have done for some while) but don't know if they have localised severs for UK / Europe?
As I said to CG, it is wierd and I can't explain it but for me the solution was that it started to work again.
I dont like running without firewall either. Since I am unsure about effectiveness of Norton firewall, it is difficult to know if Norton is protected from SYN flood, UDP flood, ICMP floor, Land, Smurf, SYN fragment, Fraggle Attack, Tear Drop and a whole list of DoS defences that need to be in place.
I will have a better idea I hope after Friday this week. Please bear with me.
I have installed and successfully run Wireshark but you didnt tell me I need a degree from NASA to interpret! lol
I see all the http 1.1 and I see red lines but I cant figure out what in the firewall is stoping the process. I will keep working with this tool, it looks interesting but needs some investigating.
P.S.
Unlike a software proxy server, I dont think this tool will work for me, because ideally I need to capture traffic in both directions as it reaches and as is sent from the router. That means a sniffer on the broadband side of the router and not just looking at traffic to and from the PC to the router. I hope that makes sense.
However, if I was a betting man (which I am on roulette) I place heavily that this is an http 1.1/1.0 issue and the firewalls in the router are not responding back to Symantec because they do not distinguish between 1.1 and 1. if that makes sense. Whoever decided in Symantec to make a change like this in 16.5 without thinking through the consequences of proxy and hardware firewalls, and without testing on basic equipment (I'm using Belkin and others have listed their equipment) deserves a pat on the back on his/her way out.
Not sure. If it transpires that the problem is related solely to NIS 2009 16.5 and 360 v3, it begs the question as to how such a change was tested in-house before release. That is, whether or not they knew of the problem prior to releasing the patch, they ought to have tested in house thoroughly first. Thats my view.
Nice idea. I am sending you a private message please watch out in the top right.
Of course there is a change in 16.5, we know that because Symantec have confrmed a change in the treatment of http 1.1 packets. The change has to be reflected somewhere and it is reasonable that it could be in the lue.dll. The only reservation I have is that I do not know what else has been changed in lue.dll or elsewhere..
I should later perhaps compare the lue.dll in NIS and the lue.dll in Norton 360 v3 since they share common code.
There is no facility to upload lue.dll to this forum. Another contributor has it posted on a server for download but it is up to him/her if he/she wants to make it widely available. I have yet to test it, and I am awaiting Symantec's response to this workaround.
Meanwhile, out of interest, did you try disabling firewall in your router?
now its working normaly