Forums
New posts
Search forums
News
Security News
Technology News
Giveaways
Giveaways, Promotions and Contests
Discounts & Deals
Reviews
Users Reviews
Video Reviews
Support
Windows Malware Removal Help & Support
Mac Malware Removal Help & Support
Mobile Malware Removal Help & Support
Blog
Log in
Register
What's new
Search
Search titles only
By:
Search titles only
By:
Reply to thread
Menu
Install the app
Install
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Forums
Software
Security Apps
Other security for Windows, Mac, Linux
Portmaster Firewall (Alpha stage)
Message
<blockquote data-quote="dhaavi" data-source="post: 961862" data-attributes="member: 93006"><p>Thanks all for your great feedback and questions! Please ping me if I missed to cover a technical question below that you wanted an answer to.</p><p></p><p></p><p>With the fix mentioned below, we fixed an issue with the Portmaster not correctly detecting connectivity. It may have detected connectivity too early in the past, meaning it would attempt to update when there is not connection yet. So, this _might_ work a lot better now.</p><p></p><p></p><p>We use one.one.one.one -> 1.1.1.1 as a check if DNS resolved correctly during connectivity testing. What we like about using one.one.one.one is that (1) it is not suspicious - we don't like to broadcast to the network that the Portmaster is running on a device - and (2) the returned IP address will (very likely) never change.</p><p>We did not think about other systems blocking that domain though, which caused the Portmaster to retry it.</p><p></p><p>This problem reached us in a fortunate time window and we have already implemented and released a fix for that: If resolving one.one.one.one is not successful, we now use dns-check.safing.io as a fallback, which makes it obvious the Portmaster is at work, but we need a guarantee on the returned IP address for the check to reliably work.</p><p></p><p>No, there was no impact, just that the Portmaster would think it is only "semi online". But, as laid out above, this should now be resolved anyway.</p><p></p><p></p><p>Interesting. From what I saw when I looked into this, this should not be related.</p><p></p><p></p><p>Until now we've only had problems with the Tray Notifier appearing multiple times. We use a PID-lock for the notifier - what could have happened is that the notifier failed to clean up after itself (hard shutdown?) and then PID of the old PID-lock of the notifier was taken by another process, letting the notifier think that there is already an active instance running.</p><p></p><p></p><p>We definitely want to do this, but this isn't easy to do while keeping things fast as they are. On Linux, we'd have to find a whole new way to interact with the network stack, on Windows we'd need to add support for counting data in the kernel extension. So, it'll come, but it'll take some time.</p><p></p><p></p><p>What do you mean exactly by "protect"? We cannot stop packets from arriving at your device.</p><p>Currently, the Portmaster drops incoming packets it does not allow, meaning that a scan will be not be able to see open ports that are not allow to accept connections by the Portmaster. In my opinion, that ticks the "protect" box.</p><p>In addition, we have a portscan detection system in progress (no ETA! [Estimated Time of Arrival]), which will outright block all communication with an IP that is scanning your device, even when scanning allowed ports. This will also have notifications.</p></blockquote><p></p>
[QUOTE="dhaavi, post: 961862, member: 93006"] Thanks all for your great feedback and questions! Please ping me if I missed to cover a technical question below that you wanted an answer to. With the fix mentioned below, we fixed an issue with the Portmaster not correctly detecting connectivity. It may have detected connectivity too early in the past, meaning it would attempt to update when there is not connection yet. So, this _might_ work a lot better now. We use one.one.one.one -> 1.1.1.1 as a check if DNS resolved correctly during connectivity testing. What we like about using one.one.one.one is that (1) it is not suspicious - we don't like to broadcast to the network that the Portmaster is running on a device - and (2) the returned IP address will (very likely) never change. We did not think about other systems blocking that domain though, which caused the Portmaster to retry it. This problem reached us in a fortunate time window and we have already implemented and released a fix for that: If resolving one.one.one.one is not successful, we now use dns-check.safing.io as a fallback, which makes it obvious the Portmaster is at work, but we need a guarantee on the returned IP address for the check to reliably work. No, there was no impact, just that the Portmaster would think it is only "semi online". But, as laid out above, this should now be resolved anyway. Interesting. From what I saw when I looked into this, this should not be related. Until now we've only had problems with the Tray Notifier appearing multiple times. We use a PID-lock for the notifier - what could have happened is that the notifier failed to clean up after itself (hard shutdown?) and then PID of the old PID-lock of the notifier was taken by another process, letting the notifier think that there is already an active instance running. We definitely want to do this, but this isn't easy to do while keeping things fast as they are. On Linux, we'd have to find a whole new way to interact with the network stack, on Windows we'd need to add support for counting data in the kernel extension. So, it'll come, but it'll take some time. What do you mean exactly by "protect"? We cannot stop packets from arriving at your device. Currently, the Portmaster drops incoming packets it does not allow, meaning that a scan will be not be able to see open ports that are not allow to accept connections by the Portmaster. In my opinion, that ticks the "protect" box. In addition, we have a portscan detection system in progress (no ETA! [Estimated Time of Arrival]), which will outright block all communication with an IP that is scanning your device, even when scanning allowed ports. This will also have notifications. [/QUOTE]
Insert quotes…
Verification
Post reply
Top