We've had some occasional problems with strange (non-printable) characters appearing in the CDP and LLDP fields - it was thought to have been fixed in a previous release but apparently not, so we addressed that in this release. Those non-printable characters occasionally included apostrophes or double quotes which completely messed up (technical term) the SQL commands, so an SQLite database error popped up. In LLDP you will now always see hex characters in the MAC Address and Network Address fields and in CDP 'Port (ifName) and Device ID will either show a printable string or hex characters - both are valid.
We also changed LLDP and CDP retrieval phases to be more responsive to user input.
Speaking of strange, non-printable characters, the new SNMP Walk Tool used for support would also occasionally show strange characters. That has been fixed too.
More minor report changes and we updated also SQLite to the latest version along with the MAC address/manufacturer database.
Please visit www.SwitchPortMapper.com to download this new release.
By the way, this version works on Windows 10 Preview 10074.
Kirk
A look at all things to do with NetScanTools® Products. Inside you will find tips and comments about using our programs and even off topic comments.
Showing posts with label SQLite. Show all posts
Showing posts with label SQLite. Show all posts
Wednesday, May 13, 2015
Monday, March 9, 2015
NetScanTools LE v1.52 Released on March 6, 2015
The latest release of NetScanTools LE (designed for Law Enforcement) was ready on March 6, 2015.
Version 1.52 makes operational changes to Port Scanner/Scan Common Ports to scan only the current protocol type selected, ie. TCP, UDP or TCP+UDP. Previous versions scanned using the whole list, TCP+UDP regardless of the selection.
Whois has improved support for IPv6 and the ability to get whois information for the new top level domains was greatly expanded.
We tested it on Windows 10 Enterprise version. Everything operated normally as far as we could see.
WinPcap: only one part of NetScanTools LE uses WinPcap - the Packet Capture Tool. Due to recent issues customers have had with WinPcap on Windows 8.1, we decided to add in a test to make sure WinPcap is installed and running. If npf.sys is not running you will not be able to launch the Packet Capture Tool.
We updated SQLite to v3.8.8.3 and also updated the database files.
Please visit http://www.netscantools-le.com/ to get the latest version. You may install it over previous versions.
Version 1.52 makes operational changes to Port Scanner/Scan Common Ports to scan only the current protocol type selected, ie. TCP, UDP or TCP+UDP. Previous versions scanned using the whole list, TCP+UDP regardless of the selection.
Whois has improved support for IPv6 and the ability to get whois information for the new top level domains was greatly expanded.
We tested it on Windows 10 Enterprise version. Everything operated normally as far as we could see.
WinPcap: only one part of NetScanTools LE uses WinPcap - the Packet Capture Tool. Due to recent issues customers have had with WinPcap on Windows 8.1, we decided to add in a test to make sure WinPcap is installed and running. If npf.sys is not running you will not be able to launch the Packet Capture Tool.
We updated SQLite to v3.8.8.3 and also updated the database files.
Please visit http://www.netscantools-le.com/ to get the latest version. You may install it over previous versions.
Labels:
NetScanTools LE,
new release,
port scanner,
SQLite,
whois,
Windows 10,
WinPcap
Friday, April 4, 2014
Managed Switch Port Mapping Tool 2.32 Released
Two releases of the Switch Port Mapper were done quickly on the heels of v2.30 - the reason was to address issues with SQLITE_BUSY messages seen by some users (but never by us). It occurs during a SELECT of one table and using some of the data from that SELECT to do an INSERT into a different table - same database file. By doing a BEGIN IMMEDIATE wrapping the statements, I was able to solve the problem. It didn't used to happen so it must be a change in SQLITE operation.
I also added in a message to tell the user when Ping Sweep is activate but the IP range for Ping Sweep is empty. That's important because if you want to use Ping Sweep to prepopulate arp tables or to get NetBIOS info from a set of target, you had better define the targets. Why is this needed? simple: most people are using the Switch Port Mapper to map Layer 2 switches that don't keep track of IPs, layer 2's keep track of MAC addresses. So you have to get the IPs by retrieving ARP tables and looking for the MAC addresses so you can work backwards and get the IP addresses.
Get Managed Switch Port Mapping Tool v2.32 here:
http://www.SwitchPortMapper.com/
I also added in a message to tell the user when Ping Sweep is activate but the IP range for Ping Sweep is empty. That's important because if you want to use Ping Sweep to prepopulate arp tables or to get NetBIOS info from a set of target, you had better define the targets. Why is this needed? simple: most people are using the Switch Port Mapper to map Layer 2 switches that don't keep track of IPs, layer 2's keep track of MAC addresses. So you have to get the IPs by retrieving ARP tables and looking for the MAC addresses so you can work backwards and get the IP addresses.
Get Managed Switch Port Mapping Tool v2.32 here:
http://www.SwitchPortMapper.com/
Labels:
ARP,
layer 2,
new release,
SQLite,
Switch Port Mapper
Saturday, December 21, 2013
Managed Switch Port Mapping Tool v2.21 released December 20, 2013
This is an important release - especially if you rely on the history database (history.db3) for anything. There was a problem writing multirow mac address, IP address, hostname and interface manufacturer cells (ports with several devices attached to them, like other switches) to the history database. This has been corrected along with several other minor changes. I also move to address an issue with SQLITE_BUSY message handling, so if you are on a slow computer with a slow hard drive, it should work better for you.
You can download this release from http://www.SwitchPortMapper.com/ or from NetScanTools.com. We've also recently added an FTP link for those of you with a strange problem downloading using older versions of Internet Explorer. FTP seems to work, while HTTP on old IE sometimes results in a corrupted zip file. I have no idea why that's happening because the problem shows up for those people no matter which site they download from. Strange.
This release has been fully tested on Windows 8.1, 7 and XP. Other operating systems newer than XP should work fine.
Here is the list of detailed changes:
-Corrected problem saving multirow cells (ports with 2 or more attached mac addresses) to the history database. This affects MAC Address, IP Address, Hostname and Interface Manufacturer columns.
-Changes to SQLite interface to better handle the rare occurrence of SQLITE_BUSY messages.
-Improved retrieval of serial number, model number and software versions from Netgear switches.
-Added analysis of used/unused Gigabit Ethernet (type 117) ports on a switch.
-Added new table to history database saving the dot1dBasePortIfIndex for future use.
-Added checkboxes to control the visibility of the auth and priv passwords in the SNMPv3 settings window.
-Added warning to SNMPv3 settings window regarding AuthPriv mode when the database is unprotected.
-Improved SNMPManager utility to better check versions of libeay32.dll.
-Updated SQLite to version 3.8.2
-Updated MAC address/Manufacturer database.
You can download this release from http://www.SwitchPortMapper.com/ or from NetScanTools.com. We've also recently added an FTP link for those of you with a strange problem downloading using older versions of Internet Explorer. FTP seems to work, while HTTP on old IE sometimes results in a corrupted zip file. I have no idea why that's happening because the problem shows up for those people no matter which site they download from. Strange.
This release has been fully tested on Windows 8.1, 7 and XP. Other operating systems newer than XP should work fine.
Here is the list of detailed changes:
-Corrected problem saving multirow cells (ports with 2 or more attached mac addresses) to the history database. This affects MAC Address, IP Address, Hostname and Interface Manufacturer columns.
-Changes to SQLite interface to better handle the rare occurrence of SQLITE_BUSY messages.
-Improved retrieval of serial number, model number and software versions from Netgear switches.
-Added analysis of used/unused Gigabit Ethernet (type 117) ports on a switch.
-Added new table to history database saving the dot1dBasePortIfIndex for future use.
-Added checkboxes to control the visibility of the auth and priv passwords in the SNMPv3 settings window.
-Added warning to SNMPv3 settings window regarding AuthPriv mode when the database is unprotected.
-Improved SNMPManager utility to better check versions of libeay32.dll.
-Updated SQLite to version 3.8.2
-Updated MAC address/Manufacturer database.
Labels:
new release,
SNMP,
SQLite,
Switch Port Mapper
Thursday, September 5, 2013
NetScanTools Basic v2.30 Released
On September 4 we released a minor update to NetScanTools Basic, our freeware entry level NetScanTools product. It is now at v2.30.
This update adds a right click menu to all the results windows giving you a way to copy information to the clipboard, print the results or save them to a text file. It also adds an automatic check for a new release (you can turn this off) and updates the whois server database. Since the whois database uses SQLite, we also updated that to the latest version 3.8.0.2.
How to get v2.30:
If you already have NetScanTools Basic, click on Help/Check for New Version and follow the directions in the embedded web page. Or you can go to http://www.netscantools-basic.com/ and download it directly. Install over the top of any old versions.
Enjoy!
This update adds a right click menu to all the results windows giving you a way to copy information to the clipboard, print the results or save them to a text file. It also adds an automatic check for a new release (you can turn this off) and updates the whois server database. Since the whois database uses SQLite, we also updated that to the latest version 3.8.0.2.
How to get v2.30:
If you already have NetScanTools Basic, click on Help/Check for New Version and follow the directions in the embedded web page. Or you can go to http://www.netscantools-basic.com/ and download it directly. Install over the top of any old versions.
Enjoy!
Wednesday, April 24, 2013
SQLite Discussion - Sorting Order: TEXT vs NUMBER
One of our customers noticed a problem with our Switch List Editor in the Managed Switch Port Mapping Tool. The list ordering relies on a column in a table that we'll call ListIndex. The DDL for the table had defined the column as [ListIndex] TEXT. The index being saved in the column was the numbers zero through however many rows there are for that set of entries (this is not the main constraint column, just an indexing column within a set of rows).
If you did:
'SELECT * FROM theTable WHERE mainConstraintCol='rowSet' ORDER BY ListIndex ASC'
we expected to get a set of rows indexed 0, 1, 2, 3, 4 etc. in that order. That worked fine until there were more than 10 entries in a set of rows. Then the sorting would be 0, 1, 10, 11, 12, 13, 14, 2, 3, 4, 5, 6, 7, 8, 9. Obviously it is the creect sorting if the column is of type TEXT, but wrong since we are interested in the numbers themselves.
The solution was to change the DDL to this: [ListIndex] NUMBER (or INTEGER). That way the ORDER BY sorting ends up correctly in numeric order for lists larger than 10: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, etc.
Changing the DDL works OK if you are creating the table every time, but this table is persistent between application sessions. Because SQLite (to my knowledge) has no ALTER TABLE method for changing an existing table DDL Type from TEXT to NUMBER, I had to do the create temp table, copy contents from original, DROP the original table and recreate it correctly, then copy the temp table contents back to the original. A pain, but functional method. I would be interested in any other simpler methods.
Moral of this story is to be sure of your column typing when you define a table in SQLite especially if you are depending on the contents of that column to index something else.
SQLite: www.sqlite.org
Managed Switch Port Mapping Tool: www.SwitchPortMapper.com
If you did:
'SELECT * FROM theTable WHERE mainConstraintCol='rowSet' ORDER BY ListIndex ASC'
we expected to get a set of rows indexed 0, 1, 2, 3, 4 etc. in that order. That worked fine until there were more than 10 entries in a set of rows. Then the sorting would be 0, 1, 10, 11, 12, 13, 14, 2, 3, 4, 5, 6, 7, 8, 9. Obviously it is the creect sorting if the column is of type TEXT, but wrong since we are interested in the numbers themselves.
The solution was to change the DDL to this: [ListIndex] NUMBER (or INTEGER). That way the ORDER BY sorting ends up correctly in numeric order for lists larger than 10: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, etc.
Changing the DDL works OK if you are creating the table every time, but this table is persistent between application sessions. Because SQLite (to my knowledge) has no ALTER TABLE method for changing an existing table DDL Type from TEXT to NUMBER, I had to do the create temp table, copy contents from original, DROP the original table and recreate it correctly, then copy the temp table contents back to the original. A pain, but functional method. I would be interested in any other simpler methods.
Moral of this story is to be sure of your column typing when you define a table in SQLite especially if you are depending on the contents of that column to index something else.
SQLite: www.sqlite.org
Managed Switch Port Mapping Tool: www.SwitchPortMapper.com
Tuesday, February 12, 2013
SQLite INSERT OR REPLACE without a constraint
I learned something new yesterday while working on a simple four column table that keeps a list of the favorite tools in NetScanTools Pro. This table was set up without a constraint meaning there is nothing stopping us from inserting a row that is identical to a current row. Here is the DDL for the table:
CREATE TABLE [favorites] (
[col1] NUMBER,
[col2] TEXT,
[col3] NUMBER,
[col4] NUMBER);
As you can see - no constraints.
While working with the right click menu that adds a tool to NetScanTools Pro I discovered that it was adding the same row twice. I was using an INSERT INTO favorites... SQL command. So I thought I would get rid of the duplicates by using INSERT OR REPLACE INTO favorites. Wrong.
What I didn't know/remember was that the OR REPLACE means to replace the rows that are causing a constraint violation. Since there is no constraint, there is no constraint violation meaning the OR REPLACE clause does nothing and multiple identical rows can still be inserted.
An obvious solution is to change the table and add a constraint like this:
CREATE TABLE [favorites] (
[col1] NUMBER,
[col2] TEXT,
[col3] NUMBER,
[col4] NUMBER,
CONSTRAINT [] PRIMARY KEY ([col1]) ON CONFLICT REPLACE);
But to do so in an installed base of software in the hands of customers would require changes: ie. copying the existing table, deleting the old table and recreating it with the constraint. Plus it would require checking every time the program is started to make sure it had been done or some other versioning method would have to be used. Lots of details.
I arrived at a different solution using a TRIGGER to remove duplicate rows before the INSERT happens. This requires no changes to the design of the table and does not require changing anything in the user's database. This statement creates a TEMPORARY TRIGGER if it does not already exist and does this before an INSERT happens. It deletes any rows that match 'new' col1, then does the INSERT.
CREATE TEMP TRIGGER IF NOT EXISTS [unique_row]
BEFORE INSERT
ON favorites
BEGIN
DELETE FROM favorites WHERE new.col1= col1;
END
Pretty simple and appears to get the job done without modifying the original table. TRIGGERS are very powerful and I will probably be using more of them in the future - but using them with care.
Thanks to Bogdan Ureche for help in understanding what was going on with INSERT OR REPLACE without a corresponding CONSTRAINT.
www.SQLite.org
CREATE TABLE [favorites] (
[col1] NUMBER,
[col2] TEXT,
[col3] NUMBER,
[col4] NUMBER);
As you can see - no constraints.
While working with the right click menu that adds a tool to NetScanTools Pro I discovered that it was adding the same row twice. I was using an INSERT INTO favorites... SQL command. So I thought I would get rid of the duplicates by using INSERT OR REPLACE INTO favorites. Wrong.
What I didn't know/remember was that the OR REPLACE means to replace the rows that are causing a constraint violation. Since there is no constraint, there is no constraint violation meaning the OR REPLACE clause does nothing and multiple identical rows can still be inserted.
An obvious solution is to change the table and add a constraint like this:
CREATE TABLE [favorites] (
[col1] NUMBER,
[col2] TEXT,
[col3] NUMBER,
[col4] NUMBER,
CONSTRAINT [] PRIMARY KEY ([col1]) ON CONFLICT REPLACE);
But to do so in an installed base of software in the hands of customers would require changes: ie. copying the existing table, deleting the old table and recreating it with the constraint. Plus it would require checking every time the program is started to make sure it had been done or some other versioning method would have to be used. Lots of details.
I arrived at a different solution using a TRIGGER to remove duplicate rows before the INSERT happens. This requires no changes to the design of the table and does not require changing anything in the user's database. This statement creates a TEMPORARY TRIGGER if it does not already exist and does this before an INSERT happens. It deletes any rows that match 'new' col1, then does the INSERT.
CREATE TEMP TRIGGER IF NOT EXISTS [unique_row]
BEFORE INSERT
ON favorites
BEGIN
DELETE FROM favorites WHERE new.col1= col1;
END
Pretty simple and appears to get the job done without modifying the original table. TRIGGERS are very powerful and I will probably be using more of them in the future - but using them with care.
Thanks to Bogdan Ureche for help in understanding what was going on with INSERT OR REPLACE without a corresponding CONSTRAINT.
www.SQLite.org
Tuesday, March 15, 2011
SQLite, AUTO_VACUUM and Windows ACLs
This article applies to Windows 7 32/64 and Windows Vista 32/64 with UAC active.
In January an enduser pointed out to me that every time he tried to use the Real Time BlackList tool in NetScanTools Pro, he got an SQLite error message about the database being 'read-only' - it could not be opened. The software was installed on Windows 7-64 bit and NetScanTools Pro is operating at 'asInvoker' privilege which is normally USER privileges.
After doing the usual tech support routines by checking file properties, I was stumped - until yesterday when I was able to duplicate it on two Windows 7 machines.
The SQLite database is copied into our own directory created at install time under c:\ProgramData which is the common user data area. The thought was that any account using the program would be able to access the database. That was the idea. It's not the only database we put in there and the others were opening fine so I set out to find out why.
The only thing different about this database is that it has the pragma "AUTO_VACUUM" set. It appears that with AUTO_VACUUM SQLite moves freed pages around within the tables. This requires write privileges. SQLite error messages should do more than simply state that the database is read-only by checking the file ACLs given the calling process account privileges then stating the incompatibility with the current AUTO_VACUUM state.
To see the file access privs on an account level, you have to go into our C:\ProgramData\NWPS\NetScanToolsPro common user directory and do an "icacls *.*" on the command line. You will see that indeed user level privileges (BUILTIN\Users) only have (I)(RX) - inherit, read, execute privileges while the other higher level accounts have (F) full privileges. Since AUTO_VACUUM requires write access to the database to make changes, it will not have the proper privs for a user level account. So, yes, opening the database fails (I just don't think the message is good enough).
So now, how to fix it. Recreating the database with AUTO_VACUUM off fixes it. But what if you need to write (as a USER) to the Real Time Blacklist database using the tool we provide to edit the database? You can't because the administrators group are the owner.
The solution is to change the directory and file ACLs. I did this by modifying the installer to call a function of my own design which applied FULL access privs (grfAccessPermissions=GENERIC_ALL) to grfInheritance=SUB_CONTAINERS_AND_OBJECTS_INHERIT at our NWPS\NetScanToolsPro directory level. If that is done and you do the icacls command, all files in that directory show the "Everyone:(I)(F)" which means that every account can fully access the files and that includes our SQLite database that we couldn't open. You have to use AllocateAndInitializeSid, SetEntriesInAcl, and SetNamedSecurityInfo so accomplish this. You have to do this in the installer because it is running at admin privileges.
To summarize, if you have a program running Windows 7 or Vista at USER level that needs to access an SQLite database with write privileges contained in the C:\ProgramData common user directory that was not created by your program - you've got a problem. And that problem is even worse if it has AUTO_VACUUM enabled. You have to modify the file access privileges to FULL control in order to allow SQLite to operate on the database correctly.
In January an enduser pointed out to me that every time he tried to use the Real Time BlackList tool in NetScanTools Pro, he got an SQLite error message about the database being 'read-only' - it could not be opened. The software was installed on Windows 7-64 bit and NetScanTools Pro is operating at 'asInvoker' privilege which is normally USER privileges.
After doing the usual tech support routines by checking file properties, I was stumped - until yesterday when I was able to duplicate it on two Windows 7 machines.
The SQLite database is copied into our own directory created at install time under c:\ProgramData which is the common user data area. The thought was that any account using the program would be able to access the database. That was the idea. It's not the only database we put in there and the others were opening fine so I set out to find out why.
The only thing different about this database is that it has the pragma "AUTO_VACUUM" set. It appears that with AUTO_VACUUM SQLite moves freed pages around within the tables. This requires write privileges. SQLite error messages should do more than simply state that the database is read-only by checking the file ACLs given the calling process account privileges then stating the incompatibility with the current AUTO_VACUUM state.
To see the file access privs on an account level, you have to go into our C:\ProgramData\NWPS\NetScanToolsPro common user directory and do an "icacls *.*" on the command line. You will see that indeed user level privileges (BUILTIN\Users) only have (I)(RX) - inherit, read, execute privileges while the other higher level accounts have (F) full privileges. Since AUTO_VACUUM requires write access to the database to make changes, it will not have the proper privs for a user level account. So, yes, opening the database fails (I just don't think the message is good enough).
So now, how to fix it. Recreating the database with AUTO_VACUUM off fixes it. But what if you need to write (as a USER) to the Real Time Blacklist database using the tool we provide to edit the database? You can't because the administrators group are the owner.
The solution is to change the directory and file ACLs. I did this by modifying the installer to call a function of my own design which applied FULL access privs (grfAccessPermissions=GENERIC_ALL) to grfInheritance=SUB_CONTAINERS_AND_OBJECTS_INHERIT at our NWPS\NetScanToolsPro directory level. If that is done and you do the icacls command, all files in that directory show the "Everyone:(I)(F)" which means that every account can fully access the files and that includes our SQLite database that we couldn't open. You have to use AllocateAndInitializeSid, SetEntriesInAcl, and SetNamedSecurityInfo so accomplish this. You have to do this in the installer because it is running at admin privileges.
To summarize, if you have a program running Windows 7 or Vista at USER level that needs to access an SQLite database with write privileges contained in the C:\ProgramData common user directory that was not created by your program - you've got a problem. And that problem is even worse if it has AUTO_VACUUM enabled. You have to modify the file access privileges to FULL control in order to allow SQLite to operate on the database correctly.
Labels:
ACL,
AUTO_VACUUM,
privileges,
SQLite,
Windows 7,
Windows Vista
Wednesday, October 6, 2010
NetScanTools (TM) Pro 10.98 Published
On Monday, October 4, we released NetScanTools Pro 10.98 installed version. The USB version patch was released on Tuesday, October 5.
Here are the changes:
- Ping will now allow up to 8192 consecutive pings to sent. Problems occurred in the previous version if you exceeded 256 pings as defined in Setup.
- Certain DNS functions that use the secondary resolver (ex. Get Basic DNS Records) will now properly handle the truncated flag in the UDP response that indicates the query should be retried using TCP.
- DNS Tools - Core: Fixed problem where if a very large response to a single record query was obtained, all the records would be displayed. Example would be a large PTR record response for a single IP address.
- Updated SQLite to version 3.7.2.
- Updated database files. Removed whois prefix files.
Saturday, January 16, 2010
NetScanTools (tm) Basic Edition 2.0 Released Jan 14, 2010
This update to the Freeware Basic Edition changes the layout of the left control panel to make it less confusing. I also added the registered trademark notice for NetScanTools. The SQLite DLL to the latest version as was the whois database it works with. The biggest change was a switch to Inno Setup away from the old Wise installer. This reduced the size of the final installation .exe nearly 1 MB and it gives full compatibility with Windows 7. Speaking of Windows 7, NetScanTools Basic is fully Windows 7 compatible.
You can get NetScanTools Basic 2.0 here.
Labels:
DNS,
NetScanTools Basic,
Ping,
Ping Scan,
SQLite,
traceroute,
whois
Tuesday, November 3, 2009
NetScanTools (TM) Pro 10.94 Published
The installed version of this release was posted on November 2. This release is geared towards improved Windows 7 compatibility.
It now includes the latest version of WinPcap 4.1.1 (just released last week) which has been extensively tested on Windows 7. NetScanTools Pro uses WinPcap for packet capture and generation of specialized packets. Previously we used 4.0.2 which seems to work fine on Windows 7 for our purposes.
We've also updated the SQLite DLL to the latest version 3.6.19 and made it statically linked to avoid SxS DLL problems.
Feature-wise there are several changes to the "DNS Tools-Core" toolset. There is a new tool called "Get Basic DNS Records". This tool requests SOA, A, NS, MX, CNAME, PTR and TXT resource records as applicable for a given input IP address, hostname or domain name. It saves time by combining all those queries into one query.
DNS Tools - Core also now includes options for requesting the NSEC, DNSKEY and RRSIG resource records. We have had the ability to parse those records for awhile, but now you can directly request them and the parsing has now been significantly improved. When parsing NSEC, we added showing the list of resource records (RR) covered. In DNSKEY we added display of the public key as hex and also now also compute and display the Key ID. The Key ID can be correlated with the corresponding Key ID from the RRSIG records. The RRSIG record parsing was improved by adding display of the signature in hex and we now parse many more "types covered".
DNS Tools - Core also had a problem when doing a Zone Transfer of a medium to large zone. They would crash the program. This was due to a memory allocation error and also due to the fact that in C "static int x = 0;" is not reset to zero when the function is re-entered.
Passive Discovery has a change which is more user related. We had heard from people who saw a "Error compiling filter" when they tried to run it. This was due to a mismatch between the WinPcap interface they selected, the subnet mask and the starting network IP address. We are no longer saving the subnet mask and starting IP, they are being recalculated. We also reworded the Recalculate button to better explain what it does and we improved the error messages.
There were some other minor changes but I won't go into those. As usual the database were updated. If you have NetScanTools Pro with an active maintenance plan, click on Help/Check for New Version to get 10.94.
It now includes the latest version of WinPcap 4.1.1 (just released last week) which has been extensively tested on Windows 7. NetScanTools Pro uses WinPcap for packet capture and generation of specialized packets. Previously we used 4.0.2 which seems to work fine on Windows 7 for our purposes.
We've also updated the SQLite DLL to the latest version 3.6.19 and made it statically linked to avoid SxS DLL problems.
Feature-wise there are several changes to the "DNS Tools-Core" toolset. There is a new tool called "Get Basic DNS Records". This tool requests SOA, A, NS, MX, CNAME, PTR and TXT resource records as applicable for a given input IP address, hostname or domain name. It saves time by combining all those queries into one query.
DNS Tools - Core also now includes options for requesting the NSEC, DNSKEY and RRSIG resource records. We have had the ability to parse those records for awhile, but now you can directly request them and the parsing has now been significantly improved. When parsing NSEC, we added showing the list of resource records (RR) covered. In DNSKEY we added display of the public key as hex and also now also compute and display the Key ID. The Key ID can be correlated with the corresponding Key ID from the RRSIG records. The RRSIG record parsing was improved by adding display of the signature in hex and we now parse many more "types covered".
DNS Tools - Core also had a problem when doing a Zone Transfer of a medium to large zone. They would crash the program. This was due to a memory allocation error and also due to the fact that in C "static int x = 0;" is not reset to zero when the function is re-entered.
Passive Discovery has a change which is more user related. We had heard from people who saw a "Error compiling filter" when they tried to run it. This was due to a mismatch between the WinPcap interface they selected, the subnet mask and the starting network IP address. We are no longer saving the subnet mask and starting IP, they are being recalculated. We also reworded the Recalculate button to better explain what it does and we improved the error messages.
There were some other minor changes but I won't go into those. As usual the database were updated. If you have NetScanTools Pro with an active maintenance plan, click on Help/Check for New Version to get 10.94.
Labels:
DNSKEY,
NetScanTools Pro,
new release,
NSEC,
RRSIG,
SQLite,
Windows 7,
Zone Transfer
Thursday, November 6, 2008
Managed Switch Port Mapping Tool v1.95 Released
The newest release of the Managed Switch Port Mapping Tool was released yesterday and posted this morning. This version has several internal changes which should allow more models of switches to be mapped.
It also has something that was long overdue: support for the Windows Common Controls v6+. When the program is run XP and Vista this gives a different more up-to-date look to things like checkboxes, radio buttons and other controls. Why did we wait so long? it was very hard to do using the Visual C++ 6 compiler. Remember, we only recently made the transition to using Visual C++ 2005 and we are now making the transition to 2008. And speaking of the common control look -- it doesn't work on Windows Server 2003 or 2008. A new milestone: This release of the program has finally been successfully tested on Windows Server 2008.
This release also marks the first time I've fully understood how the Side by Side (WinSxS) DLLs are to be handled properly -- at least I think I understand. The program is linked with the CRT and MFC DLLs so we need a certain version or later of those DLLs on the machine. Our installer now looks for the right version and if it does not find them, the Microsoft Visual C++ 2005 redistributable installer is launched to put the right DLLs in the right places. This was all supposed to stop DLL hell, but I think it created a significantly more complex situation -- if you don't believe me, just have a quick look in C:\windows\WinSxS. It definitely made our installer bigger.
As usual, we updated to the latest version of SQLite: 3.6.4. I can't say enough good things about SQLite. I find it to be very robust and easy to use. The SQL is powerful enough for our needs and it makes it very easy to work with the large amounts of data that we retrieve from the switch. I use a C++ wrapper that I found on CodeProject so the learning curve was really fast. Try SQLite sometime! -the link to their site is on the right.
You can get the latest version by clicking on Help/Check for Update or by going to the Switch Port Mapper website on the right.
It also has something that was long overdue: support for the Windows Common Controls v6+. When the program is run XP and Vista this gives a different more up-to-date look to things like checkboxes, radio buttons and other controls. Why did we wait so long? it was very hard to do using the Visual C++ 6 compiler. Remember, we only recently made the transition to using Visual C++ 2005 and we are now making the transition to 2008. And speaking of the common control look -- it doesn't work on Windows Server 2003 or 2008. A new milestone: This release of the program has finally been successfully tested on Windows Server 2008.
This release also marks the first time I've fully understood how the Side by Side (WinSxS) DLLs are to be handled properly -- at least I think I understand. The program is linked with the CRT and MFC DLLs so we need a certain version or later of those DLLs on the machine. Our installer now looks for the right version and if it does not find them, the Microsoft Visual C++ 2005 redistributable installer is launched to put the right DLLs in the right places. This was all supposed to stop DLL hell, but I think it created a significantly more complex situation -- if you don't believe me, just have a quick look in C:\windows\WinSxS. It definitely made our installer bigger.
As usual, we updated to the latest version of SQLite: 3.6.4. I can't say enough good things about SQLite. I find it to be very robust and easy to use. The SQL is powerful enough for our needs and it makes it very easy to work with the large amounts of data that we retrieve from the switch. I use a C++ wrapper that I found on CodeProject so the learning curve was really fast. Try SQLite sometime! -the link to their site is on the right.
You can get the latest version by clicking on Help/Check for Update or by going to the Switch Port Mapper website on the right.
Subscribe to:
Posts (Atom)