Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stuck on Obtaining IP address (firewalld) #19

Open
Evan-aja opened this issue Jun 14, 2021 · 13 comments
Open

Stuck on Obtaining IP address (firewalld) #19

Evan-aja opened this issue Jun 14, 2021 · 13 comments
Labels
enhancement New feature or request

Comments

@Evan-aja
Copy link

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.

@garywill

This comment has been minimized.

@Evan-aja

This comment has been minimized.

@garywill

This comment has been minimized.

@Evan-aja

This comment has been minimized.

@garywill

This comment has been minimized.

@Evan-aja

This comment has been minimized.

@basilrabi
Copy link

basilrabi commented Jun 30, 2021

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.

@garywill

This comment has been minimized.

@garywill garywill reopened this Jul 3, 2021
@Evan-aja
Copy link
Author

Evan-aja commented Jul 3, 2021

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

@dimasdhimek
Copy link

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

@garywill garywill added Fedora help wanted Extra attention is needed need investigation Need more test results, info and investigation labels Aug 11, 2021
@garywill
Copy link
Owner

garywill commented Aug 26, 2021

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

@garywill garywill added enhancement New feature or request and removed Fedora labels Aug 26, 2021
@garywill garywill changed the title Stuck on Obtaining IP address Stuck on Obtaining IP address (firewalld) Aug 26, 2021
@Evan-aja
Copy link
Author

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

@garywill
Copy link
Owner

@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 #19 (comment)

@garywill garywill removed help wanted Extra attention is needed need investigation Need more test results, info and investigation labels Nov 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants