Posts on zhiwen.dev

network debugging tools

Fri, 16 Jan 2026 21:37:01 +0800

“This is supposed to work!”, as we told ourselves as we attempt to integrate multiple systems together.

Often in deployment environments, connections can fail unknowingly as we try to bring together complex systems and integrations across multiple network zones and dependencies. There are several tools that help you identify the critical point(s) of failure.

Tool	Answers	OSI / Stack Layers
`tcpdump`	What packets are actually on the wire?	L2–L7 (Packet-level visibility)
`ping`	Can I reach the host? Latency? Packet loss?	L3 (Network / ICMP)
`traceroute` / `tracert`	Where along the path does it fail?	L3 (Network)
`nc`	Can I connect to a raw TCP/UDP socket?	L4 (Transport)
`openssl`	Does TLS/session/handshake work correctly?	L5–L6 (Session & Presentation – TLS)
`dig`	Is DNS resolving correctly?	L7 (Application – DNS)
`curl`	Does the application respond correctly?	L7 (Application – HTTP/TLS)
`nmap*`	What ports/services are exposed?	L3–L7 (Discovery & probing)

I was hesitant in placing nmap in this list due to how often a tool like this would be quickly flagged by IDS/IPS systems. However, if your network or systems allow such a tool, nmap can be very powerful, extending beyond connectivity debugging, to advanced functions such as service and os fingerprinting.

what makes a great engineer

Mon, 15 Dec 2025 19:11:09 +0800

Lately, I’ve been thinking about what actually makes a great engineer. I’ve had an intuitive sense of it, but never managed to structure it clearly.

Earlier this week, I had a 1-to-1 session with my tech lead where we discussed topics surrounding performance, feedbacks and concerns. One of the conversations that stood out to me was him defining what makes a “great” engineer — aptitude, attitude, experience & environment.

I found this framing both simple and insightful. It took something abstract and made it tangible. It also gave me some inspiration — This post is my attempt to further unpack those qualities and add my own perspective.

a new blog

Sun, 23 Nov 2025 00:00:00 +0000

I enjoy writing documentations as I am “forced” to convert ideas into technical writing. Knowing these documentations will be consumed by other fellow engineers means I HAD to write in a maintainable and readable manner.

However, as an engineer who also has a homelab, I often struggle with writing documentation for my homelab. My homelab serves a single-digit number of users and there was only one maintainer - me, myself, and I. There wasn’t enough ROI to justify spending time writing any form of documentation for services I am running.