dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
957
share rss forum feed

nranieri

join:2005-01-03
Massapequa, NY

Help with "stale"clients on mtk

Click for full size
Click for full size
We have been finding this more and more often lately. Clients that attach to our hotspot and cause the interface to stop transmitting. Usually they have very low signal levels, but that is not always the case. The client has a last activity that climbs until the client is disco'd. Usually that will bring the interface back immediately, but will sometimes have to dis-enable it to get it back. It has become a large part of my job to chase these clients down and build access lists to keep them off, as our resort market turns over every week.

Mikrotik has been no help. Have sent them several supout files and they have nothing.

Would appreciate any help.


John Galt
Forward, March
Premium
join:2004-09-30
Happy Camp
kudos:8
What is your client lease time set at?

nranieri

join:2005-01-03
Massapequa, NY
Lease time? DHCP assigned IP lease time? 7 days.


John Galt
Forward, March
Premium
join:2004-09-30
Happy Camp
kudos:8
I'd shorten that up...especially if you have a lot of turnover.

nranieri

join:2005-01-03
Massapequa, NY
Sorry, maybe I am missing something obvious, but what would DHCP lease times have to do with this? The problem will happen if the client in question is connected for just a few seconds. They will remain there til I find them, but the interface will stop forwarding almost immediately.


Inssomniak
The Glitch
Premium
join:2005-04-06
Cayuga, ON
kudos:2
reply to nranieri
My guess is the interface doesnt stop transmitting, but just transmits so slow that it looks like it stops.

You can create an access list rule to not allow such bad signals.
You can also get rid of some of the slow rates like 1,2,5.5

Ive been using Mikrotik for ever and have never seen a client get stale like that before. Hmm..
--
OptionsDSL Wireless Internet
»www.optionsdsl.ca


John Galt
Forward, March
Premium
join:2004-09-30
Happy Camp
kudos:8
reply to nranieri
said by nranieri:

Sorry, maybe I am missing something obvious, but what would DHCP lease times have to do with this? The problem will happen if the client in question is connected for just a few seconds. They will remain there til I find them, but the interface will stop forwarding almost immediately.

Maybe nothing, but, curiously, I have a friend that notice similar behavior on one of his hotspots...this just happened last week.

He has a newly installed hotspot overlooking a small city park (one square block) using a UniFi radio. He noticed that after a while new customers would connect, but not authenticate and pass traffic to the internet.

He gets a lot of client churn, maybe 40-60 unique clients per day at this location.

We looked at -all- of the configuration items at length. The only thing that we noticed was that the lease time was set to one week.
Since most visits are only in the one hour or less range we set the lease time to one hour.

That seems to have solved the problem, such as it is. I am not sure what the underlying issue is, as this falls outside of my area of expertise. That being said, I won't let that stop me from making a wild guess as to what I think is happening.

Please excuse my 'mechanistic' approach to describing the problem...

The AP is like a building on a city street. At the door is a doorman that lets you in if you qualify (you're an 802.11 packet). You enter into the holding area (connected but not authenticated). You go up to the turnstile where you wait to be authorized to join the party (pass traffic). The party is musical chairs, and there are only so many chairs available (DHCP allocations). You have to wait at the turnstile until a seat is available. The turnstile attendant checks the tickets of the players every "lease period", in your case every week, to look for players who's lease has expired, removes those players and lets another new player in the turnstile to take a chair (allocates a DHCP slot and issues an IP address).

Since the lease period is one week, the system does not process that lease expiry until the time period is up. Consequently, there can be no issuance of new leases until slots are available. The pending connection sits and waits.

In most instances in typical WISP operation, you may not see the full utilization of the DHCP table as most clients stay connected on a typical POP. When an AP is used in hotspot service, however, there is a lot of client churn, and the table might be filled to capacity. There may be a structural programming design implementation limitation (or bug!) in the firmware that does not adequately address the full DHCP table issue. I would imagine that there are a number of different ways to handle it programming-wise, some good and others not-so-good.

Don't know...! Again, this falls outside of my area of expertise. I simply regard it as a 'black box' where things happen and I can't see what is happening.

Getting back to our particular experience...when we reset the DHCP lease time to one hour, the problem seemingly resolved itself. From that, I'd suspect that when the leases are forced and renewed at the end of the DHCP lease set time, it boots the unconnected stations off the list and issues new leases and connects. The housekeeping is done and there are always DHCP lease allocations available.

There is a point at which the lease time is too short and causes issues, but in this venue I think that one hour is reasonable based on the expected client connect times.

We are keeping an eye on the AP and this weekend might be a good time to see heavy loading...weather permitting for a trip to the park on Labor Day.

At any rate, that is why I suggested shortening the lease time.

Inssomniak See Profile's suggestion of limiting the rates and enforcing minimum signal levels would be beneficial also. I don't believe in setting up APs to be "alligator stations"...all mouth and no ears. The transmit power should be set to be equal to the APs ability to hear those clients. Utilizing a lower output power causes the clients to move into the service area where the AP can adequately hear the client, and this eliminates much of the 'thrash and bash' as the weak clients trying to negotiate a session with the AP.
--
The most powerful weapon in the world is ignorance. Politicians exploit it to achieve almost anything they want.


nranieri

join:2005-01-03
Massapequa, NY
Thanks, but it is not an IP issue. The interface actually stops. If there is a WDS link on the interface, the far side is offline til the offending client is disco'd.

I have been able to send a client to the ACL and bring the interface back immediately and then disable the ACL entry and have the interface stop again in seconds. It is not an IP issue.

It is relatively new this year, saw it maybe a handful of times last season, but something else changed this year and chasing these clients to ACLs has become a major part of my routine every week now.

It is costing us both money and reputation. And my sanity.


Inssomniak
The Glitch
Premium
join:2005-04-06
Cayuga, ON
kudos:2
How come you are using WDS on a hotspot?

LLigetfa

join:2006-05-15
Fort Frances, ON
kudos:1
reply to nranieri
Years ago at home, my wife had a laptop that would stop my AP but it wasn't an issue with weak RSSI but a driver issue. Upgrading the driver solved it.

On my hotspot at work, I have a dozen APs around the plant for service reps, contractors, etc. and one of my APs frequently stops whenever a particular rep is in town. The other reps noticed the correlation and I just have them power cycle the AP if'n they cannot get on. The hotspot is just a courtesy with no SLA and there is no revenue from it, therefore there is not much incentive for me to do much about it.

My current APs don't support rejecting weak clients but I am considering forklifting them for ones that do. I read that UBNT now supports the feature but I also read that clients can still walk away from an AP and their RSSI degrade. I'm curious about Inssomniak's suggestion and wonder how well that works on 'Tik.
--
Strange as it seems, no amount of learning can cure stupidity, and formal education positively fortifies it. -- Stephen Vizinczey

nranieri

join:2005-01-03
Massapequa, NY
reply to Inssomniak
Not all of our bh links have migrated to 5ghz yet, so some of our user radios feed other routers. That does not appear to have any bearing on this, see the problem on interfaces that are client only and serve WDS.

jcremin

join:2009-12-22
Siren, WI
kudos:3
reply to nranieri
I've seen the same sort of issue on my network on occasion. In my case, they are RB411A's with an XR9 connected to sectors. The clients are RB411/XR9/Rootenna combination.

Every once in awhile, I'll start getting calls and I'll find out that I can't even mac-ping any of the clients (making this a layer 2 problem). Disabling and re-enabling the card fixes it right away.

Once I started watching closely, it turns out that it happens much more often with a single client. The single client will not be able to communicate, even though most of the other clients are fine. Disconnecting them causes them to re-associate and everything is just fine.

I can't seem to do anything to reproduce the issue, and I don't see anything that leads me to believe it is necessarily related to noise. I can only assume that it might have something to do with RouterOS v5 because I don't believe I've ever seen the issue on v4.


John Galt
Forward, March
Premium
join:2004-09-30
Happy Camp
kudos:8
reply to nranieri
What version of the firmware are you using?


Inssomniak
The Glitch
Premium
join:2005-04-06
Cayuga, ON
kudos:2
said by John Galt:

What version of the firmware are you using?

From the images, 5.18, with 5.20 being the latest.
--
OptionsDSL Wireless Internet
»www.optionsdsl.ca

LLigetfa

join:2006-05-15
Fort Frances, ON
kudos:1
reply to nranieri
said by nranieri:

Not all of our bh links have migrated to 5ghz yet, so some of our user radios feed other routers. That does not appear to have any bearing on this, see the problem on interfaces that are client only and serve WDS.

Lemme see if I understand... You have an AP that you use to backhaul other POPs and you let uncontrolled mobile clients to connect to it as a hotspot? I call that self-inflicted pain.
--
Strange as it seems, no amount of learning can cure stupidity, and formal education positively fortifies it. -- Stephen Vizinczey


Inssomniak
The Glitch
Premium
join:2005-04-06
Cayuga, ON
kudos:2
said by LLigetfa:

said by nranieri:

Not all of our bh links have migrated to 5ghz yet, so some of our user radios feed other routers. That does not appear to have any bearing on this, see the problem on interfaces that are client only and serve WDS.

Lemme see if I understand... You have an AP that you use to backhaul other POPs and you let uncontrolled mobile client to connect to it as a hotspot? I call that self-inflicted pain.

I do too, but I wasnt gonna say anything.
--
OptionsDSL Wireless Internet
»www.optionsdsl.ca

nranieri

join:2005-01-03
Massapequa, NY
reply to LLigetfa
Yes, as I said, we have not upgraded all bh links to 5ghz yet. It is under way. But as I mentioned that is unrelated to the issue here, which happens to interfaces that do not have WDS links on them as well as those that do.


Inssomniak
The Glitch
Premium
join:2005-04-06
Cayuga, ON
kudos:2
I think you might have to take it up with Mikrotik, there are patch things you could do, like write a script to see these stale clients, add them to the list automatically. Have you tried on the Mikrotik forums?
--
OptionsDSL Wireless Internet
»www.optionsdsl.ca