2.05p3 Package Available

Hi,

I suppose you are running Look 'n' Stop in service mode.
This is a known issue, help is not working when Look 'n' Stop is started in service mode.
I investigated it already, and unfortunately I absolutely don't know why this is happening. Everything is normal but a windows call to an htmlhelp windows internal function is failing for an unknwon reason.

Frederic

 

Thanks for the super fast reply. Yes, i am running LnS in service mode. Not a big deal though. I can access the help file from LnS directory.

 

Thanks Frederic. Lot more easy to install.

 

Could it be to do with fixes for this Escalation of Privilege via HTML Help API vulnerability? If so, the alternative methods listed there of calling the Help API may work.

 

Hi Paranoid2000,

Yes, this is probably what is happening. I wasn't aware of that.
Knowing that, I've just tried to start directly hh.exe (instead of using the API) and the same occurs, the application doesn't start.
It seems Microsoft fixed this vulnerability and now hh.exe can only work if started by a user, not started by the system (as a service does).

Thanks for your help.

Frederic

 

Nah!, this should explained anyway. Thx, Frederic.

 

A suggestions for a new release:

I was a bit annoyed that LnS installed to /program files/ . That is just fine for english Windows machines, but not on localized ones. It should default to use the system standard for the application folder.

 

A better solution IMO, which involves a bit more work, would be to split LnS into two component parts - a client and a server.

The server would run as a service and effectively performs the firewall functions.

The client runs as a user app and is the GUI.

The two could communicate through named pipes or TCP/IP.

Since the client runs as a user app, there should be no problems associated with starting HTMLHelp.

 

Yup, Online Armor ran into that, can't run chm files with system privileges.

 

Yes, this is a solution and normally it would also solves other issues like FUS, or even simple session closing/opening issues, when using LnSSvc
The problem is it requires a split in the application, which is not immediate and some work would be required if we finally choose this kind of solution.

Frederic

 

When you install Look 'n' Stop for the first time, normally you can choose the installation folder as you want.
Perhaps I didn't understand you request ?

Frederic

 

Is it by design that entries in the state table gets left / stuck in there?

Btw; congratulations on the new release...

 

Once again, congratulations on Look ‘n’ Stop v2.05p3,
As I already imagined, TCP SPI simultaneous connections limit still of an annoyance with my every-day normal activities, and forces me to disabling TCP SPI feature in Look ‘n’ Stop.

 

I suppose you are talking about TCP SPI.
No this is not by design. Only when the "hsitory of the last connections" is ticked all the old entries are there. Could you give us a screen copy ?

Thanks,

Frederic

 

Still using P2P software I imagine
What about the special SpiInOnly flag: is it some use or not ?

Frederic

 

Hah, Hey Frederic

Yes, p2p software among other sorts..

Yes I’m in reference to TCP SPI state table, and no I don’t have ‘History of the last connections’ activated.

No screenshot but, CFull loggings, and SPI alerts only on Inbounds.

No, No SpiInOnly flag set..

 

I failed to mention this earlier, regarding TCP SPI state table, It was mainly with 'Connecting' entries..

 

Ok, in this case it is normal. These are really "connecting" TCP entries and all are displayed. Eventually old ones could be not displayed, with a timeout value. On the driver side, there is also a timeout and "connecting" entries are reused for a new connection after a delay.

Frederic

 

These ‘Connecting’ entries sticks in state table for hours and hours later, even a entire day they still there, until I re-boot, or re-launch Look ‘n’ Stop.

 

Are you sure they are not replaced by new "connecting" entries ?
Normally very old entries are reused (timeout mechanism) as soon there is no more a free entry. If you have a CFull indication at the same time, normally you should have only recent "connecting" entries, not old.
If it is not the case, there could be bug, explaining why you have the CFull issue.
Perhaps it's related to the SPIInOnly configuration. Could you check if the same issue is there when this flag is disabled ?

Frederic

 

Hey Frederic

Didn't set SpiInOnly flag..

 

Ok, and do you confirm you have CFull in log, and old "connecting" entries at the same time ?

Frederic

 

Regarding LnS state table, say for instance if I ran client making multi connections, and I end it and while it still hadn’t made it beyond connecting state, ‘Connecting’ entries don’t disappear for LnS state table.

I personally like to see Time-Out being used, and remove Nth Line that stays in ‘Connecting’ mode after Time-Out, should not need to wait for these entries to become old enough and pushed out of records.

 

Been checking this out. Haven't run into any issues. But for some reason the icons in the "list of active applications" are all generic. Not a big deal; but wasn't this NOT the case before??

TIA

 

These icons should the same as the ones in the list of allowev/blocked application. Is it the case ? or do you have different icons on the left side and the right side ?
Would it be possible to get a screencopy ?

Frederic