Several important bugfixes and improvements which are overdue for a long time 
RouterOS v7 will have a new linux kernel, which will allow for more hardware support, and some features and fixes that were not possible before.
RouterOS v7 is currently in early alpha and there is no scheduled release date yet.
Until than I’ll sit on my chair and wait 
while clicking refresh button on mikrotik download page
My Samsung-TV also works with disabled security.
Please tell me if you need any further information, for now i’m reverting to 6.36.3 with wireless-cm2 and enabled security.
Hello,
Changeslog says:
lte - added dlink dwm-157 D, dwm-222 support;
Could you please tell me what device-id or vendor-id. I have a DWM-222 with the following id:
1 device=“1:2” vendor=“Mobile Connect” name=“Mobile Connect” serial-number=“aa51a87072d6” vendor-id=“0x2001” device-id=“0xab00” speed=“480 Mbps” ports=0 usb-version=“2.01”
HEX POE lite, with 6.37 still not recognize it.
Thanks
On my RB751U-2HnD upgraded from 6.36.3 to 6.37.
Now the wlan1 interface is MISSING completely. It is not listed. Only the 5 ethernet ports and the bridge is there. I use the 751 only as an AP.
Of course the wireless package is grey, since there is no wifi defined in /interface.
How do I get back to the old 6.36 version? Downgrade button in packages says to reboot and after reboot, it comes back to 6.37 (of course without wlan card).
How to solve this? This is urgent since the 751 is serving a community centre which I convinced that Mikrotik is “as good” the old Cisco Aironet’s they had.
Before you press the downgrade button you must first download the correct package from the archive section
of the download page (routeros for mips) and upload it to the router files section. Then click on downgrade.
Netinstall ?
I do not need Netinstall. I have full connectivity to the router with Winbox.
But I will try the downgrade with the old version.
Edit:
I downgraded to 6.36 and it worked.
For now, no more upgrades to this RB751… I will wait what Mikrotik support will tell.
It is what I am doing already since a while!
I upgraded a mAP-Lite and a hAP-Lite from 6.36 to 6.37 without any problems with the wireless package (like other users mentioned).
I don’t (never) use the combined package and I was using wireless-rep.
Also I gave IPFIX a try on x86 and seems to be working properly now. Bugs mentioned here seem to have been fixed.
I’ll test it more extensively when time allows for it
Everyone who did lose wireless package or sees it as disabled after upgrade - can you please write to support@mikrotik.com and provide precise steps which you executed to reach such situation. From which version did you upgrade? What kinds of packages precisely were installed on device? How did you upgrade (with check-for-updates, with manual file upload)?
We are testing all kinds of packages and upgrade combinations and are not being able to reproduce such situation. Any information would be very helpful.
Nope, it’s not really fixed. nfacctd spews out tons of notices about wrong flows received.
INFO: expecting flow '16' but received '2' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '17' but received '3' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '18' but received '4' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '19' but received '5' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '20' but received '6' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '21' but received '7' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '22' but received '8' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '23' but received '9' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '24' but received '10' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '25' but received '11' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '26' but received '12' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '27' but received '13' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '28' but received '14' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '29' but received '15' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '30' but received '16' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '31' but received '17' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '32' but received '18' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '33' but received '19' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '34' but received '20' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '35' but received '21' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '36' but received '22' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '37' but received '23' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '38' but received '24' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '39' but received '25' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '40' but received '26' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '41' but received '27' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '42' but received '28' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '43' but received '29' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '44' but received '30' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '45' but received '31' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '46' but received '32' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '47' but received '33' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '48' but received '34' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '49' but received '35' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '50' but received '36' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '51' but received '37' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '52' but received '38' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '53' but received '39' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '54' but received '40' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '55' but received '41' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '56' but received '42' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '57' but received '43' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '58' but received '44' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '59' but received '45' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '60' but received '46' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '61' but received '47' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '62' but received '48' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '63' but received '60' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '60' but received '95' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '110' but received '99' collector=0.0.0.0:2055 agent=X.X.X.X:0
INFO: expecting flow '114' but received '100' collector=0.0.0.0:2055 agent=X.X.X.X:0
Bad sequence numbers?
At least timestamps seem correct.
Also using the combined package (it turns out I use it only in two CCRs after all) I am unable to disable the wireless package no matter how many times I reboot the devices.
This happens on two CCR1036. The log file shows the following weird message but the wireless package remains enabled.
> /log print
jan/01/1970 03:00:12 system,info disabled wireless@-6.37
18:54:35 system,info router rebooted
By weird, I am referring to ‘@’ after wireless.
Both devices were upgraded from v6.36 and had wireless-cm enabled.
It appears that the combined package is the culprit regarding the wireless package problems mentioned by many users.
Hello Normis!
I understand that, we have been running this successfully for nearly 8 years now, but before I even think on upgrade the relatively big wireless infrastructure and network I would in some way understand how this can impact us. If network becomes totally unstable and useless, so will our business so to say.
Till someone can tell me this, all production units will stay on the level they are today.
Anyone out there who can tell their experience by enabling DFS ?
May I please get some more detailed information on DFS - specifically how it related to 6.37
I wish to get a much better understanding on DFS and the possible side-effects prior to upgrading my Mikrotik APs to 6.37
Q - Does DFS have any effect on the CPU load (for AP and/or client) ?
Q - Can DFS have an effect on bandwidth throughput (even if it does not auto-change channels) ?
Q - Does DFS have any effect on client devices ?
Q - How does DFS effect the country (country code - available channels ((super-channel)) ) where an AP is located ?
Q - Does DFS have an effect on Super-Channel settings (frequencies) for an AP ?
Q - If an AP has a scan-list of only one frequency, and DFS detects a radar - what happens ?
Q - What happens for DFS to auto-change frequencies/channels on an AP ?
Q - Is it possible that if a Mikrotik (with 3.37 with DFS) is located near a 2-million-watt military/FAA radar system, that DFS can get false positives resulting in changed channels/frequencies on an AP ?
Q - With 6.37 & DFS, is it possible for an AP in a high-noise environment ( TV stations, FM and AM radio stations and many other APs) to trigger a DFS auto-change-channel ?
Q - May we also get any other additional DFS information not specifically asked ?
I really wish to understand clearly what is happening or may happen with DFS and radar ?
Prior to posting, I did some google searching but many of the answers I have found are vague and not clear.
Thank you
North Idaho Tom Jones
After further testing, by updating pmacct/nfacct to the latest version I don’t get any notices any more.
So I guess the problem was with nfacct.
I’ll continue my tests to verify that IPFIX is working properly.
I upgraded a wireless link yesterday that had been running DFS on 6.36.3 to 6.37 and it stayed in “Detecting Radar” Status. I had to use Superchannel to manually set it. Under 6.36.3 the DFS picked a channel, waited a while to see if radar was present then went into operational mode.
On sites using DFS we set the scan range from “default” to “5500-5680” which is the range that requires DFS. Failing to do this had our links coming up all over the spectrum from 5180 - 5825 even though we started at 5500.
thats sounds quite good plan/strategy.
why don’t you add warm cat/tea and/or wife/family/kids to picture ? for example(just kidding .
Done. We can reproduce it everytime. Check support@mikrotik.com e-mail. Ticket number 2016092822000398.