Magical suggestions you find on the web often don't work and there is no reason why this bizarre approach would work.
What happens if you get rid of the static IP address and strange script?
Most of the script is operating on the obsolete Debian networking which is not used in Raspberry Pi OS.
If it doesn't work on Pi3+ and Pi4 the most likely cause is ...
ifup will not work with wireless, you should rather use iwconfig wlan0.
On my system, sudo rfkill unblock 0 followed by iwlist wlan0 scan works fine. There's no need for sudo in the second command. It could be that you have installed several network managers at the same time, or using the wireless interface in AP mode.
If a DNS request to specific URLS isn't a success but also does not trigger a redirect then your Pi won't show the captive portal page and you will end up in this situation. This points to a DNS server configuration problem on your end, as any request to a domain not on your network should be sent to the Rpi for redirection. That is my initial thought, but I ...
This sounds like a issue with the access from external.
What is the difference between the two Raspberry Pi's you can access from external and the five Pi's who are not able the be accessed from external? Are they the same hardware? Are the 5 Pi's are clones?
When you can access all from the office (same wifi) it has to be an issue with incoming connections ...
I had the same problem a couple of years ago. I googled and found it a known/confirmed linux related bug, and all linux experts said it was related to linux kernel and could not fix. So I wait for the linux update. I tried kernel update for one or two years, but the bug was still there. So I gave up and forgot.
Some months ago when I was updating my ...
I suggest that rather than trying to set a static IP Address you request the DHCP server to assign a predictable IP Address. See https://raspberrypi.stackexchange.com/a/121830/8697
The Pi WILL "work out of the box" - it is designed to use DHCP.
The values you are are attempting to assign seem to be inconsistent with your router, but you haven't ...
I doubt that disabling WiFi is the solution.
The on-board WiFi will normally be wlan0, but there is a potential race condition.
I suggest you Enable predictable network i/f names in the Advanced option of raspi_config.
Your other interfaces will then have names like wlx00c140123456
You can then add denyinterfaces wlan0 to the end of /etc/dhcpcd.conf to ...
Note that all your RX errors are "frame" errors, which means incomplete or corrupted network frames were received by the network interface and discarded. Unlike "dropped" (which mean you receive frames you don't expect) or "overrun" (which means the system is overloaded), these errors cannot be fixed by configuration.
The easiest way (that I've found) to programmatically make this message go away was to add the following to /boot/config.txt:
Yes, this does disable WiFi, but that was not a constraint in the original question (in other words, the question didn't say that disabling WiFi was unacceptable).
While I was at it, I also disabled Bluetooth, ...
No matter what I tried the raspi-config always failed with:
Could not communicate with wpa_supplicant
I already had the country code in the /etc/wpa_applicant/wpa_applicant.conf too.
In the end I used the rfkill command to enable it manually.
# rfkill unblock wifi
This seems to preserve the unblocked status, at least through warm-reboots.
Then (with quite ...
assuming it was actually in a file somewhere, lets say your ip is 126.96.36.199. you may be able to find it using this command:
grep -r 188.8.131.52 /etc
this will show you each file under the /etc hierarchy that has the string 184.108.40.206 in it. if you really get desperate, maybe sudo grep -r 220.127.116.11 / (the entire filesystem)
you could set up each pi to periodically run 'iwconfig' and dump output into an html file, (like with a cron job or boot up script) then have a simple web server running on each pi, like nginx. connect to each pi from the desktop and retrieve the html data. (you could also dump the output of vcgencmd measure_temp )
As you can see, it makes nothing.
Because the interface is already up!
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
This is what 'ip link set' controls ^^ Not this ^^^^
What toggling the first one actually means may depend on the interface type1, but one thing ...