ag123

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

rather pinctrl could be related to pinctrl or maybe gpiod. I'm not too sure if that message means that w1-gpio is using that pin so pinctrl cannot use it. if that is the case, I think it is ok if pinctrl don't use it for gpio. that message is likely safe to ignore as long as your w1-gpio works. to 'fix' that it may take editing other dts to exclude that pin from pinctrl which could be a hassle.

it may help to look in codes https://github.com/torvalds/linux/blob/master/drivers/w1/masters/w1-gpio.c https://github.com/torvalds/linux/tree/master/drivers/w1 [ 4.997793] sun50i-h616-pinctrl 300b000.pinctrl: pin PC10 already requested by onewire@0; cannot claim for 300b000.pinctrl:74 seem to suggest that pinctrl tries to map that pin but onewire@0 is using it, so i guess this is ok as long as you are not using that as normal gpio pin. that "no maps for state" is found here https://github.com/torvalds/linux/blob/cf87f46fd34d6c19283d9625a7822f20d90b64a4/drivers/pinctrl/devicetree.c#L175 ret = ops->dt_node_to_map(pctldev, np_config, &map, &num_maps); if (ret < 0) return ret; else if (num_maps == 0) { /* * If we have no valid maps (maybe caused by empty pinctrl node * or typing error) ther is no need remember this, so just * return. */ dev_info(p->dev, "there is not valid maps for state %s\n", statename); return 0; } my guess is it may be related to pinctrl-names = "default"; some related stuff https://www.kernel.org/doc/Documentation/devicetree/bindings/w1/ https://www.kernel.org/doc/Documentation/devicetree/bindings/w1/w1-gpio.txt as it works as you mentioned, I'd guess that "not valid maps for state default" can be ignored.

I'm half way feeling that it may be possibly to use DS18B20 using gpiod / libgpiod https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/ I tried googling around but thare are lots of offers for DS18B20 many of which use w1-gpio as you are doing the timing requires for DS18B20 fig 16 page 16 https://www.analog.com/media/en/technical-documentation/data-sheets/DS18B20.pdf from 15 uS to 60 uS per bit of data isn't after all that impossible to synchronize the hard part about libgpiod is the timing part as sending and receiving data is timing sensitive, if there is a way to do that to read and write data in sync with tight timing it is possibly feasible to do so even in python. i.e. no kernel drivers, the python (or c etc) codes simply use libgpiod and work the signals. I've thus far not (yet) found one based on libgpiod admist the 'noise' returned from the searches, maybe try searching around and you may find an existing implementation that's already done. ether way, you seemed to have *achieved* making w1-gpio work, perhaps try connecting a sensor to see if the dmesg changes. the hint is [ 4.997833] w1-gpio onewire@0: gpio_request (pin) failed [ 4.997841] w1-gpio: probe of onewire@0 failed with error -22 if w1-gpio does a 'probe' it is probably sending the 'reset' signal to the chip and waiting for a response

based on the messages, it seemed you managed to load the overlay for w1-gpio perhaps venture further and connect a device appropriately ? based on the data sheet https://www.analog.com/media/en/technical-documentation/data-sheets/DS18B20.pdf (page 15, fig 15) it seeemed detection works by master (host) pulling down the line for 480 uS then pull that up again. then the chip would respond by first pulling it down, and after some 60-240 uS pull that up to inform the host of presence. it may take using specialized equipment like a scope / logic analyzer to probe those signals. for what is worth, and not trying to disappoint you, I think it is probably easier to connect the sensor to a (simple) microcontroller e.g. using uart and for the microcontroller to interface the sensor. the thing is for things related to timing, it may take going pretty much close to 'bare metal' e.g. work the on chip hardware to synchronize those signals, e.g. using pwm, spi etc. a h616 manual is found here https://linux-sunxi.org/images/2/24/H616_User_Manual_V1.0_cleaned.pdf if you want to venture there. uart on orange pi zero 3 is likely available in the standard configs without dts overlays.

in a normal case, files in your home directory should belong to you except ..

type id and look at the groups you are in then ls -l and/or ls -ld and look at the owners and permissions for the files in your home folder the owners and group should match that in id otherwise you can probably change them using chown , chown -R , chmod etc. for rsync, scp etc, you probably need to use a same username across different hosts in a sense that it should remote login to your Orange Pi host using ssh with that username.

@OttawaHacker connect to the board using a usb-uart (debug) serial dongle. the boot messages would normally show up there, or that if it booted to the prompt, you could login as root and run dmesg to see what goes wrong try also the other u-boot https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/ to see if that helps. there is a sequence of patches that needs to be applied and I've done that with my implementation. Unfortunately, in my case I hardcoded the 1.5GB memory as I found that for 1.5GB boards, the mainline u-boot incorrectly detected memory as 2GB or 4GB inconsistently. For once it says 2GB, then 4GB, then 2GB, and the algorithm would probe into the wrong memory size. so 'hardcoding' it ensures that it is 1.5GB no more / no less. you can use the distributed Armbian images https://www.armbian.com/orange-pi-zero-3/ and subsequently apply the u-boot patch from my repository. If you don't use dd , you can try using the python script that I've provided in my respository to patch u-boot into the image. Checkout instructions in my repository.

@OttawaHacker you could try the images from here: https://www.armbian.com/orange-pi-zero-3/ and to patch the u-boot into the image from here https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/tree/main