DietPi-Config | WiFi Hotspot: Support for 2 WiFi adapters

[symbios24]

Hello is it possible to add a setting in the network options/adapters to use while installing a software the wifi connection instead of the ethernet that the modem is connected,i have setup my wifi connection from there but it keeps asking for the ethernet to install a software,particular i wanted to install the Hotspot so the internal wifi of the raspberry pi 3 will be used as a hotspot and another external wifi to be connected to as client to another access point to have internet that i already had setup,i managed to install wifi hotspot software but upon boot it keeps searching for the ethernet, i dont have a modem anymore so its not possible to use the hotspot like this

I want Dietpi to install and use any software by wifi and not by ethernet only

[MichaIng]

@symbios24 Many thanks for your input.

At least currently when installing Hotspot, DietPi expects an Ethernet connection for internet access while the WiFi is reserved for the Hotspot. AFAIK there is no way to use a single WiFi adapter for both, as Hostpot and to connect to the internet as well.

• I hope I understood your aim correctly at this point.

There is a request to allow using WiFi-only as Hotspot, but then for a local-only network without any internet capability.

Another idea is to allow 2 WiFi adapters, one as Hotspot and one to connect the AP itself to the internet, which would then be something like a repeater setup. €: Ah re-reading, I think this is what you actually want?

Generally I aim to make our network setup more flexible, so that you can configure each attached network adapter individually for a certain use, as default internet gateway, local network access only, or Hotspot.

[symbios24]

yes that is what i want to allow 2 WiFi adapters, one as Hotspot and one to connect the AP itself to the internet

thanks

[symbios24]

is it possible to do it manual for now before it can be added to dietpi pi?

[thaihugo]

I'm using this exact setup for years with excelent performance thanks to the wifi AC chip of the 3b+. I use an external usb wifi to connect to the access point, and internal wifi to serve my devices using the create_ap script with some optimisations that I can post on request. The only problem is that I cannot go to the network adapter part of the dietpi-config, as it will reset the ap config and break the connection as internal wifi will be reseted to client.

My optimisations are as following:

Fast wifi AC up to 300 mbits / seconds Firewall rules to create a real secure router (create_ap is a bit weak on this level) Fireqos to get some qos Switch to ethernet if wifi usb not present (in fact, selecting eth0 with create_ap will use usb wifi if available, and eth if not)

All this with pihole, kodi music, netdata and some java progam running in background

[thaihugo]

This is the create_ap conf with optimisations. The dns and dnsmasq are pihole, so not from create_ap, and this one uses wifi AC. Haveged is consuming too much cpu, and interace is eth0 as it will be replaced by usb wifi if present.

GATEWAY=192.168.99.100 SSID=Myssid SHARE_METHOD=nat WIFI_IFACE=wlan0 INTERNET_IFACE=eth0 CHANNEL=36 WPA_VERSION=2 ETC_HOSTS=0 #DHCP_DNS=1.1.1.1,8.8.8.8 DHCP_DNS=gateway NO_DNS=1 NO_DNSMASQ=1 HIDDEN=0 MAC_FILTER=0 MAC_FILTER_ACCEPT=/etc/hostapd/hostapd.accept ISOLATE_CLIENTS=0 IEEE80211N=1 IEEE80211AC=1 HT_CAPAB=[MAX-AMSDU-3839][HT40+][SHORT-GI-20][SHORT-GI-40][DSSS_CCK-40] VHT_CAPAB=[SHORT-GI-80][SU-BEAMFORMEE] DRIVER=nl80211 NO_VIRT=1 COUNTRY=US FREQ_BAND=5 NEW_MACADDR= DAEMONIZE=0 NO_HAVEGED=1 PASSPHRASE=Secretpass USE_PSK=0

[thaihugo]

create_ap.txt

This is the create_ap modified with bad scripting to put the rest of the parameters for the wifi. This part is important:

if [[ $IEEE80211AC -eq 1 ]]; then echo "ieee80211ac=1" >> $CONFDIR/hostapd.conf echo "obss_interval=300" >> $CONFDIR/hostapd.conf echo "require_vht=1" >> $CONFDIR/hostapd.conf echo "ieee80211h=1" >> $CONFDIR/hostapd.conf echo "vht_oper_chwidth=1" >> $CONFDIR/hostapd.conf echo "vht_oper_centr_freq_seg0_idx=$((${CHANNEL}+6))" >> $CONFDIR/hostapd.conf echo "basic_rates=180 240 360 480 540" >> $CONFDIR/hostapd.conf echo "disassoc_low_ack=0" >> $CONFDIR/hostapd.conf fi

[MichaIng]

@thaihugo Many thanks for sharing! 😃

Haveged is consuming too much cpu,

As you mention it. With v6.25 haveged will be installed on all DietPi systems. The reported issues without it are simply to drastic/critical, and became even worse since I think kernel 4.15 and some recent systemd update. Boot hangs, network hangs, service start timeouts and other things happen, that bad just for a small number of users, but potentially all systems can face them. For good reason it is at least mentioned in hostapd, since the demand of entropy raises much with this service. Half of the reported heavy problems due to empty entropy pool were in combination with hostapd up.

CPU usage is only there if cat /proc/sys/kernel/random/entropy_avail fails below the defined 1024 (KiB), so in case during early boot and when it is otherwise obviously required. Although if 1024 is a good boarder or not could be discussed. I did never face sudden drops > ~300 at least, so 512 could be sufficient in very most cases.

If empty entropy pool causes issues or not depends on how the software handles it. In the past this was often ignored by systemd/Debian but with recent versions they became stricter due to the security impact of missing/pseudo-random bits, which is why the issues became even more urgent on Buster system (network simply hangs before initial entropy has been filled).

Sorry to make this a topic here but since I am as well unhappy with the demand of an additional package+service, I am open for discussion/tuning or alternatives in case of other opinions or if someone simply has more experience/knowledge about this topic 😉: https://github.com/MichaIng/DietPi/issues/2806

[thaihugo]

@MichaIng I understand your problem, and I'll be happy to monitor this and report any fine tuning on the #2806. The Haveged service overuse is more because of a constant loop in the script. My guess is that the batch implementation of Create_ap (not hostapd) cannot call the service to see if it has worked and any system wait in bash can be a cpu hog by itself. So I would say that it's the Haveged call from create_ap script every 2 seconds that is a cpu hog.

[MichaIng]

@thaihugo That cannot be. haveged is a passive daemon that cannot be interacted with, nor does it ship any other binary.

But I just checked the code... https://github.com/oblique/create_ap/blob/master/create_ap#L418-L438

• It checks if entropy is below 1000
• If so, checks if haveged is installed
• If not, recommend it, else check if daemon is running
• If not, start it

That loop is a very bad implementation. The daemon itself already checks if entropy drops below the defined -w 1024 (default) argument and in case does it's job, and this in a muuuch more efficient way. These which, cat, pidof and in mutex_(un)lock external binary calls all there are a huge overhead. command -v, $(<file) and such bash internals should be used, which are tenth of times faster, if you already need to run a 2 seconds loop. But the whole loop is not required.

So yeah, totally reasonable to remove all that haveged part from create_ap then 👍. And seeing this I believe we will go with an own slim implementation to enable access points 😉. But until then, great to have such an alternative. Also the official one allows to skip all the haveged part by adding --no-haveged as command line argument.

[thaihugo]

Yes the script is a good starting point, but is too big where not needed and too small on important points.

If people want to use the same script before your own implementation on a 3b 2.4ghz device, here is the corresponding config which must be used with the official create_ap or my modification (I don't think I modified the 2.4 ghz part of the script.

Again, dns and dhcp (dnsmasq) done by pi hole, you must put them to 0 if you are not using it. Also note that IOS will reject the dual band 2.4 ghz and force the router to a single band if you try a larger one.

GATEWAY=192.168.99.100 SSID=Yourssid SHARE_METHOD=nat WIFI_IFACE=wlan0 INTERNET_IFACE=eth0 CHANNEL=6 WPA_VERSION=2 ETC_HOSTS=0 #DHCP_DNS=1.1.1.1,8.8.8.8 DHCP_DNS=gateway NO_DNS=1 NO_DNSMASQ=1 HIDDEN=0 MAC_FILTER=0 MAC_FILTER_ACCEPT=/etc/hostapd/hostapd.accept ISOLATE_CLIENTS=0 IEEE80211N=1 IEEE80211AC=0 HT_CAPAB=[MAX-AMSDU-3839][HT40+][SHORT-GI-20][SHORT-GI-40][DSSS_CCK-40] DRIVER=nl80211 NO_VIRT=1 COUNTRY=US FREQ_BAND=2.4 NEW_MACADDR= DAEMONIZE=0 NO_HAVEGED=1 PASSPHRASE=Secretword USE_PSK=0

[symbios24]

hi when this will be added to dietpi? :WiFi Hotspot: Support for 2 WiFi adapters

[MichaIng]

@symbios24 I hope we can manage it for v6.26, however there are two other tasks to do first and it is a larger project since some deeper rewrite of our network setup needs to be done first.

[dequeant]

This would be awesome.

I want to use one of my old Pi3Bs as a "travel router" with a built in VPN, pi-hole, etc. The goal is to be able to take it with me and when I get into a hotel, I connect to the hotel wifi with my Pi, which hosts as an accesspoint that is VPN'd to my home network.

[snix47]

@dequeant
There is this neat solution out there: https://github.com/billz/raspap-webgui Perhaps it could be incorporated in the fantastic diet-pi package in the future.

[MichaIng]

@snix47 Me aiming for a lightweight console-based solution, however if one wants a web UI, this is indeed pretty beautiful.

[snix47]

@snix47 Me aiming for a lightweight console-based solution, however if one wants a web UI, this is indeed pretty beautiful.

So, I´ve tried the raspap-webgui, it is pretty indeed, however on the diet-pi it does not wanna play, on standard raspberry it works just fine. The functionality though, with or without web is pretty freakin great, the pi acting as router with nat(ing) and a hotspot, perfect for hotels and travel. Myself I run a plex server and wifi hotspot on a pi for the kids pleasure (good in the car and hotels), I do miss the diet-pi beeing able to hookup to Internet via wifi or cable and nat that aswell over the wifi pi-hotspot.

[Waxhaw]

Is there a way to PICK one Wifi device over another one? I thought I would add this to the request as it could impact implementation.

I'm on an Orange Pi Zero LTS device (ARM H2+ 32-bit).

It has an internal Wifi chipset that sucks so bad I've added a COMFAST USB Wifi adapter.

Here is my "ip a" output for wlan0:

3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 12:42:ac:8b:f8:22 brd ff:ff:ff:ff:ff:ff
    inet 192.168.42.1/24 brd 192.168.42.255 scope global wlan0
       valid_lft forever preferred_lft forever
    inet6 fe80::1042:acff:fe8b:f822/64 scope link 
       valid_lft forever preferred_lft forever

Here is what I get from the "lsusb command": Bus 003 Device 003: ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter

uname -a returns: Linux DnpPi 5.3.5+ #2 SMP Fri Nov 15 16:24:33 CST 2019 armv7l GNU/Linux

As much as I love DietPi I don't see an easy way to FORCE it to use the better Wifi dongle. No way to build a driver for this thing either. While I'm at it I ported DietPI from Debian Buster which has support built into the kernel for it. Just seems weird this doesn't work.

[MichaIng]

Probably the onboard WLAN can be disabled via device tree overlay, if your kernel ships some?

Otherwise edit /etc/network/interfaces and manually replace wlan0 with wlan1.

[Waxhaw]

Probably the onboard WLAN can be disabled via device tree overlay, if your kernel ships some?

Otherwise edit /etc/network/interfaces and manually replace wlan0 with wlan1.

Thanks for trying to help. I can't seem to get DietPI to see my USB WiFi if it sees one on the board.

Changing the interfaces file doesn't do anything to help me because I'm running this as a HotSpot.

so 'ip a' shows:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 02:42:44:5d:22:a3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.5/24 brd 192.168.2.255 scope global dynamic eth0
       valid_lft 85516sec preferred_lft 85516sec
    inet6 fe80::42:44ff:fe5d:22a3/64 scope link 
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 12:42:44:5d:22:a3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.42.1/24 brd 192.168.42.255 scope global wlan0
       valid_lft forever preferred_lft forever

And 'lsusb' shows:

Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 002: ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

I would have expected to see the Nickname of "WIFI@REALTEK" show up in my ip listing above. That's what Ubuntu 64-bit shows for that USB WiFi adapter on my R Pi 4.

Any thoughts on how I can FORCE the HotSpot to use the better Wifi Adapter? Thanks!

[MichaIng]

Okay, so the hardware itself is not detected as network adapter. So indeed a driver is required first.

lsusb successfully detects it as Realtek WiFi adapter. apt install firmware-realtek is installed as expected? It actually includes firmware for RTL8188EU: https://packages.debian.org/buster/firmware-realtek

And there seems to be a kernel driver: modinfo r8188eu Could you check if it's leaded: lsmod | grep 8188 Otherwise lead it: modprobe r8188eu And check back: ip l

Last resort would be compiling from sources: https://github.com/lwfinger/rtl8188eu

[Waxhaw]

Thank you sir!

Here is what I see:

/sbin/modinfo r8188eu
modinfo: ERROR: Module r8188eu not found.

root@DietPi:/home/dietpi# /sbin/lsmod | grep 8188
root@DietPi:/home/dietpi# /bin/lsmod | grep 8188
root@DietPi:/home/dietpi# 

root@DietPi:/home/dietpi# /sbin/modprobe r8188eu
modprobe: FATAL: Module r8188eu not found in directory /lib/modules/5.3.5+

root@DietPi:/home/dietpi# ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 02:42:ac:8b:f8:22 brd ff:ff:ff:ff:ff:ff
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000
    link/ether 12:42:ac:8b:f8:22 brd ff:ff:ff:ff:ff:ff

[MichaIng]

Ah the r8188eu is available on RPi, but you're using an Orange Pi. Let's search the modules for a fitting one:

find /lib/modules -name '*8188*'

[Waxhaw]

that command returns nothing for me... :-( blues

Thank you for all you've done to try and help me.

Just so you know, I went to the legacy download for the Orange PI. Then I changed the /etc/apt/sources.list to this:

deb https://deb.debian.org/debian/ buster main contrib non-free
deb https://deb.debian.org/debian/ buster-updates main contrib non-free
deb https://deb.debian.org/debian-security/ buster/updates main contrib non-free
deb https://deb.debian.org/debian/ buster-backports main contrib non-free

What was originally there were servers pointing to China and it was the previous version.

So first thing I did was point it to standard servers. Did the update/upgrade/install. Then I updated it to 'buster' and did the distro-upgrade.

Then I went and ran your script to convert to DietPI found here: https://github.com/MichaIng/DietPi/issues/1285

Cheers

[Waxhaw]

I've got an Armbian converted device is you prefer. What's interesting is the Armbian shows this:

 ─────────────────────────────────────────────────────
 DietPi v6.34.3 : 08:28 - Wed 02/03/21
 ─────────────────────────────────────────────────────
 - Device model : OrangePi Zero (armv7l)
 - CPU temp : 21'C : 69'F (Who put me in the freezer!)
 - LAN IP : 192.168.2.5 (eth0)
 - MOTD : Pi-hole users, please run "pihole -up" to fix security issues in dnsmasq:
          https://pi-hole.net/2021/01/19/pi-hole-ftl-v5-5-released-update-today/
 ─────────────────────────────────────────────────────

 DietPi Team     : MichaIng (lead), Daniel Knight (founder), Joulinar (support)
 Image           : DNP (pre-image: Armbian)
 Web             : https://dietpi.com | https://twitter.com/DietPi_
 Donate          : https://dietpi.com/#donate
 DietPi Hosting  : Powered by https://myvirtualserver.com

While the Debian device shows this:

 ─────────────────────────────────────────────────────
 DietPi v6.34.3 : 11:18 - Wed 02/03/21
 ─────────────────────────────────────────────────────
 - Device model : OrangePi Zero (armv7l)
 - CPU temp : -240064'C : -432083'F (Who put me in the freezer!)
 - LAN IP : 192.168.2.2 (eth0)
 - MOTD : Pi-hole users, please run "pihole -up" to fix security issues in dnsmasq:
          https://pi-hole.net/2021/01/19/pi-hole-ftl-v5-5-released-update-today/
 ─────────────────────────────────────────────────────

 DietPi Team     : MichaIng (lead), Daniel Knight (founder), Joulinar (support)
 Image           : DNP (pre-image: Debian Buster)
 Web             : https://dietpi.com | https://twitter.com/DietPi_
 Donate          : https://dietpi.com/#donate
 DietPi Hosting  : Powered by https://myvirtualserver.com

Notice the Debian Buster flavor has it's temps whacked. Makes me wonder if for some reason it's being treated as a 64-bit device instead of a 32-bit H2+ device.

[MichaIng]

Every kernel has it's own temperature tunables. You can check it via:

for i in /sys/class/thermal/thermal_zone[0-9]/temp /sys/class/hwmon/hwmon[0-9]/temp[0-9]_input /sys/devices/platform/coretemp.[0-9]/hwmon/hwmon[0-9]/temp[0-9]_input
do
[[ -e $i ]] && echo "$i : $(<$i)"
done

If a simple fallback is sufficient to fix that, I can do it, but when it causes incompatibility between images, I'd leave it so that the up-to-date Armbian image+kernel works.

Btw does the WiFi adapter work on the Armbian-based image? The Orange Pi manufacturer images are generally not great, from what I remember, so I'd go with Armbian and their mainline kernel approach, as long as there is not some feature missing. And of course the distro upgrade can be skipped. Btw. DietPi-PREP can do the distro upgrade as well. If it's a Stretch image, you can still select Buster at the distro version prompt 🙂.

Makes me wonder if for some reason it's being treated as a 64-bit device instead of a 32-bit H2+ device.

It's correctly detected as ARMv7 (32-bit) in both cases. Any aarch64 image would not boot and uname -m cannot be wrong, unless broken.

[Waxhaw]

Do you have a tip jar? :-)

Thanks for all of the great support. Much appreciated.

[MichaIng]

See the "Sponsor" button at the top of the GitHub site 🙂.

[Waxhaw]

Btw does the WiFi adapter work on the Armbian-based image?

No it's the identical situation and issue. Which stinks. The r8188eu is a critical hardware component for my current build.

[MichaIng]

The driver is in staging state (https://github.com/raspberrypi/linux/tree/rpi-5.10.y/drivers/staging/rtl8188eu), probably that's the reason why it's not compiled with default build config. Also they had issues to compile it: https://github.com/armbian/build/issues/2558 I just verified, it's not part of the Armbian images currently. Also on RPi it's one of a very few staging drivers, that are compiled, so nothing to blame anyone for until it become enough stable and tested to get out of staging:

2021-02-04 20:47:56 root@micha:/mnt/sda# l /lib/modules/5.10.11-v7+/kernel/drivers/staging/
total 24K
drwxrwxr-x 2 root root 4.0K Jan 28 13:16 fbtft
drwxrwxr-x 2 root root 4.0K Jan 28 13:16 rtl8188eu
drwxrwxr-x 2 root root 4.0K Jan 28 13:16 rtl8712
drwxrwxr-x 8 root root 4.0K Jan 28 13:16 vc04_services
drwxrwxr-x 2 root root 4.0K Jan 28 13:16 vt6656
drwxrwxr-x 2 root root 4.0K Jan 28 13:16 wlan-ng

It looks like if you want to use this adapter on Linux, either you need to be lucky to have the module shipped with the kernel or compile it yourself, which then likely requires some experience and tinkering as of above link it doesn't work OOTB 😢.

[creed81]

@symbios24 I hope we can manage it for v6.26, however there are two other tasks to do first and it is a larger project since some deeper rewrite of our network setup needs to be done first.

Hi @MichaIng, would it be possible to add a minimal CLI to perform wifi-to-wifi hotspot in the upcoming releases? We need to use Raspberry pi os to do that currently and miss out on a lot of baked in functionality offered by Diet-Pi