fix(console): skip extra newline after username in login_stage_2()

[lipxu]

Description

SSHConsoleConn.login_stage_2() has an unconditional write_channel(self.RETURN) at the bottom of every loop iteration. After sending the username, the next loop iteration reads the terminal echo of the username ("admin"), which matches neither the login-prompt pattern nor the Password-prompt pattern — so all if branches are skipped and the unconditional write_channel(RETURN) fires, sending a blank newline to the DUT before Password: is shown.

The DUT receives the blank newline as the password → authentication fails → Linux pam_faildelay enforces a 3-second mandatory delay → the test framework times out → socket closes. All 3 retry attempts fail the same way.

dut_console/test_escape_character.py had a 2.6% pass rate (out of 11,323 runs over 30 days) due to this bug. Rare passes happen only when network timing causes the real password to race ahead of the accidental blank Enter.

Root Cause

The loop-bottom write_channel(self.RETURN) is intended to wake up the terminal when no pattern is matched (e.g., before the login prompt appears). It should only fire while waiting for the username prompt, not after the username has been sent:

# login_stage_2() — before fix
if not user_sent and re.search(username_pattern, output, flags=re.I):
    self.write_channel(username + self.RETURN)
    ...
    user_sent = True
    # next iteration reads "admin" echo — matches no pattern — falls through to:

self.write_channel(self.RETURN)   # ← sends blank \n as accidental password

Fix

Guard the loop-bottom write_channel(RETURN) so it only fires when still waiting for the username prompt:

if not user_sent and re.search(username_pattern, output, flags=re.I):
    self.write_channel(username + self.RETURN)
    ...
    user_sent = True
# username echo iteration and all subsequent iterations skip the blank CR:

if not user_sent:                   # ← fix: only wake up terminal before username is sent
    self.write_channel(self.RETURN)
time.sleep(0.5 * delay_factor)
i += 1

Verification

Manually confirmed on bjw-can-7060-1 via console (bjw-can-e1031-2, line 27):

• Sending empty Enter at Password: prompt → ~3 seconds silence → "Login incorrect" (pam_faildelay)
• Normal login with correct password → shell in under 1 second
• DUT PAM config: pam_faildelay.so delay=3000000

Re-run on vms11-t0-7060-cx32-1 with partial fix confirmed the terminal-echo-iteration is the remaining bug (log showed write_channel: b'\n' between username and password).

https://elastictest.org/scheduler/testplan/69c3c20fa32086e7e883bc08

Type of change

• Bug fix

Tested

• Pending test run on testbed with the corrected fix

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[yxieca]

AI agent on behalf of Ying. Reviewed; no issues found.

[mssonicbld]

Cherry-pick PR to 202511: #23362