Re: [WISPA] Maximum sector power?
How about the age old, if your AP talks to one client at a time, then it is a ptp system. Much more so now with scheduling and UBNT's AirMax. I'm still on the talk about a 120* or less allows you to increase beyond 36 on each end. The talk was coming from the FCC a few years back from people like Van Budweiser and Dr. Pepper. -- Original Message -- From: Rubens Kuhl rube...@gmail.com Reply-To: WISPA General List wireless@wispa.org Date: Thu, 24 Jun 2010 01:43:03 -0300 The PtP/PtMP distinction does create interesting ambiguity. But then My favorite ambiguity is whether the PtP/PtMP distinction applies to the full-duplex system or per traffic direction... one reading would say that an uplink(Customer - WISP) that is made using directive antennas can follow PtP instead of PtMP rules, which would apply only to the downlink (WISP - Customer) . Rubens 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/ Sent via the WebMail system at avolve.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/
Re: [WISPA] Maximum sector power?
Or you can be legit in Canada, and go for 3.65 GHz and get up to 57 dBM legally in rural areas ;) Courtesy of the guy that changed the rules for 3.65 in Canada and is looking for the US to do the same... F. On 2010-06-23, at 5:41 PM, Fred R. Goldstein wrote: I'm just a little confused about some of these nice-looking access points. The UBNT Rocket M5, for instance, can put out +27 dBm. It plugs *right into* a nice 19dB sector antenna. Okay, the smaller, 120 dB sector is only 16 dB. Now math is not really my thing but I get a total ERP there of +43 to 46 dBm. FCC Rule 15.247 states that the maximum transmitted power output for digitally-modulated intentional radiators in the 5725-5850 MHz band (ISM) is 1 watt, and the maximum antenna gain is 6 dBi. Each additional dB of antanna gain means one less dB of power. So the maximum ERP is 4 watts (+36). Point-to-point is an exception in that specific band; it is allowed unlimited antenna gain. But point-to-multipoint systems, omnidirectional applications, and multiple co-located intentional radiators transmitting the same information are under the cap. So am I correct in assuming that everybody who uses the Rocket M5, or any other similar PtMP system for subscriber access, turns the transmitter power REAL low (~+20 + feedline loss), in order to keep the ERP below +36? Or are we assuming that since you're technically only transmitting and receiving to one end user at a time, it's really PtP? SkyPilot's legal hack, of course, is to have eight 45 degree sector antennas and only use one at a time, so it is legally PTP even with +42 EiRP. And with advanced 11N 4x4 beamforming antennas, something like that will become relatively easy. But we're not quite there yet. Thoughts? -- Fred Goldsteink1io fgoldstein at ionary.com ionary Consulting http://www.ionary.com/ +1 617 795 2701 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] Maximum sector power?
I see negligible difference in signal strength anyway between 20 and 27. -- Original Message -- From: Francois Menard fmen...@xittel.net Reply-To: WISPA General List wireless@wispa.org Date: Thu, 24 Jun 2010 09:03:59 -0400 Or you can be legit in Canada, and go for 3.65 GHz and get up to 57 dBM legally in rural areas ;) Courtesy of the guy that changed the rules for 3.65 in Canada and is looking for the US to do the same... F. On 2010-06-23, at 5:41 PM, Fred R. Goldstein wrote: I'm just a little confused about some of these nice-looking access points. The UBNT Rocket M5, for instance, can put out +27 dBm. It plugs *right into* a nice 19dB sector antenna. Okay, the smaller, 120 dB sector is only 16 dB. Now math is not really my thing but I get a total ERP there of +43 to 46 dBm. FCC Rule 15.247 states that the maximum transmitted power output for digitally-modulated intentional radiators in the 5725-5850 MHz band (ISM) is 1 watt, and the maximum antenna gain is 6 dBi. Each additional dB of antanna gain means one less dB of power. So the maximum ERP is 4 watts (+36). Point-to-point is an exception in that specific band; it is allowed unlimited antenna gain. But point-to-multipoint systems, omnidirectional applications, and multiple co-located intentional radiators transmitting the same information are under the cap. So am I correct in assuming that everybody who uses the Rocket M5, or any other similar PtMP system for subscriber access, turns the transmitter power REAL low (~+20 + feedline loss), in order to keep the ERP below +36? Or are we assuming that since you're technically only transmitting and receiving to one end user at a time, it's really PtP? SkyPilot's legal hack, of course, is to have eight 45 degree sector antennas and only use one at a time, so it is legally PTP even with +42 EiRP. And with advanced 11N 4x4 beamforming antennas, something like that will become relatively easy. But we're not quite there yet. Thoughts? -- Fred Goldsteink1io fgoldstein at ionary.com ionary Consulting http://www.ionary.com/ +1 617 795 2701 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/ Sent via the WebMail system at avolve.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/
Re: [WISPA] Wierd StarOS/OLSR - Ubiquity RocketM5 bridge - Cisco issue
I didn't quite follow all of that, it must be too early. But I can tell you we have 4 of the PtP UBNT links using their M-series. 3 of those OSPF fine. The other won't OSPF for the life of me. All same config and firmware on all units. On Thu, Jun 24, 2010 at 4:38 AM, Scott Lambert lamb...@lambertfam.orgwrote: We have been putting up some Ubiquity RocketM5 point-to-point bridge links, running airos 5.2, lately to replace some overloaded StarOS backhauls. Where these links have gone in, we static route the traffic across them. They happen to be on the OSPF/OLSR divider boundry. I would like to find a good way to redistribute between the routing protocols, but that's for another day. When I get time, I'll probably just convert the 20 odd OLSR towers to OSPF. These are our first experience with Ubiquity. The first two were no muss, no fuss. The third link went up nicely. It's configured the same as the other two links. About an hour after we plugged the local end at our office into the main switch, rather than a laptop, we started loosing routes to sites which pass through the tower at the far end of the link. All hosts on the tower LAN can see each other. We can reach all of them from anywhere else on our network. It is just routes for hosts connected wirelessly to that tower which are no longer known to the staros box which has the existing backhaul to our office. We rebooted everything at the remote tower. The links came up. The routes were good. Approximately an hour later, the same routes fell out. So, we decided it must be due to some sort of wierd multicast OLSR issue when these towers were suddenly able to see each other across the bridges. I unplugged the ethernet at the office and waited until tonight to try again. The routes straightened themselves out as soon as I unplugged the office end. Wild. This afternoon, I setup a seperate VLAN on the switch for this link. Before I left the office I plugged it in about, 8:00pm. I didn't have any other devices configured on that VLAN. There were no problems for several hours until I configured the new VLAN on the Cisco that was sometime between 1:01 and 1:10am. The RANCID run at 1:01 didn't see any changes but the run at 2:01 found them. At 1:10am Nagios noticed that it couldn't reach the equipment through those same routes. + interface GigabitEthernet0/3.13 + description Wireless VPN 3 + encapsulation dot1Q 13 + ip address 10.127.3.1 255.255.255.0 + no cdp enable + ! That's the subnet for the RocketM5s. The StarOS gear on the tower uses a public /29 subnet. I tried various things with reboots and restarts of OLSR on the staros gear at the tower. The routes came back for four or five minutes then went away again. No good. So, at about 2:10am, I logged into the RocketM5 at the tower and disabled it's ethernet interface. Within a few seconds, my pings to equipment through the lost routes began succeeding. It's now 3:25, and all's well. I am puzzled. We really need the additional bandwidth the ubiquity link can give us on this link. At 3:26 I enabled the LAN at the tower just to make sure. Within 2 minutes, splat. This time I left the LAN enabled at the tower and disabled the WLAN interface at the office. All better in seconds. Administratively shutting down interface gig0/3.13 at the office seems to be enough to heal OLSR at the tower. If the tower LAN can see the cisco, we drop routes. But the other ubiquity links connect back to the same cisco at the office. I think we will probably replace the switch at the tower tomorrow to see if it has problems we haven't tickled before. I'm stumped. Does anyone else have any ideas? -- Scott LambertKC5MLE Unix SysAdmin lamb...@lambertfam.org 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] Maximum sector power?
Now, do this. Take a Mikrotik, set the transmitting antenna to A, and put your smaller sector up, then put on the B connector the largest sector you can find. :) That work? --- Dennis Burgess, Mikrotik Certified Trainer Link Technologies, Inc -- Mikrotik WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of Learn RouterOS -Original Message- From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On Behalf Of Fred R. Goldstein Sent: Wednesday, June 23, 2010 4:41 PM To: WISPA General List Subject: [WISPA] Maximum sector power? I'm just a little confused about some of these nice-looking access points. The UBNT Rocket M5, for instance, can put out +27 dBm. It plugs *right into* a nice 19dB sector antenna. Okay, the smaller, 120 dB sector is only 16 dB. Now math is not really my thing but I get a total ERP there of +43 to 46 dBm. FCC Rule 15.247 states that the maximum transmitted power output for digitally-modulated intentional radiators in the 5725-5850 MHz band (ISM) is 1 watt, and the maximum antenna gain is 6 dBi. Each additional dB of antanna gain means one less dB of power. So the maximum ERP is 4 watts (+36). Point-to-point is an exception in that specific band; it is allowed unlimited antenna gain. But point-to-multipoint systems, omnidirectional applications, and multiple co-located intentional radiators transmitting the same information are under the cap. So am I correct in assuming that everybody who uses the Rocket M5, or any other similar PtMP system for subscriber access, turns the transmitter power REAL low (~+20 + feedline loss), in order to keep the ERP below +36? Or are we assuming that since you're technically only transmitting and receiving to one end user at a time, it's really PtP? SkyPilot's legal hack, of course, is to have eight 45 degree sector antennas and only use one at a time, so it is legally PTP even with +42 EiRP. And with advanced 11N 4x4 beamforming antennas, something like that will become relatively easy. But we're not quite there yet. Thoughts? -- Fred Goldsteink1io fgoldstein at ionary.com ionary Consulting http://www.ionary.com/ +1 617 795 2701 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] Maximum sector power?
FYI. Please make sure that you are running the most recent version 5.2 on the M series... Older firmware had known issues in setting up the output power. Faisal On Jun 24, 2010, at 10:06 AM, Stuart Pierce spie...@avolve.net wrote: I see negligible difference in signal strength anyway between 20 and 27. -- Original Message -- From: Francois Menard fmen...@xittel.net Reply-To: WISPA General List wireless@wispa.org Date: Thu, 24 Jun 2010 09:03:59 -0400 Or you can be legit in Canada, and go for 3.65 GHz and get up to 57 dBM legally in rural areas ;) Courtesy of the guy that changed the rules for 3.65 in Canada and is looking for the US to do the same... F. On 2010-06-23, at 5:41 PM, Fred R. Goldstein wrote: I'm just a little confused about some of these nice-looking access points. The UBNT Rocket M5, for instance, can put out +27 dBm. It plugs *right into* a nice 19dB sector antenna. Okay, the smaller, 120 dB sector is only 16 dB. Now math is not really my thing but I get a total ERP there of +43 to 46 dBm. FCC Rule 15.247 states that the maximum transmitted power output for digitally-modulated intentional radiators in the 5725-5850 MHz band (ISM) is 1 watt, and the maximum antenna gain is 6 dBi. Each additional dB of antanna gain means one less dB of power. So the maximum ERP is 4 watts (+36). Point-to-point is an exception in that specific band; it is allowed unlimited antenna gain. But point-to-multipoint systems, omnidirectional applications, and multiple co-located intentional radiators transmitting the same information are under the cap. So am I correct in assuming that everybody who uses the Rocket M5, or any other similar PtMP system for subscriber access, turns the transmitter power REAL low (~+20 + feedline loss), in order to keep the ERP below +36? Or are we assuming that since you're technically only transmitting and receiving to one end user at a time, it's really PtP? SkyPilot's legal hack, of course, is to have eight 45 degree sector antennas and only use one at a time, so it is legally PTP even with +42 EiRP. And with advanced 11N 4x4 beamforming antennas, something like that will become relatively easy. But we're not quite there yet. Thoughts? -- Fred Goldsteink1io fgoldstein at ionary.com ionary Consulting http://www.ionary.com/ +1 617 795 2701 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/ Sent via the WebMail system at avolve.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] Wierd StarOS/OLSR - Ubiquity RocketM5 bridge - Cisco issue
Make sure you are running the most recent version of 5.2 firmware.also you need to be running then in AP-WDS and CPE-WDS mode. Faisal On Jun 24, 2010, at 9:08 AM, Jayson Baker jay...@spectrasurf.com wrote: I didn't quite follow all of that, it must be too early. But I can tell you we have 4 of the PtP UBNT links using their M-series. 3 of those OSPF fine. The other won't OSPF for the life of me. All same config and firmware on all units. On Thu, Jun 24, 2010 at 4:38 AM, Scott Lambert lamb...@lambertfam.orgwrote: We have been putting up some Ubiquity RocketM5 point-to-point bridge links, running airos 5.2, lately to replace some overloaded StarOS backhauls. Where these links have gone in, we static route the traffic across them. They happen to be on the OSPF/OLSR divider boundry. I would like to find a good way to redistribute between the routing protocols, but that's for another day. When I get time, I'll probably just convert the 20 odd OLSR towers to OSPF. These are our first experience with Ubiquity. The first two were no muss, no fuss. The third link went up nicely. It's configured the same as the other two links. About an hour after we plugged the local end at our office into the main switch, rather than a laptop, we started loosing routes to sites which pass through the tower at the far end of the link. All hosts on the tower LAN can see each other. We can reach all of them from anywhere else on our network. It is just routes for hosts connected wirelessly to that tower which are no longer known to the staros box which has the existing backhaul to our office. We rebooted everything at the remote tower. The links came up. The routes were good. Approximately an hour later, the same routes fell out. So, we decided it must be due to some sort of wierd multicast OLSR issue when these towers were suddenly able to see each other across the bridges. I unplugged the ethernet at the office and waited until tonight to try again. The routes straightened themselves out as soon as I unplugged the office end. Wild. This afternoon, I setup a seperate VLAN on the switch for this link. Before I left the office I plugged it in about, 8:00pm. I didn't have any other devices configured on that VLAN. There were no problems for several hours until I configured the new VLAN on the Cisco that was sometime between 1:01 and 1:10am. The RANCID run at 1:01 didn't see any changes but the run at 2:01 found them. At 1:10am Nagios noticed that it couldn't reach the equipment through those same routes. + interface GigabitEthernet0/3.13 + description Wireless VPN 3 + encapsulation dot1Q 13 + ip address 10.127.3.1 255.255.255.0 + no cdp enable + ! That's the subnet for the RocketM5s. The StarOS gear on the tower uses a public /29 subnet. I tried various things with reboots and restarts of OLSR on the staros gear at the tower. The routes came back for four or five minutes then went away again. No good. So, at about 2:10am, I logged into the RocketM5 at the tower and disabled it's ethernet interface. Within a few seconds, my pings to equipment through the lost routes began succeeding. It's now 3:25, and all's well. I am puzzled. We really need the additional bandwidth the ubiquity link can give us on this link. At 3:26 I enabled the LAN at the tower just to make sure. Within 2 minutes, splat. This time I left the LAN enabled at the tower and disabled the WLAN interface at the office. All better in seconds. Administratively shutting down interface gig0/3.13 at the office seems to be enough to heal OLSR at the tower. If the tower LAN can see the cisco, we drop routes. But the other ubiquity links connect back to the same cisco at the office. I think we will probably replace the switch at the tower tomorrow to see if it has problems we haven't tickled before. I'm stumped. Does anyone else have any ideas? -- Scott LambertKC5MLE Unix SysAdmin lamb...@lambertfam.org 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
Re: [WISPA] Wierd StarOS/OLSR - Ubiquity RocketM5 bridge - Cisco issue
I can't comment on the OP, but I can tell you that we are. OSPF talks, but never goes Full and exchanges routes. Latest FW on both ends. Like I said, same exact config as the other links which work perfect. On Thu, Jun 24, 2010 at 7:20 AM, Faisal Imtiaz fai...@snappydsl.net wrote: Make sure you are running the most recent version of 5.2 firmware.also you need to be running then in AP-WDS and CPE-WDS mode. Faisal On Jun 24, 2010, at 9:08 AM, Jayson Baker jay...@spectrasurf.com wrote: I didn't quite follow all of that, it must be too early. But I can tell you we have 4 of the PtP UBNT links using their M-series. 3 of those OSPF fine. The other won't OSPF for the life of me. All same config and firmware on all units. On Thu, Jun 24, 2010 at 4:38 AM, Scott Lambert lamb...@lambertfam.org wrote: We have been putting up some Ubiquity RocketM5 point-to-point bridge links, running airos 5.2, lately to replace some overloaded StarOS backhauls. Where these links have gone in, we static route the traffic across them. They happen to be on the OSPF/OLSR divider boundry. I would like to find a good way to redistribute between the routing protocols, but that's for another day. When I get time, I'll probably just convert the 20 odd OLSR towers to OSPF. These are our first experience with Ubiquity. The first two were no muss, no fuss. The third link went up nicely. It's configured the same as the other two links. About an hour after we plugged the local end at our office into the main switch, rather than a laptop, we started loosing routes to sites which pass through the tower at the far end of the link. All hosts on the tower LAN can see each other. We can reach all of them from anywhere else on our network. It is just routes for hosts connected wirelessly to that tower which are no longer known to the staros box which has the existing backhaul to our office. We rebooted everything at the remote tower. The links came up. The routes were good. Approximately an hour later, the same routes fell out. So, we decided it must be due to some sort of wierd multicast OLSR issue when these towers were suddenly able to see each other across the bridges. I unplugged the ethernet at the office and waited until tonight to try again. The routes straightened themselves out as soon as I unplugged the office end. Wild. This afternoon, I setup a seperate VLAN on the switch for this link. Before I left the office I plugged it in about, 8:00pm. I didn't have any other devices configured on that VLAN. There were no problems for several hours until I configured the new VLAN on the Cisco that was sometime between 1:01 and 1:10am. The RANCID run at 1:01 didn't see any changes but the run at 2:01 found them. At 1:10am Nagios noticed that it couldn't reach the equipment through those same routes. + interface GigabitEthernet0/3.13 + description Wireless VPN 3 + encapsulation dot1Q 13 + ip address 10.127.3.1 255.255.255.0 + no cdp enable + ! That's the subnet for the RocketM5s. The StarOS gear on the tower uses a public /29 subnet. I tried various things with reboots and restarts of OLSR on the staros gear at the tower. The routes came back for four or five minutes then went away again. No good. So, at about 2:10am, I logged into the RocketM5 at the tower and disabled it's ethernet interface. Within a few seconds, my pings to equipment through the lost routes began succeeding. It's now 3:25, and all's well. I am puzzled. We really need the additional bandwidth the ubiquity link can give us on this link. At 3:26 I enabled the LAN at the tower just to make sure. Within 2 minutes, splat. This time I left the LAN enabled at the tower and disabled the WLAN interface at the office. All better in seconds. Administratively shutting down interface gig0/3.13 at the office seems to be enough to heal OLSR at the tower. If the tower LAN can see the cisco, we drop routes. But the other ubiquity links connect back to the same cisco at the office. I think we will probably replace the switch at the tower tomorrow to see if it has problems we haven't tickled before. I'm stumped. Does anyone else have any ideas? -- Scott LambertKC5MLE Unix SysAdmin lamb...@lambertfam.org 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!
Re: [WISPA] Maximum sector power?
We had a discussion about this on the ubnt board. I have a pair of nanobridge M units. No difference was shown with an increase or decrease in power. I did notice at a certain point that after a day the units would completely stop transmitting. A reboot would fix it. Sent from my iPhone On Jun 24, 2010, at 8:16 AM, Faisal Imtiaz fai...@snappydsl.net wrote: FYI. Please make sure that you are running the most recent version 5.2 on the M series... Older firmware had known issues in setting up the output power. Faisal On Jun 24, 2010, at 10:06 AM, Stuart Pierce spie...@avolve.net wrote: I see negligible difference in signal strength anyway between 20 and 27. -- Original Message -- From: Francois Menard fmen...@xittel.net Reply-To: WISPA General List wireless@wispa.org Date: Thu, 24 Jun 2010 09:03:59 -0400 Or you can be legit in Canada, and go for 3.65 GHz and get up to 57 dBM legally in rural areas ;) Courtesy of the guy that changed the rules for 3.65 in Canada and is looking for the US to do the same... F. On 2010-06-23, at 5:41 PM, Fred R. Goldstein wrote: I'm just a little confused about some of these nice-looking access points. The UBNT Rocket M5, for instance, can put out +27 dBm. It plugs *right into* a nice 19dB sector antenna. Okay, the smaller, 120 dB sector is only 16 dB. Now math is not really my thing but I get a total ERP there of +43 to 46 dBm. FCC Rule 15.247 states that the maximum transmitted power output for digitally-modulated intentional radiators in the 5725-5850 MHz band (ISM) is 1 watt, and the maximum antenna gain is 6 dBi. Each additional dB of antanna gain means one less dB of power. So the maximum ERP is 4 watts (+36). Point-to-point is an exception in that specific band; it is allowed unlimited antenna gain. But point-to-multipoint systems, omnidirectional applications, and multiple co-located intentional radiators transmitting the same information are under the cap. So am I correct in assuming that everybody who uses the Rocket M5, or any other similar PtMP system for subscriber access, turns the transmitter power REAL low (~+20 + feedline loss), in order to keep the ERP below +36? Or are we assuming that since you're technically only transmitting and receiving to one end user at a time, it's really PtP? SkyPilot's legal hack, of course, is to have eight 45 degree sector antennas and only use one at a time, so it is legally PTP even with +42 EiRP. And with advanced 11N 4x4 beamforming antennas, something like that will become relatively easy. But we're not quite there yet. Thoughts? -- Fred Goldsteink1io fgoldstein at ionary.com ionary Consulting http://www.ionary.com/ +1 617 795 2701 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/ Sent via the WebMail system at avolve.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/ 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] Maximum sector power?
Man, that's ugly. I've never tested the spread of the older nanos, the new M series look as if they stay where you put them though. But that's a mess... Bob- -Original Message- From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On Behalf Of Jeromie Reeves Sent: Thursday, June 24, 2010 12:56 AM To: WISPA General List Subject: Re: [WISPA] Maximum sector power? Do not forget OOB and the likes. I have been using AirView for a while to check on my sites and some were unacceptable to me (5mhz but still hitting 10 or 20mhz at -85) so I replaced the cards (all MT sites). I am unsure if the cards are bad, going bad, or just how they were working from day one. Swapped them, and they look much better. I have been hunting down interference (most of it not self, only 2 links were over lapping and that due to the spread on the cards). I noticed that some sites had a higher then expected noise floor. I tracked it down to pretty much all of my NS5's (non M's). There is a pretty high bleed from a number of them. The linked airview screen shot shows a site with nothing but a nano5 in AP WDS mode with no clients connected. It is set for 5mhz and ch 164. The step to -...@5.810 is present with in 30 seconds of powering the nano. The next step down, to about -...@5.793 a bit after that (60~90sec). This was taken with a rocket and 120* 16db sector about 10ft in front and 10ft below the nano. The nano is running stock firmware and will be replaced with a nano5m. http://img718.imageshack.us/img718/8832/snapshot3v.png On Wed, Jun 23, 2010 at 9:12 PM, Robert West robert.w...@just-micro.com wrote: Stick with the rules, dude. You'll still get customers and you'll still make money. One FCC visit can ruin your day, Bob- -Original Message- From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On Behalf Of Fred R. Goldstein Sent: Wednesday, June 23, 2010 5:41 PM To: WISPA General List Subject: [WISPA] Maximum sector power? I'm just a little confused about some of these nice-looking access points. The UBNT Rocket M5, for instance, can put out +27 dBm. It plugs *right into* a nice 19dB sector antenna. Okay, the smaller, 120 dB sector is only 16 dB. Now math is not really my thing but I get a total ERP there of +43 to 46 dBm. FCC Rule 15.247 states that the maximum transmitted power output for digitally-modulated intentional radiators in the 5725-5850 MHz band (ISM) is 1 watt, and the maximum antenna gain is 6 dBi. Each additional dB of antanna gain means one less dB of power. So the maximum ERP is 4 watts (+36). Point-to-point is an exception in that specific band; it is allowed unlimited antenna gain. But point-to-multipoint systems, omnidirectional applications, and multiple co-located intentional radiators transmitting the same information are under the cap. So am I correct in assuming that everybody who uses the Rocket M5, or any other similar PtMP system for subscriber access, turns the transmitter power REAL low (~+20 + feedline loss), in order to keep the ERP below +36? Or are we assuming that since you're technically only transmitting and receiving to one end user at a time, it's really PtP? SkyPilot's legal hack, of course, is to have eight 45 degree sector antennas and only use one at a time, so it is legally PTP even with +42 EiRP. And with advanced 11N 4x4 beamforming antennas, something like that will become relatively easy. But we're not quite there yet. Thoughts? -- Fred Goldstein k1io fgoldstein at ionary.com ionary Consulting http://www.ionary.com/ +1 617 795 2701 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/
Re: [WISPA] Maximum sector power?
At 6/24/2010 09:32 AM, Bob West wrote: Man, that's ugly. I've never tested the spread of the older nanos, the new M series look as if they stay where you put them though. But that's a mess... Sure is. I smell hardware. Looking at the plot over time, it reminded me of a well-known phenomenon from the vacuum tube era, parasitic oscillation. Drifting crappy waveforms, not constant power. Isn't that why the tetrode was invented? I have vague memories of using gimmick capacitors (two pieces of teflon-insulated wire, twisted together tighter or looser to adjust) to neutralize VHF power amplifiers, back around 40 years ago. I've never taken apart a Ubiquiti or MikroTik board but I'd guess that they are using a reasonably high-gain final output transistor with some microstrip PC-board tuned circuits. A little out of spec and you can find enough feedback to make it oscillate. Maybe too high a VSWR? Or just a marginal design? Positive feedback to the parasitic itself caused by heat, making it get worse as it warms up? Just an OT guessing, of course. Bob- -Original Message- From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On Behalf Of Jeromie Reeves Sent: Thursday, June 24, 2010 12:56 AM To: WISPA General List Subject: Re: [WISPA] Maximum sector power? Do not forget OOB and the likes. I have been using AirView for a while to check on my sites and some were unacceptable to me (5mhz but still hitting 10 or 20mhz at -85) so I replaced the cards (all MT sites). I am unsure if the cards are bad, going bad, or just how they were working from day one. Swapped them, and they look much better. I have been hunting down interference (most of it not self, only 2 links were over lapping and that due to the spread on the cards). I noticed that some sites had a higher then expected noise floor. I tracked it down to pretty much all of my NS5's (non M's). There is a pretty high bleed from a number of them. The linked airview screen shot shows a site with nothing but a nano5 in AP WDS mode with no clients connected. It is set for 5mhz and ch 164. The step to -...@5.810 is present with in 30 seconds of powering the nano. The next step down, to about -...@5.793 a bit after that (60~90sec). This was taken with a rocket and 120* 16db sector about 10ft in front and 10ft below the nano. The nano is running stock firmware and will be replaced with a nano5m. http://img718.imageshack.us/img718/8832/snapshot3v.png -- Fred Goldsteink1io fgoldstein at ionary.com ionary Consulting http://www.ionary.com/ +1 617 795 2701 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] Maximum sector power?
I look at power compared to a car. You get better performance at a certain RPM on a car. This is almost never near the redline. Once you reach the limit you are wasting power. Radio cards are the same way. If you drive them at 100% they can not be as efficient as on a lower power setting. Justin -- Justin Wilson j...@mtin.net http://www.mtin.net/blog Wisp Consulting Tower Climbing Network Support From: Ryan Ghering rgher...@gmail.com Reply-To: WISPA General List wireless@wispa.org Date: Wed, 23 Jun 2010 22:53:23 -0600 To: WISPA General List wireless@wispa.org Subject: Re: [WISPA] Maximum sector power? We are running RocketM2's and RocketM5's and we have set policy's on the 120 sectors to limit the power on the radios to 17db they seem to act better then setting them to 20. Oddly enough much stronger signal's at 17 than at 20.. We have one site where we have the radios set to 13 and they work beautifully. Ryan On Wed, Jun 23, 2010 at 10:43 PM, Rubens Kuhl rube...@gmail.com wrote: The PtP/PtMP distinction does create interesting ambiguity. But then My favorite ambiguity is whether the PtP/PtMP distinction applies to the full-duplex system or per traffic direction... one reading would say that an uplink(Customer - WISP) that is made using directive antennas can follow PtP instead of PtMP rules, which would apply only to the downlink (WISP - Customer) . Rubens 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/ -- Ryan Ghering Network Operations - Plains.Net Office: 970-848-0475 - Cell: 970-630-1879 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] Maximum sector power?
I am not driving them past the default power, and often at lower then max modulations. The replaced cards are working closer to expected (still some bleed over but well under what the others were doing). The nano still spews like a collage student after sumer break. I am going to drop its modulation and power each in steps and see if it cleans up any. It also looks like only the places where I have 2 5ghz units are acting that dirty. I wonder if the other antennas are not picking up the near field? I will separate the units instead of just un plugging one, and see if it cleans up. On Thu, Jun 24, 2010 at 7:43 AM, Justin Wilson li...@mtin.net wrote: I look at power compared to a car. You get better performance at a certain RPM on a car. This is almost never near the redline. Once you reach the limit you are wasting power. Radio cards are the same way. If you drive them at 100% they can not be as efficient as on a lower power setting. Justin -- Justin Wilson j...@mtin.net http://www.mtin.net/blog Wisp Consulting Tower Climbing Network Support From: Ryan Ghering rgher...@gmail.com Reply-To: WISPA General List wireless@wispa.org Date: Wed, 23 Jun 2010 22:53:23 -0600 To: WISPA General List wireless@wispa.org Subject: Re: [WISPA] Maximum sector power? We are running RocketM2's and RocketM5's and we have set policy's on the 120 sectors to limit the power on the radios to 17db they seem to act better then setting them to 20. Oddly enough much stronger signal's at 17 than at 20.. We have one site where we have the radios set to 13 and they work beautifully. Ryan On Wed, Jun 23, 2010 at 10:43 PM, Rubens Kuhl rube...@gmail.com wrote: The PtP/PtMP distinction does create interesting ambiguity. But then My favorite ambiguity is whether the PtP/PtMP distinction applies to the full-duplex system or per traffic direction... one reading would say that an uplink(Customer - WISP) that is made using directive antennas can follow PtP instead of PtMP rules, which would apply only to the downlink (WISP - Customer) . Rubens 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/ -- Ryan Ghering Network Operations - Plains.Net Office: 970-848-0475 - Cell: 970-630-1879 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] St. Louis Regional Meeting Change of Venue
To everyone, I have successfully negotiated a lower rate of $79/room at the Renaissance https://www.marriott.com/hotels/travel/stlsa-renaissance-st-louis-airport-h otel/ Hotel near the St. Louis Airport. This rate will include free parking (normally $10/night, free Internet in rooms (Ethernet Jacks) and free Airport Shuttle service. The Exhibition Hall and Meeting Room space is tremendous and is approximately 6x the size we had at the Holiday Inn. I am going back to the hotel tonight and will sign the contract in the morning. They will be giving us a registration page and discount code as their normal room rates are $149. I will update everyone as soon as I have the discount code to register. I appreciate everyone's patience as this has taken almost 4 days to complete. The Holiday Inn would prefer that you call in to cancel your reservations ASAP, so they can release the rooms to their staff to fill with new reservations. They promised to be very cooperative. Please make sure you ask for a cancellation confirmation number just in case. The reservation/cancellation number is 1.314.427.4700 This meeting is going to be a great time, value and educational seminar that I wish all of our members could attend. I look forward to seeing old friends and meeting new ones. We are also able to open up the exhibition hall for new vendor booths and tabletop reservations. Contact me if you are interested. My time to respond is difficult right now as I am in a non-verizon area. I will be returning to St. Louis tonight and then leaving in the morning for my trip back to Indiana. If you have questions, it is probably better to give me a call in the meantime. Thanks, Rick Harnish President WISPA 260-307-4000 cell 866-317-2851 WISPA Office Skype: rick.harnish. rharn...@wispa.org 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] St. Louis Regional Meeting Change of Venue
Great work on that Rick! Regards, Jeff Jeff Broadwick ImageStream 800-813-5123 x106 (US/Can) +1 574-935-8484 x106 (Int'l) -Original Message- From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On Behalf Of Rick Harnish Sent: Thursday, June 24, 2010 4:10 PM To: memb...@wispa.org; 'WISPA General List' Subject: [WISPA] St. Louis Regional Meeting Change of Venue To everyone, I have successfully negotiated a lower rate of $79/room at the Renaissance https://www.marriott.com/hotels/travel/stlsa-renaissance-st-louis-airport-h otel/ Hotel near the St. Louis Airport. This rate will include free parking (normally $10/night, free Internet in rooms (Ethernet Jacks) and free Airport Shuttle service. The Exhibition Hall and Meeting Room space is tremendous and is approximately 6x the size we had at the Holiday Inn. I am going back to the hotel tonight and will sign the contract in the morning. They will be giving us a registration page and discount code as their normal room rates are $149. I will update everyone as soon as I have the discount code to register. I appreciate everyone's patience as this has taken almost 4 days to complete. The Holiday Inn would prefer that you call in to cancel your reservations ASAP, so they can release the rooms to their staff to fill with new reservations. They promised to be very cooperative. Please make sure you ask for a cancellation confirmation number just in case. The reservation/cancellation number is 1.314.427.4700 This meeting is going to be a great time, value and educational seminar that I wish all of our members could attend. I look forward to seeing old friends and meeting new ones. We are also able to open up the exhibition hall for new vendor booths and tabletop reservations. Contact me if you are interested. My time to respond is difficult right now as I am in a non-verizon area. I will be returning to St. Louis tonight and then leaving in the morning for my trip back to Indiana. If you have questions, it is probably better to give me a call in the meantime. Thanks, Rick Harnish President WISPA 260-307-4000 cell 866-317-2851 WISPA Office Skype: rick.harnish. rharn...@wispa.org 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] St. Louis Regional Meeting Change of Venue
Great job, Rick. Forbes On 6/24/2010 1:09 PM, Rick Harnish wrote: To everyone, I have successfully negotiated a lower rate of $79/room at the Renaissance https://www.marriott.com/hotels/travel/stlsa-renaissance-st-louis-airport-h otel/ Hotel near the St. Louis Airport. This rate will include free parking (normally $10/night, free Internet in rooms (Ethernet Jacks) and free Airport Shuttle service. The Exhibition Hall and Meeting Room space is tremendous and is approximately 6x the size we had at the Holiday Inn. I am going back to the hotel tonight and will sign the contract in the morning. They will be giving us a registration page and discount code as their normal room rates are $149. I will update everyone as soon as I have the discount code to register. I appreciate everyone's patience as this has taken almost 4 days to complete. The Holiday Inn would prefer that you call in to cancel your reservations ASAP, so they can release the rooms to their staff to fill with new reservations. They promised to be very cooperative. Please make sure you ask for a cancellation confirmation number just in case. The reservation/cancellation number is 1.314.427.4700 This meeting is going to be a great time, value and educational seminar that I wish all of our members could attend. I look forward to seeing old friends and meeting new ones. We are also able to open up the exhibition hall for new vendor booths and tabletop reservations. Contact me if you are interested. My time to respond is difficult right now as I am in a non-verizon area. I will be returning to St. Louis tonight and then leaving in the morning for my trip back to Indiana. If you have questions, it is probably better to give me a call in the meantime. Thanks, Rick Harnish President WISPA 260-307-4000 cell 866-317-2851 WISPA Office Skype: rick.harnish. rharn...@wispa.org 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] Wierd StarOS/OLSR - Ubiquity RocketM5 bridge - Cisco issue
Just curious - what if you switch the radio roles around (make the AP, the CPE and vice-versa)? I've had that fix some strange issues like that. -RickG On Thu, Jun 24, 2010 at 9:20 AM, Jayson Baker jay...@spectrasurf.com wrote: I can't comment on the OP, but I can tell you that we are. OSPF talks, but never goes Full and exchanges routes. Latest FW on both ends. Like I said, same exact config as the other links which work perfect. On Thu, Jun 24, 2010 at 7:20 AM, Faisal Imtiaz fai...@snappydsl.net wrote: Make sure you are running the most recent version of 5.2 firmware.also you need to be running then in AP-WDS and CPE-WDS mode. Faisal On Jun 24, 2010, at 9:08 AM, Jayson Baker jay...@spectrasurf.com wrote: I didn't quite follow all of that, it must be too early. But I can tell you we have 4 of the PtP UBNT links using their M-series. 3 of those OSPF fine. The other won't OSPF for the life of me. All same config and firmware on all units. On Thu, Jun 24, 2010 at 4:38 AM, Scott Lambert lamb...@lambertfam.org wrote: We have been putting up some Ubiquity RocketM5 point-to-point bridge links, running airos 5.2, lately to replace some overloaded StarOS backhauls. Where these links have gone in, we static route the traffic across them. They happen to be on the OSPF/OLSR divider boundry. I would like to find a good way to redistribute between the routing protocols, but that's for another day. When I get time, I'll probably just convert the 20 odd OLSR towers to OSPF. These are our first experience with Ubiquity. The first two were no muss, no fuss. The third link went up nicely. It's configured the same as the other two links. About an hour after we plugged the local end at our office into the main switch, rather than a laptop, we started loosing routes to sites which pass through the tower at the far end of the link. All hosts on the tower LAN can see each other. We can reach all of them from anywhere else on our network. It is just routes for hosts connected wirelessly to that tower which are no longer known to the staros box which has the existing backhaul to our office. We rebooted everything at the remote tower. The links came up. The routes were good. Approximately an hour later, the same routes fell out. So, we decided it must be due to some sort of wierd multicast OLSR issue when these towers were suddenly able to see each other across the bridges. I unplugged the ethernet at the office and waited until tonight to try again. The routes straightened themselves out as soon as I unplugged the office end. Wild. This afternoon, I setup a seperate VLAN on the switch for this link. Before I left the office I plugged it in about, 8:00pm. I didn't have any other devices configured on that VLAN. There were no problems for several hours until I configured the new VLAN on the Cisco that was sometime between 1:01 and 1:10am. The RANCID run at 1:01 didn't see any changes but the run at 2:01 found them. At 1:10am Nagios noticed that it couldn't reach the equipment through those same routes. + interface GigabitEthernet0/3.13 + description Wireless VPN 3 + encapsulation dot1Q 13 + ip address 10.127.3.1 255.255.255.0 + no cdp enable + ! That's the subnet for the RocketM5s. The StarOS gear on the tower uses a public /29 subnet. I tried various things with reboots and restarts of OLSR on the staros gear at the tower. The routes came back for four or five minutes then went away again. No good. So, at about 2:10am, I logged into the RocketM5 at the tower and disabled it's ethernet interface. Within a few seconds, my pings to equipment through the lost routes began succeeding. It's now 3:25, and all's well. I am puzzled. We really need the additional bandwidth the ubiquity link can give us on this link. At 3:26 I enabled the LAN at the tower just to make sure. Within 2 minutes, splat. This time I left the LAN enabled at the tower and disabled the WLAN interface at the office. All better in seconds. Administratively shutting down interface gig0/3.13 at the office seems to be enough to heal OLSR at the tower. If the tower LAN can see the cisco, we drop routes. But the other ubiquity links connect back to the same cisco at the office. I think we will probably replace the switch at the tower tomorrow to see if it has problems we haven't tickled before. I'm stumped. Does anyone else have any ideas? -- Scott Lambert KC5MLE Unix SysAdmin lamb...@lambertfam.org WISPA Wants You! Join today! http://signup.wispa.org/ WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe:
Re: [WISPA] Maximum sector power?
Does the FCC take its cues from the IRS? :) On Thu, Jun 24, 2010 at 12:43 AM, Rubens Kuhl rube...@gmail.com wrote: The PtP/PtMP distinction does create interesting ambiguity. But then My favorite ambiguity is whether the PtP/PtMP distinction applies to the full-duplex system or per traffic direction... one reading would say that an uplink(Customer - WISP) that is made using directive antennas can follow PtP instead of PtMP rules, which would apply only to the downlink (WISP - Customer) . Rubens 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] Maximum sector power?
Not to argue your point as I agree with you but how do you know your running it at 100%? Just cause it says so doesnt mean it is. (It being the radio). -RickG On Thu, Jun 24, 2010 at 10:43 AM, Justin Wilson li...@mtin.net wrote: I look at power compared to a car. You get better performance at a certain RPM on a car. This is almost never near the redline. Once you reach the limit you are wasting power. Radio cards are the same way. If you drive them at 100% they can not be as efficient as on a lower power setting. Justin -- Justin Wilson j...@mtin.net http://www.mtin.net/blog Wisp Consulting Tower Climbing Network Support From: Ryan Ghering rgher...@gmail.com Reply-To: WISPA General List wireless@wispa.org Date: Wed, 23 Jun 2010 22:53:23 -0600 To: WISPA General List wireless@wispa.org Subject: Re: [WISPA] Maximum sector power? We are running RocketM2's and RocketM5's and we have set policy's on the 120 sectors to limit the power on the radios to 17db they seem to act better then setting them to 20. Oddly enough much stronger signal's at 17 than at 20.. We have one site where we have the radios set to 13 and they work beautifully. Ryan On Wed, Jun 23, 2010 at 10:43 PM, Rubens Kuhl rube...@gmail.com wrote: The PtP/PtMP distinction does create interesting ambiguity. But then My favorite ambiguity is whether the PtP/PtMP distinction applies to the full-duplex system or per traffic direction... one reading would say that an uplink(Customer - WISP) that is made using directive antennas can follow PtP instead of PtMP rules, which would apply only to the downlink (WISP - Customer) . Rubens 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/ -- Ryan Ghering Network Operations - Plains.Net Office: 970-848-0475 - Cell: 970-630-1879 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] Wierd StarOS/OLSR - Ubiquity RocketM5 bridge - Cisco issue
On Thu, Jun 24, 2010 at 07:20:23AM -0600, Jayson Baker wrote: On Thu, Jun 24, 2010 at 7:20 AM, Faisal Imtiaz wrote: On Jun 24, 2010, at 9:08 AM, Jayson Baker wrote: On Thu, Jun 24, 2010 at 4:38 AM, Scott Lambert wrote: We have been putting up some Ubiquity RocketM5 point-to-point bridge links, running airos 5.2, lately to replace some overloaded StarOS backhauls. Where these links have gone in, we static route the traffic across them. These are our first experience with Ubiquity. The first two were no muss, no fuss. The third link went up nicely. It's configured the same as the other two links. About an hour after we plugged the local end at our office into the main switch, rather than a laptop, we started loosing routes to sites which pass through the tower at the far end of the link. All hosts on the tower LAN can see each other. We can reach all of them from anywhere else on our network. It is just routes for hosts connected wirelessly to that tower which are no longer known to the staros box which has the existing backhaul to our office. ** SNIPPED ** ** OLSR between StarOS boxes at the remote tower ** ** dropping routes, but not OLSR adjacencies ** Administratively shutting down interface gig0/3.13 at the office seems to be enough to heal OLSR at the tower. If the tower LAN can see the cisco, we drop routes. But the other ubiquity links connect back to the same cisco at the office. I think we will probably replace the switch at the tower tomorrow to see if it has problems we haven't tickled before. I'm stumped. Does anyone else have any ideas? I didn't quite follow all of that, it must be too early. But I can tell you we have 4 of the PtP UBNT links using their M-series. 3 of those OSPF fine. The other won't OSPF for the life of me. All same config and firmware on all units. Make sure you are running the most recent version of 5.2 firmware.also you need to be running then in AP-WDS and CPE-WDS mode. I can't comment on the OP, but I can tell you that we are. OSPF talks, but never goes Full and exchanges routes. Latest FW on both ends. Like I said, same exact config as the other links which work perfect. I'm still waiting for a chance to test again during off-peak hours. I may have included too much information, and too little information, and created confusion. The e-mail was helping me document and track my trouble shooting process. I often solve my own problem while writing up e-mail to mailing lists. Usually, because I've skipped some simple trouble shooting step without realizing it until I proof read the message before sending it. The summary is : When the Ubiquity bridge is up, passing traffic or not, the OLSR at the tower site begins having issues between StarOS routers directly connected to the tower switch. The OLSR which is falling apart, does not need to cross the Ubiquity link in order to function. In fact, there is nothing at the near end of the link which could do anything with the OLSR packets. OLSR falls apart BEFORE I get to the point at which I would attempt to actually utilize the Ubiquity link. The only traffic I am attempting to pass at the point of failure is from the office to the RocketM5 at the tower. Here are the series of changes to the network which lead to issues: Connect RocketM5 to tower switch: OLSR at tower OK Create association AP-WDS at office to STA-WDS at the tower: OLSR at tower OK Connect RocketM5 AP at office to office switch in it's own VLAN: OLSR at tower OK Configure Cisco at office to join VLAN: OLSR at tower falls apart Configure Cisco at office to exit VLAN: OLSR at tower OK Cisco join VLAN to OLSR time to failure approximately 90 - 105 seconds. Cisco exit VLAN to OLSR time to heal approximately 10 seconds. The Cisco is not configured to run any routing protocols over this VLAN. If anyone thinks it would help, I could draw up an ascii diagram. -- Scott LambertKC5MLE Unix SysAdmin lamb...@lambertfam.org 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] Wierd StarOS/OLSR - Ubiquity RocketM5 bridge - Cisco issue
Sounds like Cisco / Vlan is giving you trouble... Two suggestions... check if there is a loop getting created somewhere.. and 2nd suggestions... turn CDP off on the Cisco ... Faisal Imtiaz Snappy Internet Telecom 7266 SW 48 Street Miami, Fl 33155 Tel: 305 663 5518 x 232 Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net On 6/24/2010 8:08 PM, Scott Lambert wrote: On Thu, Jun 24, 2010 at 07:20:23AM -0600, Jayson Baker wrote: On Thu, Jun 24, 2010 at 7:20 AM, Faisal Imtiaz wrote: On Jun 24, 2010, at 9:08 AM, Jayson Baker wrote: On Thu, Jun 24, 2010 at 4:38 AM, Scott Lambert wrote: We have been putting up some Ubiquity RocketM5 point-to-point bridge links, running airos 5.2, lately to replace some overloaded StarOS backhauls. Where these links have gone in, we static route the traffic across them. These are our first experience with Ubiquity. The first two were no muss, no fuss. The third link went up nicely. It's configured the same as the other two links. About an hour after we plugged the local end at our office into the main switch, rather than a laptop, we started loosing routes to sites which pass through the tower at the far end of the link. All hosts on the tower LAN can see each other. We can reach all of them from anywhere else on our network. It is just routes for hosts connected wirelessly to that tower which are no longer known to the staros box which has the existing backhaul to our office. ** SNIPPED ** ** OLSR between StarOS boxes at the remote tower ** ** dropping routes, but not OLSR adjacencies ** Administratively shutting down interface gig0/3.13 at the office seems to be enough to heal OLSR at the tower. If the tower LAN can see the cisco, we drop routes. But the other ubiquity links connect back to the same cisco at the office. I think we will probably replace the switch at the tower tomorrow to see if it has problems we haven't tickled before. I'm stumped. Does anyone else have any ideas? I didn't quite follow all of that, it must be too early. But I can tell you we have 4 of the PtP UBNT links using their M-series. 3 of those OSPF fine. The other won't OSPF for the life of me. All same config and firmware on all units. Make sure you are running the most recent version of 5.2 firmware.also you need to be running then in AP-WDS and CPE-WDS mode. I can't comment on the OP, but I can tell you that we are. OSPF talks, but never goes Full and exchanges routes. Latest FW on both ends. Like I said, same exact config as the other links which work perfect. I'm still waiting for a chance to test again during off-peak hours. I may have included too much information, and too little information, and created confusion. The e-mail was helping me document and track my trouble shooting process. I often solve my own problem while writing up e-mail to mailing lists. Usually, because I've skipped some simple trouble shooting step without realizing it until I proof read the message before sending it. The summary is : When the Ubiquity bridge is up, passing traffic or not, the OLSR at the tower site begins having issues between StarOS routers directly connected to the tower switch. The OLSR which is falling apart, does not need to cross the Ubiquity link in order to function. In fact, there is nothing at the near end of the link which could do anything with the OLSR packets. OLSR falls apart BEFORE I get to the point at which I would attempt to actually utilize the Ubiquity link. The only traffic I am attempting to pass at the point of failure is from the office to the RocketM5 at the tower. Here are the series of changes to the network which lead to issues: Connect RocketM5 to tower switch: OLSR at tower OK Create association AP-WDS at office to STA-WDS at the tower: OLSR at tower OK Connect RocketM5 AP at office to office switch in it's own VLAN: OLSR at tower OK Configure Cisco at office to join VLAN: OLSR at tower falls apart Configure Cisco at office to exit VLAN: OLSR at tower OK Cisco join VLAN to OLSR time to failure approximately 90 - 105 seconds. Cisco exit VLAN to OLSR time to heal approximately 10 seconds. The Cisco is not configured to run any routing protocols over this VLAN. If anyone thinks it would help, I could draw up an ascii diagram. 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] Wierd StarOS/OLSR - Ubiquity RocketM5 bridge - Cisco issue
Turn off extra reporting on the Ubiquities. Regards Michael Baird Sounds like Cisco / Vlan is giving you trouble... Two suggestions... check if there is a loop getting created somewhere.. and 2nd suggestions... turn CDP off on the Cisco ... Faisal Imtiaz Snappy Internet Telecom 7266 SW 48 Street Miami, Fl 33155 Tel: 305 663 5518 x 232 Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net On 6/24/2010 8:08 PM, Scott Lambert wrote: On Thu, Jun 24, 2010 at 07:20:23AM -0600, Jayson Baker wrote: On Thu, Jun 24, 2010 at 7:20 AM, Faisal Imtiaz wrote: On Jun 24, 2010, at 9:08 AM, Jayson Baker wrote: On Thu, Jun 24, 2010 at 4:38 AM, Scott Lambert wrote: We have been putting up some Ubiquity RocketM5 point-to-point bridge links, running airos 5.2, lately to replace some overloaded StarOS backhauls. Where these links have gone in, we static route the traffic across them. These are our first experience with Ubiquity. The first two were no muss, no fuss. The third link went up nicely. It's configured the same as the other two links. About an hour after we plugged the local end at our office into the main switch, rather than a laptop, we started loosing routes to sites which pass through the tower at the far end of the link. All hosts on the tower LAN can see each other. We can reach all of them from anywhere else on our network. It is just routes for hosts connected wirelessly to that tower which are no longer known to the staros box which has the existing backhaul to our office. ** SNIPPED ** ** OLSR between StarOS boxes at the remote tower ** ** dropping routes, but not OLSR adjacencies ** Administratively shutting down interface gig0/3.13 at the office seems to be enough to heal OLSR at the tower. If the tower LAN can see the cisco, we drop routes. But the other ubiquity links connect back to the same cisco at the office. I think we will probably replace the switch at the tower tomorrow to see if it has problems we haven't tickled before. I'm stumped. Does anyone else have any ideas? I didn't quite follow all of that, it must be too early. But I can tell you we have 4 of the PtP UBNT links using their M-series. 3 of those OSPF fine. The other won't OSPF for the life of me. All same config and firmware on all units. Make sure you are running the most recent version of 5.2 firmware.also you need to be running then in AP-WDS and CPE-WDS mode. I can't comment on the OP, but I can tell you that we are. OSPF talks, but never goes Full and exchanges routes. Latest FW on both ends. Like I said, same exact config as the other links which work perfect. I'm still waiting for a chance to test again during off-peak hours. I may have included too much information, and too little information, and created confusion. The e-mail was helping me document and track my trouble shooting process. I often solve my own problem while writing up e-mail to mailing lists. Usually, because I've skipped some simple trouble shooting step without realizing it until I proof read the message before sending it. The summary is : When the Ubiquity bridge is up, passing traffic or not, the OLSR at the tower site begins having issues between StarOS routers directly connected to the tower switch. The OLSR which is falling apart, does not need to cross the Ubiquity link in order to function. In fact, there is nothing at the near end of the link which could do anything with the OLSR packets. OLSR falls apart BEFORE I get to the point at which I would attempt to actually utilize the Ubiquity link. The only traffic I am attempting to pass at the point of failure is from the office to the RocketM5 at the tower. Here are the series of changes to the network which lead to issues: Connect RocketM5 to tower switch: OLSR at tower OK Create association AP-WDS at office to STA-WDS at the tower: OLSR at tower OK Connect RocketM5 AP at office to office switch in it's own VLAN: OLSR at tower OK Configure Cisco at office to join VLAN: OLSR at tower falls apart Configure Cisco at office to exit VLAN: OLSR at tower OK Cisco join VLAN to OLSR time to failure approximately 90 - 105 seconds. Cisco exit VLAN to OLSR time to heal approximately 10 seconds. The Cisco is not configured to run any routing protocols over this VLAN. If anyone thinks it would help, I could draw up an ascii diagram. 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] Maximum sector power?
Yeah no way to tell unless you hook it up. I just go by if the radio is rated at 27dbm and the software is set to 27dbm then I am assuming it is 100%. Assuming is the key word. -- Justin Wilson j...@mtin.net http://www.mtin.net/blog Wisp Consulting Tower Climbing Network Support From: RickG rgunder...@gmail.com Reply-To: WISPA General List wireless@wispa.org Date: Thu, 24 Jun 2010 19:53:34 -0400 To: WISPA General List wireless@wispa.org Subject: Re: [WISPA] Maximum sector power? Not to argue your point as I agree with you but how do you know your running it at 100%? Just cause it says so doesnt mean it is. (It being the radio). -RickG On Thu, Jun 24, 2010 at 10:43 AM, Justin Wilson li...@mtin.net wrote: I look at power compared to a car. You get better performance at a certain RPM on a car. This is almost never near the redline. Once you reach the limit you are wasting power. Radio cards are the same way. If you drive them at 100% they can not be as efficient as on a lower power setting. Justin -- Justin Wilson j...@mtin.net http://www.mtin.net/blog Wisp Consulting Tower Climbing Network Support From: Ryan Ghering rgher...@gmail.com Reply-To: WISPA General List wireless@wispa.org Date: Wed, 23 Jun 2010 22:53:23 -0600 To: WISPA General List wireless@wispa.org Subject: Re: [WISPA] Maximum sector power? We are running RocketM2's and RocketM5's and we have set policy's on the 120 sectors to limit the power on the radios to 17db they seem to act better then setting them to 20. Oddly enough much stronger signal's at 17 than at 20.. We have one site where we have the radios set to 13 and they work beautifully. Ryan On Wed, Jun 23, 2010 at 10:43 PM, Rubens Kuhl rube...@gmail.com wrote: The PtP/PtMP distinction does create interesting ambiguity. But then My favorite ambiguity is whether the PtP/PtMP distinction applies to the full-duplex system or per traffic direction... one reading would say that an uplink(Customer - WISP) that is made using directive antennas can follow PtP instead of PtMP rules, which would apply only to the downlink (WISP - Customer) . Rubens 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/ -- Ryan Ghering Network Operations - Plains.Net Office: 970-848-0475 - Cell: 970-630-1879 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/
