@nathana The root cause to the issue is before conntrack session is confirmed in Linux conntrack stack, if Linux stack receives multiple packets (both DNS A and AAAA queries) from same session (ie the same source port …. btw the wireless clients should be using different source ports for each DNS type), the DNS AAAA packet would be dropped by the Linux stack.
1 Like
@GaryHans Thanks & that’s helpful, but…again, this traffic is being bridged by the AP, not routed. Sooo…why, at the AP level, is conntrack entering into the picture at all? Are you doing something funky with ebtables?
Conntrack is necessary in order to do filtering(allow, modify, drop) of packets which is a feature that can be done on bridged packets. It is linux kernel related and common to networking devices.
@nathana just building on Pete’s comment, with Enterprise APs it is not just simply bridging of packets like done by a hub, basic L2 switch or basic home AP. Enterprise APs have an expansive list of rich features (ie Application Control, filters, ACLs, etc) that require additional packet processing, especially for control plane packets.
@Pete_C, @GaryHans Thanks again.
Okay, so ebtables. 
Of course it makes sense that enterprise-grade APs are capable of such things. I suspect that the thing that is surprising at least some of us is, we expect that if we turn all such filters/ACLs/post-processing features off in the device, it would prevent frames/packets that are being affected by a bug in that code path to avoid hitting that code path in the first place. And what it sounds like you are telling us is that there is absolutely no way to 100% completely turn off those features and make the AP act as JUST a dumb bridge, even if it is either for the purpose of troubleshooting, or just as a temporary work-around.
It is my experience that, though these are good and desirable features to have and they bring good value to the product, the more “smarts” you inject into packet processing, the more opportunities there are for bugs to crop up. No slam on Cambium…it’s just the nature of the beast & not unique at all to you. But when those bugs inevitably do crop up & bring things to a screeching halt or highly negatively impact the user experience, those of us maintaining these networks need to have a way to actually turn them completely off, both so that we can help confirm the locus of the problem, and also so that we at least have usable networks until a fix is delivered.
Linux is probably at the root of (conservatively) about 90% of small network appliances (CPE especially), so it is also interesting to me that if this is a problem with Linux connection tracking implementation, that this issue hasn’t more widely affected other products by other manufacturers. If this wasn’t an issue until cnPilot e-series 6.x firmware, perhaps conntrack implementation changed in newer Linux kernel versions?
1/3 of the way through July…
Been running a WAX630E at home for a few weeks now. I swapped it in when I was testing something on Ruckus.
I lost my DPSK/EPSK… but as a WAP… No one in the house is complaining. Everyone can stream their TVs or movies. My WiFi calling never drops. IoT devices don’t complain at me.
Still pulling for you guys!
Huzzah ! Now it’s onto the meshing fixes after this gets fixed
Call from the bossman…
“Chris… I need to put something in here. I can get cAP XLs and need to install this week.”
This is gonna suck…
Those things are absolute dogs.
I tested them at work and they were all round poorer than the regular cAPs in almost every way.
1 Like
But they sure are loud!!!
Wifi 4.5. No chance of update to full WiFi 5 in 2022. I hate it when sales tries to sneak in a Mikrotik outdoor WAP, into my Ruckus systems. I just yell at them when the client complains about their connectivity outside and on the same side of the home where the outdoor wap is.
“What did you think was gonna happen! This happens every F–king time you spec that!”
But they just refuse to pay for the Ruckus outdoor WAPs. They always say the client complained that they won’t pay for that.
Sometimes they even try and bargain… “What if we put the WAP in an out door box?”
The delta in price between the R550 and XV2-2, would support the XV2-2T pricing.
But I gotta have that “this always works” system, that I do with Ruckus.
I can to some extent sympathize with those who balk at the price of modern enterprise APs. It seems like when the next generation hardware comes out, it doesn’t replace the existing products in the line-up at similar price points & cause previous-gen to get cheaper. No: all of a sudden, unit prices are like 2x the cost that they were previously. E-series Pilots are a great example frankly: WiFi 5 versions’ MSRPs are (near as I can tell) no cheaper than they used to be prior to the introduction of the WiFi 6 hardware, and XV2-2 MSRP is literally 2x or more the cost of e410. And that price difference really starts to add up when you multiply it times the number of units needed for proper coverage and makes it a hard sell…
I also have to wonder how you think you’d manage to talk a customer who doesn’t want to pay more than $100 MSRP for a cAP XL into instead paying ~$550 for a XV2-2 when they aren’t willing to pay ~$850 for a R550. The price delta between the MikroTik and the Cambium is greater than that between the Cambium and the Ruckus.
Things get even more complicated when you throw that name-begins-with-a-U company who shall not be named into the equation. Product availability (though absolutely not an inconsequential factor!) aside for the moment, when a U6-Pro goes for $150 MSRP, how are Cambium competing with that? Even if you suck it up and go to the Amazon scalpers, you’re still paying “only” ~$250/ea for them, so that’s still less than half the price of the XVs! So why would you not pitch those to a customer instead of cAPs if you’re that desperate? Are they really that terrible and/or are Cambium and Ruckus really worth paying 2x-3x more?
The job was sold with Ruckus. Product shortages are why the cap is being considered. This is due to a move in date.
And I see the UniF–k stuff all the time. The point of sales boys always try to use them at our commercial installs. As soon as they start having issues… We break them off a VLAN on our Ruckus WAPs and suddenly their connectivity problems vanish. As do the UniF–k WAPs from the ceilings. The Point of Sales guys still bill monthly for them (that’s just dirty) but it’s not my job to “do anything about it”. (I have been reminded repeatedly)
In residential installs… I see UniF–k pretty regularly. It’s handled by someone else and I won’t trouble shoot the wireless on those jobs. Amazingly… There are no problems on the wired side of the network. That f–ktard salesman who convinced the owner of the company that UniF–k was as good as Ruckus, eats s–t on the regular, from pissed off clients. They yell at me to help the guy… And I tell them I CAN’T. I refuse to look at the UniF–k server and my only answer is… “Take the device and connect it to my switch”… Or… “take a ruckus WAP out there and temp install it.” Surprise to no one… The Ruckus has worked Everytime.
As for Mikrotik wireless… My disdain for them is on full display all over their forums. I even beat them into submission and got them to admit publicly that they can’t correct the problems they have until they leave this driver. The hardware they have produced… Can’t take the new driver… Except on 3 models. WiFi6 isn’t even on the road map. 6E??? Yeah right. The cap AC XL is stuck on a 2015 wireless protocol. With no chance for update.
I learned the hard way about their (Mikrotik) hardware limits… A couple thousand dollars out of your own pocket will have that effect. But on paper and in the lab caps-man is awesome. It’s just when you use it in the real world do those radios really show how bad they suck.
As someone who has ripped out more Ubnt wifi/Mikrotik wifi that he would like to remember.The $ up front saved helps me nothing with if I have to and rip out and replace it in 6 months. I want 3 calls from the client 1)Call for site survey 2)Call for purchase order 3)Call in 5 years time telling me they want to upgrade to latest wifi standards.
At least with Ruckus/Aruba/Cambium I can log a ticket and speak engineer(s) that will hopefully get down to the issue/bug that we’ve discovered as opposed to ubnt/tik where you’re pretty much boned.You will have to throw the dice and hope it gets fixed in a new hardware release or downstream software release which could take a decade I’ve had the pleasure of discovering.
Ruckus is as close to set and forget as you can get to set and forget though very few customers go for it these days.
The cambium wifi 6 stuff has been a bit underwhelming if I have to be honest as I’ve had great success with the 410/510 combos in past in harsh or dense metallic environments, but hopefully they’ll get the software nailed down properly.
The point you’ve raised about new models not putting price pressure on the “old” models you see with the other top brands as well though I still think Cambium are better off selling the 410’s at a cheaper price thereby negating the ubnt advantage and then hooking customers into a subscription for cnMaestro X.
Yes, acknowledged that you see the pricing problem with other top brands, too. It’s a problem with WiFi networking gear in general, but it is one that I don’t really understand since it seems to be a somewhat new phenomenon and bucks historical trends when it comes to standards-based commodity tech. You even see it in consumer grade gear, where the average price of a home router with WiFi has been rapidly creeping up over recent years. Remember the days when 802.11g home APs were comfortably sub-$100 at retail? On day of release? Now people are spending $200 or more on the usual suspects (Netgear/Linksys/etc.) if they want something “current”, while last-gen (or even older) gear from these brands is still getting cranked off the manufacturing line and selling for roughly same MSRP as when it was introduced. It’s kind-of nuts and only ensures that we will be continuing to deal with “new” 802.11n and ac deployments and their limitations for years to come rather than being allowed to put them behind us and move on.
But it’s not even just that 11ac E-series Pilots still sell for $300 while the WiFi 6 Pilots are 2x that. It’s that the Ubiquiti WiFi 6 hardware sells for half the cost of a WiFi 5 E-series!! Which makes a WiFi 6 Pilot a whopping 4x the unit cost of a comparable (by the spec sheet) UBNT product.
Which brings me back to my question: is Cambium WiFi REALLY worth 4x the cost of UBNT? And if so, what about it justifies that cost? I’m genuinely asking: I haven’t touched UBNT WiFi 5 or 6 gear myself so I just have no context for how good or bad it is, or what the common problems are with it that would cause one to “rip out and replace in 6 months”.
What I can tell you, though, is that I am quickly becoming underwhelmed by the Cambium enterprise offerings as a whole. Between the bug that’s the subject of this thread (which, thankfully, I have yet to run into personally) and the one that I started my own thread about (Specific VAPs (one SSID on one radio) randomly stops bridging (some?) traffic), we’re talking two showstopper bugs that are both active & ongoing concerns, not ones that cause “mere annoyance”. It also absolutely does not help that the bug we are fighting was brought to our attention by one of our loudest customers, and that currently we have no real solution for them other than perhaps to rip out and replace the Cambium with UBNT (so, how’s that for irony). So all of this taken together leaves me wondering how well either we or the customer were actually served by us convincing them that it would be worth it for them to pony up a little extra for the “superior” Cambium solution.
I also have no direct experience with UBNT support, though I’ve heard troubling reports second-hand. MTik on the other hand I have extensive dealings with…their main problem support-wise is responsiveness, and occasionally language barrier issues. But in all fairness, I have to say that I’ve brought plenty of bugs to their attention over the years that they have turned around and fixed for me (it helps if you can repro the issue and give them minimum viable config; in my experience they are good at understanding well-formulated bug reports and acting on them). But MTik’s problem product-wise on the WiFi side is that they are constantly years behind the curve, even if they are cheap. Great routing and switching products for the $, not-so-great on WiFi side.
The ticket I filed for our bug will be the first real taste of Cambium support that I (personally) will experience. And though it’s early in the ticket lifecycle, and I’m willing to give them some time and some slack, I gotta say that the responses I’ve seen so far are not instilling me with much confidence…
Looks like the stable release that fixes the issue is now available.
FIXED: FLCN-11173 ALL AP dropped DNS AAAA inquiry.
Been working through this one. EPSK bit me.
Back to a hard stop.
@Springs I sense your luck & mine in this department might be quite similar, lol
I coined Nathan’s Law some years back: if your software or the software component of your product has a bug in it, no matter how obscure it is or how obscure the edge-case or trigger is, I will somehow manage to end up tripping it.
I can’t begin to count the number of times I have opened deeply-researched and carefully composed tickets with manufacturers detailing the bugs I’ve run into, only to initially be told (often not in so many words) that I’m “using it wrong”. After many frustrating hours/days/weeks/months of pushing back, the ones who finally come through with a fix will then tell me, “man, we’ve never seen anything like this before, nor heard from anyone else who has”. 
(There are some manufacturers where I have gone through this song-and-dance more than once. You’d think after the first 2-3 times I was proven right that the fault was with the product that they’d have learned to trust me, and we could just skip past that first unproductive part. I try to make a habit out of not crying wolf.)
@Springs and @djdrastic, you both mentioned having major problems with / having to replace Ubnt WiFi. If I had major problems with Ubnt WiFi, that would definitely help my case when pushing to use Cambium WiFi.
However, I don’t have problems with it. We have had several customers for several years with several generations of gear. I’d like to know - what sort of problems have you seen with Ubnt? If I can match those problems, I could more readily consider Cambium in appropriate circumstances.
1 Like
That list went on for years.
But some of the bigger ones are dealing with interference and density.