Finding an IP Address

Have you ever been in a situation where you know the physical address, i.e. MAC address, of a local network device but not its IP address? This post tells you how to go about to find that elusive address. The instructions below are for Windows but is easily ported to any OS, since the tools used are ubiquitous.

1. Create a batch file pingsubnet.cmd that contains the following statement

2. @FOR /L %%h IN (1,1,255) DO @ping -n 1 %1.%%h
   

   This will loop from 1 to 255 to send a single echo request to the IP addresses you get from concatenating the subnet parameter and the for loop variable (%1.%%h). This assumes that the subnet is a class C subnet.
3. Execute pingsubnet for your subnet.
4. Execute the following command

   arp -a > arp.txt
   

   The command arp, which name stands for Address Resolution Protocol, will list the IP address and MAC address of every local network device you've communicated with.
5. Open the file arp.txt and search for the MAC address of the device  with an unknown IP address.
6. Having found the MAC address you have also found the IP address!

Testing the interior

What impact will your choice of software development processes have on your software design? The question is of course impossible to answer if asked out of context. However, it is obvious that a given process may have a desired impact, reflecting the goals of the process itself, as well as an undesired impact, should the goals of the process interfere with other design goals. In Encapsulation and testability Alexander Tarnowski blogs on TDD in relation to the OO concept of encapsulation, pointing out that a desire to make software testable may interfere with a desire to make software adhere to encapsulation.

When designing for testability there are two separate domains of software to design, the code to be tested and the code that tests. In his blogpost Alexander elaborates on the necessity to make the interior of code (i.e. parts that normally would have private or internal visibility) public, in order for it to be testable. While I agree on the central issue that testability is more important than encapsulation, it is still a case of TDD design goals interfering with OO design goals.

Now, what if we - instead of asking what to do about code to make it testable - turn around and consider how to design testing code with an ability to test interiors? Of course, the obvious solution (illustrated below) is to place test classes responsible for testing code with internal visibility inside the project containing the code to be tested, and likewise, test methods responsible for testing code with private visibility inside the containing class.

A major flaw in the above method to test the interior is that your executables will contain test code. While it is possible to avoid this using preprocessor directives, testing should really be handled by the compiler, IDE and testing framework analogous to the way compiler and IDE handles debugging.