ag123

@av4625 there is one experiment that I did not try which is to play with wpa_supplicant with its own /etc/wpa_supplicant.conf if it works, it'd likely point to a problem in network manager itself, possibly that network manager is sending the 'wrong' commands. However, as I couldn't figure out how to work that with network manager, possibly conflicts since network manager is intended to control it via the unix socket? redoing the 'whole' thing by having network manager unmanage the wifi interface is another test, but I did not try that due to the effort involved.

@av4625 I tried setting up WiFI AP using Network Manager which in turns uses wpa_supplicant. The configuration is actually 'much' easier than this current manual method using hostapd. 1st install dnsmasq (without this I found errors in journalctl -u NetworkManager logs saying that dnsmasq is not accessible) apt install dnsmasq then the following needs to be done using the usb uart serial debug dongle on the 3 serial pins. to configure the upstream *ethernet* interface it is nmcli c add "Wired connection 1" ifname end0 type ethernet That creates the network manager connection for the ethernet interface and it obtains its address via dhcp Hang / no response while half way working with usb uart serial debug dongle Some troubles while working in the usb uart serial debug dongle, it occasionally (quite frequently) hangs for uncertain reasons, no response in terminal. The terminal app I used is putty https://www.putty.org/ There is actually 'no solution' to the serial debug hang issue. I'm halfway suspecting that it may be due to loose connections, but I can't prove it. I used cheap usb-uart dongles like these https://www.aliexpress.com/w/wholesale-usb-uart.html solution to serial debug hang What I actually did to 'overcome' this is that I first configure the ethernet to work correctly in network manager (as above using nmcli). after that useful tip, install avahi (mDNS https://en.wikipedia.org/wiki/Multicast_DNS ) apt install avahi-daemon apt install avahi-utils then in /etc/avahi/avahi-daemon.conf [server] publish-workstation=yes then I look for that over the network using avahi-browse -a to search for the board in the lan. it is then simple to ssh into that e.g. ssh user@orangepizero3.local The ethernet connection proved to be more stable than the 'usb uart serial debug' monitor route. ------ configuring the WiFi AP. nmcli d wifi hotspot ifname wlan0 ssid testspot password 12345678 The good thing about NetworkManager with this is that it configures and setup the WiFi hotspot, configures all that necessary routing, setup ip masquadering through the other interface ( i.e. ipv4.method = shared ), configures dnsmasq. Everything with this 'simple looking' command line. devices are unable to connect with / without password I'm able to reproduce the various troubles that you are encountering. e.g. it is not possible to connect after playing with the various wpa / wpa 2 settings including things like key-mgmt, pairwise, group etc. I tried specifying 'tkip, ccmp' for both pairwise and group, didn't work. I run wpa_ctl status like what you see the key-mgmt is 'unknown'. I set "log_level debug" < yup just this statement in the prompt, then run journalctl -fu wpa_supplicant. The trouble is I've troubles connecting, but that nothing shows in the log during my connection attempts. I googled around next, apparently wpa_supplicant has its own large set of knobs (parameters) to play with https://web.mit.edu/freebsd/head/contrib/wpa/wpa_supplicant/wpa_supplicant.conf ^ what is quite interesting in this example is that key-mgmt do have the various options in network manager, but that in wpa_ctl , and running "status" command shows that to be 'unknown'. solution to 'NetworkManager' AP Actually, I 'don't have a solution'. Rather, I'm not sure where and what to tweak to try to make wpa_supplicant work with Network Manager. I tried creating a /etc/wpa_supplicant.conf play with some values, more occasional hangs etc, but did not solve the problem, i.e. journalctl -fu wpa_supplicant don't show any entries and I can't connect from my android phone. Then I switched back to my hostapd based setup in prior comment. it 'just works', practically 'no nonsense' The trouble with hostapd based setup is that you have more work to do (unlike that nmcli one liner to create an AP) if you want to run a routed setup as discussed in the prior comment. I'd guess that you could adapt that 'bridged' setup, e.g. doing that and running dhcp (e.g. dnsmasq or isc-dhcp-server, you would need to configure it separately) https://gist.github.com/ag88/de02933ba65500376d1ff48e504b1bf3 could be a possible setup. The catch is that when you connect through ethernet, that dhcp is running on the bridge and if you have another dhcp server in the lan, things can be somewhat messy. the other ways would be to do a truly routed setup as discussed in prior comments. Configuring the WiFI interface as 'ethernet' in Network manager I'm not too sure if it is quite possible to setup the 'wifi' interface as 'ethernet' in network manager (e.g. nmcli). e.g. nmcli c add "WiFI connection" ifname wlan0 type ethernet ipv4.method manual ipv4.address <IP>/<prefix> ipv4.gateway <GW-address> ^ I'd guess ipv4.method = shared and without those ipv4.address, ipv4.gateway params may be possible with this which would do ip masquadering through the other (ethernet) interface use ip -4 add and/or ip route, to check what addresses and subnet gets assigned to wifi interface (wlan0) if you used ipv4.method = shared That is needed for the dhcp server below. Note check also if network manager 'automatically' configures dnsmasq as dhcp server by using ipv4.method = shared, which would make that extra step to configure dnsnmasq below redundant, unnecessary. 'everything' can be configured in network manager if this works. I've not tried this, but that if this is feasible, it would save some effort trying to set an ip address and routing for the wifi interface. I'd guess hostapd should still be able to run on top of that as hostapd doesn't bother about the ip and routing stuff. The bridge (bridge=br0) is not needed in hostapd.conf in this case. and with this it is not necessary to 'unmanage' the wifi interface in network manager i.e. that /etc/NetworkManager/conf.d/99-unmanaged-devices.conf is not required And in addition, you would still need to install and configure dhcp (dnsmasq or isc-dhcp-server) to provide the connecting devices with ip address and dns address. note: see that ipv4.method = shared above. This step may not be needed. oh and systemctl disable wpa_supplicant, I'm not too sure if hostapd would conflict with wpa_supplicant (I'd guess quite possible, they do pretty much similar and contradictory system calls. Hostapd runs an AP, wpa_supplicant mainly tries to setup a wifi client) do report on if this is feasible / successful / issues etc if you try this

@av4625 here are some of my thoughts, as discussed prior, wpa_supplicant and / or hostapd is The 'library' that does *all* of WPA/WPA2/WPA3 https://w1.fi/wpa_supplicant/devel/ The design goal for wpa_supplicant was to use hardware, driver, and OS independent, portable C code for all WPA functionality The design goal for hostapd was to use hardware, driver, and OS independent, portable C code for all WPA functionality. That means selecting either wpa_supplicant or hostapd would provide the wifi AP functionality specifically for WPA / WPA2 and authentication. Using hostapd apparently has 'better' logging as the access attempt is logged journalctl -u hostapd there are some messages, some abstracts from my logs STA mac_addr IEEE 802.11: associated STA mac_addr RADIUS: starting accounting session 63AA93B230BE083E STA mac_addr WPA: pairwise key handshake completed (RSN) STA mac_addr WPA: group key handshake completed (RSN) STA mac_addr IEEE 802.11: disassociated this helps ascertain that the connection / WPA / WPA2 is established and authentication is successful From prior discussions, it seemed NetworkManager uses wpa_supplicant. In my case, I find the lack of logs 'opaque' and lacks info for adequate troubleshooting. I'm also unsure if I can adequately separate the concerns with Network Manager with an AP, i.e. hostapd itself (for WPA/WPA2 and authentication), then dhcp to provide (to connecting clients) ip address and dns address, ipv6 router advertisements etc and in addition to setup a bridge separate from the wifi interface itself. And in part, hostapd apparently provides significantly more detailed configuration, in particular for the various features supported by wifi itself. https://web.mit.edu/freebsd/head/contrib/wpa/hostapd/hostapd.conf Hence, I choose to use hostapd instead. However, given those documentations, https://w1.fi/wpa_supplicant/devel/, it'd seem that hostapd and wpa_supplicant are likely equivalent. just that i'm more familiar with hostapd currently. Hence, in my setup. I've Network Manager omit setting up the wifi interface. /etc/NetworkManager/conf.d/99-unmanaged-devices.conf [keyfile] unmanaged-devices=interface-name:wlan0 Network manager, however, is used to setup the bridge and manage the ethernet interface, configured using nmcli. Then hostapd is configured to patch the wifi interface into the bridge after hostapd is running. /etc/hostapd/hostapd.conf bridge=br0 Networkmanager configuration of the bridge looks like this > nmcli c NAME UUID TYPE DEVICE bridge d0fc7d8a-51ea-4c5d-a297-943e2a037cff bridge br0 lo 59201f46-2fff-4f67-9822-7019cea62cf5 loopback lo br-eth 29c02c5c-4d75-4e03-bb71-8a761e076562 ethernet end0 > sudo brctl show bridge name bridge id STP enabled interfaces br0 8000.xxyy yes end0 wlan0 Here, wlan0 is patched into the bridge by hostapd. Note the race condition issue discussed 3 comments prior. The ethernet connection should be visible in NetworkManager in the default configuration e.g. as "Wired connection 1" Then to setup the bridge I used a bunch of nmcli commands https://gist.github.com/ag88/de02933ba65500376d1ff48e504b1bf3 nmcli con down "Wired connection 1" nmcli con del "Wired connection 1" nmcli con add connection.id bridge type bridge ifname br0 nmcli con add connection.id br-eth type bridge-slave ifname end0 master br0 #this is for dynamic (dhcp IP address) #nmcli c modify bridge ipv4.method auto #this is for fixed ip address, and assume that your gateway router is at 192.168.1.1 nmcli c modify bridge ipv4.method manual ipv4.addresses 192.168.1.10/24 ipv4.gateway 192.168.1.1 In the above I removed the default Ethernet connection and replaced that with a bridge setup. The above can only be done via a 'usb-uart serial debug' bridge/dongle on the 3 serial pins for the serial console. i.e. you can't work from ssh into the ethernet connection and change the network configs. This is for the bridged setup. For a routed setup, my thoughts are that the 'missing' things are configure ip address and routing for the wifi (wlan0) interface (this would need to be done outside NetworkManager if it isn't managing it) run a dhcp server to provide connecting clients with ip address and dns address (this can be provided by dnsmasq or a dhcp server (e.g. isc-dhcp-server). (other services to run can included ipv6 router advertisements (radvd or dnsmasq does that), avahi (multi-cast DNS) etc) configure 'upstream' routing / forwarding through the ethernet (end0) Those are covered to some extent in the prior discussions. If you managed to run a succcessful setup say with hostapd, my guess is that you could likely migrate/convert that into a completely NetworkManager setup which uses wpa_supplicant internally. It could possibly be 'less verbose' as compared to these setups which requires a lot of additional manual configuration as like above.

@jimg thanks. Nothing wrong or against a routed configuration, just that a routed configuration needs the various routers to 'play well together'. In fact, I preferred a routed configuration as it separates the LAN segments, just that a routed config need more planning e.g. if there are more than a single router. I'm using bridge config partly as the central router handles dhcp etc. one of the 'problems' that I confront is ipv6 router advertisements https://en.wikipedia.org/wiki/Radvd https://en.wikipedia.org/wiki/IPv6#Stateless_address_autoconfiguration_(SLAAC) As my isp provides only a /64 'network', I kind of am 'out of options' as IPV6 normally reserves the entire lower 64 bits as the 'host' part. Hence, it is not possible to subnet the lower /64 network. That leaves practically only bridging as the only option for the subnets. Then that these OPi Zero 3 APs are 'mesh' APs and that a slight benefit here is that using bridges makes them 'auto' configuring, i.e. the same AP can be 'shifted' around to other network points and it 'just works' without re-configuring. Routing can achieve similar effect, but that a routing daemon is needed, static routing may have some limitations for 'auto' configuring in this respects. I've not tried netplan and I think I should try it out. Apparently netplan currently, only supports NetworkManager for AP https://netplan.readthedocs.io/en/stable/netplan-yaml/#properties-for-device-type-wifis and it seemed the 'workaround', is to only have netplan setup the ip address of the wifi interface https://eternaltinkering.com/blog/ubuntu-server-wifi-ap.html hostapd etc would be separate from that.

yes this is useful I added in /etc/NetworkManager/conf.d/99-unmanaged-devices.conf [keyfile] unmanaged-devices=interface-name:wlan0 Network Manager can still manage the end0 (ethernet) interface which is what I did. In fact, I used Network manager to setup a bridge and let hostapd patch wlan0 into the bridge. And in fact I manage my ip address and services on the bridge itself, i.e. use the bridge as my ip 'interface', all other stuff (dns, dhcp, etc can run on that instead) It is not without issues though, Network Manager and hostapd has a race condition at startup, because hostapd creates the bridge (this is if you use the bridge=br0 configuration) if it is started earlier. And Network Manager sometimes gets goofy there and disabled the bridge etc. Hence, I make hostapd start 2 seconds later using /usr/bin/sleep 2 in the hostapd.service file. If using a bridge is not necessarily one's preferred option as the LAN segments becomes all connected. Then one'd need to setup the sub-nets accordingly and update the routing tables (at least static routing) accordingly, you would need to consider the 'overall' network setup including adjacent routers as well. One can setup NAT (ip masquadering) so that on the up stream (e.g. ethernet) only a single ip address is used, and that Opi Zero 3 AP does that NAT. Accordingly there is another trick known as proxy arp. https://wiki.debian.org/BridgeNetworkConnectionsProxyArp The main reason I'm using a bridge is actually that dhcp, dns and routing is based on the 'main' router which is not the Opi Zero 3 AP itself, this works rather well in a small e.g. home network with a few devices. what @jimg proposes should be good working configurations with local ip and without the bridge. there could be possible race conditions to look out for though, e.g. that dhcp, dns, dnsmasq, avahi etc has a dependency on the wlan0 interface and probably needs to run after the wlan0 interface (e.g. ip etc ) is setup and up. accordingly, systemd-networkd can be used to setup the network, https://wiki.archlinux.org/title/Systemd-networkd Apparently, it has rather good support for hostapd https://wiki.archlinux.org/title/Systemd-networkd#[DHCPServer] one may like to explore this option instead. Though I've not tried it myself and hence can't comment much about it. It'd be good to 'document' that say in a post (e.g. in tutorials https://forum.armbian.com/forum/40-reviews-tutorials-hardware-hacks/) here, if one successfully setup the AP with all the necessary services running. e.g. hostapd, dhcp, dhs, dnsmasq etc. accordingly, there is another way to setup the interfaces e.g. in /etc/network/interfaces https://wiki.debian.org/NetworkConfiguration#A4_ways_to_configure_the_network this may work better with hostapd setup and can likely co-exist with Network Manager if one used them in combination. e.g. that the network setup can run first, after that hostapd, dhcp, dns, dnsmasq, avahi etc can run after the dependent wlan0 interface is up.

if this is based on hostapd try journalctl -u hostapd to check the connect logs, normally successful connection attempts is quite 'intuitive' e.g. that there is normally a WPA / authentication related message other things that possibly matters include ip address, that should be provided by dhcp (e.g. dnsmasq) dns server, i think some os (e.g. android at least) tries to connect to some internet web sites (google?) and complains that there is no internet if is not accessible. if there is after all no internet, you may need to run a dns to resolve the ap itself if you are accessing it via domain names. For accessing the host itself, i'm not too sure if dnsmasq can work as dns and resolve its own domain. Otherwise, accessing the host would likely need to be based on ip address. alternatively, I'd think install and configure avahi (MDNS) which may help to resolve the ap itself as host.local (e.g. orangepizero3.local) interfaces and routing, we normally assume that it is configured and working? but nevertheless it may help to check e.g. ip link ip -4 add ip route

@robertoj Thanks I stumbled into this in a google search looks like quite a feasible and interesting 'project' to try.

What do you use to run the ILI9341 LCD? FBTFT? https://github.com/notro/fbtft

I'd guess that channel=36 specifier in hostapd.conf 2 comments above would likely make a difference. prior, i stated channel=0 and I'm assuming ACS (automatic channel selection). I think ACS may not be working after all, hence, it is necessary to specify the channel manually. the easiest way to list all channels and frequencies is sudo iw list and to list APs that are visible accordingly it is nmcli dev wifi or sudo iw dev wlan0 scan I think iw dev wlan0 scan and nmcli dev wifi needs to be done without hostapd or an AP (e.g. on Network Manager) running I think on Android (and/or iphone?) there are also apps available to list visible WiFi APs and their frequencies / channels even if it conflicts (e.g. 2 AP on the same channel) I'd guess it'd still work, just that there'd be 'interference' and possibly lower throughput. --- blurb: yes OpenWRT, Armbian, ... are among the earliest 3rd party open sourced implementations to run on Orange Pi Zero 3. using Armbian (vs OpenWRT) is just my personal preference, partly as it is a complete linux distribution (e.g. debian). One can run various other things in addition to simply using it as a 'router'. And that deban, ubuntu style apt update ; apt upgrade or apt install xxyy is very mature and setting up many different apps is simply a one liner apt install xxyy. And not least Ambian build framework is one of the highlights https://github.com/armbian/build one can catch up to the (bleeding) 'edge' of Linux if one wants to. another blurb, using SBC (Single board computers) as WiFi hotspot running open sourced implementations e.g Armbian, OpenWRT etc is 'very significant'. Well, these days there are dedicated 'mesh' routers, those are likely faster e.g. WiFi 6 etc (cost wise may actually be equal) but that running Armbian (etc) means one can literally customize the use including setting it up as a router / WiFi hotspot and customize the network setup to work around problems that may not be possible on 'standard' consumer box routers. And in addition running apps, e.g. file server (lan based storage) , web server with apps, stream media, databases (mysql?) etc in addition.

Imho trying OpenWRT isn't a direct 'solution' of a problem. A notion is that 'it works in A OS' and 'doesn't work in B OS' normally won't give a clue to fixing the problem in 'B OS', except for the cases of *strictly a config problem*. rather if you have A OS with a particular config that works and another A OS that has a config that doesn't work, then one'd be better comparing the 2 different configs between the 2 A OS, it would more likely find the 'config error'. in theory if it is strictly config error, then you may as well copy over the 'correct' config and it should work. my guesses as it has come this far is that it may not be simply a config problem. i.e. that there is (or at least may be) no problem with configs. there is 'something else' that cause the problem, and it may not be config. the thing is we do not know what that 'something else' is. We can't rule out hardware differences, there are different memory sizes for Orange Pi zero 3 ( 1, 1.5, 2, 4 GB) as it has not been discussed here. But even then that is just one of the possible factors. for the record, I've been using hostapd, Armbian on Orange Pi Zero 3, and it is practically my desktop WiFi hotspot, it 'just works', at least that Android connects to it flawlessly, and yes WPA2 (see prior comments) It runs for months literally without reboot and offers fast > 100 Mbps (throughput across both wifi and ethernet interfaces) WiiFi5 on 5 ghz band. And I think (or I observed) that iphones connect just fine ! (we need inputs from other iphone users who have successfully done the same that if that 'just works'. Then maybe it is easier to compare on the same basis. not easy to narrow down what that 'something else' is. For now, based on prior analysis a few comments prior (especially about the hostapd/wpa_supplicant 'discovery', perhaps rebuild the Armbian image (kernel + distribution) from source may help ! Still it is a gamble, as I do not know the root cause of it. edit: @av4625 there is one other thing, and this relates to config https://gist.github.com/ag88/de02933ba65500376d1ff48e504b1bf3 in my hostapd.conf example I specified channel=0 (that should literally should mean auto selection of channel) in actual fact, I used a specific channel # "a" simply means 5Ghz hw_mode=a # the channel to use channel=36 ieee80211ac=1 the relevant channel is selected by running sudo iw list which gives a detailed list of the frequencies / channels that can be set then simply pick a channel that is legal and that one prefers (e.g. by checking that no other AP visible is using it) and set that in the hostapd.conf as above if that is the problem, maybe it helps. it is perhaps overlooked as the assumption is that only WPA/WPA2 is the issue.

@av4625 blurb I stumbled into this https://w1.fi/wpa_supplicant/devel/ googling around if this is true both wpa_supplicant and hostapd does part of WPA / WPA2 probably the protocol negotiation parts, i.e. maintaining state in some ways. still more questions than answers If this is true try to build an Armbian image yourself as in the prior comment. my speculations: if you rebuild the image from source, it would pull new (possibly updated copies of hostapd and wpasupplicant) into your image. the kernel and wifi driver may have the relevant patches that connect the driver and wpa_supplicant/hostapd ( since wpa_supplicant and/or hostapd does everything that is required for WPA/WPA2) i.e. if all these are true and read verbatim, since wpa_supplicant/hostapd does all of WPA/WPA2 if WPA2 is broken itself it probably means a broken wpa_supplicant and/or hostapd (depending on the one that you use) but that if it isn't wpa_supplicant / hostapd that breaks WPA / WPA2, then this must means that the plumbing between the wifi driver and wpa_supplicant / hostapd is broken which cause things like authentication / wpa / wpa 2 to fail. This seemed so key, wpa_supplicant / hostapd is the 'technology' / 'secret' to a good WPA/WPA2 etc implementation for wifi (in general, all, any wifi) a key part of wifi. hope this helps

I tried searching for an image in https://github.com/armbian/os/releases unfortunately, I did not seem to find a nightly image for zero 3 I'd like to suggest you can try to build an image off the edge release, which would be a recent kernel https://docs.armbian.com/Developer-Guide_Build-Preparation/ https://docs.armbian.com/Developer-Guide_Building-with-Docker/ and you can make distribution related selections e.g. debian, ubuntu, minimal, 'full' (gui) etc. that do not necessarily fix the problem as using a recent kernel may possibly break things, but that you can nevertheless try rebuild with the 'current' kernel if that doesn't work. a thing would be I'm not too sure if a recent kernel could help in any way, but that if using an edge kernel makes a difference (i'm not sure if it does) it may be worth a try. ** one thing about building the kernel / distribution image from source is that it may get more recent patches even for that matter fror the drivers to be bundled and included. That may 'accidentally' help if someone pushed a patch to fix some issues. I do not know enough about wifi, in particular if encryption related stuff e.g. WPA, WPA2 is after all only in the wifi driver itself or that the linux kernel does that for the drivers. e.g. more like a 'library' . if it is only in the driver itself, that would possibly mean that every wifi dfirver for a different soc will behave differently. e.g. that one driver supports WPA, WPA2 doesn't mean that another does it. deeper down there may be protocol differences as well which makes it 'incompatible' with some platforms e.g. Mac, iphone etc. oops it seemed that is done by wpa_supplicant? https://wireless.docs.kernel.org/en/latest/en/users/documentation/wpa_supplicant.html https://w1.fi/wpa_supplicant/ ^ this is important, if WPA, WPA2 etc is handled by wpa_supplicant then my understanding about running hostapd without wpa_supplicant is perhaps flawed. As it seemed wpa_supplicant is The thing that does WPA/WPA2 etc (i.e. it is The library for WPA/WPA2) If this is true (i.e. wpa_supplicant does WPA/WPA2 and nothing else does it, then the question is what breaks wpa_supplicant from being able to do so? what is the thing 'in-the-middle' that makes wpa_supplicant fail to authenticate? and establish WPA/WPA2? when I'm reviewing the docs for hostapd https://wireless.docs.kernel.org/en/latest/en/users/documentation/hostapd.html I've an impression that hostapd merely *configures* the wifi driver rather than literally doing WPA/WPA2 etc I'm not too sure about wpa_supplicant though. if this is true, then WPA, WPA2 is either in the driver itself or that the kernel handles it (e.g. by means of a 'library' kind of stuff).

@av4625 imho you may want to try the hostapd.conf edits as suggested in the last comment. that basically enables WPA in addition to WPA2. Beyond that, i'm not sure what else can be done for authentication and encryption (e.g. WPA, WPA2). other things may be to review the hostapd logs e.g. journalctl -u hostapd to see if there are any hints and perhaps enable 'debug' to standard output (that goes to journalctl) as suggested in the prior comment for hostapd.conf. Another thing is to look in the nightlly rolling releases and perhaps use a recent image to see if that helps https://github.com/armbian/os/releases This likely matters as those uses kernels that are beyond 6.6 and may have additional fixes patched into the drivers. it may be possible to study the kernel driver for Wifi CdTech 20U5622 module. That goes beyond configuration. It is after all possible to build it completely from source, the kernel and an armbian iamge (not too difficult for a default build, it lets you choose the base distribution e.g. debian, ubuntu, edge vs current, with the full set of kernel build configuration as part of it) https://docs.armbian.com/Developer-Guide_Building-with-Docker/ This makes Armbian different vs the vendor releases, though the vendor released the (kernel) sources as well in github. But I've not tried building from there.

@robertoj I messed with arduino (stm32duino https://www.stm32duino.com/) 'outside' of Armbian. accordingly, those 'Aliexpress' type boards has a pin for LED, which is the backlight, this is separate from the SPI interface that displays graphics https://thesolaruniverse.wordpress.com/2021/05/02/wiring-an-ili9341-spi-tft-display-with-esp8266-based-microcontroller-boards-nodemcu-and-wemos-d1-mini/ those from Adafruit are quite similar in that respects https://learn.adafruit.com/adafruit-2-8-and-3-2-color-tft-touchscreen-breakout-v2/pinouts hence, backlight is simply controlled as a regular gpio pin Accordingly in linux that has to be driven via FBTFT driver, so a (google) search for that keyword would probably return results. those are pretty low res like 320x240, but it certainly beats operating without a display. there are ili9341 LCDs with touchscreens and a chip to drive that, I'm not sure what drivers would work that out of the box.

a couple of thoughts, in hostapd.conf the password is specified in wpa_passphrase, you need to specify that in that file. hostapd.conf normally lives in /etc/hostapd/hostapd.conf, use that installed with the "apt install hostapd" command. for the exact file used look in /usr/lib/systemd/system/hostapd.service that hostapd log is nevertheless 'useful' at least it shows that hostapd is attempting to setup the connection, rather than perhaps wpa_supplicant. in my setup, I limited the protocol to WPA2 https://gist.github.com/ag88/de02933ba65500376d1ff48e504b1bf3 I assume you are working through the ethernet port e.g. using ssh. it is possible to stay with 'default' network setup and omitting those nmcli configurations if you are just testing connectivity to WiFi. Those nmcli commands are mainly to set a fix ip on the ethernet interface and to setup a bridge across both wifi and lan. Not re-configuring the network especially the ethernet port would not hang things if you are working from the ethernet port. messing with network configuration practically mandates using the usb-uart serial debug port as your console, it is not possible to configure the ethernet port while you are connected through it e.g. using ssh. But it is recommended to still 'unmanage' the wifi interface from Network manager to prevent conflicts. it is possible to temporarily unmanage the connection during the session nmcli dev set wlan0 managed no but that I find it a hassle as it reverts to managed on reboot, so I added in /etc/NetworkManager/conf.d/99-unmanaged-devices.conf [keyfile] unmanaged-devices=interface-name:wlan0 i go to the extent of disabling wpa_supplicant systemctl stop wpa_supplicant.service systemctl disable wpa_supplicant.service I'm not too sure if that is after all necessary, but that I just wanted to be sure only hostapd is controlling the WiFi interface. it is possible to setup hostapd.conf to use both WPA and/or WPA2, some changes are needed in hostapd.conf # 1=wpa, 2=wep, 3=both auth_algs=1 # bit0 = WPA # bit1 = IEEE 802.11i/RSN (WPA2) (dot11RSNAEnabled) # both WPA and WPA2 wpa=3 # use a pre-shared key wpa_key_mgmt=WPA-PSK # Set of accepted cipher suites (encryption algorithms) for pairwise keys # Pairwise cipher for WPA (v1) (default: TKIP) wpa_pairwise=TKIP CCMP # Pairwise cipher for RSN/WPA2 (default: use wpa_pairwise value) #rsn_pairwise=CCMP # you need to set the wifi password here wpa_passphrase=your_wifi_passphrase_min_8_char # Levels (minimum value for logged events): # 0 = verbose debugging # 1 = debugging # 2 = informational messages # 3 = notification # 4 = warning # logger_syslog=-1 logger_syslog_level=2 logger_stdout=-1 # you may want to set logger_stdout_level=1 debug logger_stdout_level=2 in the above changes, that should allow hostapd to do both wpa and wpa2, this is just in case your devices are actually using wpa rather than wpa2. a complete hostapd.conf example is here https://web.mit.edu/freebsd/head/contrib/wpa/hostapd/hostapd.conf I think the default character encoding in armbian is utf-8, that can be checked using the command "locale" or checking the environment variables using "env". type a plain text password for that wpa_passphrase config in the file. note that if you are not using a network bridge and there is no DHCP servers, you would need to configure the wlan0 interface with an ip address and network using say ip commands e.g. /etc/network/interfaces source /etc/network/interfaces.d/* # Network is managed by Network manager auto lo iface lo inet loopback # added the following auto wlan0 iface wlan0 inet static address 10.0.0.1 netmask 255.255.255.0 ^ note I'm not too sure if this'd work given that Network Manager is in use. This is kind of trying to setup wlan0 'outside' of Network manager. In my setup using the bridge, I let network manager manage the bridge and I patched the wlan0 interface into the bridge. (ref: https://wiki.debian.org/NetworkConfiguration ) and run a dhcp server. e.g. dnsmasq or isc-dhcp-server apt install isc-dhcp-server https://ubuntu.com/server/docs/how-to-install-and-configure-isc-dhcp-server I think network manager is easier in this aspect as it manages the interface setting ip address and running a dhcp server and configure forwarding. Just that I find network manager 'opaque' in that very little logs are found when wifi clients/hosts connects and that the dhcpd etc are not explicit in network manager configs. hope that helps