I solved all my NV2 AP disconnects by improving each AP antenna enclosure shielding from each other this has reduced the signal pickup from the other AP's and stopped NV2 disconnects,Hello.
Still is there problem that causes disconnects on links with NV2 !!
A lot of solved with MK support.
Links have good signal (-50 - 60), good CCQ but still disconnect, not responding. Problem persist in all version 5.x (also in 5.14)
It happens on 200meters links (with a sextant), but also on the 9 km links with high-quality parabolic antenas.
This is reflected in the single 802.11N but also in the N 2x2. If on the same link is NV2 disabled, there is NO problem with disconnect.
http://ispforum.cz/download/file.php?id=1656
http://ispforum.cz/download/file.php?id=1652
http://ispforum.cz/download/file.php?id=1653
Have anyone same problems? Thank you
This NV2 link works on channel 5680. There is NO network on same chanel. See scan...I solved all my NV2 AP disconnects by improving each AP antenna enclosure shielding from each other this has reduced the signal pickup from the other AP's and stopped NV2 disconnects,
http://forum.mikrotik.com/viewtopic.php ... it=rx%2Ftx
Never had NV2 disconnects with grids but I moved them as far apart from the AP's on the mast,
When you scan from each antenna what is the pickup signal level from this scan of other nearby units,
I also hope!I have the same problem (perfect db -53 to -60, not noise, etc.) ... I'm looking for 5.15 every day with the hope of a fix...
Have you tried moving this effected antenna to another nearby location (even on a temporary mast) and checking.Dear MT team.
How do we report this problem? Via email no answer from support.
I have generated supout.rif after disconnect with 5.15rc1(12.April) and still disconnect.
Thanks
It's not a problem "one link".Have you tried moving this effected antenna to another nearby location (even on a temporary mast) and checking.
Is this happening on just one mast with ptp's + ptmp's AP's or several masts, also when you updated OS version have you updated firmwareIt's not a problem "one link".Have you tried moving this effected antenna to another nearby location (even on a temporary mast) and checking.
The problem occurs in most links (PTP) and a large number of sector antenas (Point To Multipoint)
there have been made multiple Nv2 stability improvements since v5.8.In my opinion you are all wasting your time trying to find a fix - we have done extensive field testing and have found the ONLY successful NV2 installations are way out in the country where there is NO other RF - we have concluded that NV2 is extremely susceptible to even the slightest of interference. Having said that we gave up testing at ROS 5.8 so it is possible they have improved it since then.
As for NV2 improvements since 5.8, if they are worth trying, why are they not documented in change log...
A very interesting comment can I ask have you got a 5-6 GHz spectrum usage graph to support this theory, I certainly haven’t wasted my time in fixing my NV2 disconnects as it’s now working perfectly.In my opinion you are all wasting your time trying to find a fix - we have done extensive field testing and have found the ONLY successful NV2 installations are way out in the country where there is NO other RF - we have concluded that NV2 is extremely susceptible to even the slightest of interference. Having said that we gave up testing at ROS 5.8 so it is possible they have improved it since then.
to my best knowledge the hw-retries are ignored by NV2 (and nstreme too)...Have you tried to increase hw-retries? What data-rates have you selected?
I mentioned this before, why cannot MT just grey out any wireless setting not used when NV2 protocol is selected.to my best knowledge the hw-retries are ignored by NV2 (and nstreme too)...Have you tried to increase hw-retries? What data-rates have you selected?
VAP does not work with NV2 protocol, which is a pity.Hi I have the following problem.
I have put all clients in the NV2 Nstream 802.11 protocol. Then when AP is still in any protocol clients can still connect to the VAP on the distribution, but as soon as I change the AP to NV2 protocol all clients disconnect. Clients only register when AP is back to any protocol.
Can anyone please help in this regard? Maybe I'm doing something wrong.
Thank you.
Thank you. Good to hear this message.we will try to do some more testing with 2x2 on Nv2 protocol.
For other that has problems with disconnection, you also use 2x2, or it is also happening for one stream operations?
send to supportplease provide us support output file in a new support ticket about this router.
We need support output file from this AP and as well from those 6 clients.
distance is from 34meters to about 500metersLooking at the signals (tx/rx) from registered clients from -36 upwards, what distance is these clients from the AP.
Also fourth client down -52/-65 after 5.30 minutes rx/tx rate of 6Mbps should be higher
You working with this setup in N 2x2 ?Try to setup connection without QAM-64 and is much better now.
See settings in attachment (must disable MCS 5-7, and MCS 13-15 - on basic rates too).
rate selection algorithm: advanced
You say mostly shielded can I ask have you shielded the SXT as this is the first item to start with and there is two methods external or internal, I have attached two pictures one for external shielding for a Sextant and my own internal shielding of a SXT using first 25mm copper strip painted over with conductive paint and earthed back to the board, which before shielding was picking up signals from AP’s from the rear of the SXT but after screening they were not.................... Setup is in (mostly shielded (6m underground)) laboratory, both clients are SXTs. I also saw a post about lowering the TX power on wiki, tried that, didn't help (not even a tiny bit)
You probably know where I'm going - from this view it really totally looks like a hardware problem (on ~30% of new wireless cards!). Please tell me it's not :].................................
Thanks :]
-exa
Hello. We have still problems on P2MP links. It is 802.11N with NV2
clients who have ROS 5.9 are most stable then clients with 5.19.
Any client when is downgraded to 5.9 - then have good uptime and little disconnect.
With 5.18 and 5.19 a lot of problems with disconnect
Have anybody the same problem?
The same problem with 5.20rc1. Have you used it in multipoint (AP Bridge) ?Hello. We have still problems on P2MP links. It is 802.11N with NV2
clients who have ROS 5.9 are most stable then clients with 5.19.
Any client when is downgraded to 5.9 - then have good uptime and little disconnect.
With 5.18 and 5.19 a lot of problems with disconnect
Have anybody the same problem?
Test Ros 5.20 RC 1 i works!
//Rickard
More bandwidth less bandwidth how much of a difference was there between ROS 5.9, 5.17, 5.19Like others I had a good experience with CPE up to 5.9 with AP at 5.17 (but only with firmware from 5.9 - go figure)
5.17 CPE and AP had fewer disconnects but taking much longer, and less bandwidth
5.19 (CPE/AP) even better uptime, quick 2s reconnect, but less bandwidth
5.19 CPE and 5.17 AP, little less disconnects than 5.9, same bandwidth as 5.9
Looking forward to 5.20
5.17, 5.19 clients interfere with each other. While single client is OK as soon as, in my setup, three start to contend for the bandwidth - throughput drops.More bandwidth less bandwidth how much of a difference was there between ROS 5.9, 5.17, 5.19Like others I had a good experience with CPE up to 5.9 with AP at 5.17 (but only with firmware from 5.9 - go figure)
5.17 CPE and AP had fewer disconnects but taking much longer, and less bandwidth
5.19 (CPE/AP) even better uptime, quick 2s reconnect, but less bandwidth
5.19 CPE and 5.17 AP, little less disconnects than 5.9, same bandwidth as 5.9
Looking forward to 5.20
Using 802.11- hidden node – and interference between clients Ok but not when using NV2 , I use as standard 23db CPE’s for clients and don’t have any NV2 issues maybe because of the narrow beamwidth 23db has.5.17, 5.19 clients interfere with each other. While single client is OK as soon as, in my setup, three start to contend for the bandwidth - throughput drops.More bandwidth less bandwidth how much of a difference was there between ROS 5.9, 5.17, 5.19Like others I had a good experience with CPE up to 5.9 with AP at 5.17 (but only with firmware from 5.9 - go figure)
5.17 CPE and AP had fewer disconnects but taking much longer, and less bandwidth
5.19 (CPE/AP) even better uptime, quick 2s reconnect, but less bandwidth
5.19 CPE and 5.17 AP, little less disconnects than 5.9, same bandwidth as 5.9
Looking forward to 5.20
I get about 10% less with 5.17, 5.19 plus the cumulative bandwidth graph is much more jagged.
I would except there is nothing in the Changelog regarding fixing issues with disconnects and NV2. I can't really afford to try this version just for the heck of it. Your tech support suggest 5.14 a few weeks back when I asked about the problems, that seemed to help with less disconnects, but didn't make them go away. I have also found that not using QAM-64 has helped as well.bac522,
please upgrade to RouterOS v5.20 and report back with the results. Also can you provide us with remote access to your problematic link?
What's new in 5.20 (2012-Aug-15 13:04):
*) manual upgrade to NEW beta poe controller firmware v2.0 for RB750UP and OmniTIK UPA;
more info at http://wiki.mikrotik.com/wiki/Manual:PoE-Out
*) fix RB951-2n wireless issues;
*) ups - fixed resource leak;
here it is:I would except there is nothing in the Changelog regarding fixing issues with disconnects
*) fix RB951-2n wireless issues;
Got it...I'll give it a shot on some less critical PTP links first to see how it works out.here it is:I would except there is nothing in the Changelog regarding fixing issues with disconnects
*) fix RB951-2n wireless issues;
How can this could apply to non RB951-2n hardware? Either you solved something related only to the RB951 (and the changelog line is correct) or you solved something which affects NV2 in general and the line is confusing.here it is:I would except there is nothing in the Changelog regarding fixing issues with disconnects
*) fix RB951-2n wireless issues;
This version didn't solve the problem on a secondary link which was having the same problems. I had been running this link for some time on 5.14 without the disconnects, but after going to 5.20 I started getting disconnects today...might be interference related. I could provide access to these links if need be. I'm going to down rev this link back to 5.14 and see if the problem still happens.bac522,
please upgrade to RouterOS v5.20 and report back with the results. Also can you provide us with remote access to your problematic link?
You have to remember what type of scan you are doing and what it will not report and as such you really cannot take the scan as giving you a full picture of frequency usage because it will only report 802.11 or MT propriety wireless protocol compliant signals and will not show RF devices which could be also transmitting on the band.............................
As for the problematic link, which was my main concern, after turning off QAM-64 and making a frequency change, the link has been rock solid for 4 days without a disconnect. Frequency change shouldn't have matter though as noise floor, SNR and CCQ% were still the same between the different frequencies unless external interference was coming in via the back of the unit.
.....................................................
.
I don't believe that to a correct statement...an signal propitiatory or not would at least be reflected in the noise floor at a minimum. And we do have a quite a few proprietary systems up next to Mtik's and they do seem to notice signals from proprietary systems such as Redline and Solectek.You have to remember what type of scan you are doing and what it will not report and as such you really cannot take the scan as giving you a full picture of frequency usage because it will only report 802.11 or MT propriety wireless protocol compliant signals and will not show RF devices which could be also transmitting on the band.............................
As for the problematic link, which was my main concern, after turning off QAM-64 and making a frequency change, the link has been rock solid for 4 days without a disconnect. Frequency change shouldn't have matter though as noise floor, SNR and CCQ% were still the same between the different frequencies unless external interference was coming in via the back of the unit.
.....................................................
.
In a unlicensed band any RF device can use those frequencies and not only just Wlan equipment, could I ask for example if there was a RF video amp running at 5500 would it show up on a scan and would the noise floor show that 5500 was being used by some RF device which could be analogue and not digital.
I don't believe that to a correct statement...an signal propitiatory or not would at least be reflected in the noise floor at a minimum. And we do have a quite a few proprietary systems up next to Mtik's and they do seem to notice signals from proprietary systems such as Redline and Solectek.
Noise is noise, regardless if analog or digital (although RF is always analog anyways, just depends on how you modulate the signal in the radio wave), so you're noise floor would increase if their is an active signal in the area on the frequency.In a unlicensed band any RF device can use those frequencies and not only just Wlan equipment, could I ask for example if there was a RF video amp running at 5500 would it show up on a scan and would the noise floor show that 5500 was being used by some RF device which could be analogue and not digital.
I don't believe that to a correct statement...an signal propitiatory or not would at least be reflected in the noise floor at a minimum. And we do have a quite a few proprietary systems up next to Mtik's and they do seem to notice signals from proprietary systems such as Redline and Solectek.
Since going back to 5.14 with NV2, the link that was disconnecting on me yesterday with 5.20 has been connected solid now for over 18 hours. Really think something is foo after 5.14 with NV2.This version didn't solve the problem on a secondary link which was having the same problems. I had been running this link for some time on 5.14 without the disconnects, but after going to 5.20 I started getting disconnects today...might be interference related. I could provide access to these links if need be. I'm going to down rev this link back to 5.14 and see if the problem still happens.bac522,
please upgrade to RouterOS v5.20 and report back with the results. Also can you provide us with remote access to your problematic link?
"RF is always analog anyways" does that mean switched-mode transmitter architectures based on baseband PWM coding is analogue?
Noise is noise, regardless if analog or digital (although RF is always analog anyways, just depends on how you modulate the signal in the radio wave), so you're noise floor would increase if their is an active signal in the area on the frequency.
My new favorite configuration: AP ROS5.17, CPE ROS5.20, single CPE ROS5.9 (this one appeared to be taking down every CPE with ROS5.20 when it was on 5.20 and 5.17, go figure)I had to TURN OF nv2 on many 5,6ghz sectors. Now is uptime very good (with 802.11). A lot of days.
When I turn NV2 on - then still disconnect clients. Every hour
Clients and AP = ROS 5.20
that is not true i had version 5.14 previously and now 5.20 and the results are sameI have the same disconnect problem with version 5.20
Version 5.14 better worked and not disconnect in NV2.
read up friend! send an email to support...How do we get 5.21 ?
I have just test with 5.21rc1 - view and rateManyX, why don´t do the same test with the v5.21rc1? is the best version for NV2
[@GASZ_3] > log print
oct/01 08:49:52 wireless,info 00:00:00:00:00:4D@GASZ_3_H: disconnected, not responding
oct/01 08:49:57 wireless,info 00:00:00:00:00:4D@GASZ_3_H: connected
oct/01 08:58:54 wireless,info 00:00:00:00:00:BB@GASZ_3_H: disconnected, not responding
oct/01 08:58:59 wireless,info 00:00:00:00:00:BB@GASZ_3_H: connected
oct/01 09:37:23 wireless,info 00:00:00:00:00:BB@GASZ_3_H: disconnected, not responding
oct/01 09:37:28 wireless,info 00:00:00:00:00:BB@GASZ_3_H: connected
oct/01 10:16:38 wireless,info 00:00:00:00:00:BB@GASZ_3_H: disconnected, not responding
oct/01 10:16:48 wireless,info 00:00:00:00:00:BB@GASZ_3_H: connected
oct/01 10:28:30 wireless,info 00:00:00:00:00:0C@GASZ_3_H: disconnected, not responding
oct/01 10:28:35 wireless,info 00:00:00:00:00:0C@GASZ_3_H: connected
oct/01 10:42:23 wireless,info 00:00:00:00:00:4D@GASZ_3_H: disconnected, not responding
oct/01 10:42:28 wireless,info 00:00:00:00:00:4D@GASZ_3_H: connected
oct/01 11:14:02 wireless,info 00:00:00:00:00:BB@GASZ_3_H: disconnected, not responding
oct/01 11:14:07 wireless,info 00:00:00:00:00:BB@GASZ_3_H: connected
oct/01 11:20:24 wireless,info 00:00:00:00:00:4D@GASZ_3_H: disconnected, not responding
oct/01 11:20:30 wireless,info 00:00:00:00:00:4D@GASZ_3_H: reconnecting
oct/01 11:20:30 wireless,info 00:00:00:00:00:4D@GASZ_3_H: connected
oct/01 11:22:57 wireless,info 00:00:00:00:00:BB@GASZ_3_H: disconnected, not responding
oct/01 11:23:02 wireless,info 00:00:00:00:00:BB@GASZ_3_H: reconnecting
oct/01 11:23:02 wireless,info 00:00:00:00:00:BB@GASZ_3_H: connected
oct/01 12:11:35 wireless,info 00:00:00:00:00:4D@GASZ_3_H: disconnected, not responding
oct/01 12:11:41 wireless,info 00:00:00:00:00:4D@GASZ_3_H: connected
oct/01 12:21:44 wireless,info 00:00:00:00:00:BB@GASZ_3_H: disconnected, not responding
oct/01 12:21:49 wireless,info 00:00:00:00:00:BB@GASZ_3_H: connected
oct/01 12:48:29 wireless,info 00:00:00:00:00:4D@GASZ_3_H: disconnected, not responding
oct/01 12:48:34 wireless,info 00:00:00:00:00:4D@GASZ_3_H: connected
oct/01 13:18:19 wireless,info 00:00:00:00:00:BB@GASZ_3_H: disconnected, not responding
oct/01 13:18:24 wireless,info 00:00:00:00:00:BB@GASZ_3_H: connected
oct/01 13:30:15 wireless,info 00:00:00:00:00:4D@GASZ_3_H: disconnected, not responding
oct/01 13:30:20 wireless,info 00:00:00:00:00:4D@GASZ_3_H: connected
oct/01 14:09:47 wireless,info 00:00:00:00:00:4D@GASZ_3_H: disconnected, control frame timeout
oct/01 14:09:53 wireless,info 00:00:00:00:00:4D@GASZ_3_H: connected
oct/01 14:51:25 wireless,info 00:00:00:00:00:4D@GASZ_3_H: disconnected, control frame timeout
oct/01 14:51:30 wireless,info 00:00:00:00:00:4D@GASZ_3_H: connected
oct/01 15:11:48 wireless,info 00:00:00:00:00:BB@GASZ_3_H: disconnected, control frame timeout
oct/01 15:11:53 wireless,info 00:00:00:00:00:BB@GASZ_3_H: connected
oct/01 15:32:11 wireless,info 00:00:00:00:00:4D@GASZ_3_H: disconnected, control frame timeout
oct/01 15:32:17 wireless,info 00:00:00:00:00:4D@GASZ_3_H: connected
oct/01 16:20:03 wireless,info 00:00:00:00:00:BB@GASZ_3_H: disconnected, not responding
oct/01 16:20:08 wireless,info 00:00:00:00:00:BB@GASZ_3_H: connected
oct/01 16:25:56 wireless,info 00:00:00:00:00:4D@GASZ_3_H: disconnected, not responding
oct/01 16:26:01 wireless,info 00:00:00:00:00:4D@GASZ_3_H: connected
oct/01 17:30:07 wireless,info 00:00:00:00:00:4D@GASZ_3_H: disconnected, not responding
oct/01 17:30:12 wireless,info 00:00:00:00:00:4D@GASZ_3_H: connected
oct/01 18:36:54 wireless,info 00:00:00:00:00:0C@GASZ_3_H: disconnected, not responding
oct/01 18:36:59 wireless,info 00:00:00:00:00:0C@GASZ_3_H: connected
oct/01 19:25:30 wireless,info 00:00:00:00:00:4D@GASZ_3_H: disconnected, not responding
oct/01 19:25:35 wireless,info 00:00:00:00:00:4D@GASZ_3_H: connected
oct/01 19:26:54 wireless,info 00:00:00:00:00:0C@GASZ_3_H: disconnected, not responding
oct/01 19:26:59 wireless,info 00:00:00:00:00:0C@GASZ_3_H: connected
oct/01 19:30:40 wireless,info 00:00:00:00:00:BB@GASZ_3_H: disconnected, not responding
oct/01 19:30:45 wireless,info 00:00:00:00:00:BB@GASZ_3_H: connected
oct/01 20:17:58 wireless,info 00:00:00:00:00:0C@GASZ_3_H: disconnected, not responding
oct/01 20:18:03 wireless,info 00:00:00:00:00:0C@GASZ_3_H: connected
oct/01 20:27:26 wireless,info 00:00:00:00:00:BB@GASZ_3_H: disconnected, not responding
oct/01 20:27:31 wireless,info 00:00:00:00:00:BB@GASZ_3_H: connected
oct/01 20:31:42 wireless,info 00:00:00:00:00:4D@GASZ_3_H: disconnected, not responding
oct/01 20:31:48 wireless,info 00:00:00:00:00:4D@GASZ_3_H: connected
oct/01 21:09:54 wireless,info 00:00:00:00:00:BB@GASZ_3_H: disconnected, not responding
oct/01 21:09:59 wireless,info 00:00:00:00:00:BB@GASZ_3_H: connected
oct/01 21:14:56 wireless,info 00:00:00:00:00:4D@GASZ_3_H: disconnected, not responding
oct/01 21:15:02 wireless,info 00:00:00:00:00:4D@GASZ_3_H: connected
oct/01 21:47:46 wireless,info 00:00:00:00:00:BB@GASZ_3_H: disconnected, not responding
oct/01 21:47:51 wireless,info 00:00:00:00:00:BB@GASZ_3_H: connected
oct/01 22:23:31 wireless,info 00:00:00:00:00:4D@GASZ_3_H: disconnected, not responding
oct/01 22:23:36 wireless,info 00:00:00:00:00:4D@GASZ_3_H: connected
oct/01 22:24:06 wireless,info 00:00:00:00:00:BB@GASZ_3_H: disconnected, not responding
oct/01 22:24:11 wireless,info 00:00:00:00:00:BB@GASZ_3_H: connected
00:22:54 wireless,info 00:00:00:00:00:BB@GASZ_3_H: disconnected, not responding
00:22:59 wireless,info 00:00:00:00:00:BB@GASZ_3_H: connected
00:37:45 wireless,info 00:00:00:00:00:4D@GASZ_3_H: disconnected, not responding
00:37:50 wireless,info 00:00:00:00:00:4D@GASZ_3_H: connected
01:04:53 wireless,info 00:00:00:00:00:BB@GASZ_3_H: disconnected, not responding
01:04:58 wireless,info 00:00:00:00:00:BB@GASZ_3_H: connected
02:44:07 wireless,info 00:00:00:00:00:4D@GASZ_3_H: disconnected, not responding
02:44:17 wireless,info 00:00:00:00:00:4D@GASZ_3_H: connected
04:58:17 wireless,info 00:00:00:00:00:4D@GASZ_3_H: disconnected, not responding
04:58:23 wireless,info 00:00:00:00:00:4D@GASZ_3_H: connected
05:34:31 wireless,info 00:00:00:00:00:4D@GASZ_3_H: disconnected, not responding
05:34:36 wireless,info 00:00:00:00:00:4D@GASZ_3_H: connected
06:26:17 wireless,info 00:00:00:00:00:4D@GASZ_3_H: disconnected, not responding
06:26:22 wireless,info 00:00:00:00:00:4D@GASZ_3_H: connected
06:36:44 wireless,info 00:00:00:00:00:BB@GASZ_3_H: disconnected, not responding
06:36:49 wireless,info 00:00:00:00:00:BB@GASZ_3_H: connected
07:21:20 wireless,info 00:00:00:00:00:4D@GASZ_3_H: disconnected, not responding
07:21:25 wireless,info 00:00:00:00:00:4D@GASZ_3_H: connected
07:31:29 wireless,info 00:00:00:00:00:BB@GASZ_3_H: disconnected, not responding
07:31:34 wireless,info 00:00:00:00:00:BB@GASZ_3_H: connected
08:27:02 wireless,info 00:00:00:00:00:BB@GASZ_3_H: disconnected, not responding
08:27:07 wireless,info 00:00:00:00:00:BB@GASZ_3_H: connected
08:33:28 wireless,info 00:00:00:00:00:BB@GASZ_3_H: disconnected, control frame timeout
08:33:33 wireless,info 00:00:00:00:00:BB@GASZ_3_H: connected
please provide us support output file from that router.That many sector writes is a serious problem specially if the chip can only do 3million writes before its lifetime is over
Is this where in a attempt to have NV2 operational for all types of antenna’s in all situations, performance is sacrificed to cross the board compatibility for antenna’s, maybe I am totally wrong but I have no problems with NV2 since I seriously addressed RF shielding on crowded masts, If I had a problem I would use a spectrum analyser along with analysing AC voltage supply and adding RF suppression beads to DC leads for equipment at the effected site.Hi,
Seems that the improvements I thought v5.21rc1 had apart from solving the disconnect issue don't really exist
The disconnects are not there any more (at least not visible in the log) but the dismal throughput has returned. I can barely transport 1Mbps both ways in UDP bandwidth test using the exact same hardware and config. This is a few days after a successful 24hr bandwidth test running at 10/2Mbps.
Rgds,
Mark.
5.21 is still in RC stage. I hope that 5.21 final will have no problems with speedNow I completely resigned from nv2 and nstreme
every new version on ROS is worse than last
Mikrotik team should focus on wireless because competition is very far in front of.
I also wanted to highlight that competition takes for routers that is more power full
then "cisko" look at advertisement on site
I wish all the best Mikrotik Team.
Shields? Can you give more info?
You should ask support for access to development testing section, it has updated versions each day. since your rc1 there have been some 10 newer releases.Hi,
Do we need to contact support for this release or are we to use the link provided to download the original v5.21rc1 release (which, BTW, does not work anymore)?
Rgds,
Mark.
It should be so as we have removed most of the settings that we could from the winbox that are not used for Nv2 wireless protocol. The same applies for the nstreme protocol. Here you can see the matrix which features/settings are working which what wireless protocol:upgrading from 5.20 to 5.21 with mipsbe.npk there is no hide ssid and most of the advanced settings are gone
downgrading to 5.20 solves the problem
why is that?
1.5 years it's been thereAt long last
No that is not what Uldis said!
Settings that had never any effect on Nv2 have been removed from view. They still work the same as they used to work before. They are available in non-Nv2 modes.
yes the setting values remains the same - they are just not shown in the winbox for that specific wireless protocol.No that is not what Uldis said!
Settings that had never any effect on Nv2 have been removed from view. They still work the same as they used to work before. They are available in non-Nv2 modes.
so if hide ssid is on with the 802.11 protocol and we switch over to nv2 the hide ssid is still on and working even if you dont see it in winbox
The setting remains but it's only applicable to 802.11 mode. If setting is not visible it means that it's not supported.yes the setting values remains the same - they are just not shown in the winbox for that specific wireless protocol.No that is not what Uldis said!
Settings that had never any effect on Nv2 have been removed from view. They still work the same as they used to work before. They are available in non-Nv2 modes.
so if hide ssid is on with the 802.11 protocol and we switch over to nv2 the hide ssid is still on and working even if you dont see it in winbox
correctso no hide ssid in nv2