[cacl][test] Add coverage for caclmgrd-owned dhcp_server syslog rule

[Xichen96]

Description of PR

Summary:
Add explicit CACL coverage for the caclmgrd-owned dhcp_server docker0 syslog (RELP tcp/2514) INPUT exception. Ownership of this rule moved from the container start/stop script into caclmgrd, which re-emits it on every control-plane ACL flush-and-rebuild while FEATURE|dhcp_server is enabled, so it survives the rebuild (root cause of sonic-net/sonic-buildimage#27584).

New test test_caclmgrd_dhcp_server_syslog asserts:

1. the docker0 tcp/2514 ACCEPT rule is present above caclmgrd's control-plane catch-all DROP while the feature is enabled;
2. it survives a control-plane ACL flush-and-rebuild (the existing dummy_acl_rules fixture forces one via acl-loader);
3. it is removed on feature-disable and restored on feature-enable.

The test skips when dhcp_server is not enabled on the DUT (bridge-mode, host-namespace only; enabled by default on e.g. mx).

This is the optional coverage called out in #26470. It complements the expectation update in #26477.

Depends on #26477 (stacked). #26477 updates generate_expected_rules (udp/514 -> tcp/2514); this PR only adds the new behavioral test. Merge order is #26477 first, then rebase this PR, so the two never present conflicting expectations on the target branch.

Product change set this covers (all merged on master):

• [dhcp_server] Revert container-side docker0 syslog iptables add/del (#26637); caclmgrd to own the rule sonic-buildimage#28328 — remove the container-side add/del.
• [caclmgrd] Own the dhcp_server docker0 syslog INPUT exception sonic-host-services#412 — caclmgrd owns the rule.
• [dhcp_server] Wait for caclmgrd-owned docker0 syslog rule on start/stop sonic-buildimage#28580 — container-side feature-gated waits.

Fixes # (issue)
Related: #26470. ADO: 38902700 (parent PBI 38699922). Underlying bug: sonic-net/sonic-buildimage#27584.

Type of change

• Bug fix
• Testbed and Framework(new/improvement)
• New Test case
  • Skipped for non-supported platforms
• Test case improvement

Back port request

• 202311
• 202405
• 202411
• 202505
• 202511
• 202512
• 202605

Tracking issue/work item for backport/cherry-pick request (GitHub issue or Microsoft ADO): Microsoft ADO 38902700 / #26470
Failure type: day-one issue (the container-owned docker0 syslog rule never survived a caclmgrd control-plane ACL rebuild; this coverage follows the product change onto each branch it is backported to)

Tested branch

• master
• 202311
• 202405
• 202411
• 202505
• 202511
• 202512
• 202605
• N/A

Test result

The behavior asserted here (caclmgrd owns the docker0 tcp/2514 rule above the catch-all DROP, survives an ACL rebuild, toggles with the feature) was confirmed during the 3-PR hardware validation on bjw-can-720dt-2 (720dt, mx, 202605 image 20260510.07) by hand-patching the caclmgrd + container changes onto a running DUT. A full pytest run of this new case against a live DUT requires a test image that already contains the three product PRs above (submodule-propagated); until then the CACL path on the old image still programs udp/514. This is a source/test/image ordering dependency — the coverage merges in lockstep with the product change reaching the image.

Approach

What is the motivation for this PR?

test_cacl_application (updated in #26477) checks the static expected ruleset but does not exercise the ownership contract that #27584 is about: that caclmgrd re-emits the rule across a rebuild and tracks the feature toggle. This adds that behavioral coverage.

How did you do it?

Added test_caclmgrd_dhcp_server_syslog, reusing the dummy_acl_rules fixture to apply control-plane ACLs (which forces a caclmgrd INPUT flush/rebuild and the catch-all DROP). The test reads FEATURE|dhcp_server state via sonic-db-cli, skips when disabled, and otherwise checks rule presence/ordering, survival across the rebuild, and the disable/enable transitions, restoring the original feature state in a finally block.

How did you verify/test it?

python3 -m py_compile + repo pre-commit (flake8) pass. Behavior matches the hand-patched DUT observations from the 3-PR HW validation. Full suite run is gated on image propagation as noted in Test result.

Any platform specific information?

Host-namespace IPv4 INPUT rule; only runs where the dhcp_server feature is enabled (skips otherwise).

Supported testbed topology if it's a new test case?

Any topology with dhcp_server enabled (e.g. mx); skipped elsewhere. Module marker is topology('any', 'bmc').

Documentation

N/A.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

Adds a new CACL behavioral test to validate that the dhcp_server docker0 syslog exception (RELP tcp/2514) is owned by caclmgrd, is ordered above the control-plane catch-all DROP, survives a control-plane ACL flush/rebuild, and follows FEATURE|dhcp_server enable/disable transitions.

Changes:

• Add test_caclmgrd_dhcp_server_syslog to assert presence + ordering of the docker0 tcp/2514 ACCEPT rule while the feature is enabled.
• Reuse dummy_acl_rules to force a control-plane ACL flush/rebuild and verify the rule is re-emitted.
• Toggle dhcp_server feature to validate rule removal and restoration, with cleanup restoring the original feature state.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (1)

tests/cacl/test_cacl_application.py:1450

• This new test hard-codes the tcp/2514 dhcp_server_syslog rule, but elsewhere in this same file generate_expected_rules() still describes/expects the older docker0 syslog exception as UDP/514 and is gated on container presence (see around lines 581-586). If that earlier expectation isn’t updated (or this PR isn’t rebased onto the change from #26477), the file will have conflicting assumptions about the dhcp_server syslog rule and the overall CACL suite can become inconsistent across branches/images.

    dhcp_syslog_rule = ("-A INPUT -i docker0 -p tcp -m tcp --dport 2514"
                        " -m comment --comment dhcp_server_syslog -j ACCEPT")
    catch_all_drop = "-A INPUT -j DROP"

    orig_state = duthost.shell(

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

tests/cacl/test_cacl_application.py:1509

• The cleanup path waits for dhcp_server state/rule to converge back to the original value, but the return value of wait_until(...) is ignored. If the restore fails or never converges, the test can still pass and leave the DUT in a modified state, causing follow-on tests to be flaky. Please assert that the cleanup convergence actually succeeded.

            wait_until(

[mssonicbld]

This PR has backport request label(s) for branch(es): 202605, but is missing required test information. Please make sure you tick the tested branch(es) in the Tested branch section and provide test evidence (e.g., 202605: <test result>) in the Test result section as well in your PR description.

_{---Powered by SONiC BuildBot}

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

tests/cacl/test_cacl_application.py:1456

• The teardown fixture currently only waits for CONFIG_DB FEATURE|dhcp_server 'state' to match the original value. That key reflects desired config and may flip immediately after config feature state, so this doesn't guarantee the iptables rule/programming has converged; if the test fails mid-toggle, a transient rule/state can still leak into the next test despite the fixture's intent. Consider also waiting for the docker0 tcp/2514 rule presence/absence to match orig_state when restoring.

    cur_state = duthost.shell(
        "sonic-db-cli CONFIG_DB HGET 'FEATURE|dhcp_server' state",
        module_ignore_errors=True)["stdout"].strip()
    if cur_state != orig_state:
        duthost.shell("sudo config feature state dhcp_server {}".format(orig_state),
                      module_ignore_errors=True)
        pytest_assert(
            wait_until(
                60, 5, 0,
                lambda: duthost.shell(
                    "sonic-db-cli CONFIG_DB HGET 'FEATURE|dhcp_server' state",
                    module_ignore_errors=True)["stdout"].strip() == orig_state),
            "dhcp_server feature state did not converge back to {} during teardown"
            .format(orig_state))

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.