Since OSPv2 B-Step devices are de-facto a standard devices currently
being sold, it was decided to start using them for testing in prplOS CI
instead of current OSPv2 A-Step boards.
References: PCF-2200
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
(cherry picked from commit 7310621934)
CDRouter’s prpl certification tests fail with missing TR-181 parameters
when run against the mainline-23.05 branch, as newer CDRouter releases
default to the 4.1.0 datamodel. For this branch we must explicitly pin
the prplWareVersion testvar to 4.0.0, which matches the datamodel
implemented by prplOS.
This prevents false-positive failures such as missing:
- Device.Ethernet.Interface.{i}.SFPReferenceList
- Device.Routing.Router.{i}.IPv4Forwarding.{i}.MTU
- Device.Routing.Router.{i}.IPv6Forwarding.{i}.MTU
- Device.Routing.Router.{i}.IPv6Forwarding.{i}.SourceIPPrefix
Fixes: PCF-2179
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
There is now dedicated LCM data partition mounted under /lcm which is
not cleared up after each test, thus containers used in previous tests
persist during the DUT reboot and flashing procedure, violating test
imdepotence and making consecutive test fail.
So lets fix it by clearing up the LCM data partition during DUT firmware
flashing procedure, clearing just ext4 filesystem metadata, not erasing
complete 3 GiB and saving some time.
16 0x000a6c00 0x006a6bff "lcm_data"
attrs: 0x0000000000000000
type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
guid: 777a7bb0-4d48-4b39-8cc1-da40d9f28205
The 0xa6c00 is the starting eMMC block of that partition and 0x400 is
eMMC erase group size, thus minimal size we can erase.
Reported-by: Matthias Franck <matthias.franck@softathome.com>
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
(cherry picked from commit 85f379b696)
We need to make sure, that prplWare passes prplOS Network Test Plan
certification test suite. We've added separate test package with
Mandatory test cases, but we should be able to test as well the
remaining, currently Optional or Privisionary Excluded test cases, so we
get the test results and work towards making all of them Mandatory.
The test package contains only mandatory tests from the test plan, so 64
tests:
prplos.1.1.1, prplos.1.1.2, prplos.1.1.8, prplos.1.1.9, prplos.1.1.10,
prplos.1.1.11, prplos.1.1.12, prplos.1.1.13, prplos.1.2.10,
prplos.1.2.20, prplos.1.2.21, prplos.1.2.22, prplos.1.2.23,
prplos.1.2.24, prplos.1.2.25, prplos.1.2.27, prplos.1.2.28,
prplos.1.2.30, prplos.1.3.4, prplos.1.3.5, prplos.1.3.6, prplos.1.3.7,
prplos.1.3.9, prplos.1.3.11, prplos.1.3.14, prplos.1.3.15,
prplos.1.3.16, prplos.1.3.18, prplos.1.3.19, prplos.1.3.20,
prplos.1.3.21, prplos.1.3.22, prplos.1.3.23, prplos.1.3.24,
prplos.1.3.25, prplos.1.3.26, prplos.1.3.27, prplos.1.4.2, prplos.1.4.3,
prplos.1.4.4, prplos.1.5.4, prplos.1.5.5, prplos.1.5.6, prplos.1.5.7,
prplos.1.5.14, prplos.1.5.15, prplos.1.5.16, prplos.1.5.17,
prplos.1.5.18, prplos.1.5.19, prplos.1.6.1, prplos.1.6.2, prplos.1.6.6,
prplos.1.6.7, prplos.1.6.8, prplos.1.6.13, prplos.1.6.15, prplos.1.6.19,
prplos.1.6.24, prplos.1.6.25, prplos.1.6.26, prplos.1.6.27,
prplos.1.6.28, prplos.1.6.29
References: PCF-1609
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
(cherry picked from commit fc5eedd76a)
Currently we're seeing prplOS.1.4.9 test failure which is happening due
to disabled config options:
* ipv6WanRDNSS - This option enables or disables the IPv6 RDNSS option
for router advertisements on the WAN. When set to yes, CDRouter will
announce the configured IPv6 DNS servers using the RDNSS option in
router advertisements.
* ipv6WanDNSSL - This option enables or disables the IPv6 DNSSL option
for router advertisements on the WAN. When set to yes, CDRouter will
announce the domain name, as configured by the testvar wanDomainName,
using the DNSSL option in router advertisements.
So lets fix it by enabling those config options.
References: PPW-362
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
(cherry picked from commit 72bbfce2a4)
[during cherry-pick the TLS changes were reverted as we don't have
FEAT-53 support in mainline-23.05]
We need to make sure, that prplWare passes prplOS Network Test Plan
certification test suite and for that we need to configure CDRouter and
DUT.
CDRouter config changes in new prplos-certification config:
* ipv6WanMode was changed from autoconf to DHCP
* ipv6LanMode was changed from autoconf to DHCP
DUTs are being dynamically configured with following datamodel
configuration:
* DHCPv6Client.Client.wan.RequestAddresses=1 so DUT requests IA_NA
* RouterAdvertisement.InterfaceSetting.lan.AdvManagedFlag=1 so CDRouter
can start DHCPv6 client
- WARNING(lan): The Mbit in the last router advertisement is set to 0 indicating that DHCPv6 is not allowed
- WARNING(lan): Cannot start DHCPv6 client
References: PCF-1609
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
(cherry picked from commit c9e14b80e7)
We need to create a new configuration for prplOS Certification testing,
so lets start from generic-ipv6 config, so the CDRouter configuration
changes needed for prplOS Certification tests are visible in the next
Git commit (diff).
References: PCF-1609
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
(cherry picked from commit e6546c2347)
We need to make sure, that prplWare passes prplOS Network Test Plan
certification test suite. So lets add a new `certification tests` stage
with a new prplOS-Network-Test-Plan-Mandatory-v1.1.0 CI test job which
should help us QA this.
The test package contains only mandatory tests from the test plan, so 63
tests:
prplos.1.1.3, prplos.1.1.4, prplos.1.1.5, prplos.1.1.6, prplos.1.1.7,
prplos.1.2.1, prplos.1.2.2, prplos.1.2.3, prplos.1.2.4, prplos.1.2.5,
prplos.1.2.6, prplos.1.2.7, prplos.1.2.8, prplos.1.2.9, prplos.1.2.11,
prplos.1.2.12, prplos.1.2.13, prplos.1.2.14, prplos.1.2.15,
prplos.1.2.16, prplos.1.2.17, prplos.1.2.18, prplos.1.2.19,
prplos.1.2.26, prplos.1.2.29, prplos.1.3.1, prplos.1.3.2, prplos.1.3.3,
prplos.1.3.8, prplos.1.3.10, prplos.1.3.12, prplos.1.3.13,
prplos.1.3.17, prplos.1.4.1, prplos.1.4.5, prplos.1.4.6, prplos.1.4.7,
prplos.1.4.8, prplos.1.4.9, prplos.1.5.1, prplos.1.5.2, prplos.1.5.3,
prplos.1.5.8, prplos.1.5.9, prplos.1.5.10, prplos.1.5.11, prplos.1.5.12,
prplos.1.5.13, prplos.1.6.3, prplos.1.6.4, prplos.1.6.5, prplos.1.6.9,
prplos.1.6.10, prplos.1.6.11, prplos.1.6.12, prplos.1.6.14,
prplos.1.6.16, prplos.1.6.17, prplos.1.6.18, prplos.1.6.20,
prplos.1.6.21, prplos.1.6.22, prplos.1.6.23
References: PCF-1609
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
(cherry picked from commit 3b134e421c)
Support for 24.10 based prplOS comes with UPDK 9.2.0/9.1.95 which brings
as well prpl Standard Flash Layout, so lets adapt the flashing
procedure using new bootloader and FIT image.
References: PCF-1832
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
New MediaTek/Arcadyan Mozart regular track reference platform is being
introduced, so lets enable the runtime testing using cram/CDRouter tests
on one Mozart device currently plugged into testbed-02.
References: PCF-1460, PCF-1461
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
After changes done in commit cd0b155631 ("profiles: prpl:
tr069-manager: bump to v1.35.5"), we've started seeing increased number
of CDRouter test failures related to TR-069 testing:
FAIL: Did not receive TR-069 Inform RPC from CPE after 120 seconds » no-wan-tr069-inform
FAIL: Did not receive TR-069 Inform RPC from CPE after 240 seconds » no-wan-tr069-inform
Until this gets fixed, lets increase the default acsWaitForInform timeout
from 120 seconds to 480 seconds, which hopefully should provide enough
room for cwmpd to connect with ACS.
References: PPW-544
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
Currently we've only "prplOS Test Plan for prpl devices" included in the
prpl-Certification package, but we need as well "prpl High-Level API
Tests" (USP) and "prpl High-Level API Tests for CWMP" as we need to make
sure, that prplWare is usable via both USP and CWMP protocols.
So lets add those currently missing test cases:
* prpl High-Level API Tests (USP)
* prpl_hl-api.1.1 - Profile GetSupportedDM
* prpl_hl-api.1.2 - Profile Parameters Write
* prpl_hl-api.1.3 - Get
* prpl_hl-api.1.4 - Set
* prpl_hl-api.1.5 - Add and Delete
* prpl High-Level API Tests for CWMP
* prpl_hl-api-cwmp.2.1 - Profile GetParameterNames
* prpl_hl-api-cwmp.2.2 - Profile Parameters Write
* prpl_hl-api-cwmp.2.3 - Get
* prpl_hl-api-cwmp.2.4 - Set
* prpl_hl-api-cwmp.2.5 - Add and Delete
References: PCF-1611
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
CDRouter offers a dedicated prpl Certification expansion for the prpl
Foundation’s prplWare and High-Level API Certification program.
As an officially approved testing tool, CDRouter is an authorized test
tool for use in conducting the prplWare and High-Level API self-testing
certification.
prplOS should be routinely tested using the CDRouter prpl Certification
expansion, so lets add the prpl Certification CI jobs for all devices
and new prpl Certification package.
Closes: PCF-1611
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
CDRouter offers a dedicated prpl Certification expansion for the prpl
Foundation’s prplWare and High-Level API Certification program.
As an officially approved testing tool, CDRouter is an authorized test
tool for use in conducting the prplWare and High-Level API self-testing
certification.
prplOS should be routinely tested using the CDRouter prpl Certification
expansion, so lets add the needed configuration:
prplosLanInterfaceAlias - This parameter specifies the LAN interface
Alias used to verify bridge functions on the prplOS implementation. This
parameter must be set to the value of Device.Bridging.Bridge.{i}.Port.{i}.Alias
that corresponds to the primary LAN test interface used for prplOS
Certification testing.
useSameLanInterface - If this testvar is set to no, CDRouter will
change LAN interfaces each time a test is run when multiple LAN
interfaces are configured. You can disable this behavior by configuring
the testvar useSameLanInterface to yes.
We set this value to `yes`, because we're only utilizing one LAN port.
References: PCF-1611
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
Current CI testing pipeline is very comprehensive and unusable for
testing of more granular deliveries and thus a new prplWare Smoke Test
Suite is needed.
The idea behind this new prplWare Smoke Test Suite is, that the complete
test runtime should fit into the range of 60-90 minutes.
The new Smoke Test Suite should contain testing a bit of everything, so
we cover most of the areas, while being able to finish a test within a
reasonable timeframe.
Thus this new test suite combines the current:
* CDRouter TOP 100 IPv4 and IPv6 packages, minus:
- the longest running TCP/UDP firewall port scan tests:
* ipv6_firewall_100
* ipv6_firewall_101
* cdrouter_firewall_100
* cdrouter_firewall_101
* cdrouter_firewall_110
- the failing tests on OSP boards:
* cdrouter_nat_201 tracked in PCF-972
* cdrouter_l2tppt_2 tracked in PCF-971
* CDRouter TR-069 package, minus the reboot test od128_test_14.1
* CDRouter USP certification test cases + USP basic test + prpl HL-API
tests (minus the problematic and currently always failing prpl_hl-api.1.4 Set test)
* cdrouter_dyndns_1 - DynDNS client sends an update request when the WAN IP address changes
* cdrouter_dyndns_2 - DynDNS client does not update if the WAN reestablishes with the same IP address
So the package contains in total 310 CDRouter test cases.
Closes: PCF-1645
References: PCF-971, PCF-972
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>
We're going to use single smoke-test config to test bit of everything in
single test suite, so lets sync the DynDNS config from the generic
config.
References: PCF-1645
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
We're going to use single config for both IPv4 and IPv6 testing, so lets
sync the dhcpLeaseTime of 180 seconds from generic config, currently
being used for IPv4 based tests only.
References: PCF-1645
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
Copy over generic-ipv6 configuration to smoke-test, so later changes are
clearly visible.
References: PCF-1645
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
The main purpose of this upstep is the integration of the Wifi7/MLO
feature.
Additional updates :
Feeds :
- Update libswlc to v5.30.2
CRAM tests :
- obuspa.t/ubus-datamodel-list.t : add new objects introduced by the
pwhm v7.x upstep
- 100-pwhm.t : update script to test MLO main link interface status
- 101-mlo.t : new script to test MLO deactivation
CDRouter updates (tri-band MLO prequesties) :
- Security mode is now set to WPA3-WPA2-Personal
- Add SAE in the expected key management mode list.
- Remove 'be' from the expected phy mode list on OSPv2. As it shouldn't
be broadcasted if MLO is not supported or when the access point is not
part of an MLD.
PWHM reference commit : 0627886f993c25b0de4ee628d9d07e7f67f01008
Closes: PPM-2984
References: PPW-228
Signed-off-by: Houssem Dafdouf <houssem.dafdouf_ext@softathome.com>
We have been running CDRouter wireless tests on the 2.4GHz band, using default
settings except for changing the SSID to prplOS-2g-6 and channel to 6. In multiple
test loops, the majority of observed failures occur specifically in CDRouter’s
wifi_10 test when running on the OSPv1 board. Removing the wifi_10 test, however,
leads to near 100% passing results, indicating that the issue is specifically tied
to how the AP handles the 4-way EAPOL handshake under wifi_10.
Packet captures and hostapd logs suggest the AP resets its handshake state machine
prematurely, returning to PTKSTART and eventually causing deauthentication (reason code 15).
This breaks the test procedure and leads to a high failure rate on OSPv1.
Analysis shows that other boards (e.g., MXL25641-HDK-6, Haze, Freedom) do not exhibit
the same level of instability. For OSPv1 (URX851-HDK-3), the failure rate can reach about
40-78% during wifi_10 runs. Removing wifi_10 reduces failures drastically.
Until the root cause in the EAPOL 4-way handshake process is identified and resolved,
we will remove the wifi_10 test from the test suite. Doing so mitigates the frequent
failures and allows the rest of the suite to execute reliably.
References: PCF-1586
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>
This reverts commit e19787c7e5 as the
issues should be fixed and thus the workaround shouldn't be needed.
References: PCF-1168
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
This reverts commit 65b6e4b990 as the
issues should be fixed and thus the workaround shouldn't be needed.
References: PCF-1252
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
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>
The default behavior is changed. We don't want to respond to ping6 WAN requests anymore.
This reverts commit 0dd60b27eb.
Signed-off-by: Matthias FRANCK <matthias.franck@softathome.com>
There is now dedicated LCM data partition mounted under /lcm which is
not cleared up after each test, thus containers used in previous tests
persist during the DUT reboot and flashing procedure, violating test
imdepotence and making consecutive test fail.
So lets fix it by clearing up the LCM data partition during DUT firmware
flashing procedure, clearing just ext4 filesystem metadata, not erasing
complete 3 GiB and saving some time.
20 0x000f6800 0x006f67ff "lcm_data"
attrs: 0x0000000000000000
type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
guid: c5cde408-0b88-48ba-8701-eed060c51309
The 0xf6800 is the starting eMMC block of that partition and 0x400 is
eMMC erase group size, thus minimal size we can erase.
References: PCF-1101, PCF-1267
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
In commit 5bbd04eaa4 ("PROVISORY: ci: cdrouter: attempt to workaround
NTP sync issues") we've increased CDRouter test startTimeout from 90 to
180 seconds, but it turned out to be not enough, so lets increase
CDRouter startTimeout even further to 360 seconds and see how it
goes.
References: PCF-1168, PCF-1257
Suggested-by: Vincent Harle <vincent.harle@softathome.com>
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
(cherry picked from commit abcb4d2126)
Currently obuspa get Device queries take an increasing time with every
query. This causes CDRouter USP tests to timeout.
Let's increase the USP message timeout until a proper fix is introduced.
References: PCF-1252
Suggested-by: Vincent Harle <vincent.harle@softathome.com>
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>
(cherry picked from commit 4f3dd6db11)
Currently we're experiencing some NTP time sync issues:
54.82 - IP interface wan has ipv4address = 10.0.0.2 (IP.Interface.2.Status = Up, IP.Interface.2.IPv4Address.1.Status = Enabled)
...snip...
59.64 - Router main has gateway ipaddress = 10.0.0.1
...snip...
113.35 - Time Client cpe-client-1 is Synchronized
114.45 - Time Client cpe-client-1 is Unsynchronized
...snip...
174.46 - Time Client cpe-client-1 is Synchronized
NTP sync was achieved at May 7 11:50:50
May 7 11:50:50 prplOS obuspa[2025]: resolved_path_results {
May 7 11:50:50 prplOS obuspa[2025]: resolved_path: "Device.Time."
May 7 11:50:50 prplOS obuspa[2025]: result_params {
May 7 11:50:50 prplOS obuspa[2025]: key: "Status"
May 7 11:50:50 prplOS obuspa[2025]: value: "Synchronized"
May 7 11:50:50 prplOS obuspa[2025]: }
May 7 11:50:50 prplOS obuspa[2025]: }
and within 3 sec testing is stopped
May 7 11:50:53 prplOS CI: Testing finished, up 5 minutes
Looks like chronyd was able to get time sync from 3 sources:
May 7 09:00:54 prplOS chronyd[2953]: Selected source 3.3.3.7 (1.europe.pool.ntp.org)
May 7 11:49:45 prplOS chronyd[2953]: Selected source 3.3.3.6 (0.europe.pool.ntp.org)
May 7 11:49:50 prplOS chronyd[3916]: Selected source 3.3.3.7 (1.europe.pool.ntp.org)
OBUSPA polls Device.Time.Status every 10sec, query at 11:50:40 returns status as Unsynchrozied
May 7 11:50:40 prplOS obuspa[2025]: resolved_path_results {
May 7 11:50:40 prplOS obuspa[2025]: resolved_path: "Device.Time."
May 7 11:50:40 prplOS obuspa[2025]: result_params {
May 7 11:50:40 prplOS obuspa[2025]: key: "Status"
May 7 11:50:40 prplOS obuspa[2025]: value: "Unsynchronized"
May 7 11:50:40 prplOS obuspa[2025]: }
Thus status was not updated atleast till 11:50:40.
So lets increase current CDRouter startTimeout from 90 to 180 seconds
and see how it goes.
References: PCF-1168
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
(cherry picked from commit 5bbd04eaa4)
Current CDRouter tests are not passing due to the following issue:
FAIL: The USP agent failed to acknowledge the initial USP message, resulting in the error: "unable-to-start-connection-to-usp-agent".
The failure is occurring because the device is unable to obtain NTP
time. The status of Device.Time is listed as Error_FailedToSynchronize.
Under task PCF-1104, OB-USP-A is configured to withhold attempting
connections to the ACS until essential USP services like DeviceInfo. are
registered, the WAN connection is established, and NTP time is
successfully synchronized. In this scenario, the NTP time has not been
synchronized, which is causing the error.
So lets unblock this by enabling the NTP time synchronization by using
the default/pre-configured prplOS 0.europe.pool.ntp.org and
1.europe.pool.ntp.org NTP servers.
References: PCF-1104
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
(cherry picked from commit 568acaccf8)
Extend currently used default CDRouter-USP-Certification package (78
tests) with additional tests:
* usp_basic_1 - Verify that the Agent supports the Get message
* usp_basic_2 - Verify that the Agent supports the GetSupportedDM message
* usp_basic_3 - Verify that the Agent supports the GetInstance message
* usp_basic_4 - Verify that a subscription can be added, modified, and deleted on the Agent
* prpl_hl-api.1.1 - Profile GetSupportedDM
* prpl_hl-api.1.2 - Profile Parameters Write
* prpl_hl-api.1.3 - Verify prpl TR-181 Profile using GET
* prpl_hl-api.1.4 - Verify prpl TR-181 Profile using SET
* prpl_hl-api.1.5 - Verify prpl TR-181 Profile using Add and Delete on all creatable objects
To make the distinction clear, lets rename the package to CDRouter-USP-prpl.
References: PCF-1095
References: https://support.qacafe.com/cdrouter/user-guide/cdrouter-prpl-hl-api-user-guide/
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
(cherry picked from commit b29ee20bde)
OB-USP-A has following configuration in its factory reset database:
Device.LocalAgent.MTP.1.STOMP.Destination "/queue/agent-1"
So lets change the CDRouter's configuration accordingly.
References: PCF-1095
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
(cherry picked from commit 9e288988c0)
With the platform update to ATH 12.4.0 CS based on 6.1 kernel, we're
experiencing different behavior to previous release ATH 12.2.0 CS based on 5.4
kernel, where the serial console prompt detection takes a bit longer and
sometimes we hit the login timeout of 60 seconds. So lets fix it by
adjusting the timeout slightly to 75 seconds as currently the longest
time experienced was 73.386 seconds.
References: PCF-1177
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
(cherry picked from commit 0564d1db50)
Currently Aquantia PHY initialization is broken in kernel, leading
either to very long firmware loading time or broken networking.
Tim Hsu proposed workaround, where Aquantia PHY is initialized in
U-Boot, for that `aq_phy_reset` command was added to U-Boot and present
in U-Boot 2016.01.03-prpl release[1]. The workaround resets the Aquantia
PHY in U-Boot and loads the firmware as well, so Linux kernel does not
need to perform this steps.
1. https://gitlab.com/prpl-foundation/platform/qualcomm/u-boot-qca-freedom/-/releases/2016.01.03-prpl
References: PCF-1177
Suggested-by: Tim Hsu <Tim.Hsu@wnc.com.tw>
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
(cherry picked from commit aef94937eb)
* rename filenames due to generic subtarget introduction
* wireless-freedom: add the configuration of static phy number and phy detection time
* wireless-freedom: set vendor wireless uci only after the uci file is ready
* mac80211-qca: attach guest vap to br-guest
* mac80211-qca: disable ath12k cold_boot_cal
* mac80211-qca: ath12k-validate data length before copying data
* ipq95xx: Do not reset AQR PHY when booting
* ipq95xx: update codebase to ATH12.4.0CS
* aq_phy: Do not download AQR PHY firmware if it is ready by bootloader
References: PCF-1176
Signed-off-by: Marvin Lu <marvin.lu@wnc.com.tw>
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org> [squash, commit facelift]
(cherry picked from commit 776aa2bdd5)
Commit a60e06aee2 ("PROVISORY: version.mk: keep OpenWrt for
VERSION_DIST_SANITIZED") was not backported to prpl/nightly as it was
meant to be part of prplOS 3.y releases only, thus basically we need to
finish the configuration of prplOS re-branding and change all occurences
of `openwrt-` distribution name to `prplos-`.
References: PCF-691
References: a60e06aee2 ("PROVISORY: version.mk: keep OpenWrt for VERSION_DIST_SANITIZED")
References: e63487b1ee10 ("profiles: prpl: integrate configuration options for prplOS branding")
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
Add mxl25641-hdk-6 aka OSPv2 board with ethernet WAN uplink so we can QA
this new board.
References: PCF-1136
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
Update mxl_wlan_hostap_ng profile for below changes:
* bump to version WLAN6.2.2.65
Update mxl_x86 profiles for below changes:
* bump to version updk_9.1.50
* Enabled Maxlinear Multicast modules
* Enabled MaxLinear kernel speedtest module
* TC based QoS-SP, WRR, Q Shaping, DT, WRED
* Emmc flash partition layout now supports manufacturing data, LCM partition and separate rootfs data partition.
* prpl Standard Flash layout v1.0 compliance is work in progress, tracked in PCF-1101
* LCM partition is added to Emmc flash
* LED nodes for MxL OSP platform are enabled
* An additional 4 GB DDR U-Boot configuration is added
Signed-off-by: Bhavesh Bharadiya <bnbharadiya@maxlinear.com>
Signed-off-by: Petr Štetiar <ynezz@true.cz> [testbeds, test fixes]
Add prpl-haze-emmc so we can flash prplOS into eMMC flash storage using
sysupgrade image directly from the U-Boot bootloader.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
New obuspa package was just added, thus we need to QA it on CI to
prevent regressions, so lets enable CDRouter testing stock using
CDRouter-USP-Certification package.
References: PCF-1005
Signed-off-by: Petr Štetiar <ynezz@true.cz>
New obuspa package was just added, thus we need to QA it on CI to prevent
regressions, so lets make CDRouter aware, that the CPEs support USP over
STOMP protocol.
References: PCF-1005
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Currently we've experiencing following issue:
Test cdrouter-342: Verify L2TP over IPSEC session passes through router
SECTION(cdrouter-342): Attempting to establish L2TP tunnel
FAIL: L2TP tunnel setup failed
Vincent found out, that issue is due to loss of the IPSEC tunneling
because the DUT start leaking LAN client IP on the WAN, where In WAN
capture one can see ESP packet suddenly changing from source
202.254.1.2 to 192.168.1.94.
The issue is currently not manifesting on other targets, so it looks
like target specific, so lets disable the test case on URX851 target.
References: PCF-971
Suggested-by: Vincent Harle <vincent.harle@softathome.com>
Signed-off-by: Petr Štetiar <ynezz@true.cz>