Best posts made by cas

@brolly759 said

I tried the above and it worked, if you have the time, try it to and let me know how it goes! :)

Well, perhaps you can backup your uboot, but it seems that you can't write it back this way:

# mtd write u-boot.bin mtd0
Could not open mtd device: mtd0
Can't open device for writing!

[edit]
You can, but it's not as trivial, so it requires some hoop jumping to get it done.

# mtd write u-boot-env.bin u-boot-env
Unlocking u-boot-env ...

Writing from u-boot-env.bin to u-boot-env ...
# mtd write u-boot.bin u-boot
Unlocking u-boot ...

Writing from u-boot.bin to u-boot ...

[/edit]

I think this is an awesome deal Humble Book Bundle: DIY Electronics by Wiley

Even if you don't need the books yourself, tell your friends.

@Elliot-477569 said

Am I doing this correctly?

elliot477569@Helium2:/mnt/d/Onion/source/build_dir/host/sed-4.2.2$ make configure
make: 'configure' is up to date.

Maybe we're missing something.
My interpretation of this is that configure didn't get built:

make[4]: Entering directory '/mnt/d/Onion/source/build_dir/host/sed-4.2.2'
CDPATH="${ZSH_VERSION+.}:" && cd . && bash /mnt/d/Onion/source/build_dir/host/sed-4.2.2/build-aux/missing --run autoconf
autom4te: need GNU m4 1.4 or later: /mnt/d/Onion/source/staging_dir/host/bin/m4
Makefile:1023: recipe for target 'configure' failed
make[4]: *** [configure] Error 1
make[4]: Leaving directory '/mnt/d/Onion/source/build_dir/host/sed-4.2.2'

But your make says it's up to date, which would indicate it was built successfully.

Perhaps it's time to backup your .config and make distclean and start from scratch?

[edit]
Looking back through the thread, the following:
1.) make died, making sed.
2.) a later make skipped over sed (indicating it was successful - correlates with your make configure ) and then died making the next file: patch.

Maybe this is a timing issue within make? Perhaps a later thread is exiting before an earlier thread has completed?
What if you just run make with no parameters? It'll be slow, but hopefully sequential...
[/edit]

@William-Scott said

@Douglas-Kryder @cas Sure it does. There's a 3.3 volt regulator on board which, like any other semiconductor, is going to have some, albeit low, leakage current. I suggest the same experiment with the O2 not in the dock. I suspect results would be similar.

Good idea, but I seem to recall from various posts on this forum related to powering the O2's without a dock, it seems that the device will not run reliably unless a regulator is used. Indeed, even Onion's docs about doing this employ a 3v3 regulator Powering the Omega with No Dock.
But for this test, I suppose I only need the device to boot, enable the wifi and then shutdown, so I reckon I can try doing this with the bench PSU and breadboard dock and see what happens.
Ah, and I just realised I'll have to employ some kind of USB to serial device for communication, which is something I haven't tried to do as yet, so this could take a little while to test.

@György-Farkas said

It's very nice indeed. So I have to repeat my previous halt / poweroff / reboot experiments.
I think you can do this with your custom-made 'LEDE firmware (17.01)' instead of the official b160.
Could you share with us that FW?

Sure, I'll rebuild it without the Onion reboot patch and drop a link here. Will be several hours from now though.
Bear in mind I just started playing with the LEDE/OpenWrt firmware build, so it's very raw - no Onion packages, wifi works but untested (but sounds promising based on a recent post by @luz) and just a few basic additional packages I find useful (file, screen, usb storage, ext4 & vfat).

@Daniel-Petrie
Ok, here you go:

# cat /etc/config/wireless

config wifi-device 'ra0'
        option type 'ralink'
        option mode '9'
        option channel '11'
        option txpower '100'
        option ht '20+40'
        option disabled '0'
        option log_level '0'

config wifi-iface
        option device 'ra0'
        option network 'wlan'
        option mode 'ap'
        option encryption 'psk2'
        option ApCliAuthMode 'WPA2PSK'
        option ApCliEncrypType 'AES'
        option ApCliSsid 'XXXXXXX'
        option ApCliBssid '3c:47:11:8b:f1:f1'
        option ApCliPassWord 'xxxxxxxxxxxxx'
        option ssid 'XXXX'
        option ApCliEnable '0'
        option key 'xxxxxxxxxxxxx'

config wifi-config
        option ssid 'XXXXXXX'
        option bssid '3c:47:11:8b:f1:f1'
        option encryption 'WPA2PSK'
        option key 'xxxxxxxxxxxxx'

# cat /etc/config/network

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd1d:48c4:7633::/48'

config interface 'wlan'
        option type 'bridge'
        option ifname 'eth0.1'
        option proto 'static'
        option ipaddr '192.168.3.1'
        option netmask '255.255.255.0'
        option ip6assign '60'

config interface 'wan'
        option ifname 'eth0.2'
        option proto 'dhcp'
        option ipv6 '0'

config interface 'wwan'
        option ifname 'apcli0'
        option proto 'dhcp'
        option ipv6 '0'

Also check that the channel number shown by aps matches the channel in 'config-wifi-device'. I think that was important at the time.

@cas
been considering that option but the amount of time it takes.....i could also reboot it then.....

Aah yes, but that requires manual intervention. ;-) As I rediscovered yesterday, the 30s sleep is quite important as it takes time for the hardware to realign before you run the wifimanager to reconnect.

I wrote this a while back to turn the radio on and off as desired - 'set-radio-status.sh'. Feel free to adapt it and perhaps it could be useful to you. You'll need to add something that checks for connectivity and determines when to run it though.

#! /bin/sh

# uci set wireless.ra0.disabled=[0|1]

#echo "Debug: $# $1"

if [ "1" != "$#" ];then
 echo "Usage: $0 enable / disable"
 exit 0
fi

if [ "enable" != "$1" ] && [ "disable" != "$1" ];then
 echo "Usage: $0 enable / disable"
 exit 0
fi

if [ "enable" == "$1" ]; then
 ACTION=0
else
 ACTION=1
fi

UCIBIN='/sbin/uci'
WIFIMANAGERBIN='/usr/bin/wifimanager -v'
RELOADCONFIGBIN='/sbin/reload_config'
SLEEPBIN='/bin/sleep'

RADIOSTATUS=`${UCIBIN} get wireless.ra0.disabled`

if [ "0" == "${RADIOSTATUS}" ] && [ "1" == "${ACTION}" ];then
 # Currently enabled and choice is disable
 (>&2 echo "lights out")
 ${UCIBIN} set wireless.ra0.disabled=1
 ${UCIBIN} commit wireless
 ${RELOADCONFIGBIN}
# ${WIFIMANAGERBIN}
elif [ "1" == "${RADIOSTATUS}" ] && [ "0" == "${ACTION}" ]; then
 # Currently disabled and choice is enable
 ${UCIBIN} set wireless.ra0.disabled=0
 ${UCIBIN} commit wireless
 ${RELOADCONFIGBIN}
 ${SLEEPBIN} 30
 (>&2 echo "wifimanager -v")
 ${WIFIMANAGERBIN}
else
 # Nothing to do
 echo "State is already as requested."
fi

@Douglas-Kryder said in Omega2+ reproducible builds:
"... anyway, i get it when they now say that they never said they were open source and that what we got as a contributor was the hardware and build "b160" and earlier. and those constituted what onion was responsible for. i'm left with the impression that onion has done everything to date that is planned and anything else would be a bonus. ..."

While b160 is the latest working build, my concern with having to remain at b160 is that we will be unable to implement any critical security fixes into the firmware binary. The IoT landscape in general is already littered with many insecure devices that are eventually recruited into bot armies through their unpatched/unpatchable vulnerabilities and if we can't secure our O2's against future threats, I feel that we'll just be contributing to that cause.

I too would like a reproducible build that I could tweak when it becomes necessary.

IIRC, the power dock doesn't supply coms over the USB port.

[edit]
From the documentation: Onion Omega2 Documentation

No USB-to-Serial

There is no USB-to-Serial Chip on the Dock. This means that you will not be able to connect to the Omega serially over the Micro-USB port.

You can still connect to your Omega’s terminal with SSH, you can learn how to do that in this guide to connecting to the Omega.

[/edit]

@Jakub-K I had considered that, but I thought I read somewhere that the MAC address can be changed, in which case it couldn't be guaranteed to be unique.

I think I'll have to look into that in more detail.

Reading almost everything posted on this so far and my own trial and error lead me to trying to use the bssid in addition to the ssid values.

Which works... sort of.
My wireless doesn't connect to the hidden ap on boot, but a simple edit of the /etc/config/wireless to change option ApCliEnable from '0' to '1' followed by:

uci commit
reload_config
wifi

results in it connecting fine. I still have to work out what is going wrong at boot, but thought I'd share this in the mean time while I work my way through the wifimanager and wifi scripts.

So if anyone wants to try this, you will first need to get the bssid by using aps like so:

# aps
WRTnode AP scaner.
Begin scaning APs, pls wait...
Finished.
APs available are...
ra0       get_site_survey:
Ch  SSID                             BSSID               Security               Signal(%)W-Mode  ExtCH  NT
11                                   3c:47:11:8b:fi:fi   WPA1PSKWPA2PSK/TKIPAES 86       11b/g/n NONE   In

# 

Then add the bssid so that it appears in the config wifi-iface as option ApCliBssid and config wifi-config as option bssid alongside your other values. Mine look like this:

# uci show wireless | grep -i bssid
wireless.@wifi-iface[0].ApCliBssid='3c:47:11:8b:fi:fi'
wireless.@wifi-config[0].bssid='3c:47:11:8b:fi:fi'

Remember to change the ApCliEnable from '0' to '1' if it is currently '0', followed by:

# uci commit
# reload_config

Followed finally by:

# wifi
setting apcli
APCli use bssid connect.

And check if your interface has now come up:

# ifconfig apcli0
apcli0    Link encap:Ethernet  HWaddr 42:A3:6B:00:Fi:Fi
          inet addr:192.168.1.3  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:185941 errors:0 dropped:1 overruns:0 frame:0
          TX packets:134863 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:109980847 (104.8 MiB)  TX bytes:8482977 (8.0 MiB)