Page 1 of 1
v5.6 released
Posted: Wed Aug 03, 2011 9:32 am
by normis
What's new in 5.6 (2011-Aug-02 14:45):
*) fixed ssh server crashing when sessions were interrupted
*) ipsec - fix a problem which could silently remove a manual policy
from the kernel if the peer configuration has 'generate-policy' set to 'yes'
and if the policy matches with the traffic selector of a SA being removed
on the responder side, also fix a problem that some generated policies
may stay in kernel after relevant SA was removed;
*) profiler - correctly show idle task on RB1200;
*) webfig - fix dual nstreme interface setting lists;
*) webfig - fix Wireless Access/Connect List editing;
*) webfig - fix bitrate presentation in simple queues (show 1.5M as 1500k);
*) fixed micro-sd access on RB400 not to stop everything else;
*) sstp - when server certificate verification is enabled for sstp client,
it will additionally compare IP addresses found in certificate's
subjectAltName and subject CN to the real address, DNS names are ignored;
*) tftp - optional block counter roll-over support;
*) hotspot - fixed possible crash in case of multiple Radius CoA requests;
*) userman - speedup user deletion with big log size,
note that first userman startup after this update
may take few minutes if the log size is in hundreds of MB;
*) mpls - added support for enabling/disabling control word usage for
BGP based VPLS tunnels (both - Cisco and RFC 4761 based);
*) mpls - added support for auto-discovery of VPLS NLRI encoding method
for Cisco BGP based VPLS tunnels;
*) winbox - sometimes after disconnecting, winbox could not connect back;
*) bgp - allow parallel operation of RFC4761 "l2vpn" and
draft-ietf-l2vpn-signaling "l2vpn-cisco" BGP VPLS variants inside
single peering session.
*) console - ":resolve" command now returns IPv6 address for domain names
that have only IPv6 address records;
*) snmp - provide ups alarms for bad or low battery or for ups overload;
*) route - fixed SNMP getnext queries, were failing to find next
prefix in the OID order;
http://www.mikrotik.com/download.html
Re: v5.6 released
Posted: Wed Aug 03, 2011 10:21 am
by Chupaka
Normis, why are files of mipsle the only in separate directory? it was in 5.5 release, it's in 5.6... When you changed all WinBox menus to alphabetical order - it was a bit uncomfortable for the first times, but then it appeared to be very cosy. But I bet nobody likes when all packages are in one heap!.. It's very easy to mis-select package for another platform when uploading new version... And it wastes space when you try to make your own per-platform folders and have to leave original files in place for torrent seeding...
Re: v5.6 released
Posted: Wed Aug 03, 2011 10:27 am
by TKITFrank
Hi Normis,
Is ticket #2011062866000285 fixed in this release?
Re: v5.6 released
Posted: Wed Aug 03, 2011 10:27 am
by janisk
recreating torrent file, so files are in folders as expected.
edit: 10:40 EEST torrent file is corrected. You should re-download the file.
Re: v5.6 released
Posted: Wed Aug 03, 2011 10:28 am
by normis
Hi Normis,
Is ticket #2011062866000285 fixed in this release?
edit, this should be fixed.
Re: v5.6 released
Posted: Wed Aug 03, 2011 10:49 am
by Chupaka
recreating torrent file, so files are in folders as expected.
edit: 10:40 EEST torrent file is corrected. You should re-download the file.
nice, thanks!
Re: v5.6 released
Posted: Wed Aug 03, 2011 11:19 am
by oeyre
Are there any changes relating to #2011062966000309 in this release?
Re: v5.6 released
Posted: Wed Aug 03, 2011 12:21 pm
by mrz
Are there any changes relating to #2011062966000309 in this release?
No, it will be fixed in one of the future releases.
Re: v5.6 released
Posted: Wed Aug 03, 2011 3:46 pm
by muadib
Hello,
After update from 5.5 i'm getting lots of layer7 erros:
log print
13:43:55 firewall,warning layer7 match failed, regexp too complex (^(.?.?\16\03.*\16\03|.?.?\01\03\01?.*\0B))
13:43:56 firewall,warning layer7 match failed, regexp too complex (^(.?.?\16\03.*\16\03|.?.?\01\03\01?.*\0B))
13:43:56 firewall,warning layer7 match failed, regexp too complex (^(.?.?\16\03.*\16\03|.?.?\01\03\01?.*\0B))
13:43:56 firewall,warning layer7 match failed, regexp too complex (^(.?.?\16\03.*\16\03|.?.?\01\03\01?.*\0B))
13:43:56 firewall,warning layer7 match failed, regexp too complex (^(.?.?\16\03.*\16\03|.?.?\01\03\01?.*\0B))
13:43:56 firewall,warning layer7 match failed, regexp too complex (^(.?.?\16\03.*\16\03|.?.?\01\03\01?.*\0B))
13:44:00 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:00 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:00 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:00 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:00 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:00 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:00 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:02 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]*ftp)
13:44:02 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:02 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]*ftp)
13:44:02 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:02 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]*ftp)
13:44:02 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:02 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]*ftp)
13:44:02 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:02 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]*ftp)
13:44:03 system,info,account user admin logged in from 192.168.6.250 via telnet
13:44:03 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:03 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]*ftp)
13:44:03 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:03 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]*ftp)
13:44:03 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:12 firewall,warning layer7 match failed, regexp too complex (^(.?.?\16\03.*\16\03|.?.?\01\03\01?.*\0B))
13:44:12 firewall,warning layer7 match failed, regexp too complex (^(.?.?\16\03.*\16\03|.?.?\01\03\01?.*\0B))
13:44:12 firewall,warning layer7 match failed, regexp too complex (^(.?.?\16\03.*\16\03|.?.?\01\03\01?.*\0B))
13:44:12 firewall,warning layer7 match failed, regexp too complex (^(.?.?\16\03.*\16\03|.?.?\01\03\01?.*\0B))
13:44:12 firewall,warning layer7 match failed, regexp too complex (^(.?.?\16\03.*\16\03|.?.?\01\03\01?.*\0B))
13:44:12 firewall,warning layer7 match failed, regexp too complex (^(.?.?\16\03.*\16\03|.?.?\01\03\01?.*\0B))
13:44:12 firewall,warning layer7 match failed, regexp too complex (^(.?.?\16\03.*\16\03|.?.?\01\03\01?.*\0B))
13:44:13 firewall,warning layer7 match failed, regexp too complex (^(.?.?\16\03.*\16\03|.?.?\01\03\01?.*\0B))
13:44:13 firewall,warning layer7 match failed, regexp too complex (^(.?.?\16\03.*\16\03|.?.?\01\03\01?.*\0B))
13:44:13 firewall,warning layer7 match failed, regexp too complex (^(.?.?\16\03.*\16\03|.?.?\01\03\01?.*\0B))
13:44:13 firewall,warning layer7 match failed, regexp too complex (^(.?.?\16\03.*\16\03|.?.?\01\03\01?.*\0B))
13:44:13 firewall,warning layer7 match failed, regexp too complex (^(.?.?\16\03.*\16\03|.?.?\01\03\01?.*\0B))
13:44:13 firewall,warning layer7 match failed, regexp too complex (^(.?.?\16\03.*\16\03|.?.?\01\03\01?.*\0B))
13:44:13 firewall,warning layer7 match failed, regexp too complex (^(.?.?\16\03.*\16\03|.?.?\01\03\01?.*\0B))
13:44:17 firewall,warning layer7 match failed, regexp too complex (http/(0\.9|1\.0|1\.1) [1-5][0-9][0-9] [\t-\r -~]*(connection:|content-type:|content-length:|date:)|post [\t-\r -~]
* http/[01]\.[019])
13:44:17 firewall,warning layer7 match failed, regexp too complex (http/(0\.9|1\.0|1\.1) [1-5][0-9][0-9] [\t-\r -~]*(connection:|content-type:|content-length:|date:)|post [\t-\r -~]
* http/[01]\.[019])
13:44:17 firewall,warning layer7 match failed, regexp too complex (http/(0\.9|1\.0|1\.1) [1-5][0-9][0-9] [\t-\r -~]*(connection:|content-type:|content-length:|date:)|post [\t-\r -~]
* http/[01]\.[019])
13:44:17 firewall,warning layer7 match failed, regexp too complex (http/(0\.9|1\.0|1\.1) [1-5][0-9][0-9] [\t-\r -~]*(connection:|content-type:|content-length:|date:)|post [\t-\r -~]
* http/[01]\.[019])
13:44:17 firewall,warning layer7 match failed, regexp too complex (http/(0\.9|1\.0|1\.1) [1-5][0-9][0-9] [\t-\r -~]*(connection:|content-type:|content-length:|date:)|post [\t-\r -~]
* http/[01]\.[019])
13:44:17 firewall,warning layer7 match failed, regexp too complex (http/(0\.9|1\.0|1\.1) [1-5][0-9][0-9] [\t-\r -~]*(connection:|content-type:|content-length:|date:)|post [\t-\r -~]
* http/[01]\.[019])
13:44:17 firewall,warning layer7 match failed, regexp too complex (http/(0\.9|1\.0|1\.1) [1-5][0-9][0-9] [\t-\r -~]*(connection:|content-type:|content-length:|date:)|post [\t-\r -~]
* http/[01]\.[019])
13:44:17 firewall,warning layer7 match failed, regexp too complex (http/(0\.9|1\.0|1\.1) [1-5][0-9][0-9] [\t-\r -~]*(connection:|content-type:|content-length:|date:)|post [\t-\r -~]
* http/[01]\.[019])
13:44:17 firewall,warning layer7 match failed, regexp too complex (http/(0\.9|1\.0|1\.1) [1-5][0-9][0-9] [\t-\r -~]*(connection:|content-type:|content-length:|date:)|post [\t-\r -~]
* http/[01]\.[019])
13:44:17 firewall,warning layer7 match failed, regexp too complex (http/(0\.9|1\.0|1\.1) [1-5][0-9][0-9] [\t-\r -~]*(connection:|content-type:|content-length:|date:)|post [\t-\r -~]
* http/[01]\.[019])
13:44:17 firewall,warning layer7 match failed, regexp too complex (http/(0\.9|1\.0|1\.1) [1-5][0-9][0-9] [\t-\r -~]*(connection:|content-type:|content-length:|date:)|post [\t-\r -~]
* http/[01]\.[019])
13:44:17 firewall,warning layer7 match failed, regexp too complex (http/(0\.9|1\.0|1\.1) [1-5][0-9][0-9] [\t-\r -~]*(connection:|content-type:|content-length:|date:)|post [\t-\r -~]
* http/[01]\.[019])
13:44:18 firewall,warning layer7 match failed, regexp too complex (http/(0\.9|1\.0|1\.1) [1-5][0-9][0-9] [\t-\r -~]*(connection:|content-type:|content-length:|date:)|post [\t-\r -~]
* http/[01]\.[019])
13:44:18 firewall,warning layer7 match failed, regexp too complex (http/(0\.9|1\.0|1\.1) [1-5][0-9][0-9] [\t-\r -~]*(connection:|content-type:|content-length:|date:)|post [\t-\r -~]
* http/[01]\.[019])
13:44:20 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]*ftp)
13:44:20 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:20 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]*ftp)
13:44:20 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:20 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]*ftp)
13:44:20 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:20 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]*ftp)
13:44:20 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:20 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]*ftp)
13:44:20 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:20 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]*ftp)
13:44:20 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:20 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]*ftp)
13:44:20 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:20 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:20 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:20 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]*ftp)
13:44:21 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:21 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]*ftp)
13:44:21 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:21 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]*ftp)
13:44:21 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:21 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]*ftp)
13:44:21 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:21 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]*ftp)
13:44:21 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:21 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:21 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:21 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:21 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]*ftp)
13:44:21 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:21 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]*ftp)
13:44:21 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:21 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]*ftp)
13:44:22 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:22 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]*ftp)
13:44:22 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:30 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:30 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:30 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:30 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:30 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:30 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
13:44:30 firewall,warning layer7 match failed, regexp too complex (^220[\t-\r -~]* (e?smtp|simple mail))
I'm using layer 7 with mangle and queue tree.
Thanks
Re: v5.6 released
Posted: Wed Aug 03, 2011 4:00 pm
by glucz
I'm trying to get the meaning of this:
*) sstp - when server certificate verification is enabled for sstp client,
it will additionally compare IP addresses found in certificate's
subjectAltName and subject CN to the real address, DNS names are ignored;
What does this mean in simple terms? Do I now have to have the server IP address as a subjectAltName in the certificate? Is now the SSTP server forcing the client to perform additional checks regarding the certificate? Does the DNS names in the CommonName are ignored in favor of IP addresses in the AltName?
Is SSTP going to be easier or more difficult to use?
Sorry for the many questions, but I really have no idea what this release note covers.
GL
Re: v5.6 released
Posted: Wed Aug 03, 2011 4:07 pm
by mrz
Yes, now you have to set server's IP address (not DNS name) when creating certificate.
SSTP is not harder to use, it is just an additional security feature.
Re: v5.6 released
Posted: Wed Aug 03, 2011 4:48 pm
by Ciambot
Nothing about wireless?
Re: v5.6 released
Posted: Wed Aug 03, 2011 5:41 pm
by dzieva
Hello Normis,
Is ticket #2011072166000401 fixed in this release?
Thanks,
Dzieva
Re: v5.6 released
Posted: Wed Aug 03, 2011 6:40 pm
by glucz
Yes, now you have to set server's IP address (not DNS name) when creating certificate.
SSTP is not harder to use, it is just an additional security feature.
OK. So let's assume for a moment that I'm running a VPN server and want to connect to it using SSTP. I generate my certificate signing request and for the CN I use the server IP. I then submit the cetificate signing request to Godaddy or any other signing CA (windows will not connect to servers showing an unsigned certificate by a trusted signing CA). They will throw out the CSR since the CN would not contain a valid domain name.
I'm then stuck creating my own CA and distributing root certificates to my users who may or may not know how to import them into which keystore.
If this is what 5.6 is doing, then it sounds like the killing of an otherwise useful routeros feature.
Thanks
GL
Re: v5.6 released
Posted: Wed Aug 03, 2011 7:48 pm
by MCT
Yes, now you have to set server's IP address (not DNS name) when creating certificate.
SSTP is not harder to use, it is just an additional security feature.
It's pretty much an industry standard to use domain names, how exactly is this a 'feature'?
Re: v5.6 released
Posted: Wed Aug 03, 2011 8:24 pm
by sobrado
Yes, now you have to set server's IP address (not DNS name) when creating certificate.
SSTP is not harder to use, it is just an additional security feature.
It's pretty much an industry standard to use domain names, how exactly is this a 'feature'?
Because nameservers cannot be trusted.
Re: v5.6 released
Posted: Wed Aug 03, 2011 8:40 pm
by glucz
Because nameservers cannot be trusted.
That's why windows for example will not accept the server certificate unless it's signed by a trusted signer. So now not only will they have to contaminate the DNS, they will have to generate a valid a signed certificate in your domain name.
So now IE/FF/Chrome/Opera/Safari should warn us every time we visit a secure site like
https://amazon.com that although the certificate is in order, we should better use
http://72.21.211.176 because DNS servers can be hijacked left and right? (what about DNSSEC btw.) This game had been played and the winner is the domain name. Do not re-invent this wheel.
--I feel however that we are misunderstanding something here and was hoping that MT could give a better explanation instead of this half sentence ... this goes back to an earlier issue that better changelogs are needed instead of these misleading half sentences--
Re: v5.6 released
Posted: Thu Aug 04, 2011 12:56 am
by Beccara
Still no IPv6 love with no DHCPv6-PD
Re: v5.6 released
Posted: Thu Aug 04, 2011 1:47 am
by JorgeAmaral
Yes, now you have to set server's IP address (not DNS name) when creating certificate.
SSTP is not harder to use, it is just an additional security feature.
OK. So let's assume for a moment that I'm running a VPN server and want to connect to it using SSTP. I generate my certificate signing request and for the CN I use the server IP. I then submit the cetificate signing request to Godaddy or any other signing CA (windows will not connect to servers showing an unsigned certificate by a trusted signing CA). They will throw out the CSR since the CN would not contain a valid domain name.
I'm then stuck creating my own CA and distributing root certificates to my users who may or may not know how to import them into which keystore.
If this is what 5.6 is doing, then it sounds like the killing of an otherwise useful routeros feature.
Thanks
GL
Hi,
I think that the changelog is a little bit confusing.
It should be: "if CN has IP compare, if CN has fqdn ignore, if subjectAltName has IP compare to real IP address of the server. Only one is required".
@Normunds: Can you please confirm if it is like this?
I successfully created the server certificate with fqdn on CN, IP of server in subjectAltName, and it works.
If you look about subjectAltName and IPSEC, you will find a couple of places explaining why subjectAltName must be used.
Kindly regards,
Re: v5.6 released
Posted: Thu Aug 04, 2011 8:03 am
by normis
Still no IPv6 love with no DHCPv6-PD
I already told you no sooner than v5.8
Re: v5.6 released
Posted: Thu Aug 04, 2011 8:51 am
by macgaiver
Hello,
After update from 5.5 i'm getting lots of layer7 erros:
log print
13:43:55 firewall,warning layer7 match failed, regexp too complex...
It looks like they managed to replace periodical router crash with similar log message (at least for me).
Re: v5.6 released
Posted: Thu Aug 04, 2011 9:42 am
by normis
Regarding the L7 problem:
For some time it was known that some specific layer7 filters in combination with specific traffic may cause router to crash.
We were able to narrow down the problem and introduced a first version of the fix - as soon as specific conditions for possible crash was met firewall will add a log entry to inform about situation and will avoid the crash.
The current "fix" actually contained a bug, so it produces unnecessary log entries.
We are still working on final solution, in fact it is already known that version 5.7 will have more precise fix that will significantly reduce blocked regexps as we narrow the problem even more (thanks to your reports)
Re: v5.6 released
Posted: Thu Aug 04, 2011 11:46 am
by muadib
Regarding the L7 problem:
For some time it was known that some specific layer7 filters in combination with specific traffic may cause router to crash.
We were able to narrow down the problem and introduced a first version of the fix - as soon as specific conditions for possible crash was met firewall will add a log entry to inform about situation and will avoid the crash.
The current "fix" actually contained a bug, so it produces unnecessary log entries.
We are still working on final solution, in fact it is already known that version 5.7 will have more precise fix that will significantly reduce blocked regexps as we narrow the problem even more (thanks to your reports)
Hello Normis,
Thank you!
Any adicional info you need just let me know.
Re: v5.6 released
Posted: Thu Aug 04, 2011 4:11 pm
by sergejs
Hello Normis,
Is ticket #2011072166000401 fixed in this release?
Thanks,
Dzieva
5.6 version include improvements for wireless and NV2.
Have you tried v5.6 on problematic link?
Do you experience the same disconnect problems?
Re: v5.6 released
Posted: Thu Aug 04, 2011 5:58 pm
by MCT
Yes, now you have to set server's IP address (not DNS name) when creating certificate.
SSTP is not harder to use, it is just an additional security feature.
It's pretty much an industry standard to use domain names, how exactly is this a 'feature'?
Because nameservers cannot be trusted.
Yes, they can't be trusted. I'm aware of that, that's why you have certificate authorities to validate. If someone is running a large web server and hasn't yet gone to load balancing hardware it's pretty routine to balance the load by having the domain name resolve to multiple IPs. The servers could be distributed around the world and local requests would get resolved to a local server. You'd have to generate and validate certificates for every IP you use? Then you're paying the certificate authority to sign each one? No thanks.
Is it a useful feature to be able to lock it to a single IP should you need to? Yes, absolutely.
Is it useful to anyone running domains with more than one IP? Nope
IPs change too.
It's more secure to have one master certificate. If you have a new one for every IP then someone can hijack DNS and have fake certificates for their own site. If they get the 'hey the site certificate has changed' message all the time because each IP has it's own certificate they're going to ignore the warning as it's become routine.
Nothing is secure, get use to it, but don't break established systems that everyone uses.
If you want to be paranoid then come to Blackhat USA and DEFCON. There's a talk later on a flaw in OSPF that allows an attacker to take over network routing. Cisco routers which are generally known to be solid and secure enough that classified information is trusted to run on them? Well there's another talk on exploiting unified images on Cisco. Cisco has millions to spend on security hardening. You think Mikrotik would fare any better? I know it wouldn't as I've looked over the system and seen things that tell me the people writing the code haven't had enough training on secure coding practices.
Note: Mikrotik, I'm quite willing to sign a (reasonable, and mutual) non-disclosure agreement and help make it more secure.
If you took away the option to use something that
could be attacked with a vulnerability then we'd never use anything. There is actually an unpatched PHP vulnerability right now that can give remote execution, you want to shut off most of the internet because someone could potentially use it?
Re: v5.6 released
Posted: Thu Aug 04, 2011 6:41 pm
by dzieva
Hello Normis,
Is ticket #2011072166000401 fixed in this release?
Thanks,
Dzieva
5.6 version include improvements for wireless and NV2.
Have you tried v5.6 on problematic link?
Do you experience the same disconnect problems?
Hello Sergejs,
Yes, Yes, with v5.6 build jul/28...
I will update to v5.6 build aug/02 and test it.
Thanks,
Dzieva
Re: v5.6 released
Posted: Thu Aug 04, 2011 8:56 pm
by changeip
5.6 version include improvements for wireless and NV2.
The release notes show no changes to wireless package at all so why would he think that it would make a difference? (Sarcasm intended)
Re: v5.6 released
Posted: Thu Aug 04, 2011 9:53 pm
by chadd
Hello Normis,
Is ticket #2011072166000401 fixed in this release?
Thanks,
Dzieva
5.6 version include improvements for wireless and NV2.
Have you tried v5.6 on problematic link?
Do you experience the same disconnect problems?
We are still having disconnects with version 5.6, I have been sending in support output files. Hopefully it will help you guys get it taken care of.
Re: v5.6 released - not working on SXT?
Posted: Thu Aug 04, 2011 11:46 pm
by zervan
I've updated remote SXT and after reboot I lost it. Then I tried to update testing SXT which I have here - I lost it as well. No single packet from them - I tried to discover using WinBox, I tried to watch traffic using Wireshark, nothing. What's going on?
Edit: I'm talking about ethernet (cable) connection, I didn't try wireless.
Re: v5.6 released - not working on SXT?
Posted: Fri Aug 05, 2011 12:24 am
by csallor
Updated 5.6
jan/02 00:00:10 system,info verified routerboard-5.6-mipsbe.npk
jan/02 00:00:11 system,info verified ntp-5.6-mipsbe.npk
jan/02 00:00:11 system,info verified wireless-5.6-mipsbe.npk
jan/02 00:00:11 system,info verified advanced-tools-5.6-mipsbe.npk
jan/02 00:00:11 system,info verified security-5.6-mipsbe.npk
jan/02 00:00:11 system,info verified system-5.6-mipsbe.npk
jan/02 00:00:11 system,info installed system-5.6
jan/02 00:00:11 system,info installed security-5.6
jan/02 00:00:11 system,info installed advanced-tools-5.6
jan/02 00:00:11 system,info installed wireless-5.6
jan/02 00:00:11 system,info installed ntp-5.6
jan/02 00:00:11 system,info installed routerboard-5.6
jan/02 00:00:11 system,info router rebooted
jan/02 00:00:14 interface,info ether1 link up (speed 100M, full duplex)
jan/02 00:00:19 wireless,info 00:0C:42:B5:XX:XX@wlan1 established connection on XXXX, SSID XXXXXXXX
jan/02 01:00:45 interface,info ether1 link down
jan/02 01:00:47 interface,info ether1 link up (speed 100M, full duplex)
jan/02 01:03:10 interface,info ether1 link down
jan/02 01:03:11 interface,info ether1 link up (speed 100M, full duplex)
jan/02 19:01:16 interface,info ether1 link down
jan/02 19:01:18 interface,info ether1 link up (speed 100M, full duplex)
jan/02 19:01:22 interface,info ether1 link down
jan/02 19:01:24 interface,info ether1 link up (speed 100M, full duplex)
jan/02 19:01:40 interface,info ether1 link down
jan/02 19:01:41 interface,info ether1 link up (speed 100M, full duplex)
01:31:21 interface,info ether1 link down
01:31:22 interface,info ether1 link up (speed 100M, full duplex)
01:47:18 interface,info ether1 link down
01:47:20 interface,info ether1 link up (speed 100M, full duplex)
Re: v5.6 released - not working on SXT?
Posted: Fri Aug 05, 2011 1:40 am
by chadd
I have had the same issue with one board since I have upgraded, so I am not sure what the deal is but again I am only seeing it on one 411.
Updated 5.6
jan/02 00:00:10 system,info verified routerboard-5.6-mipsbe.npk
jan/02 00:00:11 system,info verified ntp-5.6-mipsbe.npk
jan/02 00:00:11 system,info verified wireless-5.6-mipsbe.npk
jan/02 00:00:11 system,info verified advanced-tools-5.6-mipsbe.npk
jan/02 00:00:11 system,info verified security-5.6-mipsbe.npk
jan/02 00:00:11 system,info verified system-5.6-mipsbe.npk
jan/02 00:00:11 system,info installed system-5.6
jan/02 00:00:11 system,info installed security-5.6
jan/02 00:00:11 system,info installed advanced-tools-5.6
jan/02 00:00:11 system,info installed wireless-5.6
jan/02 00:00:11 system,info installed ntp-5.6
jan/02 00:00:11 system,info installed routerboard-5.6
jan/02 00:00:11 system,info router rebooted
jan/02 00:00:14 interface,info ether1 link up (speed 100M, full duplex)
jan/02 00:00:19 wireless,info 00:0C:42:B5:XX:XX@wlan1 established connection on XXXX, SSID XXXXXXXX
jan/02 01:00:45 interface,info ether1 link down
jan/02 01:00:47 interface,info ether1 link up (speed 100M, full duplex)
jan/02 01:03:10 interface,info ether1 link down
jan/02 01:03:11 interface,info ether1 link up (speed 100M, full duplex)
jan/02 19:01:16 interface,info ether1 link down
jan/02 19:01:18 interface,info ether1 link up (speed 100M, full duplex)
jan/02 19:01:22 interface,info ether1 link down
jan/02 19:01:24 interface,info ether1 link up (speed 100M, full duplex)
jan/02 19:01:40 interface,info ether1 link down
jan/02 19:01:41 interface,info ether1 link up (speed 100M, full duplex)
01:31:21 interface,info ether1 link down
01:31:22 interface,info ether1 link up (speed 100M, full duplex)
01:47:18 interface,info ether1 link down
01:47:20 interface,info ether1 link up (speed 100M, full duplex)
Re: v5.6 released
Posted: Fri Aug 05, 2011 9:55 am
by sergejs
csallor,
please send support output file from your router to support (
support@mikrotik.com).
chadd
Thank you very much. We have received support output files and now researching them. As soon as we will have any information or feedback, we will let you know!
Re: v5.6 released
Posted: Fri Aug 05, 2011 3:30 pm
by emersonmill
My RB1200 reboot when enable or disable auto-negotiation on any interface.
Message log:
system error critical router was rebooted without proper shutdown (cause1)
Re: v5.6 released
Posted: Fri Aug 05, 2011 4:11 pm
by kirshteins
My RB1200 reboot when enable or disable auto-negotiation on any interface.
Message log:
system error critical router was rebooted without proper shutdown (cause1)
Is there any output on serial console while rebooting? It is recommended to send supout.rif file from this router to
support@mikrotik.com
Re: v5.6 released
Posted: Fri Aug 05, 2011 8:19 pm
by yogii
Hello Normis,
Is ticket #2011072166000401 fixed in this release?
Thanks,
Dzieva
5.6 version include improvements for wireless and NV2.
Have you tried v5.6 on problematic link?
Do you experience the same disconnect problems?
Hello Sergejs,
Yes, Yes, with v5.6 build jul/28...
I will update to v5.6 build aug/02 and test it.
Thanks,
Dzieva
hello Dzieva, did you implementing nv2 wireless protocol?
so what the result, is disconnect problem solved in 5.6?
thanks.
Re: v5.6 released
Posted: Fri Aug 05, 2011 8:26 pm
by petro25
Hello Normis,
Is ticket #2011072166000401 fixed in this release?
Thanks,
Dzieva
5.6 version include improvements for wireless and NV2.
Have you tried v5.6 on problematic link?
Do you experience the same disconnect problems?
NV2 bridge 56 км ки 411 r52hn (baza)
aug/05 21:57:24 wireless,debug wlan1: 00:0C:42:64:52:7B in local ACL, accept
aug/05 21:57:24 wireless,info 00:0C:42:64:52:7B@wlan1: connected
aug/05 21:58:22 wireless,info 00:0C:42:64:52:7B@wlan1: reconnecting
aug/05 21:58:22 wireless,debug wlan1: 00:0C:42:64:52:7B in local ACL, accept
aug/05 21:58:22 wireless,info 00:0C:42:64:52:7B@wlan1: connected
aug/05 22:11:46 system,info,account user admin logged in from 178.49.73.94 via win
box
NV2 station bridge 56 km r52hn (klient)
16:06:17 wireless 00:0C:42:62:DA:48@wlan1: lost connection, synchronization timeout
16:06:18 wireless 00:0C:42:62:DA:48@wlan1 established connection on 2312, SSID gorn
16:06:37 wireless 00:0C:42:62:DA:48@wlan1: lost connection, synchronization timeout
16:06:39 wireless 00:0C:42:62:DA:48@wlan1 established connection on 2312, SSID gorn
16:58:50 wireless 00:0C:42:62:DA:48@wlan1: lost connection, synchronization timeout
16:58:51 wireless 00:0C:42:62:DA:48@wlan1 established connection on 2312, SSID gorn
16:59:21 wireless 00:0C:42:62:DA:48@wlan1: lost connection, synchronization timeout
16:59:22 wireless 00:0C:42:62:DA:48@wlan1 established connection on 2312, SSID gorn
Re: v5.6 released
Posted: Fri Aug 05, 2011 8:54 pm
by npero
Mirror bug, in registration table P throughput for N link is calculated wrong.
Re: v5.6 released - not working on SXT?
Posted: Fri Aug 05, 2011 9:48 pm
by zervan
I've updated remote SXT and after reboot I lost it. Then I tried to update testing SXT which I have here - I lost it as well. No single packet from them - I tried to discover using WinBox, I tried to watch traffic using Wireshark, nothing. What's going on?
Edit: I'm talking about ethernet (cable) connection, I didn't try wireless.
What about the others? Do you have such problem with SXT as well? I am going away for a week so I will try to solve that later.
Re: v5.6 released
Posted: Sat Aug 06, 2011 8:14 pm
by tjc
I was comparing exported configurations before and after the upgrade from 5.5 to 5.6 and noticed a new option that I can't find anything about on the wiki, "sip-direct-media". It showed up here:
/ip firewall service-port
set ftp disabled=no ports=21
set tftp disabled=no ports=69
set irc disabled=no ports=6667
set h323 disabled=no
set sip disabled=no ports=5060,5061 sip-direct-media=yes
set pptp disabled=no
Clues?
Re: v5.6 released
Posted: Sun Aug 07, 2011 3:58 am
by WirelessRudy
I almost finished upgrading all my 250+ rb's from 5.x to v5.6. (rb's 122, 133c3, 532, 411, 433, 333, 711's SXT's etc.) most done remote (wireless).
For some of these forum users that report sometimes they lost the unit after an upgrade: After upload of the package of wish check that all packages are really upgraded and mentioned in black in the file list. When only in light grey text, something had gone wrong (checksum is not correct?) and you need to upload that package again.
If one or more of the packages are not uploaded to the routerboard, or some data of the package is corrupt it might that an essential package is not loaded during the reboot and you loose control over that unit. Sometimes control is lost because dhcp package is corrupt while device is dhcp-client. Or if updated client is wireless and the wireless package is corrupt the wireless connection is lost.
It is therefore VERY IMPORTANT to check if the desired package are indeed uploaded in proper condition before the router is to be rebooted!
Wireless disconnects:
I have been very active on this forum amongst some others about this issue.
I have 220+ wireless units in an environment where all available spectrum is used, sometimes twice. (All 5Ghz upper band)
All my P2P ant P2MP are 802.11a with NV2 or 802.11n with NV2.
P2MP are typical 10Mhz bandwidth.
Although 5.6 is a bit better than previous releases, it is still more important than the pre NV2 era to separate radios as much as possible from signals they should not receive.
But my network is now 98% stable when it comes to wireless disconnects. The last 2% can be of any source, not necessarily related to NV2 or interference.
Ethernet port flapping:
The issue is still there, 5.6 did not bring any improvement on that.
But:
All my units that have the Ethernet port flap are connected with their Ethernet port via a power-shot to 3rd party units (wifi router, PC or laptop, switch)
I had one Ethernet port flap many times a day. I fit one mini-router (rb150) in-between the cable with all ports bridged, and the flapping has gone between the two router-boards. So the unit that reported some 20 to 30 Ethernet port flaps a day is now rock solid!
The Ethernet port of the rb150 that now connects to the client shows now a port flapping, but less as before (?)
I am developing a ´feeling´ the Ethernet port flap issue is more related to ESD which makes the ROS sense if like a port is down. So far I could not proof that a Ethernet port flap is actually ´breaking´ the connection. Clients don't seem to notice any disconnects.
But more tests and longer investigation is needed to get to the bottom of this issue.
I started a new topic on this Ethernet port flap issue with some question to report more detailed from us users that still have the issue.
http://forum.mikrotik.com/viewtopic.php ... 21#p275121
Furthermore so far no issues with v5.6
Re: v5.6 released
Posted: Sun Aug 07, 2011 7:42 am
by doofoo
Any word on PPPOE Server that supports MLPPP? I have seen some info (from a couple years ago) asking and saying it wasn't done but wasn't sure of the current status.
We are a smaller ISP interested in purchasing a few hundred CPE's RB750GL and standardizing on the same Level 6 X86 PPPOE concentrator on the same platform. This is a stumbling block for us unfortunately. Is there any update?
Re: v5.6 released
Posted: Sun Aug 07, 2011 11:27 am
by steen
Hello Folks!
We are also upgrading to 5.6 from 5.4 and 5.5, 4.17.
So far on RB411 (CPE) and RB333 (Routers), RB450G (Routers).
There has been some incidents, when upgrading RB450G and RB411 from 4.17 to 5.5 they never came back up on the network, visiting the router's we discovered that all ethernet leds were off but blue led was on. Fully dissconnect the power and put it back again solved the problem. Upgrading from 5.5 to 5.6 was not an issue.
Please MT, can you do something about the upgrade scenarios, like automatik failback, and automatik restart on previous firmware. Failsafe functions should be implemented like last known good and so on. Other devices we have do so, like our IBM AIX servers.
The devices should never be dead in water exeption is if there are hardware problems.
Re: v5.6 released
Posted: Sun Aug 07, 2011 1:51 pm
by steen
Hello Folks!
Ufter upgrade from 4.17 to 5.6 on our basestations RB600 we recieve very low Tx7Rx CCQ values, before it was 90-100% now it is something like 24-30.
Tx/Rx Rate went down to 9Mbit/s and vanders around 96-24 with jumps up to 54Mbit but most of time around 6. Before it was rock solid 54 Mbit/s everywhere.
Can someone please explain what is going on here and help me to fix this issue before customers wil start calling in about bad internet ?
Re: v5.6 released
Posted: Sun Aug 07, 2011 3:45 pm
by WirelessRudy
Hello Folks!
After upgrade from 4.17 to 5.6 on our basestations RB600 we recieve very low Tx7Rx CCQ values, before it was 90-100% now it is something like 24-30.
Tx/Rx Rate went down to 9Mbit/s and vanders around 96-24 with jumps up to 54Mbit but most of time around 6. Before it was rock solid 54 Mbit/s everywhere.
Can someone please explain what is going on here and help me to fix this issue before customers wil start calling in about bad internet ?
Are readings while a data stream is on the link?
Depending on your chosen data rates CCQ will step up/down depending on data throughput. In v5 versions this is more obvious (with NV2) than before.
Re: v5.6 released
Posted: Sun Aug 07, 2011 3:55 pm
by petro25
the same disconnect problems
'NV2 bridge 56 км ки 411 r52hn (baza)
aug/05 21:57:24 wireless,debug wlan1: 00:0C:42:64:52:7B in local ACL, accept
aug/05 21:57:24 wireless,info 00:0C:42:64:52:7B@wlan1: connected
aug/05 21:58:22 wireless,info 00:0C:42:64:52:7B@wlan1: reconnecting
aug/05 21:58:22 wireless,debug wlan1: 00:0C:42:64:52:7B in local ACL, accept
aug/05 21:58:22 wireless,info 00:0C:42:64:52:7B@wlan1: connected
aug/05 22:11:46 system,info,account user admin logged in from 178.49.73.94 via win
box
NV2 station bridge 56 km r52hn (klient)
16:06:17 wireless 00:0C:42:62:DA:48@wlan1: lost connection, synchronization timeout
16:06:18 wireless 00:0C:42:62:DA:48@wlan1 established connection on 2312, SSID gorn
16:06:37 wireless 00:0C:42:62:DA:48@wlan1: lost connection, synchronization timeout
16:06:39 wireless 00:0C:42:62:DA:48@wlan1 established connection on 2312, SSID gorn
16:58:50 wireless 00:0C:42:62:DA:48@wlan1: lost connection, synchronization timeout
16:58:51 wireless 00:0C:42:62:DA:48@wlan1 established connection on 2312, SSID gorn
16:59:21 wireless 00:0C:42:62:DA:48@wlan1: lost connection, synchronization timeout
16:59:22 wireless 00:0C:42:62:DA:48@wlan1 established connection on 2312, SSID gorn
Re: v5.6 released
Posted: Sun Aug 07, 2011 4:24 pm
by WirelessRudy
the same disconnect problems
'NV2 bridge 56 км ки 411 r52hn (baza)
aug/05 21:57:24 wireless,debug wlan1: 00:0C:42:64:52:7B in local ACL, accept
aug/05 21:57:24 wireless,info 00:0C:42:64:52:7B@wlan1: connected
aug/05 21:58:22 wireless,info 00:0C:42:64:52:7B@wlan1: reconnecting
aug/05 21:58:22 wireless,debug wlan1: 00:0C:42:64:52:7B in local ACL, accept
aug/05 21:58:22 wireless,info 00:0C:42:64:52:7B@wlan1: connected
aug/05 22:11:46 system,info,account user admin logged in from 178.49.73.94 via win
box
NV2 station bridge 56 km r52hn (klient)
16:06:17 wireless 00:0C:42:62:DA:48@wlan1: lost connection, synchronization timeout
16:06:18 wireless 00:0C:42:62:DA:48@wlan1 established connection on 2312, SSID gorn
16:06:37 wireless 00:0C:42:62:DA:48@wlan1: lost connection, synchronization timeout
16:06:39 wireless 00:0C:42:62:DA:48@wlan1 established connection on 2312, SSID gorn
16:58:50 wireless 00:0C:42:62:DA:48@wlan1: lost connection, synchronization timeout
16:58:51 wireless 00:0C:42:62:DA:48@wlan1 established connection on 2312, SSID gorn
16:59:21 wireless 00:0C:42:62:DA:48@wlan1: lost connection, synchronization timeout
16:59:22 wireless 00:0C:42:62:DA:48@wlan1 established connection on 2312, SSID gorn
perform a wireless scan on both ends and show us the results. Also give us your other NV2 parameters.
Re: v5.6 released
Posted: Sun Aug 07, 2011 4:29 pm
by steen
Hello Folks!
After upgrade from 4.17 to 5.6 on our basestations RB600 we recieve very low Tx7Rx CCQ values, before it was 90-100% now it is something like 24-30.
Tx/Rx Rate went down to 9Mbit/s and vanders around 96-24 with jumps up to 54Mbit but most of time around 6. Before it was rock solid 54 Mbit/s everywhere.
Can someone please explain what is going on here and help me to fix this issue before customers wil start calling in about bad internet ?
Are readings while a data stream is on the link?
Depending on your chosen data rates CCQ will step up/down depending on data throughput. In v5 versions this is more obvious (with NV2) than before.
-----------------
These signals are when there is silence, it confirms your comments. When traffic flows it gradually steps up till the maxim limit, in my case 108Mbit/s for those links. And yet after some hours no complaints (it never have been in this sector) so I guess all is back to normal.
Thank you for the swift anser!
Re: v5.6 released
Posted: Sun Aug 07, 2011 5:23 pm
by n21roadie
Hello Folks!
We are also upgrading to 5.6 from 5.4 and 5.5, 4.17.
So far on RB411 (CPE) and RB333 (Routers), RB450G (Routers).
There has been some incidents, when upgrading RB450G and RB411 from 4.17 to 5.5 they never came back up on the network, visiting the router's we discovered that all ethernet leds were off but blue led was on. Fully dissconnect the power and put it back again solved the problem. Upgrading from 5.5 to 5.6 was not an issue.
Please MT, can you do something about the upgrade scenarios, like automatik failback, and automatik restart on previous firmware. Failsafe functions should be implemented like last known good and so on. Other devices we have do so, like our IBM AIX servers.
The devices should never be dead in water exeption is if there are hardware problems.
There is a bug with 4.1X when you try to reboot it shuts down instead, discovered this as usual the hard way when a weekly scheduled reboot resulted in routers shutting down, this is fixed in the 5.X series so i never reboot a 4.x series unless i am close by to re-cycle the power.
http://forum.mikrotik.com/viewtopic.php ... it=+reboot
http://forum.mikrotik.com/viewtopic.php?f=1&t=48518
Re: v5.6 released
Posted: Sun Aug 07, 2011 5:45 pm
by steen
Hello Folks!
We are also upgrading to 5.6 from 5.4 and 5.5, 4.17.
So far on RB411 (CPE) and RB333 (Routers), RB450G (Routers).
There has been some incidents, when upgrading RB450G and RB411 from 4.17 to 5.5 they never came back up on the network, visiting the router's we discovered that all ethernet leds were off but blue led was on. Fully dissconnect the power and put it back again solved the problem. Upgrading from 5.5 to 5.6 was not an issue.
Please MT, can you do something about the upgrade scenarios, like automatik failback, and automatik restart on previous firmware. Failsafe functions should be implemented like last known good and so on. Other devices we have do so, like our IBM AIX servers.
The devices should never be dead in water exeption is if there are hardware problems.
There is a bug with 4.1X when you try to reboot it shuts down instead, discovered this as usual the hard way when a weekly scheduled reboot resulted in routers shutting down, this is fixed in the 5.X series so i never reboot a 4.x series unless i am close by to re-cycle the power.
http://forum.mikrotik.com/viewtopic.php ... it=+reboot
http://forum.mikrotik.com/viewtopic.php?f=1&t=48518
---------
Thanks!
We still have many ros4.17 RB411 CPE spread out over a wide area, hard to reach, upgrades are planned.
Re: v5.6 released
Posted: Sun Aug 07, 2011 6:12 pm
by petro25
the same disconnect problems
'NV2 bridge 56 км ки 411 r52hn (baza)
aug/05 21:57:24 wireless,debug wlan1: 00:0C:42:64:52:7B in local ACL, accept
aug/05 21:57:24 wireless,info 00:0C:42:64:52:7B@wlan1: connected
aug/05 21:58:22 wireless,info 00:0C:42:64:52:7B@wlan1: reconnecting
aug/05 21:58:22 wireless,debug wlan1: 00:0C:42:64:52:7B in local ACL, accept
aug/05 21:58:22 wireless,info 00:0C:42:64:52:7B@wlan1: connected
aug/05 22:11:46 system,info,account user admin logged in from 178.49.73.94 via win
box
NV2 station bridge 56 km r52hn (klient)
16:06:17 wireless 00:0C:42:62:DA:48@wlan1: lost connection, synchronization timeout
16:06:18 wireless 00:0C:42:62:DA:48@wlan1 established connection on 2312, SSID gorn
16:06:37 wireless 00:0C:42:62:DA:48@wlan1: lost connection, synchronization timeout
16:06:39 wireless 00:0C:42:62:DA:48@wlan1 established connection on 2312, SSID gorn
16:58:50 wireless 00:0C:42:62:DA:48@wlan1: lost connection, synchronization timeout
16:58:51 wireless 00:0C:42:62:DA:48@wlan1 established connection on 2312, SSID gorn
16:59:21 wireless 00:0C:42:62:DA:48@wlan1: lost connection, synchronization timeout
16:59:22 wireless 00:0C:42:62:DA:48@wlan1 established connection on 2312, SSID gorn
perform a wireless scan on both ends and show us the results. Also give us your other NV2 parameters.
Re: v5.6 released
Posted: Sun Aug 07, 2011 6:57 pm
by dzieva
yogii,
Is in testing,
Dzieva.
Re: v5.6 released
Posted: Mon Aug 08, 2011 2:16 am
by WirelessRudy
petro25, your settings looks ok. Show us the result of a 5, 10 and 20Mhz frequency scan of the band you use from both ends. Your issue can be interferences related. Any other units on same tower?
Re: v5.6 released
Posted: Mon Aug 08, 2011 8:02 am
by oeyre
I notice that RB493G still uses the wrong port numbers for Ethernet interfaces when the configuration is reset. Will this be fixed in the next release?
Re: v5.6 released
Posted: Mon Aug 08, 2011 9:54 am
by sergejs
oeyre,
thank you very much for the report.
We are working on the problem.
Re: v5.6 released
Posted: Mon Aug 08, 2011 10:49 pm
by ahang
Is it OK if I upgrade my RB each time when new upgrade release ?
Re: v5.6 released
Posted: Mon Aug 08, 2011 11:15 pm
by fewi
Is it OK if I upgrade my RB each time when new upgrade release ?
Maybe.
Re: v5.6 released
Posted: Tue Aug 09, 2011 2:25 am
by tjc
Is it OK if I upgrade my RB each time when new upgrade release ?
If your RouterOS license, other policies, and hardware allows it.
For example this router should be upgradable through future 5.x and 6.x versions based on the license (aka anything before 7.0 whenever that appears).
[admin@MikroTik] > /system license print
software-id: xxxx-xxxx
upgradable-to: v6.x
nlevel: 4
features:
Re: v5.6 released
Posted: Tue Aug 09, 2011 6:24 pm
by ahang
Mine is also upgradable-to: v6.x
Thanks
Re: v5.6 released
Posted: Tue Aug 09, 2011 8:23 pm
by mangust
Strange behavior or of the interface speed graph.
x86 , ROS v5.6 , RealTeck 1G ethernet.
In some pik situation MT show speed which is more then 100Mbit/s, in same time showes some interrupts in graph.
Re: v5.6 released
Posted: Wed Aug 10, 2011 1:36 am
by WirelessRudy
Strange behavior or of the interface speed graph.
x86 , ROS v5.6 , RealTeck 1G ethernet.
In some pik situation MT show speed which is more then 100Mbit/s, in same time showes some interrupts in graph.
Speed reading is a moment calculated reading. If you run a load over a long time you'll see the average goes below 100Mb.
The speed meter is not exact, sometimes a little bit more, sometimes a little less. And 8% error is not exceptional. But your next reading might be 94Mb or so. While probably the amount of data being transported is still the same.
Re: v5.6 released
Posted: Wed Aug 10, 2011 8:08 am
by odie
you should have a look at the status of the interface - not the settings to see the real connection speed !!!
settings are set to auto negotiation - the speed setting there is for nothing..
as you write that you have a 1 Gbit IF then you might also have gbit connection !!
Re: v5.6 released
Posted: Wed Aug 10, 2011 10:21 am
by winet
is there some sort of bug on this release?
i've just updated to v5.6 yesterday, and now i got CPU resource load 100%. it's been hours like this
Uploaded with
ImageShack.us
somebody help please before the router crash for overheating
Re: v5.6 released
Posted: Wed Aug 10, 2011 12:14 pm
by elgo
i've just updated to v5.6 yesterday, and now i got CPU resource load 100%. it's been hours like this
[...]
somebody help please before the router crash for overheating
Seriously, what kind of help are you expecting with this post?
Unless you do some proper support request with a supout file, I barely see what anwser you can get (except "
gather with some colleagues to blow on your router to cool it down" or a mere "
try to downgrade"?).
Re: v5.6 released
Posted: Wed Aug 10, 2011 12:15 pm
by uldis
also look into the Tool Profile to see what is using that CPU.
Re: v5.6 released
Posted: Wed Aug 10, 2011 12:48 pm
by winet
also look into the Tool Profile to see what is using that CPU.
this kind of help i'm talking about
under Tool Profile, it's "management" taking mostly 65% of the CPU load
i closed all active winbox already, nothing's changed. is there anything else i could check on?
thanks before
Re: v5.6 released
Posted: Wed Aug 10, 2011 3:47 pm
by WirelessRudy
also look into the Tool Profile to see what is using that CPU.
this kind of help i'm talking about
under Tool Profile, it's "management" taking mostly 65% of the CPU load
i closed all active winbox already, nothing's changed. is there anything else i could check on?
thanks before
reboot? Or power cycle? That sometimes helps. If issue comes back, downgrade reboot, power cycle, and upgrade again....
Re: v5.6 released
Posted: Wed Aug 10, 2011 4:05 pm
by mrz
Winbox is not "management". What configuration you have on that router?
Re: v5.6 released
Posted: Wed Aug 10, 2011 5:45 pm
by winet
Winbox is not "management". What configuration you have on that router?
a lot. but nothing is changed on configuration.
Re: v5.6 released
Posted: Wed Aug 10, 2011 5:46 pm
by winet
i closed all active winbox already, nothing's changed. is there anything else i could check on?
thanks before
reboot? Or power cycle? That sometimes helps. If issue comes back, downgrade reboot, power cycle, and upgrade again....
i'll do this in the morning
Re: v5.6 released
Posted: Thu Aug 11, 2011 4:53 am
by winet
it seems like this problem is solved just by rebooting the system. but isn't it better if we can find out what exactly caused it? because it is impossible to do a reboot every time it happens.
btw, this never happen on the older version.
Re: v5.6 released
Posted: Thu Aug 11, 2011 11:31 am
by macgaiver
winet - do you use user-manager? and have you send all this info to
support@mikrotik.com?
Re: v5.6 released
Posted: Thu Aug 11, 2011 4:44 pm
by winet
i use user-manager for hotspot. i didn't send it because i didn't know that i have to and no body told me to
i'll send it next time it occurs
Re: v5.6 released
Posted: Thu Aug 11, 2011 11:49 pm
by Caci99
I suspect it is the graphing tool causing high CPU Usage. After reboot, graphs are deleted and it starts
all over again, after a couple of days it will cause the CPU to go again 100%. I have disabled graphs
on my RB411 a week ago, and since then had no problems with CPU
Re: v5.6 released
Posted: Sat Aug 13, 2011 8:13 am
by steen
Hello Folks!
We are also upgrading to 5.6 from 5.4 and 5.5, 4.17.
So far on RB411 (CPE) and RB333 (Routers), RB450G (Routers).
There has been some incidents, when upgrading RB450G and RB411 from 4.17 to 5.5 they never came back up on the network, visiting the router's we discovered that all ethernet leds were off but blue led was on. Fully dissconnect the power and put it back again solved the problem. Upgrading from 5.5 to 5.6 was not an issue.
Please MT, can you do something about the upgrade scenarios, like automatik failback, and automatik restart on previous firmware. Failsafe functions should be implemented like last known good and so on. Other devices we have do so, like our IBM AIX servers.
The devices should never be dead in water exeption is if there are hardware problems.
There is a bug with 4.1X when you try to reboot it shuts down instead, discovered this as usual the hard way when a weekly scheduled reboot resulted in routers shutting down, this is fixed in the 5.X series so i never reboot a 4.x series unless i am close by to re-cycle the power.
http://forum.mikrotik.com/viewtopic.php ... it=+reboot
http://forum.mikrotik.com/viewtopic.php?f=1&t=48518
---------
Thanks!
We still have many ros4.17 RB411 CPE spread out over a wide area, hard to reach, upgrades are planned.
I just report that all remaining basestations and CPE:s where successfully upgraded from 4.17 to 5.6 without any problems.
We did use The Dude for upgrading all, one by one, logged in via winbox till connection lost messages arrived. In general the upgrade took 3 minutes per device.
The reconfiguring of all wireless interfaces where successful so now we can switch between nstreme and nv2 in all our network.
Re: v5.6 released
Posted: Tue Aug 16, 2011 1:24 pm
by hapi
all SXT in network.
monthly.gif
then can not connect to the SXT. Memory is full. SXT then disconnects OSPF etc..
SXT use since version 5.0 and make it completly all versions up to v5.6. RB711 and others RB do not.
Re: v5.6 released
Posted: Tue Aug 16, 2011 1:25 pm
by janisk
and configurations are completely identical on both routers?
Have you sent this to support?
Re: v5.6 released
Posted: Tue Aug 16, 2011 1:36 pm
by hapi
configuration differences. But everywhere OSPF and where not, no problem.
I did not send support.
Re: v5.6 released
Posted: Tue Aug 16, 2011 3:35 pm
by janisk
please create one after reset and one when some amount of RAM still left. That would be helpful to track down the problem.
Re: v5.6 released - not working on SXT?
Posted: Fri Aug 19, 2011 5:49 pm
by zervan
I've updated remote SXT and after reboot I lost it. Then I tried to update testing SXT which I have here - I lost it as well. No single packet from them - I tried to discover using WinBox, I tried to watch traffic using Wireshark, nothing. What's going on?
I've returned from my holiday now and started to discover what's wrong. I was not able to connect to SXT with 5.6, so I reset settings (using button) and SXT started to respond again (with default settings, of course). Then I tried to restore configuration - I lost SXT again.
So I tried to reset, downgrade to 5.5, restore configuration - everything is all right. Upgrade to 5.6 - lost. There is obviously something wrong with my configuration and 5.6. I am using bridge - ethernet and wireless are bridged together. Maybe there is something wrong with that in 5.6? I'm not sure and perhaps I will contact support.
Re: v5.6 released - not working on SXT?
Posted: Fri Aug 19, 2011 8:43 pm
by uldis
I've updated remote SXT and after reboot I lost it. Then I tried to update testing SXT which I have here - I lost it as well. No single packet from them - I tried to discover using WinBox, I tried to watch traffic using Wireshark, nothing. What's going on?
I've returned from my holiday now and started to discover what's wrong. I was not able to connect to SXT with 5.6, so I reset settings (using button) and SXT started to respond again (with default settings, of course). Then I tried to restore configuration - I lost SXT again.
So I tried to reset, downgrade to 5.5, restore configuration - everything is all right. Upgrade to 5.6 - lost. There is obviously something wrong with my configuration and 5.6. I am using bridge - ethernet and wireless are bridged together. Maybe there is something wrong with that in 5.6? I'm not sure and perhaps I will contact support.
please make the support output file from v5.5 with your config, so we could check it. Also maybe make admin user without password and send us the backup file maybe we could try to reproduce it.
Re: v5.6 released - not working on SXT?
Posted: Fri Aug 19, 2011 8:54 pm
by zervan
please make the support output file from v5.5 with your config, so we could check it. Also maybe make admin user without password and send us the backup file maybe we could try to reproduce it.
Yes, I've sent you backup file, Ticket#2011081966000477, hoping you will be able to reproduce it.
Re: v5.6 released
Posted: Thu Aug 25, 2011 8:46 am
by zervan
So it seems that problem is with L2MTU set to 2030. I can reset configuration, set L2MTU (not MTU!) to 2030 and connection is lost immediately. Perhaps I have not understood meaning of L2MTU well
But why this was working in 5.5?
Re: v5.6 released
Posted: Fri Aug 26, 2011 5:04 pm
by zervan
So it seems that problem is with L2MTU set to 2030. I can reset configuration, set L2MTU (not MTU!) to 2030 and connection is lost immediately. Perhaps I have not understood meaning of L2MTU well
But why this was working in 5.5?
To finish this story: I've got response from support - problem is related to L2MTU and will be fixed for the next RouterOS release. So don't use L2MTU higher than 2020 in SXT with version 5.6.
Re: v5.6 released
Posted: Sat Aug 27, 2011 11:54 am
by steen
Hello Folks!
Is NV2 now stable to use in production or is suggestion to wait still some releases of routeros ?
I still see lot of fuzz regarding disconnection issues with NV2.
Re: v5.6 released
Posted: Sat Aug 27, 2011 2:27 pm
by n21roadie
Hello Folks!
Is NV2 now stable to use in production or is suggestion to wait still some releases of routeros ?
I still see lot of fuzz regarding disconnection issues with NV2.
Well when MT say they cannot reproduce some of the on going disconnection issues in their test lab, effected users have sent in debug logs, we still await a solution from MT for this but it's your call to use NV2 in production it may work flawlessly for you or cause you problems, there is only one way to answer the question you have asked (test)
Re: v5.6 released
Posted: Sat Aug 27, 2011 5:07 pm
by steen
Hello Folks!
Is NV2 now stable to use in production or is suggestion to wait still some releases of routeros ?
I still see lot of fuzz regarding disconnection issues with NV2.
Well when MT say they cannot reproduce some of the on going disconnection issues in their test lab, effected users have sent in debug logs, we still await a solution from MT for this but it's your call to use NV2 in production it may work flawlessly for you or cause you problems, there is only one way to answer the question you have asked (test)
Okey, i will give it a try in production on one smaller sector over the remaining weekend and possibly full next week to see how it behaves. The LAB tests here show good results in half year tests.
Re: v5.6 released
Posted: Sat Aug 27, 2011 5:17 pm
by WirelessRudy
Hello Folks!
Is NV2 now stable to use in production or is suggestion to wait still some releases of routeros ?
I still see lot of fuzz regarding disconnection issues with NV2.
Hi ´steen´, as you could see in this forum, I had many issues with pre 5.6 releases and NV2. My whole network (+/- 250 radio's in 15km radius with 16 AP's) is now in 5Ghz upper band (200Mhz wide) working with NV2 and v5.6. I have no more disconnect issues like before that are NV2 related.
Users still should understand though that NV2 needs better channel separation between competitive AP's working the same band and clients can at times having problems with interferences due strong signals from other working frequencies than its own. But if the channels (10Mhz!) are chosen with caution the network runs fine.....
With me it runs some 3 weeks now in all v5.6ROS + updated firmwares and it has been long (pre NV2 era!) that I had such a stable network as I have now...
Even the port flap issue still around is merely a ros notification issue than a real one. Although it is still wide spread over my network there seems to be not a single client noticing it. It only happens on Ethernet ports that are connected to 3rd party devices. I hardly see it between MT routers.
Maybe v5.7 might see some extra improvement here since it has improved Ethernet drivers (according newsletter) and hopefully the ´port flap´ issue has disappeared as well!
Re: v5.6 released
Posted: Sat Aug 27, 2011 7:03 pm
by steen
Hello Folks!
Is NV2 now stable to use in production or is suggestion to wait still some releases of routeros ?
I still see lot of fuzz regarding disconnection issues with NV2.
Hi ´steen´, as you could see in this forum, I had many issues with pre 5.6 releases and NV2. My whole network (+/- 250 radio's in 15km radius with 16 AP's) is now in 5Ghz upper band (200Mhz wide) working with NV2 and v5.6. I have no more disconnect issues like before that are NV2 related.
Users still should understand though that NV2 needs better channel separation between competitive AP's working the same band and clients can at times having problems with interferences due strong signals from other working frequencies than its own. But if the channels (10Mhz!) are chosen with caution the network runs fine.....
With me it runs some 3 weeks now in all v5.6ROS + updated firmwares and it has been long (pre NV2 era!) that I had such a stable network as I have now...
Even the port flap issue still around is merely a ros notification issue than a real one. Although it is still wide spread over my network there seems to be not a single client noticing it. It only happens on Ethernet ports that are connected to 3rd party devices. I hardly see it between MT routers.
Maybe v5.7 might see some extra improvement here since it has improved Ethernet drivers (according newsletter) and hopefully the ´port flap´ issue has disappeared as well!
Lets hope, we have had rock solid network for years using nstreme here, customers exoect that also in future. Our network is in middle of town and willages, looot of interference. Directional antennas everywhere carefully aligned and placed, that pays off
Channel spacing is as big it can be to, shooting in different directions etc.
Re: v5.6 released
Posted: Sat Oct 08, 2011 1:01 pm
by OndrejSkipala
Our experience:
1) v5.6 solved our problem with /ip/route/cache where cache-size was growing and growing until it reached the max limit and then the router stopped respondng to all IP traffic. This happened in versions 4.x
2) CPU load of all RB433s and RB600 went up instead of down. RB600 that was under heavy load (75%) went to 95% and started causing serious problems - very high ping to certain interfaces (400ms or so on ethernet interface, no data overload, just high CPU).
3) Profiler tool is very usefull ! Was able to reduce CPU load by rearanging firewall rules and see the different.
4) On one RB433AH where the trafic is heavier (around 20Mbit) the router sometimes reboots without any reason. I thought it was because high CPU load - so rearanged firewall rules and reduced CPU load under 50%, but the problem occured again. Sent support.rif files to Mikrotik every time, but they did not reply or replied "upgrade to v5.8" which is not even stable yet - no, thank you.
5) After reboot (or power shut down, up) all graphing information is lost! This did not happen in version 4.x. Its a very sad thing to see.
Anybody has the same problem with rebooting and graphing?
Re: v5.6 released
Posted: Sat Oct 08, 2011 7:05 pm
by tjc
IIRC the graphing issue is related to the NTP server package taking too long to sync the system clock, and when the graphs are updated the time gap causes it to clear them. If you don't need the NTP server capabilities, using the simple NTP client rather than the separate package is supposed to avoid this. This has been reported by many people, so Mikrotik is aware of it, but sadly it seems to be a long, long way down their priority list.
Re: v5.6 released
Posted: Sun Oct 09, 2011 9:53 pm
by OndrejSkipala
IIRC the graphing issue is related to the NTP server package taking too long to sync the system clock, and when the graphs are updated the time gap causes it to clear them. If you don't need the NTP server capabilities, using the simple NTP client rather than the separate package is supposed to avoid this. This has been reported by many people, so Mikrotik is aware of it, but sadly it seems to be a long, long way down their priority list.
I use NTP client and Im not using NTP server. So only disabling the NTP package will do the work? NTP client will be still working?
Re: v5.6 released
Posted: Sun Oct 09, 2011 10:49 pm
by Caci99
Yes, but it is actually the SNTP Client that will be working. They do basically the same job.
You can find it in /system sntp client (winbox), once you have disabled the NTP Package.