oxidising 1 Posted ... I'm running Eddie 2.16.3 installed from AUR on Manjaro with kernel 4.18.5 and I'm finding that network lock takes a long time to apply all the rules required. From the logs : 2018.09.05 11:46:39 - Shell(15) of '/usr/sbin/iptables', 1 args: '-P INPUT ACCEPT'; 2018.09.05 11:46:40 - Shell(15) done in 297 ms, exit: 0 2018.09.05 11:46:40 - Shell(16) of '/usr/sbin/iptables', 1 args: '-P FORWARD ACCEPT'; 2018.09.05 11:46:40 - Shell(16) done in 270 ms, exit: 0 ... 2018.09.05 11:52:32 - Shell(1336) of '/usr/sbin/ip6tables', 1 args: '-I OUTPUT 1 -d 2a0d:5600:2:5:5200:5517:2b3b:f9b6 -j ACCEPT'; 2018.09.05 11:52:32 - Shell(1336) done in 263 ms, exit: 0 2018.09.05 11:52:32 - Shell(1337) of '/usr/sbin/ip6tables', 1 args: '-I OUTPUT 1 -d 2a0d:5600:2:5:cf41:c8d8:2e78:17b2 -j ACCEPT'; 2018.09.05 11:52:32 - Shell(1337) done in 260 ms, exit: 0 As you can see this takes a long time (around 6 minutes) with iptables version 1.6.2. At the moment I've got a workaround by just backing up / restoring the iptables rules using iptables-save > iptables_rules_AirVPN.txt iptables-restore < iptables_rules_AirVPN.txt This change is immediate but I understand that this isn't great as things will change. Anyone else encountered similar? Quote Share this post Link to post
Fezenari 1 Posted ... I've got exactly the same thing on my Manjaro, and it started just yesterday. Quote Share this post Link to post
monorail 1 Posted ... Same issue here (Manjaro Xfce, kernel 4.18.6-1). I have disabled network lock for now and hope for a quick fix. Quote Share this post Link to post
Staff 9972 Posted ... @oxidising Hello!We see that iptables is incredibly slow in your system to add a rule (from 260 to 300 milliseconds for each rule according to the output you sent us). Do you run UFW? https://wiki.manjaro.org/index.php?title=UFW_%26_GUFW Kind regards Quote Share this post Link to post
go558a83nk 362 Posted ... I had this problem with a mint vm at one time. I scratched that vm and made a new one and eddie was fast again. It's a mystery. Quote Share this post Link to post
Staff 9972 Posted ... Hello! If you enter an iptables rule from a command line interface as root, is the command faster or equally slow? Kind regards Quote Share this post Link to post
Fezenari 1 Posted ... I do not have ufw installed.iptables rule entered form terminal is fast.It looks like every shell command from Eddie is slow, even these: . 2018.09.11 21:05:33 - Shell(9) of '/usr/sbin/openvpn', 1 args: '--version'; . 2018.09.11 21:05:33 - Shell(9) done in 460 ms, exit: 1, out: 'OpenVPN 2.4.6 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 24 2018 . 2018.09.11 21:05:33 - library versions: OpenSSL 1.1.0i 14 Aug 2018, LZO 2.10 . 2018.09.11 21:05:33 - Originally developed by James Yonan . 2018.09.11 21:05:33 - Copyright (C) 2002-2018 OpenVPN Inc <sales@openvpn.net> . 2018.09.11 21:05:33 - Compile time defines: enable_async_push=no enable_comp_stub=no enable_crypto=yes enable_crypto_ofb_cfb=yes enable_debug=yes enable_def_auth=yes enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=yes enable_fragment=yes enable_iproute2=yes enable_libtool_lock=yes enable_lz4=yes enable_lzo=yes enable_management=yes enable_multihome=yes enable_pam_dlopen=no enable_pedantic=no enable_pf=yes enable_pkcs11=yes enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_small=no enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=yes enable_werror=no enable_win32_dll=yes enable_x509_alt_username=yes with_aix_soname=aix with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_sysroot=no' . 2018.09.11 21:05:33 - Shell(10) of '/usr/sbin/ssh', 1 args: '-V'; . 2018.09.11 21:05:34 - Shell(10) done in 406 ms, exit: 0, err: 'OpenSSH_7.8p1, OpenSSL 1.1.0i 14 Aug 2018' . 2018.09.11 21:05:34 - Shell(11) of '/usr/sbin/stunnel', 1 args: '-version'; . 2018.09.11 21:05:34 - Shell(11) done in 386 ms, exit: 0, err: 'stunnel 5.48 on x86_64-pc-linux-gnu platform Quote Share this post Link to post
rustintimberlake 13 Posted ... In Eddie, go to Preferences > Networking and set 'Layer IPv6' to 'Block'.Save and restart Eddie. Quote Share this post Link to post
monorail 1 Posted ... If I run Eddie from the command line instead of using Eddie-GUI I get the same issue: no connection possible with network lock enabled. Takes forever and nothing happens. Only difference is that I can stop the command line version, Eddie-GUI will just crash an a reboot is needed to get it running again. Quote Share this post Link to post
oxidising 1 Posted ... Hello! If you enter an iptables rule from a command line interface as root, is the command faster or equally slow? Kind regards Sorry for the slow reply. 2018.09.18 20:22:52 - Shell(54) of '/usr/sbin/iptables', 1 args: '-A OUTPUT -s 192.168.0.0/16 -d 192.168.0.0/16 -j ACCEPT'; 2018.09.18 20:22:52 - Shell(54) done in 403 ms, exit: 0 sudo perf stat iptables -A OUTPUT -s 192.168.0.0/16 -d 192.168.0.0/16 -j ACCEPT 0.003262772 seconds time elapsed So when I apply the rule it only takes around 3 ms instead of around 400 ms. I'm not running UFW. In Eddie, go to Preferences > Networking and set 'Layer IPv6' to 'Block'. Save and restart Eddie. This has no effect on the time it takes to apply the rules for me. If I run Eddie from the command line instead of using Eddie-GUI I get the same issue: no connection possible with network lock enabled. Takes forever and nothing happens. Only difference is that I can stop the command line version, Eddie-GUI will just crash an a reboot is needed to get it running again. In the end it does finish applying the rules (you can see it in the Logs tab of Eddie if you enable logging under settings). If you let it finish and then use the iptables-save / iptables-restore commands I showed in my first post you can use this as a temporary workaround and still have a (kind-of) working network lock. Quote Share this post Link to post
Fezenari 1 Posted ... Eddie 2.17beta (2.17.1) sure made life easier, now network lock executes only one shell command on activation, and it is tolerable now.Thanks! Quote Share this post Link to post
freedom23 3 Posted ... This problem still persists (for me) in Manjaro, even with Eddie version 2.17.2Is the network lock faster for the other users who reported about this issue, now? (I wonder is there something in the settings I have missed?) *Also reading the the selected best answer:Eddie 2.17beta (2.17.1) sure made life easier, now network lock executes only one shell command on activation, and it is tolerable now. --This is not happening on Eddie 2.17.2 running on Manjaro XFCE, Eddie is still issuing over 1000 shell commands... that take about 10 minutes on this low-end linux-box to complete. Quote Share this post Link to post
frank64 2 Posted ... I can also confirm this problem with a clean (and updated) Manjaro KDE installation. With the Network lock enabled at start-up, Eddie executes a large number (at least 1000) of iptable commands, each taking over 300ms. Whilst it is applying these commands, I cannot connect to a server, I cannot de-activate the network lock, and I cannot close eddie. Basically, eddie becomes unresponsive and unusable, and I have to reboot the system I am using 2.17.2 (but have also tried the latest stable). Thanks for any help/advice. (By the way, all is well on Debian Stable and Mint 19.1). 1 freedom23 reacted to this Quote Share this post Link to post
techterrain 4 Posted ... Reporting in with another replication of this error on latest Manjaro (XFCE). Also, due the network lock not working correctly, some of the rules persist after the end of the session, which causes connection issues in the local network. 3 freedom23, LZ1 and encrypted reacted to this Quote Share this post Link to post
***** 1 Posted ... This started happening few months ago on my Mint 19.1 running kernel 4.15.* I thought it was triggered by one of the kernel updates, but could not resolve it. Running Eddie 2.16.3, I updated to 2.17.2, but it was the same behavior and could not get it to apply network lock via new feature (build iptables-save format and apply directly), it just worked the same as 2.16.3. So I downgraded back to 2.16.3 and when playing around with it, I disconnected computer from network (WiFi) which I normally never do. I noticed that in this state, the network lock would be applied in under 10 seconds, compared to 180 seconds when computer is connected to WiFi. 1 freedom23 reacted to this Quote Share this post Link to post