Client re-registrations

tjohnson · Fri Jun 27, 2008 11:22 pm

We have about 50 AP's running 3.10. They have several different boards (411, 532, 333) and different wireless cards (SR2, WLM54, SR5). We are running Nstreme, disable CSMA and have them just bridging the ethernet and wireless card. Any AP with more than 30 clients, we see the "uptime" maxed out around 4-5 hours. Any AP's with less than that, sometimes are up for 20-30 days.

Is this a known problem?

tjohnson · Sun Jul 06, 2008 4:45 am

bump.

Any suggestions?

jwcn · Sun Jul 06, 2008 4:54 am

Are you balancing your signal strength? What does your CPU utilization run at?

tjohnson · Sun Jul 06, 2008 5:07 am

Signals are within 2db on each side of each link. CPU is less than 50%.

jwcn · Sun Jul 06, 2008 5:39 am

What is the signal range the AP is picking the customers up at?

tjohnson · Sun Jul 06, 2008 6:43 am

signals range from -63 to -85 across 44 customers.

tjohnson · Sun Jul 27, 2008 7:36 am

I received a response from MT support regarding this issue. They are saying Nstreme was not designed for a lot of client connections and that should be turned off. We are going to try that and see if it helps.

Also, they are considering a new protocol (not Nstreme) to allow more client connections per AP.

We currently have many Trango 2.4ghz AP's with over 120 users connected that work perfectly. Less than 5ms latency. Hopefully Mikrotik can come up with something as good.

0ldman · Sun Jul 27, 2008 6:22 pm

I thought one of the large points of Nstreme was polling in replacement for rts/cts?

tjohnson · Sun Jul 27, 2008 6:58 pm

That's what we thought too... until we got over 600 clients installed and are now seeing problems.

They are saying Nstreme was designed more for point to point connections.

0ldman · Tue Jul 29, 2008 6:04 pm

After reading this again, I have a similar problem. Seems to be corrected by getting the signal in at the AP a bit closer together. My target is to have all signals from -70 to -80. Any time I have a CPE Tx to the AP at worse than -83 or so, all radios drop off randomly. Changed out the CPE, got the signal up, uptime for everyone now is days (or until the power goes out, quite frequently here), where it was previously a few hours tops. I've only got 10 clients here on one omni, Nstreme with CSMA disabled.

kblazk · Mon Aug 25, 2008 7:05 pm

I am having this problem on SEVERAL towers. For no reason at all the interface will decide to dumb all of my Atheros clients. and then within 2 seconds they will all connect back up again. You can tell that it happened because the "uptimes" are so short. Funny thing is that the 1 lone prism client on a tower never re-connects. Take a look at this screen shot i have here.

Tue Aug 26, 2008 4:18 pm

what do you mean by short? 16hours

tjohnson · Tue Aug 26, 2008 5:21 pm

16 hours is short if the AP has been up for days.

We are seeing this same problem. Please fix it.

kblazk · Wed Aug 27, 2008 7:53 am

is this a problem that can be solved be removing all PRISM clients from the AP because at this point I am willing to invest in replacing the old CB3's and CPE-200's

Equis · Wed Aug 27, 2008 1:39 pm

is this a problem that can be solved be removing all PRISM clients from the AP because at this point I am willing to invest in replacing the old CB3's and CPE-200's

No

0ldman · Wed Aug 27, 2008 5:45 pm

is this a problem that can be solved be removing all PRISM clients from the AP because at this point I am willing to invest in replacing the old CB3's and CPE-200's

Just backing up Equis.

No, I have 100% Atheros, 100% MT ROS. Same problem.

rspott · Thu Aug 28, 2008 5:14 pm

Bump,

Let's keep this up top. I _used_ to have this issue, it went away and now it is back.

Now my clients can count on being connected for 35-500 seconds!

All tranzeo CPE. The APs are RB 532/XR2 and RB333/XR2.

ryan

rspott · Thu Aug 28, 2008 8:03 pm

Bump,
Let's keep this up top. I _used_ to have this issue, it went away and now it is back.
Now my clients can count on being connected for 35-500 seconds!
All tranzeo CPE. The APs are RB 532/XR2 and RB333/XR2.
ryan

Let's add some data.

All of the clients seem to disconnect (at the same time) with:

09:04:43 wireless,info 00:60:B3:5E:2D:48@wlan1: disconnected, received disassoc:
 class 3 frame received (7)

When I look here: I find normis's quide http://wiki.mikrotik.com/wiki/Wireless_Debug_Logs
and
http://readlist.com/lists/shmoo.com/hostap/0/386.html
and
http://forum.mikrotik.com/viewtopic.php?f=4&t=4015

So is this an electrical problem? A "sleep" problem? It can't be a Tranzeo issue at this point because they ALL go down at the same time.

kblazk · Fri Aug 29, 2008 12:08 am

someone said in one of the wireless lists that they talked to MT and were told that they (MT) is going to get the 802.11n support added to their software and THEN start working on this problem.

kblazk · Fri Aug 29, 2008 12:13 am

After reading this again, I have a similar problem. Seems to be corrected by getting the signal in at the AP a bit closer together. My target is to have all signals from -70 to -80. Any time I have a CPE Tx to the AP at worse than -83 or so, all radios drop off randomly. Changed out the CPE, got the signal up, uptime for everyone now is days (or until the power goes out, quite frequently here), where it was previously a few hours tops. I've only got 10 clients here on one omni, Nstreme with CSMA disabled.

can anyone confirm that this problem is related to clients that are connected with signals -80 and worse because i have a 3 sector AP and the 1 sector that is dropping off the worse (every 5 minutes) has about 5 clients connected worse than -80 and the other sectors don't.

0ldman · Fri Aug 29, 2008 7:55 am

I'll keep an eye on it on each of my 3 AP's. Two of them don't have many clients, the one serving me has more and it is the one with problems.

kblazk · Fri Aug 29, 2008 8:21 am

Well I don't think that's it either now, I took the poor signal clients out of the access list and it would still drop everyone off every 5 minutes.

I seem to have isolated this problem not to noise but to large amounts of traffic. I can trigger the re-connects by doing BW tests from one of the clients on the problem sector. It will knock them all off every time I do the BW test....

0ldman · Fri Aug 29, 2008 9:33 am

I have noticed that if one client has high traffic, everyone else will reconnect, sometimes the high traffic client does, sometimes not.

I have not had the opportunity to drop the weak clients, but it does seem to happen more often when the weak clients are connected (one guy unplugs his when not in use).

I have noticed that if I ping everyone "-t -l 10000" that they don't drop out for quite some time. I haven't tried that recently, I only had about 6 clients on at the time.

rspott · Tue Sep 02, 2008 7:35 pm

Bump. Is M-tik working on this at all?

Does anyone have an open ticket with case/ticket number we can reference when we open our tickets?

kblazk · Thu Sep 04, 2008 6:00 am

ok I'm on to another hunch here, i wonder if this problem is related to power and voltage? does 12v versus 24v make any difference for anyone?

Reason I ask is because someone stated in another post that once they hit a certain number of clients that they had to use a higher voltage power supply or they would get the re-registrations.

rspott · Thu Sep 04, 2008 6:44 am

[quote="kblazk"]ok I'm on to another hunch here, i wonder if this problem is related to power and voltage? does 12v versus 24v make any difference for anyone?

The site I am on only supports 12VDC.

kblazk · Thu Sep 04, 2008 7:20 am

I will check it on one of my sites here in a few days and report back what I find.

I am in communication with another WISP that is not experiencing these problems and they are all using 24v on their towers and my only towers that are having these problems are run by 12v setup's. I have 1 tower that is not having these problems and it just happens to be 24v... go figure.

I will test and report back.

kblazk · Sat Sep 06, 2008 9:04 pm

well unfortunately I tested the RB600 with 24v and 48v and it made absolutely no difference from 12v.

tjohnson · Sun Sep 07, 2008 7:32 am

The re-registration problem is a known issue with MT. I'm not sure if they are working on it or not. It seems they would rather spend their time adding new options and features than fixing existing problems and bugs.

kblazk · Mon Sep 08, 2008 3:54 am

whats the point in adding new features to something that you can't even use in the first place????

Mon Sep 08, 2008 9:38 am

whats the point in adding new features to something that you can't even use in the first place????

if you have an issue with RouterOS, please write to support, and also send a supout.rif file. If three-four people on the forum have an issue, it doesn't mean everyone has it. So please help us help you, and send us those files.

rspott · Tue Sep 16, 2008 11:41 pm

Attached is a packet capture of the Mikrotik’s beacon timestamp restarting, triggering the Tranzeo CPQ’s and some other devices to re-associate. The reasoning behind the CPQ’s re-associating on beacon timestamp is for the fact that this indicates the AP rebooted, or was replaced, which means there may be capability changes, and the CPQ needs to re-associate to confirm it still matches capabilities.

Since the timestamp goes to 0 and restarts, the CPQ is doing as intended.

Packet number:

#1-16 Beacon timestamp translates into 18hours
#17 Beacon timestamp translates into seconds or less than 1.
#18 first probe response (the probe request must not have been captured, poor signal to some CPQ’s on bench)
#146 first authentication packet
#159 first association request

Observer prints it in time, Wireshark does it in Hex, which I’m looking at for this email.
About 8 seconds after 0 timestamp, CPQ’s are re-associated.
FYI, that times changes, and is not 18 hours. It could be minutes, hours, days.
See forum http://forum.mikrotik.com/viewtopic.php ... 99#p127799

Is there a corrective action the users can take to stop this behavior from the AP?

Capture file is located here:
http://www.tranzeofaq.com/MT-CPQ-Reconnect.cap

rspott · Tue Sep 16, 2008 11:57 pm

Attached is a packet capture of the Mikrotik’s beacon timestamp restarting, triggering the Tranzeo CPQ’s and some other devices to re-associate. The reasoning behind the CPQ’s re-associating on beacon timestamp is for the fact that this indicates the AP rebooted, or was replaced, which means there may be capability changes, and the CPQ needs to re-associate to confirm it still matches capabilities.

Since the timestamp goes to 0 and restarts, the CPQ is doing as intended.

Packet number:

#1-16 Beacon timestamp translates into 18hours
#17 Beacon timestamp translates into seconds or less than 1.
#18 first probe response (the probe request must not have been captured, poor signal to some CPQ’s on bench)
#146 first authentication packet
#159 first association request

Observer prints it in time, Wireshark does it in Hex, which I’m looking at for this email.
About 8 seconds after 0 timestamp, CPQ’s are re-associated.
FYI, that times changes, and is not 18 hours. It could be minutes, hours, days.
See forum http://forum.mikrotik.com/viewtopic.php ... 99#p127799

Is there a corrective action the users can take to stop this behavior from the AP?

Capture file is located here:
http://www.tranzeofaq.com/MT-CPQ-Reconnect.cap

Ticket#2008091666000531

rspott · Fri Sep 19, 2008 6:08 pm

A quick Video showing the issue from the AP:

http://www.tranzeofaq.com/MtikDrops/

Ticket Number: Ticket#2008091666000531

I don't see any reply to this via support, is this normal?

I don't think there are any holidays happening: http://en.wikipedia.org/wiki/Public_holidays_in_Latvia

Can we get a reply or acknowledgment on this issue please?

netrat · Fri Sep 19, 2008 6:23 pm

I received a response from MT support regarding this issue. They are saying Nstreme was not designed for a lot of client connections and that should be turned off. We are going to try that and see if it helps.

Also, they are considering a new protocol (not Nstreme) to allow more client connections per AP.

I'm confused?? When should you use Nstreme? Is there a rough estimate on the max number of client associations you should use Nstreme with?

rspott · Sun Sep 21, 2008 11:32 pm

tjohnson · Sun Sep 21, 2008 11:40 pm

Mikrotik's support response to me was "Nstreme was never designed for what you are trying to use it for. It was designed for point to point or point to multi-point with few clients".

MT's latest response is no more than 50 clients per AP (with or without Nstreme).

All of our clients are running Nstreme and it works really well... unless you go over 50 clients and if you can live with the erratic latency issues (ping times will be 5, 6, 5, 10, 5, 300, 280, 5, 5, etc.).

jorj · Mon Sep 22, 2008 9:27 am

A quick Video showing the issue from the AP:

http://www.tranzeofaq.com/MtikDrops/

Ticket Number: Ticket#2008091666000531

I've looked at your video, and all your tranzeo clients are linked on wlan2, not on wlan1 that drops all the clients. Have you considered that "could" be an issue, in first case ?

[edit]
It seems to me that you also have tranzeo's linked to wlan1 as well. Why are them also dropped ?!? In your specific case it might be the fact that you're mixing 11b and 11g clients, many of them with weak signal, below -85 db.

Don't know for the rest of the posts, though....

rspott · Tue Sep 23, 2008 12:43 am

A quick Video showing the issue from the AP:

http://www.tranzeofaq.com/MtikDrops/

Ticket Number: Ticket#2008091666000531

I've looked at your video, and all your tranzeo clients are linked on wlan2, not on wlan1 that drops all the clients. Have you considered that "could" be an issue, in first case ?

Look again: All of the clients on this AP are Tranzeo Clients. WLAN2 is not affected by this issue (it is 5.8)

It seems to me that you also have tranzeo's linked to wlan1 as well. Why are them also dropped ?!? In your specific case it might be the fact that you're mixing 11b and 11g clients, many of them with weak signal, below -85 db.

Again, ALL of the clients linked to wlan1 are Tranzeo clients. Some may have weak signals. Does this mean that if I come by your network with a laptop and a signal strength of -85 and connect to your network all of your clients drop? No. I don't think so.

The issue here is Mikrotik ignoring the spirit of the law (802.11-2007) and following the letter of the law. The Mtik AP gives out random 0 timestamps in it's beacons. While this is not "banned" by 802.11-2007, it is implied that you should not do this unless the feature-set of your AP changes.

The Tranzeo clients (and as I have found out from over a dozen other large WISPs) other brand clients INCLUDING Mtik clients will properly dis-associate when they see this incorrect 0 timestamp. If this issue has not bitten your 2.4ghz based WISP, it might soon.

This is a problem. Mtik needs to own up and fix it.

tjohnson · Tue Sep 23, 2008 12:52 am

Just to clarify: We are seeing this problem on all of our Mikrotik AP's (over 50 of them) and we are using 900mhz, 2.4ghz and 5ghz. We are also using Nstreme on all AP's and clients.

JR · Thu Sep 25, 2008 12:32 am

Did this happen before 3.10?

tjohnson · Thu Sep 25, 2008 1:09 am

Yes. Since v3.3 (because that's when we first started installing MT AP's and clients).

kblazk · Tue Sep 30, 2008 6:35 pm

i watched the video, that is exactly what several of my AP's are doing, all Tranzeo clients dropping. Some of them only do it a few times a day but i had one AP that was doing it every few minutes and i had to replace that AP with Star-OS or risk loosing all those customers.

Why is Mikrotik being so-silent on this?

ssalgadoe · Thu Oct 02, 2008 6:33 pm

Do we have any updates on this?

Simmer · Wed Oct 08, 2008 4:08 am

MT has developed some new test wireless packages to resolve this issue. I have been using it for 4 or 5 days now and so far Tranzeos are working pretty good. However my Deliberants and being kind of stupid almost the same problem the Tranzeos have been. But not quite the same.

I hope MT doesn't mind me posting the links:

http://mikrotik.com/download/temp/custo ... mipsbe.npk
http://mikrotik.com/download/temp/custo ... mipsle.npk
http://mikrotik.com/download/temp/custo ... 14-ppc.npk

Chris

tjohnson · Wed Oct 08, 2008 5:26 am

If I am using MT on both the AP and client, do I have to upgrade both or just the AP side?

Simmer · Wed Oct 08, 2008 12:14 pm

Shoul just be the AP side. That is all that I have upgraded. The MT clients do just fine with any version loaded on them.

Chris

avolve · Sat Oct 11, 2008 12:12 am

How about a Intel/AMD/386 version ?

infowest · Sat Oct 11, 2008 2:07 am

Has this upgrade only addressed the client disconnects, or is latency also improved?

olawale · Sun Oct 12, 2008 3:13 pm

Who is online