Turris issueshttps://gitlab.nic.cz/groups/turris/-/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/os/build/-/issues/429Firewall status in LuCI is empty2024-03-04T10:12:20+01:00Michal HruseckyFirewall status in LuCI is emptyAs reported on our forum, firewall statu in LuCI might be empty. This might be some mixup between iptables and nftables firewall, we need to check, but we need to reproduce first.
https://forum.turris.cz/t/turris-os-7-0-is-in-rc/19755/27As reported on our forum, firewall statu in LuCI might be empty. This might be some mixup between iptables and nftables firewall, we need to check, but we need to reproduce first.
https://forum.turris.cz/t/turris-os-7-0-is-in-rc/19755/27Turris OS 7.0Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/build/-/issues/431SDIO WiFi crashing kernel on Turris OS 7.02024-03-04T10:12:33+01:00Michal HruseckySDIO WiFi crashing kernel on Turris OS 7.0We have a report of SDIO WiFi crashing the kernel on Turris OS 7.0, we need to investigate. Firstly, try to repoproduce it, but updating driver to a newer version might be a good idea as well and might be enough.
https://forum.turris.cz...We have a report of SDIO WiFi crashing the kernel on Turris OS 7.0, we need to investigate. Firstly, try to repoproduce it, but updating driver to a newer version might be a good idea as well and might be enough.
https://forum.turris.cz/t/turris-os-7-0-is-in-rc/19755/12Turris OS 7.0https://gitlab.nic.cz/turris/os/packages/-/issues/944Knot Resolvers in Turris OS 7.02024-03-04T10:08:34+01:00Michal HruseckyKnot Resolvers in Turris OS 7.0Users reported problems with knot-resolver in Turris OS 7.0 RC, we should investigate.
https://forum.turris.cz/t/turris-os-7-0-is-in-rc/19755/7Users reported problems with knot-resolver in Turris OS 7.0 RC, we should investigate.
https://forum.turris.cz/t/turris-os-7-0-is-in-rc/19755/7Turris OS 7.0Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/reforis/reforis-gsm-plugin/-/issues/1Add reForis plugin to manage LTE2024-03-21T13:10:22+01:00Filip HronAdd reForis plugin to manage LTEThis reForis module will be part of the `LTE support package`.
Whenever a package is installed, necessary `foris_controller_lte_module` will also be present.
# Idea
Refer to the `lte.json` schema in [lte.json](https://gitlab.nic.cz/tur...This reForis module will be part of the `LTE support package`.
Whenever a package is installed, necessary `foris_controller_lte_module` will also be present.
# Idea
Refer to the `lte.json` schema in [lte.json](https://gitlab.nic.cz/turris/foris-controller/foris-controller-lte-module/-/blob/master/foris_controller_modules/lte/schema/lte.json)
## `get_settings` action
Along with settings (which if not to be set are not visible to the user), there is also `info` sent from the backend.
The info should be visible on the page.
### The `info` property of modem settings
| property | type | description |
| -- | -- | -- |
| `state` | enum | locked/connected |
| `manufacturer` | str | self explanatory |
| `model` | str | - |
| `operator` | | - |
| `registration` | enum | home/roaming |
| `sim_lock` | bool | whether modem needs `PIN` to unlock `SIM` to operate |
### The `auth` property of the modem setting
Only when `type` is not `"none"` username and password are required. Users can modify it.
| property | type | desc |
| -- | -- | -- |
| `type` | enum | pap/chap/both/_none_ |
| `username` | str | onyl required if when not type not _none_ |
| `password` | str | same as above |
### The root part of the response
| property | type | desc |
| -- | -- | -- |
| `id` | str | modem _id_ at backend |
| `qmi_device` | str | another modem identification |
| `apn` | str | __Access Point Name__ |
| `pin` | str(4) | when `"unset"`, PIN is not present on `uci` backend |
Only `apn` can be changed in this section.
## ``update_settings`` action
### Extra properties
| property | type | desc |
| -- | -- | -- |
| `new_pin` | str | `PIN` to be changed |
### User can set
- `apn`
- `auth`
### Restrictions
Do not let the user change `pin` unless `sim_lock` is `true`. It is not possible to use the current (mmcli) API.
# Wireframe
<details><summary>Click to expand</summary>
![GSM_Settings__Final___1_](/uploads/e1564bccab0097a111d6d8c424be5017/GSM_Settings__Final___1_.png)
</details>Aleksandr GumroianAleksandr Gumroianhttps://gitlab.nic.cz/turris/user-docs/-/issues/171Update VLAN documentation for OpenWrt 21.022022-02-21T16:59:40+01:00Karel KociUpdate VLAN documentation for OpenWrt 21.02In reference of changes handled in turris/os/build#273 we should update VLAN configuration.In reference of changes handled in turris/os/build#273 we should update VLAN configuration.https://gitlab.nic.cz/turris/pakon/-/issues/27Pakon unindependent on Suricata2022-05-13T11:50:58+02:00Filip HronPakon unindependent on SuricataStep to improve Pakon loadStep to improve Pakon loadPakon 1.4.0Filip HronFilip Hronhttps://gitlab.nic.cz/turris/nsfarm/-/issues/35Basic firewall testing2022-03-15T14:38:49+01:00Karel KociBasic firewall testingWe should test firewall.
* [ ] Zone separation and forwarding
* [ ] Port forwarding
* [ ] Block and accept network rule
* [ ] MasquaradeWe should test firewall.
* [ ] Zone separation and forwarding
* [ ] Port forwarding
* [ ] Block and accept network rule
* [ ] Masquaradehttps://gitlab.nic.cz/turris/os/build/-/issues/292Add support for VHT80+802023-01-03T14:53:24+01:00Josef SchlehoferAdd support for VHT80+80After a long lead time, we received card, which supports VHT80+80, but it is unfortunately presented as VHT160, which is something different. This includes (re)Foris and LuCI, which has missing support for `iwinfo HTMODE VHT80+80`.
Open...After a long lead time, we received card, which supports VHT80+80, but it is unfortunately presented as VHT160, which is something different. This includes (re)Foris and LuCI, which has missing support for `iwinfo HTMODE VHT80+80`.
OpenWrt:
- [ ] Add support for two [LuCI files]
- [ ] [modefreq.htm](https://github.com/openwrt/luci/blob/7f5becc69e004f831c9dc09e0859c179b439c7d2/modules/luci-compat/luasrc/view/cbi/wireless_modefreq.htm#L47)
- [ ] [wireless.js](https://github.com/openwrt/luci/blob/master/modules/luci-mod-network/htdocs/luci-static/resources/view/network/wireless.js)
- [ ] Add it to [OpenWrt documentation](https://openwrt.org/docs/guide-user/network/wifi/basic#htmodewi-fi_channel_width)
Turris:
- [ ] Add support for reForis
We can add it to reForis once LuCI changes are merged.
____
Reference iwinfo:
https://git.openwrt.org/?p=project/iwinfo.git;a=blob;f=iwinfo_lib.c;h=70b080cedfc07be6b001f7084ad63ffe69d92f3f;hb=HEAD#l66
___
cc: @proharhttps://gitlab.nic.cz/turris/logc/-/issues/8Stream to lines helper object2021-09-09T15:01:11+02:00Karel KociStream to lines helper objectIt turns out that it is a common task to accumulate read text until we reach the end of the line and then log that (or potentially handle it in another way). This is the case when we read text from a file, pipe from subprocess or even wh...It turns out that it is a common task to accumulate read text until we reach the end of the line and then log that (or potentially handle it in another way). This is the case when we read text from a file, pipe from subprocess or even when we integrate with some other logging method.
It might make sense to implement it as `fopencookie` handle as in general what we want is `write` function that accumulates text until we get the end of the line. It is a question if-then callback should happen or if a user should call a function that checks for a new line (I think that the first is preferable as that decreases the amount of stored data).
It might also be interesting to have mode when we keep last X number of bytes in buffer. This might be beneficial for applications that run subprocesses and want to receive end of their output on failure (where commonly error resides).https://gitlab.nic.cz/turris/user-docs/-/issues/141How to remove or uninstalled packages2024-03-27T16:40:54+01:00Josef SchlehoferHow to remove or uninstalled packagesOn our support, we received a response, then he installed some packages from our documentation, but he does not know how he should uninstall it.
I think it is not clear that unchecking and saving it in Package management tab will remove...On our support, we received a response, then he installed some packages from our documentation, but he does not know how he should uninstall it.
I think it is not clear that unchecking and saving it in Package management tab will remove it. :thinking:
What do you think @ljelinek ?Lukas JelinekLukas Jelinekhttps://gitlab.nic.cz/turris/os/build/-/issues/264Throughput issue of WAN->LAN TCP routing (with NAT) on Turris MOX2021-06-03T21:13:14+02:00Martin DeckyThroughput issue of WAN->LAN TCP routing (with NAT) on Turris MOXI am experiencing a strange throughput (performance) issue on my Turris MOX when downloading via TCP (e.g. HTTP, HTTPS) from the Internet. The issue affects many but not all hosts. Here is the network setup where I can deterministically ...I am experiencing a strange throughput (performance) issue on my Turris MOX when downloading via TCP (e.g. HTTP, HTTPS) from the Internet. The issue affects many but not all hosts. Here is the network setup where I can deterministically reproduce the issue:
`[Host A] <---> (Internet) <---> WAN [Turris MOX] LAN <---> [Host B]`
All traffic is IPv4, the MTU is 1500 bytes everywhere, I don't observe any IP packet fragmentation. The connectivity of Host A is 200 Mbps symmetric (WEDOS). The WAN connectivity of the Turris MOX is 300 Mbps symmetric (viaGIA). The Gbit LAN port of the Turris MOX is connected directly to Host B via a short patch cable.
In isolation, the throughput of all the links has been verified both locally and by connecting to a 3rd Host C on the Internet (1 Gbps connectivity, Casablanca) and it is trivial to achieve the nominal speed of download/upload. The issue is not observed when Host C replaces Host A in the setup (but again, the problem is not unique to Host A).
Host A runs the following command:
`nc -4 -k -l -p 4000 < /dev/zero`
Host B runs the following command:
`nc -4 89.221.222.131 4000 > /dev/null`
In other words, Host B connects via TCP (and through NAT routing on Turris MOX) to Host A and Host A sends a stream of zero bytes to Host B via this TCP connection. **The observed download speed fluctuates between 4 Mbps to 8 Mbps instead of being close to the ideal 200 Mbps.**
Further observations:
- Running the receiving command (i.e. `nc 89.221.222.131 4000 > /dev/null`) directly on the Turris MOX yields successfully the ideal download speed of 200 Mbps.
- Running a "relay" on the Turris MOX (i.e. `nc 89.221.222.131 4000 | nc -l -p 4000`) and connecting to this relay directly on Host B (i.e. `nc -4 192.168.168.1 4000 > /dev/null`) also yields a solid download speed of 120 Mbps. This demonstrates that the individual links of the Turris MOX are not saturated.
- Even more strangely and surprisingly, when running the original benchmark between Host A and Host B, it is possible to improve the speed of the A -> B transfer close to 200 Mbps **just by running another TCP transfer between the Turris MOX and Host B at the same time** (i.e. `nc -l -p 4000 < /dev/zero` on the Turris MOX and `nc -4 192.168.168.1 4000 > /dev/null` on Host B)! This "disturbing" TCP connection not only improves the performance of the original TCP connection, but the download speeds appear to be strangely correlated, again close to 200 Mbps. This suggests that the issue might have something to do with interrupt processing on the Turris MOX or something.
Turris MOX: MOX Start (1024 MB, WAN port) + MOX C (LAN ports)
Turris OS: 5.1.10 with kernel 4.14.222 (the same behavior is observed on 5.2.0 with kernel 4.14.229), no non-standard configuration
If you need more information of any kind, I would be happy to provide them.Marek BehunMarek Behunhttps://gitlab.nic.cz/turris/pakon/-/issues/17Project: pakon-standalone2022-10-17T21:29:35+02:00Filip HronProject: pakon-standalone## Vision
There is a requirement to make Pakon stand-alone package. There are three parts that will make this happen without need running it on any Turris device. In short, without having Foris type UI. In order to archieve the goal we ...## Vision
There is a requirement to make Pakon stand-alone package. There are three parts that will make this happen without need running it on any Turris device. In short, without having Foris type UI. In order to archieve the goal we need to prepare each part in small steps.
1. contemporary __pakon-light__ repository and project:
- Refactor code to meet our company project standards. (python proj. structure, ``pytest``, _installer_)
- (more importantly) Introduce way to filter data from database in __CLI__ command.
2. __pakon-api__
- Prepare __JSON__ schema for frontend.
- Create __API__ wrapper.
3. React based __web-ui__
- Analyze and get back with more detail. ``< TODO``
important note:
- Projects __2.__ and __3.__ may share the same _wsgi_ wrapper as both are based.
## Project structure, requirements
- [x] https://gitlab.nic.cz/turris/pakon/-/issues/26
- [ ] https://gitlab.nic.cz/turris/pakon/-/issues/27
- [ ] Create front-end standalone UIFilip HronFilip Hronhttps://gitlab.nic.cz/turris/os/build/-/issues/295Repetitive failing attempts to update a router2023-01-13T20:54:14+01:00Ghost UserRepetitive failing attempts to update a routerSeveral users report about repetitive notifications from updater about failed update attempts. Although updater runs 6 times a day and the update/check for update is successful in the end, it's definitely an annoying matter that spams ou...Several users report about repetitive notifications from updater about failed update attempts. Although updater runs 6 times a day and the update/check for update is successful in the end, it's definitely an annoying matter that spams our users and generates unneeded traffic on our mailservers as well.
Also, the issue starts to be so frequent, that's at least suspicious for what's going on and what is causing this not so uncommon issue.
Last clues leads to failing `repo.turris.cz` domain name resolution and to Knot Resolver.
Some reports
- public forum:
- [Update Error On Turris 5.1.8](https://forum.turris.cz/t/update-error-on-turris-5-1-8/14839/4)
- [updater-failed](https://forum.turris.cz/t/updater-failed-runtime-string-requests-string-utils-unable-to-finish-uri-https-repo-turris-cz-hbs-omnia-lists-pkglists-datacollect-lua-download-failed/15482)
- [Problem s aktualizaci? - Updater failed](https://forum.turris.cz/t/problem-s-aktualizaci-updater-failed/15553/8)
- internal support tickets
- [RT#1256943](https://rt.nic.cz/Ticket/Display.html?id=1256943)
- [RT#1261131](https://rt.nic.cz/Ticket/Display.html?id=1261131)
- [RT#1356544](https://rt.nic.cz/Ticket/Display.html?id=1356544)
- Several reports in comments below :point_down: :point_down:
---
**Original issue description**
I have been getting the following error for the past two days when my Turris Omnia tries to update packages:
```
##### Error notifications #####
Updater failed:
runtime: [string "requests"]:417: [string "utils"]:420: Getting URI (https://repo.turris.cz/hbs/omnia/lists/pkglists/luci_controls.lua) failed: Connection timed out after 60029 milliseconds
```https://gitlab.nic.cz/turris/healthcheck/-/issues/9Monitor smartctl prefail parameters2022-06-06T14:17:53+02:00Karel KociMonitor smartctl prefail parametersWe should monitor prefail parameters in smartctl and warn if they start incresing or if they cross some level.
Example of this is to check number of drive starts. If that number starts increasing rapidly it can mean problems woth power ...We should monitor prefail parameters in smartctl and warn if they start incresing or if they cross some level.
Example of this is to check number of drive starts. If that number starts increasing rapidly it can mean problems woth power supply. Result can be broken mechanics on rotation drives.https://gitlab.nic.cz/turris/foris-controller/foris-controller-wwan-module/-/issues/1Support for qmi2023-05-24T17:41:09+02:00Karel KociSupport for qmiWe should add support for broadband interface using QMI. In general I think it might be suitable to create new foris-controller plugin for it (same as new reForis plugin).
How it in general works is that there is device (such as serial ...We should add support for broadband interface using QMI. In general I think it might be suitable to create new foris-controller plugin for it (same as new reForis plugin).
How it in general works is that there is device (such as serial one) and configuration in `/etc/config/network` such as follows:
```
network.wan=interface
network.wan.proto='qmi'
network.wan.apn='internet'
network.wan.device='/dev/cdc-wdm0'
network.wan.auth='none'
network.wan.pdptype='ipv4'
```
should be approximately enough to configure it.
Initial problem to solve is how to detect `device`. This can be in general any device but we can support only driver cdc_wdm/qmi_wwan with its naming scheme `/dev/cdc-wdm*`. This also means that (although unlikely) we should support multiple devices at once as there can be multiple such devices connected/available.
In the end what should be user able to enter is:
* `apn`
* `pdptype` with possibilities `ipv4`/`ipv6`/`ipv4v6` (probably as selection of two booleans)
* `pincode` (this should be optional as sim card might not have pin code configured)
We should provide possibility to prefill valid `apn` and `pdptype` from common databases. This should be package/python library with database generated from other sources. This should be solved the same way as it is now done https://gitlab.nic.cz/turris/turris-os-packages/-/tree/master/utils/ouidb. Selection should be according to MCC + MNC (Mobile Country Code + Mobile Network Code) of sim card.
Note that this also creates new interface. It makes sense to add support so we can also add it to LAN or WAN or GUEST (although it makes sense mostly to have it in wan only). That means support for these interfaces in interfaces tab (in reForis).
It might be interesting to also think about integrating mwan3 as part of this (this can be again separate task in the end as it might make sense to have it not just with broadband connection).
(In reference to https://gitlab.nic.cz/turris/project/-/issues/108)https://gitlab.nic.cz/turris/os/packages/-/issues/587Turris 1.x: Update U-boot2022-06-22T16:46:34+02:00Karel KociTurris 1.x: Update U-bootUpdate uboot to new version on Turris 1.x. Doing so should enable for example boot from USB.Update uboot to new version on Turris 1.x. Doing so should enable for example boot from USB.Turris OS 6.1.0https://gitlab.nic.cz/turris/foris/foris-subordinates-plugin/-/issues/6Device in exclamation mark state2020-11-09T10:24:04+01:00Martin MatějekDevice in exclamation mark stateSuccesfully paired mox (paired to omnia) state is "exclamation mark".
![2020-03-29_22.57.18_10.0.5.1_eba4cbea85ae](/uploads/b0b091dfb49f526166c221e33e320b2e/2020-03-29_22.57.18_10.0.5.1_eba4cbea85ae.png)
Also wifi setup is inaccessible...Succesfully paired mox (paired to omnia) state is "exclamation mark".
![2020-03-29_22.57.18_10.0.5.1_eba4cbea85ae](/uploads/b0b091dfb49f526166c221e33e320b2e/2020-03-29_22.57.18_10.0.5.1_eba4cbea85ae.png)
Also wifi setup is inaccessible with the same state.
![2020-03-29_22.57.48_10.0.5.1_ebd7ec6f870e](/uploads/4e626fa926a361e4da92f73281d22a44/2020-03-29_22.57.48_10.0.5.1_ebd7ec6f870e.png)
Nevertheless, wifi on mox is configured same as on omnia, so it is more matter of wrong detection of Mox state.
## Probable cause
Lost connection to paired device
## Affected software and versions
TOS 4.0.5 (HBS) through 5.1 (HBL) on Omnia, TOS 4.0.5 on MoxMichal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/nsfarm/-/issues/24Farm rack preparation2021-09-08T10:13:37+02:00Karel KociFarm rack preparationWe now have nice shining (ok not shining) rack to put nsfarm in to. These are steps to get it available to all of us.
![IMG_20191114_153245](/uploads/7bd7316d60068006ef008b81568d7331/IMG_20191114_153245.jpg)
* [x] mount two remaining s...We now have nice shining (ok not shining) rack to put nsfarm in to. These are steps to get it available to all of us.
![IMG_20191114_153245](/uploads/7bd7316d60068006ef008b81568d7331/IMG_20191114_153245.jpg)
* [x] mount two remaining shelf to rack
* [x] get velcro strip to attach the Turris Omnia boxes
* [x] buy 1 m long patch cables (20 pieces) in blue and grey colors (OFC preffered)
* [x] attach the power supplies to the bottom of the shelves
* [ ] move PC to bottom of rack
* [x] install Debian unstable to PC
* ansible PC
* [x] Install and configure LXD for NSFarm
* [x] Create users (at least kkoci and jbetik)
* [x] grand those users access to LXD and to serial devices (groups lxd and dialout)
* [ ] make server accessible trough turris domain (possibly `nsfarm.turris.cz`?)
* [ ] generate central configuration for nsfarm (`/etc/nsfarm.yml`) (blocked by https://gitlab.labs.nic.cz/turris/nsfarm/issues/7)
* [ ] connect and configure both omnias we have so farLukas JelinekLukas Jelinek2020-10-23https://gitlab.nic.cz/turris/nsfarm/-/issues/6Setup utilities for all fixtures to use2022-02-15T18:14:07+01:00Karel KociSetup utilities for all fixtures to useMost of the work done in fixtures is some sort of configuration done. Every fixture have to later revert its changes (otherwise it taints environment). To make it clean as much as possible we should simplify common configuration tasks. T...Most of the work done in fixtures is some sort of configuration done. Every fixture have to later revert its changes (otherwise it taints environment). To make it clean as much as possible we should simplify common configuration tasks. The idea is to have objects with ability to track changes and reverting them on context leave. Imagine for example following code:
```python
with nsfarm.setup.Setup() as setup:
setup.preserve("/etc/passwd")
board_serial.run('echo root:"{}" | chpasswd'.format(password))
yield
```
This is going to set root password but preserves content of `/etc/passwd` so when fixture is teared down it restores original content (note that this is not a good idea but rather just an example).
We should have basic general setups handling following areas
* [x] Preserve files content (for arbitrary file)
* [x] Preserve path existence/non-existence (for directories)
* [ ] UCI
More specific setups:
* [x] root password setup
* [ ] local time setup
* [x] various uplink setups
* [x] static IP
* [x] DHCP
* [x] PPPOE
* [x] updater setup (target branch/version/build)