During CDRouter tests, prplMesh is currently running in Agent mode (default).
This means cwmpd is unable to resolve the "Device.WiFi.DataElements." tree, because it is specific to the prplMesh controller.
Therefore, start prplMesh in controller mode before these tests are executed, so the "Device.WiFi.DataElements." datamodel is available.
Closes: PPM-3382
Signed-off-by: Maarten De Decker <maarten.dedecker@mind.be>
Copy over files from the prplMesh repository to flash devices in the R1 Easymesh testbed.
Adds an easyMesh R1 certification test on Freedom as a smoke test (MAP-4.4.2_BHWIFI_FH5GH).
Closes: PPM-3316
Signed-off-by: Maarten De Decker <maarten.dedecker@mind.be>
Currently we're seeing Mozart VLAN related CI test failures as it seems,
that the fixup commit fixing the bridge port of lan0 interface got lost
somehow during the rebase.
Fixes: 95e21db42b86 ("ci: testbed-device.py: Mozart: fix VLAN config by adding lan0 interface")
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
As the vendor prefix has changed, the commands to be executed also changed. The DUT init script should be updated accordingly
Issue: PCF-1489
Signed-off-by: Toon Caeyers <toon.caeyers_ext@softathome.com>
Currently the eth1 interface is being configured, but physically lan0 is
connected to the network, so lets adapt the _init_lan_vlan with correct
LAN port.
References: PCF-1462
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Currently we're experiencing test failures of prpl_h-api-cwmp.2.5
CDRouter test caused by 503 errors being returned by cwmpd. This is
happening as the default rate limits are low for this test case.
So lets add the DUT init script, which will increase the default
settings to following values:
ManagementServer.X_PRPL-COM_FreqConnectionRequest=60
ManagementServer.X_PRPL-COM_MaxConnectionRequest=10000
So basically allowing 10k requests in 60 seconds.
References: PCF-1611
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
After aligning the tr181-dns datamodel with the tr181 v2.18 datamodel,
the DNS.Relay.X_PRPL-COM_Config object no longer exists:
Running .gitlab/scripts/dut-init/cdrouter-dut-flush-dns-relay-cache.sh
Command failed: Request timed out
> DNS.Relay.X_PRPL-COM_Config.[Alias=="lan"].FlushCache()
ERROR: No objects found DNS.Relay.X_PRPL-COM_Config.[Alias=="lan"].FlushCache
So lets fix it by using the current DNS.Relay.Config without the prefix.
References: PCF-1492
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
Currently the CDRouter VLAN tests are failing with:
FAIL: Could not establish IPv4 DHCP address on lan » no-lan-dhcp-address
This is happening as the UPDK 9.1.80 upstep changes the value of the
model variables in the device tree:
* OSPv1: from `mxl,lightning mountainmxl,lgp` to `mxl,osp-tb341`
* OSPv2: from `mxl,lightning mountainmxl,octopusmxl,octopus-641` to `mxl,osp-tb341-v2`
and thus the DUT VLAN configuration is unable to detect the board
properly and configure the VLAN on the the correct LAN port properly.
So lets adapt the board identification in the VLAN configuration to the
new device tree model variables.
Fixes: 45d2f1fcccc7 ("profiles: mxl_x86_osp_tb341_v2: update to UPDK 9.1.80")
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
There is currently a lot of old and already very obsolete stuff in the
tree for the past devices like glinet-b1300, urx851-b0-dk, nec-wx3000hp.
So lets cleanup all those unused bits to make the tree more tidy and
easier to maintain.
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
Problem: Cannot set SSID during the configuration of the DUT
Cause: Starting from PWHM v6.34.1 we shouldn't use the terminating dot
when accessing SSIDReference and LowerLayers parameters.
Solution: Remove the termiantion dot when selecting SSID via the
LowerLayers reference.
Note: The previous version of the cdrouter-dut-configure-dyndns.sh was
based on PWHM version from prplOS 3.2 which is based on 6.34.0 with a
backport of only some PPWH/PPM tickets. The pwhm commit related to the
terminating dot change is not part of the list.
PWHM commit : b8706173c1240d8dabdd9816a49fd774b968c160
References: PPM-3069
Signed-off-by: Houssem Dafdouf <houssem.dafdouf_ext@softathome.com>
WORKAROUND: When the first check misses, the ddns script only rechecks after 60s,
this can fall just outside the allowed range of the test.
Lowering it to 30s should allow for the second check to still count.
Issue:PPW-282 - DynDNS 3.1 maintenance release CDRouter test fails
Signed-off-by: Toon Caeyers <toon.caeyers_ext@softathome.com>
(cherry picked from commit de7bb3795ad55d21d94079bf699d15dde4d49d2d)
Issue: VLAN tests fail to configure the vlan on the lan side because a VLANPort can not be created
Cause: Trailing dots are no longer allowed in the path references. TR181-bridging v2.8.13, v2.8.10 and v2.8.12 include changes to remove the trailing dot from path references. This is done to be inline with the tr181 spec
Fix: Remove the trailing dots from the command creating the VLANPort
Signed-off-by: Toon Caeyers <toon.caeyers_ext@softathome.com>
On Freedom, for some reason, the 5GHz and 6GHz radios are causing random
issues in conjunction with regulatory domain change, leading to
following hostapd startup errors randomly:
wlan2.1: interface state UNINITIALIZED->COUNTRY_UPDATE
Hardware does not support configured mode
wlan2.1: IEEE 802.11 Hardware does not support configured mode (2) (hw_mode in hostapd.conf)
Could not select hw_mode and channel. (-2)
In the single hostapd scenario it results in the completely lacking WiFi
functionality on the DUT.
So until the root of the problem is found, try to workaround the issue
by using channel 11 in the second testbed, thus we don't need to set
regulatory domain.
References: PPW-303, PPM-3103
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
Three issues were identified with CDRouter wireless tests:
1. The wireless configuration handling changed, making SSIDs no longer
available at fixed datamodel indexes.
2. The default Channel=1 frequency spectrum changed in the testbed environment,
causing increased interference with other devices.
3. Both testbeds and DUTs in them were using identical default settings,
resulting in crosstalk between them when CDRouter Wireless tests were
run on both testbeds at the same time.
So lets fix it by moving each testbed into different channel and properly
configuring the wireless settings for each testbed and DUT corresponding
to the testbed:
- testbed-01: RegulatoryDomain=CZ, Channel=6, SSID=prplOS-2g-6
- testbed-02: RegulatoryDomain=CZ, Channel=12, SSID=prplOS-2g-12
While at it, switch from ubus-cli to ba-cli, which is now preferred due
to its bus agnostic nature, thus making the commands more future proof.
Closes: PPM-3069
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
Currently we run init scripts via `sh` which is not the best way to run
scripts, because it for example limits the ability to use `#!/usr/bin/env bash`
in the scripts. This commit changes the way how init scripts are run to use
shebang.
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
For some reasons the current 180s timeout is not enough in most cases
currently, so the console_dump_system_state() timeouts which results in
lack of complete output. So lets workaround it by increasing the timeout
to 360s.
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
When running the changes done in commit 140ad37e2ab0 ("cdrouter:
wireless: make wifiBeaconPhy configurable"), we can see:
Traceback (most recent call last):
File ".gitlab/scripts/testbed-cdrouter.py", line 441, in <module>
main()
File ".gitlab/scripts/testbed-cdrouter.py", line 437, in main
args.func(cdr)
File ".gitlab/scripts/testbed-cdrouter.py", line 345, in config_import
content = self.replace_env_config_variables(content)
File ".gitlab/scripts/testbed-cdrouter.py", line 330, in replace_env_config_variables
text = re.sub(pattern, value, text)
File "/usr/lib/python3.7/re.py", line 192, in sub
return _compile(pattern, flags).sub(repl, string, count)
TypeError: cannot use a string pattern on a bytes-like object
The re.sub() command fails because a non utf-8 encoded string is
passed. Let's therefore adapt the method that is called for opening a
file to always return a utf-8 decoded string.
Fixes: 140ad37e2ab0 ("cdrouter: wireless: make wifiBeaconPhy configurable")
Signed-off-by: Matthias FRANCK <matthias.franck@softathome.com>
With the new wnc-freedom wifi7 box, the wifiBeaconPhy testvar of CDRouter needs to include "be" as well. Let's make this configurable in the CI by introducing a CDROUTER_CONFIG_WIFI_BEACON_PHY variable that can be set uniquely for every box.
Signed-off-by: Matthias FRANCK <matthias.franck@softathome.com>
'uci_dyndns.org' server index has changed in OpenWRT 23.05. Adapt the initialization script accordingly.
Signed-off-by: Yüce Kürüm <yuce.kurum@mind.be>
Signed-off-by: Yüce Kürüm <yuce.kurum_ext@softathome.com>
We're unable to run CDRouter test for CPE's TR-069 functionality due to
the following error during the test init phase:
FAIL: Did not receive TR-069 Inform RPC from CPE after 120 seconds » no-wan-tr069-inform
Analyzing the logs, issue arise whenever CPE manages to get a first WAN
address from testbed server instead of CDRouter. With additional unbound traces we can see what happens:
As WAN is up, DNS query for controller.cdroutertest.com is forwarded to
configured upstream DSN server (8.8.8.8 and 1.1.1.1)
1.1.1.1 will reply with a SOA as cdroutertest.com is registered:
cdroutertest.com. 3600 IN SOA ns1.linode.com. support.qacafe.com. 2021000016 14400 14400 1209600 86400
As TTLS is set to 3600 seconds, unbound will cache this as a negative answer for 1 hour.
Latter upstream of CPE is switched to CDRouter, obuspa tries to resolve
controller.cdroutertest.com, but it gets the cached answer as its TTL is
not expired, and no WAN DSN query is done.
So lets fix it by flushing the DNS relay cache during the DUT init
phase, once the network is switched to the CDRouter.
Fixes: PCF-1215
Suggested-by: Vincent Harle <vincent.harle@softathome.com>
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
(cherry picked from commit 53f718bde87b0e1773244da021daf2eeeac8a62a)
I've intentionally connected LAN network into different LAN port on the
board to increase testing coverage and possible fixed configurations
here and there, so for that we need to specify a different bridge port
for VLAN configuration used during CDRouter VLAN testing.
References: PCF-1138
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
While integrating support for OSPv2, also known as MXL25641-HDK-6, I
discovered that it's impossible to uniquely identify the machine. This
is because the /proc/device-tree/compatible (DTS Root Node) is identical
across all MxL boards.
So lets workaround it by using `/proc/device-tree/model` additionally,
which at least help distinguish between OSPv1 and OSPv2, thus we first
check for `compatible` and if not usable, then fallback to `model`
property.
References: PCF-1161
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
For some unknown reason upstream Linux kernel in version 4.16 via commit
5ee39a71fd89 ("arm64: Disable unhandled signal log messages by default")
silenced the reporting of traces for user space exceptions and thus
making arm64 the only architecture having this disabled by default:
arch/arm64/kernel/traps.c:int show_unhandled_signals = 0;
arch/csky/kernel/traps.c:int show_unhandled_signals = 1;
arch/loongarch/mm/fault.c:int show_unhandled_signals = 1;
arch/mips/mm/fault.c:int show_unhandled_signals = 1;
arch/parisc/mm/fault.c:int show_unhandled_signals = 1;
arch/powerpc/kernel/signal.c:int show_unhandled_signals = 1;
arch/riscv/kernel/traps.c:int show_unhandled_signals = 1;
arch/s390/mm/fault.c:int show_unhandled_signals = 1;
arch/sparc/mm/fault_32.c:int show_unhandled_signals = 1;
arch/sparc/mm/fault_64.c:int show_unhandled_signals = 1;
arch/x86/mm/fault.c:int show_unhandled_signals = 1;
We would like to be aware about such exceptions at least during
development, so lets enable it in development builds in the same spirit
as we did for coredumps in commit 6cf5635bf50e ("ci: generate coredumps
during development").
References: PCF-1107, PCF-1108
Signed-off-by: Petr Štetiar <ynezz@true.cz>
_init_lan_vlan() defaults to use `Bridging.Bridge.1.Port.2.` for LAN
VLAN configuration, which is wrong on prpl-haze as there is nothing
connect to that LAN1 port, so lets fix it by using the correct
`Bridging.Bridge.1.Port.4` (LAN3).
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Currently we're trying to have coredumps disabled to avoid regressions
such as PCF-663, but sometimes it might be handy to be able to collect
coredumps from the CI jobs, so lets introduce CI_BUILD_ENABLE_COREDUMPS
variable and enable it during development only, that is not on tagged
builds and not on builds in designated branches.
References: PCF-992, PCF-967
Signed-off-by: Petr Štetiar <ynezz@true.cz>
getDebugInformation script collects all the useful information from the
running system already, so lets use it instead of current list of
commands. While at it, dump the output directly to the serial console
and thus bypass labgrid as it might influence the behavior and/or the
output.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Currently there is 30 second timeout hardcoded in shell run() method,
but we sometimes might need to use different value, so lets extend the
method args to allow overriding it.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
We're currently using obsoleted 'intel,lgm' board name from device tree,
so fix it by using current 'mxl,lgm' name.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Changes done in commit c7581879d874 (".gitlab: scripts: Update scripts
for M1 delivery") turned generic LAN VLAN init code to URX851 specific
code so lets fix it by reverting the device specific changes.
Fixes: c7581879d874 (".gitlab: scripts: Update scripts for M1 delivery")
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Fixes following ruff warning:
testbed-device.py:240:9: F841 Local variable `network` is assigned to but never used
Fixes: c7581879d874 (".gitlab: scripts: Update scripts for M1 delivery")
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Currently we're using fixed WiFi.AccessPoint.1 for CDRouter wireless
testing, but this has changed and its device specific, so lets handle it
dynamically.
Suggested-by: Marouan MCHARFI <marouan.mcharfi_ext@softathome.com>
Signed-off-by: Petr Štetiar <ynezz@true.cz>
- cdrouter-dut-enable-pppoe: Update the script to use wanmanager to set PPP mode wan mode.
- testbed-device.py: Update commands to work with latest datamodel changes. At the same time update some commands to use ubus-cli rather than ubus directly.
Signed-off-by: Matthias FRANCK <matthias.franck_ext@softathome.com>
Import URX851 support for runtime testing from private prplos-urx851
project, so we can extend public QA process using those devices as well.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Enable testing of wireless stack using following essential CDRouter
tests:
wifi_1 Graceful wireless LAN client restart
wifi_2 Restart wireless LAN client without releasing address
wifi_3 Restart wireless LAN client without releasing or obtaining a new address
wifi_10 Verify connectivity using all wifi modes advertised by the DUT
wifi_11 Verify DUT prevents use of TKIP cipher when using HT/VHT/HE
wifi_20 Verify DUT's wifi beacons contain expected mode information
wifi_30 WiFi association stress test
wifi_40 WiFi SSID scan test
Run those 8 testcases, in a loop 2 times and repeat each test 2 times.
References: PCF-883
Signed-off-by: Petr Štetiar <ynezz@true.cz>
(cherry picked from commit eb74a59a99925f040813d364ca19b8b91260ad6c)
It seems like current 90s timeout for LAN network readiness checking is
not long enough, likely due to some netifd issues connected to PCF-860,
so lets increase it to 180s and see how it goes.
References: PCF-860
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Currently CDrouter TR069 tests are failing:
FAIL: Expected to find Device.LANConfigSecurity.ConfigPassword in Values list
FAIL: Expected to find Device.LANConfigSecurity. in Names list
FAIL: Expected to find Device.LANConfigSecurity.ConfigPassword in Names list
Those failures are caused by a recent TR069 updates, where the mapping
was done internally by the TR069 stack, but its not doing that mapping
anymore, so until we get the fix of the mapping in the proper TR181
component, we should simply provide it manually via ProxyManager.
Suggested-by: Vincent Harle <vincent.harle@softathome.com>
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Contains changes needed to make DSLite configuration actually working on
the DUT.
References: PCF-791
Signed-off-by: Vincent Harle <vincent.harle@softathome.com>
Signed-off-by: Petr Štetiar <ynezz@true.cz>
(cherry picked from commit 9eb7cab05cf14c8d83702fa3daeeb46cc36c71c1)
It seems, that in the latest ddns packages there is no
/etc/ddns/services file present and services are being defined in
/usr/share/ddns/default JSON files.
Until this is fixed properly, lets workaround it by manually generating
/etc/ddns/services file.
We need to change service offset in CDRouter DUT init script to 9 as
it's where members.dyndns.org is currently being defined.
References: PCF-830
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Sync CI bits with the current state in prplos branch on commit
9af7fff65169 ("ci: fix build Docker image sdk-x86-64 job").
Signed-off-by: Petr Štetiar <ynezz@true.cz>
