It may sound basic but if you want to get into networking, start with networking rather than with some specific tools.
I'm sure I've said this many times before, but in my opinion a tool should not be some "magic black box" that does something for you without you understanding how. You should be able to reproduce the same results by hand and only then use tools to make the process easier. If you really understand what a tool does and how it does it you can be sure you're using it right as well as not being dependent on the specific features that tool may or may not have implemented.
Of course this is entirely impractical in many cases, but the idea is you have the knowledge that would, in theory, enable you to do it by hand if you had enough time and documentation on hand. A good rule of thumb for me has been to think to myself if I would be able to write such a tool myself. (Again if you had the time of course.)
For some practical things on where you could start;
- The OSI model. It's rather useful to know what layer you're working on so you know what you can do in theory and what you can expect to find.
- Some common layer 2 protocols like Ethernet, ARP and VLAN.
- Some common layer 3 protocols like IPv4, IPv6, ICMP and GRE.
- Some common layer 4 protocols like TCP, UDP and BGP.
- If you're interested in the really low level stuff from layer 1, some really basic radio theory for WiFi and/or modulation and signalling stuff could be fun. But practically you probably won't need this unless you plan to use/make some really low level hardware stuff.
- For WiFi cracking stuff, some idea of how the different encryption mechanisms work is very useful.
- Don't take this for the gospel truth. It's just my ideas and experience of what I have found useful.
- Don't take this to mean I think you should know every detail about all this by heart. Usually a reasonable global understanding of how a system works is good enough. You can always look up any specific details when you need them.
Example; know that an IP packet has some headers and body, maybe what some of the main headers do, but you probably won't need to know every individual header, what order they are in and what byte sizes they are.