Sorry for the late response.

I am getting things setup to give it a try.

Will get back to you.

I tested the script below and it is working on my Devuan Excalibur laptop.

#!/bin/sh

# skinny-create-ap v2.5 (August 27, 2026)
# Bruno "GNUser" Dantas (GPLv3)

# Purpose: Turn a GNU/Linux system into a wireless router
# Dependencies: $ sudo apt install iproute2 iptables busybox hostapd net-tools
# Syntax: $ sudo skinny-create-ap <lan_if> <wan_if> <ssid> <passphrase>
# Example usage: $ sudo skinny-create-ap wlan0 eth0 DevuanHotspot TopSecret123
# To turn off the hotspot: $ sudo pkill hostapd; sudo pkill -f udhcpd

# user variables:
lan_if="$1"
wan_if="$2"
ssid="$3"
password="$4"
channel=6
dns_server=9.9.9.9

main()
{
	prevent_nm_interference
	select_subnet
	setup_kernel
	setup_nat
	setup_dhcp
	setup_ap
}

prevent_nm_interference()
{
	nmcli dev set "$lan_if" managed no >/dev/null 2>&1
}

select_subnet()
{
	# let's make sure the subnet/"ip_stem" we use for wlan isn't already being used by the host:
	ip_stem_part1=192.168
	ip_stem_part2=60
	while netstat -tulpn | grep -q "$ip_stem_part1.$ip_stem_part2"; do
		ip_stem_part2=$(( ip_stem_part2 + 10 ))
	done
	ip_stem=$ip_stem_part1.$ip_stem_part2
	echo "$(basename $0): will use ip_stem $ip_stem"
}

setup_kernel()
{
	echo 1 >/proc/sys/net/ipv4/conf/"$wan_if"/forwarding
	echo 1 >/proc/sys/net/ipv4/ip_forward
}

setup_nat()
{
	iptables -t nat -A POSTROUTING -o "$wan_if" -j MASQUERADE
	iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
	iptables -A FORWARD -i "$lan_if" -o "$wan_if" -j ACCEPT
}

setup_dhcp()
{
	# first, bring up $lan_if and give it a suitable ip address:
	if ip link set "$lan_if" up; then
		ip addr add $ip_stem.1/24 dev "$lan_if"
	else
		echo "$lan_if does not exist or cannot be brought up. Make sure necessary driver +/- firmware is installed." >&2
		exit 1
	fi

	# create config file:
	echo "
start $ip_stem.100
end $ip_stem.200
interface $lan_if
opt dns $dns_server
opt subnet 255.255.255.0
opt router $ip_stem.1
" >/etc/udhcpd.conf

	# start dhcp server:
	busybox udhcpd
}

setup_ap()
{
	# create hostapd config file:
	echo "
ssid=$ssid
interface=$lan_if
driver=nl80211
channel=$channel
ignore_broadcast_ssid=0
hw_mode=g
auth_algs=1
wpa=2 
wpa_passphrase=$password
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP
rsn_pairwise=CCMP

# N
ieee80211n=1
wmm_enabled=1
" >/tmp/hostapd.conf

	# start hostapd:
	hostapd /tmp/hostapd.conf &
}

main

How-to (3 steps):

1. Put the script somewhere in your PATH and make it executable. I'd call it skinny-create-ap or similar.

2. Install the script's dependencies:

$ sudo apt install iproute2 iptables busybox hostapd net-tools

3. Run the script. Syntax is sudo skinny-create-ap <lan_if> <wan_if> <ssid> <passphrase> so, for example:

$ sudo skinny-create-ap wlan0 eth0 DevuanHotspot TopSecret123

If your goal is a wifi repeater (i.e., the Devuan host creating the AP is itself connected to the internet by wifi), the host needs to have two wireless nics. For example, the host could use wlan0 to connect to the internet and wlan1--or wlx00127b20535e or whatever ifconfig shows--to create the AP. In this situation, the command would look something like this:

$ sudo skinny-create-ap wlx00127b20535e wlan0 DevuanHotspot TopSecret123

At thist point, clients should be able to connect to the AP/hotspot you created

Once you're done and want to take down the hotspot, run these commands on the host machine:

$ sudo pkill hostapd; sudo pkill -f udhcpd

Let me know how it goes.

P.S. If after running the script you find that your host machine cannot resolve domain names, check the file /etc/resolv.conf and make sure it contains the ip address of your preferred dns server. Here is what my minimal, working /etc/resolv.conf looks like:

nameserver 9.9.9.9

Maybe you're not changing the stem/subnet in the right place? Try this:

First run sudo pkill -f dnsmasq just to make sure there isn't an instance of dnsmasq already running and interfering.

Then try this script. I added a function to make sure the selected ip_stem isn't already being used. I haven't tested it but it should work.

#!/bin/sh

# skinny-create-ap v2.4 (August 27, 2026)
# Bruno "GNUser" Dantas (GPLv3)

# Purpose: Turn a GNU/Linux system into a wireless router
# Dependencies: iproute2 iptables dnsmasq hostapd
# Not a dependency but highly recommended: haveged
# Syntax: $ sudo skinny-create-ap <lan_if> <wan_if> <ssid> <passphrase>
# Example usage: $ sudo skinny-create-ap wlan0 eth0 DevuanHotspot TopSecret123
# To turn off the hotspot: $ sudo pkill hostapd; sudo pkill -f 'dnsmasq.*/tmp/dnsmasq.conf'

# user variables:
lan_if="$1"
wan_if="$2"
ssid="$3"
password="$4"
channel=6
#dns_server=1.1.1.1

main()
{
	prevent_nm_interference
	select_subnet
	setup_kernel
	setup_nat
	setup_dhcp
	setup_ap
}

prevent_nm_interference()
{
	nmcli dev set "$lan_if" managed no >/dev/null 2>&1
}

select_subnet()
{
	# let's make sure the subnet/"ip_stem" we use for wlan isn't already being used by the host:
	ip_stem_part1=192.168
	ip_stem_part2=60
	while sudo netstat -tulpn | grep -q "$ip_stem_part1.$ip_stem_part2"; do
		ip_stem_part2=$(( ip_stem_part2 + 10 ))
	done
	ip_stem=$ip_stem_part1.$ip_stem_part2
	echo "$(basename $0): will use ip_stem $ip_stem"
}

setup_kernel()
{
	echo 1 >/proc/sys/net/ipv4/conf/"$wan_if"/forwarding
	echo 1 >/proc/sys/net/ipv4/ip_forward
}

setup_nat()
{
	iptables -t nat -A POSTROUTING -o "$wan_if" -j MASQUERADE
	iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
	iptables -A FORWARD -i "$lan_if" -o "$wan_if" -j ACCEPT
}

setup_dhcp()
{
	# first, bring up $lan_if and give it a suitable ip address:
	if ip link set "$lan_if" up; then
		ip addr add $ip_stem.1/24 dev "$lan_if"
	else
		echo "$lan_if does not exist or cannot be brought up. Make sure necessary driver +/- firmware is installed." >&2
		exit 1
	fi

	# create dnsmasq config file:
	echo "
dhcp-leasefile=/tmp/dnsmasq.leases
dhcp-range=$ip_stem.100,$ip_stem.200,255.255.255.0,24h
#dhcp-option-force=option:dns-server,$dns_server
" >/tmp/dnsmasq.conf

	# start dnsmasq (with care not to clash with any dnsmasq instances that might already be running):
	dnsmasq --interface="$lan_if" --bind-interfaces --except-interface=lo -C /tmp/dnsmasq.conf 
}

setup_ap()
{
	# create hostapd config file:
	echo "
ssid=$ssid
interface=$lan_if
driver=nl80211
channel=$channel
ignore_broadcast_ssid=0
hw_mode=g
auth_algs=1
wpa=2 
wpa_passphrase=$password
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP
rsn_pairwise=CCMP

# N
ieee80211n=1
wmm_enabled=1
" >/tmp/hostapd.conf

	# start hostapd:
	hostapd /tmp/hostapd.conf &
}

main

I tried 192.168.60, 192.168.70, 192.168.80 &, 192.168.90 and I was getting the same response.

When I got to 192.168.100, I got the following response:

RTNETLINK answers: File exists

dnsmasq: failed to create listening socket for 192.168.90.1: Address already in use

When I tried 192.168.110, 192.168.120 & 192.168.130, I got the following response:

dnsmasq: failed to create listening socket for 192.168.90.1: Address already in use

What else can I look at or try?

Thanks!! again, mtbvfr.

Looks like the script has been broken by dnsmasq in the setup_dhcp() procedure.

I get the following output:

dnsmasq: failed to create listening socket for 192.168.50.1: Address already in use

The best I can do to help pinpoint the problem is the following.

sudo ss -tulpn | grep "192.168.50.1" provides the following output:

udp   UNCONN 0      0        192.168.50.1:137        0.0.0.0:*    users:(("nmbd",pid=2996,fd=21))        
udp   UNCONN 0      0        192.168.50.1:138        0.0.0.0:*    users:(("nmbd",pid=2996,fd=23))

pid=2996 refers to "nmbd -D"

TIA!!

TL;DR version:
    With modern linux kernels (5.6 or later) there is no need to install haveged on a GNU/Linux box being used as a wireless router.

Detailed version:
    Entropy is needed for fast communication between wireless router and wireless clients (due to wpa2 cryptography operations). It used to be recommended to run cat /proc/sys/kernel/random/entropy_avail on the router and, if result was less than 1000, to install haveged and run it as a daemon to augment router's entropy pool.
    Turns out that linux 5.6 incorporated a haveged-inspired mechanism that generates entropy extremely quickly (~200 MiB/s), making the haveged daemon obsolete for this use case (fast entropy generation). Also, result of cat /proc/sys/kernel/random/entropy_avail is now meaningless (the command always returns "256").

Ref: https://github.com/jirka-h/haveged/issues/57

P.S. Would the forum moderator kindly delete haveged from Reply #18 (two places) and Reply #21 (one place)? I tried to delete it myself, but was denied ("You do not have permission to access this page").

The nmcli command fixes things on the Lenovo L540.

After I enter my sudo password for running v2.3 of skinny-create-ap, there is no more output in the Terminal app. It simply returns to the Command Prompt.

Thanks! again, MTB.

If I run nmcli dev set wlan0 managed no, how do I undo the effects of this when I've finished using the Access Point

With nmcli dev set wlan0 managed yes

No.

Regarding wicd, its last stable release was in 2016 and last merge request from 2019. You could try it but the software is unmaintained.

NetworkManager is installed and running when I experience the handle_probe_req: send failed issue.

If I run nmcli dev set wlan0 managed no, how do I undo the effects of this when I've finished using the Access Point or does the command sudo pkill hostapd; sudo pkill -f 'dnsmasq.*/tmp/dnsmasq.conf' take care of this?

Is wicd a viable alternative to NetworkManager?

I will try testing tomorrow.

Thanks, MTB.

I updated the script in reply #18 to include the nmcli command. I will go ahead and mark the thread as "Solved" (almost 7 years later--haha).

P.S. Please let me know if the nmcli command fixes things on your Lenovo L540. As for your other laptops, I'll leave those for you and other users to troubleshoot. I suggest scrutinizing the wifi hardware (not all hardware supports AP mode), excluding interference from network managers, and excluding interference from other software (e.g., rfkill).

Sometimes, after a while, "handle_probe_req: send failed" is output multiple times.

Hi mtbvfr. I cannot reproduce the problem on my ThinkPad X200 with ALFA USB wifi adapter and Tiny Core Linux.

I don't normally run the skinny-create-ap script on my ThinkPad X230 with Devuan Daedalus but I gave it a try and I am able to reproduce your problem:

$ sudo skinny-create-ap wlx00127b20535e wlan0 DevuanHotspot TopSecret123
...
[I can connect to the hotspot using my phone, and phone can access the internet without any problems for several minutes]
wlx00127b20535e: INTERFACE-DISABLED 
wlx00127b20535e: INTERFACE-ENABLED 
[here the phone loses connection to the hotspot]
handle_probe_req: send failed
handle_probe_req: send failed
handle_probe_req: send failed
handle_probe_req: send failed
handle_probe_req: send failed
handle_probe_req: send failed

Since the hotspot works perfectly for several minutes before failing, I suspect the sudden failure is related to either power management or a networking daemon (e.g., NetworkManager) interfering.

One big difference between my X200 with TCL and X230 with Daedalus is that the latter uses NetworkManager.

Two questions for you, mtbvfr:

1. On your Lenovo L540 using Devuan Daedalus, is NetworkManager installed and running when you experience the "handle_probe_req: send failed" issue?

2. If you run nmcli dev set wlan0 managed no and then start the hotspot with sudo skinny-create-ap wlan0 eth0 DevuanHotspot TopSecret123 does the "handle_probe_req: send failed" problem go away?

I'm testing #2 right now.

But repeaters are simply much cheaper.

But I do have two cents of advice that I can give right away:

Over the years, I've had many headaches of the type you're having now. I am not exaggerating when I say that all of my wifi-related headaches went away when I started using hand-picked hardware (ALFA AWUS036ACHM) and hand-picked minimalist OS (Tiny Core Linux) on my GNU/Linux box being used as a wireless router.

In other words, every problem I've ever encountered related to creating wifi hotspots were either due to poor hardware support or an OS that was getting in the way by doing things that I did not expect or desire.