MikroTik

Posted: **Tue Apr 10, 2007 9:12 pm**

I'm having a strange issue with the "deauth" spam a few other forum users have posted about. I haven't seen any real explanation or possible solution in the community forum regarding this issue though, there are a couple of recent threads:

http://forum.mikrotik.com/viewtopic.php ... ght=deauth
http://forum.mikrotik.com/viewtopic.php ... ght=deauth
http://forum.mikrotik.com/viewtopic.php ... ght=deauth
http://forum.mikrotik.com/viewtopic.php ... ght=deauth

This has now happened on 3 AP's in the span of less than a week, when we've never seen it before.

The first AP is an RB532 w/ 502 daughter board, SR2 in AP mode, R52 in client mode, and Prism 2511MP in client mode. This access point has been up and running for about 1.5 years. At some point, all stations disassociated for some unknown reason, and the log began filling with error messages like this:

05:20:55 wireless,info Broadcast: data from unknown device 00:11:7C:0A:12:CC, sent deauth (1 events suppressed)
05:20:59 wireless,info Broadcast: data from unknown device 00:11:7C:0A:12:E0, sent deauth (1 events suppressed)
05:21:04 wireless,info Broadcast: data from unknown device 00:11:7C:0A:12:E0, sent deauth (13 events suppressed, 3 deauths suppressed)
05:21:10 wireless,info Broadcast: data from unknown device 00:11:7C:0A:12:E0, sent deauth (4 events suppressed)
05:21:15 wireless,info Broadcast: data from unknown device 00:11:7C:0A:12:E0, sent deauth (2 events suppressed)
05:21:20 wireless,info Broadcast: data from unknown device 00:11:7C:0A:12:E0, sent deauth (2 events suppressed)
05:21:25 wireless,info Broadcast: data from unknown device 00:11:7C:0A:12:E0, sent deauth
05:21:30 wireless,info Broadcast: data from unknown device 00:11:7C:0A:12:E0, sent deauth
05:21:35 wireless,info Broadcast: data from unknown device 00:11:7C:0A:12:E0, sent deauth
05:21:41 wireless,info Broadcast: data from unknown device 00:11:7C:0A:12:CC, sent deauth (1 events suppressed)

I worked extensively with the configuration (including changing ROS versions from 2.9.38 to 2.9.42, and even 2.9.27) trying to resolve the problem (adjusting various settings), and was able to get a few stations to associate. Notably all were Atheros stations, no Prism (CB3) stations would associate. Eventually, I gave up as it was late at night. The next morning, everybody was associated. Here is the log excerpt from when everything came back (pppoe entries removed):

05:26:55 wireless,info Broadcast: data from unknown device 00:11:7C:0A:10:EC, sent deauth
05:27:00 wireless,info Broadcast: data from unknown device 00:11:7C:0A:10:EC, sent deauth (7 events suppressed)
05:27:03 wireless,info Broadcast: data from unknown device 00:11:7C:0A:12:E0, sent deauth (2 events suppressed)
05:27:10 wireless,info Broadcast: data from unknown device 00:11:7C:0A:10:EC, sent deauth (2 events suppressed)
05:27:12 wireless,info 00:11:7C:0A:12:E0@Broadcast: connected
05:27:15 wireless,info Broadcast: data from unknown device 00:11:7C:0A:10:EC, sent deauth (1 events suppressed)
05:27:16 wireless,info 00:11:7C:0A:12:E0@Broadcast: disconnected, reassociating
05:27:20 wireless,info Broadcast: data from unknown device 00:11:7C:0A:10:EC, sent deauth (1 events suppressed)
05:27:24 wireless,info 00:11:7C:0A:12:E0@Broadcast: connected
05:27:25 wireless,info Broadcast: data from unknown device 00:11:7C:0A:10:EC, sent deauth (1 events suppressed)
05:27:31 wireless,info 00:11:7C:0A:12:CC@Broadcast: connected
05:27:36 wireless,info 00:11:7C:0A:10:EC@Broadcast: connected
05:27:38 wireless,info 00:02:6F:3F:1F:BC@Broadcast: connected
05:27:39 wireless,info 00:02:6F:3B:F0:9D@Broadcast: connected
05:27:41 wireless,info 00:02:6F:41:5D:92@Broadcast: connected
05:27:41 wireless,info 00:02:6F:3A:DF:E4@Broadcast: connected
05:27:15 wireless,info Broadcast: data from unknown device 00:11:7C:0A:10:EC, sent deauth (1 events suppressed)
05:27:16 wireless,info 00:11:7C:0A:12:E0@Broadcast: disconnected, reassociating
05:27:20 wireless,info Broadcast: data from unknown device 00:11:7C:0A:10:EC, sent deauth (1 events suppressed)
05:27:24 wireless,info 00:11:7C:0A:12:E0@Broadcast: connected
05:27:25 wireless,info Broadcast: data from unknown device 00:11:7C:0A:10:EC, sent deauth (1 events suppressed)
05:27:31 wireless,info 00:11:7C:0A:12:CC@Broadcast: connected
05:27:36 wireless,info 00:11:7C:0A:10:EC@Broadcast: connected
05:27:38 wireless,info 00:02:6F:3F:1F:BC@Broadcast: connected
05:27:39 wireless,info 00:02:6F:3B:F0:9D@Broadcast: connected
05:27:41 wireless,info 00:02:6F:41:5D:92@Broadcast: connected
05:27:41 wireless,info 00:02:6F:3A:DF:E4@Broadcast: connected
05:27:15 wireless,info Broadcast: data from unknown device 00:11:7C:0A:10:EC, sent deauth (1 events suppressed)
05:27:16 wireless,info 00:11:7C:0A:12:E0@Broadcast: disconnected, reassociating
05:27:20 wireless,info Broadcast: data from unknown device 00:11:7C:0A:10:EC, sent deauth (1 events suppressed)
05:27:24 wireless,info 00:11:7C:0A:12:E0@Broadcast: connected
05:27:25 wireless,info Broadcast: data from unknown device 00:11:7C:0A:10:EC, sent deauth (1 events suppressed)
05:27:31 wireless,info 00:11:7C:0A:12:CC@Broadcast: connected
05:27:36 wireless,info 00:11:7C:0A:10:EC@Broadcast: connected
05:27:38 wireless,info 00:02:6F:3F:1F:BC@Broadcast: connected
05:27:39 wireless,info 00:02:6F:3B:F0:9D@Broadcast: connected
05:27:41 wireless,info 00:02:6F:41:5D:92@Broadcast: connected
05:27:41 wireless,info 00:02:6F:3A:DF:E4@Broadcast: connected
05:27:15 wireless,info Broadcast: data from unknown device 00:11:7C:0A:10:EC, sent deauth (1 events suppressed)
05:27:16 wireless,info 00:11:7C:0A:12:E0@Broadcast: disconnected, reassociating
05:27:20 wireless,info Broadcast: data from unknown device 00:11:7C:0A:10:EC, sent deauth (1 events suppressed)
05:27:24 wireless,info 00:11:7C:0A:12:E0@Broadcast: connected
05:27:25 wireless,info Broadcast: data from unknown device 00:11:7C:0A:10:EC, sent deauth (1 events suppressed)
05:27:31 wireless,info 00:11:7C:0A:12:CC@Broadcast: connected
05:27:36 wireless,info 00:11:7C:0A:10:EC@Broadcast: connected
05:27:38 wireless,info 00:02:6F:3F:1F:BC@Broadcast: connected
05:27:39 wireless,info 00:02:6F:3B:F0:9D@Broadcast: connected
05:27:41 wireless,info 00:02:6F:41:5D:92@Broadcast: connected
05:27:41 wireless,info 00:02:6F:3A:DF:E4@Broadcast: connected
05:27:15 wireless,info Broadcast: data from unknown device 00:11:7C:0A:10:EC, sent deauth (1 events suppressed)
05:27:16 wireless,info 00:11:7C:0A:12:E0@Broadcast: disconnected, reassociating
05:27:20 wireless,info Broadcast: data from unknown device 00:11:7C:0A:10:EC, sent deauth (1 events suppressed)
05:27:24 wireless,info 00:11:7C:0A:12:E0@Broadcast: connected
05:27:25 wireless,info Broadcast: data from unknown device 00:11:7C:0A:10:EC, sent deauth (1 events suppressed)
05:27:31 wireless,info 00:11:7C:0A:12:CC@Broadcast: connected
05:27:36 wireless,info 00:11:7C:0A:10:EC@Broadcast: connected
05:27:38 wireless,info 00:02:6F:3F:1F:BC@Broadcast: connected
05:27:39 wireless,info 00:02:6F:3B:F0:9D@Broadcast: connected
05:27:41 wireless,info 00:02:6F:41:5D:92@Broadcast: connected
05:27:41 wireless,info 00:02:6F:3A:DF:E4@Broadcast: connected
05:27:41 wireless,info 00:02:6F:3F:1E:E5@Broadcast: connected
05:27:41 wireless,info 00:02:6F:3A:D6:8E@Broadcast: connected
05:27:42 wireless,info 00:02:6F:3F:1F:BC@Broadcast: disconnected, reassociating
05:27:42 wireless,info 00:02:6F:3F:1F:BC@Broadcast: connected
05:27:43 wireless,info 00:02:6F:3F:21:05@Broadcast: connected
05:27:43 wireless,info 00:02:6F:3B:E7:56@Broadcast: connected
05:27:44 wireless,info 00:02:6F:44:C5:22@Broadcast: connected
05:27:46 wireless,info 00:02:6F:3A:D4:9F@Broadcast: connected
05:27:46 wireless,info 00:02:6F:3B:EA:5F@Broadcast: connected
05:27:46 wireless,info 00:02:6F:3A:D4:A0@Broadcast: connected
05:27:47 wireless,info 00:02:6F:3A:E2:F9@Broadcast: connected
05:27:47 wireless,info 00:02:6F:41:50:2E@Broadcast: connected
05:27:48 wireless,info 00:02:6F:3B:EA:71@Broadcast: connected
05:27:49 wireless,info 00:02:6F:3A:E0:74@Broadcast: connected
05:27:50 wireless,info 00:02:6F:3B:ED:2F@Broadcast: connected
05:27:50 wireless,info 00:02:6F:3A:D5:E6@Broadcast: connected
05:27:50 wireless,info 00:02:6F:3F:1F:89@Broadcast: connected
05:27:50 wireless,info 00:02:6F:3B:ED:30@Broadcast: connected
05:27:51 wireless,info 00:02:6F:3B:F0:96@Broadcast: connected
05:27:52 wireless,info 00:02:6F:3D:74:8C@Broadcast: connected
05:27:53 wireless,info 00:02:6F:3B:EF:90@Broadcast: connected
05:27:53 wireless,info 00:02:6F:38:56:7F@Broadcast: connected
05:27:53 wireless,info 00:02:6F:3A:88:F0@Broadcast: connected
05:28:06 wireless,info 00:02:6F:3B:E7:E0@Broadcast: connected
05:28:57 wireless,info 00:02:6F:3A:DF:E7@Broadcast: connected

I suspect that the problem may be CPE related, and in this case possibly cleared up when the CPE was rebooted (i.e. someone trying to use their service, restarted CPE because it wasn't working). About 12 hours later, I was monitoring the situation and decided to change the AP from 2.4Ghz-B where it had settled in while troubleshooting, back to 2.4Ghz-B/G. When I changed it, the *exact* same thing happened again, with even the same MAC addresses showing up in the deauth logs. Again, I messed with it and ended up leaving the thing alone. The next morning, everybody was back again.

Our initial thought was that perhaps this was a damaged SR2 or something of that nature, especially since I tried several different revisions of ROS in the troubleshooting process. However, the following Monday (yesterday) I had the same situation come up on another AP some distance away (about 80 miles). This AP has been acting strangely for a while, but I can't say if it's been this issue or not.

The second AP is an RB532+502, running 2.9.38 with an SR2, SR5 (output power lowered), and 2x 2511MP, one set to 8dB output power to go easier on the PSU. I feel that previous issues with this AP are due to overload on the RB532 power supply, but in this situation I saw exactly the same symptoms as the first AP I talked about.

I tried many configuration changes, including updating ROS to 2.9.42. I did not try older versions on this unit because it didn't make a difference on the first one. After trying quite a few settings and not bringing stations back, I left it alone for about 4 to 6 hours. The stations did not return. As a last ditch effort, I had the thought that if the stations that are de-authing think they are associated, but the AP doesn't, what if the AP changed? To this end, I changed the MAC address of the AP. Immediately, all stations re-associated and have remained associated since that time.

The 3rd AP did the same thing, though when I changed the MAC address, it didn't seem to help immidiatly. I changed it back, and diddled a little more, then all of the stations came back. I don't know for sure, but I feel like changing the MAC and changing it back may have been the catalyst to resolution.

Is it possible that the CPE is the issue? In all cases the most log entries for the deauth issue show as EZ3+ MAC addresses (http://www.e-zy.net/products/outdoor/3plus), though some LS2 MAC id's showed up. No prisms exhibited this issue. We don't have very many of these units, because we were not happy with the high failure rate.

I sincerely doubt that it could be bad hardware, as the same issue has occurred on 3 separate AP units. In some cases on these forums, users reported that changing the card resolved the problem, but it seems to me like that may have been resolution because the MAC ID changed, not because the card was bad. In these situations, I have to wonder what would have happened if they simply changed the MAC ID instead of changing the hardware.

Any thoughts or input on this subject are appreciated! I've also submitted a ticket to the official support channels including supout files, but I was hoping to perhaps get some more input from the community.

Posted: **Tue Apr 10, 2007 10:00 pm**

Just had a 4th AP do the EXACT SAME thing.

This one is an x86 (intel i815, p3 600Mhz, 2.9.38) with 3x Xi325 cards (prism 2.5, AP) and 1x CM9 (feed).

Problem seems to be occuring on only one interface at the moment.

In this case, it appears that rebooting the AP (upgrade to 2.9.42 in the process) seems to have resolved the symptoms. . . at least so far, I'm still tinkering with it.

Posted: **Wed Apr 11, 2007 4:59 am**

It looks like this is only happening on 2.4ghz right?

have you done a freq. usage scan, or a snooper scan when the issue happens? maybe something new to the area is wiping out your Freq.

its unlikly though as SOME units should still be able to connect even with the freq. really wiped out.

channel changes did not help i'm assuming.

Posted: **Wed Apr 11, 2007 8:25 am**

It looks like this is only happening on 2.4ghz right?

Yes, we don't use any 5.8Ghz for distribution, only backhaul.

have you done a freq. usage scan, or a snooper scan when the issue happens? maybe something new to the area is wiping out your Freq

Yes, nothing new of significance.

its unlikly though as SOME units should still be able to connect even with the freq. really wiped out.

Yeah. I've had problems with channel use before, it has different symptoms.

channel changes did not help i'm assuming.

No, no significant change by changing the channel.

The only change I was able to make that had any significant impact, was to change the MAC ID of the access point interface.

Posted: **Fri Apr 13, 2007 4:29 pm**

I've had a problem that seems very close to the one that you are having. I was also using an sr2 for clients. I never tried changing my mac address so i have no answer on that. When i installed my ap it was late at night and after i had powered it up no one was connected not even my laptop 100 feet away. I tried all kinds of setings with no luck and went home. Got up the next morning with everyone connected and thought what the hell is going on. Then proceded to make changes to settings on the sr2 and once again no one connected. Messed with it for hours and gave up. Later in the day everyone was connected again. After screwing with this for a month i finally found that it wasn't my settings but some form of compatiblity issue( i think mixed client eviroment some clients prism and some atheros ) I mainly use tranzeo clients but also had a few teletronics pci cards on this tower. If you just disable and enable your wireless interface at rapid speeds and who knows how many times in a row (varied) clients would come back. This was not an answer for me because if power went out or i made a setting change i would have the same problem every time. I bought a senao 2511 to replace sr2 and all problems went away. I forgot to mention that i had already replaced the sr2 with another and replaced the rb532 with another and had even tried a cm9 on both boards to only have the same problem.
If you are still having this problem please try the disabling and enabling of the wireless interface and see if this works and also when cycle the interface does it show 1 to 5 clients connected and then lose them within a minute because mine would. This isn't an answer but hopefully we can find what is the actual problem because I'm getting ready to deploy a few xr2's and praying that i don't see this issue again.

Posted: **Fri Apr 13, 2007 5:04 pm**

I've had a problem that seems very close to the one that you are having. I was also using an sr2 for clients. I never tried changing my mac address so i have no answer on that. When i installed my ap it was late at night and after i had powered it up no one was connected not even my laptop 100 feet away. I tried all kinds of setings with no luck and went home. Got up the next morning with everyone connected and thought what the hell is going on. Then proceded to make changes to settings on the sr2 and once again no one connected. Messed with it for hours and gave up. Later in the day everyone was connected again. After screwing with this for a month i finally found that it wasn't my settings but some form of compatiblity issue( i think mixed client eviroment some clients prism and some atheros ) I mainly use tranzeo clients but also had a few teletronics pci cards on this tower. If you just disable and enable your wireless interface at rapid speeds and who knows how many times in a row (varied) clients would come back. This was not an answer for me because if power went out or i made a setting change i would have the same problem every time. I bought a senao 2511 to replace sr2 and all problems went away. I forgot to mention that i had already replaced the sr2 with another and replaced the rb532 with another and had even tried a cm9 on both boards to only have the same problem.
If you are still having this problem please try the disabling and enabling of the wireless interface and see if this works and also when cycle the interface does it show 1 to 5 clients connected and then lose them within a minute because mine would. This isn't an answer but hopefully we can find what is the actual problem because I'm getting ready to deploy a few xr2's and praying that i don't see this issue again.

Did you have wireless debugging on in your log files? If you don't, I suggest turning it on.

I think you'll find that you were having the *exact* same problem.

You might also want to rethink changing from Atheros AP to Prism AP. The Atheros can handle many more clients, much better than a prism.

Posted: **Sat Apr 14, 2007 8:31 pm**

I had a similar problem when trying B/G mode with CM9 radio cards, my CPE units are mainly SmartBridge B only.

The problem occurred whilst migrating from LocustWorld Mesh to MikroTik. I tried to replicate the same setup, i.e. one radio per box handling both WDS and local CPE traffic on seperate virtual APs.

Switching to B/G mode to try and get better bandwidth on WDS, everything went bananas. In the end I had to give up on B/G mode and go back to B only. I implemented a new transmitter using 5.8GHz as a PTP link to get the extra bandwidth.

The problem appeared to be with only one site that was in the middle of a chain, i.e. it had one upstream and one downstream router. It was tring to relay WDS and act as AP to local CPEs via one radio. I would have liked to add a second or third radio at this site, but it was too difficult to mount additional antennae. The site is probably going to be ceased soon, so it wasn't worth the effort to find a long term solution.

Posted: **Sun Apr 15, 2007 12:26 am**

no i didn't have the logs turned on on so i don't have anything to base it off of. if you come up with any answers please let us know. And i was using a cm9 in 5.8 for my backhaul. I will be testing the xr2 on mikrotik platform this coming week. I was going to use Ikarus software on a Gateworks board but i've already had plenty of fun with that stuff testing at home. good luck

Posted: **Sun Apr 15, 2007 5:47 am**

I had a small water tower single AP site that worked fine with a Tranzeo AP. We upgraded the site to 3 sectores running rb532's with SR2 cards. ! of the sectors has the exact proplem oters have reported. After a couple of days of down time and work we decided to put the old Tranzeo AP back up on the sector having problems. The problem immedialy went away. Never found a solution to this.

Posted: **Mon Apr 16, 2007 1:03 am**

An update on my last post. We just finished removing the Tranzeo and replaced with a XR2. Had the same problem as with the SR2. I lowered the Tx power down and found that at 17dB all stay connected with no problems at all. To test I set the power back up to 25dB and got deauths again.

I was hopiong someone might have some insight as to why this behaves this way.

Posted: **Mon Apr 16, 2007 8:20 pm**

An update on my last post. We just finished removing the Tranzeo and replaced with a XR2. Had the same problem as with the SR2. I lowered the Tx power down and found that at 17dB all stay connected with no problems at all. To test I set the power back up to 25dB and got deauths again.

I was hopiong someone might have some insight as to why this behaves this way.

Try changing your MAC address and see what happens. I'm starting to lean towards this being a CPE related issue, but I can't quite pin it down.

Posted: **Thu May 03, 2007 11:05 pm**

i also have the same symptoms, also replaced everyting and the SR2 card twice, then replaced it with 8602 card, The 8602 card gives high ping times to clients, so i think the solution is to add a second AP on the board and split up the clients, because im running 60+ clients on one ap.
I reckon this should fix the problem, i already lost 2 x SR2 cards due to this problem

MikroTik

Multiple problems with "deauth" spam/DOS

Multiple problems with "deauth" spam/DOS

strnge deauths