linux-router
linux-router copied to clipboard
garywill
Stuck on Obtaining IP address (firewalld)
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
lnxrouter --ap wlp3s0 MyAccessPoint -p MyPassPhrase
PID: 5919
Target interface is wlp3s0 (e0:ca:94:8b:53:4f)
Use random LAN IPv4 address 192.168.53.1
wlp3s0 already in channel 11 (2462 MHz)
Channel fallback to 11
Creating a virtual WiFi interface...
x0wlp3s0 created
Set x0wlp3s0 unmanaged by NetworkManager
Assigning MAC address e0:ca:94:8b:53:59 to virtual interface x0wlp3s0 according to wlp3s0 ...
haveged_watchdog PID: 6045
Starting hostapd
hostapd PID: 6048
Configuration file: /dev/shm/lnxrouter_tmp/lnxrouter.wlp3s0.conf.W74/hostapd.conf
Using interface x0wlp3s0 with hwaddr e0:ca:94:8b:53:59 and ssid "MyAccessPoint"
x0wlp3s0: interface state UNINITIALIZED->ENABLED
x0wlp3s0: AP-ENABLED
iptables: NAT
MASQUERADE all opt -- in * out !x0wlp3s0 192.168.53.0/24 !-> 192.168.53.0/24
ACCEPT all opt -- in x0wlp3s0 out * 192.168.53.0/24 -> 0.0.0.0/0
ACCEPT all opt -- in * out x0wlp3s0 0.0.0.0/0 -> 192.168.53.0/24
Loaded kernel module nf_nat_pptp
iptables: allow DNS
ACCEPT tcp opt -- in x0wlp3s0 out * 192.168.53.0/24 -> 192.168.53.1 tcp dpt:53
ACCEPT udp opt -- in x0wlp3s0 out * 192.168.53.0/24 -> 192.168.53.1 udp dpt:53
iptables: allow dhcp
ACCEPT udp opt -- in x0wlp3s0 out * 0.0.0.0/0 -> 0.0.0.0/0 udp dpt:67
Starting dnsmasq
Jun 14 12:55:30 dnsmasq[6076]: started, version 2.85 cachesize 150
Jun 14 12:55:30 dnsmasq[6076]: compile time options: IPv6 GNU-getopt DBus no-UBus no-i18n IDN2 DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth cryptohash DNSSEC loop-detect inotify dumpfile
Jun 14 12:55:30 dnsmasq-dhcp[6076]: DHCP, IP range 192.168.53.10 -- 192.168.53.250, lease time 1h
Jun 14 12:55:30 dnsmasq-dhcp[6076]: DHCP, sockets bound exclusively to interface x0wlp3s0
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
Jun 14 12:55:30 dnsmasq[6076]: cleared cache
dnsmasq PID: 6076
== Setting up completed, now linux-router is working ==
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. (
x0wlp3s0: STA 2c:4d:54:a7:8c:22 IEEE 802.11: authenticated
x0wlp3s0: STA 2c:4d:54:a7:8c:22 IEEE 802.11: associated (aid 1)
x0wlp3s0: AP-STA-CONNECTED 2c:4d:54:a7:8c:22
x0wlp3s0: STA 2c:4d:54:a7:8c:22 RADIUS: starting accounting session 503193598255D4BF
x0wlp3s0: STA 2c:4d:54:a7:8c:22 WPA: pairwise key handshake completed (RSN)
x0wlp3s0: AP-STA-DISCONNECTED 2c:4d:54:a7:8c:22
x0wlp3s0: STA 2c:4d:54:a7:8c:22 IEEE 802.11: authenticated
x0wlp3s0: STA 2c:4d:54:a7:8c:22 IEEE 802.11: associated (aid 1)
x0wlp3s0: AP-STA-CONNECTED 2c:4d:54:a7:8c:22
x0wlp3s0: STA 2c:4d:54:a7:8c:22 RADIUS: starting accounting session 67324ADF103B09AB
x0wlp3s0: STA 2c:4d:54:a7:8c:22 WPA: pairwise key handshake completed (RSN)
x0wlp3s0: AP-STA-DISCONNECTED 2c:4d:54:a7:8c:22
x0wlp3s0: STA 2c:4d:54:a7:8c:22 IEEE 802.11: authenticated
x0wlp3s0: STA 2c:4d:54:a7:8c:22 IEEE 802.11: associated (aid 1)
x0wlp3s0: AP-STA-CONNECTED 2c:4d:54:a7:8c:22
x0wlp3s0: STA 2c:4d:54:a7:8c:22 RADIUS: starting accounting session 5C975DF981254FC3
x0wlp3s0: STA 2c:4d:54:a7:8c:22 WPA: pairwise key handshake completed (RSN)
x0wlp3s0: AP-STA-DISCONNECTED 2c:4d:54:a7:8c:22
x0wlp3s0: STA 2c:4d:54:a7:8c:22 IEEE 802.11: authenticated
x0wlp3s0: STA 2c:4d:54:a7:8c:22 IEEE 802.11: associated (aid 1)
x0wlp3s0: AP-STA-CONNECTED 2c:4d:54:a7:8c:22
x0wlp3s0: STA 2c:4d:54:a7:8c:22 RADIUS: starting accounting session 3447F6397B00AB6C
x0wlp3s0: STA 2c:4d:54:a7:8c:22 WPA: pairwise key handshake completed (RSN)
x0wlp3s0: AP-STA-DISCONNECTED 2c:4d:54:a7:8c:22
x0wlp3s0: STA 2c:4d:54:a7:8c:22 IEEE 802.11: authenticated
x0wlp3s0: STA 2c:4d:54:a7:8c:22 IEEE 802.11: associated (aid 1)
x0wlp3s0: AP-STA-CONNECTED 2c:4d:54:a7:8c:22
x0wlp3s0: STA 2c:4d:54:a7:8c:22 RADIUS: starting accounting session 49A83E82BB3A7A28
x0wlp3s0: STA 2c:4d:54:a7:8c:22 WPA: pairwise key handshake completed (RSN)
x0wlp3s0: AP-STA-DISCONNECTED 2c:4d:54:a7:8c:22
any thought regarding this behavior? I would love to see this issue to be fixed as soon as possible.
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.servicewith the command# systemctl disable --now firewalld.servicethere's no need to reboot the system in my testing, as the daemon is instantly killed with the deletion of the symlink with the--nowparameter
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~~
-
disable firewalld. Or
-
add
x0wlan0to 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