jimg

I have always use a routed configuration instead of a bridge because I'm always configuring my AP as our home router or subnet router. If there is no upstream router in front, then you will definitely need to install a firewall too like ufw or firewalld (which I always do). It's worth noting that Armbian now uses netplan to setup networking each time at boot. Server/IOT images configure netplan to use systemd-networkd. Server images use NetworkManager. To change from systemd-networkd, you need to install NetworkManager, then change the netplan configuration file(s) to use it instead. Interfaces not named or matched in the netplan file or ignored by Netplan, so if you're creating a hotspot with hostapd & dnsmasq, wlan0 should be left out of the configuration files listed in /etc/netplan. systemd-networkd has more limited functionality than NetworkManager when using netplan; e.g., you can use matching rules like 'wlx*' when defining networks with NetworkManager in netplan but not systemd-networkd.

If you tried creating an access point using NetworkManager, my guess is it's probably overwriting the dnsmasq.service file. See if the access point(s) you attempted to create is listed in one of the system connection files: ls /etc/NetworkManager/system-connections If so, delete the offending file(s). If you still have NetworkManager installed, you should also do what @ag123 recommended earlier and create a file so NetworkManager doesn't attempt to control the wlan0 interface: I am not surprised. I generally like NetworkManager for networking, but have rarely succeeded in using it to set up an AP on most boards I've tried in the past. And, because it's so opaque, it's difficult to debug what's wrong. That's why I use hostapd + dnsmasq. It very configurable and easier to debug. Yes, it's installed by default on my minimal/IOT image and launched by systemd. But I think your problem is probably caused by conflicting NetworkManager configuration(s), not wpa_supplicant.

Looks like dnsmasq is running. I get that failed message in my log, too, so you can ignore it. According to your 'ip -4 add' output, it doesn't appear the wlan0 interface is getting assigned the 10.10.1.1 address like it should from the hostapd.service file. Based on the 'systemctl status hostapd.service' output, the ExecStartPre commands in that file that set the address aren't being run. What's the output of 'cat /etc/systemd/system/hostapd.service'?

A 169.x.x.x address is a link-local address and indicates the Orange Pi's DHCP server (i.e., dnsmasq) isn't running. As mentioned in the ansible file, dnsmasq is masked by default on installation. To get it to function, you have to both unmask and enable it after installation: sudo systemctl unmask dnsmasq.service sudo systemctl enable dnsmasq.service If you did that and it's still not working, check if dnsmasq is running using: sudo systemctl status dnsmasq.service Check the 'Active' attribute in the output; It should be "active (running)". If it's not, check the log messages printed at the end of the report's output to determine the cause. Feel free to post the output here if you need help debugging it. dmsmasq by default is left disabled after installation. Did you enable the dnsmasq systemd service as mentioned in the ansible file?

FWIW, here's the ansible script I use to set up the Orange Pi Zero 2W we use as our home wireless access point running in 5 Ghz (AC) mode. It is currently on Armbian 24.11 Debian Bookworm using kernel 6.6.54. This should work on an Orange Pi Zero 3 since it uses the same CPU and wifi chip. Note I am using systemd-networkd that netplan uses by default in Armbian's minimal/IOT images, not nmcli. --- - name: Install networking packages apt: name: - hostapd - dnsmasq state: present # setup access point - name: configure dnsmasq file: src: dnsmasq.conf dest: /etc/dnsmasq.conf mode: 0644 tags: - dnsmasq - name: create dnsmasq.service.d directory if non-existent file: path: /etc/systemd/system/dnsmasq.service.d recurse: true state: directory tags: - dnsmasq - name: copy fix for systemd-resolved conflict when: - ansible_facts.services['systemd-networkd.service'] is defined - ansible_facts.services['systemd-networkd.service']['status'] == 'enabled' copy: src: systemd-resolved-fix.conf dest: /etc/systemd/system/dnsmasq.service.d/systemd-resolved-fix.conf mode: 0644 tags: - dnsmasq - name: activate dnsmasq service command: systemctl enable dnsmasq.service tags: - dnsmasq - name: Set up IPv4 forwarding ansible.builtin.copy: src: routed-ap.conf dest: /etc/sysctl.d/10-routed-ap.conf mode: 0644 - name: copy hostapd.conf file: src: hostapd.conf dest: /etc/hostapd/hostapd.conf mode: 0644 tags: - hostapd - name: copy hostapd.service file: src: hostapd.service dest: /etc/systemd/system/hostapd.service mode: 0644 tags: - hostapd # hostapd is masked by default after installation - name: unmask hostapd.service command: systemctl unmask hostapd.service tags: - hostapd - name: activate hostapd service command: systemctl enable hostapd.service tags: - hostapd Here's the /etc/dnsmasq.conf file: # disables dnsmasq reading any other files like /etc/resolv.conf # for nameservers no-resolv #IGNORE_RESOLVCONF=yes #DNSMASQ_EXCEPT="lo" interface=wlan0 log-queries log-facility=/var/log/dnsmasq.log addn-hosts=/etc/hosts no-dhcp-interface=lo domain-needed bogus-priv dhcp-range=10.10.1.50,10.10.1.199,12h dhcp-option=3,10.10.1.1 server=1.1.1.1 The /etc/systemd/system/dnsmasq.service.d/systemd-resolved-fix.conf file mentioned in the script stops systemd-resolved when dnsmasq is started so it doesn't conflict with dnsmasq: [Unit] After=systemd-resolved.service [Service] ExecStartPre=/usr/bin/systemctl stop systemd-resolved.service ExecStartPost=/usr/bin/systemctl start systemd-resolved.service The /etc/sysctl.d/10-routed-ap.conf file enables iPv4 and IPv6 address forwarding. This is required since hostapd is running in routed mode, not bridged: # https://www.raspberrypi.org/documentation/configuration/wireless/access-point-routed.md # Enable IPv4 routing net.ipv4.ip_forward=1 # Enable IPv6 routing #net.ipv6.conf.default.forwarding=1 The /etc/hostapd/hostapd.conf file, configured for the wifi chips' capabilities: ssid=<YOUR SSID GOES HERE> interface=wlan0 hw_mode=g channel=40 driver=nl80211 logger_syslog=0 logger_syslog_level=0 wpa=2 preamble=1 # Wifi Multi-Media support, also required for full speed on 802.11n/ac/ax wmm_enabled=1 wpa_passphrase=<YOUR PASSWORD GOES HERE> wpa_key_mgmt=WPA-PSK wpa_pairwise=TKIP rsn_pairwise=CCMP auth_algs=1 macaddr_acl=0 ## IEEE 802.11n ieee80211n=1 ht_capab=[LDPC][HT40-][HT40+][SHORT-GI-20][SHORT-GI-40][RX-STBC1] country_code=US ieee80211d=1 ## IEEE 802.11n ## IEEE 802.11a hw_mode=a ## IEEE 802.11a ## IEEE 802.11ac ieee80211ac=1 vht_capab=[MAX-MPDU-7991][RXLDPC][SHORT-GI-80][SU-BEAMFORMEE][MU-BEAMFORMEE][VHT-TXOP-PS][MAX-A-MPDU-LEN-EXP3] vht_oper_chwidth=1 vht_oper_centr_freq_seg0_idx=42 ## IEEE 802.11ac # controlling enabled ctrl_interface=/var/run/hostapd ctrl_interface_group=0 The /etc/systemd/system/hostapd.service file: [Unit] Description=Advanced IEEE 802.11 AP and IEEE 802.1X/WPA/WPA2/EAP Authenticator Documentation=man:hostapd(8) After=network.target Before=dnsmasq.service ConditionFileNotEmpty=/etc/hostapd/hostapd.conf #Wants=dhcpcd.service #Before=network.target dhcpcd.service wpa_supplicant.service [Service] Type=forking PIDFile=/run/hostapd.pid Restart=on-failure RestartSec=2 Environment=DAEMON_CONF=/etc/hostapd/hostapd.conf EnvironmentFile=-/etc/default/hostapd ExecReload=/bin/kill -s HUP $MAINPID ExecStartPre=/usr/bin/ip link set wlan0 down ExecStartPre=/usr/bin/ip address flush dev wlan0 ExecStartPre=/usr/bin/ip link set wlan0 up ExecStartPre=/usr/bin/ip addr add 10.10.1.1/24 dev wlan0 ExecStart=/usr/sbin/hostapd -B -P /run/hostapd.pid $DAEMON_OPTS $DAEMON_CONF [Install] WantedBy=multi-user.target Hope this helps.

`{ managed, AP}` indicates these are mutually exclusive. You cannot simultaneously have managed (aka STA) mode and AP mode operating at the same time. `total <= 3` means you can have at most (managed OR AP) AND (P2P-client or P2P-GO) AND (P2P-device).

The build instructions `README` suggest it's possible to build an image using Github actions. So, I created a new repository and created the following file under `.github/workflows/orangepizero3_build.yml` name: Build Orange Pi Zero 3 server image on: workflow_dispatch: jobs: build-armbian: runs-on: ubuntu-latest steps: - uses: armbian/build@main with: armbian_token: "${{ secrets.GITHUB_TOKEN }}" # GitHub token armbian_release: "bookworm" # userspace armbian_target: "build" # build=image, kernel=kernel armbian_board: "orangepizero3" # build target armbian_ui: "server" But when I tried to run this action, I received this error: Error: Could not find file '/home/runner/work/_actions/_temp_52217267-7314-4a20-996d-95b7097793e8/_staging/armbian-build-de030c7/patch/kernel/rockchip-rk3588-collabora/dt/rk3588-nanopc-cm3588-nas.dts'. Am I doing something wrong? Is there some aspect to building an image using Github Actions I'm missing?

What exactly have you tried so far? How are you determining it's not working? What kind of SD card are you using, and how are you installing Armbian on it? What are you using for a power supply and USB cable for power? What's the behavior of the status LEDs? Are you using a keyboard and monitor, or are you connecting to the board via SSH? Have you tried attaching a serial cable to it and reading the output over a serial terminal?

The "create access point" utility in `armbian-config` has several bugs that prevent it from working, due to changes in the default installation since it was written: - hostapd does not install a default configuration file at `/etc/hostapd.conf` - hostapd is installed masked by default - dnsmasq fails to start because systemd-resolvd launches first as the default DNS resolver I can write patches to fix this utility, but I'm wondering if it will ultimately be worth it. I noticed this access point utility doesn't exist in the `armbian-configng` repository. Is that because Armbian is dropping this utility, or no one has gotten around to it yet? (There's not even a placeholder for it.) What's the status of `armbian-configng` anyhow? Will it eventually replace `armbian-config`?

I don't think the Orange Pi Zero 3 supports w1-gpio. The only 1-wire overlay that I know of is for H5-equipped boards.

Yes, that appears to be correct. I couldn't figure out why the UART on the p26 pin header wasn't working. Found your post and tried ttyS1 instead. Working beautifully now. Thanks 🙂.