So I'm not sure how it happened...after all the family left Thanksgiving evening, my oldest son somehow talked us into letting him buy an Xbox 360. I can't believe we actually let him -- I guess the turkey made us sleepy and dulled our minds. It's his money though -- not mine. He works as a dishwasher in one of those high end Sequim retirement homes. I guess that's our contribution to keeping Walmart in business in this weird economy.
If only I had learned how to write games instead of networking software.
We have a Black Friday sale going on too on our netscantools.com website.
Thursday, November 27, 2008
Friday, November 21, 2008
ENUM records
There are several DNS based registries (zones) where someone using VOIP can publish their SIP (or other) connection information. When a device like an IPPBX needs to connect to another internet phone or IPPBX, it can query DNS to find the service information.
For example, if you have a phone number you can query DNS in the e164.org, or e164.arpa namespaces (there are others) for DNS NAPTR records that describe how to connect to the machine handling the phone number. If the number has been registered in DNS, you will get the service type and a regular expression (regex) defining how the connection is to be made. The regex will have a portion delimited by the exclamation point character called a URI, typically in the format !sip:somenumberorstring@exampledomain.net! -- this part is used along with the service type to make the connection to the machine receiving the phone call via SIP or H323.
Our freeware ENUMresolver make it easy to see if the records are in DNS and it displays their format. It accepts a telephone number and can query your default DNS or a specific DNS for the records and displays them. You must include the country code in front of the phone number. Numbers in the North American Numbering Plan (US/Canada/Carribean) need to include the number "1" in front of the phone: 1 (360) 999-9999 is acceptable US format in ENUMresolver.
We just released v2.00 on November 19, so you can now tell it to query a specific DNS and it also has a list of root zones for you to select from -- of course you can enter any root zone you want.
You can get it at our freeware page.
For example, if you have a phone number you can query DNS in the e164.org, or e164.arpa namespaces (there are others) for DNS NAPTR records that describe how to connect to the machine handling the phone number. If the number has been registered in DNS, you will get the service type and a regular expression (regex) defining how the connection is to be made. The regex will have a portion delimited by the exclamation point character called a URI, typically in the format !sip:somenumberorstring@exampledomain.net! -- this part is used along with the service type to make the connection to the machine receiving the phone call via SIP or H323.
Our freeware ENUMresolver make it easy to see if the records are in DNS and it displays their format. It accepts a telephone number and can query your default DNS or a specific DNS for the records and displays them. You must include the country code in front of the phone number. Numbers in the North American Numbering Plan (US/Canada/Carribean) need to include the number "1" in front of the phone: 1 (360) 999-9999 is acceptable US format in ENUMresolver.
We just released v2.00 on November 19, so you can now tell it to query a specific DNS and it also has a list of root zones for you to select from -- of course you can enter any root zone you want.
You can get it at our freeware page.
Friday, November 14, 2008
dig +trace
If you are curious about how DNS works, you probably should have a look at dig +trace. Dig +trace gives you a hierarchical listing of the DNS servers responsible for each level of a domain name.
The tool starts by going to the top level name servers (you know, the 13 root servers that make DNS work) and asking for the top level domain name servers for .com or .net or .uk or .whatever. Then it picks one of those top level servers and asks for the servers responsible for the next level, like netscantools.com, etc. It does this until it finds the authoritative servers for the hostname or domain name or IP address you entered.
It's great for getting a top down view of how the DNS system works. You can also see if there are problems finding the authoritative servers. You can do this from the unix/linux command line (dig hostname +trace) or from our software.
Here is an example using www.microsoft.com as an input to NetScanTools Pro's Name Server Lookup tool:
[Start Query]
DiG Starting Timestamp: 11/14/08 21:03:54
; <<>> DiG 9.x <<>> www.microsoft.com +trace
. 65326 IN NS a.root-servers.net
. 65326 IN NS b.root-servers.net
{snip}
;; Received 228 bytes from 208.200.248.8 (208.200.248.8) in 63 ms
com. 172800 IN NS H.GTLD-SERVERS.NET
com. 172800 IN NS I.GTLD-SERVERS.NET
{snip}
;; Received 509 bytes from a.root-servers.net (198.41.0.4) in 140 ms
(note: these are the authoritative domain servers for handling the queries for hostnames in the microsoft.com domain)
microsoft.com. 172800 IN NS ns1.msft.net
microsoft.com. 172800 IN NS ns2.msft.net
microsoft.com. 172800 IN NS ns3.msft.net
microsoft.com. 172800 IN NS ns4.msft.net
microsoft.com. 172800 IN NS ns5.msft.net
;; Received 209 bytes from H.GTLD-SERVERS.NET (192.54.112.30) in 234 ms
www.microsoft.com. 3600 IN CNAME toggle.www.ms.akadns.net
;; Received 73 bytes from ns1.msft.net (207.68.160.190) in 62 ms
[End Query]
With each level, you can see that a number was returned. This is the TTL (time-to-live) for the DNS record in seconds. If you do the dig +trace query again, the numbers for the root servers will be smaller reflecting the time you took between queries.
You can see that ns1 told us that www.microsoft.com is aliased to a server handled by Akamai. It did not tell us the IP address -- we did an 'ANY' query and the CNAME record was all that was returned to us.
The tool starts by going to the top level name servers (you know, the 13 root servers that make DNS work) and asking for the top level domain name servers for .com or .net or .uk or .whatever. Then it picks one of those top level servers and asks for the servers responsible for the next level, like netscantools.com, etc. It does this until it finds the authoritative servers for the hostname or domain name or IP address you entered.
It's great for getting a top down view of how the DNS system works. You can also see if there are problems finding the authoritative servers. You can do this from the unix/linux command line (dig hostname +trace) or from our software.
Here is an example using www.microsoft.com as an input to NetScanTools Pro's Name Server Lookup tool:
[Start Query]
DiG Starting Timestamp: 11/14/08 21:03:54
; <<>> DiG 9.x <<>> www.microsoft.com +trace
. 65326 IN NS a.root-servers.net
. 65326 IN NS b.root-servers.net
{snip}
;; Received 228 bytes from 208.200.248.8 (208.200.248.8) in 63 ms
com. 172800 IN NS H.GTLD-SERVERS.NET
com. 172800 IN NS I.GTLD-SERVERS.NET
{snip}
;; Received 509 bytes from a.root-servers.net (198.41.0.4) in 140 ms
(note: these are the authoritative domain servers for handling the queries for hostnames in the microsoft.com domain)
microsoft.com. 172800 IN NS ns1.msft.net
microsoft.com. 172800 IN NS ns2.msft.net
microsoft.com. 172800 IN NS ns3.msft.net
microsoft.com. 172800 IN NS ns4.msft.net
microsoft.com. 172800 IN NS ns5.msft.net
;; Received 209 bytes from H.GTLD-SERVERS.NET (192.54.112.30) in 234 ms
www.microsoft.com. 3600 IN CNAME toggle.www.ms.akadns.net
;; Received 73 bytes from ns1.msft.net (207.68.160.190) in 62 ms
[End Query]
With each level, you can see that a number was returned. This is the TTL (time-to-live) for the DNS record in seconds. If you do the dig +trace query again, the numbers for the root servers will be smaller reflecting the time you took between queries.
You can see that ns1 told us that www.microsoft.com is aliased to a server handled by Akamai. It did not tell us the IP address -- we did an 'ANY' query and the CNAME record was all that was returned to us.
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.
Wednesday, October 22, 2008
Satellite TV R.I.P.
I watched most of the last presidential debate a week ago (boring...). I turned off the TV and came back later at 11 to watch the news. I turned on the TV and the satellite box as usual. No news. The TV worked fine but all I saw was error 015 Acquiring Satellite Signal with no progress being made -- it kept endlessly cycling through the satellites and the transponders. I tried resetting it but that didn't work.
So the next day I checked all the wiring inside and out. Then I called tech support. I tried the computerized voice command help. That was just plain weird and entirely unhelpful. I asked the computer for a technician (more weirdness). The first guy I got sounded Irish and far away. He probably was in Ireland. So I gave him my account details and he immediately said he could not (or would not) help me and he would transfer me to someone who would. Then I was promptly hung up on.
I called back and got someone in India. How do I know that? I didn't have to ask because she sounded far away and I've worked side by side with people from India before. She was helpful and walked me through the same simple tests I had already done, but our conclusion was something had failed. So she offered to schedule an appointment with a technician. I asked how much that was going to cost: $49.95 just for the tech to show up because we didn't spend $7 a month on insurance. And the costs would go up from there. I said no thanks, we would think about it.
We didn't think for long. It turns out that over the last 8 years since we got it, the TV viewing in our house has dropped precipitously. The only thing being watched was the 11 O'clock news and the first half of Jay Leno (the Seahawks weren't being watched this year). This is entirely due to the internet. I spend my full day on the internet, then some of the evening if I have to. News is at the click of a mouse whenever I want to look. And now all the TV networks have current and classic shows available to watch whenever I want to see them, not when satellite has them on. We had become more and more disappointed with the channel selection. The 500 or so channels we got were filled with boring shopping channels, infomercials, foreign language channels and duplicate shows all over the place. And PPV for about half of the rest.
So last Friday we simply said we were done and I cancelled the satellite by talking to someone in the US -- what a concept -- someone on the same continent! Now we save $40 a month that we can use to buy a whole year's TV series or a couple of movies each month. And we don't care about the Feb 2009 HDTV switchover now.
Freedom.
By the way, this has nothing to do with NetScanTools.
So the next day I checked all the wiring inside and out. Then I called tech support. I tried the computerized voice command help. That was just plain weird and entirely unhelpful. I asked the computer for a technician (more weirdness). The first guy I got sounded Irish and far away. He probably was in Ireland. So I gave him my account details and he immediately said he could not (or would not) help me and he would transfer me to someone who would. Then I was promptly hung up on.
I called back and got someone in India. How do I know that? I didn't have to ask because she sounded far away and I've worked side by side with people from India before. She was helpful and walked me through the same simple tests I had already done, but our conclusion was something had failed. So she offered to schedule an appointment with a technician. I asked how much that was going to cost: $49.95 just for the tech to show up because we didn't spend $7 a month on insurance. And the costs would go up from there. I said no thanks, we would think about it.
We didn't think for long. It turns out that over the last 8 years since we got it, the TV viewing in our house has dropped precipitously. The only thing being watched was the 11 O'clock news and the first half of Jay Leno (the Seahawks weren't being watched this year). This is entirely due to the internet. I spend my full day on the internet, then some of the evening if I have to. News is at the click of a mouse whenever I want to look. And now all the TV networks have current and classic shows available to watch whenever I want to see them, not when satellite has them on. We had become more and more disappointed with the channel selection. The 500 or so channels we got were filled with boring shopping channels, infomercials, foreign language channels and duplicate shows all over the place. And PPV for about half of the rest.
So last Friday we simply said we were done and I cancelled the satellite by talking to someone in the US -- what a concept -- someone on the same continent! Now we save $40 a month that we can use to buy a whole year's TV series or a couple of movies each month. And we don't care about the Feb 2009 HDTV switchover now.
Freedom.
By the way, this has nothing to do with NetScanTools.
Monday, October 13, 2008
DHCP Servers
People have asked me to talk a bit about the DHCP Servers. As you probably know, DHCP is used on networks to automatically assign IP addresses to client computers (or devices) that connect to the network.
When a client without an IP address starts up on the network, it sends a DHCP_DISCOVER message. The DHCP server replies with a DHCP_OFFER to that client. The client then sends back a DHCP_REQUEST and the server acknowledges with a DHCP_ACK. Once this sequence is complete, the client can use that IP address for the duration of the time period contained in the offer packet.
Our DHCP Server Discovery Tool sends the DHCP_DISCOVER message and displays the returning DHCP_OFFERs. That means if you have more than one DHCP server on your network, you can see all of them and the information they are offerring.
Why is it important to see all the DHCP servers? Several reasons.
One is accidental conflicts. Two DHCP servers might be offerring overlapping ranges of IP addresses. This is not a good situation and could happen if a new device is put into the network that contains an active DHCP server that is active by default. Actiontec DSL routers, Windows Servers and Linux systems can all run DHCP servers.
Another similar situation that might occur is when a new device with an active DHCP server is added to a network by being moved from a previous location (a recycled device) and that device had a DHCP server offering a range of IP addresses from a different subnet than the subnet it is being moved to. Devices requesting new IP addresses might be offered an IP for a different (incorrect) subnet by the second DHCP server. This would mean that any device successfully obtaining an IP address from the new server would be prevented from talking on the network it is attached to because the IP address it has obtained is not within the subnet. This could be classified as a rogue server.
Another more dangerous scenario is when a "rogue" server is added for the specific purpose of offering legitimate IP addresses, while at the same time offering the IP address of a malicious DNS or router. The DHCP_OFFER packets contain more than just the offered IP address, they contain many other optional fields like DNS and router IPs.
Our DHCP Server Discovery Tool shows all the responding servers and the information they are offering including the IP address, subnet mask, DNS IPs, Router IPs, lease times etc. This way you can see the parameters and decided for yourself whether the information is correct -- especially if you find a second DHCP server on your network.
When a client without an IP address starts up on the network, it sends a DHCP_DISCOVER message. The DHCP server replies with a DHCP_OFFER to that client. The client then sends back a DHCP_REQUEST and the server acknowledges with a DHCP_ACK. Once this sequence is complete, the client can use that IP address for the duration of the time period contained in the offer packet.
Our DHCP Server Discovery Tool sends the DHCP_DISCOVER message and displays the returning DHCP_OFFERs. That means if you have more than one DHCP server on your network, you can see all of them and the information they are offerring.
Why is it important to see all the DHCP servers? Several reasons.
One is accidental conflicts. Two DHCP servers might be offerring overlapping ranges of IP addresses. This is not a good situation and could happen if a new device is put into the network that contains an active DHCP server that is active by default. Actiontec DSL routers, Windows Servers and Linux systems can all run DHCP servers.
Another similar situation that might occur is when a new device with an active DHCP server is added to a network by being moved from a previous location (a recycled device) and that device had a DHCP server offering a range of IP addresses from a different subnet than the subnet it is being moved to. Devices requesting new IP addresses might be offered an IP for a different (incorrect) subnet by the second DHCP server. This would mean that any device successfully obtaining an IP address from the new server would be prevented from talking on the network it is attached to because the IP address it has obtained is not within the subnet. This could be classified as a rogue server.
Another more dangerous scenario is when a "rogue" server is added for the specific purpose of offering legitimate IP addresses, while at the same time offering the IP address of a malicious DNS or router. The DHCP_OFFER packets contain more than just the offered IP address, they contain many other optional fields like DNS and router IPs.
Our DHCP Server Discovery Tool shows all the responding servers and the information they are offering including the IP address, subnet mask, DNS IPs, Router IPs, lease times etc. This way you can see the parameters and decided for yourself whether the information is correct -- especially if you find a second DHCP server on your network.
Stock Market Up Finally!
936 points up is amazing considering the drop over last week. Does it mean a turn-around? I don't know. I want to see a trend develop first. Hopefully it means something positive.
I would like to take issue with some of these columnists that say the losses were all on money that never existed. My 401K was down just to the amount of moneys that I put in there. Not fake imaginary money. Real money.
I would like to take issue with some of these columnists that say the losses were all on money that never existed. My 401K was down just to the amount of moneys that I put in there. Not fake imaginary money. Real money.
Subscribe to:
Posts (Atom)