ag123

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

there is another thing I did though, I disabled bluetooth as well, a pretty paranoid setup systemctl stop bluetooth.service systemctl disable bluetooth.service you may want to try this first just in case that makes a difference another thought though, try hostapd as well at least for a 'last resort' solution, if hostapd works while Network manager (uses wpa_supplicant) doesn't it probably confirms your suspicions. a thing about hostapd is that it logs every connection in the journalctl logs journalctl -u hostapd that would likely help with troubleshooting connection issues. to get hostapd #install hostapd apt install hostapd #check that it is not masked systemctl status hostapd #enable that so that it auto starts on reboot systemctl enable hostapd then followed by various configs (e.g. unmanage it from NetworkManager), I disabled wpa_supplicant as well. https://gist.github.com/ag88/de02933ba65500376d1ff48e504b1bf3 I remembered that there is something about having hostapd listen on the bridge by specifying the bridge in hostapd.conf. There are times where hostapd did not work if that bridge is not specified, but works when it is specified. I think there are also occasions that hostapd works without that bridge, so this observation is not conclusive.

it seemed possible that WPA is used after all (even with hostapd) wlan0: STA mac_add IEEE 802.11: associated wlan0: STA mac_add RADIUS: starting accounting session EC98EEE1B63146E8 wlan0: STA mac_add WPA: pairwise key handshake completed (RSN) wlan0: STA mac_add IEEE 802.11: disassociated I'm using wifi-sec.key-mgmt wpa-psk as well the documentation shown with "describe" command in your run literally says "wpa2 + wpa3 personal", but it seemed wpa is used instead in my hostapd.conf # 1=wpa, 2=wep, 3=both auth_algs=1 # WPA2 only wpa=2 wpa_key_mgmt=WPA-PSK rsn_pairwise=CCMP it is uncertain here if that message literally means wpa or that actually wpa2 is used. https://wireless.wiki.kernel.org/en/users/documentation/hostapd apparently RSN is probably WPA2 ----- apparently there is one more configuration option in Networkmanager https://people.freedesktop.org/~lkundrak/nm-dbus-api/nm-settings.html Table 30. 802-11-wireless-security setting pairwise array of string [] A list of pairwise encryption algorithms which prevents connections to Wi-Fi networks that do not utilize one of the algorithms in the list. For maximum compatibility leave this property empty. Each list element may be one of "tkip" or "ccmp". proto array of string [] List of strings specifying the allowed WPA protocol versions to use. Each element may be one "wpa" (allow WPA) or "rsn" (allow WPA2/RSN). If not specified, both WPA and RSN connections are allowed. based on these descriptions it is likely that if "proto" is not specified both wpa and wpa2 (RSN) is allowed. my guess is the connecting device (e.g. phone) would choose the preferable more secure protocol e.g. wpa2 nevertheless, you may like to tweak them to see if that helps

just a thought ahead, if dmesg shows protocol errors during WiFi authentication, it could be that your device (phone?) could be attempting wpa3, and that if it is after all not supported, those errors may show up in dmesg. in that case, it may mean needing to use wpa2 to connect, which I think most devices (phones?) does it automatically. another thing is to check things like character encoding etc, ascii is the safest, but otherwise maybe utf-8 should be ok. A thing is if the encoding is different, what is saved as the password may be *different* from what you think it is. the quotes (") for the password may affect it too, try with and without quotes. alternatively try nmcli conn edit access_point then in the prompt set wifi-sec.psk save persistent activate that would be manually setting the password note also that the notation may have changed between NetworkManager releases e.g. 802-11-wireless-security.key-mgmt 802-11-wireless-security.psk etc if that is changed in the nmcli edit prompt, print command should show them -- blurb: network manager seemed to use dnsmasq, but that network manager seemed to manage that internally rather than running an dnsmasq instance. I've orignally used hostapd because I wanted more control over how wifi AP works, e.g. that I wanted to setup a bridge with wifi and ethernet without dnsmasq and I'm not too sure how Network Manager does that. But I think Network Manager should be possible for that. A side perk with hostapd is that it logs every connection (e.g. journalctl -u hostapd), that'd help at least with troubleshooting disconnects etc. hostapd has a lot of other features (e.g. radius ) , and lots of wifi config options which probably can be omitted (e.g. using default) in simple Wifi setups.

can you show the result of nmcli conn edit access_point then in the prompt describe wifi-sec.key-mgmt I think wpa-psk is after all correct, that should be wpa2 That describe statement should probably show all the available options another thing that may help is to look at dmesg output especially when you are connecting to see if that detect any issues. accordingly, some wifi hardware does wpa within the wifi soc itself, while some others implement all that in software, I'm not sure which is done in this case. Accordingly, there may be some protocol changes / unsupported protocol as well (e.g. wpa3) which I'm not sure if it is there in the (kernel) stack for that particular driver or even the hardware itself. wpa2 should be mostly there.

The original discussion thread is this Reposting this below just in case it may be useful ---- how i set it up https://gist.github.com/ag88/de02933ba65500376d1ff48e504b1bf3 --- Imho for WiFi purposes nmcli (network manager cli) is not very different from hostapd, just that hostapd possibly has more configuration options. To setup an access point, there are quite a few pieces of network configuration that needs to be setup: The WiFi AP itself (e.g. using network manager or hostapd) if you are able to connect and verify that in the log, that is probably solved. e.g. journalctl -u NetworkManager or for hostapd journalctl -u hostapd hostapd tends to have log entries for every host that connects, I'm not sure about NetworkManager. DHCP (issuing IP address to connected hosts) this is particularly true for IPv4 hosts on dynamic IP. DHCP would likely also need to distribute the DNS server, so configure that if it isn't done. e.g. https://ubuntu.com/server/docs/how-to-install-and-configure-isc-dhcp-server For IPv6 you may need to setup radvd (router advertisement daemon) https://en.wikipedia.org/wiki/Radvd so that the connected hosts can setup their own IPv6 address quite often IPV6 requires its own /64 address range / network (* note below dnsmasq does this as well) e.g. apt install radvd https://wiki.archlinux.org/title/IPv6#For_gateways Configure the WiFi AP as a router or bridge. Router: note that if you are using hostapd and not using a network bridge and there are no DHCP servers, you would need to configure the wlan0 interface with an ip address and network using say ip commands e.g. (ref: https://wiki.debian.org/NetworkConfiguration) /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 192.168.1.1 netmask 255.255.255.0 To run it as a router, you would need to do DHCP (and RADV) for your WiFi hosts as above For such reasons, I tend to use isc-dhcp-daemon so that I can configure the dhcpd precisely as I needed. But I'd guess it may be possible with Network manager. (* note below dnsmasq does this as well) e.g. https://ubuntu.com/server/docs/how-to-install-and-configure-isc-dhcp-server apt install isc-dhcp-server Configure routing and/or IP NAT (e.g. IP masquerading). I've tried IP NAT and that sometimes it is easier as up stream normally only a single IP address is needed. Routing would need a subnet to be setup, that is normally ok but that you would need to configure your main gateway router as well for the overall network setup so that it knows where/how to forward packets. many consumer getway/routers simply used NAT, that is ok as well. But that your main gateway/router may need a static route to say that for that subnet, send it to your OPi Zero 3 Wifi AP. Bridging: To run it as a bridge you would need to setup the zero 3 WiFi AP as a bridge. This can be done using nmcli (network manager). In fact, this is my own personal preference for a small network. e.g. https://www.cyberciti.biz/faq/how-to-add-network-bridge-with-nmcli-networkmanager-on-linux/ https://gist.github.com/ag88/de02933ba65500376d1ff48e504b1bf3 DHCP (and RADV) can be done from the main gateway/router so long as the bridged packets reaches the WiFi hosts. Similarly, the DNS server likely needs to be distributed this way as well I've not done it completely from within nmcli for this setup as I used hostapd for the WiFi AP. But that I used nmcli (network manager) for the bridge. But that those notes above remains similar whether you used network manager or hostapd. take note that with hostapd for WiFi AP, you probably need to un-manage the Wifi interface in Network Manager configs so that it doesn't conflict with hostapd. https://gist.github.com/ag88/de02933ba65500376d1ff48e504b1bf3 oh and when messing with network interfaces use a debug usb-uart serial dongle or you may get 'locked out' from your zero 3 Apparently, dnsmasq does all three: DNS, DHCP, RADV https://thekelleys.org.uk/dnsmasq/doc.html but that there may be some configurations that are needed for it to work correctly https://docs.fedoraproject.org/en-US/fedora-server/administration/dnsmasq/ https://wiki.archlinux.org/title/Dnsmasq

Imho for WiFi purposes nmcli (network manager cli) is not very different from hostapd, just that hostapd possibly has more configuration options. To setup an access point, there are quite a few pieces of network configuration that needs to be setup: The WiFi AP itself (e.g. using network manager or hostapd) if you are able to connect and verify that in the log, that is probably solved. e.g. journalctl -u NetworkManager or for hostapd journalctl -u hostapd hostapd tends to have log entries for every host that connects, I'm not sure about NetworkManager. DHCP (issuing IP address to connected hosts) this is particularly true for IPv4 hosts on dynamic IP. DHCP would likely also need to distribute the DNS server, so configure that if it isn't done. e.g. https://ubuntu.com/server/docs/how-to-install-and-configure-isc-dhcp-server For IPv6 you may need to setup radvd (router advertisement daemon) https://en.wikipedia.org/wiki/Radvd so that the connected hosts can setup their own IPv6 address quite often IPV6 requires its own /64 address range / network (* note below dnsmasq does this as well) e.g. apt install radvd https://wiki.archlinux.org/title/IPv6#For_gateways Configure the WiFi AP as a router or bridge. Router: To run it as a router, you would need to do DHCP (and RADV) for your WiFi hosts as above For such reasons, I tend to use isc-dhcp-daemon so that I can configure the dhcpd precisely as I needed. But I'd guess it may be possible with Network manager. (* note below dnsmasq does this as well) e.g. apt install isc-dhcp-server Configure routing and/or IP NAT (e.g. IP masquerading). I've tried IP NAT and that sometimes it is easier as up stream normally only a single IP address is needed. Routing would need a subnet to be setup, that is normally ok but that you would need to configure your main gateway router as well for the overall network setup so that it knows where/how to forward packets. many consumer getway/routers simply used NAT, that is ok as well. But that your main gateway/router may need a static route to say that for that subnet, send it to your OPi Zero 3 Wifi AP. Bridging: To run it as a bridge you would need to setup the zero 3 WiFi AP as a bridge. This can be done using nmcli (network manager). In fact, this is my own personal preference for a small network. e.g. https://www.cyberciti.biz/faq/how-to-add-network-bridge-with-nmcli-networkmanager-on-linux/ https://gist.github.com/ag88/de02933ba65500376d1ff48e504b1bf3 DHCP (and RADV) can be done from the main gateway/router so long as the bridged packets reaches the WiFi hosts. Similarly, the DNS server likely needs to be distributed this way as well I've not done it completely from within nmcli for this setup as I used hostapd for the WiFi AP. But that I used nmcli (network manager) for the bridge. But that those notes above remains similar whether you used network manager or hostapd. take note that with hostapd for WiFi AP, you probably need to un-manage the Wifi interface in Network Manager configs so that it doesn't conflict with hostapd. https://gist.github.com/ag88/de02933ba65500376d1ff48e504b1bf3 oh and when messing with network interfaces use a debug usb-uart serial dongle or you may get 'locked out' from your zero 3 Apparently, dnsmasq does all three: DNS, DHCP, RADV https://thekelleys.org.uk/dnsmasq/doc.html but that there may be some configurations that are needed for it to work correctly https://docs.fedoraproject.org/en-US/fedora-server/administration/dnsmasq/ https://wiki.archlinux.org/title/Dnsmasq --- footnote: the Wifi AP on OPi Zero 3 has been running well on 5 ghz for me for quite a while, practically as my desktop Wifi AP https://gist.github.com/ag88/de02933ba65500376d1ff48e504b1bf3 it is fast > 100 Mbps throughput, and stable (running for days to months on end without reboot) it is a practical way to setup multiple WiFI AP , hotspot say in a home where signals is poor say due to walls etc. these days 'mesh' router products does something similar, possibly more elaborate and faster than this for a premium.

running a Wifi AP (hotspot) has quite a few pieces of protocols / apps that needs to be setup to work correctly I used hostapd https://gist.github.com/ag88/de02933ba65500376d1ff48e504b1bf3 but that network manager (e.g. via nmcli etc) should work ok using hostapd seemed more 'transparent' in a sense that the config is in a text file. for nmcli check the interface settings the other thing is check how *dhcpd* is installed, I used isc dhcp server and that works ok I'm not sure how that'd work in network manager, but that I prefer running my own separate instance of dhcp server as that simplifies troubleshooting if things go goofy There are various guides about that. A google search would probably find them e.g. https://variwiki.com/index.php?title=Wifi_NetworkManager#Configuring_WiFi_Access_Point_with_NetworkManager

in addition, armbian tends to be 'beyond' bleeding edge in a sense, like (*additional*) support for orange pi zero 3 is developed right here in this forum, no where else. and of course, it is by this community ('community support'), which means that you are practically supporting 'yourself'

@burger242 wrote note that Armbian is right here on https://www.armbian.com/ nowhere else. you go to the 'wrong' link. the authentic Armbian for Orange Pi Zero 3 images is here: https://www.armbian.com/orange-pi-zero-3/ scroll down to the bottom Note that this is a "community maintained" image, which means that that image is made possible by volunteers / contributors you see if you review this thread itself. simply flash the image to the sd card e.g. using belana etcher plug that into the uSD slot and boot it up. it is recommended that you use a usb-uart dongle to connect to the board on the 'debug uart' pins and use a serial terminal app e.g. https://www.putty.org/ to connect to it on the serial console. you should be able to see it boot up in the serial console that way. if you become any more 'advanced' than simply getting started, you can build your own image: https://docs.armbian.com/Developer-Guide_Build-Preparation/

well h618 isn't a 'high performing' cpu, so don't expect too much in terms of opencl etc, probably nil. and even GPU support is probably sketchy https://docs.mesa3d.org/drivers/panfrost.html https://bakhi.github.io/mobileGPU/panfrost/ https://en.opensuse.org/ARM_Mali_GPU GPU is a most undocumented aspects of these socs, many time you are left with 'you are on your own', no docs, no help, no hints, no nothing you can try plain old NEON https://developer.arm.com/Architectures/Neon https://developer.arm.com/documentation/dht0002/a/Introducing-NEON/Developing-for-NEON/Automatic-vectorization this would probably 'just works'

@D I'm really unfamiliar with DTS and such, hence there isn't much I'd help. But that are there any hints in dmesg etc? And as I suggested, try to decompile the dtb for your board and review that. In my case, I tried that for Orange Pi Zero 3 and did not see pwm devices listed. Hence, I'd guess those would need to be added by applying a .dtbo (device tree overlay binary). Accordingly, you may be able to check the same thing in a running system by checking them under /proc/device-tree as well. e.g. if you don't find them in /proc/device-tree, maybe that overlay isn't loaded.

@D answer to that question is 'complicated', there are a bunch of DTS patches https://github.com/armbian/build/tree/main/patch/kernel/archive/sunxi-6.6/patches.armbian which are laid on top of mainline H616 DTS https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero3.dts https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi you can try to decompile the dtb file back to its source to examine it dtc -I dtb -O dts -o ~/devtree.dts /boot/dtb/allwinner/sun50i-h618-orangepi-zero3.dtb

for H618 simply try the mainline uboot and kernel >= 6.6 various things has gone into mainline u-boot and kernel that makes it run on Orange Pi Zero 3 one could perhaps even try the Orange Pi Zero 3 image to see how that goes

@madeofstown I'd guess it is good to leave the default serial uart console running there as otherwise if things goofs, you may have no means to login onto the board. with the serial console, you can connect a usb-uart serial dongle and login to Armbian on the board. but if you insist you can nevertheless try going into /usr/lib/systemd/system look for those *getty* (e.g. ls *getty*), it would be one of those services. but that for debug output I'm not sure about that though, a google search I'd guess would get some leads e.g. https://superuser.com/questions/351387/how-to-stop-kernel-messages-from-flooding-my-console https://wiki.archlinux.org/title/working_with_the_serial_console I'd suggest to browse that same Orange Pi Zero 3 thread and figure out how to use a different serial uart port, there are probably more than a single uart port available on Orange Pi Zero 2W or Orange Pi Zero 3. using a different serial comm (uart) port is the correct solution in your case and you won't need to be bothered about console messages as they won't be there.

@JohnTheCoolingFan neither am I familiar with much of that. I'd just like to say that H618 support evolves out of H616 and the DTS for Orange Pi Zero 3 and Zero 2W is contributed by Andre Przywara from 6.6 mainline kernel. But that various contributors here worked the DTS further, check in the thread for details. Note that there are also change in *u-boot* for Orange Pi Zero 3, mainly to add the PMIC and DDR4 support for Orange Pi Zero 3 I think some key difference between Orange Pi Zero 2 (H616) vs Orange Pi Zero 3 (H618) are : - PMIC the power management IC is different - Orange Pi Zero 3 uses lpddr4 vs Orange Pi Zero 2 lpddr3 various other 'small' differences and that H618 is after all based on H616 codebase. Hence, my guess is to attempt to use the 6.6 and up mainline kernel and do a rebuild for CB1. One thing I'm not sure is where to configure that so that the build would use the 6.6.x mainline kernel during the build. It would likely 'not build cleanly' (e.g. without errors) and the build errors especially if the 'old' patches for the same board is applied and those would need to be resolved. You would take into account the actual hardware differences vs Orange Pi Zero 2 or Orange Pi Zero 3 if after all they are different on the CB1.

@madeofstown try out the orange pi zero 3 community images to see if it helps https://www.armbian.com/orange-pi-zero-3/ zero 2w don't have the motorcomm ethernet (requires an extension/expansion board accordingly), that's what I understand it to be. hopes that works still on zero 2w

dts overlay aren't 'perfect' https://elinux.org/Device_Tree_Source_Undocumented#:~:text=Node can be deleted with,%2Fdelete-property%2F directive.&text=If a delete is specified,with the overlay source file. If a delete is specified in an overlay source file, the delete only impacts the files compiled in association with the overlay source file. The delete does not result in an opcode in the resulting .dtb, thus applying the overlay will not delete the node or property in the base tree. and it may take using those 'hacks' described at that page to attempt a 'fix' hence, you may like to just note that those messages are 'benign' and w1-gpio works normally.

@wanasta orange pi zero 3 (and zero 2w) has on board wifi, have you tried them 1st? usb wifi dongles normally if the drivers are built into the kernel, plug them in and check dmesg if they are detected