I was neither endorsing SysVinit nor saying there aren't better init systems. I was just answering the OP's question, which is misleading.

Good idea but no luck. I think we've excluded that the initial mac address is hardcoded in the firmware.

Hi pcalvert. That's a good thought, but not applicable to my setup. The settings you are referring to are wifi.scan-rand-mac-address and wifi.mac-address-randomization. I use MAC address filtering in my router, so definitely don't want my devices to connect using randomized MAC addresses. I can confirm that NetworkManager is not using any of these settings:

$ cd /etc/NetworkManager/
$ sudo grep -r 'mac-address' *
[no hits]

Plus, I dual boot Devuan and Tiny Core Linux. In the latter, MAC address of my wireless card is the same as what Devuan is showing me (i.e., 54:2a:a2:6a:xx:xx).

Ralph, I think your initial theory is sounds right: There must be a hardware MAC address, which the driver or firmware changes to what I think of as my "actual" MAC address.  A small amount of time (~2 seconds) elapses between wlan0 being brought up and the driver/firmware changing the MAC address.

EDIT: Ralph, if you run my trivial script in reply #2 as a startup job, can you reproduce my observation that MAC address changes? (Although exactly what happens--and when--likely depends on the specific hardware, driver, and firmware.)

Hi ralph.ronnquist. I'd love to get to the bottom of this if you can help me. I tried removing the firmware files to see what would happen. If I boot without the firmware, I get this (which is more or less what I expected):

$ cat /sys/class/net/wlan0/address
cat: /sys/class/net/wlan0/address: No such file or directory

What would be the best way to test your theory?

Hi Red_Fir. I've encountered your issue with some recent appimages:

$ ./foo.AppImage
fuse: failed to exec fusermount: Permission denied

I'm able to fix the problem like this:

$ export FUSERMOUNT_PROG=$(which fusermount)
$ ./foo.AppImage

The bug was introduced by recent changes in the tools used to create appimages and has nothing to do with Devuan. Old appimages that were working fine on Devuan 4 (Chimaera) are still working fine for me on Devuan 5 (Daedalus) without the above workaround.

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.

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.

For sake of completeness, here are two variations on the skinny-create-ap script in reply #18. Both are tested and working for me.

Variation 1: nftables instead of iptables
If you would rather use the more modern nftables packet filtering interface for linux, only two tweaks need to be made to the instructions in reply #18.

1. Packages to install:

sudo apt install iproute2 nftables dnsmasq hostapd haveged 

2. Replace the script's setup_nat() function with this version:

setup_nat()
{
	nft add table ip nat
	nft add chain ip nat postrouting { type nat hook postrouting priority 0\; policy accept\; }
	nft add rule ip nat postrouting masquerade
}

Variation 2: 5 GHz hotspot instead of 2.4 GHz
This assumes your hardware supports it.

For me, creating a 5 GHz hotspot is simply a matter of replacing the script's setup_ap() function with this version:

setup_ap()
{
	# create hostapd config file:
	echo "
ssid=$ssid
interface=$lan_if
driver=nl80211
country_code=US
channel=44
ignore_broadcast_ssid=0
hw_mode=a
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
ht_capab=[HT40+][HT40-][SHORT-GI-20][SHORT-GI-40]
" >/tmp/hostapd.conf

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

You may need to tweak the country_code, channel, and ht_capab variables, but the above settings are pretty vanilla.

I hope that reply #18 and this reply #21 provide all you need to setup your own GNU/Linux-powered router

Happy hacking!

----------

PS1: Regarding range--If you're going to have a GNU/Linux laptop working full-time as a wireless router, you should consider using a USB wifi adapter rather than laptop's built-in wireless card because it will give you much better signal strength/range. I've been using an ALFA AWUS036ACHM for this purpose for years and it has served me well. You can find information about USB wifi adapters on linux here.

PS2: On "router" vs. "wifi repeater"--This seems like a silly distinction. In both cases, the laptop is creating a wireless access point and forwarding packets between two networks. Conceptually, it makes no difference whether your device is sharing a wired or wireless internet connection. Put another way, a "wifi repeater" is just a special kind of router where the networks on both sides of the router have a wireless physical layer.

Hi mtbvfr. Thanks for the private message with the requested info.

I understand your laptop has a successful internet connection using ethernet cable on the eth0 nic, and you want to share that internet connection wirelessly by creating an access point on wlan0.

Based on the information you provided, it seems wlan0 is ready to be used for this purpose--its driver/firmware is loaded and it supports AP mode.

It seems create_ap is no longer maintained, so let's not bother with it.

I managed to get this working on Devuan Daedalus as follows:

0. No need to uninstall or disable NetworkManager if you have it

1. Install some packages:

sudo apt install iproute2 iptables dnsmasq hostapd haveged 

2. Create a script named skinny-create-ap somewhere in your PATH and make it executable. Script should look like this:

#!/bin/sh

# skinny-create-ap v2.3 (February 19, 2024)
# 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"
ip_stem=192.168.50
channel=6
#dns_server=1.1.1.1

main()
{
	prevent_nm_interference
	setup_kernel
	setup_nat
	setup_dhcp
	setup_ap
}

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

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

3. Run the script like this, for example:

sudo skinny-create-ap wlan0 eth0 DevuanHotspot TopSecret123

Now your wireless devices (e.g., Android phone) should be able to connect to DevuanHotspot using the password TopSecret123.

Let me know how you fare.

----------

PS1: Regarding radio frequency--the shell script above creates a 2.4 GHz 802.11n ("Wi-Fi 4") access point. 2.4 GHz is a good default because it has better range, simpler configuration, no regulatory issues, and broader hardware support in AP mode. If your wireless nic supports creation of 5 GHz AP and you would prefer 5 GHz, just tweak the "setup_ap" function as appropriate (let me know if you need help).

PS2: Regarding DNS lookups--if you want dnsmasq to tell wireless clients which dns sever to use, just uncomment the two lines where you see dns_server. If you leave those two lines commented, wireless clients will rely on the router (i.e., your laptop) to resolve domain names, which is a perfectly sane default.

PS3: To turn the hotspot off, run this command: sudo pkill hostapd; sudo pkill -f 'dnsmasq.*/tmp/dnsmasq.conf'

Hi penguin. I would give deepforest a warning for the inappropriate post if I could but, alas, I'm just a fellow user.

Have you tried setxkbmap? Start with setxkbmap -query to see what your current settings are for "model" and "layout". In my case, this is what I see:

$ setxkbmap -query
rules:      evdev
model:      pc105
layout:     us

To set available models, layouts, variants, and options, do this:

$ less /usr/share/X11/xkb/rules/evdev.lst

To change settings, this is the syntax:

$ setxkbmap [-model xkb_model] [-layout xkb_layout] [-variant xkb_variant] [-option xkb_options]

So to keep your current keyboard model and change to Russian layout, for example, do:

$ setxkbmap -layout ru

You mentioned that your Russian layout seems to have some characters off position. Maybe you are not using the Russian variant that has the positions you expect? Another possibility is that the keyboard model setting is not correct--look at your keyboard and compare it with internet images of different keyboard models to ensure that setxkbmap's "model" setting is correct for your hardware.

Yes, I think s2idle uses more battery than deep.
Switching to s2idle is the only fix I ever found that allowed the keyboard on one of my laptops to work after suspend. Sorry I couldn't help you find a satisfactory fix. Happy hacking!

Hi, rechvs. I once had a similar problem, where laptop keyboard was unresponsive after resuming from suspend. Laptop in question ran Devuan (I don't remember which version) and did have pm-utils installed.

The problem/solution may vary depending on exact hardware. For me, changing suspend method from the default "deep" (i.e., suspend-to-RAM) to "s2idle" (i.e., suspend-to-idle) solved the problem:

$ sudo sh -c "echo s2idle >/sys/power/mem_sleep"

Maybe so, but the affected laptop only has one (built-in) screen and the config file has no effect unless I use Device1.