One "catch all" LOGging is still in effect after disabling ALL LOGs in the config

[yarikoptic]

I have a Debian laptop with

bilena# apt policy arno-iptables-firewall
arno-iptables-firewall:
  Installed: 2.1.1a-1
  Candidate: 2.1.1a-1
  Version table:
 *** 2.1.1a-1 900
        600 https://deb.debian.org/debian sid/main amd64 Packages
        600 https://deb.debian.org/debian sid/main i386 Packages
        900 https://deb.debian.org/debian trixie/main amd64 Packages
        900 https://deb.debian.org/debian trixie/main i386 Packages
        100 /var/lib/dpkg/status
     2.1.1-8 100
        100 https://deb.debian.org/debian bookworm/main amd64 Packages
        100 https://deb.debian.org/debian bookworm/main i386 Packages

and needed to monitor dmesg --follow but it was flooded, decided to disable logging

so I set all LOG= targets found in config to 0

```shell bilena# git grep LOG= firewall.conf:# Note: To enable logging of dropped private addresses set RESERVED_NET_LOG=1 firewall.conf:BLOCKED_HOST_LOG=0 firewall.conf:SCAN_LOG=0 firewall.conf:POSSIBLE_SCAN_LOG=0 firewall.conf:INVALID_TCP_LOG=0 firewall.conf:INVALID_UDP_LOG=0 firewall.conf:INVALID_ICMP_LOG=0 firewall.conf:RESERVED_NET_LOG=0 firewall.conf:INET_OUTPUT_DENY_LOG=0 firewall.conf:LAN_OUTPUT_DENY_LOG=0 firewall.conf:LAN_INPUT_DENY_LOG=0 firewall.conf:DMZ_OUTPUT_DENY_LOG=0 firewall.conf:DMZ_INPUT_DENY_LOG=0 firewall.conf:FORWARD_DROP_LOG=0 firewall.conf:LINK_LOCAL_DROP_LOG=0 firewall.conf:ICMP_REQUEST_LOG=0 firewall.conf:ICMP_OTHER_LOG=0 firewall.conf:PRIV_TCP_LOG=0 firewall.conf:PRIV_UDP_LOG=0 firewall.conf:UNPRIV_TCP_LOG=0 firewall.conf:UNPRIV_UDP_LOG=0 firewall.conf:IGMP_LOG=0 firewall.conf:OTHER_IP_LOG=0 firewall.conf:ICMP_FLOOD_LOG=0 firewall.conf:BROADCAST_TCP_NOLOG="" firewall.conf:#BROADCAST_UDP_NOLOG="67 68" firewall.conf:HOST_DENY_TCP_NOLOG="" firewall.conf:HOST_DENY_UDP_NOLOG="" firewall.conf:HOST_DENY_IP_NOLOG="" firewall.conf:HOST_DENY_ICMP_NOLOG="" firewall.conf:HOST_REJECT_TCP_NOLOG="" firewall.conf:HOST_REJECT_UDP_NOLOG="" firewall.conf:DENY_TCP_NOLOG="" firewall.conf:DENY_UDP_NOLOG="" firewall.conf:REJECT_TCP_NOLOG="" firewall.conf:REJECT_UDP_NOLOG="" plugins/mac-address-filter.conf:MAC_ADDRESS_LOG=0 plugins/parasitic-net.conf:PARASITIC_NET_DENY_LOG=0 plugins/pptp-vpn.conf:PPTP_VPN_DENY_LOG=0 ```

But I still have one last one LOG left -- it seems there is no variable for it in the config? or that OTHER_IP_LOG is not in effect?

bilena# iptables -L INPUT -n -v 
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 5383 1797K BASE_INPUT_CHAIN  0    --  *      *       0.0.0.0/0            0.0.0.0/0           
  798  240K INPUT_CHAIN  0    --  *      *       0.0.0.0/0            0.0.0.0/0           
  798  240K HOST_BLOCK_SRC  0    --  *      *       0.0.0.0/0            0.0.0.0/0           
  798  240K SPOOF_CHK  0    --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 VALID_CHK  0    --  ppp+   *       0.0.0.0/0            0.0.0.0/0           
    0     0 EXT_INPUT_CHAIN !1    --  ppp+   *       0.0.0.0/0            0.0.0.0/0            ctstate NEW
    0     0 EXT_INPUT_CHAIN  1    --  ppp+   *       0.0.0.0/0            0.0.0.0/0            ctstate NEW limit: avg 60/sec burst 100
    0     0 EXT_ICMP_FLOOD_CHAIN  1    --  ppp+   *       0.0.0.0/0            0.0.0.0/0            ctstate NEW
  798  240K POST_INPUT_CHAIN  0    --  *      *       0.0.0.0/0            0.0.0.0/0           
  312 83821 LOG        0    --  *      *       0.0.0.0/0            0.0.0.0/0            limit: avg 1/sec burst 5 LOG flags 0 level 6 prefix "AIF:Dropped INPUT packet: "
  798  240K DROP       0    --  *      *       0.0.0.0/0            0.0.0.0/0      

[arnova]

This is by design: This is a catch-all rule on the input-chain which, when properly configured, should never be hit. If it does, it normally means there's a network-interface missing in the configuration.

[yarikoptic]

oh, makes so much sense... I will try to remember that. May be LOG could state that e.g. AIF:Dropped INPUT (check config) packet: or alike? but overall I think the issue is resolved and someone might find an answer here ;)