deleted

buenas tardes este firmware lo instale en 3 equipos rb750gl pero los mismos dejaron de funcionar, se reinicia constantemnete y los leds encienden y apagan a cada momento no los puedo recuperar ni con netinstall, tienen alguna solucion para este problema me quedaron 3 equipos como pisapapeles.

I don't think the Mikrotik guys understand Spanish nor will most of the forum members. I believe there is a Spanish forum somewhere too...

But I'll translate:
"Good afternoon this firmware is installed on 3 devices rb750gl but these don't work after anymore, they are rebooting all the time and the LEDs are going on and off continuously. I cant' get the units back , not even with netinstall. Do you have any solution for this problem because I now have 3 units that are useless (well, I am not translating "pisapapeles".. )"

deleted

Usually when people claim their devices cannot be recovered by netinstall, it is because this is their first experience with netinstall.
Netinstall requires some proficiency to use, and trying it for the first time will usually fail, no matter if the router is in a reboot loop or perfectly fine.
Only when you have experience with netinstall and you have used it before to re-install routers, and it now fails on some other routers, you can claim that it "cannot be fixed using netinstall".

That's the point. More than that, doing the netinstall looks always a bit different from the device behavior point of view, especially if it is different model in every case.

Switching off the antivirus, firewall, other interfaces, manual ip configuration, running netinstall as admin and holding the button pressed until one see the device in netinstall application are the most important success factors. The rest is a bit of alchemy mixed with woodoo.

After dozens and dozens netinstalled devices I never know what will be the problem with the next one.

after update to 6.42.4 DHCP server cannot assign IP to some of our IP cam (mostly Foscam) randomly with this message: dhcp,warning dhcp1 offering lease 192.168.xxx.xxx for 44:2C:05:xx:xx:xx without success, never have the same problem with 6.42.3

How to fix this?
I update my MT RB1100AHx2 to latest version 6.42.4 after this may hotspot config doesn't work, its login page doesn't display and those on ip bindings doesn't work as well



hope for your rapid response. thanks.

deleted

Hi,

Just to say regarding this point:

joserudi, WirelessRudy - These fixes has nothing to do with Nv2 performance. In some cases ARM routers were rebooting themselves while runnning Nv2 links. Now we have introduced fixes that help in such cases.

My SXTsq 5 ac (6.42.4 (stable)) using a PTP Nv2 connection is still rebooting occasionally. Previously it was rebooting once a day or more (at one point every hour), but now it seems to stay up for 3 to 4 days before it reboots. The Nv2 connection is also very stable now, and only the reboots causes a drop.

Any room for further improvements to stability?

Thanks,

Chris

Hi all there! I was always fan of Mikrotik! was proud of having such a great network company in Latvia...
till some months ago...
It's seems people from UBNT started to work in Mikrotik.... for the last year....
Why it just started to suck... different configurations for different rb models in vlans,... are You kidding? cant't rewrite config in common syntax?
sorry for my mistakes... just try to not use f words...

nothing really new nor in hardware nor in software... is theis the begginning of the end?

please reply! or delete this post, if u dont care!

in this case i will send all 150 + routers and 400+ client and wifi antennas as a donation back to You!

Why it just started to suck... different configurations for different rb models in vlans,... are You kidding? cant't rewrite config in common syntax?

The VLAN configuration is the same for all models. MikroTik completely changed (improved) the VLAN configuration in 6.41 for all devices. It is not MikroTik's fault if you have some routers running versions before 6.41 and some running later versions.

EDIT: Above, I assumed that Iviks was referring to software VLAN config, and not hardware, since hardware VLAN config (and its often confusing relationship with software VLAN config) has been problematic for a long time instead of just a new issue.

Why it just started to suck... different configurations for different rb models in vlans,... are You kidding? cant't rewrite config in common syntax?

The VLAN configuration is the same for all models. MikroTik completely changed (improved) the VLAN configuration in 6.41 for all devices. It is not MikroTik's fault if you have some routers running versions before 6.41 and some running later versions.

You must be kidding... CRS1xxx vs CRS328..
Some you have to do in new bridge configuriration some left in Switch Chip. Others you can completly made in bridge menu and retain HWoffload.
So don't mislead people. Iviks has a valid point regarding VLAN config. It is not the same for all models if you want HW offload and I am certain this is what he means.

But on the point of this topic:
Can anyone confirm that there is no Switch menu on 6.42.4 for hAPac2? if you config it via cli it works.

The VLAN configuration is the same for all models. MikroTik completely changed (improved) the VLAN configuration in 6.41 for all devices. It is not MikroTik's fault if you have some routers running versions before 6.41 and some running later versions.

This is pertinent NOT true! arm models with 6.41 are not working properly with PPPoE. Everytime we take a new arm unit (SXT-sq, LHG, DISC) we can set it up with same config as we use for some 800 other routers but we have to upgrade to 6.42.x just to make internet traffic for the client happening!
Everything else works, even the antena has internet access but any traffic coming in on the PPPE-client interface on wlan is not passing to LAN port. Just a simple upgrade to 6.42.3 of .4 makes it to work again.....

But ok, since we are now on 6.42.4 and that works for all devices so far (on the use we have) we are not sending to support because we solved the problem ourselves. But what Iviks was writing was true! There were some months we couldn't even use our new batch of arm devices or we had to put a rc version on. There was no PPPoE support for a while but at the same time normal mipsbe etc devices with clone configs had no issue.....

Some you have to do in new bridge configuriration some left in Switch Chip. Others you can completly made in bridge menu and retain HWoffload.
So don't mislead people. Iviks has a valid point regarding VLAN config. It is not the same for all models if you want HW offload and I am certain this is what he means.

I assumed he must not be talking about HW offload. He said "it just started to suck", meaning he was talking about a recent change. VLAN config has always been a PITA with hw-offload, and the 'switch' menu has always been different for different device models, so the fact that this was always awkward did not jibe with his statement that it "just started to suck", and by this line of reasoning he must not have been referring to the switch menu. Except for MikroTik switches where you don't necessarily need VLAN interfaces, you've always had to set up VLANs in two places instead of one if you need hw-offload and it was easy to get two packets received for every packet sent and other weirdness like that if you didn't know exactly what you were doing. If he is talking about new things, he must mean the VLAN config under "bridge". The VLAN config was always so much of a problem with hw-offload that we just did them in software (except for switches and other such cases where we badly needed hardware acceleration).

To my knowledge, the content of the "bridge" menu is the same in all models. That is what I meant, nothing about the 'switch' menu. I assumed when I was answering he must be talking about the bridge menu, not the 'switch' menu, and that he found the bridge menu was different on some devices than others. The bridge menu should only be different on devices that are running different RouterOS versions, so I assumed if he finds the bridge menu to have different contents on different devices it must be due to different RouterOS versions on those devices.

Also, I would assume the goal is to eventually remove the 'switch' menu from all devices by integrating this functionality into the bridge, but that would take time due to different functionality with different switch chips in different devices etc. It is probably too much to expect MikroTik to integrate all of that so soon after the new bridge is developed, and the new bridge code hasn't been around for that long. I have been advising people on 6.41+ to ignore the 'switch' menu completely unless they really need something there.

This is pertinent NOT true! arm models with 6.41 are not working properly with PPPoE.

I wasn't saying anything about other issues with 6.41. My reply was only regarding the VLAN config in the bridge menu, which was changed in 6.41, and nowhere did I say that 6.41 was bug free in all regards. I have no doubt that there were bugs, and to be on the safe side, we have been remaining for several months at versions below 6.41 on production devices without careful testing to make sure everything worked. The new bridge is a big change, and big changes always have a high risk of new bugs...

I just encountered a problem with upgrading a RB850Gx2 to version 6.42.4. After the upgrade, Winbox will no longer complete connecting to the RB850Gx2. The main window opens, and a few subwindows start to populate, and then the Winbox connection hangs up, and eventually times out. The appearance is similar to what I’ve encountered in the past when there were MTU size differences that seem to cause Winbox to choke when handling large packets. However, in this case, there should not be any MTU size inconsistencies.

Note that I did upgrade my Winbox client to 3.15. I’ve also rebooted the RB850Gx2 several times, and I did perform the firmware upgrade/reboot operation as well, though this does not appear to have been necessary.

I am able to access this RB850Gx2 via SSH and the console without any problems.

Prior to the upgrade to 6.42.4, I had been on 6.42.3 with this RB850Gx2. I was not having problems accessing this router via Winbox.

Is anyone else having a problem like this?

I just encountered a problem with upgrading a RB850Gx2 to version 6.42.4. After the upgrade, Winbox will no longer complete connecting to the RB850Gx2. The main window opens, and a few subwindows start to populate, and then the Winbox connection hangs up, and eventually times out. The appearance is similar to what I’ve encountered in the past when there were MTU size differences that seem to cause Winbox to choke when handling large packets. However, in this case, there should not be any MTU size inconsistencies.

Haven't seen this myself except in the case that you mention (MTU size differences) which is related to use of MAC winbox. Are you connecting to winbox with IP?

Are you sure it isn't an MTU issue? I've seen issues before with bridge auto MTU not adjusting properly when adding a port, resulting in a bridge IP MTU that is higher than it should be. Disabling and re-enabling the bridge or rebooting the device triggers the bridge to recalculate the correct MTU to use based on the ports that are attached and then it works. I haven't been able to reproduce this issue consistently.

I just encountered a problem with upgrading a RB850Gx2 to version 6.42.4. After the upgrade, Winbox will no longer complete connecting to the RB850Gx2. The main window opens, and a few subwindows start to populate, and then the Winbox connection hangs up, and eventually times out. The appearance is similar to what I’ve encountered in the past when there were MTU size differences that seem to cause Winbox to choke when handling large packets. However, in this case, there should not be any MTU size inconsistencies.

Haven't seen this myself except in the case that you mention (MTU size differences) which is related to use of MAC winbox. Are you connecting to winbox with IP?

Are you sure it isn't an MTU issue? I've seen issues before with bridge auto MTU not adjusting properly when adding a port, resulting in a bridge IP MTU that is higher than it should be. Disabling and re-enabling the bridge or rebooting the device triggers the bridge to recalculate the correct MTU to use based on the ports that are attached and then it works. I haven't been able to reproduce this issue consistently.

I appreciate your suggestions, however this particular router has all interfaces and bridges left at default MTU sizes (i.e., actual mtu = 1500). I just scanned all interface specifications on this RB850Gx2, and every Ethernet, VLAN, and bridge is set for an MTU of 1500 (for Layer 3 protocols). I’m familiar with the MTU problems affecting Winbox because I do have lots of MikroTik routers of various stripes configured to use non-standard MTU sizes. My impression is that Winbox has issues with packet fragmentation. However, this RB850Gx2 should have been easy, since all MTU settings were left at default.

I posted this problem on this thread since it appears to be related to upgrading from 6.42.3 to 6.42.4 (or possibly the upgrade to Winbox 3.15). I changed nothing else, and I had no problem with Winbox until I performed the upgrade. Also, other routers I’ve upgraded to 6.42.4 (mostly X86 variants) have not had problems. One possibility is that this is related to the PPC processor family.

One possibility is that this is related to the PPC processor family.

I can confirm that 6.42.4 on RB1100AHx2 (PPC) does not have this issue with Winbox disconnects.

I think I may have misremembered the MTU issue that I had - L2 MTU of the bridge had 65535 like a bridge with no ports, even though it had a bunch of ports (IP MTU was set to 1500 everywhere). One symptom of this issue was broken DHCP. Disabling and re-enabling the bridge changed the L2MTU to change from 65535 to 1580 (the L2 MTU of the ports) and then DHCP started to work. If this is not your issue then it doesn't matter but I have encountered this before, and it sometimes happens on a reboot after a RouterOS upgrade.

This is pertinent NOT true! arm models with 6.41 are not working properly with PPPoE.

I wasn't saying anything about other issues with 6.41. My reply was only regarding the VLAN config in the bridge menu, which was changed in 6.41, and nowhere did I say that 6.41 was bug free in all regards. I have no doubt that there were bugs, and to be on the safe side, we have been remaining for several months at versions below 6.41 on production devices without careful testing to make sure everything worked. The new bridge is a big change, and big changes always have a high risk of new bugs...

I must agree with Iviks statement. I too was a great follower of MT for quite some time, and implemented many of these at customers sites. So much so that for a long time I even didn't need a forum account, but could figure it out by myself with my favorite search engine.
But recently I have seen time and time again that MT implements changes that do not allow for fallback, and are so fundamental that every somewhat more complex config is impacted. The most significant I think (but certainly not the only one) is the omission of masterports, in combination with the switchconfig.

Sure, I understand that the old method was complex, and specific for every device. But it allowed for some very neat configs that optimally uses the hardware. Which we are now missing.
So I certainly understand that MT wants to make something that always works on every of their devices.

But my point is that many of those devices that are already deployed and running with the old-type configs (in my case mostly with Masterports and switchconfig), are at some point hit by a OS-vulnerability that needs a newer RoS version to fix it, and therein is no more Masterports (or switchconfig) available. The autoconvert does not give a working setup. Manual reprogramming is needed, including sometimes reapproval or recertification.
This is a cost that one cannot just present to the customer, just because there was a security update.
So in short what we need is some kind of fallback! We need CONTINUITY!!

Eg. a way to import the old config with some hidden option to allow old configs to load without conversion, but with old options still in.
Or a proper LTSB like option, maintained over let's say 5 years or so. (so the continuation of 6.40.bugfix way-way-way beyond 6.40.8 )

Another example was Netwatch. There is no override for it. Even if there are no lower-privileged users available to misuse the function. Scripts based on that now need to be rewritten.

Masterports and switchconfig was in my case reason enough to ring the alarm-bell last year, even before it became "current" in 6.41. I created a forumuser (hence the name) and formulated what I perceived as a pending issue. But response on forum was nearly nonexistent, just one question for me to give an example by a user, and an explanation by a MT-tech that everything is "now possible" in a bridge. Apparently nobody cared... or understood the fundamental implications...
So I figured "I'll give bridges a try, maybe it will become better in time". And I did. But bridges hardly became better on vlans. And by now, I stopped upgrading to 6.41 and beyond.

But in the mean time, apparently MT realized that switchconfig cannot (yet) be missed, and re-added it to for instance on hap-ac2.

For me personally, without Masterports, I need to spend too many hours per device at the customers end to reprogram the config to a working one. So I'll remain in bugfix-hell 6.40.xxx as long as possible, and if I have to advise the customer on an upgrade, I probably will have to advise against MT. Simply because (currently) MT is no longer a viable option for continuity.
And thát is what is a PITY imho. As routerboard is really a great concept.

My examples are of course just indicative of the larger problem.
But please MT, give us something stable and safe to fall back on..... come on....
Not everyone is constantly playing around with their config. Not everyone want a new feature every week.. Some of us just need a stable system that can be kept safe with updates and/or bugfixes.
And... don't just remove functionality, that can cripple a config. That's just bad business.

This is a much wider issue than whether or not bridge is better than masterports, or if a user might misuse the netwatch function to execute something he normally cannot do.
It seems thinking ahead and grasping the consequences of such "improvements" is just not high on the MT priority-list anymore



Ps. another incomprehensible MT-strategy lately is the structurally shrinking of the flash-size. Was a few years ago 64MB pretty much standard on even the lowest end devices, now even the higher end devices only come with only 16MB. (I know, 16MB NOR serial flash is much smaller and cheaper than 64Mb parallel NAND). But situation now it's so bad that you cannot even install all packages anymore on an arm device with 16MB (for testing, certification and/or evaluation). You first have to remove one, to install another.
And even more important, twin partitions for ROS-failover, what many of us like to do, is not even an option anymore.
Why is this possible on an el- cheapo 750GL, but not on a much more expensive but newer hap-ac?? Makes no sense at all. And certainly not good for continuity.
Don't shrink... but make bigger... Software (Ros) is generally also growing over time between versions... Makes no sense to shrink the medium where it should reside on....

Does it fix the "lost space after upgrade" issue on CCR?
(when upgrading 6.42.1 to 6.42.3 on a CCR split into two 64MB partitions a lot of diskspace remains in-use after the upgrade and not enough space is left for another upgrade)

Hi.
We have identical problem on all CCR-routers... I opend a ticket...

All this complaining about how thing used to be has nothing to do with this release, please stay on topic !

I updated all my devices to this current release, no problems seen so far.
(RB2011/RB1100/RB962/CRS125/CHR)

In the WISP environment that I work at, we have no MikroTik switches, we are running 6.40.8 on everything. We gave up on hardware acceleration long ago because we didn't really need it for our bandwidth levels and it makes configuration much too difficult for most people, so we got by with just the software bridge config for VLANs. With most people I have talked to, they never even set up the switch chip for VLANs except for CRS switches where the config was well documented. For all of those people (and for us), these changes suddenly mean that they (and we) can take advantage of hardware offload that previously went unused. There are probably a number of users who replaced MikroTik with something else because they either didn't know about the switch chip config with master/slave and just thought that MikroTik's switching was poor performing (and I know from seeing people posting on the forum that some in fact thought this) or they knew about the switch chip VLAN config and master/slave but found it too confusing and found it easier to replace it with another vendor instead of try to figure it out.

I can't tell you how many times that we would hire on a new tech with Cisco certification, very often CCNP or even CCIE, and they would usually understand everything in RouterOS without needing special explanation except the bizarre way (in 6.40 and earlier) of setting up VLANs on bridges, which these otherwise smart people would get very confused by. I cannot count the number of times that I had to draw up a whiteboard diagram so that the tech would understand the difference between a VLAN interface *on* a bridge vs. a VLAN interface that is connected to a bridge (i.e. acting as a port of a bridge). In comparison, the new means of configuration is much simpler for people to understand. Before these bridge changes, VLANs with bridges were harder to set up on RouterOS than probably any other platform and were set up in a strange way; now it is a normal way and I pretty much don't have to explain it, people get it right away. Once the switch menu functionality is completely integrated and the menu disappears, the rest of the complexity will be gone, and I hope they keep moving in this direction. Although I sympathize with those that have to make a few changes to the config after the upgrade so that things still work as they did before - maybe MikroTik can improve the conversion routine a bit to minimize this work? In the case of the WISP that I work for, the changes introduced in 6.41+ will not require that we make changes to the config, however, it is in our best interest to do so since it will remove three or four bridges from our config that we will no longer need due to these new features. For us, a simpler setup means fewer mistakes which means fewer customer issues, ultimately increasing customer satisfaction, even if it means we have to do a bit of extra work to get there.

I also think it is not realistic for MikroTik to maintain two different code bases for "continuity" for a long period (ex. your suggested 5 years of updates for the old 6.40.x codebase) all to save 10 minutes of reconfiguration time (if that) on a customer's router. If they intend to make a change every few versions with the same level of impact of the bridge change, that becomes more problematic, and then I would begin to complain seriously about continuity. However when they announced this change, I assumed it was an anomalous event, and did not represent a new trend of changing things that would break existing setups on a regular basis.

I cannot access to router via API(PHP) after updated.
Return back to BugFix only v.6.40.8 => Worked.

In the case of the WISP that I work for, the changes introduced in 6.41+ will not require that we make changes to the config, however, it is in our best interest to do so since it will remove three or four bridges from our config that we will no longer need due to these new features. For us, a simpler setup means fewer mistakes which means fewer customer issues, ultimately increasing customer satisfaction, even if it means we have to do a bit of extra work to get there.

I am using VLAN config in our network and as a test I migrated my own home router from a config where the VLANs were done in switch config, with each VLAN connected to a separate bridge, to a new-style config with a single bridge with all the VLAN filtering and no VLAN config in the switch menu. No spanning tree or other advanced features.
Although the two configs are completely equivalent, I have lost the hardware acceleration. I don't understand why that has to be, as on other routers where no VLANs were in use on the switch the hardware acceleration was retained during conversion to bridge setup (without VLAN filtering). IMHO it should be possible to have hardware accelerated VLAN bridging as the switch chips are clearly capable of doing it. This should have priority to implement, in fact it should have been included before the new bridge config went in to "current".

The new config isn't much clearer either. I agree with you that the switch config for VLAN is tricky to get right at first (because it is so different from the usual switch VLAN setup) but once you get the hang of it, it is easy. With bridge VLAN filtering there is similar possibility for goof-ups that ruin your day (like not including the bridge itself as a tagged member when you want to connect the CPU to the VLAN for routing). So I doubt that there will be that many fewer mistakes.

IMHO it should be possible to have hardware accelerated VLAN bridging as the switch chips are clearly capable of doing it. This should have priority to implement, in fact it should have been included before the new bridge config went in to "current".

I agree completely. It is highly problematic that with some models you cannot do bridge VLAN filtering at all without making hardware offload impossible. This should be more consistent between models, and I hope they are prioritizing that. Also, bridge options should ideally be clearly marked with whether an option is supported for hardware offload or not on a specific model, so that people will know what they have to do to get hardware offload without the guesswork (kind of like the way the hardware accelerated ipsec options are marked with the "(H)").

I cannot access to router via API(PHP) after updated.
Return back to BugFix only v.6.40.8 => Worked.

The problem is in 6.42.4 user needs also 'winbox' permission to login via API. Should be fixed in next version, now you can just add that permission.

mducharme:
You are just emphasizing my point now... apparently MT is now more involved in dumbing down Ros than providing a technically better and stable OS.
By removing code supporting previous features normal upgrade process is blocked, and therefore continuity is lost.
Therefore RB also LOST its validity as a serious professional networking equipment provider with proper support. (which is weird since MT is expanding in exactly that direction too)

Codebase should have stayed IN at least until all issues were resolved and old and new functionality was on par. (and maybe even then... leaving it in for backwards compatibility).
Instead, MT chose to prematurely remove it, and at the same time, MT shrinks Flash size, which likely contributes to the need for codebase removal.
And remember, it's not just switchmenu and masterports, but there are more recent examples.

I agree that one method that works for all MT devices is the nicest. I fully support the intention. But don't just ditch the old methods too.
And if you want a simple router to set up, buy a Sweex or Sitecom.... Ros is for people who invest in knowledge of how it works.
Even with new features, novices to RoS need to dig in first or get hopelessly stuck in sub-par configs... or worse.

Simplicity in itself is not a virtue. It's just an excuse.

eddieb:
I agree that this may not be the most appropriate place, as it is not a 6.42.4 specific issue. But if you make a separate thread for it, apparently MT and community don't care to look to serious fundamental issues. This also have been proven on this forum time and time again. General threads are apparently the only ones that have sufficient reader-base to trigger a proper discussion.
Without proper discussion, understandably MT looses interest too.

So to all that are offended by Iviks statement and my response (and other responses btw), I'm truly sorry for that.
It was just the "one too many". I sense that this is an issue more and more long-term RB users are frustrated with in spite of there affinity to the great RoS. Especially now that recently it seems to happen so often. It is not just reminiscing how great things were, but trying to point out a serious fundamental issue in order to make RoS an even better RoS. And as such, in an somewhat twisted way, the release thread of a new version (like this 6.42.4 thread) might actually even be the right place for it.
I would be happy to continue in separate thread if discussion is seriously done there. And including MT, where MT is not just digging-in and defending there current strategy without the obvious customer sensitivities they have recently been ignoring in pursuit of there own goals.

Hello,

Sorry for disturbing. But loss of hdd space appears on upgrading to 6.41.2, and gone worse with upgrade to 6.41.4.
In 64 Mb partitions (2x64), only 10-15% free space left after upgrade...

Dear developers. Please help. Ticket number #2018062222003568

RB2011 upgrade from 6.34.2.

- VLANs are not converted
- new bridge is not created but interface master-slave relations removed
- after removing all VLANs to re-create the configuration manually using a new bridge, 2 bridges are automagically created somehow (RB2011 has 2 switch groups) and interfaces added
- switch VLAN config is not touched, it's still there in the switch menu

The switch menu shouldn't be there, should it? Thankfully at least the router works now with the original switch VLAN config and the VLAN interfaces I added to the bridge.

EDIT: additionally, the sfp1 interface disappeared. We don't have a module in it, but it's nowhere to be found, not even in command line. It was there with the interfaces in 6.34.2.

The switch menu shouldn't be there, should it? Thankfully at least it works now with the original switch VLAN config and the VLAN interfaces I added to the bridge.

EDIT: additionally, the sfp1 interface disappeared. We don't have a module in it, but it's nowhere to be found, not even in command line. It was there with the interfaces in 6.34.2.

The switch menu should be there because they have not yet made all of the switch options work with hardware offload besides simple bridge ports (to replace the master/slave setting). On most models they have not yet made the bridge VLAN config work with hardware offload, so VLANs still need to be configured the old way if you need hardware offload. In our case (a WISP) we don't need hardware offload because we are not bridging more than 100Mbps so we configure everything using the new means even though it means hardware offload will be disabled.

However, the sfp1 interface should not have disappeared. Does rebooting the device again make it come back? Upgrade the RouterBOOT firmware as well just in case.

@mducharme: in the meantime I've "found" the VLAN filtering option (I was in a kind of hurry to bring things back online), so I'll start testing it on the RB2011. I've modified my original post, removing the false info. So it might become possible to use the bridge config and ditch the old switch config even on this model. We'll see.

No, I rebooted to update the firmware, too, and the sfp1 interface didn't appear.

EDIT: I checked the "VLAN filtering" option. The router immediately created dynamic VLAN configuration on the bridge, based on the current switch config, and disabled HW accel on the ports. Oh well. I don't really need HW acceleration there, though, as it's a gateway, but I'm pretty much pissed that now I need to configure the same thing at 2 places... Now I left it as is, using switch config and HW accel.

@mducharme: in the meantime I've "found" the VLAN filtering option (I was in a kind of hurry to bring things back online), so I'll start testing it on the RB2011. I've modified my original post, removing the false info. So it might become possible to use the bridge config and ditch the old switch config even on this model. We'll see.

No, I rebooted to update the firmware, too, and the sfp1 interface didn't appear.

I know with the RB3011 if spanning tree is enabled then hardware offload gets turned off, that might be the case for the 2011 as well but I'm not sure. Keep that in mind as you are experimenting with the config.

Try a cold boot of the device with complete power off for 30 seconds and power back on. If sfp interface does not reappear I would probably contact MikroTik support.

EDIT: I checked the "VLAN filtering" option. The router immediately created dynamic VLAN configuration on the bridge, based on the current switch config, and disabled HW accel on the ports. Oh well. I don't really need HW acceleration there, though, as it's a gateway, but I'm pretty much pissed that now I need to configure the same thing at 2 places... Now I left it as is, using switch config and HW accel.

If you don't need HW acceleration then you don't need to configure the VLANs in the switch menu (so you don't need it in two places), you can remove that config (set the switch config back to factory default and ignore the VLAN tab) and use only bridge VLAN filtering. You might get the HW acceleration back automatically at a future date when they add HW offload support for bridge VLANs with that model.

@mducharme: thanks for the heads-up about STP. I might switch to standard bridge config later, for now it works so I'll just let it be. I need remote hands to power-cycle, so maybe tomorrow. Luckily the SFP cage is vacant.

I'm having a strange problem since I think the update before 6.2.4 and still with 6.2.4.

I have a wireless bridge from my house to 2 out buildings using a wAPac as an 802.11 ap to feed them. Randomly both SM's will drop off the ap at the exact same time and will not attempt to reconnect until I shut wireless off at the AP and then back on. This happens on 2.4 and 5ghz. Any ideas?

I've had this setup for a very long time and no issues until recently.

I cannot access to router via API(PHP) after updated.
Return back to BugFix only v.6.40.8 => Worked.

The problem is in 6.42.4 user needs also 'winbox' permission to login via API. Should be fixed in next version, now you can just add that permission.

Hi Chupaka, could you explain better how to give this permission?
My only issue is that, if i could fix it i will not realize a downgrade.

Best Regards

Donkeyrollerz - You tried to download version while it was still being released.
pe1chl - Version fixes all the problems mentioned in changelog. There are no hidden fixes.

So no... So this might be a dangerous update for some people as it might use up more disc space and then they will not be able to update or downgrade and will be forced to Netinstall.

I tested the upgrade on a CCr1036 where I have plenty of HD space so if something goes wrong I wont get shut out. Indeed this update consumed 14MB of additional space. Pre 6.42 updates did not consume much more space like that. So something still seems wrong to me.

The 6.43RC's tho have been going fine for me even tho nothing has been mentioned in the changelogs. No additional space consumed so far in those.

So no... So this might be a dangerous update for some people as it might use up more disc space and then they will not be able to update or downgrade and will be forced to Netinstall.

I tested the upgrade on a CCr1036 where I have plenty of HD space so if something goes wrong I wont get shut out. Indeed this update consumed 14MB of additional space. Pre 6.42 updates did not consume much more space like that. So something still seems wrong to me.

That is why my two CCRs are effectively locked at 6.42.1 until MikroTik sort this out... which every .x release I hope they have done, but until now hey seem to rate this serious
issue low-priority

Remember, this occured using "current" versions! When I install an RC and get something like this, I expect to have to netinstall. But when I install current versions I expect them:
1 - to be tested to not have such errors
2 - in case something still goes wrong, to fix it in the next release and/or to ship a "fix" package for the affected release.

But now it has not been fixed in 2 "current" releases..... bad!

I cannot access to router via API(PHP) after updated.
Return back to BugFix only v.6.40.8 => Worked.

The problem is in 6.42.4 user needs also 'winbox' permission to login via API. Should be fixed in next version, now you can just add that permission.

I reported this a page before, funny that no one read the topic.

Update (NV2 - ARM reboot issue):

jun/23/2018 08:24:20 system,error,critical router was rebooted without proper shutdown
jun/26/2018 09:06:28 system,error,critical router was rebooted without proper shutdown

After 3 days my SXT SQ ac running a PTP nv2 link crashed. It seems very regular ; every 3 days the router crashes and complete reboots. This is the second crash now on 6.42.4, the first one was after 3 (approx) as well.

Chris

Hi everbody,
On 6.42.4:
- OSPF adjacency will randomly drop (tested on a CCR1016-12S-1S+ with 89 neighbors on different interfaces). If we go back to 6.42.3 the issue is not present anymore.
- Mean RAM usage on 6.42.4 is about 180mbytes more that 6.42.3 (tested on CCR1016-12S-1S+)
- After upgrade, RPS is enabled on CCRs (/resources irq rps enable) while it should be disabled by default. If we perform a factory reset it is disabled.

Anybody else is seeing this?

I already opened a ticket with support (TT 2018062522004007)

Thanks,
Daniel

Version v6.42.5 has been released in current channel:

viewtopic.php?f=21&t=136171