http://forum.mikrotik.com/posting.php?mode=smilies&f=1#
Normis, Your upgrade version 6.11 Truly BIG PROBLEM with Hotspot Features
nOw back to 6.10
Please check it my support it
Tq
autosupout.rar (382 KB)
YOU MUST WRITE AND SEND AUTOSUPOUT TO support@mikrotik.com
and also write (to support) what problem you have encountered, not limited to “nOw back to 6.10”.
For example - [Ticket#2014021466000802] - Permanent disconnections from Winbox via tunnels and non stable tunnels. This problem is actual for all versions newer than 6.7. My beautiful RB1100AHx2 works in far datacenter and i already afraid to install updates of ROS. I tried to update up to 6.9 and 6.10 - but every time was forced to downgrade to 6.7.
I repeat - you made beautiful and wonderful routers with good architecture, i can do more and more configurations with it. But these small and numerous bugs spoils everything.
Hey, thanks for deleting my post!
This just shows me that my decision is right.
Just for the records to stick to the topic: SSTP is broken again, no connection from 6.11/6.10 (client) to 6.11 (server); just getting “internal error (6)”
oh 'thank you, I’ll send it to support,
my problem 'after some time hotspot menu is gone, and as a direct connection without dhcp and login page.
see log
You can be the same problem as me
tq
Please take a look to this http://forum.mikrotik.com/t/gprs-modem-zte-mf110/33317/6
Do not bring back 2009 post, when the solution are already written inside.
Have you read the whole thread?
(original reply message adapted from 2009 to 2014)
I upgraded my RB2011UAS-2HnD from 6.0 to 6.11. All works ok, though I also see the Winbox formatting problem that everyone else reports.
I do observe one strange thing: I have some Ethernet switch ports that are slaves to other masters. In all cases after upgrading traffic is being shown on the slave ports rather than the master ports (unless there is active Ethernet activity on the master port). Is this a change? I thought that previously no traffic was reported on the slave ports. Can I be sure that even though traffic is being reported on the slave ports that LAN traffic between two switch ports is not going through the router’s CPU?
Is a new feature from 6.5 to report the traffic,
*) ethernet interface stats that are behind switch chip
show real hw stats instead of just the traffic that goes through cpu;
remember to update also the firmware!!!
Normis other tech companies I have dealt with professionally have bug tracking systems that are open to anyone (Cisco to name one). The bugs are not submitted by end users but by the development teams or other authorized individuals at the company. They are then referenced by tech support when looking for issues. Not all bugs are immediately publicly viewable. Once a bug has been fully confirmed and understood by the dev team the bug is opened up to the public. The bug record contains workaround instructions if available, version numbers affected, and versions that the bug is fixed in. I don’t know that anyone is expecting user submitted bugs in a bug tracker like say an opensource project does. Typically those systems are also doubling as a issue tracker.
Folks just want straight forward answers about bugs that do exist so they can be worked around in their environment. When the limitations of the device or the software version that is being deployed are known it gives a lot more confidence in deploying it. If there are a lot of unknown issues or stigma attached to a version its hard to want to deploy it. A publicly viewable bug tracker is as much about managing expectations and rumors as it is about reducing support calls. It also builds trust in the company and their products.
Anyone can confirm this bug:
-
Not very important, upgrade to 6.11 Groove, SxLite, RB711, lost default LED indication for wireless signal strength. On RB411 try to add new LED, LED appears as unknown closing, open again new led windows in WinBox help to back to normal.
-
Before last couple version have problem with OpenVPN in bridge configuration, no problem with connection. Network is bridged connect to OpenVPN also bridge configuration have access to all device in bridge network but can’t access device where is OpenVPN server, other device in network is accessible. But connect to other device in network can connect to MT where is OpenVPN server check bridge and OpenVPN client is in the bridge. This is on x86 tested again on RB433GL also 6.11 some thing happens.
Any one see this problem.
Of course send supout to support waiting answer.
+1
+1
Thank you all for the input!
All of our hardware support COA, but not RouterOS. No new features, only bugs with new versions.
Wny not use accel-ppp? In-kernel supported out of the box, just binary daemon needed.
-
I confirm the bug, I must write how to replicate the problem and send to support@mikrotik.com
-
I not test this problem.
+1
I am stuck with 6.7 where this works ok, just because.
Example
OVPN client (192.168.1.231) —> OVPN Server (192.168.1.1) - bridge ------> lan 192.168.1.0/24
client can ping anyone in lan, lan can ping client, client cannot ping 192.168.1.1 .
As such , i cannot use 192.168.1.1 to route to other subnets that the 192.168.1.1 server knows about since it’s not reachable.
In 6.7 it works ok.
Hello i have this problem:
this is not fixed?
What’s new in 6.11 (2014-Mar-20 09:16):
*) ipsec - fix aes-cbc hardware acceleration on CCR with key sizes 192 and 256;
*) wireless - add auto frequency feature;
*) ovpn - fixed TLS renegotiation;
*) ovpn - make bridge mode work with big packets (do not leave extraneous padding);
*) ovpn - fixed require-client-certifcate;
*) ppp - revert RADIUS NAS-Port behaviour, report tunnel interface id;
*) ppp - mppe encryption together with mrru locked the router;
*) dhcp - added support for DHCP option 138 - list of CAPWAP IPv4 servers;
*) quickset - added Guest Network setup to Home AP mode;
*) console - no longer required to supply value of ‘/routing bgp instance vrf’
property ‘instance’ for ‘add’ command;
*) ethernet - added option to enable rx/tx flow control
(will be disabled by default);
*) ethernet - added ability to specify advertised modes for copper ports;
*) fixed 100% cpu usage on CCRs;
*) ssl - not finding CRL in local store for any certificate in trust chain will cause connection to fail;
*) lte - support for Huawei ME609 and ME909u-521;
In 6.10 openvpn dont work good, 6.11 work very good but only one day, now i have this error.
Ntp hangs on reached