Shaohua Wen Posted January 23, 2017 Share Posted 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:84Jan 22 14:48:00 orangepizero dnsmasq-dhcp[1676]: DHCPDISCOVER(wlan0) cc:08:8d:d5:92:84Jan 22 14:48:00 orangepizero dnsmasq-dhcp[1676]: DHCPOFFER(wlan0) 192.168.43.125 cc:08:8d:d5:92:84Jan 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:84Jan 22 14:48:09 orangepizero dnsmasq-dhcp[1676]: DHCPOFFER(wlan0) 192.168.43.125 cc:08:8d:d5:92:84Jan 22 14:48:10 orangepizero sshd[3727]: Accepted password for root from 192.168.2.101 port 62956 ssh2Jan 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:84Jan 22 14:48:20 orangepizero dnsmasq-dhcp[1676]: DHCPOFFER(wlan0) 192.168.43.125 cc:08:8d:d5:92:84Jan 22 14:48:26 orangepizero dnsmasq-dhcp[1676]: DHCPDISCOVER(wlan0) cc:08:8d:d5:92:84Jan 22 14:48:26 orangepizero dnsmasq-dhcp[1676]: DHCPOFFER(wlan0) 192.168.43.125 cc:08:8d:d5:92:84Jan 22 14:48:34 orangepizero dnsmasq-dhcp[1676]: DHCPDISCOVER(wlan0) cc:08:8d:d5:92:84Jan 22 14:48:34 orangepizero dnsmasq-dhcp[1676]: DHCPOFFER(wlan0) 192.168.43.125 cc:08:8d:d5:92:84Jan 22 14:48:42 orangepizero dnsmasq-dhcp[1676]: DHCPDISCOVER(wlan0) cc:08:8d:d5:92:84Jan 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. Link to comment Share on other sites More sharing options...
Shaohua Wen Posted January 23, 2017 Author Share Posted 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 Link to comment Share on other sites More sharing options...
jkajolin Posted January 23, 2017 Share Posted 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. Link to comment Share on other sites More sharing options...
jkajolin Posted January 23, 2017 Share Posted 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) noneJan 23 20:19:13 IotHub1 wpa_supplicant[679]: dbus: Failed to construct signal Networkmanager configuration [connection]id=MikroTikuuid=9f8346a5-ed5a-4119-8044-33da78e09695type=wifiinterface-name=wlan0permissions=secondaries=[wifi]mac-address-blacklist=mac-address-randomization=0mode=infrastructureseen-bssids=ssid=MikroTikpowersave=2[wifi-security]group=key-mgmt=wpa-pskpairwise=proto=psk=XXX[ipv4]dns-search=may-fail=falsemethod=auto[ipv6]addr-gen-mode=stable-privacydns-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. Link to comment Share on other sites More sharing options...
Shaohua Wen Posted January 24, 2017 Author Share Posted January 24, 2017 Well with the Armbian_5.24_Orangepizero_Debian_jessie_3.4.113 image, and AP does work on those configurations. Link to comment Share on other sites More sharing options...
jkajolin Posted January 24, 2017 Share Posted 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 Link to comment Share on other sites More sharing options...
jkajolin Posted January 24, 2017 Share Posted 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 statusJan 24 18:39:26 IotHub1 kernel: [ 844.024707] xradio_wlan mmc1:0001:1: ***skb_queue_tailJan 24 18:39:26 IotHub1 kernel: [ 844.024897] xradio_wlan mmc1:0001:1: ***skb_queue_tailJan 24 18:39:26 IotHub1 kernel: [ 844.229181] xradio_wlan mmc1:0001:1: ***skb_queue_tailJan 24 18:39:35 IotHub1 kernel: [ 852.925459] xradio_wlan mmc1:0001:1: ***skb_queue_tailJan 24 18:39:42 IotHub1 kernel: [ 860.217105] xradio_wlan mmc1:0001:1: ***skb_queue_tail Link to comment Share on other sites More sharing options...
Shaohua Wen Posted January 27, 2017 Author Share Posted 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! Link to comment Share on other sites More sharing options...
Recommended Posts