jkajolin

p.s) Raspbian is based on Debian Jessie. They just don't follow the normal debian development and manually merge the security patches (when ever feel like it, so not often). Therefore basic Debian guides will work unless we are talking something on lower level arm support etch.

First you need to know which network management you are using ? If the /etc/network/interfaces is empty you probably have network manager and should do all with nmcli or nmtui. If not you have wpa_supplicant for wireless When using non networkmanager (like plain Ubuntu server images do) both lan and wireless ip-management is defined at /etc/network/interfaces. wpa_supplicant is only required for the wireless selection (not the actual ip-address) and triggered from /etc/network/interfaces But when you have the network manager the ip-address don't come straight from the /etc/network/interface and relays to the problems marked at your post and you need to make certain scripts to auto load the settings

The boards are fine they can run Android or Linux variants. They just are hobbyist products not targeted for any commercial use cases (there is no real support from Raspberry either they just hide behind "non profit"). If you want real support you need to buy boards witch cost a lot more. but getting a bit off topic...

Sorry I am away few days and don't have the device with me. Remove comment rows and recheck against the wiki page for the hardware its not terrible hard. The base code has the lower header(3v) row pins first and then the upper header (5v) row. If you are unfamilar with unix editors download the file to desktop and change it there (althouht it may need to be in unix line endings) The table has values, phys pin number, gpio number and some registryprefix. Look the first row (3v pin gets skippef)

Most likely if they are correct on the actual devicetree (boot.bin on older). The file is just a wrapper for the python functions to be targetted to the correct GPIO numbers (or port-map). I did the new mapping table but did not test it just changed the pin I was using to the first free GPIO which is found without any changes. Edit the file and recompile the python to test it out... I am leading towards not to use Orange Pi devices anything other than plain linux servers and leave the actual sensor reading to more suitable devices. As 1wire don´t require any custom code it should be relatively easy to use those even on zero.

Could some one advice or point to documentation for these tasks On some images the first boot is automatically restarted probably due to the filesystem expansion. I would like to do it myself or detetch some not yet done trigger file. Secondary avoid the forced account creation on first login. I have a bootstrap task which I start by using the external usb media which does all these things and starts my application install process. But to avoid the restarts and apt-get locks the plain image should not do things automatically... example on raspbian my process takes around 15minutes but installs all my required tools.

Hello does someone have the working configuration enabling the onewire master bus on the mainline version ? I have tried to gather the information from several posts adding the missing configuration on the devicetree but as there is no real step by step guide and the kernel wiki entry makes no sense for the zero`s pins. Overlay or straight settings into the boot configuration.

Only the starting pins are correct all the rest are incorrect. Most of the pins on the zero are on PA registry unlike the "normal" PGXXX https://raw.githubusercontent.com/duxingkei33/orangepi_PC_gpio_pyH3/master/pyA20/gpio/mapping.h

I have to try it when have time. If you are using network manager you should create two connection profiles (one client dhcp and one ap static ip) ? If not then create the virtual interfaces to the /etc/network/interfaces file and use wpa_supplication for the client connection (i am not familiar how this is done, only knowledge of bridges on openstack) However as you are also using the eth0 lan connection it may lead into a "arp flux" - scenario if the lan connection and wireless client share the same subnet ?

sorry was using wrong interface ip (zero's eth0) this is directly to the hostap gateway address # ping -c 10 192.168.51.1 PING 192.168.51.1 (192.168.51.1) 56(84) bytes of data. 64 bytes from 192.168.51.1: icmp_seq=1 ttl=64 time=1.20 ms 64 bytes from 192.168.51.1: icmp_seq=2 ttl=64 time=1.84 ms 64 bytes from 192.168.51.1: icmp_seq=3 ttl=64 time=1.18 ms 64 bytes from 192.168.51.1: icmp_seq=4 ttl=64 time=4.35 ms 64 bytes from 192.168.51.1: icmp_seq=5 ttl=64 time=1.06 ms 64 bytes from 192.168.51.1: icmp_seq=6 ttl=64 time=1.47 ms 64 bytes from 192.168.51.1: icmp_seq=7 ttl=64 time=1.16 ms 64 bytes from 192.168.51.1: icmp_seq=8 ttl=64 time=1.62 ms 64 bytes from 192.168.51.1: icmp_seq=9 ttl=64 time=1.14 ms 64 bytes from 192.168.51.1: icmp_seq=10 ttl=64 time=1.87 ms --- 192.168.51.1 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9013ms rtt min/avg/max/mdev = 1.069/1.695/4.357/0.931 ms ---

ARMBIAN 5.24 stable Ubuntu 16.04.1 LTS 4.9.4-sun8i laptop -> Wifi AP (zero) -> LAN -> internet # ping -c 10 IotHub1 PING IotHub1 (192.168.88.216) 56(84) bytes of data. 64 bytes from IotHub1 (192.168.88.216): icmp_seq=1 ttl=64 time=3.11 ms 64 bytes from IotHub1 (192.168.88.216): icmp_seq=2 ttl=64 time=1.77 ms 64 bytes from IotHub1 (192.168.88.216): icmp_seq=3 ttl=64 time=1.10 ms 64 bytes from IotHub1 (192.168.88.216): icmp_seq=4 ttl=64 time=1.53 ms 64 bytes from IotHub1 (192.168.88.216): icmp_seq=5 ttl=64 time=1.14 ms 64 bytes from IotHub1 (192.168.88.216): icmp_seq=6 ttl=64 time=1.27 ms 64 bytes from IotHub1 (192.168.88.216): icmp_seq=7 ttl=64 time=1.10 ms 64 bytes from IotHub1 (192.168.88.216): icmp_seq=8 ttl=64 time=1.30 ms 64 bytes from IotHub1 (192.168.88.216): icmp_seq=9 ttl=64 time=1.58 ms 64 bytes from IotHub1 (192.168.88.216): icmp_seq=10 ttl=64 time=1.10 ms --- IotHub1 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9014ms rtt min/avg/max/mdev = 1.102/1.504/3.117/0.583 ms

better use this https://github.com/duxingkei33/orangepi_PC_gpio_pyH3.git then look the file <source>/pyA20/gpio/mapping.h // { "PA6", SUNXI_GPA(6), 7 }, // connect PA6 and GND #!/usr/bin/env python import os,sys if not os.getegid() == 0: sys.exit() from pyA20.gpio import gpio,connector,port gpio.init() gpio.setcfg(port.PA6, gpio.INPUT) gpio.pullup(port.PA6, gpio.PULLUP) state=gpio.input(port.PA6) print state

sunxi-tools's seem to be missing from the image or have I messed the paths somehow ? (Armbian_5.24_Orangepipcplus_Ubuntu_xenial_dev_4.9.4.img) got it from here https://github.com/linux-sunxi/sunxi-tools but if this is not a mistake I have to add it to my automated installation process

plugin usb serial console and see what is going on. I do have a 'lite wifi' and it seems to work just as similar to others. the boot sequence is a bit slow compared to the EEMC models

take loot of this https://docs.armbian.com/Hardware_Allwinner/#updating-a-fex extract the configuration and look for GPIO mapping. ensure that the GPIO numbers you are using are actually mapped to the correct physical pins of your device

We don't plan to use Wireless client to connect to the actual outside world, just hostap for the esp8266 to do the RESTAPI posting. How did you create the client / ap separation ? I think basically no matter which you use wpa_supplicant or network manager, you use the interace-name to bind the saved information. /etc/NetworkManager/system-connections for the nmcli and example /etc/wpa_supplicant/ for wpa_supplicant - scripts. I think you can also use nmcli or wpa_cli to do them all manually from a startup service if required.

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

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

If you are using wpa_supplicant for the wpa2-type, keymode is actually just wpa. (wpa2 just gives the authentication error). I am evaluating Orange Pi devices for a WIFI AP - nodehub to be used with ESP8266 - devices so I have tinkered between Zero, PC+ and Plus 2E H3

If you have good shell scripting skills it might be possible but it would be easier just to buy a new unit. With Client you need to use networkmanager (nmcli) or wpa_supplicant to change the settings. Most likely with client you are using dhcp for the wlan0. With AP you need to set the wlan0 as static ip for it to work as the subnets routing node (perhaps you can do this with networkmanager profile ?). Start hostap and isc-dhcp and enable the iptables forwards.

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.