Two days is not one year. Support will answer within 3 business days usually.
yes, but first ticket was of 30/09/10.
It was replied on the same day, and you didn’t write back!
Mmmm.. I writed back..
We had problems with email service time ago.. perhaps it’s the same week we had problems..
I’ll wait for the next week, but only for an answer, because I think this think it’s so important for all of us, and not only for me. The virtualAP problem is easy to avoid for us, but we need to know that is working bad..
Its spread across several tickets. It goes back to 1/18/2010.
Ticket #2010011966000026. RB1000 OpenVPN stops.
A second ticket started on 1/21/2010
Response on 1/22 asking me to disable encryption or switch to l2tp/pptp, subsequently an email telling me to disable the one l2tp tunnel i had.
Response on 2/17 saying they found a memory leak in ovpn.
Response on 3/18 saying it will eventually be fixed, and suggested I switch to another tunneling protocol ( I have previously stated that I cannot as sensitive information is transmitted over these tunnels and legal/other regulations require me to use high encryption).
Response on 4/19 telling me to switch to SSTP in 5.0b2 as SSTP is the replacement for OVPN.
New ticket 5/12, SSTP doesnt calculate idle time.
New ticket 6/22, 6/25, 6/26, 6/27, SST memory leak/lockups.
Response 6/28 about 6/22 email telling me to disable openvpn and leave only SSTP enabled. “Unfortunately OVPN will not be fixed any time soon. We will release beta4 this week which has memory leak fixed.”
7/6 new ticket, same thing with openvpn disabled.
7/9 sent 2 supouts showing memory leak
7/15 Another ticket w/ SSTP crash
7/18 went to 5.0b5, memory leak supposedly fixed. Still happens, another ticket. No response
7/21 Opened another ticket.
7/23 response stating memory leak is fixed.
7/26 SSTP connections drop again/memory leak persists
I can go on. Point is, Ive been doing everything they ask me to do for 9 months now. I guess I am the sucker for purchasing over 200 mikrotik products and continuing to purchase with no fix.
The real irony? The warranty on about 1/2 of them will be up before I actually get a fix.
They are all different problems. If you got a new problem 6 months after the first problem, you can’t say that we waited 7 months to solve your second problem. You can’t count the ticket response times together 
I don’t see your point. At all.
They are all the same problem. VPN connections wont stay up. I went 6 months with openvpn not working properly, then switched to SSTP because you said openvpn wont be fixed soon and have gone 3-4 months with SSTP not working right.
Looking back, This all started when I had only 40 tunnels, now I have almost 140, probably close to 200 by the end of the year.
EDIT: If I switch back to OpenVPN now, is it fixed? Or is it still broken?
OpenVPN and SSTP have no relation whatsoever. Not the same thing = not the same problem.
If I switch back to OpenVPN now, is it fixed? Or will I have the same problem?
OpenVPN will not be fixed, it’s broken by design (not our implementation specifically). Reasons were already explained and discussed in other topics.
#1. It worked fine on my standalone linux box that I used before I switched to an RB1000. Even the MT clients connected to it fine.
#2. So we are back to the same issue. Almost 1 year of inconsistent VPN connections.
#3. Enough bickering. What do we need to do to get it fixed? I am willing to help in any way possible. Id like to see my RB1000 have over a week of uptime ONCE.
I’ve asked many times. OpenVPN is not going away. I think it’s thriving actually, yet Mikrotik seems to think it’s fading. Many people use it and my people like it a lot. To use OpenVPN, I’ll have to use other devices and Mikrotik will be out of the loop for the OpenVPN tunnels (very unfortunate). I sincerely hope Mikrotik will reach out to the community and ask for assistance.
The ironic thing is that OpenVPN is open source, and I know it can work solid and stable for any hardware, it’s a matter of programmers developing the code to do so. This has been done by many people for other platforms, Mikrotik just needs to ask. We are here to help. I know a lot of people on this forum are quite knowledgeable about linux and linux programming.
My suggestion: Please don’t drop OpenVPN. Why kill features? A lot have depended on it.
I’m sorry but that’s a huge cop-out, OpenVPN as others have stated works fine and stable on non-MT platforms, It just seems that MT has no time or no will to work with non-MT systems. If your not going to fix it then remove it.
OpenVPN has no UDP support. Why ? All other platforms i tried have UDP support.
Is it because UDP needs assembler code not available on RB hardware ?
OpenVPN is now used by clients. It can’t be dropped. It needs to be fixed and can be fixed because it does work on x86 platforms without problems.
Mikrotik is in a very odd position. On one hand, they have a lot GPL code which is proven stable. On the other hand, if they need to modify any of that code for their platform, they will have to release their changes.
I think the solution is to re-write most code to be 100% Mikrotik code, which is an awesome endeavor, however, like all programs written from scratch, they are bound to have bugs galore, and will take a long time to mature.
In my opinion, Mikrotik is not willing to change existing GPL code to fit their needs because they don’t want to release changes. We see this a lot:
- web proxy: was squid, but now re-written
- ssh: was openssh, but now re-written
- tftp: written from scratch with bugs (even though an open source version is very stable (hpa-tftp))
- driver support: latest Intel drivers have existed for a long time, yet never got included in RouterOS until official kernel included them
I do commend Mikrotik for doing this, they’ve achieved quite a bit, and came a long way in RouterOS. However, as much as I like any software, I really hesitate to think the above method is better. If code is out there, and it works, and it’s stable, it should be used for the better of any product. Then, more work could go into their own protocols (EoIP, Netstream, NV2, etc..) rather then trying to re-invent the wheel.
This is all from my experience through the years with Mikrotik, and is my own options and thoughts.
I think as well that they are in a difficult position. They need to change something.
They could open the code, and concentrate on hardware developpment.
There are lots of things to do on the hardware side, like implementing HDL code on FPGA chips, to get wire speed routing, filtering and hardware encryption for IPsec and other VPNs protocols.
Actually Mikrotik rely highly on private code and chips manufacturers. I’m not sure it’s the best solution to protect their work because they cannot use easily GPL code. More, using network integrated chips is quite dangerous because they cannot update them directly by code change.
If they were developping proprietary HDL code on FPGA chips, they could protect more easily there private work. So they could open router OS code, and include proprietary extensions to target the FPGA hardware acceleration.
HDL programming is the road to follow for fast and reliable routers. Classical processor max speed is 3 Ghz since years and will stay here next for some years because 3 GHz is a physical limitation well known by RF designers.
Companies not using parallel and logic processing (HDL programming) in their hardware design will stay at Gigabyte speed or less.
Router OS 5.0 RC1 problems show the limits of the actual strategy.
They do use GPL code and alot of it to the point where there are rumblings around FSF and the such of GPL violations
But anyway yes ROS is buggy and yes MT support is a bit of a pain (Stop telling me to install RC1 on production routers!) but you learn to work around it. We’ve only just done the jump from 3.30 to 4.10 because 4 was too buggy until 4.10 and we likely wont touch 5 until its about the same. MT release their versions too soon I haven’t seen a ROS release that hasn’t had some kind of MAJOR issues for the first 3-5 point releases
I think this is a very good discussion topic and needs more attention. I think emailing support@mikrotik.com could also gain some traction.
Normis has spoken, it wont be fixed 
This discussion is getting out of hand