@crispyoz ok, i discovered another strange behavior. When connecting to an ShellyBluetooth Dongle AP the omega keeps disconnecting/connecting. I need to run a script which continuesly ping the AP to keep the connection. With other hardware the connection to the shelly is no problem. So it looks like the omega is doing something different.

@Antony If you're using the standard Warp Core driver some of this stuff is not functional and there is no documentation. If you are using the OpenWrt driver you can refer to the relevant documentation here. Keep in mind that altering some of this stuff may breach the law in your jurisdiction.

@DocHardinger Cool project! Home automation for your home on wheels I automated some of my apartment using Omega2, my existing home automation system was missing some features so I added them. I can't really answer your question since every case is different, but I prefer to be running the most current release and since there is not much difference between 22 and 23 it's fairly trivial to switch over to 23. Since 23 is the current release, all the new stuff and improvements will be on 23. For me it just came down to testing time before I could put it into production.

@MK it's important to understand that wifisetup simply uses UCI to modify the WiFi setup and then bring the interface up, it has no functionality to check the WiFi subsequently is connected, only that it is enabled. If you bring the WiFi interface up (wifisetup does this) if the SID/encryption/passphrase are rejected by the router the interface goes down then up, then down. A little like playing on a pogo stick. The solution I use in my own app is to wait 15 seconds after the interface comes up then ping a known good ip. 8.8.8.8 and 8.8.4.4 a good bets as they're Google's DNS servers. I don't do this in scripts, I wrote it into my app, but you can also use a script accessible via UBUS directly or using mod-ubus (see docs)

@DocHardinger Try disabling your wifi configuraiton then use the wifi command to configure your wifi but add the -d switch which will provide additional logging.

@Rotenone your best bet will be to make a new thread where you explain the issue you're having See the how to ask for help post for best practices on describing your issue

@huntc As far as I recall, wifi reload will work to update the Warp Core's AP network settings without bringing the whole radio down. I believe the wifi command needs to be used to update the STA network settings, and it will restart the radio. This is because as @crispyoz mentions, the STA interface is handcuffed to the AP interface. @crispyoz Agreed. The wifi driver landscape was much harsher back when we made Warp Core. Back then Warp Core outperformed MT76 by a large margin. But I 100% agree that MT76 has continued to evolve and has gotten to a place where it's more flexible and likely more performant. @crispyoz said in Configuring the station WiFi without restarting the AP: I'm not suggesting that it is better to use vanilla OpenWrt, the Onion customised release comes with nice scripts/tools to make the Omega experience very sweet, only that relying on Warp Core might not be the best long term strategy. That's actually a big piece of our OpenWRT 22.03 effort - we want to provide firmware that provides a good experience out of the box and is easy to build on top of. Part of that is a flexible and performant WiFi driver, so we're moving towards using MT76 while still providing the utilities/tools/configs that make the Omega2 easy to use

Thank you @Lazar-Demin!!!!

@sks14 docs are here https://openwrt.org/docs/guide-user/network/wifi/basic channel noise can certainly cause issues however you need to pinpoint the specific cause.

@dixit This is the factory reset process, per the document link I sent earlier

replying to an old thread i know... @sks @crispyoz it seems that the behaviour you describe puts the omega's in our application over the edge sometimes. keeping the "sta" part switched on without a wifi network to "connect to" in our case apparently eats so much resources (or something else happens) that it renders our application crippled. we are currently troubleshooting franticly because we start getting devices back from customers, sometimes even the omega's AP SSID disappears from the air and the omega needs a reboot to "fix" it. the serial console keeps working in this case, so luckily there is a way to investigate further. i really hope someone finds a way to make this more reliable. For now we will be shipping our devices in 'ap' mode instead of 'apsta' if you're interested, i just opened a help request about this at https://community.onion.io/topic/4659/wifi-driver-seems-to-crash-when-wifi-network-unavailable. cheers tony always open to suggestions

Same question to remove WiFi came in from our customer support department. We know we can disable the WiFi from software, but the customer has the specific security requirement that there should be no physical WiFi possible. I'm sorry to hear that removing the 0 Ohm resistor and the ceramic antenna isn't enough to disable the WiFi. Are there other hardware changes we can make to permanently disable (break) the WiFi on the Omega2+?

Hi crispyoz, I will check OpenWrt wifi driver Thanks for the answer.

@RandomPerson Please post the relevant portion of the build log

@gabornagy93 I would say this is a bug in wifisetup script, but you can work around it by escaping the slash. So in your case your password should be entered like so: 123\/4567 That's a backslash before the forward slash, if you then use the command uci show wireless you'll see the password is correctly recorded. I'm not sure if the password is then correctly passed when negotiating the connection and I can't test it right now, but if not, you could try entering your password on the wifisetup command like this: 123\\\/4567 This will ensure the password is recorded in your wireless setup as 123\/4567

@defa85 My first step was to divide the boot time into two sections. 1) System is up. 2) Network is functional. If you start with section 1, issue the command service network disable and reboot (make sure you have a serial/usb connection). The system will start without loading the network, I expect this will be around 30 seconds. Depending on what services and kernel modules you load, you may be able to tweak this a bit by disabling a service and loading it after your app, or removing kernel modules you don't need. We're talking a second or less for most of this standard stuff. Network connection accounts for roughly 50% of the entire boot process so if you can optimise this you will notice an impact. An ethernet connection is faster and while you may think a static IP is faster, that is not necessarily the case on all routers. Disable ipv6, configure a specific channel if you are using wifi. dmesg will give you the timings, but for more detail you can enable more detailed debugging during boot up by watching for this prompt: Press the [f] key and hit [enter] to enter failsafe mode Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level press 4 and enter, then once boot is complete use the dmesg command to see the details and timing.

@Alberto-Brosich This is a nice article on debugging wifi issues: https://community.onion.io/topic/3306/faq-how-do-i-check-if-i-m-successfully-connected-to-a-wifi-network/5?_=1610027797289 The log should give you more information about what is going on. If you are associated but not getting an IP it may be an issue with your dhcp client, to confirm this set the proto to static and hard code the ip. After restarting the network see if you can ping your network router and 8.8.8.8 (google dns) The results of this will provide more info as to where your issue may lie.

@Denis-Ber The easy way to understand how to use UCI is try this: uci show wireless Look at the result and you should see the wifi password something like this: wireless.sta.key='b840e8634d3d81e89e442cdbc' Then use the command: uci set wireless.sta.key='your new key' uci commit wireless service network restart