Turris OS packages issueshttps://gitlab.nic.cz/turris/os/packages/-/issues2022-02-16T17:00:46+01:00https://gitlab.nic.cz/turris/os/packages/-/issues/309ddns-scripts: ERROR : IP update not accepted by DDNS Provider2022-02-16T17:00:46+01:00Darshaka Pathiranaddns-scripts: ERROR : IP update not accepted by DDNS ProviderUpdating the IP reports an error, but the update itself is successful:
```
123228 : Waiting 600 seconds (Check Interval)
124228 : Detect registered/public IP
124228 : #> /bin/nslookup myexample.ddnss.org >/var/run/...Updating the IP reports an error, but the update itself is successful:
```
123228 : Waiting 600 seconds (Check Interval)
124228 : Detect registered/public IP
124228 : #> /bin/nslookup myexample.ddnss.org >/var/run/ddns/myddns_ipv4.dat 2>/var/run/ddns/myddns_ipv4.err
124228 : Registered IP '213.xx.xx.84' detected
124228 info : Rerun IP check at 2019-01-22 12:42
124228 : Detect local IP on 'network'
124228 : Local IP '213.xx.xx.84' detected on network 'wan'
124228 : Forced Update - L: '213.xx.xx.84' == R: '213.xx.xx.84'
124228 : #> /usr/bin/curl -RsS -o /var/run/ddns/myddns_ipv4.dat --stderr /var/run/ddns/myddns_ipv4.err --noproxy '*' 'http://ip4.ddnss.de/upd.php?user=myusername&pwd=***PW***&host=myexample.ddnss.org&ip=213.xx.xx.84'
124229 : DDNS Provider answered:
<head>
<meta name="robots" content="noindex">
<title>DDNSS - Kostenloser DynDNS Service : Re-ProutDNS v5.01v</title>
</head>
<body>
<p><font face="Verdana" size="2"></font></p>
<p><font face="Verdana" size="2">Updated 1 hostname.</font></p>
</body>
124229 ERROR : IP update not accepted by DDNS Provider
124229 : Waiting 600 seconds (Check Interval)
```
I've created an upstream issue: https://github.com/openwrt/packages/issues/8013
I am not sure, if this can be fixed on our side until it is fixed on upstream.https://gitlab.nic.cz/turris/os/packages/-/issues/308provide dependant for open-plc-utils-mdiogen2019-07-08T11:07:17+02:00Ghost Userprovide dependant for open-plc-utils-mdiogenWith `open-plc-utils-mdiogen` available in the TOS 3.11.2 repo its dependant is missing however
> ERROR:
> inconsistent: Package open-plc-utils-mdiogen *requires package open-plc-utils that is not available*.With `open-plc-utils-mdiogen` available in the TOS 3.11.2 repo its dependant is missing however
> ERROR:
> inconsistent: Package open-plc-utils-mdiogen *requires package open-plc-utils that is not available*.https://gitlab.nic.cz/turris/os/packages/-/issues/307logread wrapper for LuCI packages2019-07-22T19:59:57+02:00Josef Schlehoferlogread wrapper for LuCI packagesI'm in touch with @dibdot and he said that Turris OS 4.x still doesn't have a wrapper for logread, which means e.g. **System Log** tab in LuCI is empty. He sent me a small [wrapper](/uploads/d13fb9996193f517aca3cda69dd8f325/logread), whi...I'm in touch with @dibdot and he said that Turris OS 4.x still doesn't have a wrapper for logread, which means e.g. **System Log** tab in LuCI is empty. He sent me a small [wrapper](/uploads/d13fb9996193f517aca3cda69dd8f325/logread), which we can re-use and copy it to /sbin. :-)
For now, I'm thinking about these solutions:
* add a dependency for syslog-ng to logread
* add logread to files in sys-log and copy it to /sbin
* and maybe more coming later?
I think this could also solve issues like this:
https://forum.turris.cz/t/logread-broken/1181/ (reproducible on Turris Omnia, TOS 3.11.2)
https://forum.turris.cz/t/combination-of-syslog-ng-luci-system-logging-configuration-mwan3/5975Turris OS 3.11.3https://gitlab.nic.cz/turris/os/packages/-/issues/305nextcloud (15.0.2) occ command broken due to missing php on PATH2022-02-16T17:01:02+01:00cmacq2nextcloud (15.0.2) occ command broken due to missing php on PATHThe `occ` script to manage the nextcloud from the command line has the following shebang: `#!/usr/bin/env php`
Checking over SSH, `$PATH` is set to: `/usr/bin:/usr/sbin:/bin:/sbin` and `which php` cannot find a `php` executable.
A fix c...The `occ` script to manage the nextcloud from the command line has the following shebang: `#!/usr/bin/env php`
Checking over SSH, `$PATH` is set to: `/usr/bin:/usr/sbin:/bin:/sbin` and `which php` cannot find a `php` executable.
A fix could be to add symlink: `ln -s /usr/bin/php-cli /usr/bin/php`.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/304nextcloud (15.0.2) lighttpd configuration broken2021-11-08T09:26:29+01:00cmacq2nextcloud (15.0.2) lighttpd configuration brokenUpgraded nextcloud from 14.06 to 15.02. The security check now complains about a missing `Referrer-Policy` header when, in fact, two `Referrer-Policy` headers are sent by the server.
It looks like as of 15.02 the previous fix for `/etc/...Upgraded nextcloud from 14.06 to 15.02. The security check now complains about a missing `Referrer-Policy` header when, in fact, two `Referrer-Policy` headers are sent by the server.
It looks like as of 15.02 the previous fix for `/etc/lighttpd/conf.d/nextcloud` to add this header is no longer applicable:
```
alias.url += ( "/nextcloud" => "/srv/www/nextcloud" )
$HTTP["url"] =~ "^/nextcloud" {
# Add 'X-Frame-Options' header, making sure it the website is not embedded in a frame or iframe.
# This avoids clickjacking, and might be helpfull for HTTPS websites
# As frames are not used nowadays, this should be safe to enable at least SAMEORIGIN
# Other option might be DENY or ALLOW-FROM. DENY is not used as frame is used in some old LuCI modules
#setenv.add-response-header += ( "X-Frame-Options" => "SAMEORIGIN")
setenv.add-response-header += ( "Referrer-Policy" => "no-referrer")
}
$HTTP["url"] =~ "^/nextcloud/(build|tests|config|lib|3rdparty|templates|data)" {
url.access-deny = ("")
}
```
Should now probably be:
```
alias.url += ( "/nextcloud" => "/srv/www/nextcloud" )
$HTTP["url"] =~ "^/nextcloud/(build|tests|config|lib|3rdparty|templates|data)" {
url.access-deny = ("")
}
```https://gitlab.nic.cz/turris/os/packages/-/issues/301[version bump] bird {1.6.5|2.0.3}2019-05-15T18:45:58+02:00Ghost User[version bump] bird {1.6.5|2.0.3}Is there a reason for sticking to the 1.x branch and not making the transition to 2.x?
https://bird.network.cz/
7.1.2019 - New releases 2.0.3 and 1.6.5! Check NEWS files
> Version 1.6.5 (2019-01-05)
> o MRT table dumps (RFC 6396)...Is there a reason for sticking to the 1.x branch and not making the transition to 2.x?
https://bird.network.cz/
7.1.2019 - New releases 2.0.3 and 1.6.5! Check NEWS files
> Version 1.6.5 (2019-01-05)
> o MRT table dumps (RFC 6396)
> o BGP Long-lived graceful restart
> o Filter: Make ifname attribute modifiable
> o Improved keeping track of IPv6 link-local addresses
> o Many bugfixes
>
> Version 1.6.4 (2018-03-22)
> o Basic VRF support
> o Simplified autoconf scripts
> o BGP: Shutdown communication (RFC 8203)
> o BGP: Allow exchanging LOCAL_PREF with eBGP peers
> o BGP: Allow to specify interface for regular sessions
> o BGP: New option 'disable after cease'
> o RAdv: Support for more specific routes (RFC 4191)
> o RAdv: Proper handling of prefix retraction
> o Filter: Allow silent filter execution
> o Filter: Fixed stack overflow in BGP mask expressions
> o Several bug fixes
___
> Version 2.0.3 (2019-01-05)
> o MRT table dumps (RFC 6396)
> o BGP Long-lived graceful restart
> o BGP: Optional import table (Adj-RIB-In)
> o BGP: Extend 'next hop keep' and 'next hop self' options
> o BGP: Improved VRF support
> o OSPF: Authentication trailer for OSPFv3 (RFC 7166)
> o Babel: New option to randomize router ID
> o Filter: Custom route attributes
> o Filter: Support for src accessor to SADR source prefix
> o Filter: Support for VPN_RD sets
> o Filter: Make ifname attribute modifiable
> o Perf: Protocol to measure BIRD performance internally
> o More verbose error messages in config processing
> o Log file size limit / log rotation
> o Many bugfixes
>
> Notes:
>
> Export of routes to RS EBGP (route server) sessions from other sources than
> RS EBGP sessions was changed that ASN is no longer prepended to BGP_PATH in
> that case. The change does not affect regular BGP configurations or regular
> route servers that have only RS EBGP peers.
>
> For BGP route servers and route reflectors, the default value of option
> 'next hop keep' was changed to a more appropriate value.
>
> Attributes for OSPF and Babel metrics are no longer reset when exported to
> these protocols and could be set anywhere in BIRD. As a result, OSPF metric is
> kept when a route is reannounced between OSPF instances. Also, when route is
> exported to OSPF with both ospf_metric1 and ospf_metric2 attributes it is now
> propagated as OSPF-E2 route instead of as OSPF-E1 route.
>
> Compiling BIRD with --enable-debug no longer automatically activates debug
> mode (-d option) nor local mode (-l option). Also, debug mode with output to
> file (-D option) no longer not forces foreground mode (-f option).
>
> The configure script now uses standard option --runstatedir, the old option
> --with-runtimedir is deprecated.
>
>
> Version 2.0.2 (2018-03-22)
> o Source-specific routing support for Linux kernel and Babel
> o BGP: New option 'disable after cease'
> o Filter: Allow silent filter execution
> o Filter: Fixed stack overflow in BGP mask expressions.
> o Several bugfixes
>
> Notes:
>
> Syntax prefix:netmask for IPv4 prefixes was dropped. Just use prefix/pxlen.
>
>
> Version 2.0.1 (2018-01-16)
> o Linux MPLS kernel support
> o Better handling of channels inherited from templates
> o Default EBGP Route Propagation Behavior without Policies (RFC 8212)
> o Many bugfixes
>
> Notes:
>
> To satisfy requirements of RFC 8212, external BGP protocols now require
> explicit configuration of import and export policies.
>
>
> Version 2.0.0 (2017-12-11)
> o Integrated IPv4 + IPv6 design
> o Support for MPLS next hops
> o Support for VPNv4 and VPNv6 networks
> o Microsecond timers infrastructure
> o Basic VRF support
> o Babel: Support for dual-stack IPv4/IPv6
> o Babel: Many improvements and bugfixes
> o Major BGP protocol redesign
> o Full support for Multiprotocol BGP
> o BGP multicast support (SAFI 2)
> o BGP flowspec support (RFC 5575)
> o BGP with MPLS labels (RFC 3107)
> o BGP MPLS/VPN support (RFC 4364)
> o BGP 6PE - IPv6 NLRI over IPv4 MPLS (RFC 4798)
> o BGP IPv4 NLRI with an IPv6 Next Hop (RFC 5549)
> o BGP Confederations (RFC 5065)
> o BGP Shutdown communication (RFC 8203)
> o BGP: Allow exchanging LOCAL_PREF with eBGP peers
> o BGP: Allow to specify interface for regular sessions
> o OSPF: Support of address families in OSPFv3
> o OSPF: Enable ECMP and Link detection by default
> o RAdv: Support for more specific routes (RFC 4191)
> o RAdv: Proper handling of prefix retraction
> o RIP: Enable ECMP and Link detection by default
> o Redesign of RPKI handling
> o New RPKI-Router protocol
> o Static: Minor overhaul
> o Static: Support for all new route types
> o Kenrel: Default Linux kernel metric changed to 32
> o Kernel: Fix IPv6 ECMP handling with Linux 4.11+
> o Update of show route command
> o BIRD client persistent history
> o New build system
> o Unit tests
> o ...
>
> Notes:
>
> Tables are now defined with appropriate net type keyword. Protocols and tables
> are now connected by explicit channels, most related protocol options (table,
> import, export, ...) are now channel options. See doc/bird.conf.example2 for
> configuration examples. Some options were removed/replaced.Turris OS 3.11.3https://gitlab.nic.cz/turris/os/packages/-/issues/300cqueues: add new package for knot-resolver2019-05-02T18:09:49+02:00Jan Pavlineccqueues: add new package for knot-resolverInspiration https://github.com/nwf/openwrt-packages/commit/1fd4732b686d763baaf8084bebc3b319415bdc52Inspiration https://github.com/nwf/openwrt-packages/commit/1fd4732b686d763baaf8084bebc3b319415bdc52Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/packages/-/issues/298lmdb: create new package2019-08-14T12:35:57+02:00Jan Pavlineclmdb: create new packageInspiration can be found here https://github.com/openwrt/packages/issues/5930 It is used in knot-resolver.Inspiration can be found here https://github.com/openwrt/packages/issues/5930 It is used in knot-resolver.Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/packages/-/issues/297kernel: CVE-2019-54892019-01-08T21:37:58+01:00Ghost Userkernel: CVE-2019-5489http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5489
> The mincore() implementation in mm/mincore.c in the Linux kernel through 4.19.13 allowed local attackers to observe page cache access patterns of other processes on the same ...http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5489
> The mincore() implementation in mm/mincore.c in the Linux kernel through 4.19.13 allowed local attackers to observe page cache access patterns of other processes on the same system, potentially allowing sniffing of secret information. (Fixing this affects the output of the fincore program.) Limited remote exploitation may be possible, as demonstrated by latency differences in accessing public files from an Apache HTTP Server.
___
patch https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=574823bfab82d9d8fa47f422778043fbb4b4f50ehttps://gitlab.nic.cz/turris/os/packages/-/issues/296add kernel support for Virtual Routing and Forwarding (VRF)2022-01-24T14:10:47+01:00Ghost Useradd kernel support for Virtual Routing and Forwarding (VRF)https://www.kernel.org/doc/Documentation/networking/vrf.txt
The major benefits are
* higher priority ip rules (Policy Based Routing, PBR)
* iproute2 supports the vrf
* unix socket routing
* impacts only Layer 3 and above so L2 tools (e...https://www.kernel.org/doc/Documentation/networking/vrf.txt
The major benefits are
* higher priority ip rules (Policy Based Routing, PBR)
* iproute2 supports the vrf
* unix socket routing
* impacts only Layer 3 and above so L2 tools (e.g., LLDP) are not affected
* VRF devices allow VRFs to be nested within namespaces
Sound like the perfect companion for a routing device.
Current kernel in TOS 3.11.2 has no VRF support
> type vrf
> RTNETLINK answers: Not supported`Turris OS 7.0Marek BehunMarek Behunhttps://gitlab.nic.cz/turris/os/packages/-/issues/293nextcloud installation failing due to missing dependant perlbase-utf82023-08-01T11:53:49+02:00Ghost Usernextcloud installation failing due to missing dependant perlbase-utf8Reported in [TO forum](https://forum.turris.cz/t/nextcloud-error-installation/8765) the NC installation fails apparently due to missing the dependant `perlbase-utf8`. Installing `perlbase-utf8` appears to resolve the issue.
![c8ae1b7dfa...Reported in [TO forum](https://forum.turris.cz/t/nextcloud-error-installation/8765) the NC installation fails apparently due to missing the dependant `perlbase-utf8`. Installing `perlbase-utf8` appears to resolve the issue.
![c8ae1b7dfaf4a3d01899081fbba946600486481e](/uploads/3eec960bf39467c8588553ed16913f0f/c8ae1b7dfaf4a3d01899081fbba946600486481e.png)Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/292schnapps export not working as dependant tar being absent from the base package2019-01-02T13:56:59+01:00Ghost Userschnapps export not working as dependant tar being absent from the base packageTOS 3.11.1
https://repo.turris.cz/omnia/lists/base.lua is not featuring `tar` and thus `schnapps export` fails
> tar: unrecognized option: one-file-system
> BusyBox v1.29.3 () multi-call binary.
Installing `tar` resolves the issue...TOS 3.11.1
https://repo.turris.cz/omnia/lists/base.lua is not featuring `tar` and thus `schnapps export` fails
> tar: unrecognized option: one-file-system
> BusyBox v1.29.3 () multi-call binary.
Installing `tar` resolves the issue.
TO forum cross reference https://forum.turris.cz/t/cannot-export-shnapps-snapshot/9016Turris OS 3.11.2Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/291static route not being applied when a four 8-bit octets ipv4 subnet mask is set2019-06-05T19:03:24+02:00Ghost Userstatic route not being applied when a four 8-bit octets ipv4 subnet mask is setTOS 3.11.1
Adding a static subnet route via LuCI or ssh file edit the route is not applied when a subnet mask is set via four 8-bit octets. The route however is applied if the netmask is omitted and 255.255.255.255 is assumed and thus m...TOS 3.11.1
Adding a static subnet route via LuCI or ssh file edit the route is not applied when a subnet mask is set via four 8-bit octets. The route however is applied if the netmask is omitted and 255.255.255.255 is assumed and thus makes the target subnet a host address instead of a subnet.
According to the [upstream documentation](https://openwrt.org/docs/guide-user/network/routes_configuration) the syntax for subnets in ipv4 and ipv6 differs and yet seems that the ipv4 subnet mask for the target network receives the same parsing treatment as ipv6, i.e not as four 8-bit octets but its equivalent integer.
Not working (though it would be expected)
```
config route
option interface 'foobar'
option target 'ip'
option gateway 'ip'
option netmask ‘255.255.255.0’
```
Working instead (which is rather unexpected)
```
config route
option interface 'foobar'
option target 'ip/24'
option gateway 'ip'
```
Not sure whether it is a bug or by design and latter not having made into the documentation.
TO forum cross reference https://forum.turris.cz/t/static-route-not-applied/8525https://gitlab.nic.cz/turris/os/packages/-/issues/290provide dependant for luci-app-wifischedule2019-05-14T18:50:05+02:00Ghost Userprovide dependant for luci-app-wifischeduleWith `luci-app-wifischedule` available in the TOS 3.11.1 repo [its dependant](https://github.com/openwrt/packages/tree/openwrt-18.06/net/wifischedule) is missing however
> ERROR:
> inconsistent: Package luci-app-wifischedule requires pa...With `luci-app-wifischedule` available in the TOS 3.11.1 repo [its dependant](https://github.com/openwrt/packages/tree/openwrt-18.06/net/wifischedule) is missing however
> ERROR:
> inconsistent: Package luci-app-wifischedule requires package wifischedule that is not available.Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/packages/-/issues/289ntpd package collision with busybox-ntpd2019-07-31T14:23:31+02:00Ghost Userntpd package collision with busybox-ntpdhappning since TOS 3.11
according to [upstream documentation](https://openwrt.org/docs/guide-user/services/ntp/client-server) and since both, upstream and downstream, repos featuring/serving the [ntpd package](https://downloads.openwrt....happning since TOS 3.11
according to [upstream documentation](https://openwrt.org/docs/guide-user/services/ntp/client-server) and since both, upstream and downstream, repos featuring/serving the [ntpd package](https://downloads.openwrt.org/releases/18.06.1/packages/arm_cortex-a9/packages/ntpd_4.2.8p11-1_arm_cortex-a9.ipk) it would be expected to be able to install said package. However, which worked prior to TOS 3.11 is now producing:
> INFO:Checking for file collisions between packages
> line not found
> line not found
> line not found
> line not found
> line not found
> line not found
> DIE:
> [string "transaction"]:323: [string "transaction"]:149: **Collisions**:
> • /sbin/ntpd: busybox (existing-file), ntpd (new-file)
> Aborted
[cross reference TO forum](https://forum.turris.cz/t/installing-ntpd-on-turrisos/8912/3)https://gitlab.nic.cz/turris/os/packages/-/issues/288implement a designated mac address pool to avoid mac address duplication and ...2019-01-20T23:13:53+01:00Ghost Userimplement a designated mac address pool to avoid mac address duplication and subsequent network odditiesWhilst deploying a 3rd bridge and also when using TOS in a lxc container it became apparent that any network device on top of the layer 2 is inheriting the same mac address as its parent on the layer 2. Which leads to problems in DHCP an...Whilst deploying a 3rd bridge and also when using TOS in a lxc container it became apparent that any network device on top of the layer 2 is inheriting the same mac address as its parent on the layer 2. Which leads to problems in DHCP and subsequent routing when 2 devices with the same mac address are assigned different ip addresses.https://gitlab.nic.cz/turris/os/packages/-/issues/287luajit: update to version 2.1.0-beta3-12023-08-16T14:55:26+02:00Jan Pavlinecluajit: update to version 2.1.0-beta3-1Update luajit to upstream version. This could enable build knot-resolver for Turris 1.x
(Related to https://github.com/LuaJIT/LuaJIT/issues/330)Update luajit to upstream version. This could enable build knot-resolver for Turris 1.x
(Related to https://github.com/LuaJIT/LuaJIT/issues/330)https://gitlab.nic.cz/turris/os/packages/-/issues/285provide package from upstream for running unpriviliged lxc containers on the TO2019-06-05T18:48:15+02:00Ghost Userprovide package from upstream for running unpriviliged lxc containers on the TOApparently [this package](https://downloads.openwrt.org/releases/18.06.1/packages/arm_cortex-a9/packages/lxc-unprivileged_2.1.1-2_arm_cortex-a9.ipk) being essential for running unprivilged containers on OpenWRT, however it appears absent...Apparently [this package](https://downloads.openwrt.org/releases/18.06.1/packages/arm_cortex-a9/packages/lxc-unprivileged_2.1.1-2_arm_cortex-a9.ipk) being essential for running unprivilged containers on OpenWRT, however it appears absent from the TO repo.
cross reference https://patchwork.ozlabs.org/patch/844848/
It would nessessitate an up to date shadow package https://patchwork.ozlabs.org/patch/837829/ for newgidmap and newuidmap mapping.https://gitlab.nic.cz/turris/os/packages/-/issues/284provide mechanism to communicate with modems' firmware connected on TO's WAN/SFP2020-12-28T09:18:45+01:00Ghost Userprovide mechanism to communicate with modems' firmware connected on TO's WAN/SFPIt would be welcome and highly beneficial for users of modems, e.g. [ALLNET ALL4781-VDSL2-SFP / Switch Modul (Mini-GBIC), VDSL2](https://www.allnet.de/en/allnet-brand/produkte/switches/switches-fiber-module/p/-0c35cc9ea9/), connecting to...It would be welcome and highly beneficial for users of modems, e.g. [ALLNET ALL4781-VDSL2-SFP / Switch Modul (Mini-GBIC), VDSL2](https://www.allnet.de/en/allnet-brand/produkte/switches/switches-fiber-module/p/-0c35cc9ea9/), connecting to the TO's WAN/SFP (-> `eth1`) to be able to communicate with the modem's firmware for the purpose of monitoring, diagnosing and firmware updates. [Such seems to be commonly possible with switch devices](https://forum.turris.cz/t/user-experience-allnet-all4781-vdsl2-sfp-switch-modul-mini-gbic-vdsl2/7062/66?u=n8v8r) but does not work with the TO (TOS 3.11.1).
For the aforementioned modem its vendor ALLNET provides such tool (enclosed) and shared it with one of the TO users who posted a sharing link (allegedly with permission of ALLNET) in the [Turris Forum](https://forum.turris.cz/t/user-experience-allnet-all4781-vdsl2-sfp-switch-modul-mini-gbic-vdsl2/7062/43).
Testing the tool (EBM mode) it turned out (via `tcpdump` on TO's eth1) that the `tcp` packets sent from the client running the tool are received @ TO's `eth1` but apparently deadending (no response) there. Thus this feature suggestion.
---
About the tool - it appears to have been coded by and originating from the [modem's chipset designer](https://www.metanoia-comm.com/). In W10 v1809 it should not be run from a restictive desktop but a less restrictive path. It requires MS.NET/Framework/v4.0 or above and [WinPCAP LIbrary/Utility](https://nmap.org/npcap/). Upon first execution of `DSLmonitor.exe` registers some dlls to the system.
I had no issue with its execution in a W10 _x64 v1809 environment.
[DSLmonitor_Lite_v0.10.7.A_20180813.zip](/uploads/c94fddc65f0401ce4d42a8eea2b5a9b3/DSLmonitor_Lite_v0.10.7.A_20180813.zip)[ALL4781-VDSL2-SFP_DSLmonitor_Tool.pdf](/uploads/3e501d8b81422ffc1b89f4369439e979/ALL4781-VDSL2-SFP_DSLmonitor_Tool.pdf)https://gitlab.nic.cz/turris/os/packages/-/issues/283lxc.utsname not being parsed into container's hostname2019-05-06T17:21:52+02:00Ghost Userlxc.utsname not being parsed into container's hostnameWith the container's config `lxc.utsname = foobar` it would be expected that the container's hostname would be matching `foobar` (parsed into hostname file of the respective container).
However, having tested various container installat...With the container's config `lxc.utsname = foobar` it would be expected that the container's hostname would be matching `foobar` (parsed into hostname file of the respective container).
However, having tested various container installation the hostname ends up being the standard one of the respective distro, e.g. this one ArchLinux
https://forum.turris.cz/uploads/default/original/2X/8/824139afea2ab70c51fc45b12a92292fe3297e8b.png
TOS RC 3.11.1 |
liblxc 1.1.5-15 |
luci-app-lxc 20160616-1 |
lxc 1.1.5-15 |
lxc-attach 1.1.5-15 |
lxc-auto 1.1.5-15 |
lxc-autostart 1.1.5-15 |
lxc-cgroup 1.1.5-15 |
lxc-checkconfig 1.1.5-15 |
lxc-clone 1.1.5-15 |
lxc-common 1.1.5-15 |
lxc-config 1.1.5-15 |
lxc-configs 1.1.5-15 |
lxc-console 1.1.5-15 |
lxc-create 1.1.5-15 |
lxc-destroy 1.1.5-15 |
lxc-device 1.1.5-15 |
lxc-execute 1.1.5-15 |
lxc-freeze 1.1.5-15 |
lxc-hooks 1.1.5-15 |
lxc-info 1.1.5-15 |
lxc-init 1.1.5-15 |
lxc-ls 1.1.5-15 |
lxc-lua 1.1.5-15 |
lxc-monitor 1.1.5-15 |
lxc-monitord 1.1.5-15 |
lxc-snapshot 1.1.5-15 |
lxc-start 1.1.5-15 |
lxc-stop 1.1.5-15 |
lxc-templates 1.1.5-15 |
lxc-unfreeze 1.1.5-15 |
lxc-unshare 1.1.5-15 |
lxc-user-nic 1.1.5-15 |
lxc-usernsexec 1.1.5-15 |
lxc-wait 1.1.5-15 |
rpcd-mod-lxc 20141012