After a stupid amount of work to get the Onion to popup again in the wifi network bank, and then another stupid amount of work to get the ports turned on in my device manager, after downloading and installing https://www.silabs.com/Support Documents/Software/CP210x_VCP_Windows.zip - it still won't recognize it. I can't connect. I can't even get it back to a previous firmware since I need to connect via serial. Technically, I have an ethernet shield, but that has not worked. The Onion has really soured my experience with development boards. Everything from Day 1 all those years ago has been cumbersome and confusing. I feel lied to because the commercial made it sound so accessible and easy-to-use. I bought this from Indiegogo years ago. I haven't been able to complete one successful project. (With the exception of maybe turning it into a wifi range extender, but I am not entirely sure that worked.) I couldn't even get morse code to work. I even jumped through hoops to figure out the morse code project. Then I saw the new firmware update and thought it would be easier to navigate. Unfortunately, I downloaded it and now I'm dead in the water. I can't even restore it because the directions require a serial connection. I bit the bullet when my board could no longer use Node Red, and I bit the bullet again when it was no longer cloud connected (which were two huge perks). Granted, it is too much of a pain. I think I'm done for now. I might pick it up again, but I don't have the bandwidth right now. Despite my repeated failure I learned a bit. Thank you for helping, and I appreciate the community. Since the Onion does have users of all skill levels, my suggestion would be to write (and structure) instructions as if you expect zero programming experience to read it. More importantly, please have instructional videos.

@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.

@AKindTexan : << want to be able to read the WiFi signal to noise ratio to determine if I have a bad WiFi environment. << It would be better off with something like kismet https://www.kismetwireless.net running in a workstation. May be, you are looking for a representation like this: https://en.wikipedia.org/wiki/Kismet_(software)#/media/File:Kismet-2.7.1-screenshot.gif Kismet has listed the supported wifi hardware in the above site. The typical capture is in the order of megabytes every second or even more, depending on the environment. Omega2+ has 802.11 b/g/n, (5 GHz support is optional in "n") up to 150Mbps as per specs, where as n itself is 54-600Mbps. Also, there are hardware analyzers that meets the needs of a CWAP. Thanks..

Thank you @crispyoz, I actually finally got it working this morning just the way I wanted. Here's a simple example based on what I did: printf "%s" "Connecting to WiFi" wifisetup add -ssid Network-SSID -encr wpa2 -password XXXXXXXX printf "%s" "Waiting for Internet" while ! ping -c 1 -n -w 1 www.google.com &> /dev/null do printf "%c" "." done printf "\n%s\n" "Internet Connected" opkg update Seems to be running great. It waits indefinitely but I don't want it to proceed until Internet connection is there so I didn't figure there was any reason to have a retry count. I'm using an on board RGB LED to indicate when the script starts, when it connects to wifi and begins installing OPKG packages, and when it is complete. This will be used for configuring a group of Onion modules prior to installation in our product. AutoRun is fantastic!

I'm going to pass on watching the video, but instead here are some tips on the setup scripts. If you're just interested in how the wifi is configured, take a look at /usr/bin/wifisetup for the guts of the process. If you're interested in all of the backend behind the web first-time configuration, examine the content under /www/OnionOS/static/js.

That's great news @mandroid, congrats!