Raspberry Pi Max WIFI Clients Bug

Here is a printout of /usr/lib/systemd/system/hostapd@.service:

[Unit]
Description=Advanced IEEE 802.11 AP and IEEE 802.1X/WPA/WPA2/EAP Authenticator (%I)
After=network.target
BindsTo=sys-subsystem-net-devices-%i.device

[Service]
Type=forking
PIDFile=/run/hostapd.%i.pid
Restart=on-failure
RestartSec=2
EnvironmentFile=-/etc/default/hostapd
ExecStart=/usr/sbin/hostapd -B -P /run/hostapd.%i.pid $DAEMON_OPTS /etc/hostapd/%i.conf

[Install]
WantedBy=multi-user.target sys-subsystem-net-devices-%i.device

hostapd@wlan0.service - Advanced IEEE 802.11 AP and IEEE 802.1X/WPA/WPA2/EAP Authenticator (wlan0)
Loaded: loaded (/lib/systemd/system/hostapd@.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2021-09-03 16:47:16 MDT; 17min ago
Main PID: 2336 (hostapd)
Tasks: 1 (limit: 3839)
CGroup: /system.slice/system-hostapd.slice/hostapd@wlan0.service
└─2336 /usr/sbin/hostapd -B -P /run/hostapd.wlan0.pid /etc/hostapd/wlan0.conf

Sep 03 16:47:16 rachel hostapd[2334]: Configuration file: /etc/hostapd/wlan0.conf
Sep 03 16:47:16 rachel hostapd[2334]: wlan0: Could not connect to kernel driver
Sep 03 16:47:16 rachel hostapd[2334]: Using interface wlan0 with hwaddr e4:5f:01:39:37:d7 and ssid “RPi-5g”
Sep 03 16:47:16 rachel hostapd[2334]: wlan0: interface state UNINITIALIZED->ENABLED
Sep 03 16:47:16 rachel hostapd[2334]: wlan0: AP-ENABLED
Sep 03 16:47:16 rachel systemd[1]: Started Advanced IEEE 802.11 AP and IEEE 802.1X/WPA/WPA2/EAP Authenticator (wlan0).
Sep 03 16:54:56 rachel hostapd[2336]: wlan0: STA 24:92:0e:25:3e:cc IEEE 802.11: associated
Sep 03 16:54:56 rachel hostapd[2336]: wlan0: STA 24:92:0e:25:3e:cc RADIUS: starting accounting session DB017C3014CFB1EA
Sep 03 17:01:34 rachel hostapd[2336]: wlan0: STA 24:92:0e:25:3e:cc IEEE 802.11: disassociated
Sep 03 17:01:34 rachel hostapd[2336]: wlan0: STA 24:92:0e:25:3e:cc IEEE 802.11: disassociated
~
hostapd@wlan1.service - Advanced IEEE 802.11 AP and IEEE 802.1X/WPA/WPA2/EAP Authenticator (wlan1)
Loaded: loaded (/lib/systemd/system/hostapd@.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2021-09-03 16:47:22 MDT; 18min ago
Main PID: 2349 (hostapd)
Tasks: 1 (limit: 3839)
CGroup: /system.slice/system-hostapd.slice/hostapd@wlan1.service
└─2349 /usr/sbin/hostapd -B -P /run/hostapd.wlan1.pid /etc/hostapd/wlan1.conf

Sep 03 16:48:51 rachel hostapd[2349]: wlan1: STA 24:92:0e:25:3e:cc IEEE 802.11: disassociated
Sep 03 17:01:42 rachel hostapd[2349]: wlan1: STA 24:92:0e:25:3e:cc IEEE 802.11: associated
Sep 03 17:01:42 rachel hostapd[2349]: wlan1: STA 24:92:0e:25:3e:cc RADIUS: starting accounting session 8DAC590D98A74154
Sep 03 17:01:42 rachel hostapd[2349]: wlan1: STA 24:92:0e:25:3e:cc IEEE 802.11: disassociated
Sep 03 17:01:42 rachel hostapd[2349]: wlan1: STA 24:92:0e:25:3e:cc IEEE 802.11: associated
Sep 03 17:01:42 rachel hostapd[2349]: wlan1: STA 24:92:0e:25:3e:cc RADIUS: starting accounting session 8D196CFEAF29043C
Sep 03 17:02:18 rachel hostapd[2349]: wlan1: STA 24:92:0e:25:3e:cc IEEE 802.11: disassociated
Sep 03 17:02:21 rachel hostapd[2349]: wlan1: STA 24:92:0e:25:3e:cc IEEE 802.11: associated
Sep 03 17:02:21 rachel hostapd[2349]: wlan1: STA 24:92:0e:25:3e:cc RADIUS: starting accounting session 0214FE16C6DC1573
Sep 03 17:02:58 rachel hostapd[2349]: wlan1: STA 24:92:0e:25:3e:cc IEEE 802.11: disassociated

iwconfig:
lo no wireless extensions.

eth0 no wireless extensions.

wlan0 IEEE 802.11 Mode:Master Tx-Power=31 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Power Management:on

wlan1 IEEE 802.11bg ESSID:“RPi-2g” Nickname:“WIFI@REALTEK
Mode:Master Frequency:2.412 GHz Access Point: 98:48:27:E1:7E:38
Bit Rate:54 Mb/s Sensitivity:0/0
Retry:off RTS thr:off Fragment thr:off
Power Management:off
Link Quality=1/100 Signal level=1/100 Noise level=0/100
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

/etc/default/hostapd :
DAEMON_CONF="/etc/hostapd/hostapd.conf" < — This the EnvironmentFile referenced by hostapd@.service ---- Why no %i. before conf?
~h

Hi @Techncat - What is the output of “sudo systemctl status dnsmasq” after you get a “failed to obtain ip address” error?

Status 1: after startup
dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2021-09-03 21:25:23 MDT; 12h ago
Process: 569 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, status=0/SUCCESS)
Process: 576 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, status=0/SUCCESS)
Process: 596 ExecStartPost=/etc/init.d/dnsmasq systemd-start-resolvconf (code=exited, status=0/SUCCESS)
Main PID: 593 (dnsmasq)
Tasks: 1 (limit: 3839)
CGroup: /system.slice/dnsmasq.service
└─593 /usr/sbin/dnsmasq -x /run/dnsmasq/dnsmasq.pid -u dnsmasq -r /run/dnsmasq/resolv.conf -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new

Sep 03 21:25:23 rachel dnsmasq[593]: started, version 2.80 cachesize 150
Sep 03 21:25:23 rachel dnsmasq[593]: compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detec
Sep 03 21:25:23 rachel dnsmasq[593]: warning: interface wlan0 does not currently exist
Sep 03 21:25:23 rachel dnsmasq-dhcp[593]: DHCP, IP range 11.11.11.100 – 11.11.11.199, lease time 1d
Sep 03 21:25:23 rachel dnsmasq-dhcp[593]: DHCP, IP range 10.10.10.100 – 10.10.10.199, lease time 1d
Sep 03 21:25:23 rachel dnsmasq[593]: reading /run/dnsmasq/resolv.conf
Sep 03 21:25:23 rachel dnsmasq[593]: using nameserver 192.168.0.1#53
Sep 03 21:25:23 rachel dnsmasq[593]: read /etc/hosts - 8 addresses
Sep 03 21:25:23 rachel dnsmasq[596]: Too few arguments.
Sep 03 21:25:23 rachel systemd[1]: Started dnsmasq - A lightweight DHCP and caching DNS server.

Status 2: Started SSID “RPi-2g” wlan1 “Obtaining Ip address” message keeps retrying after each time out
● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2021-09-03 21:25:23 MDT; 12h ago
Process: 569 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, status=0/SUCCESS)
Process: 576 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, status=0/SUCCESS)
Process: 596 ExecStartPost=/etc/init.d/dnsmasq systemd-start-resolvconf (code=exited, status=0/S
Main PID: 593 (dnsmasq)
Tasks: 1 (limit: 3839)
CGroup: /system.slice/dnsmasq.service
└─593 /usr/sbin/dnsmasq -x /run/dnsmasq/dnsmasq.pid -u dnsmasq -r /run/dnsmasq/resolv.c

Sep 03 21:25:23 rachel dnsmasq-dhcp[593]: DHCP, IP range 10.10.10.100 – 10.10.10.199, lease time
Sep 03 21:25:23 rachel dnsmasq[593]: reading /run/dnsmasq/resolv.conf
Sep 03 21:25:23 rachel dnsmasq[593]: using nameserver 192.168.0.1#53
Sep 03 21:25:23 rachel dnsmasq[593]: read /etc/hosts - 8 addresses
Sep 03 21:25:23 rachel dnsmasq[596]: Too few arguments.
Sep 03 21:25:23 rachel systemd[1]: Started dnsmasq - A lightweight DHCP and caching DNS server.
Sep 04 09:47:10 rachel dnsmasq-dhcp[593]: no address range available for DHCP request via wlan1
Sep 04 09:47:13 rachel dnsmasq-dhcp[593]: no address range available for DHCP request via wlan1
Sep 04 09:47:16 rachel dnsmasq-dhcp[593]: no address range available for DHCP request via wlan1
Sep 04 09:47:24 rachel dnsmasq-dhcp[593]: no address range available for DHCP request via wlan1
~
Status 3: wlan1 Rpi-2g flashes “IP Confguration Falure” before retrying again
dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2021-09-03 21:25:23 MDT; 12h ago
Process: 569 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, status=0/SUCCESS)
Process: 576 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, status=0/SUCCESS)
Process: 596 ExecStartPost=/etc/init.d/dnsmasq systemd-start-resolvconf (code=exited, status=0/SUCCESS)
Main PID: 593 (dnsmasq)
Tasks: 1 (limit: 3839)
CGroup: /system.slice/dnsmasq.service
└─593 /usr/sbin/dnsmasq -x /run/dnsmasq/dnsmasq.pid -u dnsmasq -r /run/dnsmasq/resolv.conf -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old

Sep 04 09:52:22 rachel dnsmasq-dhcp[593]: no address range available for DHCP request via wlan1
Sep 04 09:52:24 rachel dnsmasq-dhcp[593]: no address range available for DHCP request via wlan1
Sep 04 09:52:28 rachel dnsmasq-dhcp[593]: no address range available for DHCP request via wlan1
Sep 04 09:52:36 rachel dnsmasq-dhcp[593]: no address range available for DHCP request via wlan1
Sep 04 09:52:53 rachel dnsmasq-dhcp[593]: no address range available for DHCP request via wlan1
Sep 04 09:53:01 rachel dnsmasq-dhcp[593]: no address range available for DHCP request via wlan1
Sep 04 09:53:02 rachel dnsmasq-dhcp[593]: no address range available for DHCP request via wlan1
Sep 04 09:53:06 rachel dnsmasq-dhcp[593]: no address range available for DHCP request via wlan1
Sep 04 09:53:15 rachel dnsmasq-dhcp[593]: no address range available for DHCP request via wlan1
Sep 04 09:53:30 rachel dnsmasq-dhcp[593]: no address range available for DHCP request via wlan1

Status 4: Switching over from wlan1 to working wlan0 “RPi-5g” after it gets "Connected"
● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2021-09-03 21:25:23 MDT; 12h ago
Process: 569 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, status=0/SUCCESS)
Process: 576 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, status=0/SUCCESS)
Process: 596 ExecStartPost=/etc/init.d/dnsmasq systemd-start-resolvconf (code=exited, status=0/SUCCESS)
Main PID: 593 (dnsmasq)
Tasks: 1 (limit: 3839)
CGroup: /system.slice/dnsmasq.service
└─593 /usr/sbin/dnsmasq -x /run/dnsmasq/dnsmasq.pid -u dnsmasq -r /run/dnsmasq/resolv.conf -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new

Sep 04 09:52:53 rachel dnsmasq-dhcp[593]: no address range available for DHCP request via wlan1
Sep 04 09:53:01 rachel dnsmasq-dhcp[593]: no address range available for DHCP request via wlan1
Sep 04 09:53:02 rachel dnsmasq-dhcp[593]: no address range available for DHCP request via wlan1
Sep 04 09:53:06 rachel dnsmasq-dhcp[593]: no address range available for DHCP request via wlan1
Sep 04 09:53:15 rachel dnsmasq-dhcp[593]: no address range available for DHCP request via wlan1
Sep 04 09:53:30 rachel dnsmasq-dhcp[593]: no address range available for DHCP request via wlan1
Sep 04 10:00:02 rachel dnsmasq-dhcp[593]: DHCPDISCOVER(wlan0) d0:04:01:07:e4:4f
Sep 04 10:00:02 rachel dnsmasq-dhcp[593]: DHCPOFFER(wlan0) 10.10.10.165 d0:04:01:07:e4:4f
Sep 04 10:00:02 rachel dnsmasq-dhcp[593]: DHCPREQUEST(wlan0) 10.10.10.165 d0:04:01:07:e4:4f
Sep 04 10:00:02 rachel dnsmasq-dhcp[593]: DHCPACK(wlan0) 10.10.10.165 d0:04:01:07:e4:4f
~

This might also be of interest:
pi@rachel:~ $ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.107 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fe80::ba57:fd6d:cc66:9a12 prefixlen 64 scopeid 0x20
ether e4:5f:01:39:37:d6 txqueuelen 1000 (Ethernet)
RX packets 11771 bytes 5316126 (5.0 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 10780 bytes 2725731 (2.5 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1000 (Local Loopback)
RX packets 3715 bytes 1685824 (1.6 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3715 bytes 1685824 (1.6 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.10.10.10 netmask 255.255.255.0 broadcast 10.10.10.255
inet6 fe80::f79b:4cb3:5b04:9cde prefixlen 64 scopeid 0x20
ether e4:5f:01:39:37:d7 txqueuelen 1000 (Ethernet)
RX packets 6826 bytes 925978 (904.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 12213 bytes 14948439 (14.2 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

wlan1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 169.254.175.230 netmask 255.255.0.0 broadcast 169.254.255.255
inet6 fe80::42fe:691a:c4a4:4fa prefixlen 64 scopeid 0x20
ether 98:48:27:e1:7e:38 txqueuelen 1000 (Ethernet)
RX packets 4157 bytes 139262 (135.9 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 207 bytes 49215 (48.0 KiB)
TX errors 0 dropped 86 overruns 0 carrier 0 collisions 0

Try adding the 11.11.11.11 static IP address for wlan1 at the bottom of /etc/dhcpcd.conf, then reboot. That should help.

You fixed it! I can now connect to both wlan0 and wlan1 - Many thanks :+1:

One peculiarity I am observing: After boot, the order of the dongle and the Pi’s internal WiFi sometimes gets assigned to a different wlan, and the two get switched around. This seems to depend on whichever device is seen first! I can see this happening in iwconfig.

This creates a problem with an SSD connected via USB 3.0, because when the Pi 4’s WiFi gets connected to 2,4GHz it stops working because of the known USB 3.0 frequency interference issue,

But, we do seem to be getting closer :grinning:

1 Like

Glad that worked!

The interface name switching will be more complicated to fix. The only way I can think to get around that is to turn on predictive interface names. You should be able to do this from raspi-config

sudo raspi-config
    go to networking
    enable predictive interface names
    exit
sudo reboot now

Now instead of wlan0, wlan1, etc, you’d get something like wlp0s1 wlp3s1. That’s the new standard to set interface names based on their actual connections and not the boot order.

This is going to break all of the current settings we’ve just edited in files. You will need to go back and set those according to their new names.

If this does work, I will send you some files to fix the WIFI IP showing on the main page of RACHEL for you. We will also need to fix the iptables file for internet forwarding on both interfaces in /etc/iptables.ipv4.nat.

Getting closer indeed!

Hi @jamesk,
How do I derive these names? Specifically for the Pis internal WiFi. Will the two files replace wlan0 and wlan0?

You will have to make the switch to the new naming format, reboot, run ifconfig and check the output for the new names. Try

iw dev

as well. The USB one will say hopefully say “tp-link” somewhere for you to easily identify it.

The hostapd files should be renamed with the new interface names. The instanced “@” way of running the hostapd service seems to require that.

Hi @jamesk,

Before I launch into the above, I saw the following about adding priority to multiple networks in wpa_supplicant.conf.

Do you think something like this could also work for AP mode ?
Link:

Adding Multiple Wireless Network Configurations

On recent versions of Raspberry Pi OS, it is possible to set up multiple configurations for wireless networking. For example, you could set up one for home and one for school.
For example
network={
ssid=“SchoolNetworkSSID”
psk=“passwordSchool”
id_str=“school”
}

network={
ssid=“HomeNetworkSSID”
psk=“passwordHome”
id_str=“home”
}

If you have two networks in range, you can add the priority option to choose between them. The network in range, with the highest priority, will be the one that is connected.
network={
ssid=“HomeOneSSID”
psk=“passwordOne”
priority=1
id_str=“homeOne”
}
network={
ssid=“HomeTwoSSID”
psk=“passwordTwo”
priority=2
id_str=“homeTwo”
}

I see the following in our wpa_supplicant.conf file
network={
ssid=“RPi-2g” key_mgmt=NONE
}

Priority is to do with connectivity and network selection, not the interface naming. I think you’re going to have to change the interface naming for a proper solution.

@jamesk

Wow! your instructions worked perfectly. I will gather as many tablets as I can and do more exhaustive testing to see how both WiFi’s work simultaneously

After the predictive renaming, the TP-Link 2.4 GHz dongle now shows up as wlx984827e17e38, however the Pi’s WiFi stayed at wlan1. Will each TP-Link dongle of the same model have a unique “name” that must be changed before deployment or does it remain constant?

You mentioned that you have a way to update the Ip on the RACHEL main page - many thanks, you have made me a happy camper :grinning:

1 Like

Fantastic news! I’d love to hear the results of the Pi being configured this way. If there are dropouts still, if one interface is more reliable, etc.

The wlx984827e17e38 style naming is common for USB WIFI dongles and I believe that is the MAC Address of the interface. If we look above at the output of your ifconfig for wlan1

wlan1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 169.254.175.230 netmask 255.255.0.0 broadcast 169.254.255.255
inet6 fe80::42fe:691a:c4a4:4fa prefixlen 64 scopeid 0x20
ether 98:48:27:e1:7e:38 txqueuelen 1000 (Ethernet)
RX packets 4157 bytes 139262 (135.9 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 207 bytes 49215 (48.0 KiB)
TX errors 0 dropped 86 overruns 0 carrier 0 collisions 0

We can see the last part of wlx984827e17e38 as

ether 98:48:27:e1:7e:38

Now for the fun part. RACHEL’s contentshell parses the output of an ifconfig command to get the IP address and since it expects the names to be wlan0 and eth0, this needs to be changed. The function that shows the IP on the main page is in the /var/www/admin/common.php file. These are the instructions

  1. Download /var/www/admin/common.php from your RACHEL-Pi using WinSCP
  2. Navigate to line 806. You should see
function showip () {
  1. Scroll down a bit to line 821 and you should see
  if(is_rachelpi()){
        exec("/sbin/ifconfig", $output);
        preg_match("/(?:eth0|enp2s0).+?inet (.+?) /", join("", $output), $match);
        if (isset($match[1])) { echo "<b>LAN</b>: $match[1]\n"; }
        preg_match("/(?:wlan0|br\-lan).+?inet (.+?) /", join("", $output), $match);
        if (isset($match[1])) { echo "<br><b>WIFI</b>: $match[1]\n"; }
        return;
    }
  1. You will notice the interface names there. enp2s0 is the name for the ethernet interface on the RACHEL-Plus as it uses the new naming scheme too. This may already work for you for eth0, so if you see LAN: on your main page of RACHEL with an IP, don’t change that line.

  2. For WIFI, the following is looking for wlan0 or br-lan. Just change wlan0 to wlan1 or wlx984827e17e38

(?:wlan0|br\-lan) 

becomes

(?:wlx984827e17e38 |br\-lan)

  1. To add it for both interfaces, you will need to have it add a whole other line on the main page. This is echoed out, so it would look something like this when done.
    if(is_rachelpi()){
        exec("/sbin/ifconfig", $output);
        preg_match("/(?:eth0|enp2s0).+?inet (.+?) /", join("", $output), $match);
        if (isset($match[1])) { echo "<b>LAN</b>: $match[1]\n"; }
        preg_match("/(?:wlx984827e17e38 |br\-lan).+?inet (.+?) /", join("", $output), $match);
        if (isset($match[1])) { echo "<br><b>WIFI 2.4G</b>: $match[1]\n"; }
        preg_match("/(?:wlan1|br\-lan).+?inet (.+?) /", join("", $output), $match);
        if (isset($match[1])) { echo "<br><b>WIFI 5G</b>: $match[1]\n"; }
        return;
    }
  1. Transfer that file back to the device, overwriting the previous common.php, and then refresh the main page of RACHEL.

You can also alternatively edit the file directly on the device with

sudo nano /var/www/admin/common.php

I would definitely learn to use WinSCP to edit files and install notepad++ for editing this way. It’s way easier. If this works, I can look at solutions for automating finding the interface name in common.php.

All good @jamesk ! The RACHEL main page now shows both IPs as well.
Many thanks for sticking with me through this!
The SSD USB 3.0 2.4GHz interference with the Pi`s 2.4GHz WiFi is no longer an issue, since wlan1 now works exclusively on 5GHz.

1 Like

@Techncat - Awesome! You’re very welcome. I’m happy to see some innovative things happening around the Pi.

There may be one more step if you want internet forwarding working. You will need to edit

/etc/iptables.ipv4.nat

Since you have two WIFI interfaces now, you may need to duplicate the lines for the new interface and put the new names in place of wlan0. This file gets used to restore the iptables rules every time the device boots and lets users access the internet when available.

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i wlan1 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o wlan1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i wlx984827e17e38 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o wlx984827e17e38 -m state --state RELATED,ESTABLISHED -j ACCEPT

Other than that, glad it’s all going! let me know if you have any testing results.

Predictive names don’t seem to be getting assigned to wlan1.
I disconnected the dongle to see if the Pi’s 5G would still be assigned to wlan1. instead, after boot up wlan1 didn’t come up at all and ifconfig showed wlan0 as the Pi’s WiFi:

wlan0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
e4:5f:01:39:37:d7 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

I tried substituting e45f013937d7 as the Pi’s WiFi predictive name, but that doesn’t work.

when I power down and plug the dongle back in, the Pi’s WiFi is reassigned to wlan1 and everything works normally,
dmsg says:
systemd[1]: Unnecessary job for /sys/subsystem/net/devices/wlan1 was removed.
[ 4.744482] systemd[1]: Unnecessary job for /sys/subsystem/net/devices/wlan0 was removed.
[ 4.754298] systemd[1]: Unnecessary job for /sys/subsystem/net/devices/wlx984827e17e38 was removed.
[ 7.348488] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[ 7.350721] usbcore: registered new interface driver brcmfmac
[ 7.356469] usbcore: registered new interface driver 8188eu
[ 7.620384] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[ 7.620509] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[ 7.632414] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Jan 4 2021 19:56:29 version 7.45.229 (617f1f5 CY) FWID 01-2dbd9d2e
[ 7.992824] 8188eu 1-1.3:1.0 wlx984827e17e38: renamed from wlan0
[ 8.995096] random: 7 urandom warning(s) missed due to ratelimiting
[ 9.105892] 8021q: 802.1Q VLAN Support v1.8
[ 9.295035] Adding 102396k swap on /var/swap. Priority:-2 extents:4 across:147452k SSFS
[ 9.685007] bcmgenet fd580000.ethernet: configuring instance for external RGMII (RX delay)
[ 9.685827] bcmgenet fd580000.ethernet eth0: Link is Down
[ 10.015790] ==> rtl8188e_iol_efuse_patch
[ 10.259712] IPv6: ADDRCONF(NETDEV_CHANGE): wlx984827e17e38: link becomes ready
[ 10.289449] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[ 12.795260] bcmgenet fd580000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 12.795313] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 16.239017] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
[ 58.150937] fuse: init (API version 7.32)
pi@rachel:~ $

I don’t think wlan0 is considered a predictive name, so I don’t know if predictive naming is properly enabled. There’s only 1 wifi interface on the Pi since it can’t do dualband at the same time, so when the dongle is in it’s pushing the naming.

There are a few options you can try. Make sure you back up things before doing these ( make a disk image using win32diskimager ).

The first is to possible enable predictive naming properlly

edit /boot/cmdline.txt:and add "net.ifnames=1"
reboot

If that doesn’t change anything, you can try something like

ip link set wlan1 down
ip link set wlan1 name wlan0
ip link set wlan0 up

I highly suspect that would temporarily rename an interface rather than persist across reboots.

The more serious answer to this is likely going to be solmething this

https://community.mellanox.com/s/article/howto-change-network-interface-name-in-linux-permanently

Basically renaming based on mac address and setting a proper name. I don’t know if this will apply to raspios, but if it doesn’t I can help you look for a better answer if the others also failed.

Hi @jamesk, Because of time constraints, I will have to postpone further work on this project until we return in Nov. from our long overdue trip to visit family overseas.
.
There remain quite a few compatibility / reliability issues with incorporating dual Wifi and USB boot into our RACHEL Pi WiFi severs. These are mostly related to unpredictable wlan switching during bootup and very real software/ hardware interchangeabiliity problems in the field, since other dongles will have different MAC addresses.

It’s a very promising idea, and you have been exceedingly generous with all your help. :+1:

Many thanks!

1 Like

Hi @Techncat - Happy to help! It’s unfortunate that these bugs can affect things so much, but it’s generally expected with the the Pi. Even though it’s great, it definitely has it’s limitations with projects like this as we’re somewhat redesigning what it’s meant for. Still fun to try though :slight_smile:

Enjoy the trip and the visit with family. We can pick this up any time when you’re back.

James

I forgot to add that even though we were unable to get dual band WiFi working reliably, your help with adding the external USB dongle allowed us to find a way to replace the Pi’s SD card with the much faster and more reliable USB 3.0 adapter with an M.2 SSD without the Pi’s 2.4GHz WiFi interference shutdowns we were experiencing before…

After shutting off the Pi’s WiFi in /boot/config.txt as you outlined above, we have downloaded individual drivers for several different compatible Realtek WiFi dongles. They are all working very well in AP mode at 2.4GHz. I am also able to swap out the different dongles and they all come up as wlan0 after boot without requiring software modification.

I used the following updated steps by Mr. Engman for automatically verifying and installing the various Realtek dongle drivers:

sudo wget http://downloads.fars-robotics.net/wifi-drivers/install-wifi -O /usr/bin/install-wifi
sudo chmod +x /usr/bin/install-wifi
sudo install-wifi

1 Like