reForis issueshttps://gitlab.nic.cz/turris/reforis/reforis/-/issues2024-03-20T12:53:25+01:00https://gitlab.nic.cz/turris/reforis/reforis/-/issues/434An Error Occurred - shadowRoot2024-03-20T12:53:25+01:00Aleksandr GumroianAn Error Occurred - shadowRootSome users experienced this problem:
```
An Error Occurred
Error: Permission denied to access property "shadowRoot"
More detailed information is available in the console of your web browser - on most browsers accessible after pressing ...Some users experienced this problem:
```
An Error Occurred
Error: Permission denied to access property "shadowRoot"
More detailed information is available in the console of your web browser - on most browsers accessible after pressing Ctrl+Shift+J or F12.
```
Most probably it's connected to some library.Aleksandr GumroianAleksandr Gumroianhttps://gitlab.nic.cz/turris/reforis/reforis/-/issues/433Zeroconf resolve br-guest-turris A record in br-lan network via MDNS.2024-03-20T09:24:40+01:00laser84Zeroconf resolve br-guest-turris A record in br-lan network via MDNS.# Summary
Zeroconf resolve br-guest-turris A record in br-lan network via MDNS.
Address turris.local is sometime unavaliable from br-lan, attempting to connect isolated subnet address 10.111.222.1.
Pre-installed umdns service in OpenWR...# Summary
Zeroconf resolve br-guest-turris A record in br-lan network via MDNS.
Address turris.local is sometime unavaliable from br-lan, attempting to connect isolated subnet address 10.111.222.1.
Pre-installed umdns service in OpenWRT does in paraller same thing, but correctly.
# Steps To Reproduce
1. Wireshark dump:
```
192.168.1.1 224.0.0.251 MDNS 98 Standard query response 0x0000 A, cache flush 10.111.222.1 A, cache flush 192.168.1.1
```
2. Ping:
```
ping turris
Pinging turris.local [10.111.222.1] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 10.111.222.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
```
# Expected Result
Should work.
# Actual Result
Doesn't work.https://gitlab.nic.cz/turris/reforis/reforis/-/issues/428Fix link to EULA2024-02-21T18:29:07+01:00Filip HronFix link to EULAEULA link is pointing to old location [https://www.turris.cz/omnia-updater-eula](https://www.turris.cz/omnia-updater-eula)
new proper link will be known from resolution of ticket: https://gitlab.nic.cz/turris/ansible/-/issues/321EULA link is pointing to old location [https://www.turris.cz/omnia-updater-eula](https://www.turris.cz/omnia-updater-eula)
new proper link will be known from resolution of ticket: https://gitlab.nic.cz/turris/ansible/-/issues/321https://gitlab.nic.cz/turris/reforis/reforis/-/issues/424DeprecationWarning: pkg_resources is deprecated as an API2023-10-13T18:02:38+02:00Aleksandr GumroianDeprecationWarning: pkg_resources is deprecated as an APIThere are some warnings about the deprecation of `pkg_resources`.
<details>
<summary>Click to expand</summary>
```
=============================== warnings summary ===============================
reforis/__init__.py:20
/builds/turri...There are some warnings about the deprecation of `pkg_resources`.
<details>
<summary>Click to expand</summary>
```
=============================== warnings summary ===============================
reforis/__init__.py:20
/builds/turris/reforis/reforis/reforis/__init__.py:20: DeprecationWarning: pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html
import pkg_resources
-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
======================== 46 passed, 1 warning in 1.55s =========================
```
</details>
From setuptools [documentation](https://setuptools.pypa.io/en/latest/pkg_resources.html):
>>>
Use of pkg_resources is deprecated in favor of importlib.resources, importlib.metadata and their backports (importlib_resources, importlib_metadata). Some useful APIs are also provided by packaging (e.g. requirements and version parsing). Users should refrain from new usage of pkg_resources and should work to port to importlib-based solutions.
>>>https://gitlab.nic.cz/turris/reforis/reforis/-/issues/421MOX: Distinguish Wi-Fi modules2024-02-08T17:47:14+01:00Marek NovotnyMOX: Distinguish Wi-Fi modules# Summary
Using MOX there is currently no way in reForis to distinguish in _Network Settings_ -> _Wi-Fi_ which Wi-Fi interface is which MOX module (eg. SDIO or MOX G with Wi-Fi card)
# Expected Result
Since MOX is highly configurable de...# Summary
Using MOX there is currently no way in reForis to distinguish in _Network Settings_ -> _Wi-Fi_ which Wi-Fi interface is which MOX module (eg. SDIO or MOX G with Wi-Fi card)
# Expected Result
Since MOX is highly configurable device, it would help name the interfaces accordingly by their MOX module.https://gitlab.nic.cz/turris/reforis/reforis/-/issues/420MOX: Add human readable names for MOX modules2023-09-25T14:09:20+02:00Marek NovotnyMOX: Add human readable names for MOX modules# Summary
Change how MOX HW configuration notification names MOX'es modules to a more user-friendly official module names.
![Screenshot_from_2023-09-15_16-38-33](/uploads/0cc36b0ac23d37593bd5ac1b62a70c46/Screenshot_from_2023-09-15_16-38...# Summary
Change how MOX HW configuration notification names MOX'es modules to a more user-friendly official module names.
![Screenshot_from_2023-09-15_16-38-33](/uploads/0cc36b0ac23d37593bd5ac1b62a70c46/Screenshot_from_2023-09-15_16-38-33.png)
# Expected Result
```
Your MOX HW configuration changed! You added MOX E, MOX D, MOX F module(s). You removed MOX E, MOX D module(s).
Make sure that your setup is correct or try factory reset for new setup.
```
# Actual Result
```
Your MOX HW configuration changed! You added moxtet-peridot.2 moxtet-sfp.3 moxtet-usb3.1 module(s).
You removed moxtet-peridot.1 moxtet-sfp.2 module(s). Make sure that your setup is correct or try factory reset for new setup.
```https://gitlab.nic.cz/turris/reforis/reforis/-/issues/418Add Wi-Fi 6 option2024-03-21T15:39:32+01:00Filip HronAdd Wi-Fi 6 optionAllow user to switch ``Wi-Fi 6E`` when supported card is connected.Allow user to switch ``Wi-Fi 6E`` when supported card is connected.Aleksandr GumroianAleksandr Gumroianhttps://gitlab.nic.cz/turris/reforis/reforis/-/issues/417DHCP Lease Time changes to seconds upon reenabling DHCP2024-03-25T14:24:38+01:00Sandor NemesDHCP Lease Time changes to seconds upon reenabling DHCP# Summary
The "Lease time (hours)" field on the LAN page shows the value incorrectly in seconds after disabling, then reenabling the DHCP server.
- Device: Turris Omnia
- reForis version: 1.4.1
- Turris OS version: 6.3.3
# Steps To Rep...# Summary
The "Lease time (hours)" field on the LAN page shows the value incorrectly in seconds after disabling, then reenabling the DHCP server.
- Device: Turris Omnia
- reForis version: 1.4.1
- Turris OS version: 6.3.3
# Steps To Reproduce
1. Open reForis web UI.
2. Go to Network Settings > LAN.
3. Enable DHCP, and set "Lease time (hours)" field to 24, then click "Save". (See attached screenshot)
![step_3](/uploads/87b726aedae04e6c76c23705e638f3bf/step_3.png)
4. Disable DHCP, then click "Save". (See attached screenshot).
![step_4](/uploads/e94b0aaf799f3fc73ffa1fe8f9927692/step_4.png)
5. Enable DHCP, "Lease time (hours)" field becomes 86400 (which is in seconds, 86400 seconds = 24 hours). (See attached screenshot)
![step_5](/uploads/873ff2bb6277574a03ef3b335433f9e9/step_5.png)
# Expected Result
"Lease time (hours)" field should be consistent, and show the unit in hours (as the label claims that the unit is "hours").
In this case it should show the value 24.
# Actual Result
"Lease time (hours) field incorrectly shows the value 86400.Aleksandr GumroianAleksandr Gumroianhttps://gitlab.nic.cz/turris/reforis/reforis/-/issues/416can't set "Domain of DHCP clients in DNS" to anything beside 'lan'2023-08-16T10:31:02+02:00bugrasan nacan't set "Domain of DHCP clients in DNS" to anything beside 'lan'# Summary
This is an example bug report.
# Steps To Reproduce
1. login into reForis
2. navigate to *Network Settings* => *DNS*
3. enable *Enable DHCP clients in DNS*
4. change *Domain of DHCP clients in DNS* to anything else beside `lan...# Summary
This is an example bug report.
# Steps To Reproduce
1. login into reForis
2. navigate to *Network Settings* => *DNS*
3. enable *Enable DHCP clients in DNS*
4. change *Domain of DHCP clients in DNS* to anything else beside `lan`, e.g. `home.arpa`
5. then save
6. try to resolve a host that received an ip from DHCP, e.g. `myhost`
`host myhost` or `host myhost.home.arpa` both will fail.
7. change *Domain of DHCP clients in DNS* to `lan` back
8. then save
6. try to resolve a host that received an ip from DHCP, e.g. `myhost`
`host myhost` or `host myhost.lan` both will work.
# Expected Result
Should work.
this has been already reported a long time ago:
https://forum.turris.cz/t/turris-os-4-0-beta1-is-released/10107/101
# Actual Result
Doesn't work.
# Turris info
- device: turris omnia
- reforis version: 1.4.1
- turris os version: 6.3.3
- turris branch: HBS
- kernel version: 5.15.114https://gitlab.nic.cz/turris/reforis/reforis/-/issues/413Feature request: U-Boot version on About page2023-06-07T13:33:27+02:00Lukas JelinekFeature request: U-Boot version on About pageThe current _About_ page contains version information related to the TOS itself, reForis and Linux kernel. But the U-Boot version would be useful too - see the picture below.
![uboot](/uploads/10875f442fe310469d684939d5d57ccd/uboot.png)The current _About_ page contains version information related to the TOS itself, reForis and Linux kernel. But the U-Boot version would be useful too - see the picture below.
![uboot](/uploads/10875f442fe310469d684939d5d57ccd/uboot.png)https://gitlab.nic.cz/turris/reforis/reforis/-/issues/411Block wizzard when updates are in progress2023-08-16T10:30:35+02:00Michal HruseckyBlock wizzard when updates are in progressDuring the first setup of the router, user can enable automatic updates and when those get triggered the backend might stop responding (till update is finished). This can result in unexpected behavior during the initial setup. Would be b...During the first setup of the router, user can enable automatic updates and when those get triggered the backend might stop responding (till update is finished). This can result in unexpected behavior during the initial setup. Would be best it this situation could be detected and some "Wait for the updates to finish" placeholder could be displayed in the meantime.
Reported by @mblazkovaAleksandr GumroianAleksandr Gumroianhttps://gitlab.nic.cz/turris/reforis/reforis/-/issues/410Add a button to update the factory snapshot2024-03-27T13:04:19+01:00Stepan RechnerAdd a button to update the factory snapshotcc @mmatejek @mhrusecky
It would be nice for nonadvanced users to have a button to update a factory image before. If one resets the router to a too-old version, an update is not possible because of expired certificates. And it is in ge...cc @mmatejek @mhrusecky
It would be nice for nonadvanced users to have a button to update a factory image before. If one resets the router to a too-old version, an update is not possible because of expired certificates. And it is in general more useful to have the newest factory possible if one wishes to reset the router to factory defaults.
Sensful locations:
* `/reforis/administration/maintenance`
* `/reforis/administration/snapshots`Aleksandr GumroianAleksandr Gumroianhttps://gitlab.nic.cz/turris/reforis/reforis/-/issues/409Introduce Third state for test_connection results2024-03-27T13:04:32+01:00Filip HronIntroduce Third state for test_connection resultsFor now, there are two states in response on `wan/test_connection_state` (when finished)
The backend is however ready to serve three states
- `"OK"` > test passed
- `"FAILED"` > test failed
- `"UNKNOWN"` > the result cannot be determine...For now, there are two states in response on `wan/test_connection_state` (when finished)
The backend is however ready to serve three states
- `"OK"` > test passed
- `"FAILED"` > test failed
- `"UNKNOWN"` > the result cannot be determined
Please introduce to frontend.Aleksandr GumroianAleksandr Gumroianhttps://gitlab.nic.cz/turris/reforis/reforis/-/issues/408wifi: Encryption settings are not applied to guest network, just the regular ...2023-01-30T15:16:40+01:00Martin Matějekwifi: Encryption settings are not applied to guest network, just the regular wifi network## Description
Update of wifi settings will send wrong value for guest network encryption, regardless of the selected encryption for the regular wifi.
<details>
<summary>
See screenshot
</summary>
![reforis-guest-wifi-encryption](/upl...## Description
Update of wifi settings will send wrong value for guest network encryption, regardless of the selected encryption for the regular wifi.
<details>
<summary>
See screenshot
</summary>
![reforis-guest-wifi-encryption](/uploads/b1b83b7ed1d234492c7fa999176af3cf/reforis-guest-wifi-encryption.png)
</details>
Foris-controller supports setting different encryption modes for regular and guest wifi, however we don't have separate input field for guest network encryption in WiFi page.
Thus in most cases, it will send "WPA2/3" as guest network encryption in POST request.
My guess is that this is caused by the fact that we don't process the `guest_wifi.encryption` value (from GET request) in WiFi form and this value is just sent back within the POST request data for update of wifi settings.
I also believe, that value "WPA2/3" comes from defaults provided by foris-controller, in case the guest wifi settings are missing. Otherwise we receive and send back whatever value is in uci configuration (from LuCI, by hand, ...).
## Proposed solution
* a) Either use `encryption` value for `guest_wifi.encryption`, i.e. force the same encryption method for both networks.
* b) Or add additional input to form, which will allow to select encryption method for guest wifi too.Aleksandr GumroianAleksandr Gumroianhttps://gitlab.nic.cz/turris/reforis/reforis/-/issues/402Add Turris logo to Wi-Fi QR code2022-12-08T13:47:23+01:00Aleksandr GumroianAdd Turris logo to Wi-Fi QR codeThe idea is to refine the QR code look and put a logo in it.
<details><summary>Click to expand</summary>
![frame](/uploads/009e58bb8db7df16a68fa243ca804364/frame.png)
</details>The idea is to refine the QR code look and put a logo in it.
<details><summary>Click to expand</summary>
![frame](/uploads/009e58bb8db7df16a68fa243ca804364/frame.png)
</details>https://gitlab.nic.cz/turris/reforis/reforis/-/issues/400Mox: Cannot mark guide as finished HBS 6.0.22023-08-25T16:53:23+02:00Martin MatějekMox: Cannot mark guide as finished HBS 6.0.2# Summary
Mox Power Wi-Fi, TOS 6.0.2 (HBS)
Althought it could probably happen on any Mox with one ethernet interface (just module A).
This is most likely issue in backend and/or TOS default configuration itself, but I have created this...# Summary
Mox Power Wi-Fi, TOS 6.0.2 (HBS)
Althought it could probably happen on any Mox with one ethernet interface (just module A).
This is most likely issue in backend and/or TOS default configuration itself, but I have created this issue to track the unexpected "User experience" issue here.
# Steps To Reproduce
1. Fresh install of TOS 6.0.2 (medkit/factory reset).
2. Setup Mox using the Server workflow.
3. Try to finish guide.
# Expected Result
Guide should finish successfully.
# Actual Result
Error message `Cannot mark guide as finished.` appears.
![2022-11-11T20_00_39_642335935+01_00](/uploads/177720d1a8b0e0d59bacefc5d442e8e2/2022-11-11T20_00_39_642335935+01_00.png)
With additional error description from backend for http request
```
https://<router-ip>/reforis/api/finish-guide
```
<details>
<summary>See details</summary>
```
500 - Server error
Error:
Remote Exception: Internal error Uci record was not found 'network.wan.device'.('<class 'foris_controller.exceptions.UciRecordNotFound'>')
Extra:
{"module": "web", "action": "update_guide", "kind": "request", "data": {"enabled": false}}
Trace:
Traceback (most recent call last): File "/usr/lib/python3.9/site-packages/foris_controller_backends/uci/__init__.py", line 80, in get_option_named KeyError: 'device' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.9/site-packages/foris_controller/message_router.py", line 117, in process_message File "/usr/lib/python3.9/site-packages/foris_controller/module_base.py", line 61, in perform_action File "/usr/lib/python3.9/site-packages/foris_controller_modules/web/__init__.py", line 66, in action_update_guide File "/usr/lib/python3.9/site-packages/foris_controller_modules/web/handlers/openwrt.py", line 75, in update_guide File "/usr/lib/python3.9/site-packages/foris_controller_backends/web/__init__.py", line 157, in update_guide File "/usr/lib/python3.9/site-packages/foris_controller_backends/wan/__init__.py", line 393, in update_uncofigured_wan_to_default File "/usr/lib/python3.9/site-packages/foris_controller_backends/wan/__init__.py", line 326, in update_settings File "/usr/lib/python3.9/site-packages/foris_controller_backends/uci/__init__.py", line 83, in get_option_named foris_controller.exceptions.UciRecordNotFound: Uci record was not found 'network.wan.device'.
```
</details>
On reload of the "Finish" page, redirect to reforis may happen with another error.
```
500 - Server error
Error:
500 Internal Server Error: The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application.
```
However on another reload, reforis UI is finally shown to user and the error is gone.https://gitlab.nic.cz/turris/reforis/reforis/-/issues/395Threat detection status on dashboard should reflect problems2022-12-05T16:36:43+01:00Lukas JelinekThreat detection status on dashboard should reflect problemsThe current implementation of the Thread detection status on the dashboard indicates only whether the `sentinel-proxy` works. It means that malfunction of some Sentinel components are displayed only on the Sentinel overview page and not ...The current implementation of the Thread detection status on the dashboard indicates only whether the `sentinel-proxy` works. It means that malfunction of some Sentinel components are displayed only on the Sentinel overview page and not on the dashboard. An user would think that everything is OK even if it doesn't (for example, firewall logs don't work).
![sentinel-ok](/uploads/4ce88bd76430dbf68555fa3ed9781888/sentinel-ok.png)
I suggest to add some third state (e.g. with a a yellow exclamation sign - see below) for situations when Sentinel works but one or more its components don't.
![sentinel-warn](/uploads/eed79a251baa6dea06714c5e2d402157/sentinel-warn.png)https://gitlab.nic.cz/turris/reforis/reforis/-/issues/394The list of updated packages is too long2022-12-06T11:44:35+01:00Josef SchlehoferThe list of updated packages is too longThere should be some page listing or provide users with to choose how many packages he wants to see per page. This slightly improves UX, so the button, is on the end of the page to approve updates will be noticeable on the first sight.There should be some page listing or provide users with to choose how many packages he wants to see per page. This slightly improves UX, so the button, is on the end of the page to approve updates will be noticeable on the first sight.Aleksandr GumroianAleksandr Gumroianhttps://gitlab.nic.cz/turris/reforis/reforis/-/issues/393reForis is missing CSS/JS files while using node 18 because of Webpack and i...2022-12-05T16:36:14+01:00Josef SchlehoferreForis is missing CSS/JS files while using node 18 because of Webpack and its dependenciesError log:
```
Webpack --mode=production --env.lighttpd -o /turris1x/build/build_dir/target-powerpc_8548_musl/reforis-1.3.1/build/lib/reforis_static/reforis/js/app.min.js
Browserslist: caniuse-lite is outdated. Please run:
npx browse...Error log:
```
Webpack --mode=production --env.lighttpd -o /turris1x/build/build_dir/target-powerpc_8548_musl/reforis-1.3.1/build/lib/reforis_static/reforis/js/app.min.js
Browserslist: caniuse-lite is outdated. Please run:
npx browserslist@latest --update-db
Why you should do it regularly: https://github.com/browserslist/browserslist#browsers-data-updating
node:internal/crypto/hash:71
this[kHandle] = new _Hash(algorithm, xofLen);
^
Error: error:0308010C:digital envelope routines::unsupported
at new Hash (node:internal/crypto/hash:71:19)
at Object.createHash (node:crypto:133:10)
at module.exports (/turris1x/build/build_dir/target-powerpc_8548_musl/reforis-1.3.1/js/node_modules/webpack/lib/util/createHash.js:135:53)
at NormalModule._initBuildHash (/turris1x/build/build_dir/target-powerpc_8548_musl/reforis-1.3.1/js/node_modules/webpack/lib/NormalModule.js:417:16)
at handleParseError (/turris1x/build/build_dir/target-powerpc_8548_musl/reforis-1.3.1/js/node_modules/webpack/lib/NormalModule.js:471:10)
at /turris1x/build/build_dir/target-powerpc_8548_musl/reforis-1.3.1/js/node_modules/webpack/lib/NormalModule.js:503:5
at /turris1x/build/build_dir/target-powerpc_8548_musl/reforis-1.3.1/js/node_modules/webpack/lib/NormalModule.js:358:12
at /turris1x/build/build_dir/target-powerpc_8548_musl/reforis-1.3.1/js/node_modules/loader-runner/lib/LoaderRunner.js:373:3
at iterateNormalLoaders (/turris1x/build/build_dir/target-powerpc_8548_musl/reforis-1.3.1/js/node_modules/loader-runner/lib/LoaderRunner.js:214:10)
at iterateNormalLoaders (/turris1x/build/build_dir/target-powerpc_8548_musl/reforis-1.3.1/js/node_modules/loader-runner/lib/LoaderRunner.js:221:10)
at /turris1x/build/build_dir/target-powerpc_8548_musl/reforis-1.3.1/js/node_modules/loader-runner/lib/LoaderRunner.js:236:3
at context.callback (/turris1x/build/build_dir/target-powerpc_8548_musl/reforis-1.3.1/js/node_modules/loader-runner/lib/LoaderRunner.js:111:13)
at /turris1x/build/build_dir/target-powerpc_8548_musl/reforis-1.3.1/js/node_modules/babel-loader/lib/index.js:55:71
at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
opensslErrorStack: [ 'error:03000086:digital envelope routines::initialization error' ],
library: 'digital envelope routines',
reason: 'unsupported',
code: 'ERR_OSSL_EVP_UNSUPPORTED'
}
```Aleksandr GumroianAleksandr Gumroianhttps://gitlab.nic.cz/turris/reforis/reforis/-/issues/389Consider interface IP addresses preference on reconnect after reboot or netwo...2022-12-06T11:44:40+01:00Martin MatějekConsider interface IP addresses preference on reconnect after reboot or network restartAfter reconnect event (network restart, router reboot) reforis seems to only utilize the first IP from the list.
see https://gitlab.nic.cz/turris/reforis/reforis/-/blob/master/js/src/routerStateHandler/utils.js#L45
It is quite possible...After reconnect event (network restart, router reboot) reforis seems to only utilize the first IP from the list.
see https://gitlab.nic.cz/turris/reforis/reforis/-/blob/master/js/src/routerStateHandler/utils.js#L45
It is quite possible to get WAN interface IP address as first in the list and user gets redirected to unexpected location (WAN instead of LAN).
Would it be reasonable or feasible to handle preference of interfaces (LAN, WAN) from more structured data on frontend? Prefer LAN, but use WAN as fallback in case there are no LAN IPs present.
Something similar to (crude example):
```js
{
"ips": {
"lan": [...],
"wan": [...]
}
}
```
See https://gitlab.nic.cz/turris/os/packages/-/merge_requests/959#note_260014