I have logs full of.

Lost connection, control frame timeout

And

Lost connection, medium-access timeout

I have the problem with station WDS links more than standard station. It seems like the WDS links disconnect all within a seconds of each other then sometimes will reconnect within a few seconds and other times they will have a hard time reconnecting and won't even show the AP they are supposed to be connecting to in the wireless debug log.

It does happen on non WDS links also but not nearly as often. I have played around with NV2 settings but nothing really seems to help with the problem. This is a pretty noisy area in 2.4Ghz but the clients have good Signal strengths and good CCQ when moving data and I don't see the disconnect issues when running Nstreme or 802.11.

For example I have four clients within 100 yds of each other two are set up as station WDS and the other two as stations, all with almost identical signal strengths and quality. The two WDS clients will disconnect within seconds of each other while the station clients remain connected. This is a pretty noisy area for 2.4 but I am able to push ~14Mbps the all these clients individually. But the disconnects are a huge Pain, reminds me of the "extensive data loss" problems that have plagued MT for years now.

I know there are others having these same issues, has anyone found a cure for it yet?

I opened a ticket yesterday and sent in support files but have not heard anything back yet. The current ticket number is 2011052366000116

Hi, I confirm I have the same problem in the 5 GHz band. The standard 802.11 or NST works without problems. I was expecting great strength NV2 using P2MP. When using NV2 frequently appears in the log Lost Connection Control frame timeout
and the Lost connection, medium-access timeout. I used different settings - no change.

Normis or anyone from MT,

I have not received a response from you guys on this. I just sent another request for help through the ticket you generated Ticket#2011052366000116.

Again help on this would be appreciated.

Thanks,
Chadd

there are a few improvements in v5.3 in this area, maybe it could help. we have not been able to reproduce this kind of issue in our testing, but the fix could help.

there are a few improvements in v5.3 in this area, maybe it could help. we have not been able to reproduce this kind of issue in our testing, but the fix could help.

There are a lot of people who seem to be having the same issue. It happens on every AP I convert to NV2 it doesn't seem like it would be super hard to reproduce as long as you are testing in a real world outdoor noisy environment.

When is 5.3 going to be released?

Thanks,
Chadd

It was released today. Check the download page, there's also an announcement thread.

Thanks Fewi,

I missed that thread, I looked up and still saw the 5.2 release thread sticky at the top so assumed it wasn't out.

Normis,

There are no comments in the release notes about any wireless improvements.

It was released today. Check the download page, there's also an announcement thread.

there are a few improvements in v5.3 in this area, maybe it could help. we have not been able to reproduce this kind of issue in our testing, but the fix could help.

Normis,

I upgraded an AP and a few of the clients having issues from 5.2 to 5.3 and it made no difference at all, in fact it is a bit worse and we now have ethernet port flapping issues.

Thanks,
Chadd

please email about the port flapping to support. we need full description of your setup, cables, other end of the cable, powering, etc.

please email about the port flapping to support. we need full description of your setup, cables, other end of the cable, powering, etc.

Done.

please email about the port flapping to support. we need full description of your setup, cables, other end of the cable, powering, etc.

Done.

Can u post here also for members who maybe able to suggest more ?

post what?

post what?

we need full description of your setup, cables, other end of the cable, powering, etc.

we don't need it anymore, problem has been identified and fixed in v5.4 which is already available to those interested. when we complete testing, we will release it.

we don't need it anymore, problem has been identified and fixed in v5.4 which is already available to those interested. when we complete testing, we will release it.

Great

Normis,

Is it possible to receive the 5.4 beta ?

write to: support@mikrotik.com

I have logs full of.

Lost connection, control frame timeout

And

Lost connection, medium-access timeout

I have the problem with station WDS links more than standard station. It seems like the WDS links disconnect all within a seconds of each other then sometimes will reconnect within a few seconds and other times they will have a hard time reconnecting and won't even show the AP they are supposed to be connecting to in the wireless debug log.

It does happen on non WDS links also but not nearly as often. I have played around with NV2 settings but nothing really seems to help with the problem. This is a pretty noisy area in 2.4Ghz but the clients have good Signal strengths and good CCQ when moving data and I don't see the disconnect issues when running Nstreme or 802.11.

For example I have four clients within 100 yds of each other two are set up as station WDS and the other two as stations, all with almost identical signal strengths and quality. The two WDS clients will disconnect within seconds of each other while the station clients remain connected. This is a pretty noisy area for 2.4 but I am able to push ~14Mbps the all these clients individually. But the disconnects are a huge Pain, reminds me of the "extensive data loss" problems that have plagued MT for years now.

I know there are others having these same issues, has anyone found a cure for it yet?

I opened a ticket yesterday and sent in support files but have not heard anything back yet. The current ticket number is 2011052366000116

Chad, on these disconnection nv2 links, do you use nv2 security?
I have the feeling it makes a difference in busy spectrum with other nv2 channels around.

I have tried both with and without security, it doesn't seem to make a difference in my case. I have reverted back to Nstreme for now.

If MT can't reproduce what so many users are seeing and having problems with I don't have much hope of them fixing it anytime soon. I am contemplating just making the switch to UBNT and being done with the headaches.

I have logs full of.

Lost connection, control frame timeout

And

Lost connection, medium-access timeout

I have the problem with station WDS links more than standard station. It seems like the WDS links disconnect all within a seconds of each other then sometimes will reconnect within a few seconds and other times they will have a hard time reconnecting and won't even show the AP they are supposed to be connecting to in the wireless debug log.

It does happen on non WDS links also but not nearly as often. I have played around with NV2 settings but nothing really seems to help with the problem. This is a pretty noisy area in 2.4Ghz but the clients have good Signal strengths and good CCQ when moving data and I don't see the disconnect issues when running Nstreme or 802.11.

For example I have four clients within 100 yds of each other two are set up as station WDS and the other two as stations, all with almost identical signal strengths and quality. The two WDS clients will disconnect within seconds of each other while the station clients remain connected. This is a pretty noisy area for 2.4 but I am able to push ~14Mbps the all these clients individually. But the disconnects are a huge Pain, reminds me of the "extensive data loss" problems that have plagued MT for years now.

I know there are others having these same issues, has anyone found a cure for it yet?

I opened a ticket yesterday and sent in support files but have not heard anything back yet. The current ticket number is 2011052366000116

Chad, on these disconnection nv2 links, do you use nv2 security?
I have the feeling it makes a difference in busy spectrum with other nv2 channels around.

I have tried both with and without security, it doesn't seem to make a difference in my case. I have reverted back to Nstreme for now.

If MT can't reproduce what so many users are seeing and having problems with I don't have much hope of them fixing it anytime soon. I am contemplating just making the switch to UBNT and being done with the headaches.

Probably you're up for migraines in that case.
I am in the process of removing all ubnt stuff from my network. Apart from the lack of options compared to ROS, some product lines are not half as reliable as MT stuff.
But my main issue I had was in a mixed network where nv2 can't be used (nor the airmax, remember that you have to change all units into ubnt!) the ubnt units had much more issues with disconnects than the ROS radios.

Some other measures I took to reduce the disconnect I had on my (5G) networks:
- Go for 10Mhz bandwidth channels.
- Separate as much as possible the available channels. It seems nv2 just needs more ´space´ to work than legacy modes
- Fixed conn rates. Set CPE's to default and let the AP pick only one or two rates. Makes the network much more stable.

I found that with NV2 channel spacing preferably would be better than 20Mhz, ideal is at least 40Mhz.
Off course that is in 2,4G band not even possible. To my opinion this is also the reason most disconnect issues with NV2 still around are from 2.4Ghz network users.

Oh, by the way, I have one short range link (15 mtrs!) between two NS-loco's with airmax enabled. I had many disconnects with these as well. Only when I removed the airmax (=tdma, like nv2) link became more stable.
But since competitor with ubnt-Airmax based network and several AP's is overshooting this link the disconnects never really disappeared. This while their signal levels where much lower off course and the closest freq. still some 20Mhz away from my centre freq. Only until I started to use an indoor channel nobody else uses the link stabilized.

My opinion is that TDMA is more aggressive in interferences towards other radio links. AP in NV2 mode is just transmitting at full power all the time, even in idle conditions. Where legacy AP radio only transmits in full power when data needs to be move.
Also, in MT ROS I just have more tools to cope with it.
Hence my prediction .......

there are a few improvements in v5.3 in this area, maybe it could help. we have not been able to reproduce this kind of issue in our testing, but the fix could help.

please email about the port flapping to support. we need full description of your setup, cables, other end of the cable, powering, etc.

we don't need it anymore, problem has been identified and fixed in v5.4 which is already available to those interested. when we complete testing, we will release it.

I have tried both with and without security, it doesn't seem to make a difference in my case. I have reverted back to Nstreme for now.

If MT can't reproduce what so many users are seeing and having problems with I don't have much hope of them fixing it anytime soon. I am contemplating just making the switch to UBNT and being done with the headaches.

@ Chadd I am confused from reading replies by Normis (a) MK could not reproduce the issue (b) Email support (c) Problem identified and fixed in V5.4, but reading your reply today have you tried 5.4 and is this issue still present

you both are talking about two things. chadd mentioned he has a port flapping issue, I was answering about that. I have no information about the Nv2 issue, and cannot verify that it exists. Maybe it's a configuration issue.

...........
Oh, by the way, I have one short range link (15 mtrs!) between two NS-loco's with airmax enabled. I had many disconnects with these as well. Only when I removed the airmax (=tdma, like nv2) link became more stable.
.......

Hi WirelessRudy,

On reading your comment about disconnects at 15 meters reminded me about my experiences with band II fm broadcasting and the reason why circular polarity antenna’s which have a gain of -3db is used in preference to using single polarity antenna’s with gain of between 0dB to +8dB, was phase cancellation which occurred when a strong single polarity signal gets inverted, could the same be happening in your case?

Info about NV2

Problems with wireless I describe here.

I wanted to use NV2, but unfortunately the clients are often disconnected with the following message CONTROL FRAME TIMEOUT. Disconnecting lasted several minutes. At 802.11, or NST runs fine.
The signals are so good, I think, when running standard 802.11.

http://forum.mikrotik.com/viewtopic.php?f=7&t=51959

...........
Oh, by the way, I have one short range link (15 mtrs!) between two NS-loco's with airmax enabled. I had many disconnects with these as well. Only when I removed the airmax (=tdma, like nv2) link became more stable.
.......

Hi WirelessRudy,

On reading your comment about disconnects at 15 meters reminded me about my experiences with band II fm broadcasting and the reason why circular polarity antenna’s which have a gain of -3db is used in preference to using single polarity antenna’s with gain of between 0dB to +8dB, was phase cancellation which occurred when a strong single polarity signal gets inverted, could the same be happening in your case?

Don't know, don't think so. Not using Airmax solved most of the problem and changing to lower 5Ghz band freq. has done the rest. But antenna is still NSloco which I presume has two antennas, H+V pol.
I don't have sophisticated tools to really measure what is going on in spectrum. All I can do is use the tools and info given to me by the antenna and the real life experience with some common sense...

As Normis mentioned he recommended I upgrade to 5.3 as it may fix some of the disconnect issues. I upgraded and then also had ethernet port flapping problems along with wireless NV2 disconnects. I responded saying that the ethernet port flapping was fixed in 5.4, I upgraded to 5.4 and the ethernet problem was fix but I still have wireless disconnect issues.

So to sum it up.

5.4 fixed the ethernet problem caused by 5.3

5.4 did not fix the NV2 wireless disconnects that myself and numerous others have with NV2. This is the problem that MT can't reproduce.

@ Chadd I am confused from reading replies by Normis (a) MK could not reproduce the issue (b) Email support (c) Problem identified and fixed in V5.4, but reading your reply today have you tried 5.4 and is this issue still present

Don't know, don't think so. Not using Airmax solved most of the problem and changing to lower 5Ghz band freq. has done the rest. But antenna is still NSloco which I presume has two antennas, H+V pol.
I don't have sophisticated tools to really measure what is going on in spectrum. All I can do is use the tools and info given to me by the antenna and the real life experience with some common sense...

One quick test if using vertical polarity is to rotate the second off vertical by say 20-40 degree's (similiar to rotating a telescopic Fm antenna to improve reception) and check if disconnects still occur?

As Normis mentioned he recommended I upgrade to 5.3 as it may fix some of the disconnect issues. I upgraded and then also had ethernet port flapping problems along with wireless NV2 disconnects. I responded saying that the ethernet port flapping was fixed in 5.4, I upgraded to 5.4 and the ethernet problem was fix but I still have wireless disconnect issues.

So to sum it up.

5.4 fixed the ethernet problem caused by 5.3

5.4 did not fix the NV2 wireless disconnects that myself and numerous others have with NV2. This is the problem that MT can't reproduce.

Chadd i assume you have upgraded your firmware as well
/system routerboard> print

Hey guys this is my first post... so go easy...

I have been a WISP for 6 years as of July of this year... for what it is worth.. in this industry who knows! Anyway... we have been running StarOS for most all of our time as a WISP. We are now in the process of coverting our complete network, (20 AP's) over to MT. We took one AP and ran a RB493G with XR2 and XR5 cards in a combo Radio Waves 2.4/5.8 sector. We went out to every customer and changed out the CPE's to RB411 brds (2ea. 133 brds) 25ea. total. We have all arc wirless 19db panels with DBii Pro 20's, bout 15ea., xr's, bout 5ea., and Enq. 8602s (think that is correct #?), bout 5ea. We ran also ran Nv2. We ran this setup for a while until we started havin some 'dropped' client issues plus some other issues. Then one morning the AP crashed (bout a 30 day period). To make a long story short we determined we had a bad Cat5e cable going up to AP. By this time the RB493G was acting very flakey... can't blame the board... we had a cable full of moisture.

So... we changed cable... put a RB435G in the place of the RB493G and put back the XR2 and XR5 cards. Unit has been very stable ever since... 4 days now. Thennnnnnnn... this morning noticed some 2.4 clients popping on and off. I remebered that my Engineer had changed the "Distance Timeout" (under advanced) in the AP setting to 00:00:07 instead of :03 in the RB493G setup. So I went back into the new RB435G this morning and changed the "Distance Timeout" on the new RB435G to 00:00:07 and the clients have stopped dropping. I also went into the 4 or so clients that were getting dropped and changed their time out to :07 also. But they were not dropping after I changed the AP only.

Now.... it has only been 1 hour since I have done this so you all know what that means... but I do remember that when we changed this before it helped a lot. Also I don't know about you guys, and maybe some gals, but I almost always forget to check for the things that can cause problems that we very seldom tend to look at becasue normally they are stable... like, cabling, constant power from a POE (this was one of our problems from bad cable... power up and down), connectors, grd blocks, etc. BTW... what forced the cabling issue for us was we have had almost 30 inches of rain int the last 60 days. We are located in the very Northwest of Arkansas... just 1 hour from Joplin Mo. that was hit by the worst tornado in the history of records... man has it been raining!!

So anyway... I do hope we all keep this thread open until we are convienced that the 'dropping issue' is a 'non issue.

Thanks in advance for your time... don't know bout you all but I never seem to have enough of it. ~ R

P.S. Just checked AP before submitting this.. now bout 1 1/4 hours and all still good.

Hey guys this is my first post... so go easy...

So... we changed cable... put a RB435G in the place of the RB493G and put back the XR2 and XR5 cards. Unit has been very stable ever since... 4 days now. Thennnnnnnn... this morning noticed some 2.4 clients popping on and off. I remebered that my Engineer had changed the "Distance Timeout" (under advanced) in the AP setting to 00:00:07 instead of :03 in the RB493G setup. So I went back into the new RB435G this morning and changed the "Distance Timeout" on the new RB435G to 00:00:07 and the clients have stopped dropping. I also went into the 4 or so clients that were getting dropped and changed their time out to :07 also. But they were not dropping after I changed the AP only.

I think you are probably talking about disconnect timeout, I have played with this setting and think on the AP I have been talking about it is currently set to 6seconds. That particular setting doesn't seem to help with the NV2 timeout disconnects. Setting that number too high can also tie up your AP because that is how long your AP waits to disconnect a client after unsuccessful attempts at transmitting data to the Client. It is based off of three settings I think.

HW retries:
On Fail Retry Time:
Disconnect Timeout:

Yes Sir... you are correct.. Disconnect Timeout my mistake. Let me share the latestest update with you. After studying the Disconnect Timeout function I came to the same conclusion as you stated... and I also did some ping testing and proved that to be the case. I have since gone back and set my D_T_out to :05 and reset my distance to 2 miles past the distance of the fartherest customers location. We have fresnal (sp?) issues as well as we are in the mountains and have bad foliage problems so the extra distance seems to help. I don't know that much about routerOS... yet... but after 6 years around wless we have always had better luck setting AP distance a bit past the longest connection.

Here are the results of the latest settings: 1: Pings are back to an acceptable level... of course we noticed with Nv2 it seems pings will take a back seat to TCP traffic... and that is ok with me. 2: Disconnects are still happening but less than at :03. 3. The only disconnects I am getting out of 25 clients on 2.4 are the 4 Worst Siganls (I believe this note is very important). The Worst signals are the clients that are being disconnected also... I have to believe this is relevent to the disconnects, in my case anyway.

I know I am not the best 'Tech' type to be posting on this forum but I have come to the conclusion that most all of the trouble shooting I have done for my 30 years as a field tech involved with cabling recing signal and processing that signal that I must make sure all of the components that I can control are 100%. Sooooo... with that said I am going to go with my field tech to these locations (customers dropping off the AP) and replace the radio cards in the units and the cabling at the customers houses. With this done then I will feel I have given the MT Engineer's the best field situation so they might be able to look at something on the software end. I also believe (this is just me) it would be near impossible for a software Engineering team to duplicate "Every" problem as a WISP I can, or could have. I have used other software to run my WISP and 'hands down' the routerOS ROCKS!! I love it!

Also my Engineer is going to take the log files from this AP, I think he said every 5 mins., so we will have numbers, time of day, etc. to help run down problems we are having. I am very interested in this post since my future as a company depends on how well our new MT AP's work. I do know that when I can run 8 simaltanious 512 to 1meg connections on a 2.4 AP with full through put on all 8 that Nv2 is what I want on my network... very impressive software.

To be continued... thanks to all... ~ R

I think you are probably talking about disconnect timeout, I have played with this setting and think on the AP I have been talking about it is currently set to 6seconds. That particular setting doesn't seem to help with the NV2 timeout disconnects. Setting that number too high can also tie up your AP because that is how long your AP waits to disconnect a client after unsuccessful attempts at transmitting data to the Client. It is based off of three settings I think.

HW retries:
On Fail Retry Time:
Disconnect Timeout:

All these settings have no meaning in AP running NV2: http://forum.mikrotik.com/viewtopic.php ... 03#p251203

@ chadd

Can you post your reading under wireless tab a "scan", i would like to check is signal, noise, freq
You may ask why but i have a suspicion that the timing disconnects could be linked to a noisy tower, one of my masts was working very good with NV2 (5 Ap’s + 2 PTP’s) but attached extra 2 PTP’s and 2 AP’s had hourly disconnects and one had every 4 or so hours disconnects, only one with the narrowest TX/RX (10°)
beam did not suffer, the rest have 90° RX/TX beam

For me a temp solution was to use a rotation of wireless protocols AP1 =802.11, AP2 =NV2, AP3 =802.11, etc
And for my issues I am going to concentrate on the reduction of unwanted signal levels?

http://forum.mikrotik.com/viewtopic.php?f=7&t=49835

This area is for sure noisy and I am sure most of the issues are related to that. But IMO NV2 should work at least as good if not better than Nstreme and straight 802.11 when dealing with noise. But in my experience NV2 will not handle noise well at all.

@ chadd

Can you post your reading under wireless tab a "scan", i would like to check is signal, noise, freq
You may ask why but i have a suspicion that the timing disconnects could be linked to a noisy tower, one of my masts was working very good with NV2 (5 Ap’s + 2 PTP’s) but attached extra 2 PTP’s and 2 AP’s had hourly disconnects and one had every 4 or so hours disconnects, only one with the narrowest TX/RX (10°)
beam did not suffer, the rest have 90° RX/TX beam

For me a temp solution was to use a rotation of wireless protocols AP1 =802.11, AP2 =NV2, AP3 =802.11, etc
And for my issues I am going to concentrate on the reduction of unwanted signal levels?

http://forum.mikrotik.com/viewtopic.php?f=7&t=49835

This area is for sure noisy and I am sure most of the issues are related to that. But IMO NV2 should work at least as good if not better than Nstreme and straight 802.11 when dealing with noise. But in my experience NV2 will not handle noise well at all.

I am not sure NV2 will handle noise better than nstreme or 802.11, all i can say is my disconnects are directly related to other stuff on my mast and as mentioned NV2 was working OK but when i added extra ptp's it triggered disconnects again,

There is a very interesting comment made about NV2 in this thread
http://forum.mikrotik.com/viewtopic.php ... nd#p231060

nv2 doesn't play nice. it wants the whole playground to itself.

What happens if I share a tower with other WISPs?

Are we now in a race to see who can implement NV2 first? If the other guys beat me to it, will my links become unusable?

From the documentation:

As NV2 does not use CSMA technology it may disturb any other networks in the same channel. In the same way other networks may disturb NV2 network, because every other signal is considered noise

http://wiki.mikrotik.com/wiki/NV2#Compa ... _protocols

On a mast with multiples of AP's + Ptp's unwanted signal isolation or reduction from the others is a must, for me i have to increase from -11dbm to a least -30+, on Ptp's where noise is picked up between the link then the use of reduced beamwidth antenna's, the height at each location and every step is taken to select a area with minimum unwanted signal pickup, then NV2 can it's "playground" to play fair?

@n21roadie:
The thread you refer to made me realize about half a year ago that I'd better start using NV2 too! Since competition is using Airmax which is in fact having same sort of effect (also tdma) and I have been reading that Motorola's same tdma technology for years already ´blasts´ other spectrum users away....

And than I ran into the disconnection problems. In my region all 5Ghz 20Mhz channels are used, sometimes even double or 3 times. (By me separated moderately, and by the ´others´ overshooting my masts!)
I played for a month to realize it all had to do with interferences and the more ´aggressive´ tdma behaviour.
So I started to make my networks more resisting interferences and to be sure to use tdma myself wherever possible! I am now almost completely free of the disconnects issue while the area only saw more usage from radio's in 5Ghz band! I only have one network left which has several NS5's to be replaced and thus not on NV2 yet. Here is the last where I still see disconnects appear.

My approach was to ´harden´ radio links as much as possible against interferences by shielding, separation and concentration:

- Use 10Mhz channel wherever possible instead of 20Mhz.
- Use as much channel separation as possible with close range AP's or on same towers
- Always use ´connect-to´ in stations and make 2 rules. 1 for the SSID and one for the mac of the AP. (In case the SSID frame my become corrupt due interference next rule makes sure it picks the mac in the frames, or vice versa.)
- Always use the ´access-list´ in the AP.
- Use fixed ARP listing in stead of dynamic. (I found suddenly some IP-mac bonds that could not be. Either intruders or maybe corrupted frame made mac to read a little different? Who knows!
- Use ´management frame protection´ in 802.11 mode and NV2 security in tdma networks. (It helps!)
- Use ´Scan list´ in CPE's. If radio disconnect it comes back faster but more important, radio only listens on its centre freq. and is therefore better ´concentrated´ to its working freq. Togehter with the 10Mhz channel I think it is a very good tool to get away from 20Mhz band users. They might still have problems with my 10Mhz thouhg! (hehehe)
- Set conn rates in AP. Choose maximal 3 or 4 rates only. The lesser the better since less ´jumping up and down´ for both CPE and AP. It made the links more stable and higher CCQ's from the start. In default rate setting conn. rate took sometimes several seconds to reach higher rates. With poor CCQ as results...
- Use as high as possible gain and directional antenna's. If that mean to lower the gain of radio that is fine! For CPE's use directional antenna's since they are better in ´hearing´ towards where they should and worse in picking up signals they should not pick up in the first place.
- I started to ´shield´ manually (spray paint or alu foil with foam layer) boards+radio better from signals. The cheap ´all-in-one´ CPE boxes are vulnerable to pick up through their plastic back and sides. (Some competitor AP's are right in line, but on the back, of some of my CPE's which had problems. After shielding problems became less.)
- Started to use NV2 wherever possible. (Dumped all nanostations. They had the worse problems anyway and are also responsible for higher physical failure rates)
- Upgraded my whole network to ros5.4 now. Very stable (wireless) version!

If I would give a rate on a 1 to 10 scale I would say my network ran with an 8 a year ago, went down to 5-6 after NV2 / tdma came in the area but am back to 9-9,5 after all the changes I made

(If I'd only could see what the competition has to suffer from now.... hmmm)

Next on the plan is migrating to 802.11a´n´ with nv2! New adventures ahead!

[quote="WirelessRudy" ......

- Use ´Scan list´ in CPE's. If radio disconnect it comes back faster but more important, radio only listens on its centre freq. and is therefore better ´concentrated´ to its working freq. Togehter with the 10Mhz channel I think it is a very good tool to get away from 20Mhz band users. They might still have problems with my 10Mhz thouhg! (hehehe)

- Upgraded my whole network to ros5.4 now. Very stable (wireless) version!

[/quote]
I have tried unsucessfully to have my cpe's scan to another ap on the connect list, when primary ap on the connect list fails, maybe i am doing this incorrectly?

[quote="WirelessRudy" ......

- Use ´Scan list´ in CPE's. If radio disconnect it comes back faster but more important, radio only listens on its centre freq. and is therefore better ´concentrated´ to its working freq. Togehter with the 10Mhz channel I think it is a very good tool to get away from 20Mhz band users. They might still have problems with my 10Mhz thouhg! (hehehe)

- Upgraded my whole network to ros5.4 now. Very stable (wireless) version!

I have tried unsucessfully to have my cpe's scan to another ap on the connect list, when primary ap on the connect list fails, maybe i am doing this incorrectly?[/quote]Well, in that case you have to set both of their freq's in the Scan list.
I do not know how it exactly works but by enabling the Scan list and mentioning one, or more freq's the radio only listens on these freq's. You can set several freq's after each other, just separate them with a comma (,).
You can see the result in the status screen of the wireless window. If in default you see all freq's of the band being scanned, if enabled you only see it try the freq. you want it to use.

[quote][Well, in that case you have to set both of their freq's in the Scan list.
I do not know how it exactly works but by enabling the Scan list and mentioning one, or more freq's the radio only listens on these freq's. You can set several freq's after each other, just separate them with a comma (,).
You can see the result in the status screen of the wireless window. If in default you see all freq's of the band being scanned, if enabled you only see it try the freq. you want it to use.
/quote]
Thanks but unfortunately this is a manual scan of what frequencies the CPE will use, my plan was to have a Auto changeover to another AP on the connect list if the primary Ap was down but not so, the SSID if different from primary AP is the obstacle to this auto change over selection?

Well, in that case you have to set both of their freq's in the Scan list.
I do not know how it exactly works but by enabling the Scan list and mentioning one, or more freq's the radio only listens on these freq's. You can set several freq's after each other, just separate them with a comma (,).
You can see the result in the status screen of the wireless window. If in default you see all freq's of the band being scanned, if enabled you only see it try the freq. you want it to use.

Thanks but unfortunately this is a manual scan of what frequencies the CPE will use, my plan was to have a Auto changeover to another AP on the connect list if the primary Ap was down but not so, the SSID if different from primary AP is the obstacle to this auto change over selection?

Example:
Set in "connect to" list two connect rules, one for each AP, the primary one on top. Set it by either SSID or the AP's mac address.
Next, un-tick the "default auth" box in the wireless interface window (or disable in console).
Now; if the scan list is on default, the radio scans the whole band until it meets the first SSID/mac address in the ´connect to´list. If that AP is not found radio will scan until it meets the second AP SSID/mac and tries to connect. (Special in 10Mhz or 5Mhz bandwidth freq's the scan can take quite some time, special on slow boards.)
Now, to shorten the scan in the "Scan list" set only the two freq's of both of the AP's. Now the radio will only scan on these two frequencies and thus will have a faster change to find one of the AP's SSID/mac and connects to it. It ´listens´ on the freq's of both AP's only!

You now have a fully automated ´scan for best AP´ setup that works fastest.

One tip:
I set for each AP a ´connect-to´ rule with in one its SSID and the other the mac address. So for 2 AP's you'll get 4 rules.
Reason: If you use mac address only and you need to change the radio of the AP (because it is broken), clients won't connect to new radio. You'll have to visit each of them. (If they are not connected to another AP.)
If you use SSID only but due interferences part of that info in the broadcast beacon might get lost the CPE will disconnect.
By setting a rule for both the CPE has, if one of them fails, still the change to connect to AP by the other. So a lesser change of disconnect and a better change to re-connect after disconnection.
This guideline I developed myself because I have the feeling it helps very well in a heavy used spectrum (with lots of interferences).

I set for each AP a ´connect-to´ rule with in one its SSID and the other the mac address. So for 2 AP's you'll get 4 rules.
Reason: If you use mac address only and you need to change the radio of the AP (because it is broken), clients won't connect to new radio. You'll have to visit each of them. (If they are not connected to another AP.)
If you use SSID only but due interferences part of that info in the broadcast beacon might get lost the CPE will disconnect.

When wireless device receives frame (e.g. beacon in this case) it checks frame CRC. That CRC is calculated over whole frame (both - header, that includes mac addresses, and contents, that includes SSID in case of beacon frame), not just part of it. If CRC is incorrect, that frame is not processed any further. So you can not receive "partially correct" beacon frame where mac address is correct, but SSID is wrong. Therefore this 2 rules per AP approach is not necessary - you will achieve the same with just one rule that specifies SSID. Other than that your approach is completely valid and effective in decreasing re-connection time.

I set for each AP a ´connect-to´ rule with in one its SSID and the other the mac address. So for 2 AP's you'll get 4 rules.
Reason: If you use mac address only and you need to change the radio of the AP (because it is broken), clients won't connect to new radio. You'll have to visit each of them. (If they are not connected to another AP.)
If you use SSID only but due interferences part of that info in the broadcast beacon might get lost the CPE will disconnect.

When wireless device receives frame (e.g. beacon in this case) it checks frame CRC. That CRC is calculated over whole frame (both - header, that includes mac addresses, and contents, that includes SSID in case of beacon frame), not just part of it. If CRC is incorrect, that frame is not processed any further. So you can not receive "partially correct" beacon frame where mac address is correct, but SSID is wrong. Therefore this 2 rules per AP approach is not necessary - you will achieve the same with just one rule that specifies SSID. Other than that your approach is completely valid and effective in decreasing re-connection time.

Ok, thanks. Never too old to learn. So for hardening the connection it is no use. Is there any difference in choosing either the SSID classifier or the mac address in the ´connect-to´ lists?
Maybe a wise idea to use both the classifiers in one ´connect-to´ rule?
Pro's and con's of each of these 3 options?

Ok, thanks. Never too old to learn. So for hardening the connection it is no use. Is there any difference in choosing either the SSID classifier or the mac address in the ´connect-to´ lists?
Maybe a wise idea to use both the classifiers in one ´connect-to´ rule?
Pro's and con's of each of these 3 options?

By the time client has finished scanning and chooses AP to connect to, it knows both - SSID and mac-address of every AP it sees. So the classifiers used in connect-list does not affect how client is scanning, it only affects how client chooses AP from the list obtained during scanning. Effect of connect-list on client performance is negligible no matter what classifiers you use, as long as you do not create unreasonable amount of connect-list rules.

What classifiers to use depends completely on logic you want clients to use when connecting. Specifying both - SSID and mac-address can be considered "strongest" way to specify particular AP. If you use this combination, client will not connect to other AP (e.g. rogue AP with same SSID and stronger signal). On the other hand - like you already wrote, when you specify only SSID, you have the ability to change AP without reconfiguring clients. Of course, you can strengthen your setup against rogue, same SSID, stronger signal AP by creating 2 rules - one with mac and SSID and second only with SSID. This way rogue AP will only be able to cause client to connect to it if it will make client not see the correct AP, but if you will decide to replace AP, client will still connect with second rule and you can go and update connect-list to new AP.

I would say that you may want to use mac-address matcher if there are (or there are chances that there may be) multiple APs with the same SSID in range. If that is not the case then mac-address matcher is of no use.

I have a really great idea..

How about we fix the disconnect issues so how long it takes to reconnect doesn't matter. I mean really we are talking about how to "speed up" re connections that shouldn't be happening in the first place.

I have an AP and 3 clients that are open waiting for Uldis to log into that are having disconnect issues.

The disconnects are a huge problem here guys, why do you think there are so many people on the forums trying to work around them with all different settings and such? I have tried every setting under the sun and nothing helps with the disconnects.

Ok, thanks. Never too old to learn. So for hardening the connection it is no use. Is there any difference in choosing either the SSID classifier or the mac address in the ´connect-to´ lists?
Maybe a wise idea to use both the classifiers in one ´connect-to´ rule?
Pro's and con's of each of these 3 options?

By the time client has finished scanning and chooses AP to connect to, it knows both - SSID and mac-address of every AP it sees. So the classifiers used in connect-list does not affect how client is scanning, it only affects how client chooses AP from the list obtained during scanning. Effect of connect-list on client performance is negligible no matter what classifiers you use, as long as you do not create unreasonable amount of connect-list rules.

What classifiers to use depends completely on logic you want clients to use when connecting. Specifying both - SSID and mac-address can be considered "strongest" way to specify particular AP. If you use this combination, client will not connect to other AP (e.g. rogue AP with same SSID and stronger signal). On the other hand - like you already wrote, when you specify only SSID, you have the ability to change AP without reconfiguring clients. Of course, you can strengthen your setup against rogue, same SSID, stronger signal AP by creating 2 rules - one with mac and SSID and second only with SSID. This way rogue AP will only be able to cause client to connect to it if it will make client not see the correct AP, but if you will decide to replace AP, client will still connect with second rule and you can go and update connect-list to new AP.

I would say that you may want to use mac-address matcher if there are (or there are chances that there may be) multiple APs with the same SSID in range. If that is not the case then mac-address matcher is of no use.

I have a really great idea..

How about we fix the disconnect issues so how long it takes to reconnect doesn't matter. I mean really we are talking about how to "speed up" re connections that shouldn't be happening in the first place.

True. But a strict ´connect-to´ list is only a part of it. As you can see in my list http://forum.mikrotik.com/viewtopic.php ... 91#p266791 I have done many more and all my disconnects are gone.

I live in a valley with a radius of abt. 10-15km max
I have 18 AP's in that valley, all 10Mhz channels, I have 17 backhaul links to reach all these AP's. Most run on 20Mhz, 1 bonded link (2 x 20Mhz channel) and 2 ´n´ links (40Mhz) and I can only use the upper 5ghz band which is only 200Mhz wide!
Apart from that, I have seen in the valley at least another dozen channels used by others. Some plain 802.11a back hauls and AP's and also some 6 Airmax tdma AP's overshooting the whole valley fm the mountains.
And I think I have one or two WiMax providers working in the adjacent 5.8Ghz band.

All my radio's are at the bottom of the valley in small just tree protruding towers or on roofs of houses. Hence I need so many cells. The `big´ brothers use some hight points (+600 mtrs) on the surrounding mountains and therefore overshoot all my AP's with their signals.

If I run ´snooper´ for a while on any of my radio's, I easy pick up 15-20 relative strong AP-channels and same amount traces of channels.
Running a scan on any of my omni AP's spread through the valley I always pick up 3 or 4 other channels with strengths of -70 or even much better (up to -40!).

As I explained, I was really hammered with disconnects all over the place some year ago when I started to use nv2 and the competition came with their Airmax units.
But now, by implementing all the suggestions made in the post referred too I have no more problems with disconnects. NV2 with encryption and 10Mhz wherever possible did for me most of the job. But all the other settings will also help.
All my AP's run 10Mhz with NV2 and NV2 is also used on most of the back hauls.

As I wrote somewhere else in this forum, the introduction of tdma protocols and the software and drivers to deliver it, imho also made radio's more sensitive for ´foreign´ signals, specially if they are also NV2. Some even stated NV2 is more "aggressive" and "you'd better be the first to use it!".
That doesn't mean it is a failure or downgrade of the radio/software, you just have to be more careful in how your network is setup.
But, on the other hand, some have the idea some chip-sets perform less than they should, or could, with NV2. So yeah, things are always open for further improvements....., probably both on the OS, the drivers and the chip-sets themselves...

As I wrote somewhere else in this forum, the introduction of tdma protocols and the software and drivers to deliver it, imho also made radio's more sensitive for ´foreign´ signals, specially if they are also NV2. Some even stated NV2 is more "aggressive" and "you'd better be the first to use it!".
That doesn't mean it is a failure or downgrade of the radio/software, you just have to be more careful in how your network is setup.
But, on the other hand, some have the idea some chip-sets perform less than they should, or could, with NV2. So yeah, things are always open for further improvements....., probably both on the OS, the drivers and the chip-sets themselves...

Rudy,

Thanks for the tips and suggestions, they are appreciated. You are fighting the same battle as myself and countless others using MT for wireless. My comment wasn't directed toward you but to Mikrotik support. It is frustrating to see them chime in on the best way to setup a connect list in a thread where someone is asking for help with disconnects, when they haven't address the disconnect issue.

Our area has quite a bit of noise also and I have tried every setting under the sun. I have been using MT for ~7 yrs and as mentioned in other threads I have been fighting disconnects in one shape or form that whole time, nothing nearly as bad as the NV2 disconnect problems though. So I know the tricks of the trade to combating Disconnects, but it is always nice to see how someone else is trying to deal with it.

As far as being the first to use TDMA that makes no difference what soever because at some point in time everyone will be using some sort of TDMA protocol. So if NV2 can't coexist with itself where does that leave it when dealing with other TDMA players?

Thanks,
Chadd

then you'll be forced to use motorola gear, it always seems to kick butt when interference is concerned.

then you'll be forced to use motorola gear, it always seems to kick butt when interference is concerned.

The problem with Moto is limited throughput. The OFDM gear isn't nearly as resilient when it comes to noise, it also requires more signal to noise than the older gear.