AFWall+ 4.1.0: NFLOG logs missing for blocked apps in blacklist mode

[Desparatus]

AFWall+ 4.1.0: NFLOG firewall logs missing in blacklist mode, work in whitelist mode

Summary

AFWall+ 4.1.0 can correctly block traffic and log it with NFLOG in whitelist mode, but the same blocked application does not produce firewall log entries in blacklist mode.

This was reproduced on the same device, same AFWall+ version, same application, same UID, same Wi-Fi network, and same NFLOG backend.

The firewall blocking itself works in both modes. The difference is specifically whether the blocked packet is written to AFWall+'s LogData database.

Environment

• AFWall+: 4.1.0
• versionCode: 20260801
• Android: 14 Go Edition
• Android userspace ABI: 32-bit ARM / armeabi-v7a
• ro.product.cpu.abi: armeabi-v7a
• ro.product.cpu.abilist: armeabi-v7a,armeabi
• ro.product.cpu.abilist64: empty
• /system/bin/linker64: does not exist
• Kernel: 4.19.191
• Root: Magisk 30.7 / version 30700
• Logging target: NFLOG

Test application:

• Package: eu.darken.sdmse
• UID: 10185
• App: SD Maid SE

The device is using Wi-Fi during the reproduction.

Blacklist mode reproduction

Active profile:

AFWallPrefs

BlockMode=blacklist

AFWall generated the expected rules for UID 10185:

-A afwall-3g-home -m owner --uid-owner 10185 -j afwall-3g-home-reject
-A afwall-wifi-lan -m owner --uid-owner 10185 -j afwall-wifi-lan-reject
-A afwall-wifi-wan -m owner --uid-owner 10185 -j afwall-wifi-wan-reject

Logs.db was cleared before the test:

LogData BEFORE = 0

The NFLOG daemon was running on group 40:

/data/user/0/dev.ukanth.ufirewall/app_bin/nflog

and:

40 <nflog-pid> ...

After launching SD Maid and allowing it to attempt network access:

afwall-wifi-wan-reject:
8 packets / 480 bytes NFLOG
8 packets / 480 bytes REJECT

So the packet definitely hit the AFWall reject chain and NFLOG rule.

However:

LogData AFTER = 0

No SD Maid log entries were created.

The complete clean blacklist reproduction is attached as:

afwall_blacklist_reproduction.txt

Whitelist mode reproduction

Active profile:

AFWallProfile1

BlockMode=whitelist

SD Maid remained non-whitelisted and was therefore blocked.

Logs.db was cleared before the test:

LogData BEFORE = 0

After launching SD Maid:

afwall-wifi-wan-reject:
6 packets / 360 bytes NFLOG
6 packets / 360 bytes REJECT

This time AFWall created log entries:

LogData AFTER = 2

The two rows were:

2|10185|SD Maid SE|TCP|50206|140.82.112.6|60|192.168.0.46|443|1787983244144||0
1|10185|SD Maid SE|TCP|50206|140.82.112.6|60|192.168.0.46|443|1787983244129||0

The complete clean whitelist reproduction is attached as:

afwall_whitelist_reproduction.txt

Independent NFLOG testing

The bundled nflog binary was also tested independently of AFWall's normal Java-side logging path.

Running:

/data/user/0/dev.ukanth.ufirewall/app_bin/nflog 40

with stdin kept open successfully received NFLOG traffic and produced parsed output such as:

AFWTEST IN= OUT=wlan0 SRC=192.168.0.46 DST=192.168.0.245
PROTO=TCP SPT=8022 DPT=58348 UID=10182

A separate controlled {AFL} NFLOG test successfully populated AFWall's Logs.db with 50 records.

This demonstrates that the following components work:

• iptables NFLOG target
• kernel NFLOG support
• NFLOG group 40
• AFWall's bundled nflog binary
• delivery of NFLOG data to nflog
• nflog parsing/output
• AFWall LogService
• AFWall's log parser/database path

The failure therefore appears to depend on the AFWall profile/mode rather than a general lack of NFLOG support.

Additional observation

AFWall+'s 4.1.0 source contains a log-suppression path in LogService.shouldSuppressLog() that examines the interface UID lists such as AllowedPKGWifi_UIDS.

In blacklist mode, the same interface UID list is used as part of generating reject rules. This creates a possible semantic mismatch:

blacklist mode:
UID in interface list -> firewall rejects UID

log suppression:
UID in interface list -> possible log suppression

Because the blacklist-mode packet is successfully rejected and reaches NFLOG but produces no LogData row, this shouldSuppressLog() / interface-UID interaction is my leading hypothesis for the cause.

I have not proven that this exact branch is responsible, so this should be treated as a suspected cause rather than a confirmed one.

Expected behavior

Blocked traffic should be logged consistently in both blacklist and whitelist modes.

Actual behavior

With AFWall+ 4.1.0:

Blacklist mode

blocked packet
→ NFLOG rule hit
→ REJECT rule hit
→ no LogData entry

Whitelist mode

blocked packet
→ NFLOG rule hit
→ REJECT rule hit
→ LogData entry created

Reproduction steps

Blacklist

1. Select the AFWallPrefs blacklist profile.
2. Ensure eu.darken.sdmse is blocked.
3. Clear AFWall's firewall log database.
4. Confirm BlockMode=blacklist.
5. Launch SD Maid SE.
6. Allow it to attempt network access.
7. Observe the afwall-wifi-wan-reject NFLOG/REJECT counters increase.
8. Observe that no corresponding SD Maid row appears in AFWall's firewall log.

Whitelist

1. Select the AFWallProfile1 whitelist profile.
2. Leave eu.darken.sdmse non-whitelisted.
3. Clear AFWall's firewall log database.
4. Confirm BlockMode=whitelist.
5. Launch SD Maid SE.
6. Allow it to attempt network access.
7. Observe the same NFLOG/REJECT behavior.
8. Observe that SD Maid entries now appear in AFWall's firewall log.

Attached files

• afwall_blacklist_reproduction.txt

  • AFWall 4.1.0 version information
  • blacklist mode verification
  • SD Maid UID and generated rules
  • NFLOG daemon/group state
  • clean reproduction
  • NFLOG/REJECT counters
  • LogData count and recent rows

• afwall_whitelist_reproduction.txt

  • AFWall 4.1.0 version information
  • whitelist mode verification
  • SD Maid UID
  • clean reproduction
  • NFLOG/REJECT counters
  • resulting SD Maid LogData rows

I can also provide separate exported AFWall rule files for both profiles.

Additional testing note

SD Maid has root access, but the tested network traffic was associated with UID 10185, and the AFWall rules explicitly matched UID 10185. The reproduction therefore does not depend on SD Maid's root capability.

The issue appears reproducible on this device with AFWall+ 4.1.0 and is specifically associated with blacklist-mode logging.

afwall_whitelist_reproduction.txt
afwall-backup-whitelist.json
afwall_blacklist_reproduction.txt
afwall-backup-blacklist.json