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