Linux Mint verbindet sich nicht mit LineageOS-Hotspot

thegustavo · 8. November 2022 um 21:26

Hallo zusammen,

ich habe mir ein feines neues Notebook gekauft - ein HP Envy x360 convertible
Nun möchte ich mich mit meinem Handy über Hotspot verbinden und scheitere daran.

In der AFWall+ habe ich „Tethering - DHCP + DNS Dienste“ aktiviert. Ich sehe das WLAN auf dem Laptop, aber wenn ich mich verbinden möchte, passiert nichts. Das Wartesymbol von Linux Mint dreht sich, ich bekomme aber keine Verbindung hin.

Der „Sicherheit“ wegen habe ich als Passwort für WPA2 12345678 gewählt, damit ich sicher bin, dass das für den ersten Test korrekt ist. Hilft nichts - ich bekomme keine Verbindung hin.

Wie und wo kann ich denn da auf Fehlersuche gehen? Im Log der AWFall+ finde ich zumindest schon mal nichts. Habt Ihr eine Idee?

Danke Euch.

tulpenknicker · 9. November 2022 um 01:20

Selber habe ich Tethering nie benutzt.

nobody · 9. November 2022 um 05:02

Versuch mal bei aktiviertem Hotspot die AFWall+ Regeln nochmal manuell anzuwenden. In AFWall+ die drei Punkte antippen und Apply/Anwenden.

thegustavo · 9. November 2022 um 14:09

Danke für den Tip. Der ist leider nicht die Lösung für mein Problem.

Leider nicht - ich habe die entsprechenden Einträge in meinem CustomScript erhänzt. Ohne Erfolg.

Ich kann aber wohl davon ausgehen, dass es am CustomScript liegt. Denn mit aktiverter AFWall+, aber ohne dem CustomScript funktioniert Tethering. Da scheint etwas im argen zu liegen… . Seht Ihr etwas, das falsch ist? Sonst habe ich „nur noch“ ein paar weitere Scripts von ASN. Dies hier ist mein Hauptscript:

## AFWall+ additional firewall rules
## Mike Kuketz
## www.kuketz-blog.de

IPTABLES=/system/bin/iptables
IP6TABLES=/system/bin/ip6tables

# Default deny connections
$IPTABLES -P INPUT DROP  
$IPTABLES -P FORWARD DROP  
$IPTABLES -P OUTPUT DROP

$IP6TABLES -P INPUT DROP  
$IP6TABLES -P FORWARD DROP  
$IP6TABLES -P OUTPUT DROP

# Disable IPv6
echo 0 > /proc/sys/net/ipv6/conf/wlan0/accept_ra
echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6
echo 1 > /proc/sys/net/ipv6/conf/default/disable_ipv6

# Privacy IPv6 Address
echo 2 > /proc/sys/net/ipv6/conf/all/use_tempaddr
echo 2 > /proc/sys/net/ipv6/conf/default/use_tempaddr

# Captive mode
settings put global captive_portal_detection_enabled 1
settings put global captive_portal_mode 1
settings put global captive_portal_http_url "http://captiveportal.kuketz.de"
settings put global captive_portal_https_url "https://captiveportal.kuketz.de"
settings put global captive_portal_fallback_url "http://captiveportal.kuketz.de"
settings put global captive_portal_other_fallback_urls "http://captiveportal.kuketz.de"

# Allow loopback interface lo 
$IPTABLES -A INPUT -i lo -j ACCEPT
$IPTABLES -A "afwall" -o lo -j ACCEPT

# Allow ICMP packets
$IPTABLES -A INPUT -p icmp -m icmp --icmp-type echo-reply -j ACCEPT
$IPTABLES -A INPUT -p icmp -m icmp --icmp-type echo-request -j ACCEPT
$IPTABLES -A INPUT -p icmp -m icmp --icmp-type destination-unreachable -j ACCEPT

# Allow all traffic from an established #connection 
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow connection to CaptivePortal
$IPTABLES -A "afwall" -d 46.38.242.112 -p tcp -j ACCEPT

# Set a specific DNS server for all networks except home WiFi
$IPTABLES -t nat -I OUTPUT ! -s 192.168.178.0/24 -p tcp --dport 53 -j DNAT --to-destination 80.241.218.68
$IPTABLES -t nat -I OUTPUT ! -s 192.168.178.0/24 -p udp --dport 53 -j DNAT --to-destination 80.241.218.68

# Tethering
$IPTABLES -I afwall-wifi-tether -p udp -m owner --uid-owner 1052 -m udp --sport 67 --dport 68 -j RETURN
$IPTABLES -I afwall-wifi-tether -p udp -m owner --uid-owner 1052 -m udp --sport 53 -j RETURN
$IPTABLES -I afwall-wifi-tether -p tcp -m owner --uid-owner 1052 -m tcp --sport 53 -j RETURN

# Properly reject all remaining packages
$IPTABLES -A INPUT -p tcp -j REJECT --reject-with tcp-reset
$IPTABLES -A INPUT -j REJECT --reject-with icmp-port-unreachable

# Enable Apps to access Orbot 
$IPTABLES -A "afwall" -d 127.0.0.1 -p tcp --dport 9040 -j ACCEPT 
$IPTABLES -A "afwall" -d 127.0.0.1 -p udp --dport 5400 -j ACCEPT 

# Android Media Server over Orbot
$IPTABLES -t nat -A OUTPUT -p tcp -m owner --uid-owner 1013 -j DNAT --to-destination 127.0.0.1:9040 
$IPTABLES -t nat -A OUTPUT -p udp -m owner --uid-owner 1013 -j DNAT --to-destination 127.0.0.1:5400 

# AntennaPod over Orbot
$IPTABLES -t nat -A OUTPUT -p tcp -m owner --uid-owner 10181 -j DNAT --to-destination 127.0.0.1:9040
$IPTABLES -t nat -A OUTPUT -p udp -m owner --uid-owner 10181 -j DNAT --to-destination 127.0.0.1:5400

# VLC over Orbot
$IPTABLES -t nat -A OUTPUT -p tcp -m owner --uid-owner 10186 -j DNAT --to-destination 127.0.0.1:9040
$IPTABLES -t nat -A OUTPUT -p udp -m owner --uid-owner 10186 -j DNAT --to-destination 127.0.0.1:5400

# Twidere over Orbot
$IPTABLES -t nat -A OUTPUT -p tcp -m owner --uid-owner 10187 -j DNAT --to-destination 127.0.0.1:9040
$IPTABLES -t nat -A OUTPUT -p udp -m owner --uid-owner 10187 -j DNAT --to-destination 127.0.0.1:5400

trip · 10. November 2022 um 06:45

thegustavo:

# Default deny connections
$IPTABLES -P INPUT DROP  
$IPTABLES -P FORWARD DROP  
$IPTABLES -P OUTPUT DROP

[...]

# Tethering
$IPTABLES -I afwall-wifi-tether -p udp -m owner --uid-owner 1052 -m udp --sport 67 --dport 68 -j RETURN
$IPTABLES -I afwall-wifi-tether -p udp -m owner --uid-owner 1052 -m udp --sport 53 -j RETURN
$IPTABLES -I afwall-wifi-tether -p tcp -m owner --uid-owner 1052 -m tcp --sport 53 -j RETURN

Mit einer DROP Policy benötigst Du ACCEPT Rules, damit Datenpakete durchgelassen werden.

Die Tetheting Regeln brauchst Du meiner Meinung aber nicht mehr, https://github.com/ukanth/afwall/issues/965 ist unterdessen gelöst.

Da fehlen dann aber noch Regeln für hereinkommende DHCP und DNS Anfragen auf UDP Ports 67 und 53.

AFwall+ (ohne Custom Scripts) geht von INPUT Policy ACCEPT aus.

thegustavo · 17. November 2022 um 19:31

Meine Güte - Vollkatastrophe

Habe gerade die Version 3.5.3 von AFWall+ installiert - nun habe ich sofort wieder das Kreuz neben dem WLAN- und dem LTE-Symbol. Muss man in dieser Version etwas weiteres freigeben, damit CaptivePortal funktioniert? Mit dem Haken bei „CaptivePortal“ bleibt das Kreuz jedenfalls und verschwindet nicht. Mir wäre das egal, wenn DavX5 seinen Dienst damit nicht quittieren würde… .

Also wieder die 3.3.1 installiert, in der dieser Bug wohl noch nicht gefixed ist… .

Wären dies hier wenigstens die korrekten Regeln?

$IPTABLES -A INPUT -p udp --dport 53 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 53 -j ACCEPT
$IPTABLES -A INPUT -p udp --dport 67 -j ACCEPT
$IPTABLES -A INPUT -p udp --dport 68 -j ACCEPT

trip · 17. November 2022 um 23:35

Die zwei letzten kannst Du sogar noch mit --dport 67 --sport 68 und --dport 68 --sport 67 verschärfen. Aber ja, das wären sie.

Ich selbst habe mir ähnlich zu afwall-reject von AFWall+ noch eine eigene afwall-custom-drop CHAIN erstellt, die genauso Log-Ausgaben erzeugt, aber mit DROP anstelle REJECT endet. Damit kann ich dann auch verworfene INPUT und FORWARD Pakete sehen.

Ich glaube außerdem, dass Du für funktionierendes Tethering FORWARD Policy ACCEPT benötigst, sonst bekommt Dein Notebook zwar IP Adresse und löst DNS Namen auf, aber Dein Smartphone leitet die eigentlichen Verbindungen von/zu Notebook nicht weiter.

Das ist wohl von OS zu OS unterschiedlich. Bei mir reicht es, wenn ich [1073] Network Stack freigebe.

Update: Habe jetzt auch mal AFWall+ und WiFi-Hotspot ausprobiert. War etwas hakelig, da ich ebenfalls DROP Policies verwende. Aus AFWall+ Sicht kann ich aber sagen, dass ein Standard-AFWall+ bei meinem OS funktionieren würde.

Einziger Knackpunkt war, dass eine Internet Verbindung existeren muss (mobile Daten), damit die relevante CHAIN afwall-wifi-tether überhaupt zum Zuge kommt. Ohne Internet hat der Hotspot trotz Aktivierung von [-12] (Tethering) - DHCP+DNS-Dienste nicht zuverlässig funktioniert.

Ansonsten passen die generierten Regeln. -p udp --sport 67 --dport 68 generiert AFWall+ bei meinem OS für UIDs 0 (root), 9999 (nobody) und 1073 (com.android.networkstack). -p [udp|tcp] --sport 53 bekommt UIDs 0, 9999 und 1052 (dnsmasq). Auf anderen OS generiert AFWall+ ggf. andere UIDs. Ob die stimmen bekommst Du z.B. mit Logging heraus.

Solche Regeln habe ich ebenfalls benötigt (s.o.). Dann geht bereits DHCP und DNS. Das DROP Verhalten meiner FORWARD Chains musste ich wie vermutet auf ACCEPT ändern. Dann hatten auch Geräte hinter dem Hotspot Internet.

thegustavo · 11. Dezember 2022 um 19:40

@trip: Wäre es frech oder zu viel verlangt, wenn Du den entsprechenden Teil Deines Custom Scripts hier einstellen könntest? Das würde mir sehr helfen. Danke Dir

trip · 11. Dezember 2022 um 21:33

Nein, überhaupt nicht.

Besser noch geeignet als das Custom Script ist die Ausgabe von iptables -S. Ich melde mich nochmal …

… und zwar jetzt.

Das hier ist die editierte und entsprechend gekürzte Ausgabe meines iptables -S. Habe ich nicht getestet. Könnte aber funktionieren. Ich hoffe, ich habe nichts übersehen.

Hier noch der obligatorische Disclaimer für/gegen simples Copy&Paste:

Keine Garantie, Benutzer sollten wissen und verstehen, was sie tun. Die Kommentare sollte man lesen und beachten. Nur für IPv4 und nur für WiFi-Hotspot über mobile Daten gedacht. Whitelist modus (Allow selected) und enable inbound connections werden als angewählt vorausgesetzt, ebenso -12 - DHCP+DNS-Dienste für WiFi und mobile Daten (3G), Tor control stattdessen als abgewählt. DNS Proxy ist Auto oder Enabe DNS via netd, Log Target ist LOG. UID Nummern können von OS zu OS variieren, ebenso WiFi Interface Bezeichnungen und verwendeter WiFi-Hotspot IP-Adressbereich.

Viel Erfolg.

####
# Full paths of binaries to use ($IPTABLES is already set) - adapt according to your OS
###
BIN_TRUE=/system/bin/true

####
# DROP INPUT and FORWARD until chains are re-created
###

$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP

####
# own log-drop chain - follows rule syntax of afwall-reject
###

# create or flush
$IPTABLES -N afwall-custom-drop || $IPTABLES -F afwall-custom-drop

# !!! ATTENTION: adapt next rule if according to the rule found within afwall-reject !!!
$IPTABLES -A afwall-custom-drop -m limit --limit 1000/min -j LOG --log-prefix "{AFL}" --log-tcp-options --log-ip-options --log-uid
$IPTABLES -A afwall-custom-drop -j DROP

####
# own forward chain
###

# create or flush
$IPTABLES -N afwall-custom-forward || $IPTABLES -F afwall-custom-forward

# allow packets into local WiFi-HOTSPOT network - only for connections initiated within local WiFi-HOTSPOT network
# !!! ATTENTION: wlan+ may be different on your OS (AFWall+ also considers as wifi: eth+, tiwlan+, ra+, bnep+ ) !!!
# !!! ATTENTION: WiFi-HOTSPOT network IP-address range may be different on your OS, please check with ip addr !!!
$IPTABLES -A afwall-custom-forward -d 192.168.43.0/24 -o wlan+ -m state --state ESTABLISHED,RELATED -j RETURN

# allow packets originating within local WiFi-HOTSPOT network
# !!! ATTENTION: wlan+ may be different on your OS (AFWall+ also considers as wifi: eth+, tiwlan+, ra+, bnep+ ) !!!
# !!! ATTENTION: WiFi-HOTSPOT network IP-address range may be different on your OS, please check with ip addr !!!
$IPTABLES -A afwall-custom-forward -s 192.168.43.0/24 -i wlan+ -j RETURN

# log-drop everything else
$IPTABLES -A afwall-custom-forward -j afwall-custom-drop

# add to FORWARD chain at first position
$IPTABLES -D FORWARD   -j afwall-custom-forward || $BIN_TRUE
$IPTABLES -I FORWARD 1 -j afwall-custom-forward

####
# OUTPUT chain - general
###

# allow localhost packets - for symmetry with INPUT chain
$IPTABLES -A afwall -o lo -j RETURN

####
# INPUT chain - enable Enable inbound connections for it
###

# allow localhost packets
$IPTABLES -A afwall-input -i lo -j RETURN

# allow packets for locally initiated connections
$IPTABLES -A afwall-input -m state --state ESTABLISHED,RELATED -j RETURN

# allow late DHCP replies / broadcasts
$IPTABLES -A afwall-input -p udp --sport 67 --dport 68 -j RETURN

# allow DHCP requests from local WiFi-HOTSPOT network
# !!! ATTENTION: wlan+ may be different on your OS (AFWall+ also considers as wifi: eth+, tiwlan+, ra+, bnep+ ) !!!
$IPTABLES -A afwall-input -i wlan+ -p udp --sport 68 --dport 67 -j RETURN

# allow DNS requests from local WiFi-HOTSPOT network
# !!! ATTENTION: wlan+ may be different on your OS (AFWall+ also considers as wifi: eth+, tiwlan+, ra+, bnep+ ) !!!
$IPTABLES -A afwall-input -i wlan+ -p udp --dport 53 -j RETURN
$IPTABLES -A afwall-input -i wlan+ -p tcp --dport 53 -j RETURN

# log-drop everything else
$IPTABLES -A afwall-input -j afwall-custom-drop

####
# OUTPUT chain - WiFi only
###

# allow DHCP replies / broadcasts to local WiFi-HOTSPOT network in case no internet connection is available
# AFWall+ generates these rules (amongst others) within afwall-wifi-tether as well
# if [-12](Tethering) - DHCP+DNS-Dienste is enabled for WiFi and internet connection is available
# !!! ATTENTION: the --uid-owner numbers may vary depending on OS - lookup at least the afwall-wifi-tether rules !!!
$IPTABLES -A afwall-wifi -p udp --sport 67 --dport 68 -m owner --uid-owner 0 -j RETURN
$IPTABLES -A afwall-wifi -p udp --sport 67 --dport 68 -m owner --uid-owner 9999 -j RETURN
$IPTABLES -A afwall-wifi -p udp --sport 67 --dport 68 -m owner --uid-owner 1073 -j RETURN

####
# ACCEPT INPUT and FORWARD
###

$IPTABLES -P INPUT ACCEPT
$IPTABLES -P FORWARD ACCEPT

Update: Folgendes Custom shutdown script benötigt man noch.

####
# Full paths of binaries to use ($IPTABLES is already set) - adapt according to your OS
###
BIN_TRUE=/system/bin/true

####
# INPUT chain - Enable inbound connections may have been disabled in the mean time
###

# remove from INPUT chain
$IPTABLES -D INPUT -j afwall-input || $BIN_TRUE

####
# own forward chain
###

# remove from FORWARD chain
$IPTABLES -D FORWARD -j afwall-custom-forward || $BIN_TRUE

thegustavo · 13. Dezember 2022 um 07:54

Danke Dir für die Info, @trip.
Damit habe ich für das kommende Wochenende schon ordentlich was vor

trip · 26. Dezember 2022 um 11:43

Ich habe die Skripte nochmals überarbeitet (Aufruf von true und RELATED) und um unnötiges Tor entschlackt. Shutdown Skript ist zwischenzeitlich auch dazugekommen.

AFWall+ Tethering ist nicht gerade intuitiv gelöst. Es setzt eine Internetverbindung über mobile Daten voraus. Die Freigabe dafür erfolgt ebenfalls über [-12](Tethering) - DHCP+DNS-Dienste für Mobile Daten.

Während Freigabe für WiFi (und Tethering) „Downstream“ bedeutet (Angebot eines Hotspots bzw. Tethering-Zugangspunkts), ist für Mobile Daten „Upstream“ gemeint (tatsächliche Verbindung ins Internet).

Habe den Disclaimer entsprechend angepasst und auch sonst präzisiert.

Update: Wenn Du jetzt die INPUT und FORWARD Policies noch auf ACCEPT stellst, kannst Du einen Großteil der Skripte weglassen (die gesamte FORWARD und INPUT Behandlung). Es bleiben nur noch die 3 afwall-wifi Regeln übrig. Und die sind bei bestehender Internet-Verbindung auch nicht nötig.

Also, am besten probierst Du erstmal ohne Custom Skripte aus (Policies ACCEPT), das müsste nämlich gehen. Und schränkst erst dann nach und nach ein. Konfiguration siehe Disclaimer …

thegustavo · 28. Dezember 2022 um 12:11

Danke Dir erneut
Ich habe es in der Tat noch nicht geschafft, mich damit auseinander zu setzen. Das steht für Anfang 2023 an. Scheint nun aber hoffentlich einfacher zu sein.

Dir (und allen anderen Lesern) einen schönen Rutsch in ein hoffentlich schönes neues Jahr.

MarMic · 25. Oktober 2023 um 22:00

Hallo Trip.

Erst einmal vielen Dank für dein bereitgestelltes Skript!!

Ich bin leider nicht sehr afwall-affin, habe daher mir im „Baukasten-Prinzip“ die für mich relevanten Blöcke aus den Beiträgen hier von kuketz bzw. der Foren-User zusammengestellt. Das hat auch bislang gut funktioniert, war ich auf älteren Android-/afwall-Versionen unterwegs.

Mit A13 und/oder afwall 3.5.2 fing es dann an, dass ich keinen Hotspot mehr beitreten bzw. auch keinen mehr anbieten konnte.

Dein Skript scheint für das Setup von „thegustavo“ evtl. zu passen. Ich habe allerdings ein etwas anderes - und da scheint noch etwas zu fehlen.

Könntest du bitte hier supporten?

Ausgangspunkt:
Zwei A13-Geräte mit jeweils afwall 3.6.0 und dem von dir o.g. Startskript.
Gerät 1 bietet den Hotspot an.
Gerät 2 kann sich verbinden und erhält von Gerät 1 eine IP-Adresse.

Probleme:
Apps auf Gerät 2 erhalten keine Antworten aus dem Internet.
Ein ping (termux) auf 8.8.8.8 bekommt keine Antwort.
Ein nslookup (auf z.B. www.google.de) bekommt kein Ergebnis.

Auf Gerät 1 sehe ich im Log, dass Pakete von (oder an?) „Unbekannt (-100) rmnet_data1“ an den im Skript eingetragenen DNS-Server (176.9.93.198:53) geblockt werden. Aber auch TCP-Pakete von Apps vom Gerät 2 (z.B. whatsapp) erscheinen im Log, werden aber ebenfalls geblockt.

Auf Gerät 2 sehe ich im Log, dass nur UDP-Pakete von/an „Unbekannt (1073) eth“ auf Gerät 1 (Ziel-IP-Adresse 255.255.255.255:67) geblockt werden.

Kann es sein, dass ich hier „nur“ noch etwas im Skript ergänzen muss, damit UDP-Abfragen korrekt weitergeleitet bzw. zurückkommen können?

Ergänzung:
Aufgrund der Hinweise im Log von Gerät 1 habe ich eine interessante Seite gefunden, die mich Noob aber leider nicht zum Nerd macht.
https://android.stackexchange.com/questions/195374/how-to-assign-mobile-datas-public-ip-to-host-connected-on-hotspot

Gruß
MarMic

trip · 7. November 2023 um 22:03

Ich bin unterdessen von AFWall+ weggegangen. Verschiedene Gründe, hauptsächlich weil ich gleichzeitig auch kein gerootetes LineageOS mehr haben wollte.

Kann also nicht mehr wirklich beitragen. Ich kann meinen Tipp oben nur noch mal wiederholen.

Falls es immer noch nicht geht, kann Dir vielleicht die AFWall+ Community auf github helfen. Meiner Meinung nach müsste es dann nämlich ein Problem von AFWall+ selbst sein.

Noch ein paar Denkanstöße, an denen Du ansetzen könntest.

Ich habe mir damals immer die Log-Einträge mit logcat angeschaut. Diese waren detaillierter und die Sende-/Empfangsrichtung war auch klar.
Außerdem die erzeugten Regeln mittels iptables -S, und versucht nachzuvollziehen, welche Regel zum Blockieren der Pakete führt, bzw. welche Regel fehlt.
Drittens, einfaches Setup: AFWall+ ohne Skripte, nur Gerät 1 mit Firewall, INPUT und FORWARD chains (auf Gerät 1) sollten nichts blockieren.

Das Log auf Gerät 2 zeigt nur auf Gerät 2(!) geblockte Pakete an. Am besten hier erst mal keine Firewall.