After securing a Windows Server 2012 box with TLS 1.0 disabled per PCI-DSS 3.1 requirements, I found that I could only connect to it through Remote Desktop (RDP) from a Windows 8.1 or Windows 10 client.
The problem was this: all attempts to connect through the LAN via Remote Desktop from Windows 7 were met with "This computer can't connect to the remote computer. Try connecting again...etc."
The Server 2012 Standard (not R2) computer is running the most simple Remote Desktop mode accessed through Computer/Remote Settings as shown below.
I went through rabbit trails with firewall settings, Remote Desktop Services (which I did not install) turning on and off the 'Allow connections only from computers running Remote Desktop with Network Level Authentication', using Select Users - none of them worked.
During extensive searching I ran across a some discussions of TLS and RDP on Windows 7. I found that we had RDP 7.1 on the Windows 7 sp1 computer and RDP 8.0 was an optional download through Windows update. RDP 8 apparently has support for later TLS versions beyond the disabled TLS 1.0. RDP 8 for Windows 7 is discussed here: https://support.microsoft.com/en-us/kb/2592687.
Solution: After installing the KB2592687 update (an optional update in Windows update), rebooting and installing even more updates triggered by that update, RDP 8.0 client was installed and connected normally to the Windows 2012 server.
There is also an RDP 8.1 client only update KB2830477 that I may install later but for now I can Remote Desktop in to the Server 2012 box from Windows 7 without any apparent problems.
More info on RDP 8.1 for Windows 7 including prerequisites: http://blogs.msdn.com/b/rds/archive/2013/11/12/remote-desktop-protocol-8-1-update-for-windows-7-sp1-released-to-web.aspx
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 Windows 7. Show all posts
Showing posts with label Windows 7. Show all posts
Wednesday, June 24, 2015
Thursday, July 28, 2011
Managed Switch Port Mapping Tool v1.99.5 Released
This latest release was made available for download today. It adds support for SMC switches. We tested it thoroughly with an SMC6128L2 switch and there are now SMC specific extensions in our software to gather more information about the switch.
There was one fundamental operational change that you should be aware of: ping sweep has been moved up near the start of the switch mapping process. This was done to force the switch to update it's bridge tables with any mac addresses that may have 'aged' out of the tables. That way as many devices as possible will be seen. Be sure to put in all the IPv4 ranges you need to be pinged ahead of time.
Another set of changed dealt with the operation of the IP to hostname resolver. We added a control in Settings to turn use of the caching table on or off. We also added a control in Settings to be sure that it is erased on exit. The reasoning behind this is that in a DHCP environment, IPs change and you should probably be clearing the table more often. The table is used much like a 'hosts' file for quick resolution of IPv4 addresses to hostnames in successive mappings. This will become more necessary in v2.0. In order to minimize DNS queries, we use this table. Now there are more options for erasing it to remove what will become stale information. One other thing we added was a check for duplicate hostnames - what we mean by this is two IPs having the same hostname. If this is found, you get to see the hostname(s) and IPs that are sharing the hostname. You would definitely want to manually erase the IP/hostname Resolver table in Database Maintenance if this occurs. If it repeats after doing that, you have a DNS problem.
Another change was in the area of print margins. A user pointed out that the print margins were rather large. Investigation revealed that the default margins were supposed to be 25mm. But in reality it was more like 250mm or one inch. If you are using a 96 dpi printer, then it is one inch. The File menu now has Print Page Options to allow you to change this.
Finally, in an effort to get away from the ancient Wise installer that we've used for years, this release now uses Inno Setup. Inno Setup reduced the size of the installer by around 1 MB. That doesn't sound like much but it is when you consider many downloads. It's also a modern and fast installer, so it works better on Windows 7.
http://www.switchportmapper.com/
or
http://www.netscantools.com/spmapmain.html
Enjoy!
Kirk
There was one fundamental operational change that you should be aware of: ping sweep has been moved up near the start of the switch mapping process. This was done to force the switch to update it's bridge tables with any mac addresses that may have 'aged' out of the tables. That way as many devices as possible will be seen. Be sure to put in all the IPv4 ranges you need to be pinged ahead of time.
Another set of changed dealt with the operation of the IP to hostname resolver. We added a control in Settings to turn use of the caching table on or off. We also added a control in Settings to be sure that it is erased on exit. The reasoning behind this is that in a DHCP environment, IPs change and you should probably be clearing the table more often. The table is used much like a 'hosts' file for quick resolution of IPv4 addresses to hostnames in successive mappings. This will become more necessary in v2.0. In order to minimize DNS queries, we use this table. Now there are more options for erasing it to remove what will become stale information. One other thing we added was a check for duplicate hostnames - what we mean by this is two IPs having the same hostname. If this is found, you get to see the hostname(s) and IPs that are sharing the hostname. You would definitely want to manually erase the IP/hostname Resolver table in Database Maintenance if this occurs. If it repeats after doing that, you have a DNS problem.
Another change was in the area of print margins. A user pointed out that the print margins were rather large. Investigation revealed that the default margins were supposed to be 25mm. But in reality it was more like 250mm or one inch. If you are using a 96 dpi printer, then it is one inch. The File menu now has Print Page Options to allow you to change this.
Finally, in an effort to get away from the ancient Wise installer that we've used for years, this release now uses Inno Setup. Inno Setup reduced the size of the installer by around 1 MB. That doesn't sound like much but it is when you consider many downloads. It's also a modern and fast installer, so it works better on Windows 7.
http://www.switchportmapper.com/
or
http://www.netscantools.com/spmapmain.html
Enjoy!
Kirk
Labels:
DNS,
hosts file,
installation,
Switch Port Mapper,
SwitchPortMapper.com,
Windows 7
Tuesday, June 21, 2011
IPv6 Teredo Problems and Solutions on Windows 7-64 bit
I came back from the Wireshark Sharkfest '11 Conference excited to try some of the things I had learned. Imagine my dismay when I fired up my Windows 7-64 test box only to find that certain parts of NetScanTools Pro 11 that are IPv6 aware ceased working. Immediately I was able to see that it was the parts of the program that depended on the getaddrinfo function call that were failing. How did I know that? I used the other 'home-grown' NetScanTools resolver functions to talk with DNS (they bypass Windows resolver entirely and talk directly to any DNS) and by using Wireshark I could see the AAAA records coming back from DNS. I could see that the getaddrinfo function was not getting and reporting the IPv6 AAAA records. Very strange.
So I looked at a couple of things. First I did a cursory check of the network settings with ipconfig. All appeared normal. Then I spent some time recompiling NetScanTools Pro while playing around with various options in the addrinfo hints structure passed into getaddrinfo. That was not fruitful. Nothing I did could make the getaddrinfo function return the AAAA record. I was seeing the 11004 WSANO_DATA error. So I put that aside and looked more carefully at the IPv6 networking subsystem.
Next I tried to see if it was NetScanTools failing or something deeper. So I tried using command line "ping -6 ipv6.google.com". This failed with a message effectively admitting that it couldn't resolve the hostname to an IPv6. Good - sort of. Next I tried the other way doing a "ping -6 2001:4860:b006::69". That came back with even more ominous wording "Ping transmit failed. General Failure.". But I could use both command line ping and NetScanTools Pro IPv6 Ping to contact Link-Local IPv6 addresses on my local network - as I should be able to do. The IPv6 routing table didn't yield any real clues either.
Using both NetScanTools Pro, ipconfig and various netsh command line things I was able to see that while isatap was active, I was not seeing teredo - I had seen it before when using command line ping and when using NetScanTools Pro. Teredo was what I wanted to try decoding with Wireshark. NetScanTools Pro showed me that Teredo was there but it had an admin status of 'Down'. So I tried various netsh commands to reactivate Teredo. They all appeared to work, but Teredo never reappeared in the list of hidden devices in Device Manager. I tried the solutions floating around on the internet for making sure IPv6 was active and getting Teredo to show up in Device Manager, but still no luck.
A little history might help. I had recently installed VMware Workstation 7.1.4 on that machine because it's a test machine and I needed lots of OS's available. Could it be that? I don't know for sure because I spent time on VMware forums looking for similar problems - but didn't see any. It could have been a Windows Update patch that turned off Teredo, but I just don't know for sure. The two VMware Virtual Ethernet Adapters both had link-local fe80 IPv6 addresses, so IPv6 wasn't entirely dead. AND of all things, I could start Windows Server 2008 in a virtual machine with all of it's IPv6 functions working perfectly including NetScanTools Pro. I did find this page dealing with firewall settings for Teredo and found that everything was OK: http://support.microsoft.com/kb/968510
So today I spent lots of time with the netsh commands. I used "netsh interface IP show config" to see all the interfaces similar to ipconfig. By doing a "netsh interface ipv6 show interface" I could see all the active connections. What was missing was Teredo. I used "netsh interface set interface teredo set state default" to make sure it was there and it answered OK. But still no Teredo. Then I found this interesting command "netsh interface IPv6 show teredo". It said the State was 'offline' and the Error value was "client is in a managed network". Progress. Big progress.
So I put that error string into google and found a reference to this blog: http://blogs.msdn.com/b/p2p/archive/2007/03/22/teredo-and-the-pnrp-global-cloud.aspx
Essentially Teredo detected (incorrectly) that the machine was in a corporate environment - this is probably due to multiple OS's and several switches being active with all their chatter. So the fix was to use "Netsh interface teredo set state enterpriseclient". Once I did that, there was no need for rebooting or anything. "netsh interface IPv6 show teredo" now showed the correct info like Local Mapping and External NAT Mapping. And all of a sudden both command line ping and NetScanTools Pro IPv6 enabled tools began to work again.
I guess the thing that bugs me is this: why is there this huge dependency on Teredo for IPv6 in Windows 7? If I ask for a name resolution using getaddrinfo with a hint of AF_INET6 I EXPECT a response if AAAA records are coming back from the default dhcp assigned system DNS. It shouldn't matter that IPv6 is fully enabled on the system using Teredo or anything else. So my workaround will be to write EXTRA CODE to resend an AAAA or PTR record request from my own private resolver on failure of getaddrinfo because I can't trust it. I hope someone at Microsoft reads this and helps me understand why it was behaving this way.
All I wanted to do was try to decode Teredo traffic with Wireshark...
Kirk Thomas
NetScanTools Developer and Sharkfest '11 attendee
So I looked at a couple of things. First I did a cursory check of the network settings with ipconfig. All appeared normal. Then I spent some time recompiling NetScanTools Pro while playing around with various options in the addrinfo hints structure passed into getaddrinfo. That was not fruitful. Nothing I did could make the getaddrinfo function return the AAAA record. I was seeing the 11004 WSANO_DATA error. So I put that aside and looked more carefully at the IPv6 networking subsystem.
Next I tried to see if it was NetScanTools failing or something deeper. So I tried using command line "ping -6 ipv6.google.com". This failed with a message effectively admitting that it couldn't resolve the hostname to an IPv6. Good - sort of. Next I tried the other way doing a "ping -6 2001:4860:b006::69". That came back with even more ominous wording "Ping transmit failed. General Failure.". But I could use both command line ping and NetScanTools Pro IPv6 Ping to contact Link-Local IPv6 addresses on my local network - as I should be able to do. The IPv6 routing table didn't yield any real clues either.
Using both NetScanTools Pro, ipconfig and various netsh command line things I was able to see that while isatap was active, I was not seeing teredo - I had seen it before when using command line ping and when using NetScanTools Pro. Teredo was what I wanted to try decoding with Wireshark. NetScanTools Pro showed me that Teredo was there but it had an admin status of 'Down'. So I tried various netsh commands to reactivate Teredo. They all appeared to work, but Teredo never reappeared in the list of hidden devices in Device Manager. I tried the solutions floating around on the internet for making sure IPv6 was active and getting Teredo to show up in Device Manager, but still no luck.
A little history might help. I had recently installed VMware Workstation 7.1.4 on that machine because it's a test machine and I needed lots of OS's available. Could it be that? I don't know for sure because I spent time on VMware forums looking for similar problems - but didn't see any. It could have been a Windows Update patch that turned off Teredo, but I just don't know for sure. The two VMware Virtual Ethernet Adapters both had link-local fe80 IPv6 addresses, so IPv6 wasn't entirely dead. AND of all things, I could start Windows Server 2008 in a virtual machine with all of it's IPv6 functions working perfectly including NetScanTools Pro. I did find this page dealing with firewall settings for Teredo and found that everything was OK: http://support.microsoft.com/kb/968510
So today I spent lots of time with the netsh commands. I used "netsh interface IP show config" to see all the interfaces similar to ipconfig. By doing a "netsh interface ipv6 show interface" I could see all the active connections. What was missing was Teredo. I used "netsh interface set interface teredo set state default" to make sure it was there and it answered OK. But still no Teredo. Then I found this interesting command "netsh interface IPv6 show teredo". It said the State was 'offline' and the Error value was "client is in a managed network". Progress. Big progress.
So I put that error string into google and found a reference to this blog: http://blogs.msdn.com/b/p2p/archive/2007/03/22/teredo-and-the-pnrp-global-cloud.aspx
Essentially Teredo detected (incorrectly) that the machine was in a corporate environment - this is probably due to multiple OS's and several switches being active with all their chatter. So the fix was to use "Netsh interface teredo set state enterpriseclient". Once I did that, there was no need for rebooting or anything. "netsh interface IPv6 show teredo" now showed the correct info like Local Mapping and External NAT Mapping. And all of a sudden both command line ping and NetScanTools Pro IPv6 enabled tools began to work again.
I guess the thing that bugs me is this: why is there this huge dependency on Teredo for IPv6 in Windows 7? If I ask for a name resolution using getaddrinfo with a hint of AF_INET6 I EXPECT a response if AAAA records are coming back from the default dhcp assigned system DNS. It shouldn't matter that IPv6 is fully enabled on the system using Teredo or anything else. So my workaround will be to write EXTRA CODE to resend an AAAA or PTR record request from my own private resolver on failure of getaddrinfo because I can't trust it. I hope someone at Microsoft reads this and helps me understand why it was behaving this way.
All I wanted to do was try to decode Teredo traffic with Wireshark...
Kirk Thomas
NetScanTools Developer and Sharkfest '11 attendee
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, January 5, 2011
Addressing Confusion
In my December 2010 newletter I talked about NetScanTools Pro 10.98.1 on Windows 7-64 bit. I talked about how the change to the manifest from 'require administrator' (which did not allow unescalated use on a User privileges account) to 'asInvoker' allowed User privileges accounts to run NetScanTools Pro without logging in as an administrator -- some business installations only allow user level privs for their employees. But the biproduct of that change was to disallow writing to HKEY_LOCAL_MACHINE (HKLM) on Windows 7-64 and possibly Vista as well. For security reasons, UAC only allows read-only privileges in HKLM when you are not an administrator process. The process (ie. NetScanTools Pro) must have elevate privs to administrator for UAC to allow writing to that part of the registry.
NetScanTools Pro 10 only writes to one specific portion of HKLM and it only does that when you complete your registration (Validate and Save) or if you change your Maintenance Plan expiration date or Email Address using About/Edit Maintenance Plan. If you try that on Windows 7-64 with normal administrator or user privs, you get an error that it cannot write to the registry. It does not write to HKLM in the normal course of program operation, registry writes are done to HKEY_CURRENT_USER (HKCU).
The next release 10.98.2 will address this by giving a much more descriptive message explaining that in order to complete the task, you have to exit and restart with 'run as administrator'. It will also have some other changes to address some things we recently learned about the SNMP toolset.
We are working on 10.98.2 and should have it done shortly.
NetScanTools Pro 10 only writes to one specific portion of HKLM and it only does that when you complete your registration (Validate and Save) or if you change your Maintenance Plan expiration date or Email Address using About/Edit Maintenance Plan. If you try that on Windows 7-64 with normal administrator or user privs, you get an error that it cannot write to the registry. It does not write to HKLM in the normal course of program operation, registry writes are done to HKEY_CURRENT_USER (HKCU).
The next release 10.98.2 will address this by giving a much more descriptive message explaining that in order to complete the task, you have to exit and restart with 'run as administrator'. It will also have some other changes to address some things we recently learned about the SNMP toolset.
We are working on 10.98.2 and should have it done shortly.
Monday, December 20, 2010
December News
I've been pretty busy this month and I haven't updated the blog much - I hope to provide more timely updates in 2011. V11 status: All the tools from NetScanTools Pro v10 have been transferred to v11 and I'm working on finishing tooltips and icons along with general cleanup of things as I run across them.
The latest December newsletter was published last week. You can find it on our website at http://www.netscantools.com/newsletters.html - there is one very important thing in there that I will address here. In version 10.98.1 I changed the manifest so that USER level accounts could run the program without logging in as administrator on Windows 7-64 bit (this does not seem to be an issue on Win 7-32). When you run a 32 application like NetScanTools Pro on Windows 7-64, it uses a portion of the registry called HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Northwest Performance Software, Inc. which contains a redirected part "Wow6432Node". Users do not have privileges to change this key subtree and even if you login under an administrator account, the keys in this tree cannot be changed. So in order to apply registration information or change the maintenance plan expiration date, you have to right click on the NetScanTools Pro icon and select 'Run as administrator' to all the program to have full access to the keys.
The latest December newsletter was published last week. You can find it on our website at http://www.netscantools.com/newsletters.html - there is one very important thing in there that I will address here. In version 10.98.1 I changed the manifest so that USER level accounts could run the program without logging in as administrator on Windows 7-64 bit (this does not seem to be an issue on Win 7-32). When you run a 32 application like NetScanTools Pro on Windows 7-64, it uses a portion of the registry called HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Northwest Performance Software, Inc. which contains a redirected part "Wow6432Node". Users do not have privileges to change this key subtree and even if you login under an administrator account, the keys in this tree cannot be changed. So in order to apply registration information or change the maintenance plan expiration date, you have to right click on the NetScanTools Pro icon and select 'Run as administrator' to all the program to have full access to the keys.
Wednesday, November 17, 2010
NetScanTools Pro and User Privileges
Yesterday an astute user pointed out that if you start NetScanTools Pro 10.98 on Windows 7 in a USER privileges account, the operating system asks that you login with an administrator account password to allow the program to run.
NOT GOOD! You should at least be able to run the program from that type of account without jumping through hoops. So I quickly traced the issue to the MANIFEST. You programmers out there know about this. In it were commands asking for higher privileges than we really need, so I think we are going to have a new minor, minor revision on Thursday. Beside fixing that little problem, the databases will all be updated with current information.
I assume this would affect anyone still using Windows Vista as well as Windows 7. The rest of you have little to concern yourselves with regarding this problem.
Kirk
NOT GOOD! You should at least be able to run the program from that type of account without jumping through hoops. So I quickly traced the issue to the MANIFEST. You programmers out there know about this. In it were commands asking for higher privileges than we really need, so I think we are going to have a new minor, minor revision on Thursday. Beside fixing that little problem, the databases will all be updated with current information.
I assume this would affect anyone still using Windows Vista as well as Windows 7. The rest of you have little to concern yourselves with regarding this problem.
Kirk
Labels:
manifest,
NetScanTools Pro,
new release,
Windows 7,
Windows Vista
Thursday, December 24, 2009
NetScanTools Pro Maintenance Plan Renewal Sale
Did you forget to renew your NetScanTools Pro v10 Maintenance Plan? -maybe by a lot? -maybe even by a year or more?
Here is your chance to be back on the plan and get the Windows 7 friendly 10.94 version! Special price reduction on the "Over 180 days Late" v10 Maintenance Plan renewal - instead of $150, the renewal price is $135 through December 31, 2009. Call us (360) 683-9888 or go to the maintenance plan page below for a link to order online:
http://www.netscantools.com/nstpromaintenance.html
Here is your chance to be back on the plan and get the Windows 7 friendly 10.94 version! Special price reduction on the "Over 180 days Late" v10 Maintenance Plan renewal - instead of $150, the renewal price is $135 through December 31, 2009. Call us (360) 683-9888 or go to the maintenance plan page below for a link to order online:
http://www.netscantools.com/nstpromaintenance.html
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, August 20, 2009
NetScanTools (TM) Pro 10.93 Published
The installed version and USB version of NetScanTools Pro 10.93 are both now available. If you have an active maintenance plan, you can upgrade today. Use Help/Check for New Version, then login.
The changes in this release range from the cosmetic (like adding our new registered trademark notation) to bug fixes to adding a minor new feature. The minor new feature was brought about by a customer suggestion and it was to provide the decimal representation of the input IP address on Subnet Calculator. Apparently our user sometimes hardcodes the IP address in a link and making it decimal makes it harder for bots to pick up the link.
Two of the bugs were seen during the August 12 webinar:
The first was when Laura was running a Continous Ping, then she pressed Stop and went into Setup. When she was talking about the various Ping options, the Continuous Ping started up again in the background results window. This was fixed.
The second thing I saw during the webinar was when Laura entered her favorite of the day hostname and it then went through and translated it to an IP address, then ran the IP address through the list of RBL servers. The problem was that the translated address was 255.255.255.255. Actually what had happened was the host to IP didn't resolve because there was no A record for the hostname in DNS. Now if this happens, it stops and tells you that it couldn't resolve for an IP.
If you want the full list of changes, you can install 10.93, then click on the Welcome left panel control, then click on Welcome to NetScanTools Pro icon. This will show a completely revamped page including the list of changes since the last release (10.92). There are also a few helpful hints.
We will be doing additional testing on Windows 7 RTM soon to make sure everything works properly there. If you are on Windows 7 RTM and you see a problem, let us know the exact steps you are using to reproduce it -- remember, we can't fix what we can' duplicate here.
The changes in this release range from the cosmetic (like adding our new registered trademark notation) to bug fixes to adding a minor new feature. The minor new feature was brought about by a customer suggestion and it was to provide the decimal representation of the input IP address on Subnet Calculator. Apparently our user sometimes hardcodes the IP address in a link and making it decimal makes it harder for bots to pick up the link.
Two of the bugs were seen during the August 12 webinar:
The first was when Laura was running a Continous Ping, then she pressed Stop and went into Setup. When she was talking about the various Ping options, the Continuous Ping started up again in the background results window. This was fixed.
The second thing I saw during the webinar was when Laura entered her favorite of the day hostname and it then went through and translated it to an IP address, then ran the IP address through the list of RBL servers. The problem was that the translated address was 255.255.255.255. Actually what had happened was the host to IP didn't resolve because there was no A record for the hostname in DNS. Now if this happens, it stops and tells you that it couldn't resolve for an IP.
If you want the full list of changes, you can install 10.93, then click on the Welcome left panel control, then click on Welcome to NetScanTools Pro icon. This will show a completely revamped page including the list of changes since the last release (10.92). There are also a few helpful hints.
We will be doing additional testing on Windows 7 RTM soon to make sure everything works properly there. If you are on Windows 7 RTM and you see a problem, let us know the exact steps you are using to reproduce it -- remember, we can't fix what we can' duplicate here.
Labels:
Laura Chappell,
NetScanTools Pro,
NetScanTools Pro USB Version,
new release,
webinar,
Windows 7
Friday, August 7, 2009
Windows 7 RTM on MSDN
They posted it yesterday and I just confirmed it's there. Now the decision for my OS testing system: do I erase the Vista 64 that's on there now and replace it with Win7 x64? Should I try upgrading it? if I erase it all the Virtual machine OS's will be destroyed and I'll have to rebuild them -- or maybe not -- I can just save the virtual OS files onto a backup and reinstall Virtual PC and reload them. And does Microsoft's Virtual PC 2007 run on Windows 7? I know it can host it. Questions...
Subscribe to:
Posts (Atom)