We have upgraded the community system as part of the upgrade a password reset is required for all users before login in.

Omega2+ Wifi API



  • Hello to all.
    In my project Omega2 works under control of STM32 MCU.
    Omega soft should scan AP, connect/disconnect from AP in according commands from UART1.
    Now I using commands /bin/ubus call onion wifi-scan '{"device":"ra0"}'; /usr/bin/wifisetup add -ssid xxx -encr yyyy -password zzz and /usr/bin/wifisetup remove -ssid xxx for this.
    But this so ugly, better and more natural to use some functions and libraries.
    Second problem - if I try to connect to AP with invalid password how I can detect this error? /usr/bin/wifisetup is not reporting any error and connection process goes on continuously. But how I can to know about this?

    Is there some API for C or python to control Wifi?

    Thanks.



  • @Pavel-Negrobov In my opinion ubus is your best option however rather than using the command line you can use JSON request/response which will provide you a response code and any applicable error message. Using this method you can code in C/C++/Python or use it in PHP etc.

    This a sample JSON to scan for available wifi:

    {
    "jsonrpc": "2.0",
    "id": 1,
    "method": "call",
    "params": ["27c3cfb79f367b6ab2a8e46dd6049788", "iwinfo", "scan", {
    "device": "apcli0"
    }]
    }



  • This how you would login using curl:

    curl -d '{ "jsonrpc":"2.0", "id":1, "method": "call", "params": [ "00000000000000000000000000000000", "session", "login", { "username":"root", "password":"onioneer" } ] }' http://192.168.1.126/ubus

    The response would be like this:

    {
    "jsonrpc": "2.0",
    "id": 1,
    "result": [0, {
    "ubus_rpc_session": "aaea539f7d0f5d5a14fe6067caefc78f",
    "timeout": 300,
    "expires": 299,
    etc etc etc

    You use the ubus_rpc_session value in your next request to scan for wifi

    curl -d '{ "jsonrpc": "2.0", "id": 1, "method": "call", "params": ["aaea539f7d0f5d5a14fe6067caefc78f", "iwinfo", "scan", { "device": "apcli0" }] }' http://192.168.1.126/ubus



  • http://192.168.1.126/ubus -- as I understand your omega has some binary /www/ubus?
    In my omega it is absent:

    root@Omega-3079:/# ls -l /www
    drwxr-xr-x    3 root     root            47 Jun 11 15:10 OnionOS
    drwxr-xr-x    2 root     root            28 Jun 11 15:10 cgi-bin
    -rw-r--r--    1 root     root           771 Jun 11 15:10 index.html
    
    


  • @Pavel-Negrobov Omega OOTB uses uhttpd, the /ubus context is provided by the ubus uhttpd plugin.

    Make sure you have the latest firmware installed and installed uhttpd-mod-ubus



  • thanks, wifi scan work normally.
    But how I can connect/disconnect to AP? I didn't found nothing about this in ubus documentation



  • @Pavel-Negrobov I'm not clear on what you mean by connect/disconnect to AP. Are you referring to bring up the interface and bring it down? Or are you referring to connecting to a new AP and adding it to your network wireless setup?

    I'll assume you want to connect to a new WiFi AP you selected from the results of the iwinfo scan. UBUS gives you access to the UCI configuration functionality and we can use UCI to update the wireless configuration to add a new AP configuration. You can see the configuration file in /etc/config/wireless.

    To use UBUS you would send a JSON request as follows, to add a new wifi configuration section to the wireless config file, note that the first parameter is your ubus_rpc_session you received when you executed the login request from my previous comments. Notice we are calling UCI instead of iwinfo now:

    {
    "jsonrpc": "2.0",
    "id": 1,
    "method": "call",
    "params": ["c47f70c98fe4a145288d214ce12214fb", "uci", "add", {
    "config": "wireless",
    "type": "wifi-config"
    }]
    }

    Next we need to add the AP details to the section:

    {
    "jsonrpc": "2.0",
    "id": 1,
    "method": "call",
    "params": ["c47f70c98fe4a145288d214ce12214fb", "uci", "set", {
    "config": "wireless",
    "type": "wifi-config",
    "values": {
    "key": "eac0cc123d3f81e39a4e48d9da",
    "ssid": "MY-NETWORK-SSID",
    "encryption": "psk2"
    }
    }]
    }

    Then you send a commit to tell UCI to save these changes:

    {
    "jsonrpc": "2.0",
    "id": 1,
    "method": "call",
    "params": ["c47f70c98fe4a145288d214ce12214fb", "uci", "commit", {
    "config": "wireless"
    }]
    }

    Now look at your /etc/config/wireless and you will see the new entries.

    You will need to either restart the network to make this have effect, or you can reboot. Here is the reboot JSON:

    {
    "jsonrpc": "2.0",
    "id": 1,
    "method": "call",
    "params": ["c47f70c98fe4a145288d214ce12214fb", "system", "reboot", {}]
    }

    You will see this time we are not using iwinfo nor uci, we are using "system". This is the great thing about utilising the ubus system, you can interact with many areas of OpenWrt in a consistent manner. You just need to get your head around the ubus JSON requirements.

    You can also secure ubus by adding new users that can be given limited access to ubus functionality.



  • @crispyoz

    Yes, add AP (in OpenWRT terminology, I called this "connect to AP") works good.
    I also tried to delete AP with queries:

    {"jsonrpc": "2.0", "id": 1, "method": "call", "params": ["b2b0a3c1d176231a474e7a30bea02a99", "uci", "delete", {"config": "wireless", "type": "wifi-config", "values": {"ssid": "ZyXEL_GIGA_III" } }] }
    

    Commit UCI

    {"jsonrpc": "2.0", "id": 1, "method": "call", "params": ["b2b0a3c1d176231a474e7a30bea02a99", "uci", "commit", {"config": "wireless"}]}
    

    Restart network

    {"jsonrpc": "2.0", "id": 1, "method": "call", "params": ["b2b0a3c1d176231a474e7a30bea02a99", "network", "restart", {}]}
    

    But Omega stay connected after network restart. Where is my mistake?
    Section in /etc/config/wireless is disappeared



  • @Pavel-Negrobov please post the JSON response for the restart command. If it is returning 0 ie success, instead send network stop, pause 10 seconds, then send network start. I have seen similar issue on non-omega device where connection is maintained despite network restart when connecting to Netgear router.



  • @Pavel-Negrobov If your Omega2 is running one of recent official firmwares (ie. Onion Warp Core is its WiFi driver) and connected to a WiFi network then

    • disconnect from that WiFi network:
      uci set wireless.sta.disabled='1'; uci commit wireless; wifi
    • (re)connect to that WiFi network:
      uci set wireless.sta.disabled='0'; uci commit wireless; wifi


  • @crispyoz said in Omega2+ Wifi API:

    @Pavel-Negrobov please post the JSON response for the restart command. If it is returning 0 ie success, instead send network stop, pause 10 seconds, then send network start. I have seen similar issue on non-omega device where connection is maintained despite network restart when connecting to Netgear router.

    Restart:

    /# curl -d '{"jsonrpc": "2.0", "id": 1, "method": "call", "param
    s": ["932408e95d88194879428f3b5c75ba68", "network", "restart", {}]}' http://loca
    lhost/ubus
    {"jsonrpc":"2.0","id":1,"result":[0]}
    

    but network stop and network start both returns {"jsonrpc":"2.0","id":1,"result":[3]} and happens nothing.

    But thank you for the previous help. Login, scan and AP add (connect) works correctly.

    @György-Farkas said in Omega2+ Wifi API:

    @Pavel-Negrobov If your Omega2 is running one of recent official firmwares (ie. Onion Warp Core is its WiFi driver) and connected to a WiFi network then

    • disconnect from that WiFi network:
      uci set wireless.sta.disabled='1'; uci commit wireless; wifi
    • (re)connect to that WiFi network:
      uci set wireless.sta.disabled='0'; uci commit wireless; wifi

    Thanks. These commands are help, omega disconnects from AP after that.



  • @Pavel-Negrobov if you post the JSON response I can see what the issue is. Error 3 doesn't seem correct.

    The UCI method of disabling the interface seems like a hack to me.



  • @crispyoz said in Omega2+ Wifi API:

    The UCI method of disabling the interface seems like a hack to me.

    Hack???
    For example @Lazar-Demin also said in Really Bad Lag on 6 Nov 2019:

    @Nate are the Omegas connected to a WiFi network?
    If not and the WiFi client interface is active, it will scan for valid networks on a <10 second interval. This scanning kills the network throughput momentarily, forcing it to always be in catch-up mode.

    Sounds like this might be your issue from what you've described.

    To avoid this, just disable the wifi client interface:

    uci set wireless.sta.disabled='1'
    uci commit wireless
    wifi
    


  • @György-Farkas I respect your right to have an opinion, my opinion is different to yours and @Lazar-Demin on this point

    IMHO is should not be necessary to disable an interface in order to disconnect from a WiFi AP. All that should be required is to "forget" the WiFi credentials, disconnect (stop the network) then when the network restarts the WiFi should not reconnect.

    Calling network stop bring down all interfaces, by definition they should no longer be reconnected to anything. When you bring an interface back up it should read the configuration, that configuration will no longer contain the wifi credentials so the interface should be unable to connect.

    Disabling the interface may work, but in my opinion it is a hack since AP association is an OSI L2 function.



  • @crispyoz said in Omega2+ Wifi API:

    @Pavel-Negrobov if you post the JSON response I can see what the issue is. Error 3 doesn't seem correct.

    Here full output without any reduction (Wifi Connection is active at start):

    root@Omega-3079:/# curl -d '{ "jsonrpc":"2.0", "id":1, "method": "call", "params
    ": [ "00000000000000000000000000000000", "session", "login", { "username":"root"
    , "password":"redhat" } ] }' http://localhost/ubus
    {"jsonrpc":"2.0","id":1,"result":[0,{"ubus_rpc_session":"213ac1e069ca85b390c70570a6a58197","timeout":300,"expires":299,"acls":{"access-group":{"onion-os":["read","write"],"superuser":["read","write"],"unauthenticated":["read"]},"cgi-io":{"*":["write"],"upload":["write"]},"file":{"*":["*"]},"ubus":{"*":["*"],"file":["list","read","exec","write","stat"],"i2c_exp":["pwm-exp","relay-exp","oled-exp"],"iwinfo":["assoclist"],"network.device":["status"],"network.interface":["dump"],"network.interface.wwan":["status"],"onion":["wifi-scan","oupgrade","wifi-setup","omega-led","gpio"],"onion-console":["app-list"],"onion-helper":["*"],"onion-os":["app-list"],"rpc-sys":["reboot","password_set"],"service":["list"],"session":["access","login"],"system":["info","hostname","board"],"uci":["*"]},"uci":{"*":["read","write"],"commit":["write"],"delete":["read","write"],"get":["read","write"],"mjpg-streamer":["read","write"],"network":["read","write"],"onion":["read","write"],"rpcd":["read","write"],"set":["write"],"system":["read","write"],"wireless":["read","write"]}},"data":{"username":"root"}}]}root@Omega-3079:/#
    root@Omega-3079:/#
    root@Omega-3079:/#
    root@Omega-3079:/# curl -d '{"jsonrpc": "2.0", "id": 1, "method": "call", "param
    s": ["213ac1e069ca85b390c70570a6a58197", "uci", "delete", {"config": "wireless",
     "type": "wifi-config", "values": {"ssid": "ZyXEL_GIGA_III" } }] }' http://local
    host/ubus
    {"jsonrpc":"2.0","id":1,"result":[0]}root@Omega-3079:/#
    root@Omega-3079:/#
    root@Omega-3079:/# curl -d '{"jsonrpc": "2.0", "id": 1, "method": "call", "param
    s": ["213ac1e069ca85b390c70570a6a58197", "uci", "commit", {"config": "wireless"}
    ]}' http://localhost/ubus
    {"jsonrpc":"2.0","id":1,"result":[0]}root@Omega-3079:/#
    root@Omega-3079:/# curl -d '{"jsonrpc": "2.0", "id": 1, "method": "call", "param
    s": ["213ac1e069ca85b390c70570a6a58197", "network", "restart", {}]}' http://loca
    lhost/ubus
    [  916.850259] br-wlan: port 1(ra0) entered disabled state
    [  916.869218] device ra0 left promiscuous mode
    [  916.873758] br-wlan: port 1(ra0) entered disabled state
    [  916.922481] br-wlan: port 1(ra0) entered blocking state
    [  916.927796] br-wlan: port 1(ra0) entered disabled state
    [  916.933541] device ra0 entered promiscuous mode
    [  916.977410] br-wlan: port 1(ra0) entered blocking state
    [  916.982786] br-wlan: port 1(ra0) entered forwarding state
    {"jsonrpc":"2.0","id":1,"result":[0]}root@Omega-3079:/#
    root@Omega-3079:/# [  928.118990] br-wlan: port 1(ra0) entered disabled state
    [  928.132213] device ra0 left promiscuous mode
    [  928.136762] br-wlan: port 1(ra0) entered disabled state
    [  928.220242] IPv6: ADDRCONF(NETDEV_UP): br-wlan: link is not ready
    [  935.131816] br-wlan: port 1(ra0) entered blocking state
    [  935.137170] br-wlan: port 1(ra0) entered disabled state
    [  935.142880] device ra0 entered promiscuous mode
    [  935.147650] br-wlan: port 1(ra0) entered blocking state
    [  935.153001] br-wlan: port 1(ra0) entered forwarding state
    [  935.159845] IPv6: ADDRCONF(NETDEV_CHANGE): br-wlan: link becomes ready
    
    root@Omega-3079:/# curl -d '{"jsonrpc": "2.0", "id": 1, "method": "call", "param
    s": ["213ac1e069ca85b390c70570a6a58197", "network", "stop", {}]}' http://localho
    st/ubus
    {"jsonrpc":"2.0","id":1,"result":[3]}root@Omega-3079:/#
    root@Omega-3079:/# curl -d '{"jsonrpc": "2.0", "id": 1, "method": "call", "param
    s": ["213ac1e069ca85b390c70570a6a58197", "network", "start", {}]}' http://localh
    ost/ubus
    {"jsonrpc":"2.0","id":1,"result":[3]}root@Omega-3079:/#
    root@Omega-3079:/#
    

    My router is ZyXEL Keenetic GIGA 3



  • @crispyoz
    After these commands
    uci set wireless.sta.disabled='1'; uci commit wireless; wifi
    only the option disabled '0' line will change to option disabled '1' in the config wifi-iface 'sta' section of the /etc/config/wireless file.
    So after these commands
    uci set wireless.sta.disabled='0'; uci commit wireless; wifi
    Omega2 will be able to reconnect to that WiFi network.

    Please check it (before and after) with
    cat /etc/config /wireless
    or
    uci show wireless
    wireless.sta.disabled='1' vs. wireless.sta.disabled='0'



  • @Pavel-Negrobov Use network reload instead of restart, the methods stop and start don't exist, hence the error 3 response.

    You can look at what ubus methods are available using the command ubus -v list network



  • @György-Farkas Obviously I understand what it does, I just don't agree with the approach.


  • administrators

    @crispyoz We're open to suggestions on this, what kind of approach would you prefer?



  • @Lazar-Demin This thread has got a little off track and in fact there is no change required. My point was that disabling the interface in order to reconfigure the network may work but the correct approach is to utilise the network restart or reload approach since this is how linux networking was designed to function. Disabling the interface may work today but in the future there may be side effects of this approach.


Log in to reply
 

Looks like your connection to Community was lost, please wait while we try to reconnect.