Cambium assures us that the Firmware labeled June/July firmware takes care of this.
Still waiting for it.
So no beta firmware yet? If so, i would gladly test it.
Ohh sure @GaryHans … he gets the new firmware.
Mean while I am filling out a bug report for Mikrotik over the new WiFi Wave2 driver. You know… ACv2… in 2022. My XV2-2s are sitting in their boxes, being used as a stand for this Mikrotik Audience.
I was just about to unplug it and go back to my R650 as I can’t stand all these disconnect messages setting of my phone.
Sorry @Springs I thought you preferred to wait for when the 6.4.2 GA build was released but if not, I would be glad to provide the 6.4.2 beta build to you. Just dm me for details.
@GaryHans
You are not wrong.
However… Once the GA is released… I have to start vetting all over again.
That takes time.
And to be frank… It’s time that nobody pays for.
You have to “look down the road” to see a return on that.
To be completely honest… I am not in the habit of keeping hardware on my bench for 6 months. Even at NFR pricing… It’s still money spent that has yet to return a single dollar.
So occasionally… My less than charming demeanor… may rear it’s head. I apologize for that
@Springs I completely understand and appreciate your patience. I will let you know once we have the 6.4.2 GA release available.
I also responded to a Facebook thread about this issue several weeks back, in which I took an interest after hearing about this, but discovered that I was unable to reproduce the problem. Returning to this thread and seeing the latest responses, I found and appreciated the additional details provided within the DNS test results that @uberdome posted.
Of course, as has already been said, questions still remain. One big question to me is actually not even on the Cambium side, but the Roku one: to this day, Roku does not support IPv6. So…how is it possible that any Roku apps are making DNS queries for AAAA records in the first place?
@GaryHans are you able to explain in detail the exact root cause of the bug, and steps one could take in order to be able to reliably reproduce it? Under what specific circumstances would an e-series Pilot running 6.x firmware drop quad-A DNS queries? Also, how is it even possible that an access point that is simply bridging traffic is seemingly filtering out certain kinds of traffic? How does a bug like this even happen in the first place??
Thanks, all.
2 Likes
@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.