I'm building my first serious networking project: an ARP scanner in C++ on Linux. I understand much of the networking theory behind it, including ARP, Ethernet frames, MAC addresses, and IP addresses, but I'm still new to systems programming and Linux APIs.
I've been using AI as a tutor rather than blindly copying code. My process is to learn a concept, examine an implementation, question every unfamiliar part, and connect the code back to the networking theory. For example, I'm trying to understand why particular headers are needed, what sockets and file descriptors are, why socket() returns an integer, how raw sockets differ from ordinary sockets, what a network interface represents, why AF_PACKET is used, and how C++ structures map to actual Ethernet and ARP packets.
The main difficulty is bridging the gap between the theory and the low-level implementation. Is this a reasonable way to learn, or should I be writing more of the implementation from scratch before consulting examples or AI? I want to understand every major part of the program rather than merely producing a working scanner I cannot explain.
2 Answers
A working program produced quickly is not the same as learning quickly. Build smaller prerequisite exercises first: open and close ordinary sockets, inspect file descriptors, enumerate interfaces, serialize a simple structure into bytes, and capture packets for inspection. Once those pieces are familiar, the ARP scanner will be much easier to understand and you will be able to write more of it yourself.
The process you described is not useless, but starting from a finished implementation and reverse-engineering it is different from learning to design one yourself. Before looking at code, describe the steps in plain language and predict what the program must do. For example: choose an interface, construct an Ethernet frame, place an ARP request in its payload, send it, and inspect the response. Then implement one step at a time using official documentation and carefully chosen open-source examples.
I understand the distinction. I do not feel ready to build the whole program alone yet, so breaking it into smaller stages and using examples only for specific questions seems like a better approach.