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..
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
/system scheduler
add comment="" disabled=no interval=20s name="fix_registration_problem" \
on-event=":if ([/ping REMOTE_IF_IP interface=WIRELESS_IF count=1]!=1) do {:if \
([/interface wireless get WIRELESS_IF mac-address] = \"MAC_ADDRESS_ONE\") do \
{/interface wireless set WIRELESS_IF mac-address=MAC_ADDRESS_TWO} else \
{/interface wireless set WIRELESS_IF mac-address=MAC_ADDRESS_ONE}}" \
start-date=jan/01/1970 start-time=00:00:00
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.
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…
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.
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:
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.
