Csc5113c Direct

My code was perfect. The math was solid. But my throughput looked like a flatline. After three hours of blaming the compiler, the kernel headers, and my own existence, I finally enabled promiscuous mode on the NIC. That’s when I saw it.

My server was talking to the client. But so was something else .

One week you’re coding a reliable data transfer protocol over UDP (think: TCP from scratch, but sadder). The next week, your lab partner is tasked with launching a selective ACK dropping attack against your implementation using Scapy.

CSC5113C won’t just teach you how networks work. It will teach you how they fail . And in doing so, it will make you one of the rare engineers who can actually defend them. csc5113c

Just don’t run your lab scripts on the university’s production VLAN. The network admin still sends the professor angry emails about "The Great Packet Heist of 2023." Final grade: A- (lost points for forgetting to close a raw socket). Worth it.

You learn fast. You learn that sequence numbers without crypto are just polite suggestions. You learn that "congestion" is often just malice. And you learn that tcpdump is the difference between an A and a sleepless incomplete. Ask any CSC5113C alumnus about ~/lab4/attacks/ . They’ll go quiet.

Lab 4 is the turning point. You’re given a PCAP file—a recording of a real (anonymized) corporate network breach. Your job: reconstruct the attacker’s steps using only packet analysis. No logs. No alerts. Just 30,000 packets and your sanity. My code was perfect

In CSC5113C, the network isn't a series of tubes. It's a gladiator arena. Most networking courses teach you the OSI model, TCP state diagrams, and BGP routing. You memorize port numbers. You calculate checksums. You yawn.

By the final project—where you must design a zero-trust microsegmentation policy for a mock cloud environment—you’re no longer thinking about bandwidth or latency. You’re thinking: If I were the attacker, where would I sit? Only if you enjoy the feeling of your certainties being unplugged.

The first time you see a DNS exfiltration tunnel—where someone encoded /etc/passwd into subdomain requests—it feels like magic. By the end of the lab, you realize it’s just math. Clever, terrifying math. After three hours of blaming the compiler, the

One student famously found a delayed SQL injection spread across 47 fragmented ICMP echo requests. The professor didn’t even know that was possible until the student presented it. "Don't trust the wire. Don't trust the endpoint. Don't trust your textbook." This isn't paranoia. It’s the course’s core thesis. The Internet was built on trust. Modern networks survive on verification.

I was debugging a "simple" TCP congestion control algorithm for my CSC5113C project. The assignment was straightforward: modify the Linux kernel’s TCP stack to improve throughput over high-latency links. Straightforward, until it wasn't.

There is a moment in every Computer Science graduate course where the textbook stops making sense and reality kicks in. For me, that moment came at 2:00 AM in the networking lab, watching Wireshark scroll by like the green code from The Matrix .

There, nestled between legitimate ACK packets, was a series of RST (reset) packets with a TTL that didn’t match the rest of the stream. Someone—another student in the class, probably working on the offensive security track—had quietly ARP-poisoned my subnet. They weren't stealing data. They were just injecting resets to watch my retransmission timer explode.

CSC5113C does something crueler—and far more educational. It forces you to implement the protocols, then immediately break them.