Wifi driver(?) seems to crash when wifi network unavailable.

[tony ter neuzen]

@crispyoz

our specific problem involves latency and packetloss, so i'm currently making graphs with continuous ping times while sending a steady stream of randomness...

top does not really show any weird behaviour as far as i can see, but maybe i just don't know where too look

thanks a lot for the info on the choice of driver, it sounds like a sensible consideration for onion to make. i was wondering about this for some time now.

in our application we don't use the nice gui that onion built, and if you think the MT driver has become more mature it might be a path we could examine further.

It would however mean that I have to educate myself first on how to swap those drivers around.... i don't think it's in my skill set yet how to do that, unless it is simply handled by opkg...
someone i know always says: "hope is just delayed disappointment"

manually configuring is not a problem, unless you mean the /etc/config/ methods disappear. most of the time i use the uci get/set/commit trickery anyway

i guess that this will become the first time i actually need to learn how to crosscompile or build a custom firmware, but there's no reason postpone the inevitable

thanks for your input, the search continues

greetings, tony

[luz]

I can only second what @crispyoz says - while at the time Onion introduced WarpCore, the opensource mt76 driver was not really usable. But thanks to a company that needed a certified wifi and thus invested some money into mt76 development about 3 years ago, it has become perfectly stable. mt76 had already improved a lot before (I found it usable for my needs since 2017), but that development boost made it really production reliable. As it is based on standard nl80211/cfg80211, there is more generic openwrt documentation about the config details, and it has independent ap and sta modes. But the Onion UI is tailored at WarpCore, so it does not work for cfg80211.

[luz]

@tony-ter-neuzen yes, replacing the wifi driver is beyond opkg. However, once you have an openwrt build environment, enabling it is just selecting it from the ˋmake menuconfigˋ menu. ˋmt76ˋ, being the official openwrt driver for mt7688 targets, fully supports uci and /etc/config.

In general, I can only recommend having a openwrt build environment for any project going beyond a singular installation. Its simply super relaxing to know a single ˋmakeˋ can (re)build the complete firmware of a device in a totally predictable way

[crispyoz]

@tony-ter-neuzen @luz said it perfectly. If you are releasing a product you need to have a clear understanding of the mechanism by which it functions. When Windoze breaks you're at the mercy of "Toilet Maker In Chief", but with Linux/OpenWrt/OnionOS you have access to the nuts and bolts that keep the wheels turning reliably.

Put on your floaties and set up a build environment, then you can build the firmware the way you want it and when things go wrong you have a much clearer understanding of where the issues may be and where the solutions may lie.

[tony ter neuzen]

thanks @luz and @crispyoz for your input.

I fully agree with you, corners have been cut and this issue sets the record straight

you've helped me a lot by pointing out the possibility to adopt the mt76 driver as a replacement for the warp core, i will give that a try.

And it's not like this is completely voodoo wizardry to me, in this case it has been really cutting corners because of lack of time...
Very bad reason i know, but at least i'm honest about it

I'm going for that "simply super relaxing" feeling that @luz describes but that simply asks for some investments too...

So... Putting on the floaties

Thanks guys for the pointers...

cheers tony

[tony ter neuzen]

@luz and @crispyoz

thanks you guys, that was the best advice i ever followed
i just needed to be dragged over that line...

it has been a lot of trial and error, and i haven't answered all questions yet, but at this point the build environment spits out a complete firmware, including our own app with all custom files and dependencies...

i end up with a mainline openwrt with mt76 that gives me a console in 12 seconds, and is completely up and connected at the sta-end in 55...
i2c, gpio, alsa, everything in working order.

hopefully this also solves the problem i started this topic about... but that i have to test yet... i call this a big win anyway even without the problem fixed...

i did just realize that i'm building SNAPHOT at the moment, but hopefully i'll find an easy way to step back to current stable without hours of tinkering on menuconfig again

greetz, tony

[crispyoz]

@tony-ter-neuzen Congratulations on getting up to speed with building your first custom firmware!! You should now feel "super relaxed".

It may not fix your immediate issue, only time will tell, but it will allow you to tinker and experiment with all of what the Omega2+ and OpenWrt have to offer, then build the best solution for your devices. One of the things I love about the Omega2+ is that it gets you started quickly with a clearly defined set of hardware and software and once you are ready to take off the floaties you can step up to the next level.

Now you need to learn how to build your own repository so you can deploy your custom updates to your devices. Lots of fun!

[luz]

@tony-ter-neuzen happy to hear you enjoy the freedom of making your own firmware (as I hoped you will)

i did just realize that i'm building SNAPHOT at the moment, but hopefully i'll find an easy way to step back to current stable without hours of tinkering on menuconfig again

Specifically for that, OpenWrt has a very useful mechanism called diffconfig (of course, it originates, like menuconfig, from the Linux kernel's build system). It allows to capture the changes in your .config (the one and only file make menuconfig touches) relative to the target's default configuration:

./scripts/diffconfig.sh >/my/safe/place/my_diffconfig

Now you can checkout another version of OpenWrt, and then:

cp /my/safe/place/my_diffconfig .config
make defconfig

The make defconfig expands your specific config changes in the context of the default config of the current openwrt into a full .config. The result is a config with all the subtleties that might have changed between OpenWrt versions, with your changes on top. Of course, there might be conflicts, but these are much easier to spot and solve this way.

Inspired by this mechanism (and way of thinking it implies), in my various OpenWrt based Omega2 projects, I nowadays strictly refrain from forking the OpenWrt tree, but keep all changes I need as a "diff" (consisting of diffconfig, but also a set of patches to OpenWrt I might need for one reason or another) separately.

After having done this manually for a while, I built a bash script named p44build that automates most of it. With p44build, lifting a project from an older OpenWrt version to a newer one is usually a minor task - IMHO a very important thing for OpenWrt based firmware to avoid sticking with an outdated OpenWrt too long just because upgrading a fork is a pain. p44build also allows switching between targets and projects on the same tree easily.

[tony ter neuzen]

hi @luz

thanks for handing out that next step in the puzzle...

the learning curve feels quite steep to me (as a just starting out newbie) but i think i'm getting the hang of it.

first i had to break my current snapshot build system hopelessly, but that was a ritual offer that apparently had to be made...

as soon as i did a new pull instead of trying to switch over my current snapshot environment things were improving fast.

so, using that diff you mentioned it was easy to adapt my working config to 21.02, and things actually built without one warning or error... that was an immediate improvement already.

i added your plan44 feed too, that ledchain looked to good to pass up

i will be looking into p44build also, i'm already getting close to that "super relaxed" feel @crispyoz mentioned and who knows it will even get better...

Circling back to the wifi topic this started with, i noticed that with the mt76 i had to take a different approach than i used to.
i kind of got used to the fact that warp-core could (at least temporarily before it broke in my case) kept up the 'ap' end when 'sta' couldn't connect

mt76 on the other hand seems to just down the 'ap' end if 'sta' can't connect...
so... that was also not really what i was looking for either.

i did find however a nice plugin called travelmate that seems to offer some kind of solution.
it tries to connect the sta end, and if it doesn't succeed it stops trying and keeps the ap end up.

we'll see where that takes us the next couple of days....

anyaways, cheers guys, thanks for all the fish

tony

[crispyoz]

@tony-ter-neuzen can you share the content of your network and wireless files, I've not experienced the ap going down if sta can't connect.

[tony ter neuzen]

Hi @crispyoz,

Sorry for the late reply, i have been trying to roll-back to the version where i observed this problem, but that seems a bit harder than i thought.

We've been testing with travelmate as a plugin these last couple of days, but if you say you haven't experienced the problem i described it gives me hope again to solve this without extra plugins...

I'll try to get back to you as soon as i achieve breaking it again...

bye tony