-
-
Notifications
You must be signed in to change notification settings - Fork 521
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No events captured under Manjaro/Arch. #833
Comments
Hi @famewolf , You only need one package: opensnitch (1.5.x) or opensnitch-git (1.6.x). Remove one of them and it should start working. |
I tried both of them one at a time and neither worked.
…On February 5, 2023 12:37:25 PM Gustavo Iñiguez Goia ***@***.***> wrote:
Hi @famewolf ,
You only need one package: opensnitch (1.5.x) or opensnitch-git (1.6.x).
Remove one of them and it should start working.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
ok, I need you to follow the next steps in order to verify that your current installation is fine (ignore steps if already done):
This message |
I have a similar issue after the recent update. As far as I can make out from status and logs there are no errors, just no intercepts. OS: Manjaro 22.0.2 up to date
|
Hi @pnavinash , That looks like a different problem. At least in your case the daemon is running. Please, set LogLevel to DEBUG (Preferences -> Nodes), execute Also, please, close the GUI, and launch it from the shell, to see if it's outputting any errors to stdout. |
I'm seeing the same with 1.5.5 on Arch Linux. The UI doesn't seem to be able to establish a connection to the daemon since the local node is not listed. So the node preferences in the UI don't take effect. The UI prints the following on stdout/stderr:
Neither of these sound like they should keep it from communicating with the daemon, should they? |
@gustavo-iniguez-goya : Thank you, do you want me to continue to post here or create a new issue? As @weltenwort posted above, changing the log level in UI does not seem to make it through. Here is what I did:
|
hmm, I'll investigate this error |
Thanks for being willing to help us out. This might be a red herring, though, since these log lines might be from before the update was applied. For me 1.4.3 produced these, but worked flawlessly. |
Here is my update log if it helps. I was using opensnitch from AUR and it seems like Arch now ships it in community repo. You'll also see my installation and removal of
|
hmmm, on the one hand I've realized that the package On the other hand, on a clean Arch install, the daemon 1.5.5 doesn't connect to the GUI. If the daemon is started once the GUI is running, then it starts working as expected. update: this does not occur with the deb packages, built from latest sources using 1.5.0 branch (also without the ebpf modules, and procMonitorMethod set to "ebpf". |
Thanks @gustavo-iniguez-goya . I manually edited Based on your latest edit, it seems like some sort of race condition and editing is not really relevant. I'll do a restart now and check. Update after reboot: daemon again fails to connect to UI and needs a systemctl restart. |
A daemon compiled from sources works as expected in all cases: starting the daemon having the GUI running, starting the daemon before the GUI is running and then launching it. Just in case someone wants to test it out: opensnitchd.gz Or compile it from the 1.5.0 branch. Arch's opensnitch-1.5.5 daemon fails to connect to the GUI if the GUI is launched once the daemon is running. If the GUI is launched before the daemon then it works. No idea why, we haven't changed any part of the daemon or GUI that affects this functionality. I'll keep analyzing this problem, but it'd be worth investigating what has changed on Arch opensnitch 1.5.5 vs Aur opensnitch |
The That could change the behavior of the compiled binary. |
ha! good catch @weltenwort . I can tell that we're compatible with gopacket v1.1.19, but no idea about fsnotify v1.6 (it shouldn't be a problem), netlink v1.1.0 (I don't think it'll cause any problem) and >> gRPC v1.52.3 << I'd blame gRPC 1.52.3 based on the history of issues we've had. |
Any thoughts on when this may be fixed? |
This is not an OpenSnitch problem as far as I can tell. But an incompatibility with one of the libraries changed here: |
ℹ️ the packaging bug is tracked in https://bugs.archlinux.org/task/77412 |
Anybody got a link to a binary that uses the original community PKGBUILD or other workaround? |
The current workaround is to build from source: git clone https://aur.archlinux.org/opensnitch.git
cd opensnitch
# change the version to 1.5.5 so that pacman doesn't try to replace it with the broken 1.5.5 from the community
sed -i 's/^pkgver=.*/pkgver=1.5.5/' PKGBUILD
updpkgsums
makepkg -si |
Thank you! |
Yo, Arch Linux packager here. I just got back from holiday so I should have some time soon to fix my overzealous attempt at renovating the go module issues. |
I did build 1.5.3 from source and it works for the most part. I did note that if I click on a tab other than events and then go back to events it no longer populates even though popups continue to occur for new traffic and it appears to continue to work. Possibly just a gui display issue because closing the opensnitch gui and re-opening it causes the events to once again display as expected. I did have to do a systemctl enable and start of the opensnitchd service to get things going. |
As stated on our bugtracker:
|
Version 1.5.7-1 of the |
Thank you to @grawlinson for the quick packaging fix and to @gustavo-iniguez-goya for being so patient when the issue was reported here and for the fantastic work you're doing on opensnitch. |
ok, fantastic news! thanks all |
By the way, the daemon is not stopped upon uninstallation (for both opensnitch and opensnitch-git packages): ~ $ sudo pacman -R opensnitch 1 ✘
checking dependencies...
Packages (1) opensnitch-1.5.5-1
Total Removed Size: 14.46 MiB
:: Do you want to remove these packages? [Y/n]
:: Processing package changes...
(1/1) removing opensnitch [############################################] 100%
:: Running post-transaction hooks...
(1/4) Reloading system manager configuration...
(2/4) Arming ConditionNeedsUpdate...
(3/4) Updating icon theme caches...
(4/4) Updating the desktop file MIME type cache...
~ $ pgrep opensn -a
2004 /usr/bin/python /usr/bin/opensnitch-ui
2037 /usr/bin/opensnitchd -rules-path /etc/opensnitchd/rules
~ $ ls -l /usr/bin/opensnitchd
ls: cannot access '/usr/bin/opensnitchd': No such file or directory This can lead to errors if the user installs the package again (for example if they switch between git and non git version). The new daemon won't start with the error: |
Please, check the FAQ and Known Problems pages before creating the bug report:
https://github.com/evilsocket/opensnitch/wiki/FAQs
https://github.com/evilsocket/opensnitch/wiki/Known-problems
Describe the bug
Installed both opensnitch and opensnitch-git on Manjaro as well as the ebf modules for both and ran the program. In all cases the ui ran but no events were captured. There is no service called opensnitch under systemctl. I ensured all the python support packages were installed and ran a couple of pip workaround commands but nothing resolved the lack of events.
Include the following information:
To Reproduce
Describe in detail as much as you can what happened.
Steps to reproduce the behavior:
Run the program, go to the UI and open the event logs..no events listed.
Post error logs:
No crashes
If the daemon doesn't start:
/var/log/opensnitchd.log
# /usr/bin/opensnitchd -rules-path /etc/opensnitchd/rules
) and post the errors logged to the terminal.[2023-02-05 16:17:13] IMP Starting opensnitch-daemon v1.6.0rc4
[2023-02-05 16:17:13] INF Loading rules from /etc/opensnitchd/rules ...
[2023-02-05 16:17:13] IMP Start writing logs to /var/log/opensnitchd.log
setrlimit() failed with errno=1
[2023-02-05 16:17:13] ERR
unable to load eBPF module (opensnitch.o). Your kernel version (5.19.17-2-MANJARO) might not be compatible.
If this error persists, change process monitor method to 'proc'
[2023-02-05 16:17:13] ERR [eBPF]:
unable to load eBPF module (opensnitch.o). Your kernel version (5.19.17-2-MANJARO) might not be compatible.
If this error persists, change process monitor method to 'proc'
[2023-02-05 16:17:13] WAR error starting ebpf monitor method:
unable to load eBPF module (opensnitch.o). Your kernel version (5.19.17-2-MANJARO) might not be compatible.
If this error persists, change process monitor method to 'proc'
[2023-02-05 16:17:13] WAR Unable to set new process monitor (ebpf) method from disk:
unable to load eBPF module (opensnitch.o). Your kernel version (5.19.17-2-MANJARO) might not be compatible.
If this error persists, change process monitor method to 'proc'
[2023-02-05 16:17:13] WAR Is opensnitchd already running?
[2023-02-05 16:17:13] !!! Error creating queue #0: Error unbinding existing q handler from AF_INET protocol family: operation not permitted
Screenshots
If applicable, add screenshots to help explain your problem. It may help to understand the issue much better.
Additional context
python-protobuf and python-grpcio installed. slugify does not exist in any form.
The text was updated successfully, but these errors were encountered: