Win7 64 wake up

Win7 64 setup. After windows sleeps, during wake up, there is no Network protection from L`n`S for a period of time. It is only a few seconds, but as I need boot protection(which is already set with reg entry), I also need protection at all other times, even during wake up.

I did put in an e-mail to support (registered user) at the website 7 days ago, but no reply, so though to see if anyone knows of this problem/ possible fix?


- Stem

Note: I may not reply to thread for a while, I have a lot of work on at present.

 

Did you test if there is no protection (you can ping or access the machine without L n S blocking it)? I can recall similar issue with another FW (possibly ZA) but nobody could confirm that there was a failure

 

Hi Cudni,

Yes, there is an 11 second window during/ just after wake up when replies are made to pings, and windows is allowed its various outbounds during that time (the outbounds are filtered by application/Internet rules, but are bypassed during that time)

I do need to get back to work, so will check back when I can.

- Stem

 

That is a flaw then. Let us know if there is a reply from tech support

 

There are settings in advanced about keeping internet filtering and application filtering running even after looknstop has stopped ,although the help file says this is only for windows 2000/XP? ( i dont know whether help file is up to date or it is only for those OS?),although the options to tick the boxes seem available in w764bit.Is yours ticked.If not tick them. Does it make a difference stem?

 

I think that's for apps with outbound privileges such as a Browser and then you close it LNS with still keep and eye on it!

TH

 

I'm not sure.The help file states that looknstop is the closed/killed application in this instance ( I think?),though I'm not sure how looknstop could still protect if its shut-down?
...............................................
'Keep application filtering active after the application is stopped': this option is only for Windows 2000 and XP. When enable, Application Filtering is still active even if you stop the Look 'n' Stop application (or if a malware application killed Look 'n' Stop). Already known connecting applications are handled according to the rules, unknown applications are automatically blocked. There is no log.
...............................................
ellison

 

Because of the drivers.

 

I can confirm Stem finding (for at least with Windows 7 64-bit), there is a 2-3 second window of opportunity when waking up, and ‘Keep * Filtering active after the application is stopped’ wouldn’t help, because of how Sleep mode works, Look ‘n’ Stop application still in memory, but I anyway tested and still with the same results.

 

Hi ellison64,

I had already set that, but it does not help.


- Stem

 

I am getting a longer period of time showing.

This is a default Win7_64 setup. It was setup in my Internal LAN with IP 10.123.123.101/ fe80::d11f:3bf5:6a0:6999

This is a copy of the "Packet summary line" (from Wireshark) of the full packet capture during sleep/wake up (as seen from 10.123.123.100)

Outbound starts at 20 /104.065117
Replies to Echo start at 37 /109.748525
The last Echo reply is at 60 /120.748867

( 11 second window)

----------------------------------------------

No. Time Source Destination Protocol Info
1 0.000000 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=9472/37, ttl=12
2 5.242243 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=9728/38, ttl=12
3 10.741799 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=9984/39, ttl=12
4 16.242450 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=10240/40, ttl=12
5 21.743543 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=10496/41, ttl=12
6 27.243648 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=10752/42, ttl=12
7 32.743178 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=11008/43, ttl=12
8 38.243867 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=11264/44, ttl=12
9 43.743859 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=11520/45, ttl=12
10 49.245030 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=11776/46, ttl=12
11 54.745520 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=12032/47, ttl=12
12 60.245187 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=12288/48, ttl=12
13 65.745238 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=12544/49, ttl=12
14 71.246395 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=12800/50, ttl=12
15 76.745916 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=13056/51, ttl=12
16 82.246565 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=13312/52, ttl=12
17 87.747604 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=13568/53, ttl=12
18 93.247766 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=13824/54, ttl=12
19 98.747262 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=14080/55, ttl=12
20 104.065117 Giga-Byt_87:c8:e1 Broadcast ARP Who has 10.123.123.101? Tell 0.0.0.0
21 104.065129 :: ff02::1:ffa0:6999 ICMPv6 Neighbor solicitation
22 104.065355 fe80::d11f:3bf5:6a0:6999 ff02::2 ICMPv6 Router solicitation
23 104.247923 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=14336/56, ttl=12
24 105.063505 Giga-Byt_87:c8:e1 Broadcast ARP Who has 10.123.123.101? Tell 0.0.0.0
25 106.061977 Giga-Byt_87:c8:e1 Broadcast ARP Who has 10.123.123.101? Tell 0.0.0.0
26 108.058864 fe80::d11f:3bf5:6a0:6999 ff02::2 ICMPv6 Router solicitation
27 108.451502 fe80::d11f:3bf5:6a0:6999 ff02::16 ICMPv6 Multicast Listener Report Message v2
28 108.462597 Giga-Byt_87:c8:e1 Broadcast ARP Who has 10.123.123.1? Tell 10.123.123.101
29 108.468099 Giga-Byt_87:c8:e1 Broadcast ARP Who has 10.123.123.1? Tell 10.123.123.101
30 108.558127 fe80::d11f:3bf5:6a0:6999 ff02::16 ICMPv6 Multicast Listener Report Message v2
31 108.734159 Giga-Byt_87:c8:e1 Broadcast ARP Who has 10.123.123.1? Tell 10.123.123.101
32 108.739859 Giga-Byt_87:c8:e1 Broadcast ARP Who has 10.123.123.1? Tell 10.123.123.101
33 108.747942 Giga-Byt_87:c8:e1 Broadcast ARP Who has 10.123.123.1? Tell 10.123.123.101
34 109.747946 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=14592/57, ttl=12
35 109.748247 Giga-Byt_87:c8:e1 Broadcast ARP Who has 10.123.123.100? Tell 10.123.123.101
36 109.748253 AsrockIn_46:80:34 Giga-Byt_87:c8:e1 ARP 10.123.123.100 is at 00:25:22:46:80:34
37 109.748525 10.123.123.101 10.123.123.100 ICMP Echo (ping) reply (id=0x0300, seq(be/le)=14592/57, ttl=12
38 110.748017 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=14848/58, ttl=12
39 110.748253 10.123.123.101 10.123.123.100 ICMP Echo (ping) reply (id=0x0300, seq(be/le)=14848/58, ttl=12
40 111.748083 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=15104/59, ttl=12
41 111.748320 10.123.123.101 10.123.123.100 ICMP Echo (ping) reply (id=0x0300, seq(be/le)=15104/59, ttl=12
42 112.052618 fe80::d11f:3bf5:6a0:6999 ff02::2 ICMPv6 Router solicitation
43 112.748154 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=15360/60, ttl=12
44 112.748388 10.123.123.101 10.123.123.100 ICMP Echo (ping) reply (id=0x0300, seq(be/le)=15360/60, ttl=12
45 113.748227 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=15616/61, ttl=12
46 113.748462 10.123.123.101 10.123.123.100 ICMP Echo (ping) reply (id=0x0300, seq(be/le)=15616/61, ttl=12
47 114.748249 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=15872/62, ttl=12
48 114.748491 10.123.123.101 10.123.123.100 ICMP Echo (ping) reply (id=0x0300, seq(be/le)=15872/62, ttl=12
49 115.748313 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=16128/63, ttl=12
50 115.748553 10.123.123.101 10.123.123.100 ICMP Echo (ping) reply (id=0x0300, seq(be/le)=16128/63, ttl=12
51 116.748376 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=16384/64, ttl=12
52 116.748619 10.123.123.101 10.123.123.100 ICMP Echo (ping) reply (id=0x0300, seq(be/le)=16384/64, ttl=12
53 117.748435 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=16640/65, ttl=12
54 117.748673 10.123.123.101 10.123.123.100 ICMP Echo (ping) reply (id=0x0300, seq(be/le)=16640/65, ttl=12
55 118.748499 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=16896/66, ttl=12
56 118.748726 10.123.123.101 10.123.123.100 ICMP Echo (ping) reply (id=0x0300, seq(be/le)=16896/66, ttl=12
57 119.748561 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=17152/67, ttl=12
58 119.748799 10.123.123.101 10.123.123.100 ICMP Echo (ping) reply (id=0x0300, seq(be/le)=17152/67, ttl=12
59 120.748623 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=17408/68, ttl=12
60 120.748867 10.123.123.101 10.123.123.100 ICMP Echo (ping) reply (id=0x0300, seq(be/le)=17408/68, ttl=12
61 121.748681 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=17664/69, ttl=12
62 127.249878 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=17920/70, ttl=12
63 132.749375 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=18176/71, ttl=12
64 138.250037 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=18432/72, ttl=12
65 143.750095 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=18688/73, ttl=12
66 149.251259 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=18944/74, ttl=12
67 154.750775 10.123.123.100 10.123.123.101 ICMP Echo (ping) request (id=0x0300, seq(be/le)=19200/75, ttl=12

-----------------------------------------------------

 

I wasn’t arguing your observations, I meant for mine alone.

 

Is your observation unique to W7 x64?

 

I only currently have XP pro 32 and Win7 64 on my setups.

It is not a problem on Win Xp 32 when Hibernating/waking.



- Stem

 

This might be a shot in the dark ,but I googled a little a bit concerning sleep/hibernation etc and found a few posts about problems with Lan when waking up the computer.This apparently is because in device manager>network adaptors>right click >properties ...there's a setting that allows the computer to turn off the device to save power.Unticking that option fixed some lan problems ,with sleeep and hibernation.Would that be connected to the looknstop problem?
ellison

 

The same for Windows 7 32-bit, also same results with power save unticked.

 

Thanks. I also have XP and W7/x64 PCs. I use LnS on my XP PC, only - have not seen any issues.

 

Ditto here. On XP - while another computer was continuously pinging me, not a ping got through standby (nap, not hibernation) and during logging in after resume from standby. Responses to those continuous pings resumed thereafter. LnS v2.0.7

 

to reproduce Stem results, it is better anyway to keep ICMP Echo requests coming in .. blocked, and pinging is re-occurring for at least two minutes in after awakening from sleep mode, this ensures quality test being performed.

 

Thanks for the info.

I have put in another e-mail for registered "Priority Support" concerning this issue.

EDIT: I had a reply to my second e-mail. That just asked if I had set the Advanced options for keeping the filtering active when L`n`S is stopped. I though whoever replied would of at least tested.

- Stem

 

This is troublesome. It makes me curious as to when exactly LNS starts network protection during a normal boot with Windows 7 64 (or 32).

 

Shouldn’t be troublesome, Look ‘n’ Stop firewall provides boot time protection using the registry tweak.

-- BlockAllBeforeInit.reg ... copy the below information

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lnsfw]
"BlockAllBeforeInit"=dword:00000001

---- don’t copy this line ----

No gap / window of opportunity with this tweak fucus

 

I assume the reg fix once implemented resolves the issue (you tested it)?

 

This issue is a shared issue among different popular software firewalls, unless things changed since I last investigated.

anyways, yes..., I’ve tested Look ‘n’ Stop Boot-Time protection feature.

 

The reg hack is for boot protection which does work, but it does not resolve the issue at wake up. I do(did) have the reg hack in place as I mentioned in first post.



- Stem