Date: Tue, 23 Nov 2010 23:30:57 +0800 From: Adrian Chadd <adrian@freebsd.org> To: Larry Vaden <vaden@texoma.net> Cc: freebsd-mips@freebsd.org Subject: Re: does anyone have a recommendation for a solid FreeBSD-based 802.11b/g/n AP package for MIPS-based APs and CPEs? Message-ID: <AANLkTim8-4Guwh7rgn9cGqffn29q7k8eC_Kc2X2o32ub@mail.gmail.com> In-Reply-To: <AANLkTinUKjgtM9iqsjdvO_achUMRPPCZGgcnXBKxw04e@mail.gmail.com> References: <AANLkTik_vvgQfhh_K-OecR-CE8nBWu=A3Kuvt8BYdXSZ@mail.gmail.com> <AANLkTikTRMMZHFjFOo-tWGgJ1=EVu0e2pMR8ScVVNfs9@mail.gmail.com> <AANLkTi=WhMTFK=eLaZb2DNG0NE0HmUBiQqfw1_6E29q1@mail.gmail.com> <AANLkTi==En8kS6H_7sxTGFMrEO3KLAbQwgMWsAwb9A2w@mail.gmail.com> <AANLkTinUKjgtM9iqsjdvO_achUMRPPCZGgcnXBKxw04e@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23 November 2010 23:18, Larry Vaden <vaden@texoma.net> wrote: > Adrian, the reason for my original post (seeking to return to the BSD > environs) is that we are seeing gross quantities of stuck beacons in > dmesg on the Ubiquiti M series and have recently noted perps diagnosed > by the UBTik (a MikroTik in a housing form fit and function compatible > with the Rocket M2) trying to associate with _WDS requested_ resulting > in latencies of 10x-20x normal latency. =A0We don't run WDS on our 2.4 > GHz APs. =A0We only run WDS on Ubiquiti M5 series in PTP because that's > the way they produce a transparent Layer 2 bridge. > > Is the amount of time spent processing such a request, combined with > logging and a busy channel, perhaps enough to effectively cause a > denial of service? I've no idea. I haven't at all looked at WDS. As Sam likely pointed out, stuck beacons can include: * because the RF environment is somehow hilariously bad, congested or dirty (seen this); * because the code needing to setup the beacon frames, flush it to RAM before the TBTT (and related) timers fire just doesn't get a chance to run (seen this); * because your backend PCI bus/CPU/FSB bus/etc is busy, and thus the beacon frame doesn't go out in time (haven't seen this); * because the chip is being fondled in the wrong way somehow and it's locking up something (definitely seen this.) It's just a shame that people focus on "stuck beacon!" rather than trying to figure out what other events are occuring at the same time. :-) To track down stuck beacons at my wireless contract, I ended up doing a -lot- of instrumentation to try and figure out what was going on when stuck beacons occured. For example, stuck beacons were occuring in the deep past because the initial noise floor calibrations were being done every 1/10th of a second during a periodic calibration (every 20 minutes), rather than every few seconds, and this tended to upset the radio. Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTim8-4Guwh7rgn9cGqffn29q7k8eC_Kc2X2o32ub>