Error while creating queue #0: Error opening Queue handle: protocol not supported

[ItsDrike]

Describe the bug
I seem to be unable to start the opensnitchd daemon. I tried using both systemctl start opensnitchd and just the opensnitchd command, but neither worked:

The warning suggest that I already have an opensnitchd instance running, but this isn't the case (at least not that I'm aware of, I tried running killall opensnitchd, which returned me error of no such process)

To Reproduce
Steps to reproduce the behavior:

1. Install opensnitchd on Arch distribution via AUR repository opensnitch
2. Run systemctl start opensnitchd or opensnitchd
3. Get an error message of Error while creating queue #0: Error opening Queue handle: protocol not supported

Post error logs:
Output of journalctl -xeu opensnitch.service:

If the daemon doesn't start:
Whole /var/log/opensnitchd.log file content: http://ix.io/3mEB

OS (please complete the following information):

• OS: Arch Linux
• Window Manager: KDE
• Kernel version: 5.12.2-arch1-1
• Opensnitch Version: opensnitch 1.3.6-2

[gustavo-iniguez-goya]

Hi @ItsDrike ,

This error usually indicates that your kernel has no support for NFQUEUE.
Verify it with the following command:

$ grep -E "(NFT|NETLINK|NFQUEUE) /boot/config-$(uname -r)"
CONFIG_NFT_QUEUE=y
CONFIG_NETFILTER_NETLINK_QUEUE=y
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=y

You also need the following modules to be loaded:

$ lsmod | grep -i nfqueue
xt_NFQUEUE             16384  4
x_tables               53248  20 xt_conntrack,nft_compat,xt_LOG,xt_multiport,xt_tcpudp,xt_addrtype,xt_CHECKSUM,xt_recent,xt_nat,ip6t_rt,xt_set,ip6_tables,ipt_REJECT,ip_tables,xt_limit,xt_hl,xt_MASQUERADE,ip6t_REJECT,xt_NFQUEUE,xt_mark

Also don't launch opensnitchd as a regular user, it needs to run as root: ~# opensnitchd -rules-path /etc/opensnitchd/rules

[ItsDrike]

Thanks for response @gustavo-iniguez-goya

I am running the stock arch kernel (5.12.2-arch1-1), I know that opensnitchd was working on my previous arch install a couple months ago, I suppose it is possible that the support was removed from the kernel?

I tried running the first command, but it didn't seem to do much, I assume you meant grep -E "(NFT|NETLINK|NFQUEUE)" /boot/config-$(uname -r), rather than marking the path as a part of the regular expression? However running that wasn't successful either, since I don't have that file in my filesystem. I am not running any custom kernel, just the stock one.

The second command ran successfully, but it didn't find any results, implying that the support is probably not built in, here's the screenshot:

Is there some dkms or something similar to add support for this into the stock arch kernel? I wouldn't like to have to compile the kernel manually for this machine.

I didn't realise I ran the opensnitchd as regular user, thanks for reminding me, however running it as root didn't produce a different output

[gustavo-iniguez-goya]

I assume you meant grep -E "(NFT|NETLINK|NFQUEUE)" /boot/config-$(uname -r),

yes, sorry O:)

Anyways, I see that the command didn't run correctly, it didn't find your kernel config.

Check if there's a config-* file for your kernel 5.12.2 in /boot, if not, check if /proc/config.gz exists, and if it doesn't exist try loading it with modprobe configs, and then execute again zgrep -E "(NFT|NETLINK|NFQUEUE)" /proc/config.z .

Are you using a special kernel? like a hardened or minimal kernel or something like that?

[ItsDrike]

Are you using a special kernel? like a hardened or minimal kernel or something like that?

As I said, I am just using the stock arch kernel (linux package in pacman)

I did not have any config files in /boot, but I did have /proc/config.gz.

This is the output of grep -E "(NFT|NETLINK|NFQUEUE)" /proc/config.gz:

CONFIG_COMPAT_NETLINK_MESSAGES=y
CONFIG_NETFILTER_NETLINK=m
CONFIG_NETFILTER_NETLINK_ACCT=m
CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NETFILTER_NETLINK_LOG=m
CONFIG_NETFILTER_NETLINK_OSF=m
CONFIG_NF_CT_NETLINK=m
CONFIG_NF_CT_NETLINK_TIMEOUT=m
CONFIG_NF_CT_NETLINK_HELPER=m
CONFIG_NETFILTER_NETLINK_GLUE_CT=y
CONFIG_NFT_NUMGEN=m
CONFIG_NFT_CT=m
CONFIG_NFT_FLOW_OFFLOAD=m
CONFIG_NFT_COUNTER=m
CONFIG_NFT_CONNLIMIT=m
CONFIG_NFT_LOG=m
CONFIG_NFT_LIMIT=m
CONFIG_NFT_MASQ=m
CONFIG_NFT_REDIR=m
CONFIG_NFT_NAT=m
CONFIG_NFT_TUNNEL=m
CONFIG_NFT_OBJREF=m
CONFIG_NFT_QUEUE=m
CONFIG_NFT_QUOTA=m
CONFIG_NFT_REJECT=m
CONFIG_NFT_REJECT_INET=m
CONFIG_NFT_COMPAT=m
CONFIG_NFT_HASH=m
CONFIG_NFT_FIB=m
CONFIG_NFT_FIB_INET=m
CONFIG_NFT_XFRM=m
CONFIG_NFT_SOCKET=m
CONFIG_NFT_OSF=m
CONFIG_NFT_TPROXY=m
CONFIG_NFT_SYNPROXY=m
CONFIG_NFT_DUP_NETDEV=m
CONFIG_NFT_FWD_NETDEV=m
CONFIG_NFT_FIB_NETDEV=m
CONFIG_NFT_REJECT_NETDEV=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
CONFIG_NFT_REJECT_IPV4=m
CONFIG_NFT_DUP_IPV4=m
CONFIG_NFT_FIB_IPV4=m
CONFIG_NFT_REJECT_IPV6=m
CONFIG_NFT_DUP_IPV6=m
CONFIG_NFT_FIB_IPV6=m
CONFIG_NFT_BRIDGE_META=m
CONFIG_NFT_BRIDGE_REJECT=m
CONFIG_NETLINK_DIAG=m
CONFIG_ETHTOOL_NETLINK=y
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
CONFIG_SCSI_NETLINK=y
CONFIG_THERMAL_NETLINK=y
CONFIG_QUOTA_NETLINK_INTERFACE=y

The parameters that you specified are all set as m (kernel module I assume):

CONFIG_NFT_QUEUE=m
CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m

which would imply that they are supported?

[gustavo-iniguez-goya]

No, that's good, that means that the kernel is compiled with support for those modules.

Ok, can you add the following iptables rule and check if the modules are loaded automatically?

~# iptables -t mangle -I OUTPUT -m conntrack --ctstate NEW,RELATED -j NFQUEUE --queue-num 111 --queue-bypass
~# lsmod | grep -i nfqueue
xt_NFQUEUE             16384  19
x_tables               53248  13 xt_conntrack,nft_compat,xt_multiport,xt_tcpudp,xt_addrtype,xt_CHECKSUM,xt_nat,xt_set,xt_SECMARK,ip_tables,xt_MASQUERADE,xt_NFQUEUE,xt_mark

If it works and the modules are loaded, then relaunch opensnitchd.

[ItsDrike]

lsmod | grep -i nfqueue didn't return anything (I've already ran that in my 2nd post - see photo).

As for the iptables rule, it returned an error message: 'Couldn't load match `conntrack':No such file or directory'

[gustavo-iniguez-goya]

mmh, try loading the modules manually:

~# modprobe xt_conntrack
~# modprobe xt_NFQUEUE
~# iptables -t mangle -I OUTPUT -m conntrack --ctstate NEW,RELATED -j NFQUEUE --queue-num 111 --queue-bypass

usually these modules are loaded on demand when a rule that needs them is inserted.

[ItsDrike]

I tried running the modprobe commands, but they failed with message of module not found in directory /lib/modules/5.12.2-arch1-1:

[gustavo-iniguez-goya]

Sorry @ItsDrike , I'm running out of ideas. Could seek for help in the Arch forums? I think they'll help you better there.

You can search anyway for the modules to see if they are even installed: find /lib/modules/ -name 'xt_*.ko'

[ItsDrike]

Thank you for your help, the issue have been resolved on arch forums. It was actually just a matter of having updated the kernel without rebooting.

I would've found this out earlier but I was only trying the lsmod | grep -i nfqueue and find /lib/modules/ -name 'xt_*.ko' commands. And since those didn't produce any results, I didn't even think to try the modeprobe after rebooting.

On the forums, I was suggested to instead use: find /lib/modules -iname '*nf*queue*' after which I found out that the modprobe commands are working as they should and the opensnitch daemon started without problems.