I'm building my first serious networking project: an ARP scanner in C++ while studying computer networks. I understand the theory fairly well, including ARP, Ethernet frames, and MAC and IP addresses, but I'm still new to Linux and systems programming, so the implementation feels unfamiliar.
I've been using AI as a tutor rather than copying code blindly. My process is to learn a concept, examine an implementation, question every unfamiliar part, understand why it exists, and then connect it back to the networking theory. For example, I'm trying to understand why certain headers are needed, what sockets and file descriptors are, why socket() returns an integer, how raw sockets differ from regular sockets, what a network interface represents, why AF_PACKET is used, and how C++ structures map to actual Ethernet and ARP packets.
The networking concepts make sense to me; the difficult part is connecting those concepts to low-level Linux code. Is this a reasonable way to learn, or should I be writing more of the implementation from scratch before looking at examples? I want to understand every major part of the program instead of merely ending up with a working scanner I can't explain.
4 Answers
Don’t avoid implementation entirely, but don’t treat struggling to invent every line as a requirement either. Read the relevant Linux manual pages and small, reputable examples, then close them and reproduce the idea in your own code. Be especially careful with AI-generated networking code: verify constants, structure layouts, byte order, permissions, and error handling against official documentation.
The questions you’re asking are exactly the kind that help bridge theory and practice. The important change is to focus less on reverse-engineering a complete scanner and more on building tiny experiments: open a socket, inspect its return value, list interfaces, send one frame, receive one frame, and print the bytes. Each experiment should answer one question before you combine them.
Using AI as a tutor can be useful, but it’s risky if it supplies most of the implementation. Try to write a small piece yourself first, even if it’s incomplete, and then use AI or documentation to explain a specific error or concept. That forces you to form your own mental model instead of only recognizing code after someone else has written it.
That makes sense. My main difficulty is knowing what code should come next, so I’ll try breaking the project into much smaller pieces and predicting each piece before checking an explanation.
Projects are a good way to learn, but they work best when the scope is staged. Start with ordinary UDP or TCP programs so sockets and file descriptors become familiar, then move to packet capture, interfaces, Ethernet headers, and ARP. You can still study the ARP scanner now, but expect to pause and learn several Linux concepts that aren’t strictly networking theory.
I like the idea of separating the project into experiments. A complete implementation has been overwhelming because I can’t tell which parts are essential and which are just supporting code.