WDS + WPA + RADIUS problem

In the interest of unified learning it was suggested I post to this
newsgroup, rather than direct email communication.

One of our clients is an accommodation complex. They want to provide
internet access to all their tenants and unfortunately due to the
layout of the buildings it was not cost effective to run wired cables.
As a result we went for a wireless solution.

There are 4 groups of buildings in total. The administration building
and 3 complexes with units in them. They are spread out over a
reasonable amount of distance. Each complex has two physical
buildings. The buildings are all brick and are two storey.

We ended up going with 4x Netgear WG302v2's, using 21db waveguide's
and 1watt amplifiers. This was at the recommendation of a colleague of
ours. The units were setup in peer to multi-peer configuration with
the AP at the administration building being the main AP, where a
server running freeRADIUS and an internet connection exists.

The APs were configured with WDS, having three SSIDs and VLANs. A
silent SSID for the management vlan, an open security SSID for the
guest VLAN which has a single website that provides the users with the
information on configuring their computers and a WPA2 Enterprise
secured SSID for the internet VLAN.

Users authenticate using WPA2/802.11x authentication against the
RADIUS server using a username and password.

Aside from the complications imposed in configuring Windows based
computers with dot1x, we got the system up and running, however we
started experiencing randomly timed packet loss. We attempted
adjusting the radio power levels in a hope to eradicate this problem
(thinking it was radio overlap) but to no avail.

When the packet loss occurs, the APs drop out and have to re-
authenticate against the primary access point, which in turn causes
connection to the RADIUS server to fail and boots all users off.

We have since gone back and attempted to configure the system in
purely repeater mode, but this resulted in more users being unable to
stay connected for an extended period of time. We have tried taking
out the AP of the building in the middle, so there are only 3 radios
in total, this helped a little, except that a section of the complex
does not get a strong enough signal to connect now.

We have setup monitoring to measure latency and packet loss, in an
attempt to try and determine any set pattern for the problem, however
all we have found is that it is mostly random - occuring any time
throughout the day, but much worse in the evening when most tenants
are attempting to use the system.

When this problem occurs, the radios event logs report "tx queue
stuck" just before they bomb out.

Unfortunately there is no way to hard wire each AP together without an
expensive outlay in fibre optics. It has also been suggested (by the
colleague who helped us in the first place) that we may need to setup
additional APs in the 5ghz spectrum to handle the link between the
admin building and each complex, and run each of the existing radio's
on a separate channel and SSID, to avoid overlap.

Although this would most likely work - it seems like a massive over
complication and defeats the purpose of WDS to begin with.

We've struggled to find any really good information on this type of
setup so any help would be greatly appreciated. The client is
extremely frustrated as their tenants are not getting a fast, reliable
connection and we need to find a solution for them soon.

Sorry - I'll correct myself, the waveguide's are 11db omni antenna's

davidr (at) insane (dot) net (dot) au wrote:
> We ended up going with 4x Netgear WG302v2's, using 21db waveguide's

Thanks Jeff. We appreciate the time you've put into this response and
it has given us a lot to go back and reconsider.

On Mar 1, 10:29 am, Jeff Liebermann <je...@cruzio.com> wrote:
> Well, you didn't do everything wrong, but you came close.

I think sadly we have been lead a little astray in the initial
configuration - with the radio+antenna+amplifier design. The antenna's
are mounted on the roof of the buildings (I will attempt to put
together a site layout to show) and are about 3 feet above the roof.

http://www.insane.net.au/files/complex1/layout.jpg - this is a crude
layout of the complex, i dont have a copy of the site plans on me at
the moment to scan.

http://www.insane.net.au/files/complex1/admin1.jpg and
http://www.insane.net.au/files/complex1/admin2.jpg - are photos of the
administration building and mounting of the antenna on this building

http://www.insane.net.au/files/complex1/building1a.jpg
http://www.insane.net.au/files/complex1/building1b.jpg
http://www.insane.net.au/files/complex1/building1c.jpg - photos of the
most complicated structure, complex 1 and mounting of the antenna

http://www.insane.net.au/files/complex1/building2a.jpg - photo of
complex 2 and antenna mounting. Complex 3 is identical to this
building layout.

> I suggest you reconsider. *The advantages of a wired backhaul are
> substantial over WDS or other forms of mesh network. *You only need a
> cable or fiber to each access point, not each apartment. *I'll cover
> some of the other advantages as *blunder along.

I'll have to go through their wiring a bit more closely. From our
initial inspections of the complex each group of buildings had it's
own IDF and power grid. I will have to see if they wire back to a
central location - hopefully they do.
>
> >There are 4 groups of buildings in total. The administration building
> >and 3 complexes with units in them. They are spread out over a
> >reasonable amount of distance. Each complex has two physical
> >buildings. The buildings are all brick and are two storey.
>
> Time for a short rant. *Please supply numbers instead of vague
> descriptions. *How many buildings total? *How high are the buildings.
> What are the distances involved in meters? *Where in or on the
> buildings are the access points located? *On the roof? *Any coax
> cable? *If so, what types and how long? *How high off the roof? *How
> are you entering each apartment with RF? *Through the windows? *How
> much bandwidth do you have to the ISP? *How many active users per AP?

There 6 apartment complexs in total. I could not tell you their height
(see photos). Access points are located in the roof of each of the
buildings (see layout) with 3 metre cable running outside the building
out on to the roof where the antennas are mounted, on top of the roof
- approximately 3 feet above the roof. We have two adsl2 connections
coming into the network with approximately 24mbps between them (due to
distance from the exchange). The complex has 144 rooms, which means
144 possible users (if each person has one computer). At present we
are seeing 10 - 20 users per AP, although zero if any users are
signing on to the AP in Complex 2.

> Please try to be more specific and supply numbers. *Extra credit for
> hardware URL's so I don't have to Google for them.

The waveguide omni's we are using are from here:
http://www.rfshop.com.au/Default.asp...e+Omni&Level=3

The Netgear WG302v2's hardware URL is here:
http://netgear.com.au/Products/APsWi...Specifications

The units are running in b/g mode with the waveguide connected to the
primary antenna. Both antenna's are enabled.

> Problem #1. *Too big an antenna and too much xmit power. *The problem
> with 11dBi omnidirection antennas is that they have a very narrow
> vertical radiation angle. *My guess is a -3dB beamwidth of about 5
> degrees. *If the antennas are perfectly vertical (yet another
> difficulty), then you will have wonderful coverage of the rooftops and
> possibly the upper floors. *However, the lower floors may not get much
> RF.

I was concerned about that - there were a couple of rooms in Complex 1
which are on the ground floor of the northern most building which get
poor reception unless the radio on Complex 1 is set at half or full
power. From what you're saying (and what I've seen you and others post
- it would be better to aim directionals across the wall of the
buildings and aim to get the signal through the windows, rather than
the current "amplify the hell out of everything and hope to pick up a
signal" scenario we've ended up in?

> Problem #2. *The 1 watt amplifiers create what I call an "alligator".
> All you're doing is generating interference with the 1 watt amplifier.
> Remove it. *Your usable client range will be about the same, and your
> self-interference problems will be somewhat reduced.

I'll be doing that first thing next week. At the moment we have the
radios down on 1/4 power for Complex 1, 2 and 3. I assume once we
remove the amplifier we would be able to boost these back up - in
conjuction of a site survey - to help ensure a strong signal?

> >This was at the recommendation of a colleague of ours.
>
> Well, at least you have a suitable scapegoat. *

sadly :/ though that doesn't really help the client out. I am thinking
maybe our colleague has a poor understanding of this type of
installation. He had nothing to do with RADIUS/802.1x, just the
selection and placing of the antennas.

> Problem #3. *RADIUS authentication is UDP, not TCP. *There's no
> guaranteed delivery mechanism.

This explains exactly why people can access the 'open' network without
issue but struggle at times to get onto the secure network. We have
since removed RADIUS authentication to take this out of the loop.
We're working on an alternative for the security.

> Problem #4. *WDS has its place, but not outdoors. *It's basically a
> mesh network with all its issues but none of the reliability offered
> by custom routing auto protocols, self healing, roaming, and such. WDS
> is about as crude a mesh network as could be build. *WDS and mesh also
> force your system to put everyone on one channel. *Think of it this
> way.... There are 3 non-overlapping channels (1,8,11). *If you had a
> wired backhaul, you could put each access point on one of these 3
> channels, and effectively have 3 times the over the air bandwidth, or
> 1/3 the mutual interference. *I suggest you download and read
> carefully channel layout section of the Intel Hotspot Guide

Why do you say WDS is not suitable for outdoors? I understand the non-
overlapping channels and would love to put each radio on it's own
channel, however without a backhaul method this seems impossible. As
I've said, I will re-investigate our options for an alternative
backhaul, but we can't put in fibre (the client refuses to spend that
money) and I'm not sure the wiring of the complex will be very
rewarding either.

> What you should have done before deploying this abomination is put
> everything in one large room, turn everything on, and make a few
> thruput, latency, reliability, packet loss, and retrans rate
> measurements. *

Yeah we failed here. We did have the system running in our office for
test, but this was without the waveguide's and amplifiers. We were
just using the standard antennas.

> That brings up the problem of interference. *Have you done a site
> survey of the area looking for tenants that have their own systems?

Every unit has a microwave oven. There are 8 existing wireless routers
belonging to tenants who have their own ADSL connections. There is
also a radio broadcasting from the local university which is quite
strong. We chose a channel with the least number of devices
broadcasting on it - 11.

> I suggest you take known and potential interference problems rather
> seriously. *It only takes one leaky microwave oven to shut down the
> entire neighborhood. *How many microwave ovens are in the complex?

There is a microwave oven in each apartment - 16 in complex 1; 8 in
complex 2; and 8 in complex 3 = total of 32

> Problem #5. *Too complexicated. *The system management application
> probably doesn't need a VLAN and also probably assumes that it's going
> to be run over a reliable wired network, not a packet lost infested
> wireless link. *The guest VLAN is nice, but the same thing can be done
> with a simple splash page prior to authentication. *See NoCatSplash:
> <http://www.dd-wrt.com/wiki/index.php?title=NoCatSplash>
> Ignore the rubbish about it not working in the final version. *That
> was fixed long ago.

[nods] this was probably force of habit. We built/manage a VMPS based
VLAN administration system and are used to putting all the devices
into a management vlan (for security and the authentication data) and
having a logon network for authentication and if necessary
documentation.

> By management, I assume your using SNMP. *What monitoring applications
> are you using? *I'm just curious.

NAGIOS/NRPE to identify periods of extreme latency and/or packet loss.
SNMP graphing via RRDtool the interface statistics.

> >Users authenticate using WPA2/802.11x authentication against the
> >RADIUS server using a username and password.
>
> Good plan, but because RADIUS is UDP, you're going to have problems
> due to packet loss.

Yeah based on your initial emails, we're pulling the RADIUS method out
in favour of something a little closer to Chillispot/NoCatSplash. To
appease the students we've temporarily just built a MAC address list
and added them to the firewall, removed the WPA protected network and
are running it that way whilst we work out the rest.

> I suggest you forget about omni antennas for illuminating the outside
> of a building. *I use sector antennas which have a small vertical
> radiation angle, but a wide (90-160 degree) horizontal angle. *This is
> perfect for illuminating a long but not very high building from a
> distance.

I'll start looking into our options here. It would require more
radios, which is obviously not the end of the world - it's just the
backhaul which is the problem.

would it be feasible to use a radio like this one
http://www.netgear.com.au/Products/A...Specifications
to use the 5Ghz spectrum to create our backhaul if we are still unable
to get a hard wired backhaul in place? Then possibly look at using
sector antenna's as you suggest to better illuminate the apartments?

> >The client is
> >extremely frustrated as their tenants are not getting a fast, reliable
> >connection and we need to find a solution for them soon.
>
> 90 minutes to write this mess. *I need a lower overhead "hobby".

I know it may not sound like much, but your time and effort is really
appreciated. My engineer and I have been pulling our hair out over
this one and really wish we hadn't taken on the project in the first
place. We were asked to do it as a favour to this client and were
given advice by a colleague for the planning of it (and testing, site
surveying, etc).

Another company quoted on the system using 3 x 15dbi omni antenna's,
(like http://www.rfshop.com.au/Default.asp...ProductID=5890)
and 3 socris board style radios. Based on the problems we've faced
with this complex, I'm wondering how they intended on doing this since
they were only going to have a radio at admin, Complex1 and Complex3.

Cheers

David Rudduck

LR:

> On 01/03/2009 05:13, Jeff Liebermann wrote:
>
>> I can't engineer this thing from a distance without knowing
>> the method of construction and the RF attenuation of the various
>> walls and windows. In general, a window is much easier to
>> penetrate than a wall.
>>
>
> Looking at the roof in
> <http://www.insane.net.au/files/complex1/building1c.jpg>
> there does not seem to be any overlaps as if tile has been used. I
> wonder if it is metal or have they used a polycarbonate material?
> I believe they still use metal in Australia.

http://en.wikipedia.org/wiki/Corrugated_galvanised_iron


--
"Well, opinions are like assholes. Everybody has one." Dirty Harry

i'll respond to this more once we've assessed the cabling and done a
proper site survey.. i've just ordered in a wi-spy 2.4x. figure i'll
need something like that again in the future, possibly a bit over the
top but i can't really afford this sort of stuff up again.

just with regards to location, here is the google maps arial view

http://maps.google.com.au/maps?f=q&s...03642&t=h&z=18

thanks for all your help so far.. we're going to tackle everything one
step at a time..

1st. we took out radius authentication
2nd. disabled the AP in the middle complex (building 2) to drop
interference
3rd. we'll take out the amplifiers, do a site survey and assess
whether to put the middle ap back in or not
4th. we're investigating our options for the backhaul - although i am
really unconfident about the viability of using existing wiring, but
here's hoping.
5th. we'll look at better antenna's and more radios

i thought it would be appropriate that i came back here and posted an
update .. both to thank those who provided some needed assistance and
also to help anyone else out there who has a similar problem and is
struggling (like i was) to find answers.

after the last post we went back and pulled the WG302v2's out and put
in WRT54GL's running dd-wrt. we tested this in our office environment
first and with some basic QoS rules we were able to put about a dozen
computers (that's all we had here) on the mesh without any issues.

we put these into the field and they produced a much better result
than the WG302v2's, however for reasons beyond our understanding DD-
WRT would reboot for no apparent reason. After a bit of research we
read that this was a common problem with DD-WRT and WDS, and that
apparently 'Tomato' firmware did a much better job of this.

We upgraded all the WRT54GL's to run Tomato and this did infact
stabilise the environment greatly. WDS / meshing on the WRT's is much
better than the WG's, however during peak periods (as expected) we
still experienced a lot of packet loss, causing the performance to
degrade considerably.

We were unable to find any way to "hard wire" the radios and so last
week we put in 2x 5.8Ghz radios to provide a backhaul for one of the
2.4Ghz radios which was previously meshed to the primary radio. Upon
doing this the performance for this sector has jumped leaps and
bounds. Users connected to that radio and the primary radio are now
ecstatic with the performance, and users connected to the remaining
two radios (running in WDS / mesh mode) are now asking the client to
"do the same thing" to their building.

We are now in the process of purchasing another 4x 5.8Ghz radios to
create the remaining two backhauls and will be implementing this as
soon as possible.

We are faced with one remaining problem however - for reasons beyond
our understanding the WRT54GL's still randomly reboot. This is usually
only a couple of times a day, however we have been unable to work out
WHY.

Research has indicated that this is a common problem with the wireless
lan (wl) module in the firmware and that *apparently* OpenWRT's
Kamikaze firmware has an updated wl module which is not susceptible to
this problem. The only down side is that of course OpenWRT has no web
interface and the web interface of dd-wrt and tomato has been very
useful in helping to identify signal problems, bandwidth usage, etc
(and thus will be beneficial in the ongoing management of this
environment).

Alternatively we could put the WG302v2's back in - as these units did
not "randomly reboot" and had a much stronger radio, however their own
web interface was not overly intuitive either, nor was the QoS as
effective as that in dd-wrt.

I am going to run up a WRT54GL with dd-wrt again and swap the primary
radio over to test and see if we can get around the reboot problem.
Failing that I will do the same with open-wrt, although as I said, I'm
a bit hesistant because I like having the web interface for the
information it provides.

The biggest problem with this "reboot problem" is that every so often
when the unit(s) reboot, they lock up - requiring a power cycle. As
the management of the complex are not always on site, this could
create a long outage period which is not acceptible. I have considered
putting in power timers to do a power cycle once every day at say 5am
when all the students would be asleep, but would ultimately prefer the
solution to be solid.

Any thoughts / suggestions on this would be appreciated. Again thanx
for all the help - we are _nearly_ at a reliable solution.

hey jeff.. thanx again for your feedback..

On Mar 27, 11:40*pm, Jeff Liebermann <je...@cruzio.com> wrote:
> I don't run WDS on my DD-WRT access points, but I have no spontaneous
> reboots. *However, I do have some servcies and daemons going comatose,
> which has resulted in my setting up cron to reboot the router just
> after midnight every day. *

at the moment, 3 of the APs are still running in WDS mode (however we
have now ordered the remaining 5.8Ghz radios so all of them will be
running individually soon). the main radio in the WDS configuration is
the primary problem, however every radio, including the one that is
not in WDS reboot randomly throughout the day.

> However, in the past, I did have problems at coffee shops with table
> overflows that eventually caused hangs and reboots. *Specifically, the
> DHCP lease table was filling up. *That's because in v24, DD-WRT began
> saving the DCHP leases in NVRAM. *That's handy for suriving a reboot
> where you would want all the current clients to get the same IP
> address after the reboot. *However, it was a disaster at a coffee
> shop, where transient users and connections rapidly filled up the DHCP
> lease tables. *There's a setting in there somewhere under
> Administration to disable this feature. *Life was much better
> afterwards.

see that's the thing, the radios aren't doing any DHCP. that's all
being handled by the server. the radios were storing bandwidth data to
nvram, so I disabled that, but it still reboots. infact after i
disabled logging bandwidth utilisation to the main radio (ap1, which
is still in the WDS configuration), the unit locked up.

i know the lock up is a result of a reboot, as i've previously
telnet'ed into the device and rebooted it, or clicked the reboot
option inside the web interface and it has never come backup -
requiring a hard reset.

> Yep. *Putting the backhaul on 5.8GHz and getting rid of the WDS
> repeaters should yield a big performance boost. *Users are no longer
> competing for air time with the backhaul. *In addition, there are
> enough non-overlapping channels (12) on 5.8GHz to allow each backhaul
> it's own channels.

i'll have to go look up the non-overlapping channels, but yes,
definite improvement. apparently the next building in the complex will
start construction at the end of the year. i've now convinced the
client (after all of these problems) to run fibre to the building for
the backhaul.

> Syslog is your friend. *Fire up Syslog on each router, turn up the
> reporting to maximum, and send the reports to central Syslog server.
> Ideally, it should be a Linux box, but Windoze can do the job:
> <http://www.kiwisyslog.com/kiwi-syslog-server-overview/>

we're running syslog on the primary server with all AP's logging back
to it already.

this entry is me disabling bandwidth recording to nvram last night. at
which point the router locked up again.

Mar 28 22:41:58 unilink-ap01 kernel: nvram_commit(): init
Mar 28 22:41:59 unilink-ap01 kernel: nvram_commit(): end

after that there are no more entries till 1.30am when the unit was
either power cycled or miraculously came back online all by itself
(doubtful, but haven't spoken to client this morning to ascertain).

here are entries from when ap02 (which is not in WDS) has randomly
rebooted.

Mar 28 22:41:42 unilink-ap02 dnsmasq[609]: read /etc/hosts.dnsmasq - 1
addresses
Mar 28 22:41:42 unilink-ap02 init[1]: Linksys WRT54G/GS/GL
Mar 28 22:41:42 unilink-ap02 crond[615]: crond (busybox 1.12.3)
started, log level 8
Mar 28 23:00:01 unilink-ap02 crond[615]: USER root pid 985 cmd logger -
p syslog.info -- -- MARK --
Mar 28 23:00:01 unilink-ap02 root: -- MARK --
Mar 28 23:06:01 unilink-ap02 crond[615]: USER root pid 1097 cmd
ntpsync --cron
Mar 29 00:00:01 unilink-ap02 crond[615]: USER root pid 2107 cmd logger
-p syslog.info -- -- MARK --
Mar 29 00:00:01 unilink-ap02 root: -- MARK --
Mar 29 01:00:01 unilink-ap02 crond[615]: USER root pid 3205 cmd logger
-p syslog.info -- -- MARK --
Mar 29 01:00:01 unilink-ap02 root: -- MARK --
Mar 29 02:00:01 unilink-ap02 crond[615]: USER root pid 4287 cmd logger
-p syslog.info -- -- MARK --
Mar 29 02:00:01 unilink-ap02 root: -- MARK --
Mar 29 03:00:01 unilink-ap02 crond[615]: USER root pid 5380 cmd logger
-p syslog.info -- -- MARK --
Mar 29 03:00:01 unilink-ap02 root: -- MARK --
Mar 29 03:05:05 unilink-ap02 kernel: klogd started: BusyBox v1.12.3
(2008-12-14 02:54:58 PST)
Mar 29 03:05:05 unilink-ap02 kernel: CPU revision is: 00029008
Mar 29 03:05:05 unilink-ap02 kernel: Primary instruction cache 16kb,
linesize 16 bytes (2 ways)
Mar 29 03:05:05 unilink-ap02 kernel: Primary data cache 8kb, linesize
16 bytes (2 ways)
Mar 29 03:05:05 unilink-ap02 kernel: Linux version 2.4.20 (root@etch)
(gcc version 3.2.3 with Broadcom modifications) #1 Sun Dec 14 03:03:26
PST 2008
Mar 29 03:05:05 unilink-ap02 kernel: Setting the PFC value as 0x15

Tomato's features are a bit limited. I think that's the extent of
logging I can give it.

With the primary ap (ap01) i'm willing to accept it might be faulty
and / or Tomato, so I've got another unit here that I've put dd-wrt
back on to and will put in to replace and see if it makes a
difference. I would _much_ prefer to leave the wrt54's out there
instead of the wg302's.

> I have a different theory. *I've crashed, hung, and ocassionally
> rebooted many different types of routers dealing with P2P (peer to
> peer) applications, such as Bitorrent, that open HUGE numbers of
> simultaneous streams. *Each stream requires an allocated buffer in the
> router. *The router eventually runs out of buffer space. *DD-WRT and
> others have kernel hacks and buffer tweaks to reduce the effects, but
> that only raises the bar on how much abuse the router can handle.
> Instead of crashing, the router now just slows down:
> <http://www.dd-wrt.com/wiki/index.php?title=Router_Slowdown>
> See the diagnosis section.

hrmm.. we do run snort+snortsam plus ipp2p on the linux gateway to
block all p2p type traffic. Obviously it's not going to be 100%, but
it generally does a decent job. That's not to say that it isn't a
result of buffer overload either. i'll dig into the settings and see
what i can find to block more thoroughly.

One of the posts I read regarding this random reboot problem suggested
that it could be in relation to certain wireless clients causing a
problem with WL and forcing a reboot. I've lost the post now, but
quite a few people were experiencing this problem.

> Wrong. *See:
> <http://x-wrt.org>
> <http://wiki.x-wrt.org/index.php/Kamikaze_Presentation>

i had read about these but tbh hadn't started looking into them. the
router at our office has been running openwrt kamikazi for nearly 2
years now without a problem - only time it's needed to be rebooted was
when we've had power outtages and it's locked up. and i do much prefer
writing the firewall / qos rules in shell rather than a web interface
- i found dd-wrt implemented QoS nicely, but Tomato I think only
implements QoS over the WAN interface, or at least that's how it
appears as I'm not getting any noticable control over flow no matter
what settings i put into the gui.

> Not for me. *The web interface is just too slow to be useful. *You can
> dig out just about any numbers found on the web pages using commands
> on the CLI (SSH) interface by digging for it in the /proc filesystem.
> Try:
> * cat /proc/net/dev
> for network traffic stats. *You can also get most of these via SNMP.

ahhh.. thanx for that, I hadn't even thought to go through the proc
fs. i'll go have a hunt on our office router here and see what i can
find. the other thing i didn't find (and i'm sure a quick search of
the openwrt forums would present it) is how to set the radio power..
but yer, i'll go hunting.. can't be too hard.. i assume an nvram
setting.

> That's not a "spontaneous reboot". *It's a hang. *Unset the check box
> that saves the DHCP leases (and arp table) in NVRAM. *Kill off the P2P
> traffic or expand the buffers to handle the overload. *Also, see if
> you can find a WRT54GS, that has twice the RAM as the WRT54GL. *I've
> had better luck with these.

i'll keep digging into the settings.. tomato as i've mentioned seems
fairly 'simple', but i'm going to switch back as we only switched to
tomato as apparently (reading forums) it was meant to be more stable
with WDS. it is/was, but as we've ascertained, WDS is not suitable for
this situation.

> Remote reboot is fairly easy. *The sloppy way is with X10 type power
> line modules. *I have several remote sites with pager operated power
> controls. *I used to use garage door openers for "drive by" reboots.
> There's also a setting in DD-WRT to have cron reboot the router at
> regular times or intervals.

hrmm.. that's trick. i'll have to have a look into this.. for me, it
needs to be as automatic as possible, the site in quesiton is 1 1/2
hour drive by highway from where i am located..

cheers

dave

Would putting the AP's in Client Bridge mode be an option? I've only used
WDS a few times but found for me client bridge was the way to go. maybe you
have a special reason this wont work but might be worth a try..

Adair
"davidr (at) insane (dot) net (dot) au" <(E-Mail Removed)> wrote in
message
news:afa2daaf-8db3-43d0-b8c5-(E-Mail Removed)...
>i thought it would be appropriate that i came back here and posted an
> update .. both to thank those who provided some needed assistance and
> also to help anyone else out there who has a similar problem and is
> struggling (like i was) to find answers.
>
> after the last post we went back and pulled the WG302v2's out and put
> in WRT54GL's running dd-wrt. we tested this in our office environment
> first and with some basic QoS rules we were able to put about a dozen
> computers (that's all we had here) on the mesh without any issues.
>
> we put these into the field and they produced a much better result
> than the WG302v2's, however for reasons beyond our understanding DD-
> WRT would reboot for no apparent reason. After a bit of research we
> read that this was a common problem with DD-WRT and WDS, and that
> apparently 'Tomato' firmware did a much better job of this.
>
> We upgraded all the WRT54GL's to run Tomato and this did infact
> stabilise the environment greatly. WDS / meshing on the WRT's is much
> better than the WG's, however during peak periods (as expected) we
> still experienced a lot of packet loss, causing the performance to
> degrade considerably.
>
> We were unable to find any way to "hard wire" the radios and so last
> week we put in 2x 5.8Ghz radios to provide a backhaul for one of the
> 2.4Ghz radios which was previously meshed to the primary radio. Upon
> doing this the performance for this sector has jumped leaps and
> bounds. Users connected to that radio and the primary radio are now
> ecstatic with the performance, and users connected to the remaining
> two radios (running in WDS / mesh mode) are now asking the client to
> "do the same thing" to their building.
>
> We are now in the process of purchasing another 4x 5.8Ghz radios to
> create the remaining two backhauls and will be implementing this as
> soon as possible.
>
> We are faced with one remaining problem however - for reasons beyond
> our understanding the WRT54GL's still randomly reboot. This is usually
> only a couple of times a day, however we have been unable to work out
> WHY.
>
> Research has indicated that this is a common problem with the wireless
> lan (wl) module in the firmware and that *apparently* OpenWRT's
> Kamikaze firmware has an updated wl module which is not susceptible to
> this problem. The only down side is that of course OpenWRT has no web
> interface and the web interface of dd-wrt and tomato has been very
> useful in helping to identify signal problems, bandwidth usage, etc
> (and thus will be beneficial in the ongoing management of this
> environment).
>
> Alternatively we could put the WG302v2's back in - as these units did
> not "randomly reboot" and had a much stronger radio, however their own
> web interface was not overly intuitive either, nor was the QoS as
> effective as that in dd-wrt.
>
> I am going to run up a WRT54GL with dd-wrt again and swap the primary
> radio over to test and see if we can get around the reboot problem.
> Failing that I will do the same with open-wrt, although as I said, I'm
> a bit hesistant because I like having the web interface for the
> information it provides.
>
> The biggest problem with this "reboot problem" is that every so often
> when the unit(s) reboot, they lock up - requiring a power cycle. As
> the management of the complex are not always on site, this could
> create a long outage period which is not acceptible. I have considered
> putting in power timers to do a power cycle once every day at say 5am
> when all the students would be asleep, but would ultimately prefer the
> solution to be solid.
>
> Any thoughts / suggestions on this would be appreciated. Again thanx
> for all the help - we are _nearly_ at a reliable solution.