Through guided, hands-on project work, the SONiC Mentorship Program helps new contributors turn technical challenges into real-world open source impact.
In this spotlight, we speak with Zichen Zhang, an undergraduate Computer Science student at Shanghai Tech University, about his work building a new Console Mirror capability for SONiC that enables operators to record serial console traffic without interrupting an active session.
About the Mentee
Zichen is an undergraduate student majoring in Computer Science at Shanghai Tech University.
He joined the LFX Mentorship Program to gain hands-on experience contributing to a large open source networking system and to apply his academic knowledge in a real-world engineering environment. The program also gave him the opportunity to learn directly from experienced developers in the SONiC community.
Q: What project did you work on, and why is it important to SONiC?
I worked on Mirror Serial Console Traffic in SONiC.
SONiC can act as a terminal server through its console-switch functionality, allowing operators to manage the serial consoles of connected devices. The challenge is that serial console sessions are exclusive: when one operator is connected to a line, other users cannot see what is happening.
That can make troubleshooting difficult. Ethernet traffic has familiar tools such as tcpdump, but SONiC previously did not have a comparable way to observe serial console traffic without taking over the session.
Console Mirror addresses that gap.
Using consutil mirror, an administrator can begin recording traffic on a selected console line while the existing console user remains connected and continues working normally. The per-line console proxy creates a copy of the traffic and stores it in a protected local recording for later troubleshooting and analysis.
Q: What were your main technical contributions?
My work covered the feature from design through implementation and automated testing.
I first developed and refined the Console Mirror high-level design. One important architectural decision was to preserve SONiC’s existing console model: the per-line proxy remains the only process that owns the physical serial device.
Around that existing path, I introduced four internal components:
- MirrorManager for managing session state
- RecordingWriter for asynchronous file output
- RecordingArchiver for background ZIP creation
- MirrorControlServer for privileged local control through a Unix domain socket
I also designed a line-oriented recording format that stores both traffic payload and useful metadata for each record. Unprintable characters are handled safely, which makes recordings easier to inspect using familiar tools such as grep.
On the host-service side, I implemented RX and TX recording in the console proxy, bounded writer queues, file rotation, automatic timeouts, and asynchronous archiving.
A key design goal was to make sure recording never interferes with the serial forwarding path. The writer therefore runs separately from console traffic forwarding. If its queue becomes full, mirror records may be dropped and the loss is noted later, but the active console session continues without waiting for disk I/O.
I also designed archive creation to fail safely: the system creates a temporary archive first and only removes the source log segments once the final archive has been created successfully.
In addition, I implemented the command-line interface for using the feature and wrote a sonic-mgmt test plan and hardware-oriented automation to validate the functionality on real equipment.
Q: What challenges did you face, and what did you learn?
The biggest technical challenge was concurrency.
A manual stop, timeout change, automatic timeout, writer failure, or proxy shutdown can all happen close together. The system has to handle those events without closing a writer twice, leaving stale state in STATE_DB, or allowing an old timer to accidentally stop a new mirroring session.
I learned to think about the lifecycle as a state machine and to use locking carefully around shared resources to avoid race conditions.
Security was another important consideration because console recordings may contain sensitive information.
That meant making sure recording files were appropriately protected and that the control interface was accessible only to privileged users. Through that work, I gained experience with Unix file permissions, secure socket communication, and input validation.
More broadly, the mentorship taught me that a production feature involves much more than the primary success path. Clear protocol contracts, documentation, unit tests, failure handling, and realistic testbed validation are all part of building the feature itself.
Q: What impact has this mentorship had, and what are your next steps?
This project gives SONiC operators a practical new serial-console troubleshooting capability.
It makes it possible to capture both what a managed device sends and what an active console user types, then investigate that interaction after an incident occurs.
For me personally, the mentorship connected several areas I had previously encountered separately. I gained experience working across SONiC’s multi-repository development model, translating requirements into an architecture, integrating a CLI with a long-running system service, writing concurrency-aware Python, and designing tests for real serial hardware.
Community review was also a major part of the process and helped improve the design iteratively.
The next phase of the project could add capabilities such as:
- CTS/RTS mirroring
- Encrypted recordings
- Remote control through gNOI
Q: Is there anyone you’d like to acknowledge?
I’d like to thank my mentor, Zhijian Li, and the SONiC community reviewers for their guidance throughout the project.
Their feedback helped transform the original idea into a more complete design and encouraged me to think carefully about compatibility, failure handling, and testability—not just the basic functionality.
I’m also grateful to the maintainers and contributors across the SONiC project. Their existing work and review discussions gave me the context I needed to understand the console architecture and integrate the new feature across its different layers.
Finally, I’d like to thank the Linux Foundation, SONiC Foundation, and LFX Mentorship Program support team, especially Evan Harrison, for the guidance and support provided throughout the mentorship.
Get Involved
Interested in contributing to SONiC? Join the community and get involved through the SONiC wiki, mailing lists, working groups, and mentorship opportunities.
