@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

@schluchti I imagine any hardware that is running an OS is going to take more time to power up that you need. If the Omega had a sleep mode that'd be the way to do it but as yet, that's not an option. What is the reason you need such quick power up? Is there some other way to tackle the requirement? Cheers, Chris.

@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

All base stations in a wireless distribution system must be configured to use the same radio channel, method of encryption (none, WEP, WPA or WPA2) and the same encryption keys. They may be configured to different service set identifiers (SSIDs). WDS also requires every base station to be configured to forward to others in the system.