AFWall+ tells me that "Unknown(-100)" is generating traffic, but that app UID is not in the list

[ewheelerinc]

AFWall+ tells me that "Unknown(-100)" is generating traffic:

What does a negative UID mean, particularly when the UID is not listed for whitelist?

How can I whitelist a UID that generates traffic but isn't listed, even when I select "Show all apps" ?

[modernman1]

I am getting this as well on brand new OnePlus 9Pro new install
The application log details shows sometime (r_rmnet_data0) othertimes (rmnet_data2)
Sometimes it is scanning LAN addresses, othertimes it's trying to reach BEIJING, CHINA!

[5A52]

Same here. In case AFWall is enabled, there is no network in chrooted Arch linux on the phone. In AFWall log I can see Unknown(-100), and/or "Deleted app", when trying to ping or ssh something.

[Double00user]

I have the same issue [-100] Unknown, I just can't find the application in the list can you please fix this issue. Or allow to change setting for the application in log list.

I am using paid version.

[berbant]

The same. If you grant full network access to dev.afwall.special.kernel (AppID: -11) this message will no longer be displayed.

[9jS2PL5T]

Same for me. Hint by @berbant is working, but would be nice to know what Unknown (-100) is and don't grant access for (-11) to did not notified anymore.

[IronGibbet]

Thanks @berbant now the switch from WiFi to mobile data is working for me. It'd still be nice to have a specific entry for that.

[angela-d]

Same for me. Hint by @berbant is working, but would be nice to know what Unknown (-100) is and don't grant access for (-11) to did not notified anymore.

It doesn't notify anymore because you're letting those mysterious connections connect to their destination, defeating the purpose of a firewall.

Why would you give something internet access if you don't know what it is?

If your day to day usage is unaffected by -100 & -11 being blocked, you should leave them both blocked and unable to get any network access.

The logs tell you activity happened, they aren't necessarily indicative of a "problem" unless an app isn't connecting to the web as it should.

[resolutecake]

The cause of this is a race condition in the app

in Log new view, entries appear as Unknown(-100)
in Log old view, entries appear as AppID: -1, App Name: [blank]

affected are a dozen or so packets that are detected before the app can determine an App ID
It does appear for VPN initial packets, and for the Android Connectivity Check inside vpn

I believe it appeared around 3.5.3 and appears in all later versions

IMPACT:
browsers produce ERR_NAME_NOT_RESOLVED for Wi-Fi and VPN
That is because the Android Connectivity Check fails for some reason
Therefore, DNS privacy fails to function

GET-AROUND: Do not use VPN :)

[resolutecake]

Here’s a script that helped me out:
can be placed at /data/script
and added to AFWall+ as custom script ./data/script

#!/system/bin/sh
# License: ISC
# /data/data/com.termux/files/usr/bin/nano /data/tether
# hotspot to wan to work
# if not present, hotspot clients cannot reach the Internet
unset RULE CHAIN
RULE=(--match owner --uid-owner 1052 --jump RETURN)
CHAIN=afwall-3g-home
if ! iptables --check $CHAIN "${RULE[@]}"; then
  iptables --insert $CHAIN "${RULE[@]}"
fi
RULE=(--match owner --uid-owner 1052 --jump RETURN)
CHAIN=afwall-wifi-wan
if ! iptables --check $CHAIN "${RULE[@]}"; then
  iptables --insert $CHAIN "${RULE[@]}"
fi
# Android Connectivity Check to work inside vpn
# bug in AFWall+ 3.6dev causes these to be blocked as -100 -1
RULE=(--match owner --uid-owner 1073 --jump RETURN)
CHAIN=afwall-vpn
if ! iptables --check $CHAIN "${RULE[@]}"; then
  iptables --insert $CHAIN "${RULE[@]}"
fi
# OpenVPN Connect userID prevent blocking: goes over Wi-Fi but not to lan or wan
# bug in AFWall+ 3.6dev causes these to be blocked as -100 -1
RULE=(--match owner --uid-owner 10249 --jump RETURN)
CHAIN=afwall-wifi
if ! iptables --check $CHAIN "${RULE[@]}"; then
  iptables --insert $CHAIN "${RULE[@]}"
fi
unset RULE CHAIN

[resolutecake]

@ukanth This is THE BUG TO FIX for 3.6

random blocking of initial packets is not a problem when communication is retried
but it is a problem for DNS privacy, and this is lots of work to troubleshoot when a Wi-Fi Captive Portal is involved, that can have all sorts of peculiar routing involving local and remote networks

If the initial 1073 DNS request for DNS privacy fails, connectivity check fails and Internet may not be reachable
The way Android is designed, an initial DNS request must succeed for DNS privacy to work. There is an IPv4 and an IPv6 but requests are not retried

From my research, the AFWall+ set-up of user IDs is delayed and all packets are blocked before this is finished. Therefore, the dozen or so first packets for every interface are blocked no matter how AFWall+ is configured

[resolutecake]

@ukanth

Log Symptoms:
The problem is packets being associated with App ID -1 Unknown, which in new log appears as -100
— victim apps are Android Connectivity Check and OpenVPN Connect
— this can obviously be any app since the cause is unknown

Duration
Typically this -1 state only persists for about 3 seconds after an interface change
— because of retry, these dozen or so blocked packets do not become a problem

Persistence
With OpenVPN Connect, the -1 state can be persistent

Private DNS
— c Android connectivity check is retried after 7 seconds, for possibly up to a minute
—d Private DNS is not attempted if no connectivity check has succeeded
—e Private DNS gives up after about 20 s, providing the bars with a question mark. in Settings — Internet, it displays Can’t Connect under its menu item

Complete Failure
Once Private DNS gives up, it’s game over until another interface comes up. Connectivity checks stop, too

[evermind-zz]

Some news on this issue?

I am also affected by this error (using version 3.6), which version was not affected?

[evermind-zz]

I could solve it for me like that. Marking the packets!

index cdba365a..4b8ee9b0 100644
--- a/app/src/main/java/dev/ukanth/ufirewall/Api.java
+++ b/app/src/main/java/dev/ukanth/ufirewall/Api.java
@@ -426,6 +426,7 @@ public final class Api {
         } else {
             for (Integer uid : uids) {
                 if (uid != null && uid >= 0) {
+                    cmds.add("-A " + chain + " -m owner --uid-owner " + uid + " -j CONNMARK --set-mark 0x1234");
                     cmds.add("-A " + chain + " -m owner --uid-owner " + uid + action);
                 }
             }
@@ -488,6 +489,9 @@ public final class Api {
     }
 
     private static void addRejectRules(List<String> cmds) {
+        // allow all 0x1234 marked packets
+        cmds.add("-A " + AFWALL_CHAIN_NAME + "-reject" + " -m connmark --mark 0x1234 -j ACCEPT");
+
         // set up reject chain to log or not log
         // this can be changed dynamically through the Firewall Logs activity

I don't know if thats the right way to do it - but it works

[qumuq-til]

@evermind-zz Didn't quite work for me. I still see some "unknown -100" process is doing 0.0.0.0:0 -> 241.239.59.45:0, protocol 128 on eth after I applied @resolutecake 's script which unmasked process 1073 for me.

[evermind-zz]

@qumuq-til
I think I also got still some -100 but with my patch I could avoid a major slowdown within apps. I always fought something with the wifi is quite strange but no it was the firewall.

Maybe you could try marking all packets when they enter the filter in the prerouting table somehow reading the uid they enter and using it as a mark. Later in the afwall-reject table log them. In theory this may show us the process the packet originated from. I have no idea how the proper iptables syntax is or if this is even possible

[resolutecake]

There is an app “Rethink: DNS + Firewall + VPN” com.celzero.bravedns in F-Droid
that has a similar firewall to AFWall+
— because Rethink uses the newer Android VPN api, it does not require root
— Rethink integrates WireGuard, a newer VPN technology, so firewall and VPN can be used simultaneously despite only one VPN app can be active
— Rethink has its own DNS privacy, which in Android up to at least version 12 is poorly implemented causing problems and unreliable behavior

This problem with random packets being blocked by AFWall+ causing DNS Privacy, Internet connectivity and any random app to fail is difficult to fix. It is likely never going to be fixed. I have suggested what the fix is but it is a huge amount of work, effectively a complete rewrite. And the result is an AFWall+ app that still requires root

The alternative are these random patches disabling some aspect of AFWall+ making a very specific situation work better

[resolutecake]

Detecting what process submitted a packet is really, really difficult. Even if you spend weeks of programming for a particular operating system it is not 100% reliable. one-packet udp connections like QUIC http/3 are especially difficult: once you see the packet, the process may no longer exist. udp listeners may receive everything and then do in-process filtering so it cannot be determined what the process is receiving or listening for

But iptables and all other packet filtering I have seen can filter on uid if a kernel module is loaded. So 100s of rules can be created, one for each uid, that manually logs what uid was filtered. This will always work. A typical operating system will only have 100s of users, Android maybe 300. User id is otherwise often 32-bit number: 4 billion

Android 12+ has often removed iptables logging depending on how the kernel was compiled. Instead counters could be used

AFWall+ features some tricks so its logging works even if logging is not available. By aligning with what AFWall+ is already doing, logging of uid can be made to work