We finally managed to perform our RS485 testing yesterday, which involved an Omega2S+. It turns out that waiting on flush blocks for around 30ms. This was way too long for us, so we ended up calculating our time-on-wire and rounding up to the nearest ms. Given 115200 baud, start/stop bits, and a 41-byte fixed payload size, waiting 4ms worked out about right (it took about 3.7ms for the send to complete when observed by the scope). Given also that it takes about 1.5ms for our microcontroller to process the data and reply, things are working out quite well. Our Omega does RS485, although it'd be so much nicer if we didn't have to fudge the timing.

Also, ttyS0 is used for the console, hence being conflicted when trying to use it for our purposes.

All good.

In case there's any interest, we've also managed to get OpenWrt 23.05 working for us - WiFi, GPIO (char mode), WireGuard, and more. We took some inspiration from the work here and figured a few things out ourselves. Here's our fork and the changes we've made: https://github.com/openwrt/openwrt/compare/openwrt-23.05...cuprous-au:openwrt:openwrt-23.05. We also publish the images we'll be using for our production environment there.

Please note that our image is not as feature-full as the Onion one, but it should illustrate how you can start from the OpenWrt stable branch, perhaps towards building something for production.

@Lazar-Demin said in ️ Beta OpenWRT 22.03 firmware available! Your feedback is needed ️:

@huntc Thanks for the feedback. Yeah, it's a tough balancing act - staying close to the latest developments while maintaining the value-add customizations.
Can you elaborate on what you mean by "blessed by Onion" wrt the OpenWRT distribution?

I went down the standard distro path before and it was mentioned on this forum that the main repo isn't supported by Onion. So, it'd be great if that wasn't the case!

When you mention moving away from MIPS, what's the biggest driver behind that? Is it more horsepower or more support or something else?

We've had to jump through a few hoops having to target MIPS32 and Rust, but it is working for us now. We're quite interested in the more energy-efficient architectures though. Energy efficiency is important to us.

Following up - altering firstboot is insufficient. One needs to change /etc/rc.button/reset.

@luz

I'd be genuinely interested in understanding the background of wanting to prevent reading out firmware in the first place.

I now realise that the Omega family of chips is not positioned as being secure, but I do need to demonstrate that I can do all that is reasonable to make hacking difficult. We've gone to great lengths to ensure that our software services are secure. At the end of the day though, while we can't do a great deal to protect against physical access, there is information that we need to protect reasonably. Having uboot provide an easy way to gain access to the file system via the console seems avoidable, so we should attend to that. Again, having Onion support this style of bootloader would be great as I imagine most commercial deployments involving the Omega family would/should want it. However, building one's own flavour of the bootloader is arduous unless you're familiar with the process.

If an attacker gains physical access via hardware and is determined by taking the cover off the Omega chip and connecting to its flash over SPI, I'm not sure there's much that can be done to prevent that given the MT7688 architecture. That is, other than potting a board hosting the Omega in resin or similar (including its console pins).

@santi29051 We changed the ssid to "Cuprous-<mac>". Does that help? Nothing else should have changed. Also, can you get in via the serial console and see what interfaces are up? Both the AP and ethernet should be up.

@santi29051 Yep - replied in that other thread of yours.

In case there's any interest, we've also managed to get OpenWrt 23.05 working for us - WiFi, GPIO (char mode), WireGuard, and more. We took some inspiration from the work here and figured a few things out ourselves. Here's our fork and the changes we've made: https://github.com/openwrt/openwrt/compare/openwrt-23.05...cuprous-au:openwrt:openwrt-23.05. We also publish the images we'll be using for our production environment there.

Please note that our image is not as feature-full as the Onion one, but it should illustrate how you can start from the OpenWrt stable branch, perhaps towards building something for production.

@santi29051 You'll need a version of OpenWrt that includes WireGuard. We've got some pre-built packages of OpenWrt that we're using for the Omega2S+ here: https://github.com/cuprous-au/openwrt/releases.

Check out our diffs to the main 23.05 branch to see what's changed.

Thanks to both of you. I'm left not understanding whether there is something to be done... FYI I'm also using the Onion dev board with the Omega2S+.

@crispyoz Interesting. Thanks. Will do.

I began suspecting that I may have a h/w failure somehow. So, I then tried another Omega2S+ and all appears well. I can apply the Onion config to my custom 22.03 image as per my first post here. Thanks for the engagement. I hope that my config here may help others too.

I should also mention that the above occurs without applying the Onion config. I'm doing a basic wifi enabling on the 22.03 distro.

I'm also assuming that it shouldn't matter whether there's an actual antenna connected... I don't have a spare at the mo. I can't see why that should affect things though.

OK, I've managed to restore my custom image. TBH I was still having difficulty with the Onion distro also...

So, back to my custom image, which is pretty close to the 22.03 distro. If I set -x within the /sbin/wifi script then after enabling WiFi and a bit of execution, we get:

+ '[' '!' -f /lib/netifd/wireless/mac80211.sh ]
root@OpenWrt:/# [  260.011156] br-lan: port 2(phy0-ap0) entered blocking state
[  260.016854] br-lan: port 2(phy0-ap0) entered disabled state
[  260.022992] device phy0-ap0 entered promiscuous mode
[  260.050570] IPv6: ADDRCONF(NETDEV_CHANGE): phy0-ap0: link becomes ready
[  260.057548] br-lan: port 2(phy0-ap0) entered blocking state
[  260.063294] br-lan: port 2(phy0-ap0) entered forwarding state

...and then it hangs.

@crispyoz I've installed the Omega 22.03 distro again and the WiFi appears to be ok. Perhaps there's something in the kernel or other config that is missing/different from the 22.03 branch...? I'll re-install my distro and try and debug the wifi script as you suggest.