Good points Tom, particularly about the speed test. I also like the "hints" button for common trouble shooting suggestions. Tough to write the text, and harder to get the user to read it, but might reduce a few trouble calls.
Speaking from our perspective, we are looking for a small and simple diagnostic tool to help residential and small business users self diagnose the common problems, and to make it much easier for the level 1 help desk to work over the phone. Local Wi-Fi and other local gear are half the calls. Some per-user customization feature in addition the "global" settings common to all customers would be REALLY great. But what is really not all that important is the speed test. I'm not saying a speed test is not a valid testing tool in the right situation but we rarely see problems with a link that can't be seen with a ping test. Of course some customers *love* doing speed tests! That is another reason such tests cause more problems than they solve. As you pointed out, designing an accurate speed test is not trivial. I'm happy to see Larry has moved the speed test to a separate tab with a separate start button but I would really like to see an option to disable and hide the entire speed test tab with a setting in the .ini file. As someone else pointed out earlier in this thread, this testing tool might cause *more* trouble calls, not less, if it doesn't work correctly, or can't be tailored correctly for the particulars of a given network. Maybe Larry can make a second stand alone program for speed testing later, or the WISP can just host one of several that already exist and let the user run it from a browser. I would rather see Larry focus his limited time on a slick way to push customized settings out to each user. About this email address field where test results are sent. Why is this even needed? Results should be sent directly to a dedicated central address. Whoever is on duty handling tech calls can get the results as needed. This address can be set in the .ini file. There is no need for the user to send the results to his buddy or wherever. The program is branded and configured for the specific WISP and that network. No reason to have another setting for the user to mess up. Besides, emailing the results is fine for now but email is far from trouble free. Rarely do network problems prevent email from working but users break their own email clients all the time. Eventually it would be best if the results are written to a web server, or sent by ftp or maybe someday sent over a unique port directly to a specialized companion program Larry writes for a server at the NOC (rel 2 Larry ;). Thanks for your work on this Larry. It is looking very nice. We are excited to see it finished. PC Blaze Broadband > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Tom DeReggi > Sent: Friday, June 13, 2008 8:59 PM > To: WISPA General List > Subject: Re: [WISPA] User check program > > Two comments... > > When we diagnose a client, we are trying to discover six things... > > 1) Is the PC's Pri NIC active and configured for TCP IP > 2) Can they reach their home router > 3) Can they reach the first hop cell site/tower > 4) Can they reach the far side Backbone edge of network. > 5) Can they reach Internet. > 6) Is DNS resolving. > > So I suggest adding to the test, test to "self". Pinging its > own PC IP, to confirm NIC Cable plugged in, or interface > turned up. (Could be helpful even if two interfaces on PC, > ether and wireless) > > #3 is more tricky, because each client might have a different > tower IP. So this would have to be a custom set IP. It would > be left untested, if the ini file had not been configured > with a valid test IP. > I could see the installion tech adding in this IP at time of > install. But this is an essential test. It tells the End > user, whether it likely that their outage is unique to their > home. If they can get to the tower, but not further, they > know there is likely a network wide outage. It also tells the > end user to reboot the outdoor equipment. > > Secondly, I ask us to challenge why we want this tool most. > a) To test performance, or b) To locate failure points. > These are two very different purposes. I'd suggest that this > tool is most useful for option b. > > I would have the start test button for Speed test be a > sdifferent start button than the one that performs all the > other uptime tests. So a Speed test isn;t done everytime the > end user jsut wants to verify why they can't get to the Internet. > > I'd like to have a Disclaimer field right under the Speed > Test line, that was customizable by the ISP in the INI. For > example, I'd say... Speed test is just a basic test, to get a > detailed speed test, goto site at > www.xxxx.net. (I'm not saying you can;t make a good speed > test, but > speed testing can be very complicated. I'd hate to see this > valuable tool get delayed, attempting to optimize speed test > methods, or for the simplicity of the tool to be > compromised." If there is a place for a disclaimer, it could > reduce support calls, of I bought a 1.5mb, how come I'm > getting 1mb. I don;t want to bring that to their attention. > It might even be a good idea to have an ini setting that > allows the ISP to disable the speed test option. > > It could also be expanded by adding additional buttons to the > right of each Test. For example, the MAil Server Test, will > give the latency and accessibility of the Mail server. A > button could be to the right labled "test" or "Verify", and > then it launch a Telnet to port 25, and print the server response. > > It could be exspanded by having a "Hints" button to the right > of each test, to suggest ways to fix. > For example, if Gateway was not responding, it would suggest > a) check cabling, b) reboot Router, etc. > > Tom DeReggi > RapidDSL & Wireless, Inc > IntAirNet- Fixed Wireless Broadband > > > ----- Original Message ----- > From: "Tom DeReggi" <[EMAIL PROTECTED]> > To: "WISPA General List" <wireless@wispa.org> > Sent: Friday, June 13, 2008 6:01 PM > Subject: Re: [WISPA] User check program > > > > Super COOLNESS! > > > > I'd contribute some $ for that. > > > > Couple suggestions... > > > > 1) Emailing results was a great idea. But it would also be nice to have a > > second Email address that the test would go to. it could be a hidden filed > > defined in the ini file. > > the purpose would be to put the ISP's Tech Email in the second field. > > So > > everytime an end user did the test, a copy would get sent to the ISP also. > > That would solve two things. a) if bad results it would send proof to the > > ISP's tech. b) it would give techs an idea how frequently end users used > > the tool. > > > > 2) Assign each test, a test ID. It could just be a random generated > > number. > > That way the coipy emailed to the end user entered address, could be cross > > referenced and found in the ISP tech's Email. Ultimately, I'd create a > > designated ISP Email account to receive all these requests, and then it > > could be easilly looked up by test ID. > > > > 3) If the Tool uses Ping, make sure the Ping uses a large packet size, > > such > > as 1400bytes, so it gives a more meaningful latency or packetloss value. > > Might be good to be less than 1470 byte packet size, jsut to make sure > > someones customer VPN setting does not stop it from going through. Note: > > 64byte packets will often go through when a 1400 byte can't, so should use > > large packet for test. > > > > 4) Some radios that use polling such as Trango will have a high latency on > > the very first Ping only, if they haven't been passing data for a bit. > > What > > would be good is if it could be configured for the very first ping to be > > ignored, and not shown, and not averaged. > > > > 5) Have an update button, to download the latest update. Whether its an > > ini > > or the exe, that can get get downloaded. The reason is that ISPs often > > change their network design. The IP of edge of network very well may > > change. > > It could also be a tool to notify end users that their PC DNS > > configuration > > is no longer updated to the proper new DNS server. > > > > 6) connectivity to backbone router. Would like to have atleast two of > > these > > fields. Most ISPs will be multi-homed, and will want to show their end > > users > > that they can reach both Backbones/transits or edges of their network. > > > > Tom DeReggi > > RapidDSL & Wireless, Inc > > IntAirNet- Fixed Wireless Broadband > > > > > > ----- Original Message ----- > > From: "Larry Yunker" <[EMAIL PROTECTED]> > > To: "'WISPA General List'" <wireless@wispa.org> > > Sent: Monday, June 09, 2008 3:25 AM > > 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/
