Re: [WISPA] User check program
Larry, Is this on the market yet? how could I get a copy to test? Ron Wallace Hahnron, Inc. 220 S. Jackson Dt. Addison, MI 49220 Phone: (517)547-8410 Mobile: (517)270-2410 e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: Larry Yunker [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2008 04:28 PM To: ''WISPA General List'' Subject: Re: [WISPA] User check program It also means the program doesn't work with no Windows computers, which are increasingly gaining market share. True... I don't have a Mac, so I can't building for that market. While I could and probably will build something for Linux eventually, it seems irrelevant. If your client has Linux, they probably know enough about routing so that this software is unnecessary. Or if that's not possible, does anyone have any suggestions as to other visual languages which DO NOT USE .NET and which might be used for future ports of this application. Java. But JAVA requires that a Java VM be installed on the PC. The point is to avoid having to install a separate Framework. Ideally, I'd like a linker that would just compile in those components within .NET that I rely upon. 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/
Re: [WISPA] User check program
Oh yes, and where can i get more info on the User check program? Ron Wallace Hahnron, Inc. 220 S. Jackson Dt. Addison, MI 49220 Phone: (517)547-8410 Mobile: (517)270-2410 e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: Larry Yunker [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2008 04:28 PM To: ''WISPA General List'' Subject: Re: [WISPA] User check program It also means the program doesn't work with no Windows computers, which are increasingly gaining market share. True... I don't have a Mac, so I can't building for that market. While I could and probably will build something for Linux eventually, it seems irrelevant. If your client has Linux, they probably know enough about routing so that this software is unnecessary. Or if that's not possible, does anyone have any suggestions as to other visual languages which DO NOT USE .NET and which might be used for future ports of this application. Java. But JAVA requires that a Java VM be installed on the PC. The point is to avoid having to install a separate Framework. Ideally, I'd like a linker that would just compile in those components within .NET that I rely upon. 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] New laptop battery
I'm looking for a new battery for my Dell Inspiron 6400. Dell wants $300. Any recommendations? I don't want some cheap piece of crap from China that'll just die in 6 months. I was looking towards Interstate for $150 that has a similar capacity to my Dell (when new). -- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com 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/
Re: [WISPA] New laptop battery
You could try batteryrefill.com - They did a good job with an old vaio battery, but the refill of my lenovo battery is taking wayy too long because shipments of the cells from China or whereever have been delayed. Just ask them up front for timeframe. On Fri, Jun 13, 2008 at 10:36 AM, Mike Hammett [EMAIL PROTECTED] wrote: I'm looking for a new battery for my Dell Inspiron 6400. Dell wants $300. Any recommendations? I don't want some cheap piece of crap from China that'll just die in 6 months. I was looking towards Interstate for $150 that has a similar capacity to my Dell (when new). -- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com 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/ -- Dylan Oliver Primaverity, LLC Sweeping Design LLC 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/
Re: [WISPA] ip accounting solns
Marlon, Please expand. What solution are you speaking of? any link or contact info? Thanks On Thu, Jun 12, 2008 at 9:58 AM, Marlon K. Schafer [EMAIL PROTECTED] wrote: Brandon has the best solution out there. It's also cost effective. marlon - Original Message - From: Rogelio [EMAIL PROTECTED] To: WISPA General List wireless@wispa.org Sent: Wednesday, June 11, 2008 11:28 PM Subject: [WISPA] ip accounting solns Anyone here use any IP accounting solutions? Say you have one IP hog. How do you find them and alert on that? (Yes, I know about tools like MRTG, but I'm wondering if others have any other more comprehensive solutions) 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/
Re: [WISPA] New laptop battery
Where do you think all the GOOD stuff comes from, as well??? ;) Anyway... Dell did tell me that the reason their batteries are so expensive right now is that a major battery manufacturing plant burned down. I had to buy 7 $300 (extra-to-hold-in-the-laptop-bag-in-case-the-main-battery-runs-out) batteries for some CPAs that I support, because they had a laptop theft within the building. It was creepy watching those guys on camera roam throughout the building... Mark Nash UnwiredWest 78 Centennial Loop Suite E Eugene, OR 97401 541-998- 541-998-5599 fax http://www.unwiredwest.com - Original Message - From: Mike Hammett [EMAIL PROTECTED] To: WISPA List wireless@wispa.org Sent: Friday, June 13, 2008 8:36 AM Subject: [WISPA] New laptop battery I'm looking for a new battery for my Dell Inspiron 6400. Dell wants $300. Any recommendations? I don't want some cheap piece of crap from China that'll just die in 6 months. I was looking towards Interstate for $150 that has a similar capacity to my Dell (when new). -- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com -- -- 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/
Re: [WISPA] New laptop battery
Try this place I have ordered from them before http://www.laptopparts.com/. The price would be $129 thats with out shipping. James I'm looking for a new battery for my Dell Inspiron 6400. Dell wants $300. Any recommendations? I don't want some cheap piece of crap from China that'll just die in 6 months. I was looking towards Interstate for $150 that has a similar capacity to my Dell (when new). -- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com 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/
Re: [WISPA] multiple gateway question in mesh scenario
Rogelio wrote: I would like roaming, actually. Ideally, the entire mesh would be on the same LAN subnet and each user would be assigned the gateway that was the least congested. I think that pfsense is probably the easiest answer, particularly since it has hotspot URL forwarding built into the easy install Here is a feature list, for those who'd like to know more about it http://tinyurl.com/3a3cd6 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/
Re: [WISPA] multiple gateway question in mesh scenario
I guess one question would be is it a Layer 2 or Layer 3 mesh? That would influence what options you have. -Matt On Fri, 2008-06-13 at 10:43 -0700, Rogelio wrote: Rogelio wrote: I would like roaming, actually. Ideally, the entire mesh would be on the same LAN subnet and each user would be assigned the gateway that was the least congested. I think that pfsense is probably the easiest answer, particularly since it has hotspot URL forwarding built into the easy install Here is a feature list, for those who'd like to know more about it http://tinyurl.com/3a3cd6 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] Nominations site updated
The applications for all eligible nominees for the 2008 WISPA Board of Directors have been posted at http://nominations.wispa.org/ . As there are a number of qualified candidates, the Board wishes all members to have ample time to carefully consider their votes. Thus, the Board has moved the 2008 election back one week. The 2008 Board election will now take place on June 23-24, 2008. David Smith 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] XR9 separation from other 2.4 stuff
It is my understanding that the 900mhz cards are actually 2.4ghz with converters built in. So obviously putting a 900mhz card on the same board as a 2.4ghz card would be a bad idea. Now can I put them on the same tower? Lets say I put the 900mhz radio at the bottom and run some coax since 900mhz should have much less cable loss I should be able to do this. I'll leave the 2.4 stuff up top. But will the 900mhz antenna mounted in close proximity to the 2.4 antenna pick up the 2.4 and allow it to still cause interference to the radio below? Also would putting a 900mhz filter before the radio solve this? Kurt Fankhauser WAVELINC P.O. Box 126 Bucyrus, OH 44820 419-562-6405 www.wavelinc.com 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] Board Member Candidates list
WISPA Members, As Secretary of WISPA I am proud to announce the 12 qualified WISPA members that have applied and met the hurdle criteria for a seat on the Board of Directors. The Board of Directors met this morning and went over each application to ensure that the hurdle criteria had been met according to WISPA Bylaws. The following list contains the qualified WISPA members who are eligible to seek a seat on the 2008 Board of Directors. WISPA BOARD CANDIDATES to be considered: (alphabetical by first name) Dennis Burgess Frank Muto George Rogato Jack Unger Jeff Crews John Scrivner Mac Dearman Matt Larsen Michael Steed Rick Harnish Tom DeReggi Tony Morella My first thoughts are to thank each and every one of these men who filled out an application - - those who met the criteria and deemed eligible as well as those who did not qualify due to not meeting the hurdle criteria for election possibilities this year. If we didn't have these guys - we wouldn't have any options for our future leadership. 7 of the 12 will be elected to a seat on the board. For those of us who may not be (re-elected) elected this time around I would like to thank you for your dedication, decision and willingness to assist in this role. Good Luck to all. A link to the WISPA website with each candidate's application will be posted to list for consideration of your vote as soon as the information is uploaded to the server and made available later today. The election process of WISPA board should be taken to heart and every WISPA member should be sure to cast their vote. Voting dates have been set by the current WISPA board and election will take place June 23 24. More information about voting, how to vote and what to look for via your email address will be posted to this list as the week progresses. Sincerely, Mac Dearman WISPA Secretary 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/
Re: [WISPA] XR9 separation from other 2.4 stuff
* Kurt Fankhauser wrote, On 6/13/2008 3:56 PM: It is my understanding that the 900mhz cards are actually 2.4ghz with converters built in. So obviously putting a 900mhz card on the same board as a 2.4ghz card would be a bad idea. Now can I put them on the same tower? Lets say I put the 900mhz radio at the bottom and run some coax since 900mhz should have much less cable loss I should be able to do this. I'll leave the 2.4 stuff up top. But will the 900mhz antenna mounted in close proximity to the 2.4 antenna pick up the 2.4 and allow it to still cause interference to the radio below? Also would putting a 900mhz filter before the radio solve this? Hi Kurt...we're currently doing this. We have two 2.4 cards and an SR9 in one box at the top of a tower. On the same tower, lower down, we have a box with two SR9s in it. I thought at first we might have some problems but I think if you are shielded and the connections are good and tight you shouldn't have much of a problem. If you want to isolate physically then that shouldn't be an issue IMHO. LEoN Kurt Fankhauser WAVELINC P.O. Box 126 Bucyrus, OH 44820 419-562-6405 www.wavelinc.com 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/
Re: [WISPA] XR9 separation from other 2.4 stuff
We've also collocated 2.4GHz and 900MHz radios using 2.4GHz frequency up/down converters in the same enclosure before without issues. The 900MHz radios implemented with the up/down converters have pretty good filters that block non-900MHz frequencies. On Fri, 2008-06-13 at 16:15 -0400, Leon D. Zetekoff, NCE wrote: * Kurt Fankhauser wrote, On 6/13/2008 3:56 PM: It is my understanding that the 900mhz cards are actually 2.4ghz with converters built in. So obviously putting a 900mhz card on the same board as a 2.4ghz card would be a bad idea. Now can I put them on the same tower? Lets say I put the 900mhz radio at the bottom and run some coax since 900mhz should have much less cable loss I should be able to do this. I'll leave the 2.4 stuff up top. But will the 900mhz antenna mounted in close proximity to the 2.4 antenna pick up the 2.4 and allow it to still cause interference to the radio below? Also would putting a 900mhz filter before the radio solve this? Hi Kurt...we're currently doing this. We have two 2.4 cards and an SR9 in one box at the top of a tower. On the same tower, lower down, we have a box with two SR9s in it. I thought at first we might have some problems but I think if you are shielded and the connections are good and tight you shouldn't have much of a problem. If you want to isolate physically then that shouldn't be an issue IMHO. LEoN Kurt Fankhauser WAVELINC P.O. Box 126 Bucyrus, OH 44820 419-562-6405 www.wavelinc.com 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/
Re: [WISPA] star os config help- clarifying my message
that we MUST put PRINTED information in the hands of our installers on the equipment that we use ( When you are done with that printed guide, why not post it to the Forum :-) Tom DeReggi RapidDSL Wireless, Inc IntAirNet- Fixed Wireless Broadband - Original Message - From: Mark Nash [EMAIL PROTECTED] To: WISPA General List wireless@wispa.org Sent: Wednesday, June 11, 2008 10:42 AM Subject: Re: [WISPA] star os config help- clarifying my message I agree with you, Marlon on the documentation/ease-of-use. I gave up using Tranzeos for StarOS because of its flexibility and powerful boards and the atheros driver available creating an environment with extremely low latency. Tranzeos were/are super-easy. With StarOS, I've gotten over alot of the learning curve, but there is still more to learn. It's for geeks...but once you're there, you're in pretty good shape. My biggest issue as of late is that I have a problem remembering which power supply goes to which board, and remembering which of two ethernet ports is the PoE port on each different type of board. Documentation for StarOS and the equipment it supports is lacking. Just last week I told our engineer that we MUST put PRINTED information in the hands of our installers on the equipment that we use (what power supply to use, which is the PoE ports, which boards can handle the high-powered cards and how many, etc). The equipment and software is very very good, but you have to be at least a semi-geek to understand it. Mark Nash UnwiredWest 78 Centennial Loop Suite E Eugene, OR 97401 541-998- 541-998-5599 fax http://www.unwiredwest.com - Original Message - From: Marlon K. Schafer [EMAIL PROTECTED] To: WISPA General List wireless@wispa.org Sent: Wednesday, June 11, 2008 8:31 AM Subject: Re: [WISPA] star os config help- clarifying my message I have more and more trouble justifying the cost of any product with a steep learning curve. There's just no reason for gear to not have a simple and advanced mode these days. And there's no reason for documentation that doesn't cover simple questions. There's no reason to NOT have a quick start guide. There's no reason to have a box that doesn't do something right out of the box (this one shipped with all wireless ports disabled!). There's no reason to not have the option of picking up the phone and getting some help to get started. Now I'm DAYS into a project that should have taken just a few minutes. There was no documentation in the box. Not even the web site address, had to Google for it. There is no tech support number on the web site. I guess if a company wants to stay small, have a small user base etc. this is all good. You only get really tech savvy customers. Something that I'm not when it comes to routing and command line. I've got a very lean fast growing company. I have over a dozen brands of hardware deployed. They all do things differently. I have long ago given up on trying to memorize all of this crap. If it's not completely self explanatory (like 802.1d bridging actually turning on bridging) I don't have time to play with the gear. It doesn't really matter how good it is. For the record I've got the same bitch with MT. I can do a little bit more with them because they at least have a decent gui. But most of what I do with them is due to Butch's help. He's great but having to hire him all of the time raises the cost of the gear by a lot. All because I don't have the option of a Linksys simple setup option Dumb. Very dumb. Alvarion has work to do too. They use strange names for functions. Don't give typical levels as examples right in the software. I mean really, how am I supposed to know if 10, 1000 or -50 is a good number to try for interference mitigation? And which settings would I tweak for which things? Who the heck has time to read yet another 150+++ page manual? Put the basics right in the software! sigh marlon - Original Message - From: George Rogato [EMAIL PROTECTED] To: WISPA General List wireless@wispa.org Sent: Wednesday, June 11, 2008 6:56 AM Subject: Re: [WISPA] star os config help- clarifying my message Not really trying to defend star. The documentation issue has been around since Adam met Eve. The learning curve appears to be steep, but in fact, there is pretty good documentation. If you search the forums, you will pretty much find anything you need to know. Trick is first searching the forums. Then there is Tog's WiKi that is pretty good. Tog has put a lot of time into the WiKi and helping others with their star stuff. One thing I might add, one reason it's hard to document star, it's always changing, and how do you document l7 filtering or isc dhcp easily? Fortunately Tog and a few other smart guys hang out there and try to offer their help when they can. Good luck
Re: [WISPA] XR9 separation from other 2.4 stuff
Kurt Your just going to want to stay off the same channel as the xr9 and you will be ok. Kurt Fankhauser wrote: It is my understanding that the 900mhz cards are actually 2.4ghz with converters built in. So obviously putting a 900mhz card on the same board as a 2.4ghz card would be a bad idea. Now can I put them on the same tower? Lets say I put the 900mhz radio at the bottom and run some coax since 900mhz should have much less cable loss I should be able to do this. I'll leave the 2.4 stuff up top. But will the 900mhz antenna mounted in close proximity to the 2.4 antenna pick up the 2.4 and allow it to still cause interference to the radio below? Also would putting a 900mhz filter before the radio solve this? Kurt Fankhauser WAVELINC P.O. Box 126 Bucyrus, OH 44820 419-562-6405 www.wavelinc.com 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/
Re: [WISPA] star os config help- clarifying my message
They're so right about not bridging Thats a short sighted opinion. In theory, for the benefit of their Box, maybe yes. And I'm not challenging the many benefits to routing. But everyone doesn't use the box for the same purpose. Not true for many appilications. For example, what about standardized or central management and provisioning? For larger ISPs, the STAROS box is not the place that manages the customers, they have a second high performance router that the StarOS box attaches to. There are many preferred applications for layer2 redunancy (spanning tree). OFtne a network design does not start with STAROS, but STAROS gets injected into a pre-existing design. Tom DeReggi RapidDSL Wireless, Inc IntAirNet- Fixed Wireless Broadband - Original Message - From: [EMAIL PROTECTED] To: WISPA General List wireless@wispa.org Sent: Wednesday, June 11, 2008 11:40 AM Subject: Re: [WISPA] star os config help- clarifying my message Marlon, I have been using Star-OS since the beginning here. Means four years of using it. It is the fastest, easiest, and best performing of anything I've tried. They're so right about not bridging, but if you need any assistance, give me a shout. It's not even that far if you want a hands on demo on how to set things up, and I don't mind making the trip. Mark insert witty tagline here - Original Message - From: Marlon K. Schafer [EMAIL PROTECTED] To: WISPA General List wireless@wispa.org Sent: Wednesday, June 11, 2008 8:31 AM Subject: Re: [WISPA] star os config help- clarifying my message I have more and more trouble justifying the cost of any product with a steep learning curve. There's just no reason for gear to not have a simple and advanced mode these days. And there's no reason for documentation that doesn't cover simple questions. There's no reason to NOT have a quick start guide. There's no reason to have a box that doesn't do something right out of the box (this one shipped with all wireless ports disabled!). There's no reason to not have the option of picking up the phone and getting some help to get started. Now I'm DAYS into a project that should have taken just a few minutes. There was no documentation in the box. Not even the web site address, had to Google for it. There is no tech support number on the web site. I guess if a company wants to stay small, have a small user base etc. this is all good. You only get really tech savvy customers. Something that I'm not when it comes to routing and command line. I've got a very lean fast growing company. I have over a dozen brands of hardware deployed. They all do things differently. I have long ago given up on trying to memorize all of this crap. If it's not completely self explanatory (like 802.1d bridging actually turning on bridging) I don't have time to play with the gear. It doesn't really matter how good it is. For the record I've got the same bitch with MT. I can do a little bit more with them because they at least have a decent gui. But most of what I do with them is due to Butch's help. He's great but having to hire him all of the time raises the cost of the gear by a lot. All because I don't have the option of a Linksys simple setup option Dumb. Very dumb. Alvarion has work to do too. They use strange names for functions. Don't give typical levels as examples right in the software. I mean really, how am I supposed to know if 10, 1000 or -50 is a good number to try for interference mitigation? And which settings would I tweak for which things? Who the heck has time to read yet another 150+++ page manual? Put the basics right in the software! sigh marlon - Original Message - From: George Rogato [EMAIL PROTECTED] To: WISPA General List wireless@wispa.org Sent: Wednesday, June 11, 2008 6:56 AM Subject: Re: [WISPA] star os config help- clarifying my message Not really trying to defend star. The documentation issue has been around since Adam met Eve. The learning curve appears to be steep, but in fact, there is pretty good documentation. If you search the forums, you will pretty much find anything you need to know. Trick is first searching the forums. Then there is Tog's WiKi that is pretty good. Tog has put a lot of time into the WiKi and helping others with their star stuff. One thing I might add, one reason it's hard to document star, it's always changing, and how do you document l7 filtering or isc dhcp easily? Fortunately Tog and a few other smart guys hang out there and try to offer their help when they can. Good luck Ralph. George ralph wrote: I just re-read it and need to clarify. I put addresses from the same subnet on all interfaces because it seemed that an address was required per the blanks to fill in. It was never documented to only put an address on one interface. With other products,
Re: [WISPA] good multiradio wifi units for noise environments?
No amplifier reduces noise. An amplifier always injects noise. A low noise amplifier will inject less noise, and cause less noise for others. But I'd argue the goal is to avoid amplifiers all togeather. Tom DeReggi RapidDSL Wireless, Inc IntAirNet- Fixed Wireless Broadband - Original Message - From: Rogelio [EMAIL PROTECTED] To: WISPA General List wireless@wispa.org Sent: Thursday, June 12, 2008 8:14 AM Subject: Re: [WISPA] good multiradio wifi units for noise environments? Jack Unger wrote: Noise is noise and will destroy performance on any radio. Might low noise amplifiers help in these situations? http://en.wikipedia.org/wiki/Low-noise_amplifier 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/
Re: [WISPA] good multiradio wifi units for noise environments?
As Jack said, all noise effects gear equally. The question is what gear can filter it out better? Some higher end product have better built in filters into their radios. A good example is Trango Broadband. Some radios have higher quality receivers so they can make out the distorted signal better. A good example is Orthogon. Or less likely to be overloaded, because it is spec'd to be able to handle a higher powered signal. But better receive sensitivy, has no benefit against noise. Actually, it just means it can hear more lower volume noise. Unless its argued that the radio generates less internal noise, and one of the reasons it can operate at a lower signel level. When there is noise, there are only two options... How to filter it, or how to avoid it. Avoiding it means antenna choice. Narrow beams, and Thick shielding for increased front to back ratios. How to filter it, means buy a name brand product that integrates good filters (example trango, Alvarion), or use third party add-on filters, to filter it out. There is no one fits all filter. Filters are designed to filter out what you want filtered out. A filter isn't going to help filtering out others signals on the same channels as you are using. If you are in a high noise environment, DON:T get fooled into the trap of deploying at the highest power possible. Thats a game that is never won. All parties on the channel experiencethe same thing, and can all do the same thing to keep increase power to try and win over the interference. The better approach is to pick a product that allows choice of antenna. Then you can select the best antennas, to steer around or avoid the noise. These are one of the benefits that I like to the OEM type stuff (StarOS, Ligo, MT) they allow choice of antenna. (If certified of course :-) Trango's new MM model also allows CPE and AP choice of antenna. (But still in Beta, and they aren't quite ready to ship yet). Tom DeReggi RapidDSL Wireless, Inc IntAirNet- Fixed Wireless Broadband - Original Message - From: Rogelio [EMAIL PROTECTED] To: Jack Unger [EMAIL PROTECTED] Cc: WISPA General List wireless@wispa.org Sent: Thursday, June 12, 2008 7:17 AM Subject: Re: [WISPA] good multiradio wifi units for noise environments? Jack Unger wrote: Noise is noise and will destroy performance on any radio. True. But aren't there some wifi units that get better radio sensitivity due to channel bandwidth and the noise figure of the radio? 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/
Re: [WISPA] XR9 separation from other 2.4 stuff
So what you are saying is that if I have my 900mhz antenna on channel 11 (2.4 down-converting to 900) and then I have my 2.4AP on channel 1 that this is ok on the same board? Kurt Fankhauser WAVELINC P.O. Box 126 Bucyrus, OH 44820 419-562-6405 www.wavelinc.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of George Sent: Friday, June 13, 2008 4:42 PM To: WISPA General List Subject: Re: [WISPA] XR9 separation from other 2.4 stuff Kurt Your just going to want to stay off the same channel as the xr9 and you will be ok. Kurt Fankhauser wrote: It is my understanding that the 900mhz cards are actually 2.4ghz with converters built in. So obviously putting a 900mhz card on the same board as a 2.4ghz card would be a bad idea. Now can I put them on the same tower? Lets say I put the 900mhz radio at the bottom and run some coax since 900mhz should have much less cable loss I should be able to do this. I'll leave the 2.4 stuff up top. But will the 900mhz antenna mounted in close proximity to the 2.4 antenna pick up the 2.4 and allow it to still cause interference to the radio below? Also would putting a 900mhz filter before the radio solve this? Kurt Fankhauser WAVELINC P.O. Box 126 Bucyrus, OH 44820 419-562-6405 www.wavelinc.com 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/
Re: [WISPA] XR9 separation from other 2.4 stuff
Leon, How close are the 2.4 cards to that one SR9 card? What SBC are you using? Kurt Fankhauser WAVELINC P.O. Box 126 Bucyrus, OH 44820 419-562-6405 www.wavelinc.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leon D. Zetekoff, NCE Sent: Friday, June 13, 2008 4:15 PM To: WISPA General List Subject: Re: [WISPA] XR9 separation from other 2.4 stuff * Kurt Fankhauser wrote, On 6/13/2008 3:56 PM: It is my understanding that the 900mhz cards are actually 2.4ghz with converters built in. So obviously putting a 900mhz card on the same board as a 2.4ghz card would be a bad idea. Now can I put them on the same tower? Lets say I put the 900mhz radio at the bottom and run some coax since 900mhz should have much less cable loss I should be able to do this. I'll leave the 2.4 stuff up top. But will the 900mhz antenna mounted in close proximity to the 2.4 antenna pick up the 2.4 and allow it to still cause interference to the radio below? Also would putting a 900mhz filter before the radio solve this? Hi Kurt...we're currently doing this. We have two 2.4 cards and an SR9 in one box at the top of a tower. On the same tower, lower down, we have a box with two SR9s in it. I thought at first we might have some problems but I think if you are shielded and the connections are good and tight you shouldn't have much of a problem. If you want to isolate physically then that shouldn't be an issue IMHO. LEoN Kurt Fankhauser WAVELINC P.O. Box 126 Bucyrus, OH 44820 419-562-6405 www.wavelinc.com 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/
Re: [WISPA] good multiradio wifi units for noise environments?
In high noise areas you'll be better off to use almost anything but WiFi. It's the least noise tolerant protocol that I know of. Sorry, but the opposite is true. 802.11 is actually a good protocol to combat noise, when the noise is someone elses. It has built-in re-transmission into the protocol, and the -CA adds variations in transit time to increase changes of missing noise. Wifi (802.11) is a contention based protocol, purposely allowing multiple people to access the spectrum in a best effort manner. The opposite is true, that basic TDD based gear is more harmed by noise, as by default it does not re-transmit at layer2, and it transmits on schedule with out checking if its free to transmit. The exception to that is high end gear like Trango, that has Built-in ARQ to re-transmit lost packets. One of the reasons Wimax 802.16e, in less suited for unlicensed than licensed. What Wifi is bad for, is SELF interference/ self noise. The famous hidden node problem. 802.11 added RTS/CTS, to help solve this, at a significant performance impact. And Proxim and (karlnet) added polling feature to help solve this on Wifi style gear. Likewise highend gear like Trango, also adds polling. With that said, I prefer using TDD based gear in high nosie environment. The reason is that even though it might be less advantages from a contention point of view, TDD gear is a constant carrier product, so it always transmits a signal at your assigned power level. The benefit of this is that you let other people know that you are there. Therefore they can design around you, until they don't hear your signal, by selective antenna choice and pointing. Many OEM WIFI gear are poor performers in high noise environements, but it is not because the Wifi protocol. Its because its inexpensive equipment, without good filtering, low grade receivers, and OFDM modulations. OFDM high modulations really aren't very good for noise, because they require such a large Signal to noise ratio. The secret to noise environments is being clear what the QOS requirements are. TDD is sometimes the only way to have predictable QOS levels. And sometimes the only way to get TDD to work in a high noise floor area is at a low modualtion such as DSSS or FSK, or lowest modulation of OFDM. Equipment choice is a factor of what you need, and the best way to deliver that. For example Canopy has one of the loweest C/I ratios, making it favorable in high noise environments. Sometimes the OFDM speeds are essential, and the best choice is the best quality OFDM product, such as Alvarion that also has very high end filters embedded. I personally chose trango for my high noise environments, because of its unique abilty to avoid interference, with real time flexibility of polarities, and DSSS noise resilience. And also its ability to accurately scan for interference/noise. And sometimes, I use StarOS or Ligo and narrow beam antennas, because it allows me 5 and 10Mhz channels, all thats available, in my largest noise floor environments. And most importnatly you need to decide what type noise you are avoiding... Your own noise, or others? Tom DeReggi RapidDSL Wireless, Inc IntAirNet- Fixed Wireless Broadband - Original Message - From: Marlon K. Schafer [EMAIL PROTECTED] To: [EMAIL PROTECTED]; WISPA General List wireless@wispa.org Sent: Thursday, June 12, 2008 11:58 AM Subject: Re: [WISPA] good multiradio wifi units for noise environments? In high noise areas you'll be better off to use almost anything but WiFi. It's the least noise tolerant protocol that I know of. marlon - Original Message - From: Rogelio [EMAIL PROTECTED] To: WISPA General List wireless@wispa.org Sent: Wednesday, June 11, 2008 11:07 PM Subject: [WISPA] good multiradio wifi units for noise environments? I am looking for multiradio wifi units that handle well in environments with high floor noise levels, particularly in city areas where the unlicensed band is very congested. Any suggestions? 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/
Re: [WISPA] User check program
David, You could even split the difference, and have default settings compiled in, that are overridden by the presence of a valid .ini. Definately the way to do it! Tom DeReggi RapidDSL Wireless, Inc IntAirNet- Fixed Wireless Broadband - Original Message - From: David E. Smith [EMAIL PROTECTED] To: WISPA General List wireless@wispa.org Sent: Monday, June 09, 2008 11:05 AM Subject: Re: [WISPA] User check program David, there are too many variables, I think, to have a compiled program with the settings buried into it. We will want a way to modular-ize it. Or it could be done both ways, with the option to set it to compiled or INI. The compiled version WOULD make for an easier download and use, yes. Either all the variables go into an .ini file, or they all go into one file in the source code. You could even split the difference, and have default settings compiled in, that are overridden by the presence of a valid .ini. David Smith MVN.net 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/
Re: [WISPA] User check program
Well, yes but, no reason you can't build the app to auto install the run-time. Tom DeReggi RapidDSL Wireless, Inc IntAirNet- Fixed Wireless Broadband - Original Message - From: Matt Liotta [EMAIL PROTECTED] To: WISPA General List wireless@wispa.org Sent: Thursday, June 12, 2008 4:02 PM Subject: Re: [WISPA] User check program On Jun 12, 2008, at 4:47 PM, Larry Yunker wrote: When it comes to cross platform support, I would agree that Java wins out. When it comes to end-user software in a Windows environment, I would have to disagree and state that almost all recent (last 2 to 3 years) development has turned to the .Net platform. Doesn't matter what the development platform is; it matters whether the VM is installed on the desktop according to your original request. Even if every new piece of software is written in .NET it will still take time for the VM to surpass Java in terms of penetration. Apple doesn't support .NET, which is the elephant in the room you can't avoid. Regardless, I am still seeking a 3rd option... I'm looking for a good development platform which can generate standalone exe's for Windows. C++ is the only option there. Everything else is going to require a runtime. -Matt 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/
Re: [WISPA] User check program
If its being used as a speed test, its important that it is capable of giving an accurate speed test. Its better to have no speed test than to have one that makes our network look bad. Matt, made some good points about web apps not being fast enough to do accurate speed tests. We wrote a tool that used icmp to do speed tests. but the the problem with that was that many of our routers were set to limit number of Ping packets for DOS protection. So although wecould use it, it was not good for our end users. Its critical to have both a TCP and Non-TCP test. They tell two completely different things. UDP tests tell whether your network has the capacity to pass the speed tested. TCP tests factor in the end user's experience considering windows size, packet loss, distance, etc. Its also important to consider what level customers this tool will be used for. 1, 2,5,10,100 mbps customers. And its relevent how large an ISP's network is, to know what the distance will be. So correct windows size can be chosen that would allow full speed. If an ISP sells 50 mbps circuit, poor results might be redendered of hte speed test was designed for 1mbps customers. So it might be good to have a statement of what speed range the speed tool is capable of testing up to. It also might be good to have a help or more info button, that will gie a few paragrahs about interpretting speed results, and reasons why it might be slow. On the speed test, disclose where that is getting tested to. Tom DeReggi RapidDSL Wireless, Inc IntAirNet- Fixed Wireless Broadband - Original Message - From: Matt Liotta [EMAIL PROTECTED] To: WISPA General List wireless@wispa.org Sent: Thursday, June 12, 2008 3:19 PM Subject: Re: [WISPA] User check program On Jun 12, 2008, at 4:08 PM, Larry Yunker wrote: (1) For purposes of Deployment, this program requires .Net 2.0. The install program will check for the existence of .Net 2.0 on the target machine and will attempt to install it if it is not already installed. Unfortunately, .Net 2.0 won't install on any machine older than Windows98 and won't install on WinXP machines until Service Pack 2.0 or newer is installed. So, the .Net requirement is somewhat of a pain. The Installation program will work easily on machines that already have .Net or on machines that don't have .Net but have all of the prerequisites for installing .Net. Hopefully that will be the majority of installs?!?@ It also means the program doesn't work with no Windows computers, which are increasingly gaining market share. But, in an ideal world, we'd like to avoid installing .Net, so the question is this: does anyone know how to compile and deploy a Visual Basic application without requiring .Net to be installed on the target machine? Or if that's not possible, does anyone have any suggestions as to other visual languages which DO NOT USE .NET and which might be used for future ports of this application. Java. (2) One of the features of this application is a speed test. As you might imagine, sometimes speed tests will fail to complete (due to congestion, poor connection, etc.). For this reason, it becomes imperative that I create some sort of timeout mechanism so that the attempted upload or download halts with no results if the test is taking too long. I'm using the webclient.uploadfile and webclient.downloadfile methods to accomplish these tests. Does anyone know whether there is a way to force this method to halt upon a preset timeout? If not, does anyone have a good example of code to place a process in background in Visual Basic? Generally speaking, webclient is not going to be ideal for speed testing. You are going to want to operate at a lower layer. I would suggest UDP or TCP. -Matt 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/
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/ WISPA Wants You! Join today! http://signup.wispa.org/
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..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
Re: [WISPA] XR9 separation from other 2.4 stuff
If your using an XR9 then you won't be using channel 11. it's gonna be channel 4 through 7 in 5MHz incriments. So you will want to not use anything that overlaps those channels very much. Channel 6 will not be good, channel 11 and channel 1 will be fine. I Kurt Fankhauser wrote: So what you are saying is that if I have my 900mhz antenna on channel 11 (2.4 down-converting to 900) and then I have my 2.4AP on channel 1 that this is ok on the same board? Kurt Fankhauser WAVELINC P.O. Box 126 Bucyrus, OH 44820 419-562-6405 www.wavelinc.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of George Sent: Friday, June 13, 2008 4:42 PM To: WISPA General List Subject: Re: [WISPA] XR9 separation from other 2.4 stuff Kurt Your just going to want to stay off the same channel as the xr9 and you will be ok. Kurt Fankhauser wrote: It is my understanding that the 900mhz cards are actually 2.4ghz with converters built in. So obviously putting a 900mhz card on the same board as a 2.4ghz card would be a bad idea. Now can I put them on the same tower? Lets say I put the 900mhz radio at the bottom and run some coax since 900mhz should have much less cable loss I should be able to do this. I'll leave the 2.4 stuff up top. But will the 900mhz antenna mounted in close proximity to the 2.4 antenna pick up the 2.4 and allow it to still cause interference to the radio below? Also would putting a 900mhz filter before the radio solve this? Kurt Fankhauser WAVELINC P.O. Box 126 Bucyrus, OH 44820 419-562-6405 www.wavelinc.com 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/ 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/
Re: [WISPA] User check program
Tom, I appreciate all of the useful comments. Please note that I posted updated screen shots of the tool yesterday. Some of the changes that you are requesting have already been implemented. For instance, the speed test has been moved to a separate tab and now only runs if the subscriber switches to that tab-view. With regards to the other issues that have been raised I plan to deploy an initial release of this tool on Sunday. OBVIOUSLY.. It won't have everything that everyone has requested. If I halted deployment for EVERY request, I would never get any version of the product to market. After the product is released, I'm going to work on making the subsequent release even more flexible. Ideally, I'd like to make the application completely dynamic so that the ISP can define each ping (hop) that should be tested for the given client. I'm also still looking into other languages onto which I might port the application to so as to make a more compact and portable solution. Warning... I'm relatively certain that any port to a different language will be delayed for several weeks. Unfortunately, my development time is quite restricted at the moment as I am busy studying for the Ohio Bar Exam. Besides, learning an entirely new OO language is just going to take a little time. BTW, I did pick up an iMac at a garage sale today (for $5), so maybe when the time comes, I'll even be able to develop a solution for the Apple platform. Larry Yunker Network Consultant [EMAIL PROTECTED] -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..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
Re: [WISPA] User check program
Tom, I think we need to keep in mind this is a tool designed for "residential" users... we would never ask the IT Director at a business that has a 20Mbps fiber connection to download this tool to "test your connectivity" or "test your speed". LOL The whole idea was to create a simple, easy to download (single EXE with no installation required) tool that our 1st level support techs could use to help customers. Also, we have a Speedtest.net server at our location. It provides VERY accurate results from a web page (at least up to 15Mbps). There are ways to make it happen, but again, we are getting away from the initial idea of the program. Travis Microserv Tom DeReggi wrote: If its being used as a speed test, its important that it is capable of giving an accurate speed test. Its better to have no speed test than to have one that makes our network look bad. Matt, made some good points about web apps not being fast enough to do accurate speed tests. We wrote a tool that used icmp to do speed tests. but the the problem with that was that many of our routers were set to limit number of Ping packets for DOS protection. So although wecould use it, it was not good for our end users. Its critical to have both a TCP and Non-TCP test. They tell two completely different things. UDP tests tell whether your network has the capacity to pass the speed tested. TCP tests factor in the end user's experience considering windows size, packet loss, distance, etc. Its also important to consider what level customers this tool will be used for. 1, 2,5,10,100 mbps customers. And its relevent how large an ISP's network is, to know what the distance will be. So correct windows size can be chosen that would allow full speed. If an ISP sells 50 mbps circuit, poor results might be redendered of hte speed test was designed for 1mbps customers. So it might be good to have a statement of what speed range the speed tool is capable of testing up to. It also might be good to have a "help" or "more info" button, that will gie a few paragrahs about interpretting speed results, and reasons why it might be slow. On the speed test, disclose where that is getting tested to. Tom DeReggi RapidDSL Wireless, Inc IntAirNet- Fixed Wireless Broadband - Original Message - From: "Matt Liotta" [EMAIL PROTECTED] To: "WISPA General List" wireless@wispa.org Sent: Thursday, June 12, 2008 3:19 PM Subject: Re: [WISPA] User check program On Jun 12, 2008, at 4:08 PM, Larry Yunker wrote: (1) For purposes of Deployment, this program requires .Net 2.0. The install program will check for the existence of .Net 2.0 on the target machine and will attempt to install it if it is not already installed. Unfortunately, .Net 2.0 won't install on any machine older than Windows98 and won't install on WinXP machines until Service Pack 2.0 or newer is installed. So, the .Net requirement is somewhat of a pain. The Installation program will work easily on machines that already have .Net or on machines that don't have .Net but have all of the prerequisites for installing .Net. Hopefully that will be the majority of installs?!?@ It also means the program doesn't work with no Windows computers, which are increasingly gaining market share. But, in an ideal world, we'd like to avoid installing .Net, so the question is this: does anyone know how to compile and deploy a Visual Basic application without requiring .Net to be installed on the target machine? Or if that's not possible, does anyone have any suggestions as to other visual languages which DO NOT USE .NET and which might be used for future ports of this application. Java. (2) One of the "features" of this application is a speed test. As you might imagine, sometimes speed tests will fail to complete (due to congestion, poor connection, etc.). For this reason, it becomes imperative that I create some sort of timeout mechanism so that the attempted upload or download halts with no results if the test is "taking too long". I'm using the webclient.uploadfile and webclient.downloadfile methods to accomplish these tests. Does anyone know whether there is a way to force this method to halt upon a preset timeout? If not, does anyone have a good example of code to place a process in background in Visual Basic? Generally speaking, webclient is not going to be ideal for speed testing. You are going to want to operate at a lower layer. I would suggest UDP or TCP. -Matt 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/
Re: [WISPA] User check program
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..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
Re: [WISPA] good multiradio wifi units for noise environments?
Tom, Do you find this true for Trango 900 also? I've not had good luck with those. Mine seem to quit working with the first competition. I do like them for scanning for noise; and the software switchable horizontal / vertical is nice. On June 13, at 5:59 PM June 13, Tom DeReggi wrote: I personally chose trango for my high noise environments, because of its unique abilty to avoid interference, with real time flexibility of polarities, and DSSS noise resilience. And also its ability to accurately scan for interference/noise. 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/
Re: [WISPA] using street level and below tree canopy for unlicensed bands
I never saw any of the earlier messages from this thread, but I have a 4 sq mi mesh implementing right now. It is pretty much a tropical rain forest without the rain. I was required to use a dual radio product that only allows meshing on 5.8. The 2.4 is for client access only. Due to the trees, and I don't even want to mention how many nodes/mile there are, it is very difficult to get signal injection into the outlying neighborhoods. I'm having to rely on VPN over cable modem as a last resort. However, my latest experiments using Ligowave under tree canopy (at the 21 ft height at which my nodes are mounted) have been very promising. Ligo is reasonably priced and offers a really decent penetration through the overhanging trees. I'm seeing -55 to -70 signals on my hoppity-hoppity-hop links. If I can do enough of it, I won't have to use any cable modems. The dual radio units are very nice because the Ethernet port can allow me to make the host pole a gateway without having to have a switch mounted there as well! Ligo on the pole, panels facing each direction up and down the street and plug the Ethernet into the mesh radio. I can concur with Brian. I was the one who had to be the 1 man SWAT team to go in and fix those Earthlink networks after they were implemented. Philadelphia was where I spent 80% of my time and it was an extremely difficult place to make things work due to the 4-5 story residences that were 6 feet from the street. I guess these are called brownstones. If you could not put radios at street corners, you were pretty much out of luck! One more thing to say to those unfamiliar with mesh. This goes with the paragraph two above this. A mesh quickly becomes so slow that it is useless without the proper number of gateways, or bandwidth injection points. Although you may be able to mesh all the way to the city limits (or at least out 6-8 hops), your speed will be a crawl. You have GOT to have that injection going on. Sometimes as small of a ratio as 3-4 mesh nodes per injection point. That is why if you drive through Anaheim, Philly, (and for another week- New Orleans), you'll see lots and lots of Canopy SMs hanging from the Tropos radios. That's the injection layer going back to a PtMP canopy cluster someplace.. Ralph -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Webster Sent: Thursday, June 12, 2008 9:08 AM To: [EMAIL PROTECTED]; WISPA General List Subject: Re: [WISPA] using street level and below tree canopy for unlicensed bands In my days at EarthLink we did discover that the noise levels in both the 2.4 and 5 GHz bands were much lower at street level than up on high buildings or towers. This was both good and bad. It was good in that we had a better signal to noise ratio. The reason being that in Philly the buildings in many cases were three stories and taller than the mounting points we were allowed to use on the poles. With buildings shadowing a node it was much quieter. This was also a big problem in the network design. Those same buildings and trees also kept the mesh nodes from being able to link anywhere but straight along the streets between the buildings and even that was a challenge with the trees. For those reasons Philadelphia ended up with a much higher transmitter count per square mile than originally anticipated ( a lot more). Now the idea of shooting signal under the tree canopy is a good one. One problem is that you need to ensure that you can actually mount the radio below the tree canopy. In most cities the lower part of the canopy will be 10 to 15 feet above the ground and pole mounting heights typically are 20 feet or higher. At 5 GHz on a mesh system if you have to go through any more than about 10 meters of tree, the attenuation is such that you can't hold a link (with or without noise). If you are designing a network to shoot under the trees, you better have someone out on the field visually verify every single link that you want to work is clear of obstructions end to end. The reason being that any slight change in ground elevation can easily block the path because you have obstructions to consider both above and below your RF path. RF tools can not account for this, even if you have high resolution tree clutter data. They will model the tree as solid all the way down to the ground. They can not show the clear path area on the underside of the canopy. If this were a small mesh deployment and you could verify links on the ground I would say it was possible. Thank You, Brian Webster www.wirelessmapping.com http://www.wirelessmapping.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Rogelio Sent: Thursday, June 12, 2008 2:02 AM To: WISPA General List Subject: [WISPA] using street level and below tree canopy for unlicensedbands I was talking to some people today who deploy wireless networks in very noise environments, and some of
