ufw on antiX 19 I need help to check

Forum Forums Official Releases antiX-19 “Marielle Franco” ufw on antiX 19 I need help to check

Tagged: 

This topic contains 11 replies, has 3 voices, and was last updated by anticapitalista Nov 13-12:02 pm.

Viewing 12 posts - 1 through 12 (of 12 total)
  • Author
    Posts
  • #28893
    Member
    Avatar
    Yoghi

    Hi guys!

    Someone noticed troubles with ufw 0.36 on antiX 19

    There’s a temporary workaround downgrade iptables libip4tc0 libip6tc0 libiptc0 and libxtables12 to 1.6 from antiX 17 and mark them to hold with apt-mark hold iptables , apt-mark hold libip4tc0 aso but it’s only a temporary workaround.

    After 3 days of investigations I discovered the root cause but I have not enough knowledge of python to discover if it’s an ufw tantrum.

    The problem is that af_packet is loaded as module instead to be built-in, also with module loaded at boot ufw gives the known error.

    To me it’s not too polite, sure not an example of code portability.

    Someone experienced in python could check ufw 0.36 source, so we can discover if the enquiry of built-in modules depends from ufw?

    Thanks a lot indeed!

    Yoghi

    #28917
    Member
    Avatar
    skidoo

    { ok, removed unwanted “cutups” attempted solution }

    • This reply was modified 1 week, 3 days ago by skidoo.
    #28920
    Member
    Avatar
    Yoghi

    Yoghi, on the stock antiX 19 (no fussing with package downgrades)
    the “unable to start ufw” problem seems to be due to a change of syntax
    “–icmp-type blahblah” vs “icmp type blahblah”

    No, on Debian 10 with the same libraries as in antiX 19 instead UFW works flawlessly without workarounds.

    Canonical fan boys told the truth only to Debian.

    Yours is a workaround, as you wrote “(Bear in mind that these affected files are subject to being overwritten during future apt-get updates to uwf and/or firejail packages.)” like downgrading the libraries but at least downgrading the libraries and set them to hold last a bit longer without vanish at the first upgrade.

    I had an old ubuntu account so I asked on launchpad ufw list, they are not so friendly, “why if you don’t use ubuntu are asking here?” but I learnt that the trouble is in ufw 😀

    They supplied me the link to three patches and said that the enquiry of built-in modules was due to make the program running with iptables 1.8

    Cutups! 😀

    I didn’t install nothing, to have a scientific evidence I did the check on Lubuntu 19.10 Debian 10 and antiX-19 with the script check-requirements contained in the original source tarball released without patches in december 2018 ;.D

    The first patch is of march 2019!

    They mess up portability and neither say which modules are required and that they should be built-in.

    It’s needed a real solution which IMHO is not to accomplish ufw which is messing up code portability but a fork.

    Thank anyway for the help.

    Yoghi

    Attachments:
    #29034
    Forum Admin
    anticapitalista
    anticapitalista

    I installed the 4.19.73 64 bit antiX kernel and it does have af_packet.ko (4.9 kernel doesn’t).
    So, does that mean that iptables 1.8 plus ufw must need a 4.19 kernel?
    Does it work properly?

    Thanks for your valuable feedback on this.

    Philosophers have interpreted the world in many ways; the point is to change it.

    #29047
    Member
    Avatar
    Yoghi

    I installed the 4.19.73 64 bit antiX kernel and it does have af_packet.ko (4.9 kernel doesn’t).
    So, does that mean that iptables 1.8 plus ufw must need a 4.19 kernel?
    Does it work properly?

    Thanks for your valuable feedback on this.

    It depends on what do you mean for “does have”.

    Also 4.9.193 has af_packet.ko

    yoghi@ranger:~
    $ ls /lib/modules/4.9.193-antix.1-amd64-smp/kernel/net/packet/
    af_packet_diag.ko af_packet.ko

    Unfortunately Ufw developer arbitrarly stated that modules have to be compiled into kernel (builtin) as written in Ufw README (attached).

    I tried also to load the module but Ufw doesn’t give a … if the module is loaded, it wants that it’s built in kernel.
    It’s an Ufw fault, a lack of portability, on Ufw list to my question they justified this answering that this was the only way they found to make Ufw works with new nf_tables backend used by iptables >= 1.8 but this is a (can I use a Stallman’s word?) bullshit.

    Iptables works without trouble also with dinamically loaded modules, they, IMHO, simply didn’t find a way to load needed modules at boot before Ufw thanks to systemd complexity (rotfl).

    I tried this evening also with Slax which has the bare Debian kernel with af_packet built-in without installing Ufw simply booting the live and launching the check-requirements script included in Ufw source tarball as I did on Lubuntu,19.10, Debian 10.1 and antiX-19, it doesn’t give errors, as it does only on antiX, even if Slax lacks in dependency (python3:any requirements is not fulfilled so if you try to install only Ufw Debian package previously downloaded using dpkg it won’t install due to missing dependencies, installing it with apt and launching it you get no error, it works flawlessly).

    Anyway also if it’s almost sure that it lacks only af_packet compiled statically into kernel (the three tabs comparison already posted is done using cat /lib/modules/$(uname -r)/modules.builtin sorting kernel/net modules (Debian 10.1 standard I used has no kernel/drivers/net as built-in so it wasn’t sure an antiX lack of kernel/drivers/net), this evening I sent an email to Florian Westphal, hoping that my german is still good enough, to have a confirmation that af_packet is the missing piece and asking him if is it possible to have a readme inside iptables source with a complete list of required kernel modules which, until now, is missing but IMHO needed.

    If he answers I’ll let you know immediately.

    P.S. my feedback and help is due, and I too have to thank you for antiX

    #29186
    Member
    Avatar
    Yoghi

    Hi Anti,

    you didn’t explain me what do you mean for does have.

    Westphal didn’t answer, maybe systemd guys think that not systemd guys don’t deserve an answer, yet.

    I did some other checks but I stop here, I’ve no antiX 19 installation so I can’t change kernel I used a live to check and found the workaround of downgrading libraries and set them to hold.

    For sure if you want to see ufw working on antiX 19 with iptables 1.8 you have to upload kernel 4.9 reconfigured with af_packet as builtin, up to you to believe in me or not, to me is the same for 4.19 but I can’t check.

    It’s not systemd related, on CloverOS which is without systemd, without avahi, without dbus but has a kernel 5.2.1 without af_packet builtin checking as I explain in the follow and also installing it with the python programs contained in the tarball works like a charme.
    Unfortunately CloverOS is only 64bit and I’ve still 2 32bit only machine.

    On other kernel I can’t check, if someone can…

    I’ve uploaded here the source package I used for my tries.

    Download it where you prefer

    From a terminal change to the directory were yo have downloaded the tarball

    Extract with tar -xzf ufw_0.36.orig.tar.gz

    Become root

    Change to ufw directory where compatibility test is stored cd ufw-0.36/tests

    Launch the script to check requirements ./check-requirements

    If someone as a system to trash can also install from tarball
    in the main directory there are two programs

    to build issue python setup.py build

    than install with python setup.py install

    On CloverOS after that ufw it’s up and running (if you issue the command ufw enable of course).

    Loading af_packet module doesn’t work, ufw wants it builtin in kernel at least on 4.9 but I suspect that it’s a 4 problem considering that with CloverOS and kernel 5.2.1 it works.

    If someone is able to check on other kernels tha 4.9.193 I gave the instruments and the explanation to check.

    Yoghi

    #29187
    Member
    Avatar
    skidoo

    yoghi, FYI the contents of the pclinux.eu file are identical to the contents of debian buster’s “ufw_0.36.orig.tar.gz” source file
    (linked from this page: https://packages.debian.org/buster/ufw)

    and, by inspecting its companion ufw_0.36-1.debian.tar.xz file, we can note that the ONLY change applied by//for debian is this:
    debian/patch/0001-optimize-boot.patch

    Author: Jamie Strandboge <jamie@canonical.com>
    Description: to improve boot speed when disabled, don't source all of
     ufw-init-functions (which also sources in other files).
    
    Index: ufw-0.35/src/ufw-init
    ===================================================================
    --- ufw-0.35.orig/src/ufw-init
    +++ ufw-0.35/src/ufw-init
    @@ -31,6 +31,12 @@ if [ "$1" = "--datadir" ] && [ -s "$2" ]
     fi
     export DATA_DIR="$datadir"
     
    +# Debian/Ubuntu: small boot speed improvement
    +. "${rootdir}#CONFIG_PREFIX#/ufw/ufw.conf"
    +if [ "$1" = "start" ] && [ "$2" = "quiet" ] && [ "$ENABLED" = "no" ]; then
    +    exit 0
    +fi
    +
     if [ -s "${rootdir}#STATE_PREFIX#/ufw-init-functions" ]; then
         . "${rootdir}#STATE_PREFIX#/ufw-init-functions"
     else

    So, there should be nothing to be learned//gained by building from the pclinux.eu to (re)test.
    Instead, I’m suggesting to just test after rebuilding from the debian source package, with that patch removed.

    edited to add:

    I did that, tested without the patch. No change. Identical result.

    then I returned to a pristine antiX 19 Full and retested.

    sudo ufw enable
    ^–> error blahblah –icmp-type
    sudo ufw enable (try again)
    ^–> Firewall is active and enabled on system startup
    sudo ping 192.168.1.1
    ^–> 17 packets transmitted, 0 received, 100% packet loss, time 534ms
    sudo gufw (click “unlock”, and click ALLOW inbound) then
    sudo ping 192.168.1.1
    ^–v
    64 bytes received from 192.168.1.1 blahblah
    64 bytes received from 192.168.1.1 blahblah
    64 bytes received from 192.168.1.1 blahblah
    64 bytes received from 192.168.1.1 blahblah
    ^C
    — 192.168.1.1 ping statistics —
    9 packets transmitted, 9 received, 0% packet loss, time 164ms
    rtt min/avg/max/mdev = blahblah

    At that point in testing, clearly the firewall was running and was effective.
    The initial failure may be attributable to a timing//timeout issue.

    In any event, contrary to yoghi’s “understanding” of the situation, I suspect that ufw does not (and should not)
    know or care whether a builtin (vs loaded) module provides the AF_PACKET functionality.

    • This reply was modified 4 days, 12 hours ago by skidoo.
    #29194
    Member
    Avatar
    Yoghi

    Skidoo I’m not a coder and I won’t become a coder, I’m a sysadmin certified but limited to a little scripting.

    I tested it on a bunch of distro and with iptables >= 1.8 it worked only on distro with af_packet module compiled as built-in despite if 4.9 or 4.19 kernel.

    On CloverOS it worked only cause, I’ve discovered later, they still use iptables 1.6 in their live.

    It’s pointless.

    Or we try to build an antiX package and mantain it or keep using Debian packet it’s needed to recompile the kernels with af_packet built-in.

    That it’s due to ufw is stated by them answering to my question in ufw list, they weren’t able to make ufw working with iptables 1.8 and they confirmed that to require built-in modules is the only way they found to succeed.

    Up to you what to do now.

    Mantain an antiX ufw package modified as you suggest or recompile all kernels adding af_packet module built-in.

    Keep using Debian package without af_packet built-in in kernel ufw won’t never work in antiX 19 with iptables 1.8 despite the kernel in use.

    Yoghi

    #29195
    Member
    Avatar
    Yoghi

    edited to add:

    I did that, tested without the patch. No change. Identical result.


    then I returned to a pristine antiX 19 Full and retested.

    sudo ufw enable
    ^–> error blahblah –icmp-type

    Sorry Skidoo I forget to say that ufw gives no error at all, never! and I’ve spent days to check, on distro with af_packet monolithic if you prefer this instead of built in.

    I already discovered that after the error if you disable and enable it again it seems that it starts but seems, when you give i.e. reload command you get the error again.

    It shouldn’t give no error at all as on Ubuntu and derivatives, Debian aso.

    I’ve a connection limited to 30GB months I can’t download other 2GB mammoth until november 25th.

    I stop searching.

    • This reply was modified 4 days, 11 hours ago by Yoghi. Reason: missing q in quote closing tag
    #29213
    Member
    Avatar
    Yoghi

    I remembered that I downloaded the last MX 19 beta 3 unfortunately 32 bit cause I have 2 32bit laptop.

    Ufw works flawlessly ootb.

    Or we follow Ufw developer “diktat” or with kernel without af_packet built-in Ufw on antiX 19 won’t never work.

    Sad but true.

    To me it’s (solved)

    • This reply was modified 3 days, 18 hours ago by Yoghi.
    Attachments:
    #29248
    Member
    Avatar
    Yoghi

    Yesterday I found an usb key that I thought lost forever.

    I did a full install of antiX 19 on it and checked some kernel.

    To have ufw working on antiX 19 it’s needed to upgrade the standard 4.9.193-antix1 kernel coming with the iso with kernel 4.19.73-antix1 which has module af_packet compiled as built-in.

    I also tried kernels 5.2.8-antix1 and 5.2.15-antix1, it doesn’t work, it seems, due to lack of IPv6 stack only IPv4 is compiled in kernel.

    The end

    • This reply was modified 3 days, 5 hours ago by Yoghi.
    #29319
    Forum Admin
    anticapitalista
    anticapitalista

    There are new kernels fixing this issue ie with af_packet compiled as built-in.

    However, it doesn’t seem to make any difference when using 4.9 kernels on antiX-19 with ufw.

    Conclusion:
    ufw + 4.9 kernel = issues
    ufw + 4.19.83 and/or 5.2.21 kernel = no issues

    # ufw status 
    Status: active
    # cat /lib/modules/5.2.21-antix.2-amd64-smp/modules.builtin | grep af_packet.ko
    kernel/net/packet/af_packet.ko
    
    • This reply was modified 18 hours, 11 minutes ago by anticapitalista.
    • This reply was modified 18 hours, 9 minutes ago by anticapitalista.

    Philosophers have interpreted the world in many ways; the point is to change it.

Viewing 12 posts - 1 through 12 (of 12 total)

You must be logged in to reply to this topic.