…-net#21062)

[smart-switch][dpu] Do not run dhclient on the eth0 interface.

…D automatically (sonic-net#21165)

#### Why I did it
src/sonic-platform-daemons
```
* 60e7224 - (HEAD -> 202411, origin/test_202411_20, origin/test_202411_100, origin/kperumal_202411, origin/202411) thermalctld: Add support for fans on non-CPU modules (sonic-net#555) (11 days ago) [Patrick MacArthur]
```
#### How I did it
#### How to verify it
#### Description for the changelog

…ically (sonic-net#21163)

#### Why I did it
src/sonic-dbsyncd
```
* b0ea01f - (HEAD -> 202411, origin/test_202411_20, origin/test_202411_100, origin/master, origin/kperumal_202411, origin/HEAD, origin/202411, master) [lldp]Fix the issue of only one field lldp_rem_time_mark in APPL_DB (sonic-net#71) (13 days ago) [Zhaohui Sun]
```
#### How I did it
#### How to verify it
#### Description for the changelog

sonic-net#21162)

[202411][submodule] Update submodule linkmgrd to the latest HEAD automatically (sonic-net#21162)

…tomatically (sonic-net#21164)

[submodule][202411] Update submodule sonic-linux-kernel to the latest HEAD automatically

…tically (sonic-net#21166)

[submodule][202411] Update submodule sonic-sairedis to the latest HEAD automatically

…omatically (sonic-net#21168)

[submodule][202411] Update submodule sonic-swss-common to the latest HEAD automatically

…atically (sonic-net#21169)

[submodule][202411] Update submodule sonic-utilities to the latest HEAD automatically

FRR 10.0.1 upgrade (sonic-net#20269) brought in a mgmtd daemon for FRR. This needs to be started up in docker-sonic-vs as part of the other daemons in this container.

Additionally, Debian Bookworm provides version 2.5.0 of scapy, but the pip3 command later in the file downgraded it to 2.4.5, which does not work in Bookworm. Fix this by removing the pip3 installation for scapy, and updating the other packages installed via pip3.

Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com>

Initial 202411 release

Signed-off-by: Anand Mehra anamehra@cisco.com

Why I did it
dhcp_relay/test_dhcp_relay_stress.py::test_dhcp_relay_stress[offer|ack] tests are failing on dualtor topologies with signature Failed: /tmp/dhcp_stress_test_offer.json is missing, see issue aristanetworks/sonic-qual.msft#325 for more details.

Work item tracking
Microsoft ADO (number only):
How I did it
count_matched_packets method is getting stuck in a while loop as long as ptf server port receives any packet (Ex: in dualtor case, we do see continuous ICMP packets on ptf port). Fix is to consider only expected packets w.r.t timeout (similar to count_matched_packets_all_ports logic).

How to verify it
With this PR changes we should not see dhcp_relay/test_dhcp_relay_stress.py failures on dualtor topologies with symptom Failed: /tmp/dhcp_stress_test_offer.json is missing.

…00 SKUs (sonic-net#21228)

…pported for modules that does not support this API (sonic-net#21196)

… and SKUs (sonic-net#21056)

…c-net#21135)

… align with bookworm libasan (sonic-net#21134)

… of ifps (sonic-net#21095)

…onic-net#21079)

…N5600-C224O8 SKU (sonic-net#20992)

…ulations (sonic-net#20991)

…ation (sonic-net#20754)

…-net#19982)

…ic-net#21283)

…c-net#21298)

…t#21305)

…nic-utilities sonic-platform-common sonic-sairedis sonic-host-services sonic-linux-kernel

…scenarios (sonic-net#21199) (sonic-net#110)