There a different ways you could achieve what you want.
Method 1 – use systemd-networkd
If you want to use systemd just follow step 1 and step 3 of this tutorial. Just omit this command systemctl enable wpa_supplicant@wlan0, so wpa_supplicant won't bring your interface up at boot. If you want to start it manually run sudo systemctl start wpa_supplicant@...
The Tutorial you used is not up to date as it was written in 2013 and seems to be written for normal Ubuntu not Ubuntu Core.
I never used Ubuntu Core but they seem to use systemd-networkd:
By default network management on Ubuntu Core is handled by systemd's
networkd and netplan. While NetworkManager has some support to handle
netplan configuration ...
If you're meaning to access it on an operational Raspberry Pi: it's not in /boot, as other have explained.
If you're meaning to create it on an SD card on another computer: /boot is the small MS-DOS partition that shows up under Windows or Mac OS. You have to create the /boot/wpa_supplicant.conf yourself, and it will automatically be moved to the right ...
The boot partition is mounted to the directory /boot so you can just access it, for example with ls /boot.
But you will not find wpa_supplicant.conf there. It is located at /etc/wpa_supplicant/wpa_supplicant.conf.
You will need to get access to the wpa_supplicant.conf file located in:
Remove and mount the disk in another computer and modify the file..
-Obtain an HDMI cable for the Pi Zero W, a USB hub to connect mouse and keyboard. Edit through monitor. It's nice to have these 'tools' handy for this reason.
I suppose you have completely setup and running Building a 'Packet squirrel" using Raspberry Pi you have linked in your question. It is using systemd-networkd. If you want to extend it with WiFi you also have to use systemd-networkd, in particular to use *.network configuration files. So try this and add setup wpa_supplicant in addition to the existing ...
I'm sorry that I disturbed the members of the forum.
I found the solution!
It much easier than I thought:
Android Phone > Serial > Self built antenna with an Arduino > RFM95W > Raspberry Pi
I'm answering a bit late I think but a solution exists, and I think it's worth mentioning it.
For each interface, it's possible in dhcpcd.conf to specify an SSID for which the configuration below will be valid. To do so:
First stop dhcpcd (e.g run sudo systemctl stop dhcpcd)
Under your interface configuration write ssid <...
I haven't found any important differences between the wifi devices on RPi 3B, RPi 3B+ (yes, that supports 5 GHz) and RPi 4B. All my wifi setups where upstream compatible.
You are using Debian ifupdown. It may be possible that this old style networking get more and more out of the focus from the developers with newer versions of the operating system. In ...
You are mixing up different networking systems. As far as I can see it is old style Debian ifupdown managed in /etc/network/interfaces and Raspbian default networking dhcpcd. From the log I see a DHCPREQUEST from dhclient so I assume that you also use isc-dhcp-client in addition to dhcpcd. If so you have two dhcp clients running on your RasPi. This cannot ...
The installation of hostapd has changed since its latest update. If you have installed it with sudo apt install hostapd then its service is masked now. You have to configure it first and then unmask and enable it what you have done later. It should work now. I do not understand why it works the first time.
I suppose your internet router is using a 5 GHz band. As @jake already noted in his comment there is a limitation of the wifi device on the RasPi. In my tutorial you have used, you will find in section ♦ Details - hostapd (Step 2):
Please set the channel to the same value than wlan0 is connected to the wifi from your router. It is the restriction from the ...
Such behavior can be observed with failing arp resolution if resolution only works in one direction. Such errors are difficult to find and I don't know if it is your problem but it is worth to have look at it.
Just in theory how it could show your effects: with an arp request a device (here the RasPi) will broadcast an ethernet arp packet (not an ip packet) ...