New version 2.05b2

No, i need the file to be available, and to be blocked/unblocked on demand.

 

I got it down pack now baby!!!!!!!!!!

Here it is:

If Protocol WANARP.SYS isn’t allowed you can’t DNS, and because you can’t DNS you can’t authorize WANARP.SYS.


Using NPF.SYS and with DNS rules Active, Allowing Protocol Driver while Protocol Driver has activity is possible but just a small delay.

Using NPF.SYS and with DNS rules disabled, Allowing Protocol while Protocol Driver has activity, changes doesn’t apply till the very moment I enable DNS rules.

 

Because NPF.SYS isn’t depended on for Internet like WANARP.SYS Protocol I can Allow/Block DNS using Internet Filtering rules, but because WANARP.SYS can’t DNS it’s very unlikely we can allow this Protocol Driver and thus means no Internet until Frederic returns and creates a fix.

 

I have done what was suggested above re WANARP.SYS (I hope!) but stilll have problems.

The only thing resolving is my time server, which is a change as nothing was resolving before, but I have had to turn off protocol filtering to send this.

 

Actually I think that may not be true, I've just noticed I had the time server flagged to report.

 

Hi,

Since there is a cache, the verification I proposed below can fail.

Here is the correct test to be performed:
- disable Look 'n' Stop automatic start
- verify Wanarp.sys is allowed in the protocol list
- allow the protocol filtering
- reboot the computer
- connect to internet (Look 'n' Stop is not active)
- after the connexion and when you are sure you got an IP address (this is important, you can check you got an IP with IPConfig) start Look 'n' Stop
- does the problem still occur ?

This is only for investigation, obviously it is not a fix...

Thanks,

Frederic

 

Here is the correct test to be performed:
- disable Look 'n' Stop automatic start
- verify Wanarp.sys is allowed in the protocol list
- allow the protocol filtering
- reboot the computer
- connect to internet (Look 'n' Stop is not active)
- after the connexion and when you are sure you got an IP address (this is important, you can check you got an IP with IPConfig) start Look 'n' Stop
- does the problem still occur ?

This is only for investigation, obviously it is not a fix...

Thanks,

Frederic

Hi Frederic,

It seems to work just fine after doing what you mentioned above. No problems at all.

 

Hi again

Same here, all OK after doing what you asked.

 

Ok, thanks for your feedback.

I know where is the problem and how to fix it.

Frederic

 

May be just with me but I feel the approach to detecting Protocol Drivers needs re-designing, why should a Protocol Driver to be detected needing to be Allowed in “Internet Filtering” or even send packets. There has to be another way?

 

For us it's better to detect the protocol only if it really tries to send packet.
I don't know if a static detection is possible. Certainly for standard Windows protocols like Wanarp, but I'm not sure for dynamic protocol drivers like NPF.SYS.
The advantage to have a dynamic detection is that the Internet Filtering can display the content of the packet being sent.

Frederic

 

Hi aptisman & dukebluedevil

Please, contact me by email (looknstop@soft4ever.com) and I will send you a fix for testing.

Frederic.

 

Hey Frederic

You can E-mail me the Driver for testing also if you like, since I can reproduce the anomaly regardless my Internet don’t use that Protocol Driver…

 

The fix is looking good here so far!

Thanks for another great job.

 

Protocol Filtering is working just fine now with the fix. Thank you very much Frederic!

 

Why hasn’t the Installers been updated yet to include this fix

 

because a fix which works for one or two person isn't beta but alpha, and alpha releases aren't throw generally in public, they must be tested and then a new beta can come out.