CachyOS / CachyOS/distribution
[Bug]: Default UFW rules break KDE/NetworkManager Wi-Fi hotspot DHCP on fresh CachyOS KDE install
- Dominant language
- No language data
- Stars
- 27
- Forks
- 2
- PR merge metrics
- No merged PRs in 30d
Description
### Kernel
7.1.2-3-cachyos
### Desktop Environment / Window Manager
KDE Plasma
### CPU
Intel Core i5-12400f
### GPU / Driver
NVidia RTX 3060
### Description
Fresh CachyOS KDE install includes and enables UFW/plasma-firewall. Creating a Wi-Fi hotspot via KDE or nmcli brings up the AP, wlan0 gets 10.42.0.1/24, dnsmasq starts, and the phone associates with the AP, but Android cannot obtain an IP address.
tcpdump shows DHCPDISCOVER from the phone on wlan0, but no DHCPOFFER is returned while UFW rules are active.
nft list ruleset shows UFW/iptables-nft rules dropping udp dport 67 via ufw-skip-to-policy-input, and FORWARD policy is drop. Manually allowing DHCP input on wlan0, forwarding wlan0 -> enp4s0, established return traffic, and MASQUERADE fixes the hotspot.
Expected: KDE/NetworkManager hotspot should work out of the box on a default CachyOS KDE install, or CachyOS should add a preset/rule/profile for hotspot sharing when UFW is enabled.
### Steps to Reproduce
Install CachyOS KDE with the default package selection.
Confirm that ufw, ufw-extras, and plasma-firewall are installed and UFW is active.
Create a Wi-Fi hotspot using KDE Plasma NetworkManager UI or nmcli device wifi hotspot ifname wlan0 con-name hotspot ssid hotspot password "12345678".
Try to connect an Android phone to the hotspot.
The phone associates with the AP, but fails to obtain an IP address.
Run tcpdump -ni wlan0 -vvv 'port 67 or port 68'.
DHCPDISCOVER packets from the phone are visible, but no DHCPOFFER is returned while UFW rules are active.
Manually allowing DHCP input on wlan0, forwarding from wlan0 to enp4s0, established return traffic, and MASQUERADE fixes the hotspot.
### Expected Behavior
A Wi-Fi hotspot created through KDE/NetworkManager should work out of the box on a fresh CachyOS KDE install. Clients should receive an IP address via DHCP and have internet access through the wired connection.
### Actual Behavior
The hotspot AP starts and the phone can associate with it, but Android cannot obtain an IP address. wlan0 gets 10.42.0.1/24, dnsmasq starts, and tcpdump shows DHCPDISCOVER packets from the phone, but no DHCPOFFER is returned while the default UFW rules are active.
### Logs / Error Messages
https://paste.cachyos.org/p/3b54211.log
### Additional Context
Hardware:
Wi-Fi: Intel Wi-Fi 6 AX201, driver iwlwifi
Ethernet uplink: enp4s0
Hotspot interface: wlan0
Phone used for testing: Samsung S23 Ultra / Android
The Wi-Fi adapter supports AP mode. iw list includes * AP.
This does not appear to be an Intel Wi-Fi driver issue. The AP starts successfully and the phone can associate. The failure appears to be caused by the default CachyOS KDE firewall setup using UFW/plasma-firewall, which blocks DHCP and routed traffic required for NetworkManager hotspot sharing.
Relevant firewall evidence from `sudo nft list ruleset`:
- `table ip filter is managed by iptables-nft`
- UFW chains are active: `ufw-before-input`, `ufw-after-input`, `ufw-skip-to-policy-input`
- `ufw-after-input` sends `udp dport 67` to `ufw-skip-to-policy-input`
- `ufw-skip-to-policy-input` drops packets
- `FORWARD` chain has `policy drop`
This blocks DHCP for NetworkManager hotspot clients. Adding temporary iptables rules to allow UDP/67 on wlan0, allow wlan0 -> enp4s0 forwarding, allow established return traffic, and MASQUERADE makes the hotspot work.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reproducing the hotspot with KDE or the documented nmcli command, then inspect the UFW/plasma-firewall rules with tcpdump and `nft list ruleset`. Use the provided temporary firewall rules as a comparison; done means a hotspot client receives DHCP configuration and reaches the internet through the wired interface under the default firewall setup.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- linux
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100