Troliver

stories of war between boy and machine

Progress update: network mapping tool thing

The last 6 months have become very busy, so I decided to take a break from the breaking (and fixing) of our servers and get back to the program I’ve been working on to map network information (for which I still have no real name for).

Progress had been going quite well; by around December last year, I had worked out:

  • How to identify and store system information (adapters, MAC address, IP address, hostname)
  • How to import configuration settings to determine which network adapter a capture should be opened for
  • How to open a capture on a specific system adapter and capture one packet that is either LLDP or CDP
  • Dissect the packet further and extract the VLAN and Switchport ID
  • Upload all of this data as a string to a database and store it in a table
  • Display all the table data

 

 

Eventually, I figured I would try it out on our clients. I used a FOG snapin to push the program out to all the clients, and within 5 minutes, all PCs that were turned on had managed to deploy the snapin and upload their results to my database.

results1

 

It was a great feeling – suddenly seeing a hodge-podge of a program that ran on just one or two desktops now actually returning actual information (the IPs are fine, just anonymised for the post). It managed to acquire about 150 or so sets of information, so here’s the thoughts from this:

  • Hostnames look fine
  • IPs are fine
  • Dates are fine
  • VLANs are nearly all wrong
  • Switchport IDs are.. mostly ok. Lots seem wrong though
  • MAC addresses and switch IPs I have to include sometime
  • All computers need to have WinPcap installed

One thing to do for the future, which would be cool, is to see if I can create a single executable with all the code it needs to do packet capture without relying on a packet capture driver being already installed on the system. Is that even possible?

The other thing that needs to be done is to sort out the VLAN and switchport information – the cause of some of the apparently malformed is that I’m currently “guessing” where the packet data is, based on packets that I had seen from the computer I was working on and had pulled apart in Wireshark:

results2

 

I knew this would be an issue, however, since data lengths are variable, depending on the size of some of the information (switch name, IP and port ID can all be different lengths). So to fix this, I need a way to read the entire packet and work out what exactly is at which point; luckily, both LLDP and CDP packets use TLV formats – that is, each consecutive sets of bytes within the packet are all logically separated into Type, Length and Values. You can’t tell from a random location what that information is, however, so you absolutely must read the entire packet in and determine what the type is, followed by its length and then finally you can get an entire set of data as the value (usually).

Today has been spent working on that and I’m nearly done – so a next post will break it down!

, ,

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.