NetScanTools Basic was mentioned as number 5 of 15 recommended freeware network tools in the article "Most Wanted Network Tools 100% Freeware". See this blog:
http://www.sialnity.com/2010/04/most-wanted-network-tools-100-freeware/
Have a great week!
Kirk
Monday, April 26, 2010
Thursday, April 22, 2010
This application has failed to start...
Have you ever seen that message? You know, the one that says "This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem." (that's what it says on Windows XP - Vista and 7 have a more informative message). The message should read: Windows is missing important files that should have been downloaded through automatic updates -- oops!
What this usually means is that the Visual C++ redistributable fileset is wrong, either too old or missing one or more pieces. These are the Side by Side DLLs we are talking about. They reside in the C:\Windows\WinSxS directory and the have rediculously long names. Those names include the version of MFC, runtime, etc of the DLL. This problem happens most often when the compiler has a new revision, like last July 2009's revision of Visual C++ 2005.
Fortunately the fix is pretty simple. You have to find the Visual C++ redistributable installer that is missing and run it. It's installer takes care of the rest and it is a pretty fast fix. But you have to know which one to use. Our software installers look for signs that the SxS DLLs are there, then run the redist installer if they are not found. You may have to contact the software vendor to find out which one to use. Kind of a pain.
I'm posting this because one of our customers had this happen today. Fortunately he emailed and I was able to give him the link to the proper redistributable installer. It fixed his problem.
What this usually means is that the Visual C++ redistributable fileset is wrong, either too old or missing one or more pieces. These are the Side by Side DLLs we are talking about. They reside in the C:\Windows\WinSxS directory and the have rediculously long names. Those names include the version of MFC, runtime, etc of the DLL. This problem happens most often when the compiler has a new revision, like last July 2009's revision of Visual C++ 2005.
Fortunately the fix is pretty simple. You have to find the Visual C++ redistributable installer that is missing and run it. It's installer takes care of the rest and it is a pretty fast fix. But you have to know which one to use. Our software installers look for signs that the SxS DLLs are there, then run the redist installer if they are not found. You may have to contact the software vendor to find out which one to use. Kind of a pain.
I'm posting this because one of our customers had this happen today. Fortunately he emailed and I was able to give him the link to the proper redistributable installer. It fixed his problem.
Wednesday, April 21, 2010
Checking Authoritative DNS Serial Numbers
Did you know that Authoritative DNS servers consist of primary and one or more backup or secondary servers? Did you also know that they are supposed to be in sync?
It is important that the servers be in sync. Why? a record in the primary may be very different from the same record in the secondary - especially if it was just changed. A query might get the wrong information (like an IP) if the secondary returns the record instead of the primary. That's why it is important to sync them fairly quickly.
The DNS servers are listed when you do a 'whois' query for a domain. Most domains have only two, a primary and secondary. When changes are made to the primary, then they are migrated to the secondary so that if for some reason the primary does not respond to DNS queries, the secondary may continue to do so.
It is important to know if those primary and secondary servers are in sync. You can look at the SOA serial field to find out. Normally they are identical for all DNS servers. If they are not, then that indicates a problem. You can use NSLOOKUP to retrieve the SOA records from each DNS (primary and secondary). This is a tedious process if there are more than two servers to look at.
We have a tool in NetScanTools Pro that simplifies this process by doing the queries for you very quickly. That way you can see a quick snapshot of the DNS update situation. It is part of the DNS Tools - Advanced and it is called "Auth Serial Check".
Here in this example for our domain showing matching serials. Note that the program looks that them to make sure they are OK:
[Start Query]
Authoritative DNS Serial Check
Starting Timestamp: 04/21/10 17:00:28
Query: netscantools.com
NS: ns2.webnethost.net -- Serial: 2010020400
NS: ns1.webnethost.net -- Serial: 2010020400
Analysis: All serial numbers are identical, no problems detected.
[End Query]
And now here is a query showing microsoft.com's DNS serials. Note that certain DNS servers are out of date with others. "ns1" is the primary and the others are backup.
[Start Query]
Authoritative DNS Serial Check
Starting Timestamp: 04/21/10 16:44:23
Query: microsoft.com
NS: ns3.msft.net -- Serial: 2010042102
NS: ns5.msft.net -- Serial: 2010042101
NS: ns1.msft.net -- Serial: 2010042102
NS: ns4.msft.net -- Serial: 2010042102
NS: ns2.msft.net -- Serial: 2010042101
Analysis: One or more serial numbers are out of sync with the other serial numbers.
[End Query]
I checked again 15 minutes later and found that all DNS serials in the microsoft.com listing were the same. This is probably normal for a domain of this size because it may take awhile to transfer the zone updates from the primary to the secondaries. I checked the SOA record and I could see that the refresh interval is 5 minutes and the retry interval is 10 minutes, so their DNS should not be out of sync for long. It's unusual to see this, so I thought it would make a good example.
A note about the serial field formatting. These both conform to what is now recommended where the serial is human readable. In the case of microsoft.com, you can see that it is April 21 2010, update numbers 1 and 2. In the case of netscantools.com, you can see that the serial has not changed since February 4, 2010. Not all serials conform to this method. Some are just straight incremental numbers.
You can try out the Auth Serial Check tool in the NetScanTools Pro Demo at our website.
It is important that the servers be in sync. Why? a record in the primary may be very different from the same record in the secondary - especially if it was just changed. A query might get the wrong information (like an IP) if the secondary returns the record instead of the primary. That's why it is important to sync them fairly quickly.
The DNS servers are listed when you do a 'whois' query for a domain. Most domains have only two, a primary and secondary. When changes are made to the primary, then they are migrated to the secondary so that if for some reason the primary does not respond to DNS queries, the secondary may continue to do so.
It is important to know if those primary and secondary servers are in sync. You can look at the SOA serial field to find out. Normally they are identical for all DNS servers. If they are not, then that indicates a problem. You can use NSLOOKUP to retrieve the SOA records from each DNS (primary and secondary). This is a tedious process if there are more than two servers to look at.
We have a tool in NetScanTools Pro that simplifies this process by doing the queries for you very quickly. That way you can see a quick snapshot of the DNS update situation. It is part of the DNS Tools - Advanced and it is called "Auth Serial Check".
Here in this example for our domain showing matching serials. Note that the program looks that them to make sure they are OK:
[Start Query]
Authoritative DNS Serial Check
Starting Timestamp: 04/21/10 17:00:28
Query: netscantools.com
NS: ns2.webnethost.net -- Serial: 2010020400
NS: ns1.webnethost.net -- Serial: 2010020400
Analysis: All serial numbers are identical, no problems detected.
[End Query]
And now here is a query showing microsoft.com's DNS serials. Note that certain DNS servers are out of date with others. "ns1" is the primary and the others are backup.
[Start Query]
Authoritative DNS Serial Check
Starting Timestamp: 04/21/10 16:44:23
Query: microsoft.com
NS: ns3.msft.net -- Serial: 2010042102
NS: ns5.msft.net -- Serial: 2010042101
NS: ns1.msft.net -- Serial: 2010042102
NS: ns4.msft.net -- Serial: 2010042102
NS: ns2.msft.net -- Serial: 2010042101
Analysis: One or more serial numbers are out of sync with the other serial numbers.
[End Query]
I checked again 15 minutes later and found that all DNS serials in the microsoft.com listing were the same. This is probably normal for a domain of this size because it may take awhile to transfer the zone updates from the primary to the secondaries. I checked the SOA record and I could see that the refresh interval is 5 minutes and the retry interval is 10 minutes, so their DNS should not be out of sync for long. It's unusual to see this, so I thought it would make a good example.
A note about the serial field formatting. These both conform to what is now recommended where the serial is human readable. In the case of microsoft.com, you can see that it is April 21 2010, update numbers 1 and 2. In the case of netscantools.com, you can see that the serial has not changed since February 4, 2010. Not all serials conform to this method. Some are just straight incremental numbers.
You can try out the Auth Serial Check tool in the NetScanTools Pro Demo at our website.
Tuesday, April 13, 2010
Malformed UDP Packets
Malformed UDP Packets are easily generated with the new changes to the Packet Generator tool in NetScanTools Pro 10.96.1. Normally a UDP packet consists of an IP header followed by a UDP header followed by data. Usually all the parameters of those two headers are calculated at the time the packet is sent by the sockets layer, but with our Packet Generator tool we can create the packet from beginning to end including all parts of the headers.
This view from Wireshark shows a normal UDP packet:
You can see that the packet is complete and correct with all checksums and field lengths normal. The payload is only 4 bytes - it is the word 'test'.
Now look what happens if we put a value of 2 bytes into the UDP length field - remember that the UDP header itself is 8 bytes. The data payload is still the same 4 bytes. Wireshark's 'Expert Info' analyzer tells us that it is malformed and the length value is the culprit. The checksum is not analyzed and the data is not commented on.
See how Wireshark complains that the length value is less than the data and the UDP header? The message it gives is correct, the UDP length field must have a value of 8 or greater because that is the size of the UDP header itself. Can you send a UDP packet without any data? -sure, but it will also be tagged as malformed by Wireshark (exception error).
Next let's try setting the UDP header length field to something greater than the UDP header length + the data payload length. You can see that it notes that the length value (24) is greater than the payload (8 UDP header + 4 data = 12 bytes) and it does not complete the checksum calculation since all the data is not present.
A few words about what the Packet Generator tool can do. It can generate TCP, UDP, ICMP and CDP packets and send them out at a maximum repetition rate of roughly 10,000 packets per second - it is not a traffic generator capable of saturating your connection. It has a simple scripting language that allows you to send packets and even do some minor looping or use infinite looping. This is useful for connection test purposes. It uses WinPcap to generate packets, so it is pretty much limited to wired connections, not wireless connections. But even within these limits it really can show the response of applications or devices to malformed packets.
If you are interested in trying out the demo, you can do that by following this link. Please keep in mind that the demo will limit you to your local subnet but the full version does not have this limitation.
This view from Wireshark shows a normal UDP packet:
You can see that the packet is complete and correct with all checksums and field lengths normal. The payload is only 4 bytes - it is the word 'test'.
Now look what happens if we put a value of 2 bytes into the UDP length field - remember that the UDP header itself is 8 bytes. The data payload is still the same 4 bytes. Wireshark's 'Expert Info' analyzer tells us that it is malformed and the length value is the culprit. The checksum is not analyzed and the data is not commented on.
See how Wireshark complains that the length value is less than the data and the UDP header? The message it gives is correct, the UDP length field must have a value of 8 or greater because that is the size of the UDP header itself. Can you send a UDP packet without any data? -sure, but it will also be tagged as malformed by Wireshark (exception error).
Next let's try setting the UDP header length field to something greater than the UDP header length + the data payload length. You can see that it notes that the length value (24) is greater than the payload (8 UDP header + 4 data = 12 bytes) and it does not complete the checksum calculation since all the data is not present.
A few words about what the Packet Generator tool can do. It can generate TCP, UDP, ICMP and CDP packets and send them out at a maximum repetition rate of roughly 10,000 packets per second - it is not a traffic generator capable of saturating your connection. It has a simple scripting language that allows you to send packets and even do some minor looping or use infinite looping. This is useful for connection test purposes. It uses WinPcap to generate packets, so it is pretty much limited to wired connections, not wireless connections. But even within these limits it really can show the response of applications or devices to malformed packets.
If you are interested in trying out the demo, you can do that by following this link. Please keep in mind that the demo will limit you to your local subnet but the full version does not have this limitation.
NetScanTools Pro 10.96.1 Published
Yes, this is a new release: 10.96.1.
It's only been a few days since 10.96 was released, but last week a customer came to us with an important suggestion that we had to implement. The new change is in the UDP section of Packet Generator. At the customer's suggestion we added the ability to override and change the length field in the UDP header. A byproduct of this change is that the text or file data you add to the UDP packet payload is sent in it's entirety (up to the limit of your network MTU) independent of what the IP header length or UDP header length values are. Try this out using Wireshark to look at the UDP packets - Wireshark points out the packet errors you create quite well - lots of red highlighting. There were also other changes to Packet Generator in 10.96 in case you missed them. I'll be writing about this in the blog later today - click on Welcome group, then on the Blog icon.
What does this mean? it means that you now can easily create malformed UDP packets (Laura Chappell loves these).
There is also another change to the automatic checking for a new software version that you can review in the help file under General Information/Revision History.
Because these changes interrupted our normal release sequence we never did release a USB version 10.96 patch. That version was skipped for the USB version so we will be getting the 10.96.1 USB patch out shortly.
To get this new version:
From within NetScanTools Pro, please click on the left panel Welcome or Online group and then click on the Check for New Version icon. Login to obtain the updates. This upgrade is only available to persons with active maintenance plans.
It's only been a few days since 10.96 was released, but last week a customer came to us with an important suggestion that we had to implement. The new change is in the UDP section of Packet Generator. At the customer's suggestion we added the ability to override and change the length field in the UDP header. A byproduct of this change is that the text or file data you add to the UDP packet payload is sent in it's entirety (up to the limit of your network MTU) independent of what the IP header length or UDP header length values are. Try this out using Wireshark to look at the UDP packets - Wireshark points out the packet errors you create quite well - lots of red highlighting. There were also other changes to Packet Generator in 10.96 in case you missed them. I'll be writing about this in the blog later today - click on Welcome group, then on the Blog icon.
What does this mean? it means that you now can easily create malformed UDP packets (Laura Chappell loves these).
There is also another change to the automatic checking for a new software version that you can review in the help file under General Information/Revision History.
Because these changes interrupted our normal release sequence we never did release a USB version 10.96 patch. That version was skipped for the USB version so we will be getting the 10.96.1 USB patch out shortly.
To get this new version:
From within NetScanTools Pro, please click on the left panel Welcome or Online group and then click on the Check for New Version icon. Login to obtain the updates. This upgrade is only available to persons with active maintenance plans.
Thursday, April 8, 2010
NetScanTools Pro 10.96 Published
On April 6, 2010, we put the finishing touches on NetScanTools Pro 10.96. This is a minor release that does add one new feature plus several improvements to existing tools.
That new feature is the ability to save optional MD5 hash signature (checksum) files when you save text results, databases or packet capture files to disk. The MD5 file is a text file with the MD5 signature in it. This feature is particularly useful to those in law enforcement.
Improvements are in several areas, particularly Packet Generation and Capture. In the Packet Generator we have improved the scripting so that you can now do simple looping X number of times or you can do an infinite loop making it easy to send repeating sets of packets to a target. Packet Generator also now tells you if WinPcap fails to send a packet. By altering the display update of the floating packet send info window, we have been able to drastically speed up the sending of packets in continuous packet send mode.
In Packet Viewer (to be renamed Packet Capture in version 11), there were considerable improvements made to the parsing of IGMP packets and also the program now recognizes HP Switch LLC packets and Spanning Tree Protocol packets.
There are other minor things like NetBIOS Basic now reporting Windows 7 machines instead of "Windows 6.1". Clear buttons were added to the Whois and Real Time Blacklist (RBL) check tools next to the DNS IP address entry boxes.
One more interesting issue came from a tech support call I had a couple months ago. The user told me that he had a multihomed (more than one active network interface) machine and he was trying to either capture or send packets - I can't exactly remember. Anyway, it appears that the first option in the dropdown WinPcap Interface selection box was "169.254.7.179" - he said that he got an error message when trying to use that interface. After some discussion, we found there was a second IP in the dropdown box - he selected that one and everything worked.
As you may know, the 169.254.x.x IPs are what Windows assigns when it fails to get a new IP from DHCP - this is Automatic Private IP Addressing. So what was added to NetScanTools Pro was this: as the program starts, we go through the list of available interfaces. If a 169.254.x.x interface is found, the user is asked if they want to include it in the list of available WinPcap capable interfaces. Rather than just excluding those from the list, we ask you because someone may actually have set up a network with IPs in that range.
To get this new release you must have an active maintenance plan. If you do, then click on Help/Check for New Version. Login using the credentials shown in the program and download the installer. You will need your CDKEY/Serial Number to install, it is found on Help/About NetScanTools Pro. Please install over the top of your old installation and registering again should not be required.
That new feature is the ability to save optional MD5 hash signature (checksum) files when you save text results, databases or packet capture files to disk. The MD5 file is a text file with the MD5 signature in it. This feature is particularly useful to those in law enforcement.
Improvements are in several areas, particularly Packet Generation and Capture. In the Packet Generator we have improved the scripting so that you can now do simple looping X number of times or you can do an infinite loop making it easy to send repeating sets of packets to a target. Packet Generator also now tells you if WinPcap fails to send a packet. By altering the display update of the floating packet send info window, we have been able to drastically speed up the sending of packets in continuous packet send mode.
In Packet Viewer (to be renamed Packet Capture in version 11), there were considerable improvements made to the parsing of IGMP packets and also the program now recognizes HP Switch LLC packets and Spanning Tree Protocol packets.
There are other minor things like NetBIOS Basic now reporting Windows 7 machines instead of "Windows 6.1". Clear buttons were added to the Whois and Real Time Blacklist (RBL) check tools next to the DNS IP address entry boxes.
One more interesting issue came from a tech support call I had a couple months ago. The user told me that he had a multihomed (more than one active network interface) machine and he was trying to either capture or send packets - I can't exactly remember. Anyway, it appears that the first option in the dropdown WinPcap Interface selection box was "169.254.7.179" - he said that he got an error message when trying to use that interface. After some discussion, we found there was a second IP in the dropdown box - he selected that one and everything worked.
As you may know, the 169.254.x.x IPs are what Windows assigns when it fails to get a new IP from DHCP - this is Automatic Private IP Addressing. So what was added to NetScanTools Pro was this: as the program starts, we go through the list of available interfaces. If a 169.254.x.x interface is found, the user is asked if they want to include it in the list of available WinPcap capable interfaces. Rather than just excluding those from the list, we ask you because someone may actually have set up a network with IPs in that range.
To get this new release you must have an active maintenance plan. If you do, then click on Help/Check for New Version. Login using the credentials shown in the program and download the installer. You will need your CDKEY/Serial Number to install, it is found on Help/About NetScanTools Pro. Please install over the top of your old installation and registering again should not be required.
Subscribe to:
Posts (Atom)