foris-controller issueshttps://gitlab.nic.cz/turris/foris-controller/foris-controller/-/issues2024-03-21T17:25:37+01:00https://gitlab.nic.cz/turris/foris-controller/foris-controller/-/issues/267Notification about result of first measurement does not reach frontend2024-03-21T17:25:37+01:00Martin MatějekNotification about result of first measurement does not reach frontendNotification about result of first measurement run (`{'async_id': 'someid', 'passed': true}`) does not reach frontend through WS.
However the second and any additional measurement will successfully send the "end of measurement" notificat...Notification about result of first measurement run (`{'async_id': 'someid', 'passed': true}`) does not reach frontend through WS.
However the second and any additional measurement will successfully send the "end of measurement" notification.
<details>
<summary>Example run</summary>
```
===================== message recieved for 'foris-controller/0000000B00007B3C/request/librespeed/action/measure' =====================
{
"reply_msg_id": "96720bea-1237-4d5f-ae3c-2b95e8d8caf1"
}
======================================================================================================================================
===================== message recieved for 'foris-controller/0000000B00007B3C/reply/96720bea-1237-4d5f-ae3c-2b95e8d8caf1' =====================
{
"kind": "reply",
"module": "librespeed",
"action": "measure",
"data": {
"async_id": "1d80efe569b5174f"
}
}
===============================================================================================================================================
===================== message recieved for 'foris-controller/0000000B00007B3C/reply/96720bea-1237-4d5f-ae3c-2b95e8d8caf1' =====================
b''
===============================================================================================================================================
===================== message recieved for 'foris-controller/0000000B00007B3C/request/librespeed/action/measure' =====================
{
"reply_msg_id": "3dbc088c-7363-4a63-aacd-0fe9908491be"
}
======================================================================================================================================
===================== message recieved for 'foris-controller/0000000B00007B3C/reply/3dbc088c-7363-4a63-aacd-0fe9908491be' =====================
{
"kind": "reply",
"module": "librespeed",
"action": "measure",
"data": {
"async_id": "2e3ef465c6f3398d"
}
}
===============================================================================================================================================
===================== message recieved for 'foris-controller/0000000B00007B3C/reply/3dbc088c-7363-4a63-aacd-0fe9908491be' =====================
b''
===============================================================================================================================================
===================== message recieved for 'foris-controller/0000000B00007B3C/notification/librespeed/action/measure' =====================
{
"module": "librespeed",
"kind": "notification",
"action": "measure",
"data": {
"async_id": "2e3ef465c6f3398d",
"passed": true
}
}
```
</details>
Good way to reproduce this issue is to run librespeed measurement soon after TOS boot.
I am not completely sure whether foris-controller module is the culprit here, so feel free to move this issue elsewhere.Štěpán HenekŠtěpán Henekhttps://gitlab.nic.cz/turris/foris-controller/foris-controller/-/issues/273wifi: 2.4GHz channel width limitation2024-03-18T15:40:33+01:00Richard Muzikwifi: 2.4GHz channel width limitationWhen you switch to 2.4GHz Wi-Fi, it automatically selects the 160MHz wide channel, which does not work. The widths that do work with 2.4GHz are 20MHz and 40MHz. We should limit the option in the reForis when 2.4GHz is selected.When you switch to 2.4GHz Wi-Fi, it automatically selects the 160MHz wide channel, which does not work. The widths that do work with 2.4GHz are 20MHz and 40MHz. We should limit the option in the reForis when 2.4GHz is selected.Štěpán HenekŠtěpán Henekhttps://gitlab.nic.cz/turris/foris-controller/foris-controller/-/issues/247Network Settings/WAN: An unknown API error occurred.2024-03-12T14:59:37+01:00Tibor KékesiNetwork Settings/WAN: An unknown API error occurred.# Summary
The 'Network Settings' - WAN, page shows this error: 'An unknown API error occurred'.
checkd in versions:
Turris OS 5.4.4
Turris OS 6.0.1
# Steps To Reproduce
1. in LuCI save the already configured settings for WAN6
2. in ref...# Summary
The 'Network Settings' - WAN, page shows this error: 'An unknown API error occurred'.
checkd in versions:
Turris OS 5.4.4
Turris OS 6.0.1
# Steps To Reproduce
1. in LuCI save the already configured settings for WAN6
2. in reforis check the Network Settings for WAN
# Expected Result
When the configuration was done in reForis then there is no API error. When the interface is configured/changed in LuCI there will be API error. It is due to the problem in reForis:
in **network** config:
config interface 'wan6'
list ip6prefix 'xxxxxx' <-- ip6prefix should be type 'option'
option ip6addr 'xxxxxx' <-- ip6addr type 'option' and 'list' should be accepted (configuration in LuCI interface will change the type to list and will cause API error in reForis)
# Actual Result
Doesn't work.https://gitlab.nic.cz/turris/foris-controller/foris-controller/-/issues/150Firewall configuration (plugin) for port forwarding2024-02-21T18:22:14+01:00Karel KociFirewall configuration (plugin) for port forwardingIt is common and expected by users to have easy to use firewall configuration. Primary usage of that is port forwarding.
This can be either new plugin or if it makes sense it can be part of core.
We need port forwarding such as:
```
co...It is common and expected by users to have easy to use firewall configuration. Primary usage of that is port forwarding.
This can be either new plugin or if it makes sense it can be part of core.
We need port forwarding such as:
```
config redirect
option target DNAT
option src wan
option dest lan
option proto tcp
option src_dport 22
option dest_ip 192.168.1.20
option dest_port 22
option enabled 1
```
In our case it is easier as it is always going to be `wan` and `lan`. We have to just allow configuration of `proto` (`tcp`/`udp` or both), `src_dport` and `dest_ip`. I am not sure if we even have to support `dest_port` (user can do redirect of that type in luci or on target machine) but it should be easy to do and just frontend has to solve how to explain it to user so it is not confusing.
We should also think about including DMZ (probably almost the same way as we have guest network but with LAN access to DMZ) with this feature.
## MVP
As for some kind of basic version following features are required:
* [x] create fw rule in uci based on user input (`port`, destination_address, `destination_port`)
* [x] extend `port` and `destination_port` so it is able to accept ranges (see `src_port` specification in https://openwrt.org/docs/guide-user/firewall/firewall_configuration#options5)
* [x] accept only destination ips which are specified in `/etc/config/dhcp` (see (https://gitlab.nic.cz/turris/foris-controller/foris-controller/-/blob/master/foris_controller_modules/lan/schema/lan.json#L119 or https://gitlab.nic.cz/turris/foris-controller/foris-controller/-/blob/master/foris_controller/schemas/definitions/common.json#L20 )
* [ ] ~~`proto` option - by default if no `proto` is used both tcp and udp are used. If `proto` is set only `tcp/udp` redirects will be used.~~Filip HronFilip Hronhttps://gitlab.nic.cz/turris/foris-controller/foris-controller/-/issues/270Add Wi-Fi6 option2023-10-09T18:12:41+02:00Filip HronAdd Wi-Fi6 optionlinked: https://gitlab.nic.cz/turris/reforis/reforis/-/issues/418linked: https://gitlab.nic.cz/turris/reforis/reforis/-/issues/418Filip HronFilip Hronhttps://gitlab.nic.cz/turris/foris-controller/foris-controller/-/issues/268networks: wan interface should not be treated as bridge2023-10-03T12:41:12+02:00Martin Matějeknetworks: wan interface should not be treated as bridgeUpon saving configuration of an interfaces group (wan, lan, guest) without any interfaces, uci config option `bridge_empty 1` is added to that interfaces group. Meaning that even empty bridge should stay being type bridge, because we mig...Upon saving configuration of an interfaces group (wan, lan, guest) without any interfaces, uci config option `bridge_empty 1` is added to that interfaces group. Meaning that even empty bridge should stay being type bridge, because we might assign some interfaces to it later.
However, we still consider `wan` interface as special case of an interface with single physical device, therefore we should not set `bridge_empty 1` to interfaces that are not bridges.
This option is most likely ignored when applied to non-bridge device, but it is misleading, confusing and it might break network configuration on more recent Turris OS releases.
## How to reproduce
* TOS 6.0+
* MOX with more than one ethernet interface (AC/AE).
Wan assigned
```
config interface 'wan'
option proto 'dhcp'
option ipv6 '1'
option device 'eth0'
config device 'br_lan'
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
```
WAN unassigned (e.g. wifi AP)
```
config interface 'wan'
option proto 'dhcp'
option ipv6 '1'
option bridge_empty '1'
config device 'br_lan'
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
list ports 'eth0'
```
WAN reassigned again
```
config interface 'wan'
option proto 'dhcp'
option ipv6 '1'
option bridge_empty '1'
option device 'eth0'
config device 'br_lan'
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
```https://gitlab.nic.cz/turris/foris-controller/foris-controller/-/issues/248Drop ubus as message bus2023-09-21T16:37:26+02:00Martin MatějekDrop ubus as message busWe do not use ubus as message bus for foris-controller on production setup for quite a long time, neither we really test it on real hardware, so it might make sense to drop it completely.
Besides that, AFAIK reForis never supported ubus...We do not use ubus as message bus for foris-controller on production setup for quite a long time, neither we really test it on real hardware, so it might make sense to drop it completely.
Besides that, AFAIK reForis never supported ubus and uses mqtt exclusively, therefore using ubus as message bus on latest stable Turris OS (6.0) wouldn't be much useful anyway.
Tasks:
* [ ] drop CI job with ubus ([refactor/248-drop-ubus-as-message-bus](https://gitlab.nic.cz/turris/foris-controller/foris-controller/-/tree/refactor/248-drop-ubus-as-message-bus))
* [ ] remove ubus binary from CI docker image ([refactor/drop-ubus](https://gitlab.nic.cz/turris/foris-ci/-/commits/refactor/drop-ubus))
* [ ] drop ubus message bus backend
* [ ] remove ubus-related tests from CI jobs in modulesŠtěpán HenekŠtěpán Henekhttps://gitlab.nic.cz/turris/foris-controller/foris-controller/-/issues/227Wi-Fi panel fails with server error when there is no pair of matching "wifi-i...2023-09-20T19:54:32+02:00Jan TojnarWi-Fi panel fails with server error when there is no pair of matching "wifi-iface" and "wifi-device"I have confifured wi-fi networks in LuCI and now the wi-fi panel fails: An error occurred while fetching data.
The http://192.168.1.1/reforis/api/wifi response shows:
> <h1>500 - Server error</h1>
> <h3>Error:</h3>
> <p>Remote Exceptio...I have confifured wi-fi networks in LuCI and now the wi-fi panel fails: An error occurred while fetching data.
The http://192.168.1.1/reforis/api/wifi response shows:
> <h1>500 - Server error</h1>
> <h3>Error:</h3>
> <p>Remote Exception: Internal error list index out of range('<class 'IndexError'>')</p>
>
> <h3>Extra:</h3>
> <p>{"module": "wifi", "action": "get_settings", "kind": "request"}</p>
>
>
> <h3>Trace:</h3>
> <pre>Traceback (most recent call last):
> File "/usr/lib/python3.7/site-packages/foris_controller/message_router.py", line 117, in process_message
> File "/usr/lib/python3.7/site-packages/foris_controller/module_base.py", line 61, in perform_action
> File "/usr/lib/python3.7/site-packages/foris_controller_modules/wifi/__init__.py", line 36, in action_get_settings
> File "/usr/lib/python3.7/site-packages/foris_controller/utils.py", line 113, in inner
> File "/usr/lib/python3.7/site-packages/foris_controller_modules/wifi/handlers/openwrt.py", line 42, in get_settings
> File "/usr/lib/python3.7/site-packages/foris_controller_backends/wifi/__init__.py", line 219, in get_settings
> File "/usr/lib/python3.7/site-packages/foris_controller_backends/wifi/__init__.py", line 194, in _get_interface_sections_from_device_section
> IndexError: list index out of range
> </pre>
||Version|
|------|-----|
|Device|Turris|
|Serial number|21474842466|
|reForis version|1.1.2|
|Turris OS version|5.3.3|
|Turris OS branch|HBS|
|Kernel version|4.14.254|
`/etc/config/wireless`:
```
config wifi-device 'radio0'
option type 'mac80211'
option hwmode '11a'
option macaddr 'XX:XX:XX:XX:XX:XX'
option htmode 'VHT80'
option country 'CZ'
option channel '128'
config wifi-device 'radio1'
option type 'mac80211'
option macaddr 'XX:XX:XX:XX:XX:XX'
option htmode 'HT20'
option country 'CZ'
option disabled '0'
option channel 'auto'
option hwmode '11g'
config wifi-iface 'wifinet0'
option ssid '🥦'
option encryption 'psk2+ccmp'
option device 'radio0'
option mode 'ap'
option network 'lan'
option key 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
```Foris-controller 5.xhttps://gitlab.nic.cz/turris/foris-controller/foris-controller/-/issues/81Add slot name to WI-Fi settings.2023-09-16T13:21:42+02:00Bogdan BodnarAdd slot name to WI-Fi settings.The matching of Wi-Fi module on Wi-Fi page and interface on network interfaces page is not clear. We have to add some slot name to Wi-Fi devices.
So put [here](https://gitlab.labs.nic.cz/turris/foris-controller/foris-controller/blob/mas...The matching of Wi-Fi module on Wi-Fi page and interface on network interfaces page is not clear. We have to add some slot name to Wi-Fi devices.
So put [here](https://gitlab.labs.nic.cz/turris/foris-controller/foris-controller/blob/master/foris_controller_modules/wifi/schema/wifi.json#L110) something like [this](https://gitlab.nic.cz/turris/foris-controller/foris-controller/blob/master/foris_controller_modules/networks/schema/networks.json#L22). Thus I can use it in re**Foris**.https://gitlab.nic.cz/turris/foris-controller/foris-controller/-/issues/232wifi: support VHT and HE 80+80 modes2023-06-15T18:54:13+02:00Martin Matějekwifi: support VHT and HE 80+80 modesAdd support for modes that was previously left out.
Please note that even LuCI does not present option to set 80+80 modes, even though iwinfo is reporting correct HT modes.Add support for modes that was previously left out.
Please note that even LuCI does not present option to set 80+80 modes, even though iwinfo is reporting correct HT modes.https://gitlab.nic.cz/turris/foris-controller/foris-controller/-/issues/233wifi: better error reporting on update_settings2023-06-15T18:53:47+02:00Martin Matějekwifi: better error reporting on update_settingsWrite some meaningful error messages on wifi settings update, so we don't have to dive into the source code to debug what went wrong with update.
```python
if device["enabled"]:
...
if len(bands) != 1:
raise ValueError() # <-- ...Write some meaningful error messages on wifi settings update, so we don't have to dive into the source code to debug what went wrong with update.
```python
if device["enabled"]:
...
if len(bands) != 1:
raise ValueError() # <-- write better error description
band = bands[0]
# test channels (0 means auto)
if device["channel"] not in [0] + [
e["number"] for e in band["available_channels"]
]:
raise ValueError() # <-- write better error description
if device["htmode"] not in band["available_htmodes"]:
raise ValueError() # <-- write better error description
```Foris-controller 5.xhttps://gitlab.nic.cz/turris/foris-controller/foris-controller/-/issues/249wan: Do not update MAC address and/or QoS in case wan interface has no device...2023-06-15T18:52:35+02:00Martin Matějekwan: Do not update MAC address and/or QoS in case wan interface has no device assigned.These setting depends on configured wan, so it doesn't make much sense to try to set them in case WAN device is not set.These setting depends on configured wan, so it doesn't make much sense to try to set them in case WAN device is not set.Foris-controller 5.xhttps://gitlab.nic.cz/turris/foris-controller/foris-controller/-/issues/262tests: debug the timing issue within "test_connection_test_openwrt_*" tests2023-06-11T15:44:45+02:00Martin Matějektests: debug the timing issue within "test_connection_test_openwrt_*" testsThere are timing issues with the newly introduced tests in !119
However it works fine on gitlab CI, just not on few different machines (docker and/or lxc container).
Some of these tests (`test_connection_test_openwrt_*`) succeeds or fa...There are timing issues with the newly introduced tests in !119
However it works fine on gitlab CI, just not on few different machines (docker and/or lxc container).
Some of these tests (`test_connection_test_openwrt_*`) succeeds or fails, based on the order of the tests.
See https://gitlab.nic.cz/turris/foris-controller/foris-controller/-/merge_requests/119#note_272597
It seems like it is a timing issue involving mqtt, foris-controller and foris-client. Processing on the backend seems to work fine, but some replies from backend arrives too late and are discarded as invalid by foris-client.
For example every second test fails, regardless of the tested values:
```
tests/blackbox/test_wan.py::test_connection_test_openwrt_failed[openwrt-mqtt-failed] PASSED
tests/blackbox/test_wan.py::test_connection_test_openwrt_ok[openwrt-mqtt-success] FAILED
tests/blackbox/test_wan.py::test_connection_test_openwrt_unknown[openwrt-mqtt-unknown] PASSED
tests/blackbox/test_wan.py::test_connection_test_openwrt_unknown_2[openwrt-mqtt-unknown] FAILED
```https://gitlab.nic.cz/turris/foris-controller/foris-controller/-/issues/187Guest Network report DHCPv6 leases2023-05-11T14:44:46+02:00Aleksandr GumroianGuest Network report DHCPv6 leasesFollow-up of https://gitlab.nic.cz/turris/foris-controller/foris-controller/-/issues/115
Display DHCP ipv6 leases along with ipv4 DCHP leases on the Guest Network tab.Follow-up of https://gitlab.nic.cz/turris/foris-controller/foris-controller/-/issues/115
Display DHCP ipv6 leases along with ipv4 DCHP leases on the Guest Network tab.https://gitlab.nic.cz/turris/foris-controller/foris-controller/-/issues/265guest: Use separate routing table for guest network routes2023-05-04T13:44:53+02:00Martin Matějekguest: Use separate routing table for guest network routes## Description
I case that router acts as VPN client, the guest network does not have access to the Internet. The Internet connectivity is re-enabled when the VPN client disconnects.
See: turris/os/packages#805
## Proposed solution
...## Description
I case that router acts as VPN client, the guest network does not have access to the Internet. The Internet connectivity is re-enabled when the VPN client disconnects.
See: turris/os/packages#805
## Proposed solution
From comment https://gitlab.nic.cz/turris/os/packages/-/merge_requests/876#note_242659
> The VPN client and Guest network share the same (main) routing table. That means, when the VPN clients rewrites the default route to go through the VPN, the Guest network will lose the access to the Internet (as the default is going via VPN).
> I suggest to move the VPN client to the separate routing table - that means the VPN client installs the default route to go through the VPN, but as it is a different routing table, it won't affect the main routing table; thus the Guest network will keep the access to the Internet but no access to the VPN)
Apart from using separate routing table, perhaps additional changes to firewall would be necessary.https://gitlab.nic.cz/turris/foris-controller/foris-controller/-/issues/240guest: Allow handling of guest bridge IP address in CIDR format2023-03-30T18:07:48+02:00Martin Matějekguest: Allow handling of guest bridge IP address in CIDR formatCurrently we handle IP address of bridge as
```
option ipaddr ...
option netmask ...
```
Allow handling both `IP + netmask` and `CIDR` formated IP address.Currently we handle IP address of bridge as
```
option ipaddr ...
option netmask ...
```
Allow handling both `IP + netmask` and `CIDR` formated IP address.https://gitlab.nic.cz/turris/foris-controller/foris-controller/-/issues/85check_connection: add support for test result UNKNOWN2023-02-27T19:18:41+01:00Karel Kocicheck_connection: add support for test result UNKNOWNIn some cases it is possible that we just can't run some test. We were reporting it as failed until now but more appropriate state is that we can't decide, that test is inconclusive.
https://gitlab.labs.nic.cz/turris/turris-os-packages/...In some cases it is possible that we just can't run some test. We were reporting it as failed until now but more appropriate state is that we can't decide, that test is inconclusive.
https://gitlab.labs.nic.cz/turris/turris-os-packages/merge_requests/131 adds this feature to `check_connection`.Filip HronFilip Hronhttps://gitlab.nic.cz/turris/foris-controller/foris-controller/-/issues/261wan: switching IPv4 protocol settings should not leave incompatible options i...2023-02-17T21:04:43+01:00Martin Matějekwan: switching IPv4 protocol settings should not leave incompatible options in uci configFor example:
"dhcp" for IPv4 creates following config:
```
config interface 'wan'
option device 'eth2'
option proto 'dhcp'
```
Upon switching to "Static IP address" it is still fine:
```
config interface 'wan'
option device 'eth2'
...For example:
"dhcp" for IPv4 creates following config:
```
config interface 'wan'
option device 'eth2'
option proto 'dhcp'
```
Upon switching to "Static IP address" it is still fine:
```
config interface 'wan'
option device 'eth2'
option proto 'static'
option ipaddr '10.0.1.185'
option netmask '255.255.255.0'
option gateway '10.0.1.1'
```
However changing it back to "dhcp" leaves the "static ip" options intact.
```
config interface 'wan''
option device 'eth2'
option ipaddr '10.0.1.185' <-- this should not stay here
option netmask '255.255.255.0' <-- this should not stay here
option gateway '10.0.1.1' <-- this should not stay here
option proto 'dhcp'
```
Related to: #226https://gitlab.nic.cz/turris/foris-controller/foris-controller/-/issues/226Setting up DHCP on WAN keeps previous DNS servers2023-02-17T21:04:43+01:00Stepan RechnerSetting up DHCP on WAN keeps previous DNS servers# Summary
If a static address is set up on WAN and then it is switched to DHCP, the DNS servers from the previous static set-up are kept and the DNS gotten from DHCP is added. The set-up is not replaced but combined in the end - both (al...# Summary
If a static address is set up on WAN and then it is switched to DHCP, the DNS servers from the previous static set-up are kept and the DNS gotten from DHCP is added. The set-up is not replaced but combined in the end - both (all) present in `/tmp/resolv.conf.auto` and LuCI overwiew. It remains like that after restart too.
# Steps To Reproduce
1. setting up a static address on WAN and filling in some external DNS servers
2. setting up a DHCP on WAN
# Expected Result
The DNS server(s) gotten from the DHCP option is used, the previous set-up is replaced.
# Actual Result
Both (all) DNS servers are used (listed in `/tmp/resolv.conf.auto` and LuCI overwiew.
# Possible workaround
1. setting up a statica ddress on WAN again, but without filling in DNS servers
2. setting up a DHCP on WAN againhttps://gitlab.nic.cz/turris/foris-controller/foris-controller/-/issues/109wan: abstraction of get_wan_status2023-01-25T14:25:33+01:00Martin Matějekwan: abstraction of get_wan_statusCreate a simple abstraction for wan interface status, covering `wan` and `wan6` interface. Return summary of IPv4 and IPv6 status in one foris-controller api call.
Also it could prevent crash when `wan` interface is missing (#86).
Bloc...Create a simple abstraction for wan interface status, covering `wan` and `wan6` interface. Return summary of IPv4 and IPv6 status in one foris-controller api call.
Also it could prevent crash when `wan` interface is missing (#86).
Blocks: #108