I'm forwarding to the list, a response that Mr. Conlin sent to me directly. He was experiencing some difficulty posting to the list, but I think that his comments are worth sharing with everyone. They are comprehensive and useful.
My comments are embedded inline - -----Original Message----- From: Paul Conlin [mailto:[EMAIL PROTECTED] Sent: Monday, June 09, 2008 8:12 AM To: [EMAIL PROTECTED] Subject: RE: [WISPA] User check program 1) To be an effective diagnostic tool I think it needs to report the bad news with the good so a timeout should show timeout. 999ms for the averaging is good. To try an avoid bad news you could retry all 3 pings if one of the ping results timeout. Maybe just one retry to get 3 valid results then show "timeout" in red text for those that didn't get a response. Only show a red ball if all 3 timeout. Yellow for 1 or 2 responses beyond the time threshold. - fair enough. I just remember how some users would tend to get upset if even a single "failure" was reported. 2) Include in the INI file the ping time threshold for green/yellow on a per item test. That way pings to a critical internal address such as DNS could go yellow at a lower time than say an email server which is hosted by a third party on the Internet. Something like "4. Connectivity to DNS Server #2, 10.10.1.15, 25" and "6. Connectivity to Email Server, 123.123.123.123, 50", where in these examples the 25 and 50 was the example threshold beyond which the result is a yellow ball. Red ball for a timeout. - The program is designed with threshold settings that can be custom set by the ISP. I can add an additional column to display the IP address of the server being tested in each step that would be useful. 3) Continue the green/yellow/red results indicator theme to the "My Internet Settings" items also. But I guess there would be no case for a yellow ball; only green or red. An IP Address 169.254.x.x, for example, should show a RED ball as that is a common failure. Include in the INI file a range of permittable addresses. It could be in the form of "address" and "mask" such as "192.168.0.0, 255.255.0.0" or "10.10.10.0, 255.255.255.0" so you could perform a logical 'AND' with the mask value before your comparison to determine if the result should be GREEN or RED. Additionally, "169.254.x.x" is such a common failure for IP Address that maybe such an address should show the result "No Address" in red text with a red ball instead of the bogus IP address. Same red "No Address" result if DNS, or Gateway is 0.0.0.0 / blank in the user's IP stack settings. - Had not considered this, but then again, I don't have the system deriving local IP address information yet. Right now, it only derives the customer's "Internet IP address". I'll see what I can do about pulling local IP settings and manipulating them, but that may be a round-two upgrade. 4) The "Connectivity to Default Gateway" test should be first as that hop is closer and makes it more obvious why subsequent tests would fail if the gateway ping fails. - I suppose that the connectivity tests could be set to perform in a dynamic order of the ISP's choosing. Probably also a round-two upgrade. 5) Allow the INI file to include the IP address to ping and the text of the test name to be changed easily. "4. Internet Connectivity Test, 64.233.169.103, 45, 80" could be changed to "4. Google Connectivity Test, 216.239.51.99, 50, 90" or something else if Google decides to stop responding to pings or their servers slow down someday. - The INI will definitely include the ability for the ISP to set the IP addresses to be tested for each and every test-location. I don't want every ISP in the country testing against MY settings ;-) 6) Add a DNS test that actually resolves an address from the DNS server application in addition to the ping test which only confirms connectivity with the DNS server computer. - I'll look into how to perform this test. It's a good idea. 7) How does the Network Speed Test work? Is there a specific file on the speed test server that the program downloads via http get? That would make it easy to change the length of the test. What about upload speed? I'm not sure users really care much about upload but I guess it could be added. - The speed test is an http "download" (get) of a file from a web server. Obviously, each ISP will want to place the test file on their web server so that no single ISP in the US is getting thousands of download test requests every day. I didn't build an upload... I could use some suggestions on this. I'm struggling with how to handle usernames and passwords (both for FTP and EMAIL authentication). I don't want to hard code the accounts into the compiled software and I ideally don't want to expose the account information in a clear text INI file. Ideas? 8) Text from the INI file for a default email address field for the customer send test results to. For example "[EMAIL PROTECTED]" already filled in the box. - This was one that I planned to add. I'll probably create a drop-down list which can be populated by the ini file. I hate trusting clients to correctly type in email addresses ;-) 9) Ability for the program to request a new INI file from the speed test server so we could remotely update a customer's check program without customer's intervention (beyond the initial installation of course). Automatic updating the check program executatable itself would be really nice but even just an update of the INI file would be huge! No server side program would be required as this could be as simple as downloading a file from a HTTP web server just prior to performing the check each and every time. First line in the INI file could have as username "1234smith" which would be used to download file "usercheck1234smith.dat" from the web server and save it on the local computer as "usercheck.ini". If there was no such .dat file on the speed test server computer then the original "usercheck.ini" file would remain. I guess the username would have to be entered by the user to customize it during installation. If a custom username was entered during installation then it should show somewhere on the test report and be included in the test results email. - I like the idea of checking for remote updates. Probably a round two upgrade, but definitely worth doing. 10) Add ping test for the "Tower". This allows the user to determine and differentiate from a failure somewhere in our network between them and the central DNS server. This could be the IP address of the AP they get service from or maybe a backhaul router. Logically, this test would be second, after the test for a gateway ping. If the INI file was customizable on a per user basis (see item 9 above) then this particular test could be unique to each customer. This test could be disabled and hidden for a standard install of the user check program and only appear if the INI file was customized for a particular customer. - This one will go hand-in-hand with #4. Rather than hard coding the test servers, I'll change the system to pull up a dynamic list of potential test targets from the ini file. 11) Add a line under the tech support phone number for a tech support email address such as "[EMAIL PROTECTED]" since emails are always better than phone calls...if you can get your customers trained to use that method. ;) Maybe make the address clickable to open a compose new email window to encourage customers to use this method! - YES YES YES... this will definitely be included in the FIRST CUT. 12) Have the program minimize itself to a notification area icon. Once minimized, a simple red, yellow, or green ball would show status all the time. Maybe periodically ping the backbone router and Internet connectivity IP addresses. To reduce flashes of "yellow" during network congestion I wouldn't compare the resulting ping times to determine green or yellow status of the notification area icon. I would just show green if both the backbone router and the Internet addresses respond to a ping, and yellow if only the backbone router replies. Red if the backbone router does not respond to the ping. - Neat idea, I don't know if you want every one of your wireless clients generative useless ICMP traffic all of the time. On an 802.11 network, having hundreds of meaningless ICMP requests running all of the time could severely impact performance. ALSO on networks with dynamic polling, the ICMP requests could screw up the polling algorithm and cause the AP to allocate time to dormant connections. I invite feedback on this one since there is a difference of opinion here. P.S. Anyone know how to minimize to tray and modify the tray icon in vb.net? That one's new on me. 13) Add a check box option for the customer to have the user check program automatically start when they start their computer. - Hmmm.... I hate start-up programs but I'll leave this one open to consensus as well. Would this be useful? Regards, Larry Yunker Network Consultant [EMAIL PROTECTED] > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Larry Yunker > Sent: Monday, June 09, 2008 4:34 AM > To: 'WISPA General List' > Subject: Re: [WISPA] User check program > > BTW, someone is bound to ask why the system shows 0ms in the > first test.... > that happens to be what VB.Net reports when a ping times-out > (right now I have it configured to treat timeouts as 999ms > for purposes of averaging). > I considered changing the display to show 999 or "timeout", > but then I thought about how the clients might get "upset" if > they see that sort of test result, so I just left it as > displaying 0ms. It's fairly easy change if anyone thinks it > should be changed. > > - Larry > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Larry Yunker > Sent: Monday, June 09, 2008 4:25 AM > To: 'WISPA General List' > Subject: Re: [WISPA] User check program > > How's this one look? I thought I'd put something together to > be used as a "user check" program. > > It's fully functional now, but I need to build an ini file > reader to hold each ISP's individualized settings I'll > probably knock that out on Tuesday. > then I'll try to publish it. If anyone sees something they > would like changed/added, let me know. > > > > > > > > Regards, > > Larry Yunker > > Network Consultant > > [EMAIL PROTECTED] > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Travis Johnson > Sent: Saturday, June 07, 2008 6:54 PM > To: WISPA General List; [EMAIL PROTECTED] > Subject: [WISPA] User check program > > > > Hi, > > > > I was wondering if anyone has written or seen a program that would do > > some basic "connectivity" checking for customers? I had the thought > > today that it would be really cool to have a simple program > people could > > download on their PC and then run that would do things like: > > > > (1) Ping to our backbone router via IP address (showing > latency results > > as well) > > (2) Ping our main DNS servers via IP address > > (3) Ping a domain name > > (4) Ping our main email server > > (5) Ping the customers default gateway > > (6) Show their configured IP address (both on the machine and on the > > Internet) > > (7) Speed test to our backbone (maybe just FTP a file from a local > > server and compute the time vs. file size?) > > (8) One additional button that would send all the results via > email to > > whatever email address they put in. > > > > It would need to be a nice, pretty interface with a single > button that > > says "Start". Then the results could show a Green Light for each item > > that was OK or a Red Light if there is a problem. It would > also be nice > > to have your company Logo and phone number on the interface. > > > > Is anyone up for this task? I would be willing to pay to have > something > > written, unless there is already something close out there? > > > > Travis > > Microserv > > > > > > -------------------------------------------------------------- > -------------- > ---- > > WISPA Wants You! Join today! > > http://signup.wispa.org/ > > -------------------------------------------------------------- > -------------- > ---- > > > > WISPA Wireless List: wireless@wispa.org > > > > Subscribe/Unsubscribe: > > http://lists.wispa.org/mailman/listinfo/wireless > > > > Archives: http://lists.wispa.org/pipermail/wireless/ > > > > > -------------------------------------------------------------- > ------------------ > WISPA Wants You! Join today! > http://signup.wispa.org/ > -------------------------------------------------------------- > ------------------ > > WISPA Wireless List: wireless@wispa.org > > Subscribe/Unsubscribe: > http://lists.wispa.org/mailman/listinfo/wireless > > Archives: http://lists.wispa.org/pipermail/wireless/ -------------------------------------------------------------------------------- WISPA Wants You! Join today! http://signup.wispa.org/ -------------------------------------------------------------------------------- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
