- ui: fixed error getting the icon of an app.
- ui: fixed getting the list of pids of an app.
- ui: improved proc details start/stop icon behaviour.
- daemon: improved error message when we fail getting the details of a
process.
others:
- changed icon search by system-search.
When building the project with protoc-gen-go version 1.5.1,
it fails with the following:
```
protoc -I. ui.proto --go_out=plugins=grpc:../daemon/ui/protocol/
protoc-gen-go: unable to determine Go import path for "ui.proto"
Please specify either:
• a "go_package" option in the .proto source file, or
• a "M" argument on the command line.
See https://developers.google.com/protocol-buffers/docs/reference/go-generated#package for more information.
--go_out: protoc-gen-go: Plugin failed with status code 1.
```
This can be fixed by adding the full go package as an option in the
proto file. To make sure the code is generated to the correct path,
we also have to add add the `paths=source_relative` option to the
protoc plugin.
After this, the code is generated correctly, but the generated code
references classes like grpc.ClientConnInterface which were introduced
in 1.27.0.
- don't clean cache by number of items.
- clean inodes from cache every 2' if the descriptor symlink doesn't exist
anymore, or if the lastSeen time is more than 5 minutes.
- launch cache cleaners before start a new process monitoring method,
and start it only once for the life time of the daemon.
- do not store in cache the Time objects, only the nanoseconds of
the last updated time.
- if the inode of a connection is found in cache, reorder the
descriptors to push the descritptor to the top of the list.
Also add cached the inode.
It turns out that when a new connection is about to be established,
when the process resolves the domain, the same inode is used to open the
tcp connection to the target. So if it's cached we save CPU cycles.
This also occurs when we block a connection and the process retries it,
or when a connection timeouts and the process retries it
(telnet 1.1.1.1).
- update the descriptors/inodes of a PID when it's found in cache.
- when a descriptor/inode is found in cache, push it to the top
of the descriptors list. The next time it's found in cache it'll be in
the 1st position of the list, saving CPU time.
- added test cases and benchmark helpers to help analyzing performance.
Added the description of an app to the pop-ups, to help users know
what an application is or does.
The discovery of app icons has been improved for those edge cases where
the system is not properly configured and we were not able to get the
icon of the app.
- Delete lists of domains if the rule about to change is of type Lists.
- Monitor the lists of domains, and reload them if they're modified.
- Delete rules from disk when the Duration changes from
Always (saved on disk) to !Always (temporary).
- After the above operation a fsnotify Remove event is fired. Don't
delete the rule from memory if it's temporary.
- Rules are only compiled if they're enabled, avoiding unnecessary
allocations.
Any rule changed on disk caused reloading of all rules, usually
up to three times. This caused some problems.
- Don't compile Operators if the rule is disabled.
- Empty lists of domains if the user disables the rule.
- Delete rule from disk if the duration is not Always anymore.
There're some situations where we need to delete loaded lists:
- When an enabled rule of type Lists is disabled (after changed on
disk, or when configured from the GUI).
- When an enabled rule of type List with an Operator of type Lists is
disabled.
Initial support to filter connections using lists of domains.
The lists must be in hosts format:
- 0.0.0.0 www.domain.com
- 127.0.0.1 www.domain.com
From the rules editor, create a new rule, and select
[x] To this lists of domains
Select a directory with files in hosts format, select [x] Priority rule,
select [x] Deny and click on Apply.
An example of a list in hosts format:
https://www.github.developerdan.com/hosts/lists/ads-and-tracking-extended.txt
Note: you can also add a list of domains to allow, not only domains to
block.
TODOs:
- support for URLs besides directories (local lists).
- support for scheduled updates of the above URLs.
related #298
Sometimes when querying the kernel for a given connection, the inode of
the connection is 0, i.e.: invalid (or not yet valid).
In these cases we search for the connection in /proc/net/. It turns out
that some connections are found in netstat but the inode is still 0, and
we were accepting them erronously.
As a result, when looking for the inode under /proc we didn't find it,
so an "Unknown process" dialog was shown to the user.
Discarding this type of connections avoids unknown process dialogs when
using Epiphany in particular. It retries to establish the connection
several times, and finally we're able to find the PID of the process.
When testing this patch under a heavy load of 300 new connections per second running for 12 hours, I saw a few timeouts.
This means that there are legitimate cases when sending the packet to the channel will not go through
no matter how long we wait.
However, compared to the old behavior, the amount of dropped packets decreased by a factor of 100x.
The value of timeout is chosen to be 1 millisecond, because it feels reasonable that if after so long the packet did
not go through, it is not due to a congested channel but due to some other error which will not go away even if we wait longer.
Every rule has an entry point besides a constructor, which configures
all it needs to match connections, based on user defined criteria (ip,
regexp, etc).
This only needs to be done the first time we load a rule, because the
fields of a rule are static. However for rules of type "lists" we were
iniatializing each rule of this type once per connection that it
matched.
We added UPSERTS, to update the time of a rule when a connection matched
that rule.
However UPSERTS in SQLite weren't introduced until v3.24.x, thus it
causes errors on older versions (like the ones shipped with Ubuntu
16/18).
On the other hand, we need to replace the rules once we receive them
from the daemon, to reflect on the GUI any change made on the rules by hand.
More info: #344
