Community discussions

MikroTik App
 
toxicfusion
Member Candidate
Member Candidate
Topic Author
Posts: 267
Joined: Mon Jan 14, 2013 6:02 pm

Devices unable to connect - client facing

Tue Aug 03, 2021 4:35 am

Hello,

One of my clients has reached out to me regarding my networks & MikroTik Wifi deployment. For starters, I am US based IT consultant and I've deployed quite a few MikroTik CAPsMan deployments with great success...

However, this client has a restaurant in Rural area with no cellular coverage. The guest that come for dinner apparently demand free wifi.... I'm using the same rate-configuration for them as I am other clients.

Their complaint is "Some guests unable to connect to our Guest wifi, it is impacting our business". My first knee-jerk reaction is calling bullshit, as I see bunch of registered devices on guest-wifi along with their staff. If was Wireless issue, their staff network handhelds would have issues.

Could you review my rates configuration and any suggestions. Perhaps I am at fault and my configuration is the cause?

I've went and disabled my access-list rules for giggles...

I also rolled back my channel configurations on 2 & 5Ghz.

Prior I had 2Ghz configured for 2-Ghz; only-n. 5Ghz- onlyac....

See screenshots:
You do not have the required permissions to view the files attached to this post.
Last edited by toxicfusion on Tue Aug 03, 2021 6:49 am, edited 1 time in total.
 
biomesh
Long time Member
Long time Member
Posts: 561
Joined: Fri Feb 10, 2012 8:25 pm

Re: Devices unable to connect - client facing

Tue Aug 03, 2021 5:06 am

Could it be your basic rates? Perhaps they can't connect at the basic rates for association. Do you have logs perhaps?

If you don't set rates at all (and use the built in rates) does that make a difference?
 
toxicfusion
Member Candidate
Member Candidate
Topic Author
Posts: 267
Joined: Mon Jan 14, 2013 6:02 pm

Re: Devices unable to connect - client facing

Tue Aug 03, 2021 6:53 am

Could it be your basic rates? Perhaps they can't connect at the basic rates for association. Do you have logs perhaps?

If you don't set rates at all (and use the built in rates) does that make a difference?
It very well could be my rates, hence me looking for input on what I had set. I could go all defaults and let it ride out that way? I was under impression we can force and set our rates in caps man and this can aid with client devices making better roaming decisions. IE: have 12Mbps basic-rate - that way Devices forced to connect to closer access point. My supported-rates all included 6Mbps - which is required for phone devices to stay connected when idle in peoples pockets?

Or perhaps my knowledge is bunk, hence me seeking some advice :)
 
User avatar
bpwl
Forum Guru
Forum Guru
Posts: 2978
Joined: Mon Apr 08, 2019 1:16 am

Re: Devices unable to connect - client facing

Tue Aug 03, 2021 12:23 pm

Hi, let me comment on this setup. I'm just also trying to have my setups perform at best, and most is learned from theory and then tested with lots of trial and error. None of my settings are fully backed up with theoretical explanations but are always evolving as I get more experiences in. My backhaul is 4G in France, good and fast, but sometimes fully overloaded and even out for days. This makes the users go experimenting , like resetting AP's and even unplugging them (and putting them back in a non-PoE port). This gives me AP tests with reduced coverage that I wouldn't dare as experiment on innocent users.

As you know , i use no CAPsMAN.

Screenshot 1:

I'm missing CCQ as information. Sometimes the signal strength is OK, but with a very poor CCQ. (And it is not always because you pass a wall).
Signal strength looks good, the low 6Mbps/6.5Mbps rates are from devices which had no traffic yet.
Uptimes are rather short, but even then most volumes are much lower than expected.
No "sleeping" smartphones? You need "last activity" as column. That time will go up to 10 sec and then reset. (That's why in my access-list "allowed out of range" > 10 sec)

Screenshot 2:

The cable plugging user allowed me to finetune the access-list values when there was poor coverage.
My basic setting with tipping point at -86dBm for 2.4GHz , and -83 dBm for 5 GHz has been adjusted FOR MY SETUP to -83 and -80, to make roaming more effective.
All power at the legal max value for ETSI. More than 50% of the devices select 5GHz. Only a seldom device flaps between 2.4 and 5 GHz.
(The 100+ devices are iphone, iPAD, Galaxy tablets, en a laptop here and there. I have no control as users bring them and stay for some days only)
Rising the basic rate reduces the number of access-list initial rejects, but is not very efficiënt in doing that. My hope was to use high basic rate only, but that didn't work out as expected.

Screenshot 3:

Basic rates
12 Mbps as basic rate is the highest value I use. (Coming from 9 Mbps for several test months). No complains so far. (But I have no personal contact with the users, I only see that the same devices reconnect as before)

Supported rates
I would not use that 11 Mbps b-rate. There should be no 802.11b.
I do follow some recommendation of someone's presentation (I forgot who) to allow lower rates than basic rates as supported. The rate will temporarily drop due to a failed packet transmission, and I do not want to drop that connection, if it is only a glitch. At the end, at beacon time, the higher basic rate will cause "no beacon received". So I support ALL low rates.
Removing lower supported rates is a common practice in this forum. You want devices to use higher rates, OK, but forbidding the use of lower rates, is not the good answer to this in my opinion.
There are no access-lists to disconnect on lower rates, (and we know MT has no "airtime fairness" to mitigate the airtime consumption of those unwanted connections)
We only have signal strength .... which leads to SNR ... which leads to failed packets ... which leads to CCQ ... which leads to lower interface rates.
Dropping lower rates would be OK, if one had some "rate out of range" timeout.

HT basic MCS
This is very strict. MCS3 is 26-29Mbps ! This is a very high value. To be in line with the other basic rate limit, MCS1 (13-14.4) and MCS2 (19.5-21.7) should be allowed.
And there is nothing wrong with accepting MCS6 and MCS7.
Is basic rate only used in single stream? It looks like it is the case. (So HT MCS8 and up are not used)

HT supported rates
Same story as before. Support them all. You do not want those disconnects if it drops below 26Mbps for 802.11n just once.

VHT rates
802.11ac has taken away the discretionary rate accept/deny. So this is OK for 802.11ac. Not many of your clients go on 802.11ac however.

My experience only. YMMV.
 
toxicfusion
Member Candidate
Member Candidate
Topic Author
Posts: 267
Joined: Mon Jan 14, 2013 6:02 pm

Re: Devices unable to connect - client facing

Tue Aug 03, 2021 2:16 pm

In curious for anyone who’s running capsman in a business environment if they could pot screenshot of their configured rates.

Why is this a big secret in MikroTik community. For some people to not post their known good working setups?

There is ALOT of information on there on ways to configure capsman and some so called “best practices”. Quite a few docs from MUM meetings and such; but appears majority of it is all theoretical setup and when we deploy in real life with users and client devices - there are issues.

Or again, my configured rates are needing tweaking and I am wrong for my rates and perhaps missing some VHT MCS?

I know on NON capsman controlled access points. The MikroTik default rates have everything checked. 1Mbps basic rate all way up, etc.
 
User avatar
bpwl
Forum Guru
Forum Guru
Posts: 2978
Joined: Mon Apr 08, 2019 1:16 am

Re: Devices unable to connect - client facing

Tue Aug 03, 2021 2:50 pm


I know on NON capsman controlled access points. The MikroTik default rates have everything checked. 1Mbps basic rate all way up, etc.
MT does something very strange to this supported rate setting .... 5GHz-only-ac is down to 1 Mbps, 5GHz-N/AC starts from 6 Mbps. It's in the wiki also.
If you set it to default, the previous set values are there, but grayed out. What of these settings is used? No idea!
Starting from 6Mbps is what I want, not the typical 1 Mbps B-rate. 1 Mbps fills my channel with beacon air-time!
And MT does not give the CCA results, so the real time channel busy level for the channel used is unknown. Other brands even redistribute that information in their beacon.
This "could" help the client device to select the better AP.
 
toxicfusion
Member Candidate
Member Candidate
Topic Author
Posts: 267
Joined: Mon Jan 14, 2013 6:02 pm

Re: Devices unable to connect - client facing

Tue Aug 03, 2021 3:42 pm

@bpwl - Interesting tips! I did NOT know that the MT 5Ghz-only-ac is down to 1Mbps!! Do you happen to have that wiki link? I'm curious of that read.

I've now went and swapped back my caps configuration to be 2Ghz-g/n [previous was 2Ghz-only-n] and changed to 5Ghz-n/ac [prior 5Ghz-only-ac].

Also keeping basic rate to 6Mbps, and then support-rates from 6Mbps, 9Mbps,12Mbps - 54Mbps....

Do my rates look ok for general devices in wild to connect? I understand peoples configurations will vary! Some will be doing PtMP / PtP links and need very specific Basic and supported-rates between THEIR radio's! Different animal.

Mainly looking for the typical consumer configuration where all we care about is device connectivity. wheeee!
You do not have the required permissions to view the files attached to this post.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Devices unable to connect - client facing

Tue Aug 03, 2021 6:25 pm

Rural area = older phones and setting the basic rate down to 6 as you have may help. I dont thing you will need to reduce 2ghz to b/g/n but I would certainly use G/N
For 5ghz I used to have to use A/N for older products but moved up to N/AC also I stick with 20/40 Ce channel width.
 
User avatar
bpwl
Forum Guru
Forum Guru
Posts: 2978
Joined: Mon Apr 08, 2019 1:16 am

Re: Devices unable to connect - client facing

Tue Aug 03, 2021 6:57 pm

Do you happen to have that wiki link? I'm curious of that read.
Oooops wifi page is updated. (There should be screenshots of the old info in one of my answers somewhere in the forum)

5GHz-n/ac seems even gone now. https://wiki.mikrotik.com/wiki/Manual:I ... e/Wireless

They must have updated the ROS and wiki some time ago. But from what version?
I'm afraid the only sure way to find out, is decoding the beacon
 
toxicfusion
Member Candidate
Member Candidate
Topic Author
Posts: 267
Joined: Mon Jan 14, 2013 6:02 pm

Re: Devices unable to connect - client facing

Tue Aug 03, 2021 7:14 pm

Rural area = older phones and setting the basic rate down to 6 as you have may help. I dont thing you will need to reduce 2ghz to b/g/n but I would certainly use G/N
For 5ghz I used to have to use A/N for older products but moved up to N/AC also I stick with 20/40 Ce channel width.
Great suggestion and tip. I was naive with my mindset thinking. My logic was majority of people with cell phones that use guest wifi in public settings will have more current devices which would support 2Ghz-N-only and 5-Ghz-Ac.

Interesting that you stick to 20/40 Ce channel-width. All for compatibility reasons I suspect? I've been rolling with 20Mhz control-width with Ceee/eeeC [20/40/80].

Attaching my revised rate-configuration for this deployment. I'll let it ride for a day or two before turning back on my access-list rules

Revised the following -
set basic-rates to be 6Mbps.
set support-rates to be 6mbps, 9Mbps, 12-54Mbps

adjusted HT-Basic-MCS to be 1-7
adjusted HT-Supported-MCS to be ALL

VHT-Supported-MCS -- set to MT Defaults [should be all avail].
You do not have the required permissions to view the files attached to this post.
 
biomesh
Long time Member
Long time Member
Posts: 561
Joined: Fri Feb 10, 2012 8:25 pm

Re: Devices unable to connect - client facing

Tue Aug 03, 2021 10:58 pm

Just FYI, I used your most current rate settings and I had a few devices that would not connect (via capsman)- in my case these were amazon echo devices(different models). Going back to the built in rate settings allowed the devices to connect.

Just providing some feedback.
 
toxicfusion
Member Candidate
Member Candidate
Topic Author
Posts: 267
Joined: Mon Jan 14, 2013 6:02 pm

Re: Devices unable to connect - client facing

Wed Aug 04, 2021 2:52 am

Just FYI, I used your most current rate settings and I had a few devices that would not connect (via capsman)- in my case these were amazon echo devices(different models). Going back to the built in rate settings allowed the devices to connect.

Just providing some feedback.

Thank you for that feedback! Greatly appreciated.

Perhaps in this situation where my client is already upset over WiFi connectivity issues - or that some guests are making complaints. I can just “keep it simple” and use MT defaults!

Question: what 2Ghz and 5Ghz channel settings Did you have applied?

I’m curious for others running Capsman deployments in the wild for business environments what their rate configuration is. Seems like a big hush hush secret
 
biomesh
Long time Member
Long time Member
Posts: 561
Joined: Fri Feb 10, 2012 8:25 pm

Re: Devices unable to connect - client facing

Wed Aug 04, 2021 4:06 am

I use 40mhz channels for 5Ghz and 20mhz channels for 2.4Ghz. I have cap ac devices. Power is 10 for 2.4 and 22 for 5. I don't have 2.4 enabled on all aps. Hardware supported modes for 2.4 is gn and for 5 ac.

If you want an export I can get this tomorrow.

I have never customized the rates untill I did this testing for you. I never had a device not be able to connect. I think some devices are very quirky and any customization could break these devices.
 
toxicfusion
Member Candidate
Member Candidate
Topic Author
Posts: 267
Joined: Mon Jan 14, 2013 6:02 pm

Re: Devices unable to connect - client facing

Wed Aug 04, 2021 4:23 pm

@Biomesh - if you'd like to post your config export - go ahead. I wouldnt mind taking a look.

It's just odd, considering i've had this same rate configuration for two other locations. Actually two businesses right down road from one another lol..

This restaurant is not a busy as some of my other clients. But I've seen over 20+ guests connected to the guest SSID at one point, I know it was working; so I didnt question it. Myself and others never had difficulty connecting when I was on-site doing site survey and testing after the deployment.... Also all the staff & point of sale handhelds connected fine.

I believe it was just a few customers who made noise not being able to connect. I've went ahead and made further configuration and am now using the MikroTik default rates.
You do not have the required permissions to view the files attached to this post.
 
biomesh
Long time Member
Long time Member
Posts: 561
Joined: Fri Feb 10, 2012 8:25 pm

Re: Devices unable to connect - client facing  [SOLVED]

Wed Aug 04, 2021 9:25 pm

You don't even need to have a rates entry - it will use the defaults if none are defined.
/caps-man channel
add band=2ghz-onlyn control-channel-width=20mhz extension-channel=disabled \
    frequency=2412 name=2ch1 tx-power=10
add band=2ghz-onlyn control-channel-width=20mhz extension-channel=disabled \
    frequency=2437 name=2ch6 tx-power=10
add band=2ghz-onlyn control-channel-width=20mhz extension-channel=disabled \
    frequency=2462 name=2ch11 tx-power=10
add band=2ghz-onlyn control-channel-width=20mhz extension-channel=disabled \
    frequency=2412,2462,2437 name=2G tx-power=8
add band=5ghz-n/ac control-channel-width=20mhz extension-channel=Ce \
    frequency=5180 name=5-40-ch36 tx-power=22
add band=5ghz-n/ac control-channel-width=20mhz extension-channel=Ce \
    frequency=5220 name=5-40-ch44 tx-power=22
add band=5ghz-n/ac control-channel-width=20mhz extension-channel=Ce \
    frequency=5745 name=5-40-ch149 tx-power=22
add band=5ghz-n/ac control-channel-width=20mhz extension-channel=Ce \
    frequency=5785 name=5-40-ch157 tx-power=22

/caps-man datapath
add client-to-client-forwarding=yes local-forwarding=yes name=vlan vlan-id=\
    1500 vlan-mode=use-tag
	
/caps-man security
add authentication-types=wpa2-psk encryption=aes-ccm group-encryption=aes-ccm \
    group-key-update=1d name=wpa2psk passphrase=XXXXXXXXX
	
/caps-man configuration
add channel=2ch11 country="united states3" datapath=vlan keepalive-frames=\
    enabled mode=ap name=myssid-iot-11 security=wpa2psk ssid=myssid-iot
add channel=2ch1 country="united states3" datapath=vlan keepalive-frames=\
    enabled mode=ap name=myssid-iot-1 security=wpa2psk ssid=myssid-iot
add channel=2ch6 country="united states3" datapath=vlan keepalive-frames=\
    enabled mode=ap name=myssid-iot-6 security=wpa2psk ssid=myssid-iot
add channel=2G country="united states3" datapath=vlan keepalive-frames=\
    enabled mode=ap name=myssid-iot security=wpa2psk ssid=myssid-iot
add channel=5-40-ch44 country="united states3" datapath=vlan \
    keepalive-frames=enabled mode=ap name=myssid-44 security=wpa2psk ssid=\
    myssid
add channel=5-40-ch36 country="united states3" datapath=vlan \
    keepalive-frames=enabled mode=ap name=myssid-36 security=wpa2psk ssid=\
    myssid
add channel=5-40-ch157 country="united states3" datapath=vlan \
    keepalive-frames=enabled mode=ap name=myssid-157 security=wpa2psk ssid=\
    myssid
add channel=5-40-ch149 country="united states3" datapath=vlan \
    keepalive-frames=enabled mode=ap name=myssid-149 security=wpa2psk ssid=\
    myssid

/caps-man provisioning
add action=create-enabled comment=ABC-2.4 hw-supported-modes=gn \
    identity-regexp=ABC-AP master-configuration=myssid-iot-1 name-format=\
    prefix-identity name-prefix=2
add action=create-enabled comment=ABC-5 hw-supported-modes=ac identity-regexp=\
    ABC-AP master-configuration=myssid-36 name-format=prefix-identity \
    name-prefix=5
add action=create-enabled comment=Upstairs-2 hw-supported-modes=gn \
    identity-regexp=Upstairs-AP master-configuration=myssid-iot-11 \
    name-format=prefix-identity name-prefix=2
add action=create-enabled comment=Upstairs-5 hw-supported-modes=ac \
    identity-regexp=Upstairs-AP master-configuration=myssid-157 name-format=\
    prefix-identity name-prefix=5
add action=create-disabled comment=Kitchen-2 hw-supported-modes=gn \
    identity-regexp=Kitchen-AP master-configuration=myssid-iot name-format=\
    prefix-identity name-prefix=2
add action=create-enabled comment=Kitchen-5 hw-supported-modes=ac \
    identity-regexp=Kitchen-AP master-configuration=myssid-44 name-format=\
    prefix-identity name-prefix=5
add action=create-enabled comment=Bedrooom-5 hw-supported-modes=ac \
    identity-regexp=Bedroom-AP master-configuration=myssid-36 name-format=\
    prefix-identity name-prefix=5 slave-configurations=myssid-ext
add action=create-enabled comment=Bedroom-2 hw-supported-modes=gn \
    identity-regexp=Bedroom-AP master-configuration=myssid-iot-1 name-format=\
    prefix-identity name-prefix=2
add action=create-enabled comment=Office-5 hw-supported-modes=ac \
    identity-regexp=Office-AP master-configuration=myssid-149 name-format=\
    prefix-identity name-prefix=5
add action=create-enabled comment=Office-2 hw-supported-modes=gn \
    identity-regexp=Office-AP master-configuration=myssid-iot-11 name-format=\
    prefix-identity name-prefix=2
add action=create-enabled comment=XYZ-2 hw-supported-modes=gn \
    identity-regexp=XYZ-AP master-configuration=myssid-iot-6 name-format=\
    prefix-identity name-prefix=2
add action=create-enabled comment=XYZ-5 hw-supported-modes=ac \
    identity-regexp=XYZ-AP master-configuration=myssid-44 name-format=\
    prefix-identity name-prefix=5

 
gotsprings
Forum Guru
Forum Guru
Posts: 2087
Joined: Mon May 14, 2012 9:30 pm

Re: Devices unable to connect - client facing

Thu Aug 05, 2021 1:58 am

Wrong f--king tool for the job.

I love caps man... But Mikrotik's radios are not worth your time.

If you are trying to put 20 or more devices on the 2.4 in a small area... You are gonna watch the Mikrotik wireless crumble.

I have seen the 2.4 just stop passing traffic too many times. Once it gets overloaded... It can't deal.

Mikrotik wifi has been relegated to LOW SPEED, LOW DENSITY INSTALLS. Certainly never for public wifi in any of the commerical system I have built. Learned the hard way and not making that mistake anymore.

I have no problem routing 600 devices with a RG750g as the router. But I absolutely have to use someone else's wifi.
 
toxicfusion
Member Candidate
Member Candidate
Topic Author
Posts: 267
Joined: Mon Jan 14, 2013 6:02 pm

Re: Devices unable to connect - client facing

Thu Aug 05, 2021 4:20 am

Wrong f--king tool for the job.

I love caps man... But Mikrotik's radios are not worth your time.

If you are trying to put 20 or more devices on the 2.4 in a small area... You are gonna watch the Mikrotik wireless crumble.

I have seen the 2.4 just stop passing traffic too many times. Once it gets overloaded... It can't deal.

Mikrotik wifi has been relegated to LOW SPEED, LOW DENSITY INSTALLS. Certainly never for public wifi in any of the commerical system I have built. Learned the hard way and not making that mistake anymore.

I have no problem routing 600 devices with a RG750g as the router. But I absolutely have to use someone else's wifi.
Please dont spread misinformation on MikroTik wifi.... Did you not read my entire thread? It was not issue of density nor coverage nor speeds.... none of that. It was an issue with SOME GUESTS complaining they cant connect to guest wifi network at one of my customer sites....

CapsMan DOES work well and MikroTik wAP AC and cAP Ac, NetMetal AC2 all work great....

Issue was more or less self-induced due to my rate configuration. Since defaulting back to MikroTik default rates, I am seeing more devices connected to this customers guest wifi network. More than I usually see for their evening dinner service [restaurant]..
 
gotsprings
Forum Guru
Forum Guru
Posts: 2087
Joined: Mon May 14, 2012 9:30 pm

Re: Devices unable to connect - client facing

Thu Aug 05, 2021 4:48 am

Misinformation?

(Guessing that was translation issue there)

Not one statement in that post was "misinformation".

When months of back and forth was finally punctuated by Mikrotik staff stating that the problems I was seeing were not something Mikrotik could mitigate...

I dug deep accepted I had made wooper f--king mistake and abandoned tons of custom programing I wrote around Caps.

I had to PAY OUT OF MY OWN POCKET to replace a lot of caps.

And suddenly... My systems all worked like they did before I fell into the trap of thinking RouterOS translated in anyway to wireless performance.

My dinner service was at the bar next to capital one when the Caps one the Stanley Cup. My wifi carried 512 guests and the normal wifi + the point of sales and arcade systems. I had limited that subnet to 512 due to my wan speed vs the amount of access points + my airspace.

When the world series was played in DC... The broadcast truck had run out of satellite time... Guess who's bar next door they had to use for the live broadcast right out front of the stadium???

Don't piss on my shoes.
 
toxicfusion
Member Candidate
Member Candidate
Topic Author
Posts: 267
Joined: Mon Jan 14, 2013 6:02 pm

Re: Devices unable to connect - client facing

Thu Aug 05, 2021 6:51 am

Was not a translation issue. This is not a pissing contest.

I realize and I'm aware of MikroTik wireless weaknesses, and know there are better wireless products/solutions out there. Not one size fits all!

Cannot make assumption that MikroTik Wireless products [yet] can support said large venues or enterprise networks. Not going to happen. I know better. I use MikroTik for small business environments... 20-100 users.

Anything large scale or venues. Aruba, Ruckus, AeroHive [now extreme networks. :)]

Again - it's about knowing what MikroTik products & hardware are designed FOR and which market niche they fill and suite... They're not marketed toward the environment you deployed into; hence your bad experience and taking a huge $$ loss. Which AP's were you using anyways? NetMetal AC2? MikroTik always requires more AP's than other products, they also mention "placement is key".

Once MikroTik releases newer wifi gear -- CAPsMAN will wipe the floor with its feature set and price point.... Always be mindful of price point and target market.
 
gotsprings
Forum Guru
Forum Guru
Posts: 2087
Joined: Mon May 14, 2012 9:30 pm

Re: Devices unable to connect - client facing

Thu Aug 05, 2021 12:28 pm

The one thing we seem to agree on.

"If caps-man could control a good radio... It would be awesome!"

What you don't seem to want to spell out... "Mikrotik doesn't make a radio" for caps-man.

The lack of MU-MIMO in 2021 is just too much to over come. It's in the development branch right now. Everyone else is in WiFi6 and Mikrotik doesn't fully support WiFi5.

As for placement... Right out in the open with less than 20 feet to any client, and I have seen the 2.4 radio just not accept clients. In a home... Where it needed to carry 4 things. Until I cycled just the 2.4 radio. I had to set up a netwatch to figure out when the printer dropped offline. That was the cue that everything else on 2.4 would now also be unable to connect. The netwatch would tell caps-man to disable the 2.4 radio on cap AC in that room. Wait 5 seconds and bring it back. That got everything to connect every single time we tried it.

Problem being if the customer needed it to work during those drops.

And why did it not work... Because it was in a newer community and there are just too many nearby WAPs.

I have seen one radio (model doesn't matter) fail to carry 2 devices on 2.4. why? Because it was right on main street in an apartment over a bar. Sure it worked Monday to Thursday. But when they brought out the street vendors each week... A URC remote couldn't be carried at a distance of 9 feet. $245 of my own money got a Ruckus R510 into the exact same spot. The complaints stopped instantly.

So as stated before...
We will still use caps-man IF.
1. You have a slow internet connection to begin with. As the throughput falls off quick with only a few clients.
2. You are not trying to carry a whole bunch of clients. So people who fill up their homes with IOT gear or have a bunch of wireless devices... They are not gonna be happy either.
3. Are in the middle of nowhere. As we know that Mikrotik radios don't deal well with interference... If you have a lot of nearby WAPs we can't control... The Mikrotik wireless is going to be really sub par.

hAP, hAP AC, hAP AC2, cap, cap AC, wAP, wAP AC, wAP AC(V2 with the 2 ports), RB2011 with wireless, rb4011 with wireless and the one Audience I bought...

I hardwire it to my network and stick it in the dead center of my house.
It's configured as
2.4 ch 1 20 mhz on the 2x2
5.0 ch 36 80 mhz on the 2x2
5.0/5.8 ch 149 80 mhz on the 4x4

Sitting 15 feet from it... The Tx and Rx errors approach 700Mbps. And sure enough... Connections seem to be limited to about 130Megs at Best.

Flip that to UniF--k , Cambium, or Ruckus... Error rates drop to under 100M and clients tend to see a 3-400 Meg increase in throughput and far better pings. Plus, people stop having to repeat themselves on wifi calling.
You do not have the required permissions to view the files attached to this post.
 
toxicfusion
Member Candidate
Member Candidate
Topic Author
Posts: 267
Joined: Mon Jan 14, 2013 6:02 pm

Re: Devices unable to connect - client facing

Thu Aug 05, 2021 4:47 pm

@Gotsprings,

Why using 80Mhz channel-width on 5ghz? What was your CapsMan channel settings and rate settings? Did you make mistake as I did and mistakenly remove rates? Appears leaving MikroTik rates as default and just setting your minimum basic & all supported rates is the key..

I would of suggested you use wAP AC's and NetMetal AC2 with HGO antenna's for outdoor usages. cAP AC for inside. The RB4011 with wireless antenna's had known teething issues when first released and wouldnt suggest it. Better off with regular RB4011 [non-wifi model]. use it as your primary router.

I've not experienced said issues you have. I have a campground deployment of all MikroTik equipment + MikroTik hotspot with userman for voucher creation. Replaced engenius antenna's that use to be in same spots. Better wifi, no more dropped clients, no more restarting locked up engenius antennas...

Ruckus does make great access points. I would use them as well as Cambium for a deployment that supports the wifi6 features and higher associated price tag.

I'm glad you're happy with Ruckus and working well for you! That is all that matters! Again, MikroTik fits a market category for their price point. Always be mindful of that....
 
gotsprings
Forum Guru
Forum Guru
Posts: 2087
Joined: Mon May 14, 2012 9:30 pm

Re: Devices unable to connect - client facing

Sun Aug 08, 2021 2:05 am

After months of one email a week... I finally got the word from Mikrotik. It was my "unique environment" that caused all the problems. Nothing wrong in my configuration. It's purely WHERE I work.

Problem is my "Unique Environment" was present at more than 50 installs.

I learned the hard way the "hard ceiling"... And stay way the hell away from it.
 
nbctcp
Frequent Visitor
Frequent Visitor
Posts: 77
Joined: Tue Sep 16, 2014 7:32 pm

Re: Devices unable to connect - client facing

Thu Dec 02, 2021 2:40 am

I agree with you regarding using other than Mikrotik for AP
I have and ever try most Enterprise class AP out there such as Cisco, Aruba, Ruckus, Cambium, Huawei
I agree as well using Mikrotik as AP because of price tag
In the beginning I am using Mikrotik, TPLink as AP, but because of weak signal, I change all AP to Honor (Huawei cheap brand) Wifi6.
That even cheaper than Mikrotik with stronger signal and longer distance
I use Honor AP as bridge and control network traffic using Mikrotik as gateway

The one thing we seem to agree on.

"If caps-man could control a good radio... It would be awesome!"

What you don't seem to want to spell out... "Mikrotik doesn't make a radio" for caps-man.

The lack of MU-MIMO in 2021 is just too much to over come. It's in the development branch right now. Everyone else is in WiFi6 and Mikrotik doesn't fully support WiFi5.

As for placement... Right out in the open with less than 20 feet to any client, and I have seen the 2.4 radio just not accept clients. In a home... Where it needed to carry 4 things. Until I cycled just the 2.4 radio. I had to set up a netwatch to figure out when the printer dropped offline. That was the cue that everything else on 2.4 would now also be unable to connect. The netwatch would tell caps-man to disable the 2.4 radio on cap AC in that room. Wait 5 seconds and bring it back. That got everything to connect every single time we tried it.

Problem being if the customer needed it to work during those drops.

And why did it not work... Because it was in a newer community and there are just too many nearby WAPs.

I have seen one radio (model doesn't matter) fail to carry 2 devices on 2.4. why? Because it was right on main street in an apartment over a bar. Sure it worked Monday to Thursday. But when they brought out the street vendors each week... A URC remote couldn't be carried at a distance of 9 feet. $245 of my own money got a Ruckus R510 into the exact same spot. The complaints stopped instantly.

So as stated before...
We will still use caps-man IF.
1. You have a slow internet connection to begin with. As the throughput falls off quick with only a few clients.
2. You are not trying to carry a whole bunch of clients. So people who fill up their homes with IOT gear or have a bunch of wireless devices... They are not gonna be happy either.
3. Are in the middle of nowhere. As we know that Mikrotik radios don't deal well with interference... If you have a lot of nearby WAPs we can't control... The Mikrotik wireless is going to be really sub par.

hAP, hAP AC, hAP AC2, cap, cap AC, wAP, wAP AC, wAP AC(V2 with the 2 ports), RB2011 with wireless, rb4011 with wireless and the one Audience I bought...

I hardwire it to my network and stick it in the dead center of my house.
It's configured as
2.4 ch 1 20 mhz on the 2x2
5.0 ch 36 80 mhz on the 2x2
5.0/5.8 ch 149 80 mhz on the 4x4

Sitting 15 feet from it... The Tx and Rx errors approach 700Mbps. And sure enough... Connections seem to be limited to about 130Megs at Best.

Flip that to UniF--k , Cambium, or Ruckus... Error rates drop to under 100M and clients tend to see a 3-400 Meg increase in throughput and far better pings. Plus, people stop having to repeat themselves on wifi calling.

Who is online

Users browsing this forum: Ahrefs [Bot] and 26 guests