Internet tools

The NETTOOLS project is an example of how to interface with Microsofts ICMP.DLL and INETMIB.DLL.
These somewhat documented DLLs are supplied by Microsoft to allow MSs DOS
programs PING, TRACERT and NETSTAT access to the low-level IP header and MIB information.
Since MSs Winsock implementation does not support RAW sockets they had to create this API
For themselves. Thanks to many hackers with nothing else to do we too can use the API.
MS does say It Will Go Away" so keep this in mind!

PING/TRACERT

The PING and TRACERT code is implemented as an MFC thread. The main app
Creates and Starts the thread when the app is started. The thread then just sits
There and waits for the app to POST a request. Once the operation is started
The thread posts a message back to the app for each line of output to be displayed
In the main apps LISTBOX. A structure is used to pass information from
The PING/TRACERT dialog box to the thread. The reason for the thread
Is the ICMP.DLL. It uses the ASYNCH calls to Winsock. If you didnt
Process the DLL calls in a thread the user would be HourGlassed! The thread
Also allows the user to cancel the request.

Info on ICMP.DLL can be found in the SDK. You can download the Platform
SDK additional component section or you can find it on the Internet at
Various sites.

The Pingthread.cpp and .h files contain all the code to handle PING and
TRACERT requests. Pingparmlist.h contains the structure for passing
The parameters.

Nettools.h

Contains the define statements for the user messages being used by the Threads.

Mainfrm.h

Contains function prototypes for the user messages and Allocates the thread class and the parmlist Structure.

Mainfrm.cpp

Contains the code to process the messages from
The thread creates the events that are used to start and stop the thread, create the thread, starts and stops the thread.

The way the thread works is a little strange, plus I was just learning how to
Do threads when I wrote this. I used EVENTS to Initiate and Terminate the
Thread via the Frame. The thread itself uses windows user messages to
Post back the data from the operation.

The mainfrm constructor creates the events then creates a new thread.
The thread classes start function is then called. If the thread is created
The thread waits for the app to set the StartPing event. This tells the
Thread to wake up and process a request. The app then goes about its
Business until the thread posts a USER message back.

Pingthread.cpp

CpingThreadProc

a global function that IS the THREAD. Wait to be started. If started were We also asked to die, if not then process A TRACERT or PING. Post msg when done. Go back to sleep (waiting for start event).
Set the PingDead event if we were asked To die.
(in this case at app termination).

Start()

call the CreateThread and InitInstance functions. InitInstance starts Winsock this is required prior to using the ICMP.DLL plus the thread is also making Winsock calls to resolve Hostnames and addresses. Then load ICMP and store the address of the functions being Used.

Icmp_SetOpts()

Sets up the IP options for ICMP. The IP options are basically the same values used in an IP header.

ProcessReply()

Does just that. It breaks up the ICMP reply plus
any network info returned. I.e. route info

~CpingThread

Does Nothing but must be changed to Public in the
Class header file. App wizard makes it private.
It must be public in order to delete the thread.

Cleanup()

Deletes the DLL and stops Winsock.

CpingThread(Pingparms)

The Threads overloaded constructor set a pointer
To CpingThreadProc,Sets autodelete to false and sets
A pointer to parm list. After the constructor is called
The thread class now knows where the Thread process
Function is.

Kill()

Cancels the PING or TRACERT request without terminating the thread. A BOOL is set to TRUE. The other thread functions test this value after every async request

NETSTAT

The NETSTAT utility uses the INETMIB1.DLL supplied with NT. The MIBs are used
To provide Statistical information for IP. By using INETMIB1 there is no need to
Install the SNMP manager in order to get the Stats. The SNMP API is fully documented
And useable after SNMP is installed on the machine. The supplied INETMIB however
Is not documented. The Inet thread is done in the same fashion as the Ping thread.

InetThread.cpp - Contains the code to implement the INETMIB1.DLL as a thread.

CinetThreadProc

IS the thread procedure.

CinetThread(inetparms)

Sets up the pointer to the thread proc and turns off the Auto delete option.

~CinetThread()

Does nothing but it must be define as public to allow delete to be used.

InitInstance()

Loads the DLL and set pointers to its functions.

RunInet()

Determines which options are passed and calls the
Corresponding function.

Cleanup()

Called to delete the DLL and close Winsock.

Kill()

Terminates the request while keeping the thread alive.

The actual processing of the MIB data is well beyond the scope of this document.
The best way to understand it is to look at the code while reading through the reference
Information.

The SMNP extension functions used in the INETMIB1.DLL are documented
In the MSDN library. This undocumented DLL just so happens to use the
Same function names and format of the basic functions for SNMP. However
The real SNMP DLL supplied when SMNP manager is installed contains
A richer API.

Reference materials used:

Microsofts SMNPUTIL.EXE. This program is available from Microsoft in source format.
It requires that SMNP manager be installed on the machine. Its a DOS Based program that
Will dump the MIBs to the screen so you can get an idea of how they look and let you practice
Navigating through the MIB tree before writing the code that processes them.

The Goal behind writing this program was to learn MFC thread processing and at the same
Time learn a little about TCP/IP. Both topics could fill a book in themselves.
I think what I really learned here is perseverance. It took a lot of time and study
To get this working and I ended up with a very very simple program that demonstrates
The basics for learning how TCP works.

Top White Papers and Webcasts

U.S. companies are desperately trying to recruit and hire skilled software engineers and developers, but there is simply not enough quality talent to go around. Tiempo Development is a nearshore software development company. Our headquarters are in AZ, but we are a pioneer and leader in outsourcing to Mexico, based on our three software development centers there. We have a proven process and we are experts at providing our customers with powerful solutions. We transform ideas into reality.

When individual departments procure cloud service for their own use, they usually don't consider the hazardous organization-wide implications. Read this paper to learn best practices for setting up an internal, IT-based cloud brokerage function that service the entire organization. Find out how this approach enables you to retain top-down visibility and control of network security and manage the impact of cloud traffic on your WAN.