Re: [WISPA] Tracking Signal / Noise / Resends / Etc.
I could be mis-remembering this, or confusing things (say, a tower where we replaced a 5800 with a 5830 or vice-versa), and if I'm wrong I'll cop to it. But I truly believe, with religious fervor and zeal, that Trango has changed their MIBs with different point releases of the firmware. I can't comment on Trango changing a MIB, but the MIBs have peculiarities such as different OIDs for the Master and Slave units for the same parameter. So the OID for RSSI is different for each end of the PtP link. That's just bad MIB design IMHO. -- Nigel. -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Tracking Signal / Noise / Resends / Etc.
Fair enough. I agree completely. Standard MIB-II objects should be provided with MIB-II Object IDs. If they provide "equivalents" only in their own enterprise object space, that requires extra work on the user to lookup and reference the OIDs. The right way would be to provided both a MIB-II set for all the "standard" objects, and an enterprise set for their unique radio objects. Any chance you could off-list email me the Trango MIB definition files to look at? I'd like to see what they've done. Rich - Original Message - From: "David E. Smith" <[EMAIL PROTECTED]> To: "WISPA General List" Sent: Thursday, November 03, 2005 7:53 PM Subject: Re: [WISPA] Tracking Signal / Noise / Resends / Etc. rcomroe wrote: > On another part of David's reply he comments on interface.InOctets. >>And don't even get me started on >>the fact that they don't use the same Enterprise MIBs that pretty much >>everyone else on the planet uses for 'interface.InOctets' and so on. > The interfaces MIB is a standard part of the MIB-II set of objects (OIDs) > which is not part of the manufacturer's "enterprise" proprietary objects. I don't claim to be an expert on SNMP by any means. I just know that things like snmpwalk and MRTG's cfgmaker work with basically every network device I have, except Trango gear, without passing weird command-line options or going out of my way to install MIB files. If Trango wants to have their own MIBs for things like RF levels, that's their right (and since very few things are standardized, it's darn near required). But it'd be swell if they also exported "standard" stuff too. If I mis-spoke (mis-typed?) I apologize. Listen to what I mean, not what I say. :) David Smith MVN.net -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
[WISPA] wireless in yuma az?
any one have wireless in yuma. rob -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Tracking Signal / Noise / Resends / Etc.
rcomroe wrote: > On another part of David's reply he comments on interface.InOctets. >>And don't even get me started on >>the fact that they don't use the same Enterprise MIBs that pretty much >>everyone else on the planet uses for 'interface.InOctets' and so on. > The interfaces MIB is a standard part of the MIB-II set of objects (OIDs) > which is not part of the manufacturer's "enterprise" proprietary objects. I don't claim to be an expert on SNMP by any means. I just know that things like snmpwalk and MRTG's cfgmaker work with basically every network device I have, except Trango gear, without passing weird command-line options or going out of my way to install MIB files. If Trango wants to have their own MIBs for things like RF levels, that's their right (and since very few things are standardized, it's darn near required). But it'd be swell if they also exported "standard" stuff too. If I mis-spoke (mis-typed?) I apologize. Listen to what I mean, not what I say. :) David Smith MVN.net -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Tracking Signal / Noise / Resends / Etc.
I'm of course familiar with the Motorola enterprise MIBs which they constantly add to. But here's the issue why I soapbox'ed that changing a previously defined OIDs is shameful. Take the effort to develop an snmp management function ... update some device's firmware and the management function CEASES TO WORK (only happens if the manufacturer changes previously defined objects). I can't see any excuse for this. OIDs once defined should not change. If you want to provide a new model with radically different MIBs, they must spawn from a new branch under the manufacturer's enterprise MIB. No changes permitted, no exceptions, zero tolerance. I've no knowledge that Trango did this ... I'm just providing justification for my quotation that David replied to. On another part of David's reply he comments on interface.InOctets. >And don't even get me started on >the fact that they don't use the same Enterprise MIBs that pretty much >everyone else on the planet uses for 'interface.InOctets' and so on. The interfaces MIB is a standard part of the MIB-II set of objects (OIDs) which is not part of the manufacturer's "enterprise" proprietary objects. There's no problem with a device containing both (the MIB-II set and an enterprise set / I've seen several radios that contain both), but if a device includes the MIB-II set it's not in the manufacturer's authority to redefine them ... they only get to make up their own definition of their enterprise objects. Is the interface.InOctets MIB you referred to part of the standardized MIB-II or just a "similarly named" object of the manufacturer's proprietary enterprise MIB? Rich - Original Message - From: "David E. Smith" <[EMAIL PROTECTED]> To: "WISPA General List" Sent: Thursday, November 03, 2005 5:13 PM Subject: Re: [WISPA] Tracking Signal / Noise / Resends / Etc. rcomroe wrote: > Under no circumstances should > any > manufacturer CHANGE THE DEFINITION OF A PREVIOUSLY DEFINED OID. and yet... Trango's MIBs for the 5800 and 5830 are wildly different. Never mind that they're substantially the same hardware (from the point of view of "how you use them in your network," at least). And don't even get me started on the fact that they don't use the same Enterprise MIBs that pretty much everyone else on the planet uses for 'interface.InOctets' and so on. Since you can only download MIBs for the current software versions, you'll have to take me at my word that they've changed them in the past (for the 5800 AP, between firmware versions 1.4 and 1.64 they were different). I could be mis-remembering this, or confusing things (say, a tower where we replaced a 5800 with a 5830 or vice-versa), and if I'm wrong I'll cop to it. But I truly believe, with religious fervor and zeal, that Trango has changed their MIBs with different point releases of the firmware. Sorry, I didn't mean for this to turn into a Trango rant. David Smith MVN.net -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] [Fwd: Fw: [off-list] Tracking Signal / Noise / Resends / Etc.]
You misunderstood. He went out of his way not to send his message at all to the list for fear of being labeled a spammer. I went ahead and sent his information to the list whether he benefits financially or not because his information was very on-topic and is not (in my opinion) spam at all. Mr. Comroe was not a party to sending this information to the list at all. It was my doing completely. I hope this is more clear now. Thank you, Scriv Dan Petermann wrote: I have dealt with Mr. Comroe and his software in the past and he is a very helpful gentleman. I no longer use it, but that is not due to any problems with him or his software. It was for monitoring canopy radios and Moto made changes to the radio firmware that broke compatibility. I don't think he had any intention to spam. I say give him a second chance. On Nov 3, 2005, at 3:28 PM, John Scrivner wrote: I am forwarding this message to the group because this individual is not trying to spam us and is actually benefiting us I think. I am sorry if any of you think this is spam. He did not ask me to forward it onto the list. I feel it is good information and should be shared with the group. I will likely call on him for some assistance myself to see if I can streamline some of my wireless system monitoring and housekeeping tasks. Thank you Rich, Scriv Original Message Subject: Fw: [off-list] Tracking Signal / Noise / Resends / Etc. Date: Thu, 3 Nov 2005 12:49:43 -0600 From: rcomroe <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> On-List I gave you some useful pointers about monitoring methods / tools. Off-list, I'd encourage you to look at www.comroestudios.com. I'm pretty small, and just provide tools to wisps at a fraction of what than the larger companies charge. But I know what you're looking for and try to provide that to wisps. If you're interested I could help you out. As far as a vendor membership to WISPA, what's it cost? I sell only a tiny amount of product as a retirement hobby. But if you see what you need, I'd could be persuaded to become a member if it turned out to be mutually advantageous to WISPA as well as I. I poll about 18 parameters from each radio every 5 minutes or so. Most are retained in a history file that I can look back through, or graph any time interval. Others are strip-charted so multiple charts can be viewed on a web page like MRTG. Beyond just viewing or logging performance, the other thing a WISP really needs is a tool that can script instructions and actions to automate functions ... network management is more than just "viewing / reviewing" performance. Most of the WISPs that use my tool operate Canopy, where the device has snmp and web based interfaces (but the snmp interface in Canopy doesn't really work properly). Therefore some scripts interact by http while most of the continuous polling is done by snmp. Just about any action can be automated by a script and operators typically can automate actions that cycle through all radios performing reconfigurations, searching bridge tables, or anything. Rich - Original Message - From: "John Scrivner" <[EMAIL PROTECTED]> To: Sent: Thursday, November 03, 2005 11:32 AM Subject: [WISPA] Tracking Signal / Noise / Resends / Etc. I am starting to feel the pains of trying to accurately trace problems in a network that is getting increasingly larger all the time. We have roughly 20 tower locations now. We have a pretty good picture of what we are getting for bandwidth use through our MRTG graphs. We can see when any link completely drops thanks to our What's Up monitoring. We can easily track and isolate peer to peer abuse and such with traffic analysis tools in Star OS and Mikrotik as needed. What we need though is a way to track the other parameters of our network over time. It would be invaluable to me to be able to look over historical records from a hour long window up to a year long window for link integrity information. What I mean is this. I would like to see how a signal level, noise level, number of retransmits, etc. changes over time in a graph format like MRTG does with bits in and out. It would be nice to add other parameters as needed. I know SNMP is supposed to be able to do this but I do not have the slightest bit of experience using that. Is there anyone out there who knows an easy way of getting a rudimentary level of understanding about using SNMP to extract data such as this? Maybe someone has a package they use that provides this information on your network? If any WISPs out there have any answers to this please respond on this list. If you are a vendor and your product can do specifically what I am asking for above then I am sure we would like to hear about that too. Maybe if a few of us buy your products you will consider buying a vendor membership to WISPA also.:-) Thanks guys, Scriv -
Re: [WISPA] [Fwd: Fw: [off-list] Tracking Signal / Noise / Resends / Etc.]
I have dealt with Mr. Comroe and his software in the past and he is a very helpful gentleman. I no longer use it, but that is not due to any problems with him or his software. It was for monitoring canopy radios and Moto made changes to the radio firmware that broke compatibility. I don't think he had any intention to spam. I say give him a second chance. On Nov 3, 2005, at 3:28 PM, John Scrivner wrote: I am forwarding this message to the group because this individual is not trying to spam us and is actually benefiting us I think. I am sorry if any of you think this is spam. He did not ask me to forward it onto the list. I feel it is good information and should be shared with the group. I will likely call on him for some assistance myself to see if I can streamline some of my wireless system monitoring and housekeeping tasks. Thank you Rich, Scriv Original Message Subject:Fw: [off-list] Tracking Signal / Noise / Resends / Etc. Date: Thu, 3 Nov 2005 12:49:43 -0600 From: rcomroe <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> On-List I gave you some useful pointers about monitoring methods / tools. Off-list, I'd encourage you to look at www.comroestudios.com. I'm pretty small, and just provide tools to wisps at a fraction of what than the larger companies charge. But I know what you're looking for and try to provide that to wisps. If you're interested I could help you out. As far as a vendor membership to WISPA, what's it cost? I sell only a tiny amount of product as a retirement hobby. But if you see what you need, I'd could be persuaded to become a member if it turned out to be mutually advantageous to WISPA as well as I. I poll about 18 parameters from each radio every 5 minutes or so. Most are retained in a history file that I can look back through, or graph any time interval. Others are strip-charted so multiple charts can be viewed on a web page like MRTG. Beyond just viewing or logging performance, the other thing a WISP really needs is a tool that can script instructions and actions to automate functions ... network management is more than just "viewing / reviewing" performance. Most of the WISPs that use my tool operate Canopy, where the device has snmp and web based interfaces (but the snmp interface in Canopy doesn't really work properly). Therefore some scripts interact by http while most of the continuous polling is done by snmp. Just about any action can be automated by a script and operators typically can automate actions that cycle through all radios performing reconfigurations, searching bridge tables, or anything. Rich - Original Message - From: "John Scrivner" <[EMAIL PROTECTED]> To: Sent: Thursday, November 03, 2005 11:32 AM Subject: [WISPA] Tracking Signal / Noise / Resends / Etc. I am starting to feel the pains of trying to accurately trace problems in a network that is getting increasingly larger all the time. We have roughly 20 tower locations now. We have a pretty good picture of what we are getting for bandwidth use through our MRTG graphs. We can see when any link completely drops thanks to our What's Up monitoring. We can easily track and isolate peer to peer abuse and such with traffic analysis tools in Star OS and Mikrotik as needed. What we need though is a way to track the other parameters of our network over time. It would be invaluable to me to be able to look over historical records from a hour long window up to a year long window for link integrity information. What I mean is this. I would like to see how a signal level, noise level, number of retransmits, etc. changes over time in a graph format like MRTG does with bits in and out. It would be nice to add other parameters as needed. I know SNMP is supposed to be able to do this but I do not have the slightest bit of experience using that. Is there anyone out there who knows an easy way of getting a rudimentary level of understanding about using SNMP to extract data such as this? Maybe someone has a package they use that provides this information on your network? If any WISPs out there have any answers to this please respond on this list. If you are a vendor and your product can do specifically what I am asking for above then I am sure we would like to hear about that too. Maybe if a few of us buy your products you will consider buying a vendor membership to WISPA also.:-) Thanks guys, Scriv -- -- -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wisp
Re: [WISPA] Tracking Signal / Noise / Resends / Etc.
rcomroe wrote: > Under no circumstances should > any > manufacturer CHANGE THE DEFINITION OF A PREVIOUSLY DEFINED OID. and yet... Trango's MIBs for the 5800 and 5830 are wildly different. Never mind that they're substantially the same hardware (from the point of view of "how you use them in your network," at least). And don't even get me started on the fact that they don't use the same Enterprise MIBs that pretty much everyone else on the planet uses for 'interface.InOctets' and so on. Since you can only download MIBs for the current software versions, you'll have to take me at my word that they've changed them in the past (for the 5800 AP, between firmware versions 1.4 and 1.64 they were different). I could be mis-remembering this, or confusing things (say, a tower where we replaced a 5800 with a 5830 or vice-versa), and if I'm wrong I'll cop to it. But I truly believe, with religious fervor and zeal, that Trango has changed their MIBs with different point releases of the firmware. Sorry, I didn't mean for this to turn into a Trango rant. David Smith MVN.net -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
RE: [WISPA] Tracking Signal / Noise / Resends / Etc.
http://www.trangobroadband.com/pdfs/TrangoMRTG.pdf Todd Barber Skylink Broadband Internet [EMAIL PROTECTED] 970-454-9499 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Scrivner Sent: Thursday, November 03, 2005 3:17 PM To: WISPA General List Subject: Re: [WISPA] Tracking Signal / Noise / Resends / Etc. Thank you Paul. This is exactly what I was looking for in regard o customer links. If we take a service call it would be nice to see what a customer's historical data has been in regard to signal levels, bandwidth used, etc. It sounds like you hit this one right on the head. Doing the same for Trango would be sweet also. I do not know what the "Trangolink-10" is that was referenced earlier as a solution to tracking details on Trango.. Can anyone elaborate on how to graph these things on Trango? I need links to actual data if you guys do not mind. Thanks guys, Scriv Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=windows-1250; format=flowed Paul Hendry wrote: >StarOS isn't great for SNMP but Starutil works really well for various >stuff. We have been using it to graph with MRTG the signal levels for >individual clients and backhaul links as well as throughput. > >Cheers, > >P. > >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >Behalf Of David E. Smith >Sent: 03 November 2005 20:10 >To: WISPA General List >Subject: Re: [WISPA] Tracking Signal / Noise / Resends / Etc. > >rcomroe wrote: > > > >>There are 2 fundamentally different approaches for monitoring. >> >> > >[ stuff ] > >For reference, in the network Scriv is describing, there's a nasty mixture >of gear. Backhaul is primarily Trango (though that's likely to change at >some point), and the customer APs are all either StarOS running on >RouterBoard 200 hardware, or realy old Lucent APs with Karlnet >software installed. > >StarOS doesn't export a lot of the data we're looking for, as far as I and >my copy of snmpwalk can tell. (If I can read my boss's mind as well as I >think I can, though, he's probably looking more for backhaul stats than >for individual customer APs.) > >Trango supposedly does, but even their own forums are filled with people >who can't make any sense out of Trango's provided MIBs and such. (I can >usually get one-shot queries with snmpwalk and similar tools to work, but >when you put the exact same parameters into an MRTG configuration file, I >get back nothing but crazy bizarre errors. The fact that Trango changes >their MIBs between hardware versions and occasionally even between >firmware releases only compounds the problem.) > >At the risk of derailing (sorry, boss), has anyone gotten MRTG or >something similar (PRTG, Denika, or whatever) to reliably track *anything* >on a Trango? > >dave > > -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.12.7/160 - Release Date: 11/3/2005 -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
[WISPA] [Fwd: Fw: [off-list] Tracking Signal / Noise / Resends / Etc.]
I am forwarding this message to the group because this individual is not trying to spam us and is actually benefiting us I think. I am sorry if any of you think this is spam. He did not ask me to forward it onto the list. I feel it is good information and should be shared with the group. I will likely call on him for some assistance myself to see if I can streamline some of my wireless system monitoring and housekeeping tasks. Thank you Rich, Scriv Original Message Subject:Fw: [off-list] Tracking Signal / Noise / Resends / Etc. Date: Thu, 3 Nov 2005 12:49:43 -0600 From: rcomroe <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> On-List I gave you some useful pointers about monitoring methods / tools. Off-list, I'd encourage you to look at www.comroestudios.com. I'm pretty small, and just provide tools to wisps at a fraction of what than the larger companies charge. But I know what you're looking for and try to provide that to wisps. If you're interested I could help you out. As far as a vendor membership to WISPA, what's it cost? I sell only a tiny amount of product as a retirement hobby. But if you see what you need, I'd could be persuaded to become a member if it turned out to be mutually advantageous to WISPA as well as I. I poll about 18 parameters from each radio every 5 minutes or so. Most are retained in a history file that I can look back through, or graph any time interval. Others are strip-charted so multiple charts can be viewed on a web page like MRTG. Beyond just viewing or logging performance, the other thing a WISP really needs is a tool that can script instructions and actions to automate functions ... network management is more than just "viewing / reviewing" performance. Most of the WISPs that use my tool operate Canopy, where the device has snmp and web based interfaces (but the snmp interface in Canopy doesn't really work properly). Therefore some scripts interact by http while most of the continuous polling is done by snmp. Just about any action can be automated by a script and operators typically can automate actions that cycle through all radios performing reconfigurations, searching bridge tables, or anything. Rich - Original Message - From: "John Scrivner" <[EMAIL PROTECTED]> To: Sent: Thursday, November 03, 2005 11:32 AM Subject: [WISPA] Tracking Signal / Noise / Resends / Etc. I am starting to feel the pains of trying to accurately trace problems in a network that is getting increasingly larger all the time. We have roughly 20 tower locations now. We have a pretty good picture of what we are getting for bandwidth use through our MRTG graphs. We can see when any link completely drops thanks to our What's Up monitoring. We can easily track and isolate peer to peer abuse and such with traffic analysis tools in Star OS and Mikrotik as needed. What we need though is a way to track the other parameters of our network over time. It would be invaluable to me to be able to look over historical records from a hour long window up to a year long window for link integrity information. What I mean is this. I would like to see how a signal level, noise level, number of retransmits, etc. changes over time in a graph format like MRTG does with bits in and out. It would be nice to add other parameters as needed. I know SNMP is supposed to be able to do this but I do not have the slightest bit of experience using that. Is there anyone out there who knows an easy way of getting a rudimentary level of understanding about using SNMP to extract data such as this? Maybe someone has a package they use that provides this information on your network? If any WISPs out there have any answers to this please respond on this list. If you are a vendor and your product can do specifically what I am asking for above then I am sure we would like to hear about that too. Maybe if a few of us buy your products you will consider buying a vendor membership to WISPA also.:-) Thanks guys, Scriv -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ begin:vcard fn:John Scrivner n:Scrivner;John org:Mt. Vernon. Net, Inc. adr;dom:PO Box 1582;;1 Dr Park Road Suite H1;Mt. Vernon;Il;62864 email;internet:[EMAIL PROTECTED] title:President tel;work:618-244-6868 url:http://www.mvn.net/ version:2.1 end:vcard -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Tracking Signal / Noise / Resends / Etc.
Thank you Paul. This is exactly what I was looking for in regard o customer links. If we take a service call it would be nice to see what a customer's historical data has been in regard to signal levels, bandwidth used, etc. It sounds like you hit this one right on the head. Doing the same for Trango would be sweet also. I do not know what the "Trangolink-10" is that was referenced earlier as a solution to tracking details on Trango.. Can anyone elaborate on how to graph these things on Trango? I need links to actual data if you guys do not mind. Thanks guys, Scriv Paul Hendry wrote: StarOS isn't great for SNMP but Starutil works really well for various stuff. We have been using it to graph with MRTG the signal levels for individual clients and backhaul links as well as throughput. Cheers, P. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David E. Smith Sent: 03 November 2005 20:10 To: WISPA General List Subject: Re: [WISPA] Tracking Signal / Noise / Resends / Etc. rcomroe wrote: There are 2 fundamentally different approaches for monitoring. [ stuff ] For reference, in the network Scriv is describing, there's a nasty mixture of gear. Backhaul is primarily Trango (though that's likely to change at some point), and the customer APs are all either StarOS running on RouterBoard 200 hardware, or realy old Lucent APs with Karlnet software installed. StarOS doesn't export a lot of the data we're looking for, as far as I and my copy of snmpwalk can tell. (If I can read my boss's mind as well as I think I can, though, he's probably looking more for backhaul stats than for individual customer APs.) Trango supposedly does, but even their own forums are filled with people who can't make any sense out of Trango's provided MIBs and such. (I can usually get one-shot queries with snmpwalk and similar tools to work, but when you put the exact same parameters into an MRTG configuration file, I get back nothing but crazy bizarre errors. The fact that Trango changes their MIBs between hardware versions and occasionally even between firmware releases only compounds the problem.) At the risk of derailing (sorry, boss), has anyone gotten MRTG or something similar (PRTG, Denika, or whatever) to reliably track *anything* on a Trango? dave -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Tracking Signal / Noise / Resends / Etc.
Yes, that's an important topic too. There's a variety of access protocols that different devices support. Many devices have web interfaces. Some have snmp support. StarOS has that SSH interface. Another popularly supported interface is plain telnet. In a network composed of mixed equipment odds are you won't find a single access protocol common to all devices. It's good to use tools that support multiple access protocols so you can interrogate a variety of devices. MRTG is a popular tool, but it only does snmp to my knowledge, only does strip-graphs, and has limited programability for automation. You mentioned working with MIBs. When dealing with MIBs, IMO it really helps to use a tool that loads the manufacturer's MIB definition files permitting you to reference MIBs by their natural name. I don't think anybody finds working with OIDs by number as fun (for example wanting to read "RSSI", but having to reference a string like "1.3.6.1.4.1.161.19.3.2.2.2.0"!). When you say Trango frequently changes their MIB definitions, hopefully you mean they constantly re-issue their MIB definitions files adding new parameters. Under no circumstances should any manufacturer CHANGE THE DEFINITION OF A PREVIOUSLY DEFINED OID. Any manufacturer that did this should be appropriately shamed! As long as they don't change definitions of previously defined OIDs (just add new ones), this is not a problem. Can you describe what Trango changes in their MIBs? Rich - Original Message - From: "David E. Smith" <[EMAIL PROTECTED]> To: "WISPA General List" Sent: Thursday, November 03, 2005 2:10 PM Subject: Re: [WISPA] Tracking Signal / Noise / Resends / Etc. rcomroe wrote: > There are 2 fundamentally different approaches for monitoring. [ stuff ] For reference, in the network Scriv is describing, there's a nasty mixture of gear. Backhaul is primarily Trango (though that's likely to change at some point), and the customer APs are all either StarOS running on RouterBoard 200 hardware, or realy old Lucent APs with Karlnet software installed. StarOS doesn't export a lot of the data we're looking for, as far as I and my copy of snmpwalk can tell. (If I can read my boss's mind as well as I think I can, though, he's probably looking more for backhaul stats than for individual customer APs.) Trango supposedly does, but even their own forums are filled with people who can't make any sense out of Trango's provided MIBs and such. (I can usually get one-shot queries with snmpwalk and similar tools to work, but when you put the exact same parameters into an MRTG configuration file, I get back nothing but crazy bizarre errors. The fact that Trango changes their MIBs between hardware versions and occasionally even between firmware releases only compounds the problem.) At the risk of derailing (sorry, boss), has anyone gotten MRTG or something similar (PRTG, Denika, or whatever) to reliably track *anything* on a Trango? dave -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Martin Stewart Reply
Well, as one of the list members who received the spam, with this apology in hand, I'd give him a second chance But I don't run the list, so I guess it is up to you, Rick. Rick Harnish wrote: The following is a copy of a reply that Martin tried to send to the list this morning after I removed him. WISPA members, I sent an e-mail off-list to seven WISPA members. My intention was to find the person at each of these companies who is responsible for business development partnerships. We are not selling a service. We have a solution that gives the ISP part of the money that advertiser pay to web publishers for placing more relevant ads for the ISP’s end users. We have partnerships with national wholesale Internet providers and regional ISPs. The seven WISPs that I contacted through WISPA were the first Wireless based ISPs that I have spoken with to date. I apologize for causing such a commotion with your list. We offer a way for an ISP to increase the revenue earned per end user and I thought that this would be welcomed news to your members if they chose to respond to my e-mail. I will discontinue using e-mail to contact your members. Respectfully, Martin Stewart Adzilla New Media No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.12.7/160 - Release Date: 11/3/2005 -- Blair Davis AOL IM Screen Name -- Theory240 West Michigan Wireless ISP 269-686-8648 A division of: Camp Communication Services, INC -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
RE: [WISPA] Tracking Signal / Noise / Resends / Etc.
Dave, I monitor all my Trango backhauls traffic via MRTG. I downloaded their MRTG instructions and followed them. It was fairly painless. Todd Barber Skylink Broadband Internet [EMAIL PROTECTED] 970-454-9499 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David E. Smith Sent: Thursday, November 03, 2005 1:10 PM To: WISPA General List Subject: Re: [WISPA] Tracking Signal / Noise / Resends / Etc. rcomroe wrote: > There are 2 fundamentally different approaches for monitoring. [ stuff ] For reference, in the network Scriv is describing, there's a nasty mixture of gear. Backhaul is primarily Trango (though that's likely to change at some point), and the customer APs are all either StarOS running on RouterBoard 200 hardware, or realy old Lucent APs with Karlnet software installed. StarOS doesn't export a lot of the data we're looking for, as far as I and my copy of snmpwalk can tell. (If I can read my boss's mind as well as I think I can, though, he's probably looking more for backhaul stats than for individual customer APs.) Trango supposedly does, but even their own forums are filled with people who can't make any sense out of Trango's provided MIBs and such. (I can usually get one-shot queries with snmpwalk and similar tools to work, but when you put the exact same parameters into an MRTG configuration file, I get back nothing but crazy bizarre errors. The fact that Trango changes their MIBs between hardware versions and occasionally even between firmware releases only compounds the problem.) At the risk of derailing (sorry, boss), has anyone gotten MRTG or something similar (PRTG, Denika, or whatever) to reliably track *anything* on a Trango? dave -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.12.7/160 - Release Date: 11/3/2005 -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
RE: [WISPA] Tracking Signal / Noise / Resends / Etc.
StarOS isn't great for SNMP but Starutil works really well for various stuff. We have been using it to graph with MRTG the signal levels for individual clients and backhaul links as well as throughput. Cheers, P. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David E. Smith Sent: 03 November 2005 20:10 To: WISPA General List Subject: Re: [WISPA] Tracking Signal / Noise / Resends / Etc. rcomroe wrote: > There are 2 fundamentally different approaches for monitoring. [ stuff ] For reference, in the network Scriv is describing, there's a nasty mixture of gear. Backhaul is primarily Trango (though that's likely to change at some point), and the customer APs are all either StarOS running on RouterBoard 200 hardware, or realy old Lucent APs with Karlnet software installed. StarOS doesn't export a lot of the data we're looking for, as far as I and my copy of snmpwalk can tell. (If I can read my boss's mind as well as I think I can, though, he's probably looking more for backhaul stats than for individual customer APs.) Trango supposedly does, but even their own forums are filled with people who can't make any sense out of Trango's provided MIBs and such. (I can usually get one-shot queries with snmpwalk and similar tools to work, but when you put the exact same parameters into an MRTG configuration file, I get back nothing but crazy bizarre errors. The fact that Trango changes their MIBs between hardware versions and occasionally even between firmware releases only compounds the problem.) At the risk of derailing (sorry, boss), has anyone gotten MRTG or something similar (PRTG, Denika, or whatever) to reliably track *anything* on a Trango? dave -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.12.7/159 - Release Date: 02/11/2005 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.12.7/159 - Release Date: 02/11/2005 -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Tracking Signal / Noise / Resends / Etc.
At the risk of derailing (sorry, boss), has anyone gotten MRTG or something similar (PRTG, Denika, or whatever) to reliably track *anything* on a Trango? Sure. TrangoLINK-10 integrated with Nagios and MRTG. However, I had to write a wrapper perl script around the Nagios RSSI check_command because it would report spurious error values (-99dBm) causing false alerts. The script just re-issues the SNMP query again to get the correct value. -- Nigel. -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Tracking Signal / Noise / Resends / Etc.
rcomroe wrote: > There are 2 fundamentally different approaches for monitoring. [ stuff ] For reference, in the network Scriv is describing, there's a nasty mixture of gear. Backhaul is primarily Trango (though that's likely to change at some point), and the customer APs are all either StarOS running on RouterBoard 200 hardware, or realy old Lucent APs with Karlnet software installed. StarOS doesn't export a lot of the data we're looking for, as far as I and my copy of snmpwalk can tell. (If I can read my boss's mind as well as I think I can, though, he's probably looking more for backhaul stats than for individual customer APs.) Trango supposedly does, but even their own forums are filled with people who can't make any sense out of Trango's provided MIBs and such. (I can usually get one-shot queries with snmpwalk and similar tools to work, but when you put the exact same parameters into an MRTG configuration file, I get back nothing but crazy bizarre errors. The fact that Trango changes their MIBs between hardware versions and occasionally even between firmware releases only compounds the problem.) At the risk of derailing (sorry, boss), has anyone gotten MRTG or something similar (PRTG, Denika, or whatever) to reliably track *anything* on a Trango? dave -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Martin Stewart Reply
Sounds apologetic. Is he back on? If it's his first contact with WISPs I'd hate for him to think we're a bunch of jerks. Rick Harnish wrote: The following is a copy of a reply that Martin tried to send to the list this morning after I removed him. WISPA members, I sent an e-mail off-list to seven WISPA members. My intention was to find the person at each of these companies who is responsible for business development partnerships. We are not selling a service. We have a solution that gives the ISP part of the money that advertiser pay to web publishers for placing more relevant ads for the ISP’s end users. We have partnerships with national wholesale Internet providers and regional ISPs. The seven WISPs that I contacted through WISPA were the first Wireless based ISPs that I have spoken with to date. I apologize for causing such a commotion with your list. We offer a way for an ISP to increase the revenue earned per end user and I thought that this would be welcomed news to your members if they chose to respond to my e-mail. I will discontinue using e-mail to contact your members. Respectfully, Martin Stewart Adzilla New Media No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.12.7/160 - Release Date: 11/3/2005 -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
[WISPA] Martin Stewart Reply
The following is a copy of a reply that Martin tried to send to the list this morning after I removed him. WISPA members, I sent an e-mail off-list to seven WISPA members. My intention was to find the person at each of these companies who is responsible for business development partnerships. We are not selling a service. We have a solution that gives the ISP part of the money that advertiser pay to web publishers for placing more relevant ads for the ISP’s end users. We have partnerships with national wholesale Internet providers and regional ISPs. The seven WISPs that I contacted through WISPA were the first Wireless based ISPs that I have spoken with to date. I apologize for causing such a commotion with your list. We offer a way for an ISP to increase the revenue earned per end user and I thought that this would be welcomed news to your members if they chose to respond to my e-mail. I will discontinue using e-mail to contact your members. Respectfully, Martin Stewart Adzilla New Media -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
[WISPA] WISP In Bridgewater Massachusetts ?
I have a potential customer there that wants a solution. Any WISP in the area? Contact me off-list. We don't provide service in that area. -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
RE: [WISPA] Tracking Signal / Noise / Resends / Etc.
For StarOS we use MRTG and Starutil. You should be able to graph anything that Starutil can provide. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Scrivner Sent: 03 November 2005 17:33 To: wireless@wispa.org Subject: [WISPA] Tracking Signal / Noise / Resends / Etc. I am starting to feel the pains of trying to accurately trace problems in a network that is getting increasingly larger all the time. We have roughly 20 tower locations now. We have a pretty good picture of what we are getting for bandwidth use through our MRTG graphs. We can see when any link completely drops thanks to our What's Up monitoring. We can easily track and isolate peer to peer abuse and such with traffic analysis tools in Star OS and Mikrotik as needed. What we need though is a way to track the other parameters of our network over time. It would be invaluable to me to be able to look over historical records from a hour long window up to a year long window for link integrity information. What I mean is this. I would like to see how a signal level, noise level, number of retransmits, etc. changes over time in a graph format like MRTG does with bits in and out. It would be nice to add other parameters as needed. I know SNMP is supposed to be able to do this but I do not have the slightest bit of experience using that. Is there anyone out there who knows an easy way of getting a rudimentary level of understanding about using SNMP to extract data such as this? Maybe someone has a package they use that provides this information on your network? If any WISPs out there have any answers to this please respond on this list. If you are a vendor and your product can do specifically what I am asking for above then I am sure we would like to hear about that too. Maybe if a few of us buy your products you will consider buying a vendor membership to WISPA also.:-) Thanks guys, Scriv -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.12.7/159 - Release Date: 02/11/2005 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.12.7/159 - Release Date: 02/11/2005 -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Tracking Signal / Noise / Resends / Etc.
There are 2 fundamentally different approaches for monitoring. [1] Poll parameters and strip-chart them displaying some specific duration of history. In this approach data rolls off the end of the strip-chart and is not retained. Only numerical data can be displayed graphically is appropriate for strip-charting. It's strength is that charts are updated at the moment of polling, so all charts are "already made" and it's easy to review many charts at a time (since there's no waiting time at the time you want to view). [2] Poll parameters and save them in a continuous log file. The strength of this approach is any kind of data can be recorded (numeric or text), and performance can be reviewed for any recorded data (you can look back in time, zoom in on any previous moment). The disadvantage of this approach is that data is "graphed" at the moment of viewing and therefore not as convenient for perusing "multiple graphs at a time" since graphing time must be waited at the time of viewing. Don't confuse long-term strip charting for an equivalent. While you can indeed make a strip-chart display data for a whole "year", typically strip-charts only record the last 400 datapoints over history ... while polling every 5 minutes may provide a history of a couple days retaining all data, charts that display longer term are only retaining average data over longer and longer periods (you lose the actual data polled every 5 minutes). A good tool is one that can do both as appropriate for a given parameter. As far as SNMP, that's just an access protocol. Typically devices provide diagnostics on a web page, or in an SNMP agent. Some devices support both, some support only one. A good tool is one that can poll for data by either access protocol which will serve you best with any collection of equipment. Rich - Original Message - From: "John Scrivner" <[EMAIL PROTECTED]> To: Sent: Thursday, November 03, 2005 11:32 AM Subject: [WISPA] Tracking Signal / Noise / Resends / Etc. I am starting to feel the pains of trying to accurately trace problems in a network that is getting increasingly larger all the time. We have roughly 20 tower locations now. We have a pretty good picture of what we are getting for bandwidth use through our MRTG graphs. We can see when any link completely drops thanks to our What's Up monitoring. We can easily track and isolate peer to peer abuse and such with traffic analysis tools in Star OS and Mikrotik as needed. What we need though is a way to track the other parameters of our network over time. It would be invaluable to me to be able to look over historical records from a hour long window up to a year long window for link integrity information. What I mean is this. I would like to see how a signal level, noise level, number of retransmits, etc. changes over time in a graph format like MRTG does with bits in and out. It would be nice to add other parameters as needed. I know SNMP is supposed to be able to do this but I do not have the slightest bit of experience using that. Is there anyone out there who knows an easy way of getting a rudimentary level of understanding about using SNMP to extract data such as this? Maybe someone has a package they use that provides this information on your network? If any WISPs out there have any answers to this please respond on this list. If you are a vendor and your product can do specifically what I am asking for above then I am sure we would like to hear about that too. Maybe if a few of us buy your products you will consider buying a vendor membership to WISPA also.:-) Thanks guys, Scriv -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
[WISPA] Tracking Signal / Noise / Resends / Etc.
I am starting to feel the pains of trying to accurately trace problems in a network that is getting increasingly larger all the time. We have roughly 20 tower locations now. We have a pretty good picture of what we are getting for bandwidth use through our MRTG graphs. We can see when any link completely drops thanks to our What's Up monitoring. We can easily track and isolate peer to peer abuse and such with traffic analysis tools in Star OS and Mikrotik as needed. What we need though is a way to track the other parameters of our network over time. It would be invaluable to me to be able to look over historical records from a hour long window up to a year long window for link integrity information. What I mean is this. I would like to see how a signal level, noise level, number of retransmits, etc. changes over time in a graph format like MRTG does with bits in and out. It would be nice to add other parameters as needed. I know SNMP is supposed to be able to do this but I do not have the slightest bit of experience using that. Is there anyone out there who knows an easy way of getting a rudimentary level of understanding about using SNMP to extract data such as this? Maybe someone has a package they use that provides this information on your network? If any WISPs out there have any answers to this please respond on this list. If you are a vendor and your product can do specifically what I am asking for above then I am sure we would like to hear about that too. Maybe if a few of us buy your products you will consider buying a vendor membership to WISPA also.:-) Thanks guys, Scriv begin:vcard fn:John Scrivner n:Scrivner;John org:Mt. Vernon. Net, Inc. adr;dom:PO Box 1582;;1 Dr Park Road Suite H1;Mt. Vernon;Il;62864 email;internet:[EMAIL PROTECTED] title:President tel;work:618-244-6868 url:http://www.mvn.net/ version:2.1 end:vcard -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] FW: [TVWHITESPACE] FW: Broadcast to Broadband:Prominent Engineers Dismiss TV Industry Interference Claims inNew Paper
Most importantly, I would find the "key" aides in each respective office who handles such topics. Email and fax your personal comment to them and follow up with a phone call if possible. If you plan on being active in communicating to your state and federal representatives, get to know what committees they are on, since that's where much of their focus is going to be. Whereas other issues will be researched by aides and give the Senator or Rep reports and voting suggestions. Get to know the "key" people in each office in your local districts. Lunch anyone? Congress works mostly from Tues through Thurs depending on the importance and amount of issues, and most travel back to their home districts for the weekend. Remember you are a potential vote as well as the potential of steering your customers as well. Frank Muto Co-founder - Washington Bureau for ISP Advocacy - WBIA Telecom Summit Ad Hoc Committee http://gigabytemarch.blog.com/ www.wbia.us - Original Message - From: "Ron Wallace" <[EMAIL PROTECTED]> > Thanks for the heads up Rick, I'll forward this to my senator > and rep. > > Original message > >Date: Wed, 2 Nov 2005 22:03:06 -0500 > >From: "Rick Harnish" <[EMAIL PROTECTED]> > >Subject: [WISPA] FW: [TVWHITESPACE] FW: Broadcast to > Broadband: Prominent Engineers Dismiss TV Industry > Interference Claims in New Paper > >To: "'WISPA General List'" > > > > > > From: FCC NPRM for UHF TV Band Unlicensed Use > > [mailto:[EMAIL PROTECTED] On Behalf Of > > Michael Calabrese > > Sent: Wednesday, November 02, 2005 5:09 PM > > To: [EMAIL PROTECTED] > > Subject: [TVWHITESPACE] FW: Broadcast to Broadband: > > Prominent Engineers Dismiss TV Industry Interference > > Claims in New Paper > > > > > > > > Experts Refute TV Industry Claims on DTV Reception > > Issue > > > > Three Prominent Engineers State that Opening Vacant > > Channels for Wireless Broadband Will Not Interfere > > with Television Reception > > > > > > > > Last week, on a bipartisan basis, the House Commerce > > Committee approved an amendment to its digital TV > > transition bill directing the FCC to complete > > its proposed rulemaking to open up vacant, unused > > channels in the TV band spectrum (also known as > > "white space") for unlicensed wireless broadband use > > (Docket 04-186). > > > > > > > > Last year, the FCC issued a proposed rulemaking to > > allow "smart" wireless broadband devices to utilize > > empty TV channels between Chs. 2 and 51 on a > > market-by-market basis. Opening wasted TV spectrum > > for broadband in each market will especially benefit > > rural areas. Unfortunately, this proceeding has > > stalled at the Commission under Chairman Kevin > > Martin. The broadcast industry opposes the House > > amendment and the FCC's proceeding, claiming that > > unlicensed devices operating in vacant TV > > channels could cause harmful interference to TV > > signals on nearby channels. > > > > > > > > New America's Issue Brief -- authored by three of > > the nation's most respected spectrum > > engineers -- demonstrates why the > > industry's technical claims are unfounded. > > "Reclaiming the Vast Wasteland: Why Unlicensed Use > > of the White Space in the TV Bands Will Not Cause > > Interference to DTV Viewers," explains why the > > interference-avoidance mechanisms proposed by the > > FCC are sufficient to ensure that DTV reception > > is not harmed by unlicensed devices. The co-authors > > are: > > > > o Michael Marcus, former FCC Associate Chief for > > Technology, Office of Engineering and Technology > > o Paul Kolodzy, former Chair, FCC Spectrum Policy > > Task Force > > o Andrew Lippman, founding Associate Director, MIT > > Media Lab > > > > > > > > - For a more detailed version of the paper's > > argument, refer to the Technical Reply Comments of > > the New America Foundation, et al. in the > > above-referenced proceeding. > > > > > > > > - For more background on the broadcast > > industry's spurious claims regarding interference, > > refer to New America Foundation's fact sheet. > > > > > > > > - For a brief explanation of why utilizing vacant TV > > channels for broadband is important and feasible, > > see the statement by former FCC Chief Engineer > > Edmond Thomas from New America's September 7th > > Capitol Hill Briefing. > > > > > > > > > > > > Thanks for your interest. > > > > > > > > Michael Calabrese > > > > Director, Wireless Future Program > > > > New America Foundation > > > > > > > > > > > > > > > > Logo > > > > > > Cover Story > > > > Unlicensed wireless advocates after TV white space > > > > By Heather Forsgren Weaver > > > > Oct 28, 2005 > > > > WASHINGTON-Advocates of unlicensed spectrum are > > trying to get their hands on TV airwaves they > > believe w
Re: [WISPA] Spammer removed
Way to go, RICK!! Original message >Date: Thu, 3 Nov 2005 08:55:47 -0500 >From: "Rick Harnish" <[EMAIL PROTECTED]> >Subject: [WISPA] Spammer removed >To: "'WISPA General List'" > > Link: File-List > Link: Edit-Time-Data > > I have removed two addresses from our list for > spamming. [EMAIL PROTECTED] and > [EMAIL PROTECTED] I assume they are one and the > same person. If anyone knows differently, please > let me know. > > > > Thank you, > > > > Rick Harnish > > President > > OnlyInternet Broadband & Wireless, Inc. > > 260-827-2482 Office > > 260-307-4000 Cell > > 260-918-4340 VoIP > > www.oibw.net > > [EMAIL PROTECTED] > > > > [IMG] > > > > [IMG] > > > >-- >WISPA Wireless List: wireless@wispa.org > >Subscribe/Unsubscribe: >http://lists.wispa.org/mailman/listinfo/wireless > >Archives: http://lists.wispa.org/pipermail/wireless/ Ron Wallace Hahnron, Inc. 220 S. Jackson St. Addison, MI 49220 Phone: (517) 547-8410 Mobile: (517) 605-4542 e-mail: [EMAIL PROTECTED] -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] FW: [TVWHITESPACE] FW: Broadcast to Broadband: Prominent Engineers Dismiss TV Industry Interference Claims in New Paper
Thanks for the heads up Rick, I'll forward this to my senator and rep. Original message >Date: Wed, 2 Nov 2005 22:03:06 -0500 >From: "Rick Harnish" <[EMAIL PROTECTED]> >Subject: [WISPA] FW: [TVWHITESPACE] FW: Broadcast to Broadband: Prominent Engineers Dismiss TV Industry Interference Claims in New Paper >To: "'WISPA General List'" > > Link: File-List > Link: Edit-Time-Data > > FYI > > > > Rick Harnish > > President > > OnlyInternet Broadband & Wireless, Inc. > > 260-827-2482 Office > > 260-307-4000 Cell > > 260-918-4340 VoIP > > www.oibw.net > > [EMAIL PROTECTED] > > > > [IMG] > > > > [IMG] > > > > From: FCC NPRM for UHF TV Band Unlicensed Use > [mailto:[EMAIL PROTECTED] On Behalf Of > Michael Calabrese > Sent: Wednesday, November 02, 2005 5:09 PM > To: [EMAIL PROTECTED] > Subject: [TVWHITESPACE] FW: Broadcast to Broadband: > Prominent Engineers Dismiss TV Industry Interference > Claims in New Paper > > > > Experts Refute TV Industry Claims on DTV Reception > Issue > > Three Prominent Engineers State that Opening Vacant > Channels for Wireless Broadband Will Not Interfere > with Television Reception > > > > Last week, on a bipartisan basis, the House Commerce > Committee approved an amendment to its digital TV > transition bill directing the FCC to complete > its proposed rulemaking to open up vacant, unused > channels in the TV band spectrum (also known as > "white space") for unlicensed wireless broadband use > (Docket 04-186). > > > > Last year, the FCC issued a proposed rulemaking to > allow "smart" wireless broadband devices to utilize > empty TV channels between Chs. 2 and 51 on a > market-by-market basis. Opening wasted TV spectrum > for broadband in each market will especially benefit > rural areas. Unfortunately, this proceeding has > stalled at the Commission under Chairman Kevin > Martin. The broadcast industry opposes the House > amendment and the FCC's proceeding, claiming that > unlicensed devices operating in vacant TV > channels could cause harmful interference to TV > signals on nearby channels. > > > > New America's Issue Brief -- authored by three of > the nation's most respected spectrum > engineers -- demonstrates why the > industry's technical claims are unfounded. > "Reclaiming the Vast Wasteland: Why Unlicensed Use > of the White Space in the TV Bands Will Not Cause > Interference to DTV Viewers," explains why the > interference-avoidance mechanisms proposed by the > FCC are sufficient to ensure that DTV reception > is not harmed by unlicensed devices. The co-authors > are: > > o Michael Marcus, former FCC Associate Chief for > Technology, Office of Engineering and Technology > o Paul Kolodzy, former Chair, FCC Spectrum Policy > Task Force > o Andrew Lippman, founding Associate Director, MIT > Media Lab > > > > - For a more detailed version of the paper's > argument, refer to the Technical Reply Comments of > the New America Foundation, et al. in the > above-referenced proceeding. > > > > - For more background on the broadcast > industry's spurious claims regarding interference, > refer to New America Foundation's fact sheet. > > > > - For a brief explanation of why utilizing vacant TV > channels for broadband is important and feasible, > see the statement by former FCC Chief Engineer > Edmond Thomas from New America's September 7th > Capitol Hill Briefing. > > > > > > Thanks for your interest. > > > > Michael Calabrese > > Director, Wireless Future Program > > New America Foundation > > > > > > > > Logo > > > Cover Story > > Unlicensed wireless advocates after TV white space > > By Heather Forsgren Weaver > > Oct 28, 2005 > > WASHINGTON-Advocates of unlicensed spectrum are > trying to get their hands on TV airwaves they > believe will be available in channels 2-51 following > the transition to digital TV. > > After the digital conversion there will be unused > spectrum in many areas, so advocates for unlicensed > spectrum are calling for this white space. > > "The TV band has been
[WISPA] Spammer removed
I have removed two addresses from our list for spamming. [EMAIL PROTECTED] and [EMAIL PROTECTED]. I assume they are one and the same person. If anyone knows differently, please let me know. Thank you, Rick Harnish President OnlyInternet Broadband & Wireless, Inc. 260-827-2482 Office 260-307-4000 Cell 260-918-4340 VoIP www.oibw.net [EMAIL PROTECTED] -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/