We have it deployed on over 200 r195 units. Haven’t had any complaints except for we have seen an instance of high latency on the ethernet that we haven’t been able to explain. We also shut off TXburst on wifi and disable IP conflict detection. Overall seems stable.
Update: 10-18-20
We are testing to resolve this high latency issue. Disabling hardware NAT to see if that resolves.
@anthonyw, thank you for the update. So just to be clear, you have updated to 4.7.1, shut off tx burst on wifi, disabled IP conflict detection and now hardware NAT?
correct, 4.7.1-r4. Now TX and IP conflict = off is a carry over from previous firmware configs. Still testing to see if hardware NAT is causing the latency issue.
Okay I had done the same as you pre 4.7.1-R4, but I tried using all default settings minus tx burst so I may implement disabling IP conflict and hardware NAT, thank you for the feed back
I am not convinced hardware nat on the 195 is an issue. Waiting a couple days to collect data from the effected customer / unit. It is the only one of over 200 that I have a report of this issue. though this is a “super” gamer.
Good information here. I have been reading about the Tx Burst settings, but was waiting for Cambium to decide to bake that setting into a firmware upgrade.
I’m not sure I follow above. Does 4.7.1 change anything with Tx Burst or IP conflict? Or should I only change those settings if I still have issues on 4.7.1?
For the high ping time / packet loss. We had a second instance. At this point it would appear to be failing hardware. Replacement of one of the problem units seems to have resolved the issue.
@anthonyw, can you share how you are configuring these R195 units (Also, confirm they are actually R195W, not R195P)?
We have continued to see issues even on 4.7.1. I wonder how much of our problem might be configuration related when there are still people who don’t seem to have problems at all. There seems to be a mix providers who have tons of problems, and providers who seem to be fine.
I don’t think anyone has R195P’s in hand yet. All of ours are “w”.
No issues is a bit loaded. The coverage of the 195’s is limited and we occasionally have issues where we have to assist customers will properly loading the 195 by splitting devices appropriately to the 5ghz network vs everything on the 2ghz. But I don’t know that it would be different with a comparable product from anyone else. Our biggest “issue” is the failure rate, likely is above 5% and that could be better. Here is our over-rides for settings that we change that are not exposed by cnMestro:
SSID2=${SSID2g=xxxxxxx}
WPAPSK2=${WPA2g=xxxxxxxxx}
RTDEV_SSID1=${SSID5g=xxxxxxxx}
RTDEV_WPAPSK1=${xxxxxxxxx}
TxBurst=0
RTDEV_TxBurst=0
IPConflictDetection=Disable
DMZEnable=${DMZ_enabled=1}
DMZAddress=${DMZ_IP=xxx.xxx.xxx.xxx}
@anthonyw, are you applying these in an AP Group, or with a Template? If it is an AP Group, do you leave the rest of the WiFi settings defaulted or customize any of them?
This would be in an AP group. Other settings as follows:
2.4ghz = Mixed mode, 20/40, short, enable RDG, ext channel 5, enable STBC, disable A-MSDU, enable auto block ack, disable Decline BA request, enable HT, enable 20/40 coexistence, disable HT LDPC.
5ghz = network mode 11vht AC/AN only, Green Field, 20/40, short, enabled RDG, enable STBC, disable, A-MSDU, enable auto block, disable BA Request, enable HT, enable 20/40, disable HT LDPC, VHT = 80, enable VHT STBC, enable VHT Short GI, disable BHT BW signaling, enable VHT LDPC.
After looking at this I am fairly certain I am shooting myself in the leg on a couple of these. But it is what we have set at this point.
Main concept is to have 2ghz be reliable and range, 5ghz = short range and fast with no legacy devices allowed.