Open Evan-aja opened 3 years ago
I see in your log
Jun 14 12:55:30 dnsmasq[6076]: reading /etc/resolv.conf
Jun 14 12:55:30 dnsmasq[6076]: using nameserver 127.0.0.53#53
Is your host's DNS configuration correct?
Sorry, above is DNS, not DHCP. I confused myself.
In your log the host didn't receive DHCP discover
packet. Could you check iptables (or tcpdump/Wireshark) if it was filtered?
Or, run this (with root) to see if other processes occupying DHCP port
sudo ss -tulpn|grep -E "\b68\b|\b67\b"
this is the output from the command you gave me, since i'm still new to these stuff i will to give information to you as best as i could.
udp UNCONN 0 0 0.0.0.0%x0wlp3s0:67 0.0.0.0:* users:(("dnsmasq",pid=66588,fd=4))
There's no other process occupying DHCP, from your output.
Sorry no idea come to me yet. Have you tried other phones? Or try create_ap
Oh, and, it's not usual to have a nameserver 127.0.0.53#53
in /etc/resolv.conf
. Have you done some special settings to your host? Eg VPN? Tor? If yes try reset then run again.
And, If you can provide your full firewall settings, maybe someone can find something:
sudo iptables -L -v -n
sudo iptables -L -v -n -t nat
sudo iptables -L -v -n -t mangle
I didn't do anything on my system yet, it's still a clean install, and when I change the nameserver to 127.0.0.1
the program automatically changed it again to 127.0.0.53
. this only happens on fedora 34, when I tried to run the program on arch, everything went smoothly without problem. there's also a problem with hostapd cannot reading configuration file even on root if i try to use this program on opensuse tumbleweed.
create_ap and linux-wifi-hotspot produces the same behavior on all three distros tested above. so I'm very confused myself with why this is happening.
By the way, these are the outputs if the iptables command you gave me :
sudo iptables -L -v -n
Chain INPUT (policy ACCEPT 215 packets, 42952 bytes)
pkts bytes target prot opt in out source destination
2946 2720K LIBVIRT_INP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 LIBVIRT_FWX all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 LIBVIRT_FWI all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 LIBVIRT_FWO all -- * * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 223 packets, 26235 bytes)
pkts bytes target prot opt in out source destination
2625 257K LIBVIRT_OUT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain LIBVIRT_FWI (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * virbr0 0.0.0.0/0 192.168.122.0/24 ctstate RELATED,ESTABLISHED
0 0 REJECT all -- * virbr0 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
Chain LIBVIRT_FWO (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- virbr0 * 192.168.122.0/24 0.0.0.0/0
0 0 REJECT all -- virbr0 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
Chain LIBVIRT_FWX (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- virbr0 virbr0 0.0.0.0/0 0.0.0.0/0
Chain LIBVIRT_INP (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
0 0 ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
0 0 ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:67
0 0 ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:67
Chain LIBVIRT_OUT (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- * virbr0 0.0.0.0/0 0.0.0.0/0 udp dpt:53
0 0 ACCEPT tcp -- * virbr0 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
0 0 ACCEPT udp -- * virbr0 0.0.0.0/0 0.0.0.0/0 udp dpt:68
0 0 ACCEPT tcp -- * virbr0 0.0.0.0/0 0.0.0.0/0 tcp dpt:68
sudo iptables -L -v -n -t nat
Chain PREROUTING (policy ACCEPT 4 packets, 520 bytes)
pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 3 packets, 183 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 62 packets, 4466 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 62 packets, 4466 bytes)
pkts bytes target prot opt in out source destination
260 17986 LIBVIRT_PRT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain LIBVIRT_PRT (1 references)
pkts bytes target prot opt in out source destination
3 235 RETURN all -- * * 192.168.122.0/24 224.0.0.0/24
0 0 RETURN all -- * * 192.168.122.0/24 255.255.255.255
0 0 MASQUERADE tcp -- * * 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535
0 0 MASQUERADE udp -- * * 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535
sudo iptables -L -v -n -t mangle
Chain PREROUTING (policy ACCEPT 2975 packets, 2727K bytes)
pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 2972 packets, 2727K bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 2649 packets, 263K bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 2687 packets, 268K bytes)
pkts bytes target prot opt in out source destination
2687 268K LIBVIRT_PRT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain LIBVIRT_PRT (1 references)
pkts bytes target prot opt in out source destination
0 0 CHECKSUM udp -- * virbr0 0.0.0.0/0 0.0.0.0/0 udp dpt:68 CHECKSUM fill
I downloaded Fedora-Workstation-Live-x86_64-34-1.2.iso
to test.
Inspected the network with tcpdump
. I saw DHCP discover packet comming in, but Fedora 34's dnsmasq 2.84rc2
won't react. No log. No reply. I guess the problem is on it. Maybe should report a bug to them.
there's also a problem with hostapd cannot reading configuration file even on root if i try to use this program on opensuse tumbleweed.
I also see that problem, on openSUSE 15.2 recent update.
hostapd
only reads conf file at /etc/hostapd.conf
and can only use ctrl_interface=/var/run/hostapd
.
strace
showed "no permission to access" other than /etc/hostapd.conf
.
That's also a strange behavior. Also should report a bug to them.
Thanks for the clarification, so I guess the problem is bigger than just a single program acting up then, but since not that many people actually uses these apps daily and figured this specific bug, i reckon it won't be within the devs main priorities right now.
I will close this issue. thanks for the help
Had the same problem before when I was using create-ap. However, the workaround does not work anymore. I think we have to guess which services or ports are going to be allowed in the firewall so an IP Address can be assigned to the connecting device.
I think we should check if this is caused by a system service/module.
We can try these first: (not limited to these)
1
systemctl disable firewalld
2
systemctl disable networkmanager
(or disabling some other security/firewall services)
3 reboot
4
Also try use lnxrouter -6
. I have even encounter a strange bug somewhere before, that IPv6 iptables also had to be set so that IPv4 functions.
If problem still, we shouldn't be afraid to consult upstream (distro forum).
I don't have my Linux computer today, @basilrabi @Evan-aja you can try.
I have also tested this on fedora, i'm about to comment on the pull request about it, but afaik in my experiment the only thing needs to be disabled is the firewalld.service
with the command
# systemctl disable --now firewalld.service
there's no need to reboot the system in my testing, as the daemon is instantly killed with the deletion of the symlink with the --now
parameter
I have also tested this on fedora, i'm about to comment on the pull request about it, but afaik in my experiment the only thing needs to be disabled is the
firewalld.service
with the command# systemctl disable --now firewalld.service
there's no need to reboot the system in my testing, as the daemon is instantly killed with the deletion of the symlink with the--now
parameter
i think its better to allow dhcp service on firewalld setting rather than disable the firewalld
Yes it is firewalld.
Years ago people were saying firewalld used iptables as backend. Now they must have changed.
That's why I didn't see anything in iptables -L -v
. The rules are shown in nft list ruleset
.
This script needs a plan to totally switch to nft I guess. (I currently don't have a good knowledge about it) For solving this problem. Also for keeping up with the times.
(maybe 1 or 2 years later, there're still many devices using legacy iptables. And iptables-nft translation works good)
Before figuring out a perfect solution, I guess we can still use nft
1) disable firewalld. Or
2) add x0wlan0
to trusted zone to bypass the firewall for our AP.
3). I'm having a plan to create a new firewalld zone, which is mostly equal to trusted
zone, in our script then add the interface into it. Of course, on script's cleanup, we must remove the interface from the zone and delete the new zone. New zone's name should be lnxrouter-PID-interfce
Good news! I've recently found out a solution from user NeonDragon1909 here, the script should be working now, I have tested it and now the script works like a charm. it seems to me that firewalld is blocking dhcp requests by default hence why devices can't connect to the access point as it literally can't get an IP address.
here is the command :
sudo firewall-cmd --add-service=dhcp
sudo firewall-cmd --add-service=dns
sudo firewall-cmd --add-masquerade
sudo firewall-cmd -q --direct --add-rule ipv4 nat POSTROUTING 0 -o <ap_iface> -j MASQUERADE
sudo firewall-cmd -q --direct --add-rule ipv4 filter FORWARD 0 -i <internet_iface> -o <ap_iface> -j ACCEPT
sudo firewall-cmd -q --direct --add-rule ipv4 filter FORWARD 0 -i <ap_iface> -o <internet_iface> -m state --state RELATED,ESTABLISHED -j ACCEPT
just replace <ap_iface>
and <internet_iface>
with your interfaces, for example, i use wlp3s0
both on ap
, and internet
, so i replace both with wlp3s0
@Evan-aja That should work, but that's applying same rule twice (iptables + firewalld)
Simpler way is like: ( I haven't tested)
firewalld-cmd --zone=trusted --add-interface=interface
If it works (for any mode of our script), my idea is as https://github.com/garywill/linux-router/issues/19#issuecomment-906394784
I'm using fedora 34 currently, and even after all the dependencies are installed (iproute2 is iproute here but they're basically the same) and the access point is created, see below
when i'm trying to connect my phone to the newly made access point, it stuck in a loop between connecting and obtaining ip address. and after a while, it stops with "IP Configuration Failure". here is the output on the terminal while the reconnection is happening. (
any thought regarding this behavior? I would love to see this issue to be fixed as soon as possible.