Posts made by crispyoz

@Ralph-Hulslander @victoriano is correct, Omega is not a PC, there are limited resources available and any of the major GUI browsers are way too bloated to run on a device with limited resources. Take a look at lynx, it is a text based browser, has been around for decades and will run on your Omega.

@Jens-Modvig I'm watching with interest.

@CoffeeCat you need to press the letter i to get vi into insert mode.

crontab -e uses the vi editor. Vi has 2 modes, command mode and insert mode. If you are in insert mode you can type # and it will be inserted. If you are not in insert mode, you are in command mode, in which case # is interpreted as a command that does not exist.

So press i to put yourself into insert mode, then you can type the # etc

@luz Yes of course. Maybe dmidecode can help.

I track my device configurations using my serial number generator.

@CoffeeCat it sounds like there is an issue with your crontabs directory, assuming you have nothing in crontabs you need, you can use this command sequence to resolve the issue:

rm -rf /etc/crontabs
mkdir /etc/crontabs

Then try starting again at crontab -e

BTW instead of :wq command you can use ZZ to save and quit.

@luz try ubus call system board

    "system": "MediaTek MT7688 ver:1 eco:2",
    "model": "Onion Omega2+",
    "board_name": "omega2p",

I use /proc/cpuinfo to identify Omega2S vs Omega2S+ in my software.

I saw the dock a couple of weeks ago, seems like a good idea but personally I prefer discreet functional expansions.

@Pavel-Negrobov assuming you are using dhcp could check if you have a valid ip on that interface with ubus call network.interface.wwan status and examine the "ipv4-address.address"

@Pavel-Negrobov I don't know any way of actually checking the WiFi is successfully connected since UCI just changes the configuration. I just try to programatically open a connection to a known good host and check the response code.

@CAP-33 uhttpd is installed in the standard Omega firmware build and you can add php7 support. Take a look at this link:

https://openwrt.org/docs/guide-user/services/webserver/php

I find nginx performs a lot better than uhttpd, you can see the installation details here:

https://openwrt.org/docs/guide-user/services/webserver/nginx

@Pavel-Negrobov sta shows as disabled so I'm not sure how it would be associated with anything. If @György-Farkas solution works for you you should go with that.

@ckielstra Since there is no other suggestions I have 2 thing you could look at.

1. /etc/config/fstab allows you to set up mount points with the various configs. I use one for the sdcard on my devices to set up the mount point and the file system type. The docs refer to an additional "options" option which can be used to set mount options. I expect this includes the ro option but I have not tried it.

2. The USB hotplug script is executed when you insert a USB device, you could add your own script to remount in read only mode. This is a hack you could use in the absence of a better solution.

@Pavel-Negrobov If you examine your /etc/config/wireless you will see the ssid and key are still present on the sta interface section so the device will still be associated with the ap.

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

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

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

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

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

@Radek I think we all appreciate your passion and we look forward to your future contributions.