Orange Pi Zero AP and mainline kernel, any one has it working?

Shaohua Wen · January 23, 2017

Has anyone successfully configured OPI0 AP working in the mainline kernel?

I have tried to use the same configuration file with the 3.4 kernel, the hostapd started successfully, dnsmasq also running, but when client device trying to connect to the AP, the client is not able to obtain the IP address from the dnsmasq-dhcp server.

the dnsmasq log:

journalctl -f
-- Logs begin at Sun 2017-01-22 13:30:20 UTC. --
Jan 22 14:47:52 orangepizero dnsmasq-dhcp[1676]: DHCPOFFER(wlan0) 192.168.43.125 cc:08:8d:d5:92:84
Jan 22 14:48:00 orangepizero dnsmasq-dhcp[1676]: DHCPDISCOVER(wlan0) cc:08:8d:d5:92:84
Jan 22 14:48:00 orangepizero dnsmasq-dhcp[1676]: DHCPOFFER(wlan0) 192.168.43.125 cc:08:8d:d5:92:84
Jan 22 14:48:07 orangepizero sshd[3727]: userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]
Jan 22 14:48:09 orangepizero dnsmasq-dhcp[1676]: DHCPDISCOVER(wlan0) cc:08:8d:d5:92:84
Jan 22 14:48:09 orangepizero dnsmasq-dhcp[1676]: DHCPOFFER(wlan0) 192.168.43.125 cc:08:8d:d5:92:84
Jan 22 14:48:10 orangepizero sshd[3727]: Accepted password for root from 192.168.2.101 port 62956 ssh2
Jan 22 14:48:10 orangepizero sshd[3727]: pam_unix(sshd:session): session opened for user root by (uid=0)
Jan 22 14:48:10 orangepizero systemd-logind[555]: New session c5 of user root.
Jan 22 14:48:10 orangepizero systemd[1]: Started Session c5 of user root.
Jan 22 14:48:20 orangepizero dnsmasq-dhcp[1676]: DHCPDISCOVER(wlan0) cc:08:8d:d5:92:84
Jan 22 14:48:20 orangepizero dnsmasq-dhcp[1676]: DHCPOFFER(wlan0) 192.168.43.125 cc:08:8d:d5:92:84
Jan 22 14:48:26 orangepizero dnsmasq-dhcp[1676]: DHCPDISCOVER(wlan0) cc:08:8d:d5:92:84
Jan 22 14:48:26 orangepizero dnsmasq-dhcp[1676]: DHCPOFFER(wlan0) 192.168.43.125 cc:08:8d:d5:92:84
Jan 22 14:48:34 orangepizero dnsmasq-dhcp[1676]: DHCPDISCOVER(wlan0) cc:08:8d:d5:92:84
Jan 22 14:48:34 orangepizero dnsmasq-dhcp[1676]: DHCPOFFER(wlan0) 192.168.43.125 cc:08:8d:d5:92:84
Jan 22 14:48:42 orangepizero dnsmasq-dhcp[1676]: DHCPDISCOVER(wlan0) cc:08:8d:d5:92:84
Jan 22 14:48:42 orangepizero dnsmasq-dhcp[1676]: DHCPOFFER(wlan0) 192.168.43.125 cc:08:8d:d5:92:84

Here you can see DHCPOFFER, but the client didn't get the IP address.

Any suggestions or working configuration file examples are appreciated.

Shaohua Wen · January 23, 2017

cat /etc/hostapd/hostapd.conf

interface=wlan0
hw_mode=g
ctrl_interface=/var/run/hostapd
ssid=holywifi_opi0
channel=11
wpa=2
wpa_passphrase=******

cat /etc/dnsmasq.d/wlan0.conf

listen-address=192.168.43.1                       
interface=wlan0                                           
bind-interfaces
dhcp-range=192.168.43.100,192.168.43.200,12h      
resolv-file=/etc/resolv.dnsmasq.conf

cat /etc/network/interfaces

# This file intentionally left blank
#
# All interfaces are handled by network-manager, use nmtui or nmcli on
# server/headless images or the "Network Manager" GUI on desktop images

allow-hotplug wlan0
iface wlan0 inet static
    address 192.168.43.1
    netmask 255.255.255.0
        network 192.168.43.0
        broadcast 192.168.43.255
        gateway 192.168.43.1

uname -a

Linux orangepizero 4.9.4-sun8i #2 SMP Fri Jan 20 10:22:01 CET 2017 armv7l armv7l armv7l GNU/Linux

modinfo xradio_wlan

filename:       /lib/modules/4.9.4-sun8i/kernel/drivers/net/wireless/xradio/xradio_wlan.ko
alias:          xradio_core
license:        GPL
description:    XRadioTech WLAN driver core
author:         XRadioTech
alias:          sdio:c*v0020d2281*
depends:        mac80211,cfg80211
intree:         Y
vermagic:       4.9.4-sun8i SMP mod_unload ARMv7 thumb2 p2v8

jkajolin · January 23, 2017

it seems that both images are a bit mesh.

Armbian_5.24_Orangepizero_Ubuntu_xenial_default_3.4.113.img

- gives kernel failures when loading and the wireless driver dumps all sorts of debug information (the older image did work).

Armbian_5.24_Orangepizero_Ubuntu_xenial_dev_4.9.4.img

- seems to load ok but example Wifi scanning is really slow and don't always even show all the available networks.
- while I did get the connection workig, it seems that the power saving option or something else is missing ? If I disconnect the LAN - cable and try to use the WLAN only the device boots

I am using the same power source and cables that work fine with Orange Pi PC+.

p.s) I don't understand that why the network manager is used for the headless installations, the older plain /etc/network/interfaces with wpa_supplicant worked just fine.

jkajolin · January 23, 2017

Seems really odd

It seems to spawn these messages on /var/log/syslog

xradio_wlan mmc1:0001:1: missed interrupt

While booting sometimes works ok but other times the wpa_supplicant seems to fail

Jan 23 20:19:13 IotHub1 wpa_supplicant[679]: dbus: wpa_dbus_get_object_properties: failed to get object properties: (none) none
Jan 23 20:19:13 IotHub1 wpa_supplicant[679]: dbus: Failed to construct signal

Networkmanager configuration

[connection]
id=MikroTik
uuid=9f8346a5-ed5a-4119-8044-33da78e09695
type=wifi
interface-name=wlan0
permissions=
secondaries=

[wifi]
mac-address-blacklist=
mac-address-randomization=0
mode=infrastructure
seen-bssids=
ssid=MikroTik
powersave=2

[wifi-security]
group=
key-mgmt=wpa-psk
pairwise=
proto=
psk=XXX

[ipv4]
dns-search=
may-fail=false
method=auto

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=ignore

it seems that both images are a bit mesh.

Armbian_5.24_Orangepizero_Ubuntu_xenial_default_3.4.113.img

- gives kernel failures when loading and the wireless driver dumps all sorts of debug information (the older image did work).

Armbian_5.24_Orangepizero_Ubuntu_xenial_dev_4.9.4.img

- seems to load ok but example Wifi scanning is really slow and don't always even show all the available networks.
- while I did get the connection workig, it seems that the power saving option or something else is missing ? If I disconnect the LAN - cable and try to use the WLAN only the device boots

I am using the same power source and cables that work fine with Orange Pi PC+.

p.s) I don't understand that why the network manager is used for the headless installations, the older plain /etc/network/interfaces with wpa_supplicant worked just fine.

Shaohua Wen · January 24, 2017

Well with the Armbian_5.24_Orangepizero_Debian_jessie_3.4.113 image, and AP does work on those configurations.

jkajolin · January 24, 2017

I continued to tweak the mainline installation.
- disable the network-manger

- added the things back to the /etc/network/interface

- used wpa_supplicant to the wireless client

Aften it worked

- done the basic host ap installation

Now it seems to work but will output sometimes

r# dmesg | grep xradio_wlan
[   13.087342] xradio_wlan: unknown parameter 'macaddr' ignored
[   13.421168] xradio_wlan mmc1:0001:1: missed interrupt
[  189.333832] xradio_wlan mmc1:0001:1: missed interrupt
[  399.509000] xradio_wlan mmc1:0001:1: ***skb_queue_tail
[  408.520202] xradio_wlan mmc1:0001:1: ***skb_queue_tail
[  417.535028] xradio_wlan mmc1:0001:1: ***skb_queue_tail
[  422.762284] xradio_wlan mmc1:0001:1: ***skb_queue_tail
[  422.776708] xradio_wlan mmc1:0001:1: ***skb_queue_tail
[  444.360619] xradio_wlan mmc1:0001:1: received frame has no key status

# systemctl status hostapd
â— hostapd.service - LSB: Advanced IEEE 802.11 management daemon
   Loaded: loaded (/etc/init.d/hostapd; bad; vendor preset: enabled)
   Active: active (running) since Tue 2017-01-24 17:55:22 EET; 6min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 705 ExecStart=/etc/init.d/hostapd start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/hostapd.service
           â””â”€801 /usr/sbin/hostapd -B -P /run/hostapd.pid /etc/hostapd/hostapd.conf

Jan 24 17:55:21 IotHub1 systemd[1]: Starting LSB: Advanced IEEE 802.11 management daemon...
Jan 24 17:55:22 IotHub1 hostapd[705]:  * Starting advanced IEEE 802.11 management hostapd
Jan 24 17:55:22 IotHub1 hostapd[705]:    ...done.
Jan 24 17:55:22 IotHub1 systemd[1]: Started LSB: Advanced IEEE 802.11 management daemon.
Jan 24 17:58:35 IotHub1 hostapd[801]: wlan0: STA 6c:70:9f:7f:c1:29 IEEE 802.11: authenticated
Jan 24 17:58:35 IotHub1 hostapd[801]: wlan0: STA 6c:70:9f:7f:c1:29 IEEE 802.11: associated (aid 1)
Jan 24 17:58:35 IotHub1 hostapd[801]: wlan0: STA 6c:70:9f:7f:c1:29 RADIUS: starting accounting session 98C65C1E-00000000
Jan 24 17:58:35 IotHub1 hostapd[801]: wlan0: STA 6c:70:9f:7f:c1:29 WPA: pairwise key handshake completed (RSN)

# systemctl status isc-dhcp-server
â— isc-dhcp-server.service - ISC DHCP IPv4 server
   Loaded: loaded (/lib/systemd/system/isc-dhcp-server.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2017-01-24 17:55:21 EET; 6min ago
     Docs: man:dhcpd(8)
 Main PID: 711 (dhcpd)
   CGroup: /system.slice/isc-dhcp-server.service
           â””â”€711 dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf wlan0

Jan 24 17:55:22 IotHub1 dhcpd[711]: Sending on   LPF/wlan0/12:42:13:81:f5:29/192.168.51.0/24
Jan 24 17:55:22 IotHub1 dhcpd[711]: Sending on   Socket/fallback/fallback-net
Jan 24 17:55:22 IotHub1 dhcpd[711]: Server starting service.
Jan 24 17:58:36 IotHub1 dhcpd[711]: DHCPDISCOVER from 6c:70:9f:7f:c1:29 via wlan0
Jan 24 17:58:37 IotHub1 dhcpd[711]: DHCPOFFER on 192.168.51.10 to 6c:70:9f:7f:c1:29 (Jarmos-iPad) via wlan0
Jan 24 17:58:38 IotHub1 dhcpd[711]: DHCPREQUEST for 192.168.51.10 (192.168.51.1) from 6c:70:9f:7f:c1:29 (Jarmos-iPad) via wlan0
Jan 24 17:58:38 IotHub1 dhcpd[711]: DHCPACK on 192.168.51.10 to 6c:70:9f:7f:c1:29 (Jarmos-iPad) via wlan0
Jan 24 17:58:38 IotHub1 dhcpd[711]: reuse_lease: lease age 0 (secs) under 25% threshold, reply with unaltered, existing lease
Jan 24 17:58:38 IotHub1 dhcpd[711]: DHCPREQUEST for 192.168.51.10 (192.168.51.1) from 6c:70:9f:7f:c1:29 (Jarmos-iPad) via wlan0
Jan 24 17:58:38 IotHub1 dhcpd[711]: DHCPACK on 192.168.51.10 to 6c:70:9f:7f:c1:29 via wlan0

auto lo
iface lo inet loopback

allow-hotplug eth0
iface eth0 inet dhcp

allow-hotplug wlan0
iface wlan0 inet static
  address 192.168.51.1
  netmask 255.255.255.0
  wireless-power off

interface=wlan0
#driver=rtl871xdrv
ssid=IotHub1_AP
country_code=FI
hw_mode=g
channel=6
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=IotHub123
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP
wpa_group_rekey=86400
ieee80211n=1
wme_enabled=1

jkajolin · January 24, 2017

The mainline version seems to work for a while but after some use it starts to spam error messages and the client connection no longer works.
If I drop the connection and reconnect it seems to work again without anything done the server side.

Jan 24 18:39:26 IotHub1 kernel: [ 844.024694] xradio_wlan mmc1:0001:1: received frame has no key status
Jan 24 18:39:26 IotHub1 kernel: [ 844.024707] xradio_wlan mmc1:0001:1: ***skb_queue_tail
Jan 24 18:39:26 IotHub1 kernel: [ 844.024897] xradio_wlan mmc1:0001:1: ***skb_queue_tail
Jan 24 18:39:26 IotHub1 kernel: [ 844.229181] xradio_wlan mmc1:0001:1: ***skb_queue_tail
Jan 24 18:39:35 IotHub1 kernel: [ 852.925459] xradio_wlan mmc1:0001:1: ***skb_queue_tail
Jan 24 18:39:42 IotHub1 kernel: [ 860.217105] xradio_wlan mmc1:0001:1: ***skb_queue_tail

Shaohua Wen · January 27, 2017

Thanks @jkajolin,

I tried and verified that the option wpa_pairwise=CCMP is the key here.

If I commented it out, then the client is not able to receive the dhcp offer.

interface=wlan0
hw_mode=g
ctrl_interface=/var/run/hostapd
ssid=holywifi_opi0
channel=11
wpa=2
wpa_passphrase=******
wpa_pairwise=CCMP

worked!

Sign In

Orange Pi Zero AP and mainline kernel, any one has it working?

Recommended Posts

Shaohua Wen

Link to comment

Share on other sites

Shaohua Wen

Link to comment

Share on other sites

jkajolin

Link to comment

Share on other sites

jkajolin

Link to comment

Share on other sites

Shaohua Wen

Link to comment

Share on other sites

jkajolin

Link to comment

Share on other sites

jkajolin

Link to comment

Share on other sites

Shaohua Wen

Link to comment

Share on other sites

Forums

My Activity Streams

Download

Store

Important Information