I setup a site in 2007 with ver3 RouterOS and the site was working perfect until I upgrade from ver 3.6 to ver4 then my problem start, the stations started disconnecting itself in the night and sometime will go down between 7.30 and will only come back early in the morning may around 5am or sometime 6am and sometime I have to do hard reboot by removing the power and putting back before the station can come back. Now I decide to reconfigure the system to use wds but problem is far from over. I am using the network to drive 50 CCTV cameras in a golf estate. On my main high site I am using dedicated pc as a router with 3 90% sectorized antenna and one gird antenna.
Control room Rb 600
Main high site PC X86
3x Station RB112
4x Station RB433AH
3x Station RB 532
The management of this golf estate have cancel my maintenance contract with them because of this problem because it is taking me time to sort out.
With all due respect, you have not provided any info on your wireless setup, except that you have some routerboards interconnected via wireless. Export your wireless settings from a typical example site that is a problem and we may be able to help you further.
One hint, I’ve had issues with some of my clients after upgrading to 4.x.
You can reset your wireless card to defaults and reconfigure, seems to help 75% of them, or you can downgrade to 3.30, which in my case, is a 100% fix.
Agree. I still recommend that all production devices remain on v3.30 until v4.x stabilises. I’m still having all sorts of odd problems which get fixed in the next version but then something else gets broken! If Mikrotik slowed down on rolling out new features on a current release and concentrated on fixing current releases, it would be much easier to know what version to recommend to nstall! Either the latest v4 with all the bells and whistles (and the risk of bugs) or v3 with always all the bugs fixed and no new features. But I can only dream.
I’m not sure whether this would work or not, just an idea though.
This way, they could release feature releases as ‘beta’ and wait for all bugs to be fixed in current feature release. As bugs are being fixed, they will be fixed in current feature release, and next (now beta) feature release. Then, it would be easy to compare the two (at Mikrotik labs) to see if a feature is breaking something critical. Also, for customers, it gives us the comfort that we can stay with a release until Mikrotik decide to move to the next feature release.
I really do think this would help a lot. At least there should be some way of not including features.
Another idea would be to release features as individual packages (.npk files) So ex. wake on lan comes out, they release it as 3.xx-wol.npk (meaning it would only work on v3.xx or later). Then in the next ‘major’ release (v4.0, v5.0, etc..) they would be included with system.npk package.
Mikrotik, I would like a way to ‘exclude’ features in favor of only bug fixes. Would this be possible?
Ron and Doug, I have no idea what disconnection problems you have in v4, the problem with Nstreme was fixed and most people have no issues with wireless. As usual, if you have a specific issue, email mikrotik with setup details and supout.rif files.
We are working on a brand new driver in v5, first glimpse just came out, but the real deal will be probably in the next beta (3).
It is more general than just wireless. I have had problems with vlans recently in v4, wasted two dayson a client’s site with a 750G. Was convinced either I was an idiot or it was the Netgear switches not working as per 802.1q. Then I saw in next release that MT fixed it so booked a new day to visit client to upgrade the 750s, but then I heard from a colleague that you fixed vlan but broke DHCP, so I waited again. This is only the most recent problems. You guys release versions sometimes very fast as you fix one problem, then break something, then fix again.
It is therefore difficult to know for sure which version is really the ‘stable’ one. Is it the one that does not get superceded for a long time, suggesting there are no serious bugs, so no new release or has development stopped as the staff are elsewhere?
But this is off topic and has been discussed many times before, just you did ask!
I can give many examples of commercial firmware that does not get changed for many years, not days or weeks. Why? Because a) it never gets any new features added to it and b) it ‘just works’
ROFL - OK I understand the pressure of your customer’s demands.
But I was told IPv6 over PPoE was a bug, it used to work, then it was broken. Now in new version it works again, so not new feature.
My discussion is more about how MT can be open minded to make the business decision of revolutionising the way you reveal to us, your customers, what release is a good version as it fixes bugs from an untested new version because of some new feature you added. Changelog is not open enough, it does not reveal all the fixes and also does not explain all the new features (example: complete change to command syntax of DNS server settings, a great new feature, but it breaks scripts for any subversion prior to it’s release and wasted a lot of my time)
If the MT senior staff are open minded and can take constructive comments and discuss our ideas for a better method you will have a lot more happy customers. I am not a supporter of anyone who just complains in a negative way, that helps nobody, coming up with constructive solutions is always better than destructive complaints!
If you have good ideas how to improve the release system, you can always send them to the support email, and they will be forwarded to those who don’t read the forum as thoroughly as I do
Export your wireless settings from a typical example site that is a problem and we may be able to help you further.
