Re: [WISPA] Sprint / Nextel to use 900mz for iDen

2006-10-28 Thread Jack Unger

Tom,

Yes, their gear (the paging stuff) not only costs more but their 
transmitters spurious emissions have to remain low or the paging company 
risks being fined by the FCC. Sure, a transmitter can malfunction once 
in a while and cause interference to the ISM band but this is not a 
common occurance. Our gear has receivers where the manufacturing cost is 
quite low. There may be $50 worth of parts in the receiver section of an 
AP. The vendors typically do not spend a lot of money on components that 
would raise the cost of their equipment and make it non-competitive such 
as adding expensive filters to reduce the overloading problems that only 
a minority of WISPs may ever experience. Similarly, the new cars that 
people buy don't come with the most expensive tires as standard 
equipment because most people would never notice a difference or be 
willing to pay more for the premium tires.


I started deploying 900 MHz bridges in 1993 and 900 MHz APs (yes, for 
WISP service) in 1995. I used Lucent Wavelan cards in those systems. 
Whenever I was located within about 1/3 of a mile from a cell site (with 
colocated 929 MHz and 930 MHz paging) I had to add an external bandpass 
filter between the antenna and the antenna connector on the Wavelan 
card. Until I did this, I could not get full throughput (which was about 
1.3 Mbps in those days) through the card. The bandpass filter would 
clear up the problem every time. Those filters weren't even that strong 
- only about 6 dB of attenuation at 900 MHz and at 930 MHz (even less - 
maybe 5 dB at 929 MHz) but it was enough to protect the Wavelan card's 
receiver from being overloaded. These bandpass filters were made by a 
3rd-party source and custom tuned by me in a calibration lab. My filter 
cost was $125 each and they were not weatherproof so I mounted them 
indoors. The inband attenuation was aboat 1 or 1.5 dB which was 
insignificant in light of the fact that the filters worked to eliminate 
the overloading and allow the AP to receive client signals up to 10 or 
12 miles away.


Regarding Trango - I have not verified the accuracy of their spectrum 
analysis tool but what you're seeing can be explained by one observation 
and one guestimation. The -20 dBm to -30 dBm signal indications above 
929 MHz are likely fairly accurate. Nearby paging transmitters could 
easily be that loud. The fact that you're seeing signals down to 924 MHz 
or so could be explained by the Trango receiver front-end (the first 
stage connected to the antenna) being overloaded by one or more nearby 
paging transmitters. When a receiver is overloaded, it generates 
spurious signals that are not really being transmitted on the 
frequency where they show up. The spurs are being generated inside the 
receiver itself as a consequence of the overloading. It's fairly easy to 
test to see if this is the case. Just insert a bandpass filter between 
the antenna and the antenna connector (assuming a connectorized AP). If 
the AP receiving distance and/or the throughput increases, you have just 
 proved that overloading was a problem. You can also re-run the 
spectrum analysis tool and see if it no longer reports signals down to 
924 MHz. It should now report that the non-WISP signals start around 929 
MHz.


I hope this explanation helps.

jack


Tom DeReggi wrote:


Jack,

That all sounds good, and it brings up a good point, that we are just as 
probable to be the culprit, not just the other guy.

Besides, their gear costs more, right :-)
However, what specific gear do you have experience with, on this issue, 
to support your comment?
I'm not sure that I am knowledgable enough on the topic, to know for 
sure which side is the flaw, how would we tell?


I use Trango 900. Trango's have a built-in specrum site survey tool, 
that also scans a bit lower and higher than the ISM edge.  My comment 
was based on the fact that, when I do the site survey, I see signals in 
the neg 20-30 range, spanning from significantly above 930 down to mid 
portion of ISM channel 4 (924 or so).
Have you verified the accuracy of the Trango tool, and how it reacts to 
this situation?


Tom DeReggi
RapidDSL  Wireless, Inc
IntAirNet- Fixed Wireless Broadband


- Original Message - From: Jack Unger [EMAIL PROTECTED]
To: WISPA General List wireless@wispa.org
Sent: Friday, October 27, 2006 1:07 PM
Subject: Re: [WISPA] Sprint / Nextel to use 900mz for iDen


Bleed over implies that the paging system is transmitting a signal 
that is too wide. This is typically NOT the case. Our rather 
inexpensive WISP AP receivers do not have adequate selectivity to 
reject strong nearby signals. In other words, it's our equipment 
problem not their equipment problem.


Also, WISP subscriber sites, unless located right under a 
paging/cellular tower aren't close enough to be overloaded by 
paging/cellular so they would not need the bandpass filter. Only our 
APs which are located near paging/cellular towers should need the 
bandpass 

Re: [WISPA] FREE OSS and Billing Software for WiSPS

2006-10-28 Thread Jason Hensley

Their site seems to be down this morning.


- Original Message - 
From: Matt Liotta [EMAIL PROTECTED]

To: WISPA General List wireless@wispa.org
Sent: Friday, October 27, 2006 8:40 PM
Subject: Re: [WISPA] FREE OSS and Billing Software for WiSPS



I like how they end their pitch...

The reason and dreams behind getting into the WiSP business in the first 
place
can finally be realized by contracting with RidgeviewTel’s WiSP Services 
division.


-Matt

Brian Rohrbacher wrote:

FREE OSS and Billing Software for WiSPS
And then there are all the paid services.

http://www.dboss-online.com/

read the pdf
prices on page 22, but I emailed them and they said the prices are 
changing. More like $250.00 a month for 0 - 250 customers (bundled 
services)


http://www.dboss-online.com/wisp_services.pdf

Pretty neat services they offer. I'm not technical enough to do it all on 
my own, this looks ok.


Give me some input here. Are all these services needed? How does the 
value look?


Brian Rohrbacher


--
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] [Fwd: Anheuser-Busch Rice Mill Jonesboro Ar.

2006-10-28 Thread Marlon Schafer (509-982-2181)

Can anyone help a stranded motorist?

Hit me offlist for contact info.

laters,
marlon




Hi Marlon,

My company is looking for broadband service at this rural address in 
arkansas..


Anheuser-Busch
Jonesboro Rice Mill
3723 CR 905
Hwy 49 North at Farville
Jonesboro, AR 72401-0749

Do you know of anything available?


The information transmitted (including attachments) is
covered by the Electronic Communications Privacy Act,
18 U.S.C. 2510-2521, is intended only for the person(s) or
entity/entities to which it is addressed and may contain
confidential and/or privileged material. Any review,
retransmission, dissemination or other use of, or taking
of any action in reliance upon, this information by persons
or entities other than the intended recipient(s) is prohibited.
If you received this in error, please contact the sender and
delete the material from any computer.



--
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/


Re: [WISPA] Sprint / Nextel to use 900mz for iDen

2006-10-28 Thread John Scrivner
Good info Jack. In a past life I was a headend tech in the cable 
television industry. and I also performed signal egress and ingress 
troubleshooting using a Hewlett Packard 8591B analyzer. I spent a few 
thousand hours on this tool and learned much about spectrum analysis at 
that time. Here is some info for some of those out there who may be new 
to spectrum analysis:


There is something that can make these paging transmitters appear to be 
bleeding over into the ISM bands when in fact they may not be. The 
setting on the analyzer is called resolution bandwidth. This setting 
takes all power within a given bandspace and averages it together as it 
sweeps across the screen. The wider this setting is the fewer bumps you 
see on the screen. The trace will smooth out as you increase this 
setting because it is averaging power within a wider space of spectrum. 
This has the added effect of making a loud carrier appear to cover a 
wider space than it actually does and can cause you to believe that a 
paging or other carrier is bleeding over into the ISM band. On the 
contrary, narrowing the resolution bandwidth will show more accurate 
representation of actual power in a given bandspace but is slower to 
scan on most analyzers and produces a very sporadic display. If you are 
looking for narrowband or adjacent channel interference into your band 
then a narrow resolution bandwidth will be required. If you are wanting 
to take a RSSI reading of your own carrier then a wider resolution 
bandwidth will be required.


Resolution bandwidth is something you should learn to use and understand 
if you want to get more from your work. It is an important part of 
spectrum analysis. If you want to see how good an analyzer is then look 
at how low the resolution bandwidth setting will allow. For our work a 
minimum resolution bandwidth of about 100kHz is probably all you will 
ever need. Also run it at its lowest resolution bandwidth and see how 
long it takes to scan across the screen. If you are comparing multiple 
analyzers make sure you always use the same span setting (difference 
between upper and lower frequency on display). A narrower span will 
display a narrow resolution bandwidth much faster. Better analyzers will 
have a wide range of resolution bandwidth settings and will show a 
sharp, clean display in any setting.


Learning to use a spectrum analyzer can seem daunting at first glance. 
Do not let this intimidate you. You can learn to use this and get 
meaningful information from it if you give it a try. You will not break 
the analyzer by experimenting with it. If the unit you are using has 
knobs and you had it set by someone previously then just take notes of 
where they are set and then experiment with the unit. The most important 
things to master are start frequency, stop frequency, span, center 
frequency, reference level, attenuation, resolution bandwidth. Anything 
else you learn is good to know but not as much as what I just outlined 
here.


If anyone here is working with an analyzer and does not know what any of 
those things mean then feel free to ask here onlist (or offlist if you 
would prefer to not tell others you do not know):-)

Scriv



Jack Unger wrote:


Tom,

Yes, their gear (the paging stuff) not only costs more but their 
transmitters spurious emissions have to remain low or the paging 
company risks being fined by the FCC. Sure, a transmitter can 
malfunction once in a while and cause interference to the ISM band but 
this is not a common occurance. Our gear has receivers where the 
manufacturing cost is quite low. There may be $50 worth of parts in 
the receiver section of an AP. The vendors typically do not spend a 
lot of money on components that would raise the cost of their 
equipment and make it non-competitive such as adding expensive filters 
to reduce the overloading problems that only a minority of WISPs may 
ever experience. Similarly, the new cars that people buy don't come 
with the most expensive tires as standard equipment because most 
people would never notice a difference or be willing to pay more for 
the premium tires.


I started deploying 900 MHz bridges in 1993 and 900 MHz APs (yes, for 
WISP service) in 1995. I used Lucent Wavelan cards in those systems. 
Whenever I was located within about 1/3 of a mile from a cell site 
(with colocated 929 MHz and 930 MHz paging) I had to add an external 
bandpass filter between the antenna and the antenna connector on the 
Wavelan card. Until I did this, I could not get full throughput (which 
was about 1.3 Mbps in those days) through the card. The bandpass 
filter would clear up the problem every time. Those filters weren't 
even that strong - only about 6 dB of attenuation at 900 MHz and at 
930 MHz (even less - maybe 5 dB at 929 MHz) but it was enough to 
protect the Wavelan card's receiver from being overloaded. These 
bandpass filters were made by a 3rd-party source and custom tuned by 
me in a calibration 

RE: [WISPA] The Gremlin, redux

2006-10-28 Thread Mac Dearman
David,

I tend to believe you will find your answer on your network -vs- big bad
leak somewhere and the only real suggestion I can offer you would be to do
what we do here when we start having weird issues - - and that is to be
ready to start unplugging Back Hauls (one at a time) out of their
switch..Etc when the trouble starts. Have a ping running to watch for the
latency to disappear when you unplug the offending Back Haul. Once you
narrow it down to the right leg of the network you can reboot one AP at a
time until you find which AP it is coming from by running an extended ping
on that leg of the network

 Don't pull a big dummy like we did here for weeks!! Unplug the servers
one at a time too!!! That is where we found one of the servers we host was
our culprit. There traffic was of such that it was flooding our switches - -
(dirty suckers) :-)

GL -  keep us informed as to what you find

Mac Dearman


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of David E. Smith
Sent: Friday, October 27, 2006 4:10 PM
To: WISPA General List
Subject: Re: [WISPA] The Gremlin, redux

On Fri, October 27, 2006 3:11 pm, Eric Merkel wrote:

 1) Turning off inter-BSS Relay

Already done, on most towers. (We do have a couple of towers where one
business, with two locations, wants to do VPN-type stuff between 'em.)

 2) We block all the typical MS ports(135-139) which broadcast all the
 time via iptables

Done. We block 135-139, 445, and a couple other ports, both TCP and UDP.

 3) Packet shape all connections via CBQ on the AP itself to limit how
 much bandwidth any one customer can consume

Mostly done. (For historical reasons, some of our customers are still part
of a giant bridged network, and their traffic is shaped in our office not
at the AP, but those customers are relatively few and growing fewer by the
week.)

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] The Gremlin, redux

2006-10-28 Thread David E. Smith

Mac Dearman wrote:


I tend to believe you will find your answer on your network -vs- big bad
leak somewhere and the only real suggestion I can offer you would be to do
what we do here when we start having weird issues


[ snip: Mac's good advice on how to track down broadcast storms and 
other network-related problems ]


If it were a backhaul problem, though, wouldn't I see high latency on my 
backhaul links? I haven't, to date.


Here's one of the (many) experiments I've done in the past (this one was 
yesterday, actually): I logged into an affected AP, while the problem 
was happening, and firewalled off THE WHOLE INTERNET except for one IP 
address, that being the PC in my office I was using to log into that AP. 
Then, from that AP, I pinged a CPE associated with it. The problem 
persisted, high packet loss and 5000-1 millisecond latency.


I quickly undid my changes on that AP, then did exactly the same thing 
on another AP, about twenty miles away, with a different radio card, on 
a different channel, connected to me through a different backhaul link, 
and saw exactly the same performance (high packet loss, obscene latency, 
et cetera).


Meanwhile, pings to and through our backhaul links, to the APs 
themselves, various managed switches at tower locations, and so on, 
never skipped a beat. (Heck, most of 'em improved a bit, since there 
wasn't as much pesky customer traffic going through them. :)


For that matter, why do I have three towers with a mixture of 2.4GHz and 
other APs (two with a 900MHz AP, one with a 5.3GHz AP and a 5.8GHz AP) 
and the non-2.4 customers aren't affected? Keep in mind that, for 
annoying historical reasons, much of our network is still flat, 
bridged addresses flying willy-nilly across four counties. If it were a 
network storm, I'd expect it to hit all our towers, on all channels, and 
not conveniently skip over the most geographically remote ones.


There's also all the nasty logistical problems of my company not having 
twenty extra hands that we can just have sitting at all our towers for 
days, or weeks, at a time, waiting for a problem that shows up 
completely randomly, hoping I can call everyone to start unplugging 
stuff before the problem magically goes away, but that's another issue 
altogether ;)


Last, remember this really is amazingly random, and usually only shows 
up for a minute or two at a time, brief enough that I only see it in our 
logs well after the fact. (Yesterday it visited us for a good twenty 
minutes, long enough for customers to really notice, and for me to have 
time to dig into it again.)


I certainly don't mean to sound dismissive of any suggestions, it's just 
that I've tried most of the obvious ones before.


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] The Gremlin, redux

2006-10-28 Thread Rich Comroe

Eric wrote:

Looking at the beacon realtime manager and tcpdump, we've never seen
an unreasonable # of broadcasts when this is happening.


On our network 200 broadcasts per second is pretty typical.  When we see it 
spike to over 1200 per second (6-fold rise), it really drives the latency 
up.  Don't be fooled by total bw metrics ... broadcasts are so short that 
crippling broadcast storms don't show any spike in total traffic (traffic is 
actually squeezed out by the broadcasts dominating the radios).  I'm 
thinking tcpdump is like the packet dump that ethereal uses.  How do you 
determine how many broadcasts per second is transiting the AP from it?  Just 
curious.  I'm not familiar with beacon realtime manager ... can it tell 
you how many broadcasts per second are on the air during your events?  When 
you say you've never seen an unreasonable # of broadcasts, how many 
broadcasts per second do you see during an event?  What we do is simply 
chart broadcasts in  out for every radio on our network on a continuous 
basis.  Just about anything will do that, so knowing broadcast levels (and 
who's causing them) is a piece of cake ... no harder than opening a web page 
and scrolling to spot the offenders.


Rich

- Original Message - 
From: Eric Merkel [EMAIL PROTECTED]

To: WISPA General List wireless@wispa.org
Sent: Friday, October 27, 2006 3:11 PM
Subject: Re: [WISPA] The Gremlin, redux



On 10/27/06, Rich Comroe [EMAIL PROTECTED] wrote:

We look at the traffic on the
tower for abuse and/or virus and don't really find anything.

Just to be clear, you've checked your AP broadcast levels during the 
events

and not found found them elevated?  We found the most crippling network
events were not coming into the network from the outside, but were 
broadcast

storms between 2 or more customers (repeated through the APs).  They act
similar to the symptoms you cited (a few minutes of extremely elevated
latency due to the short term load they place over the rf).

Rich



We try to mitigate this problem by the following:

1) Turning off inter-BSS Relay
2) We block all the typical MS ports(135-139) which broadcast all the
time via iptables
3) Packet shape all connections via CBQ on the AP itself to limit how
much bandwidth any one customer can consume

Looking at the beacon realtime manager and tcpdump, we've never seen
an unreasonable # of broadcasts when this is happening.

-Eric
--
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] The Gremlin, redux

2006-10-28 Thread Lonnie Nunweiler

Since your customers are mostly on a bridged network then a single
malicious or misbehaving customer radio can take your WHOLE network
down.  The reason your backhaul is not affected is simply because it
has more capacity than the prism AP units.

I know you guys are tired of hearing from me about routing versus
bridging (You even gave me my own clause) but your problems are
precisely what I have been describing for all of these years.

The one point you are missing in your overall design is something I
have brought up a number of times.  A properly functioning bridged
system will echo all broadcast traffic throughout the network, thus
one system can flood the entire LAN.  This leads to the biggest single
factor -- your entire network speed is a factor of your slowest AP,
since it must rebroadcast all traffic to its users.

On a routed design you will still get problems like these slowdowns,
but the very important thing to keep in mind is that the slowdown will
only take out the one sector.  Also (and this should be enough to make
you take a hard look at routing) your LAN throughput is the sum total
of all of your AP units and thus you might actually start to use your
high speed backhaul.  Your ping times will go under 2 msec per
repeater.  Our WAR boards are actually around the 1 msec area.

The other thing you have going against you is that you are using a
unit based on the Ubicom chipset.  Remember the dear old Wet11?  That
was Ubicom using a prism radio.  CB3 is simply a newer version, but
still with some issues that seem to be killing networks everywhere.

Our last version of the Atheros driver would start to show units could
not reconnect and the only way to make the system settle down was to
change channels or reboot.  What is happening is that the CB3 has
trouble when it reconnects to an AP.  Something is not quite right
with its handshake and it does not get accepted.  This causes it to
throw a hissy fit and it starts to hammer the AP with reconnection
attempts.  That massive RF directed at the AP soon causes other units
to disconnect and guess what happens if they are a CB3?  They try the
same techniques the first tried.  Suddenly you have this massive
reconnect storm and the AP is brought to its knees until you change
channels or reboot.

Your whole problem is circular and is based on poor choices of both
equipment and network design.  You chose cheap units that only do a
pseudo bridge so you designed your LAN accordingly.  You thought you
would be safe because you had a good AP, but a LAN is mostly made up
of clients, so if the clients are poor, then it follows that your LAN
is poor.

You have some sectors already routed, but they still have the trouble.
I say this is because of the trouble of the clients, which could be
at this tower or simply because your tower is visible to them.  You
are quite likely even using 200 mW prism cards which makes this factor
even more probable.

So this means you have two issues.  1.  Clients that will have to be
updated with better firmware or replaced.   2.  Your entire system
will have to be redesigned for a proper routed design.

The way out of this is obvious, but it will be painful and costly.
There is going to be a lot of anger directed at me for this message so
I am now ducking down to avoid the flames.

Regards,
Lonnie


On 10/28/06, David E. Smith [EMAIL PROTECTED] wrote:

Mac Dearman wrote:

 I tend to believe you will find your answer on your network -vs- big bad
 leak somewhere and the only real suggestion I can offer you would be to do
 what we do here when we start having weird issues

[ snip: Mac's good advice on how to track down broadcast storms and
other network-related problems ]

If it were a backhaul problem, though, wouldn't I see high latency on my
backhaul links? I haven't, to date.

Here's one of the (many) experiments I've done in the past (this one was
yesterday, actually): I logged into an affected AP, while the problem
was happening, and firewalled off THE WHOLE INTERNET except for one IP
address, that being the PC in my office I was using to log into that AP.
Then, from that AP, I pinged a CPE associated with it. The problem
persisted, high packet loss and 5000-1 millisecond latency.

I quickly undid my changes on that AP, then did exactly the same thing
on another AP, about twenty miles away, with a different radio card, on
a different channel, connected to me through a different backhaul link,
and saw exactly the same performance (high packet loss, obscene latency,
et cetera).

Meanwhile, pings to and through our backhaul links, to the APs
themselves, various managed switches at tower locations, and so on,
never skipped a beat. (Heck, most of 'em improved a bit, since there
wasn't as much pesky customer traffic going through them. :)

For that matter, why do I have three towers with a mixture of 2.4GHz and
other APs (two with a 900MHz AP, one with a 5.3GHz AP and a 5.8GHz AP)
and the non-2.4 customers aren't affected? Keep 

Re: [WISPA] The Gremlin, redux

2006-10-28 Thread John Scrivner

Mac,
We believe this is truly an outside offender in 2.4 GHz. I have 
personally seen a carrier that is several times more power than anything 
I have ever seen. I only saw it for a brief instant though. This 
interference just does not last long enough to be caught. The high 
latency is caused by retransmits but I am sure outside interference is 
what is leading to the need for frames to be sent again. This effects 
all channels across the 2.4 GHz bands. We have seen the noise floor jump 
up higher than our radio power levels when this problem happens. What 
ever is causing this is running higher power than anything we have in 
the field. We will look at anything, though, to help troubleshoot and I 
appreciate your ideas.

Scriv


Mac Dearman wrote:


David,

I tend to believe you will find your answer on your network -vs- big bad
leak somewhere and the only real suggestion I can offer you would be to do
what we do here when we start having weird issues - - and that is to be
ready to start unplugging Back Hauls (one at a time) out of their
switch..Etc when the trouble starts. Have a ping running to watch for the
latency to disappear when you unplug the offending Back Haul. Once you
narrow it down to the right leg of the network you can reboot one AP at a
time until you find which AP it is coming from by running an extended ping
on that leg of the network

Don't pull a big dummy like we did here for weeks!! Unplug the servers
one at a time too!!! That is where we found one of the servers we host was
our culprit. There traffic was of such that it was flooding our switches - -
(dirty suckers) :-)

GL -  keep us informed as to what you find

Mac Dearman


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of David E. Smith
Sent: Friday, October 27, 2006 4:10 PM
To: WISPA General List
Subject: Re: [WISPA] The Gremlin, redux

On Fri, October 27, 2006 3:11 pm, Eric Merkel wrote:

 


1) Turning off inter-BSS Relay
   



Already done, on most towers. (We do have a couple of towers where one
business, with two locations, wants to do VPN-type stuff between 'em.)

 


2) We block all the typical MS ports(135-139) which broadcast all the
time via iptables
   



Done. We block 135-139, 445, and a couple other ports, both TCP and UDP.

 


3) Packet shape all connections via CBQ on the AP itself to limit how
much bandwidth any one customer can consume
   



Mostly done. (For historical reasons, some of our customers are still part
of a giant bridged network, and their traffic is shaped in our office not
at the AP, but those customers are relatively few and growing fewer by the
week.)

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: SPAM ? Re: [WISPA] The Gremlin, redux

2006-10-28 Thread Mac Dearman
VLAN's and Trunking stop all the broadcast traffic. You won't hear me say
NOT to static route (yuck) as I have a lot of my network statically routed,
but it does NOT out perform my bridged, VLAN'd network segments.

 I did have a completely flat bridged network and never had my network
flooded by a single user with a virus. I am not saying that its not
possible, but it never happened to me once in 4 years (and I have 15% of the
State of Louisiana covered with wireless) before changing half of my network
to a statically routed network. I did have a switch to get flooded in the
NOC that actually shut my network down many times before I caught that
sucker.

I realize that a VLAN'd network can still have trouble, but no more than
your statically routed network. There are more ways to skin a cat than one
:-) although we know your preferences :-)


Mac 


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Lonnie Nunweiler
Sent: Saturday, October 28, 2006 4:18 PM
To: WISPA General List
Subject: SPAM ? Re: [WISPA] The Gremlin, redux
Importance: Low

Since your customers are mostly on a bridged network then a single
malicious or misbehaving customer radio can take your WHOLE network
down.  The reason your backhaul is not affected is simply because it
has more capacity than the prism AP units.

I know you guys are tired of hearing from me about routing versus
bridging (You even gave me my own clause) but your problems are
precisely what I have been describing for all of these years.

The one point you are missing in your overall design is something I
have brought up a number of times.  A properly functioning bridged
system will echo all broadcast traffic throughout the network, thus
one system can flood the entire LAN.  This leads to the biggest single
factor -- your entire network speed is a factor of your slowest AP,
since it must rebroadcast all traffic to its users.

On a routed design you will still get problems like these slowdowns,
but the very important thing to keep in mind is that the slowdown will
only take out the one sector.  Also (and this should be enough to make
you take a hard look at routing) your LAN throughput is the sum total
of all of your AP units and thus you might actually start to use your
high speed backhaul.  Your ping times will go under 2 msec per
repeater.  Our WAR boards are actually around the 1 msec area.

The other thing you have going against you is that you are using a
unit based on the Ubicom chipset.  Remember the dear old Wet11?  That
was Ubicom using a prism radio.  CB3 is simply a newer version, but
still with some issues that seem to be killing networks everywhere.

Our last version of the Atheros driver would start to show units could
not reconnect and the only way to make the system settle down was to
change channels or reboot.  What is happening is that the CB3 has
trouble when it reconnects to an AP.  Something is not quite right
with its handshake and it does not get accepted.  This causes it to
throw a hissy fit and it starts to hammer the AP with reconnection
attempts.  That massive RF directed at the AP soon causes other units
to disconnect and guess what happens if they are a CB3?  They try the
same techniques the first tried.  Suddenly you have this massive
reconnect storm and the AP is brought to its knees until you change
channels or reboot.

Your whole problem is circular and is based on poor choices of both
equipment and network design.  You chose cheap units that only do a
pseudo bridge so you designed your LAN accordingly.  You thought you
would be safe because you had a good AP, but a LAN is mostly made up
of clients, so if the clients are poor, then it follows that your LAN
is poor.

You have some sectors already routed, but they still have the trouble.
 I say this is because of the trouble of the clients, which could be
at this tower or simply because your tower is visible to them.  You
are quite likely even using 200 mW prism cards which makes this factor
even more probable.

So this means you have two issues.  1.  Clients that will have to be
updated with better firmware or replaced.   2.  Your entire system
will have to be redesigned for a proper routed design.

The way out of this is obvious, but it will be painful and costly.
There is going to be a lot of anger directed at me for this message so
I am now ducking down to avoid the flames.

Regards,
Lonnie


On 10/28/06, David E. Smith [EMAIL PROTECTED] wrote:
 Mac Dearman wrote:

  I tend to believe you will find your answer on your network -vs- big
bad
  leak somewhere and the only real suggestion I can offer you would be to
do
  what we do here when we start having weird issues

 [ snip: Mac's good advice on how to track down broadcast storms and
 other network-related problems ]

 If it were a backhaul problem, though, wouldn't I see high latency on my
 backhaul links? I haven't, to date.

 Here's one of the (many) experiments I've done in the past (this one 

RE: [WISPA] The Gremlin, redux

2006-10-28 Thread Mac Dearman
John,

 Can you set up a CPE to monitor noise floor levels (MRTG..etc) and point
them at different towers owned by different companies that may be suspect in
your area? If you can identify this - - I have another idea to prove it or
release a suspect tower out of suspicion, but that will require a personal
phone call :-)

Mac Dearman

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of John Scrivner
Sent: Saturday, October 28, 2006 4:22 PM
To: WISPA General List
Subject: Re: [WISPA] The Gremlin, redux

Mac,
We believe this is truly an outside offender in 2.4 GHz. I have 
personally seen a carrier that is several times more power than anything 
I have ever seen. I only saw it for a brief instant though. This 
interference just does not last long enough to be caught. The high 
latency is caused by retransmits but I am sure outside interference is 
what is leading to the need for frames to be sent again. This effects 
all channels across the 2.4 GHz bands. We have seen the noise floor jump 
up higher than our radio power levels when this problem happens. What 
ever is causing this is running higher power than anything we have in 
the field. We will look at anything, though, to help troubleshoot and I 
appreciate your ideas.
Scriv


Mac Dearman wrote:

David,

I tend to believe you will find your answer on your network -vs- big bad
leak somewhere and the only real suggestion I can offer you would be to do
what we do here when we start having weird issues - - and that is to be
ready to start unplugging Back Hauls (one at a time) out of their
switch..Etc when the trouble starts. Have a ping running to watch for the
latency to disappear when you unplug the offending Back Haul. Once you
narrow it down to the right leg of the network you can reboot one AP at a
time until you find which AP it is coming from by running an extended ping
on that leg of the network

 Don't pull a big dummy like we did here for weeks!! Unplug the servers
one at a time too!!! That is where we found one of the servers we host was
our culprit. There traffic was of such that it was flooding our switches -
-
(dirty suckers) :-)

GL -  keep us informed as to what you find

Mac Dearman


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of David E. Smith
Sent: Friday, October 27, 2006 4:10 PM
To: WISPA General List
Subject: Re: [WISPA] The Gremlin, redux

On Fri, October 27, 2006 3:11 pm, Eric Merkel wrote:

  

1) Turning off inter-BSS Relay



Already done, on most towers. (We do have a couple of towers where one
business, with two locations, wants to do VPN-type stuff between 'em.)

  

2) We block all the typical MS ports(135-139) which broadcast all the
time via iptables



Done. We block 135-139, 445, and a couple other ports, both TCP and UDP.

  

3) Packet shape all connections via CBQ on the AP itself to limit how
much bandwidth any one customer can consume



Mostly done. (For historical reasons, some of our customers are still part
of a giant bridged network, and their traffic is shaped in our office not
at the AP, but those customers are relatively few and growing fewer by the
week.)

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] The Gremlin, redux

2006-10-28 Thread Travis Johnson

Hi,

You may have covered this before, but I probably missed it in your 
original post. What equipment are you running for each of the different 
frequencies (2.4ghz, 900mhz, 5.8ghz, etc.).


Is it possible the 2.4ghz AP's are just not able to handle the high 
packet loads (broadcast storms, viruses, whatever) that the others are?


Also, I have never seen high noise on a band actually cause high 
latency... usually it causes packet loss. My guess is you have an 
internal problem, not external.


Travis
Microserv

David E. Smith wrote:


Mac Dearman wrote:

I tend to believe you will find your answer on your network -vs- big 
bad
leak somewhere and the only real suggestion I can offer you would be 
to do

what we do here when we start having weird issues



[ snip: Mac's good advice on how to track down broadcast storms and 
other network-related problems ]


If it were a backhaul problem, though, wouldn't I see high latency on 
my backhaul links? I haven't, to date.


Here's one of the (many) experiments I've done in the past (this one 
was yesterday, actually): I logged into an affected AP, while the 
problem was happening, and firewalled off THE WHOLE INTERNET except 
for one IP address, that being the PC in my office I was using to log 
into that AP. Then, from that AP, I pinged a CPE associated with it. 
The problem persisted, high packet loss and 5000-1 millisecond 
latency.


I quickly undid my changes on that AP, then did exactly the same thing 
on another AP, about twenty miles away, with a different radio card, 
on a different channel, connected to me through a different backhaul 
link, and saw exactly the same performance (high packet loss, obscene 
latency, et cetera).


Meanwhile, pings to and through our backhaul links, to the APs 
themselves, various managed switches at tower locations, and so on, 
never skipped a beat. (Heck, most of 'em improved a bit, since there 
wasn't as much pesky customer traffic going through them. :)


For that matter, why do I have three towers with a mixture of 2.4GHz 
and other APs (two with a 900MHz AP, one with a 5.3GHz AP and a 
5.8GHz AP) and the non-2.4 customers aren't affected? Keep in mind 
that, for annoying historical reasons, much of our network is still 
flat, bridged addresses flying willy-nilly across four counties. If 
it were a network storm, I'd expect it to hit all our towers, on all 
channels, and not conveniently skip over the most geographically 
remote ones.


There's also all the nasty logistical problems of my company not 
having twenty extra hands that we can just have sitting at all our 
towers for days, or weeks, at a time, waiting for a problem that shows 
up completely randomly, hoping I can call everyone to start unplugging 
stuff before the problem magically goes away, but that's another issue 
altogether ;)


Last, remember this really is amazingly random, and usually only shows 
up for a minute or two at a time, brief enough that I only see it in 
our logs well after the fact. (Yesterday it visited us for a good 
twenty minutes, long enough for customers to really notice, and for me 
to have time to dig into it again.)


I certainly don't mean to sound dismissive of any suggestions, it's 
just that I've tried most of the obvious ones before.


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] Not quite the Gremlin, but confusing just the same.

2006-10-28 Thread Mark Koskenmaki
I have a customer who called me up on Friday, saying he had trouble with his
VOIP phone, and that his service was real slow, had been slow for a few
weeks.

Well,we rebooted his router,  and the bridge on his house (he supplied it
long ago as he owns it - came from another provider who based the network on
linksys WET-11's, one of the two bridges left on my whole network), and it
didn't make any difference.

A speed test would get him about 800kbit, to wired or wireless clients in
his house.

He sits at 1.7 miles from my ap, and has some off-brand 24 db grid.  -58 at
the AP, if I recall correctly.

I suspected interference, so we turned off his internal AP, and checked for
2.4 ghz phones in the house (nope).

Out of the blue, I reset the ap from 11 (the best channel for some weak
clients at 11 miles distance) to 4, and he went from 800kbit to 4.2Mbit.

Now, he points at the hill, and there's nothing on the hill but me, and
nothing behind me but open space - SKY!   I have other clients a bit nearer
or farther than him, and in line with him.  He sits in the middle of a large
orchard.

His speed tests of 800 kbit would make pings to other clients jump from 3 to
7 ms to 250 to 500 ms.   Those other clients had the same ping times whether
I was on channel 4 or channel 11 so long as he wasn't  trying to move data.
( I have another AP at that site on 8, but only two clients, both of which
were idle the entire time we were working on it)I could do a star-os
speed test (compressible data) of 1500KB/sec and it would raise pings from
3-7 to 40 to 70, on a client situated inline with him but farther away.

When I moved the AP to channel 4, he could repeatedly get 4.2 Mbit, and
pings to other clients would only go from 3-7 up to 20 to 35 during his
speed test.   Oh, and his VOIP phone is now glitch-free.

You think his radio might be failing?   I ahve no othe symptoms on channel
11 or 4 to any other clients (other than 11 is 3 db stronger to a couple of
clients who are quite distant and I think are in a noisy area).   And yes,
this is ALL on 11b mode.


+++
neofast.net - fast internet for North East Oregon and South East Washington
email me at mark at neofast dot net
541-969-8200
Direct commercial inquiries to purchasing at neofast dot net

- Original Message - 
From: Travis Johnson [EMAIL PROTECTED]
To: WISPA General List wireless@wispa.org
Sent: Saturday, October 28, 2006 3:55 PM
Subject: Re: [WISPA] The Gremlin, redux


 Hi,

 You may have covered this before, but I probably missed it in your
 original post. What equipment are you running for each of the different
 frequencies (2.4ghz, 900mhz, 5.8ghz, etc.).

 Is it possible the 2.4ghz AP's are just not able to handle the high
 packet loads (broadcast storms, viruses, whatever) that the others are?

 Also, I have never seen high noise on a band actually cause high
 latency... usually it causes packet loss. My guess is you have an
 internal problem, not external.

 Travis
 Microserv


-- 
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: Anheuser-Busch Rice Mill Jonesboro Ar.

2006-10-28 Thread Chad Halsted

you could give these guys a call

Black Sheep Computing
2312 E Matthews Ave
Jonesboro, AR 72401
(870) 910-6969
www.bscn.com

On 10/28/06, Marlon Schafer (509-982-2181) [EMAIL PROTECTED] wrote:

Can anyone help a stranded motorist?

Hit me offlist for contact info.

laters,
marlon




Hi Marlon,

My company is looking for broadband service at this rural address in
arkansas..

Anheuser-Busch
Jonesboro Rice Mill
3723 CR 905
Hwy 49 North at Farville
Jonesboro, AR 72401-0749

Do you know of anything available?


The information transmitted (including attachments) is
covered by the Electronic Communications Privacy Act,
18 U.S.C. 2510-2521, is intended only for the person(s) or
entity/entities to which it is addressed and may contain
confidential and/or privileged material. Any review,
retransmission, dissemination or other use of, or taking
of any action in reliance upon, this information by persons
or entities other than the intended recipient(s) is prohibited.
If you received this in error, please contact the sender and
delete the material from any computer.



--
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/




--
Chad Halsted
The Computer Works
Conway, AR
www.tcworks.net
--
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/