hi,

we have a customer client device called 'wa2204a' (from Prague). In our case it cannot connect 3.0rc5, only if the AP (RB333) interface is restarted. If the client suffers a reboot or power loss, it stucks in state 'scanning'. If we restart the AP interface it connects in 5 secs. Is this a bug? (tried many settings: B/G, G only, data rates,etc). Because this is an RB 333 we cannot downgrade. We didn't have a problem like this on the MT2.9.

As a workaround we made a script that restarts the interface once in an hour but in this case when the client reboots, the custmer have to wait 30 minutes (average) (60 minutes worst case) before he can go on the net.

update: this problem appears on other devices too: OsBridge, and not only on our RB333 but on two RB532s too... (we could downgrade the latter)

we saw that clients stucked in the scanning phase appeared in the winbox wireless registration table with "SP" data rate.. (example 11Mbit-SP/36Mbit) What does this SP mean?

considering this, this appears to be not just a little bug..

11Mbps-SP
SP - Short Preamble

I have the same problem with MT3.0rc5 and various APC based on RTL and Atheros chipset.

I too am experiencing this (or something like it) with 3.0RC5.

The client looses the connection to the access point (Mt to Mt), the access point has the client listed the in the registration table still.

Two workarounds I have for this are:
1. delete the connection on the access point
2. change MAC address of the client

I get re-registrations both ways.

Brian

this problem will be fixed in the next release of the RouterOS.

Good news on the fix in the next release! Any word on timing for the next release?

In the meantime, I have created a little script to change my MAC addresses if it gets disconnected.

REMOTE_IF_IP is the address of the remote wireless interface
WIRELESS_IF is the out interface for the wireless connection (wlan1 in my case)
MAC_ADDRESS_ONE is the MAC address of the card
MAC_ADDRESS_TWO is the alternate MAC address
I know this is not perfect, because I am counting on IP connectivity for the connection when I should be looking at the registration list. But I couldn't figure out how to use :find against the registration list to test if an interface is registered (I was getting odd results).

Also note, in my world, 20 seconds my IP connection restores in about 2 seconds. So just to be safe I am running the script every 20 seconds. I haven't experimented with longer or shorter delays in the running of the script - my worry is that if they start coming too fast, we could end up swapping MAC addresses on a good connection. Maybe a delay would work in the do {} statement. Thoughts?

And don't forget to add both MACs as authorized devices if you do some kind of MAC authentication.

Brian

I also get this bug cm9 - cm9

Thanks

P.S Thanks for the workaround script!

Yes we are having similar problems since we upgraded from 2.9 yesterday. We have many clients (OSBridge) all showing good signal but PPPoE connections are dropping and some clients are unable to connect at all.

I too would like to know when the next release is expected...

Does it happen with 5GHz too?
Thanks.

Mine are all 2.4.

seems the crapper the link the more ofte it will happen.

I'm going to switch one to 5.8, I will keep posting here.

Mine are all 2.4Ghz.

All 2.4 - 5GHz we only use for point to point and these are OK. I may have to downgrade back to 2.9 and hope that fixes the problem.

this problem will be fixed in the next release of the RouterOS.

OK, so what was the problem Uldis?
As you stated that it would be fixed in rc6 I guess you know what the problem is?

I also have had this problem for weeks, and despite I've upgraded to rc9 it's still there. I don't want to upgrade to rc10 unless I know I will benefit from it, as each AP reboot requires the clients to power-cycle their CPE.
I cannot see anything on this problem in the changelog for rc10 either.

I have addressed this problem in several threads:
http://forum.mikrotik.com/viewtopic.php?f=7&t=19476
http://forum.mikrotik.com/viewtopic.php?f=7&t=19563

...but still I have no solution.

Uldis suggested the following:

Upgrade to the latest release of the RouterOS, check the ack-timeout, try setting preamble-mode to long.

but still no use, so I reverted to "Automatic" and "Both".

kchris, otek: Have you found any workaround?
I don't want to fool around with my MACs, as I use Access list for authentication.

Customers are starting to get impatient, so I need to solve this!

Are you sure your problem is related?

Mine is fixed a few versions ago.

Are you sure your problem is related?

Mine is fixed a few versions ago.

Well I don't know, but my problem is still there.
As mentioned the behaviour has changed from disconnects every 20 seconds with this "class 3 frame (7)" message in rc5, to very frequent connects/disconnects with no message in rc9.

What was your cure? Mac swapping?

At least I'd like to know whether this problem is related to:
1. The R52 radio card (Atheros chipset)
2. The Linksys client chipset (Broadcom)
3. Client firmware
4. RouterOS

Upgraded to rc10 just now and same shit...

Me too, need a fix for this soon!

Me too. RC9 and RC10 , all bad.

please contact the support@mikrotik.com about this issue with support output file attached and detailed decription of the problem. Also mention about the wireless client who connect to the AP (OS,wireless card).

I'd love to, but I had to take it back off of the box. The client was a broadcom 2.4 ghz. All of my 5ghz and 900 mhz stuff worked fine. Just 2.4 that seemed to be affected. A CM9 in a routerboard could connect to it, but not the broadcom.

Joe

I use in router CM9 or R52 , and as client Ovislink WL-5460AP.

I use in router CM9 or R52 , and as client Ovislink WL-5460AP.

what mode are you using on that Ovislink client?
Make sure that you upgrade the OvislinkAP to the latest version.

I use in router CM9 or R52 , and as client Ovislink WL-5460AP.

what mode are you using on that Ovislink client?
Make sure that you upgrade the OvislinkAP to the latest version.

I use Firmware Version: "5460APv2_e10_b1" and mode "Client-Infrastructure"

I found a cure for my problem:
http://forum.mikrotik.com/viewtopic.php?p=95373#p95373

Actually, when reading the thread thoroughly again I see that my problem is kinda opposite to kchris': After restarting the AP the CPEs had to be restarted to connect.
Anyway, it is related, and it's Broadcom 2.4 as jcremin says.

Maybe older Sveasoft firmware builds had a somewhat flaky wireless driver? I don't know.