ProcessLasso TCP connection left in CLOSE_WAIT state [FIXED beta]

Started by Montgomery, June 29, 2015, 09:32:36 AM

Previous topic - Next topic



Process Lasso x64 on Windows 7 x64
1- Even though I've opted for Updates:Never every new Windows session shows ProcessLasso.exe having opened a TCP connection to
I assume this is the updater function.

2- If I don't close it myself this connection remains.



But its State = close_wait , so its not doing anything .
Bitsum QA Engineer


1- I denied auto-update, so no connection should be done to bitsum ;
2- A "Close Wait" connection that doesn't close after the nominal delay is not normal ;
3- It's not because a process doesn't harm that its inconsistency when applicable is not worth being mentioned.

Jeremy Collake

This is something we had reported last month, but I haven't had a chance to look into it. I believe the connection isn't properly cleaned up. I am building 8.4 final now, which will behave the same, but will be sure to get this addressed in future versions.

I hate to speculate on what is going on, but these things are certain:

  • If it is the update check occurring even though update checks are disabled, then it's a bug - and probably passed our tests because it just doesn't tell you about the update
  • If it is after a manual update, then the connection may not have been cleaned up properly.
  • Other than product activation, there really aren't any other possibilities
  • As you can see, no significant data is transferred, and the connection is just not cleaned up properly, so it's absolutely NOT any sort of 'call home' function

Topic moved to bug reports and I'll be tracking this closely. I may very well release a beta that resolves it in the coming day(s). Once I've tracked down the precise cause, I'll be able to tell you why it happened, etc...

Thanks for the report!

Apologies for the problem, and I'll post here when I have it resolved!

And smart move running dnscrypt-proxy, I have tried to encourage as many people as possible to do the same. It's amazing that so few people consider the lack of DNS query encryption a serious issue.
Software Engineer. Bitsum LLC.


Thanks for acknowledging. I understand it'n in no way a privacy issue, not with Bitsum. I was and remain puzzled but aware it's most likely nothing more than an unclosed switch, somewhere. No problem.

Process Lasso getting better, smarter and stronger at every update. Enjoying it like all of those who've tried it.

And the beat lasso goes on :)

EDIT : I had to initiate a new registration because I had closed previous one (above) a day I was in a bad mood... sorry for the disturbance.

Jeremy Collake

Glad to have you back, and apologies for my late reply! I am so often deep into product dev and leave the forum to others for a few days.

I'll have an answer/fix for this very soon... maybe tonight.
Software Engineer. Bitsum LLC.


QuoteAnd smart move running dnscrypt-proxy, I have tried to encourage as many people as possible to do the same. It's amazing that so few people consider the lack of DNS query encryption a serious issue.
Well, In china, some people are using it, and you know why. ;)

Jeremy Collake

So it appears the cause here was NOT the update check -- that is why the updates off setting didn't matter.

It's a connectivity check I added a few versions ago that didn't properly close it's internet handle.

In this case, a call is made to simply see if Bitsum's servers are accessible by accessing before attempting to show you an offer to purchase a license (even for licensed users, as the 'already activated' check is later).

It will be fixed in v8.5.0.5 beta, coming in hours at latest.
Software Engineer. Bitsum LLC.


fixed confirmed in v8.5.0.5 beta , even with updates on .
Bitsum QA Engineer

Jeremy Collake

Software Engineer. Bitsum LLC.


This tiny non-issue in fact was related to a connectivity check and not to the update check : OK

I'm no specialist (I eat without cooking!) but I imagine this type of tiny little bug with no incidence whatsoever on the program itself can be the toughest to find precisely because it is not in a heavy cause to consequence scheme...

So, my wandering made Jeremy land on a small ratio consequence/cause brain exercise :) Anyway, happy to know the origin has ben spotted and solved with PL beta, and thanks for having taken the time to resolve what was obviously not a flaw at all.