Can I configure 'station only' mode?
I want my Omega2+ to operate as a client that connects to a WiFi access point without the Onion's AP being active at the same time. I've found the FAQ https://community.onion.io/topic/3305/faq-how-do-i-turn-off-the-omega-s-wifi-access-point which states: "You cannot turn off the Omega's WiFi Access Point and still connect to an external WiFi network."
I'm wondering why that's impossible since the MediaTek API seems to support it.
The FAQ is 2 years old and I'm wondering if there have been any changes to the Warp core here.
@ckielstra this is an oft asked question and usually I would look at the source to get the answer, but the Warp Core wifi module developed by Onion is not open source so we cannot look. I've often wondered if we used the standard OpenWrt Mediatek driver if this feature would be available. On all of my devices (~250) I hide the AP and set a random ssid and password so. Here is an example from one of my devices:
option ssid 'e8c0ec6432ddbd9-6BC3FD3D' option key 'gnkdsjhfksfksgf;isyuf' option hidden '1'
I would add that an IP table rule be declared. For example:
iptables -I INPUT 1 -i br-wlan -m mac ! --mac-source <br-wlan MAC>
-j DROP or similar.
For two nodes to communicate, the MAC must be different. The above would block any MAC that is not <br-wlan MAC> on interface br-wlan which is effectively any wireless node.
luz last edited by
I've often wondered if we used the standard OpenWrt Mediatek driver if this feature would be available.
Yes, the standard OpenWrt driver for Mediatek,
mt76, supports switching AP and Station modes on and off independently.
I can tell because always build my own OpenWrt for my Omega2 projects, so I cannot use the non-open onion driver and always use mt76, and most of the time (after initial setup) in station-only mode.
In the early days of Omega2, mt76 was not yet really usable - it was hard to get a reliable WiFi connection in many cases. Which probably led Onion to develop their own, proprietary driver.
Today mt76 is working very well.
Why? Because another company who makes MT7688 based devices had the same problem (bad WiFi), but solved it in a different way.
They just contacted the author of mt76 and paid him some real engineering time to iron out problems. That was a very efficient way for them to get working WiFi (both in terms of cost and time).
Not only that: mt76 is a maintained part of OpenWrt - in contrast to proprietary code where a burden for maintaining and updating remains attached for the company that creates it.
And of course this is a huge benefit for everyone else using WiFi with MT76xx chips, with no dependency on a specific company's decision or ability to maintain a driver in the future.
Thanks @luz I've been meaning to test it for ages but never found the time.
maintaining and updating remains attached for the company that creates it.
Wired TCP/IP is implemented, wireless for all boards are in "planned" stage for the past 2+ years. It is "a lot of work", - encryption- as posted in their forums.
@tjoseph1 and one day it will be as good as OpenWrt! or maybe it will run out of steam.
Another project is rust-embedded..
The goal is to support mips, risc-v & arm (cortex-A/M and may be R?).
BTW, rpi3/4 supported, but w/o wifi ..!.
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.