v6.41.1 [current]

[Paternot]

podrian ayudarme con la password de este mikrotic

junior18 , I think this translated is: “password could help me with this mikrotik”
Not sure I understand your question/statement
North Idaho Tom Jones

Not quite. It’s more like “could you help me with this mikrotik password?”

[coliflower]

Dear all,

with 6.40.3 I had on my wAP-ac for each vAP a VLAN (on ether1 = Trunk) and a separate bridge, connected together - e.g.: bridge-vlan10 + vlan10 + vAP10 … it worked fine.

With 6.41.1 there is some “spezial” bridge solution … is there any need to change my old vAP configuration, please ?
If yes or if better … is there any kind of red-line/best-prctice or some configuration file available to avoid to get in troubles, please ?

Thanks a lot in advance !

[sindy]

The “special” bridge solution brings some advantages (namely, hardware switching where possible and a possibility to run MSTP protocol and better operation of other flavours of STP).

However, in your setup where you just need to bridge several VLANs from a single Ethernet port to virtual APs running on the very same box, you can safely stay with your existing configuration. It continues to work and none of the advantages of the new method is applicable for your setup.

[myke1124]

I was upgrading some routers from previous versions to 6.41, when all of a sudden I notice the most recent version is now 6.41.1.

I noticed that on 6.41.1 I am unable to change the neighbor discover-setting. Shown below are console output from a 6.41 router and a 6.41.1 router. They are the same router. I performed the first neighbor discovery setting change from !dynamic to all, then upgraded the router from 6.41 to 6.41.1. When the router came back online, the neighbor discovery setting was reset from all to !dynamic, and I am unable to get it to change at all now, even after multiple reboots. This occurs from the console and winbox. Interesting…

# running v6.41 - can make changes to neighbor discovery-settings
[user@router] > /ip neighbor discovery-settings 
[user@router] /ip neighbor discovery-settings> print 
  discover-interface-list: !dynamic
[user@router] /ip neighbor discovery-settings> set discover-interface-list=all 
[user@router] /ip neighbor discovery-settings> print 
  discover-interface-list: all
[user@router] /ip neighbor discovery-settings> /system package update install 

# now running v6.41.1 - after reboot - can NOT make changes to neighbor discovery-settings from cli or winbox
[user@router] /ip neighbor discovery-settings> /ip neighbor discovery-settings 
[user@router] /ip neighbor discovery-settings> print 
  discover-interface-list: !dynamic
[user@router] /ip neighbor discovery-settings> set discover-interface-list=all 
[user@router] /ip neighbor discovery-settings> print 
  discover-interface-list: !dynamic
[user@router] /ip neighbor discovery-settings>

I have noticed that you can change discovery interfaces. It seems viewing the setting always reports !dynamic. As a test I have set to none. The setting appears to be !dynamic. No neighbors appear in the neighbor list. It works like none. It seems to work with whatever it is set to, however it always displays !dynamic.

[TomjNorthIdaho]

DHCP client on CHR reappears on purpose. You can not delete it. It is intended behavior.

ditto on the why question ?

There are some/many reasons an admin would not want a dhcp-client configuation on their CHR.

• If dhcp-client is not needed , why does it auto add the dhcp-client on reboot
• Why is not needed prior to v6.39x and earlier and now needed after v6.4x ?
• What happens if a CHR has a static IP address on a network that also has a DHCP server and the CHR also injects a dhcp-client configuration on the same network - now you have two IP addresses and possibly two different gateways ?
• Is there a way to remove the dhcp-client auto inject into the configuration without disabeling the dhcp package ? ( A CHR may need to be a dhcp-server and and not be also a dhcp-client )

Will this dhcp-client auto inject feature stay in all future versions/updates of CHR ROS or can/will the auto inject of dhcp-client be disabled or removed.
Am I correct in thinking the auto inject of dhcp-client was a planned function on CHR reboots if the dhcp package is enabled ?

confused - North Idaho Tom Jones

[coliflower]

The “special” bridge solution brings some advantages (namely, hardware switching where possible and a possibility to run MSTP protocol and better operation of other flavours of STP).

Hello Sindy,

thank you !
In this case, maybe I should to got the way of future und to adapt my configuration on both wAP-ac to the new bridge … any recommendation how to start, what to read, etc. ?

Thanks !

[LIV2]

Hello Sindy,

thank you !
In this case, maybe I should to got the way of future und to adapt my configuration on both wAP-ac to the new bridge … any recommendation how to start, what to read, etc. ?

Thanks !

The change in bridging is to do with hardware switching I thought, and since the wAP-ac doesn’t use a switch chip you shouldn’t be having any problems
Can you share your config?

[minhcoi]

After update 6.41.1 my RB951Ui 2HnD has alway reboot, and i cant winbox to interface address. How can I fix this?

[strods]

Splash - We are not aware about such problem. Usually such issues appear due to some configuration issue. Please send supout file to support@mikrotik.com
onlineuser - It might affect your situation, however, we can not give you precise yes or no answer. If the problem that you have is caused by delayed/slow responses to/from OVPN server, then this might help and your problem might go away;
mla, minhcoi - Have you tried to Netinstall your device;
jackx - Did you have such problem also in 6.41 release;
TomjNorthIdaho, sid5632, pe1chl, SPKA16, XaTTa6bl4 - This is intended behavior, because it is required in order to access CHR (when used on cloud services not hosted by yourself and you do not have access to the console). Also this was the behavior also before 6.41.1 RouterOS release. Please in future for such cases either contact support or create a new forum topic. Such posts might make other users to think that this release has some bug which affects CHR installations, however, it has nothing to do with concrete RouterOS release;
russman - Please send supout file from your router generated while SFP is not working properly to support@mikrotik.com;
myke1124 - Please before posting look through previous posts in the same topic. This problem is already resolved in 6.42rc version and fix will be included in 6.41.2 RouterOS release;

[LIV2]

The DHCP on CHR thing is annoying, I guess we can all add drop rules to the output chain to block the requests

[sindy]

Hello Sindy,

thank you !
In this case, maybe I should to got the way of future und to adapt my configuration on both wAP-ac to the new bridge … any recommendation how to start, what to read, etc. ?

Thanks !

The change in bridging is to do with hardware switching I thought, and since the wAP-ac doesn’t use a switch chip you shouldn’t be having any problems
Can you share your config?

@coliflower, @LIV2 has put in another words what I’ve already written: the new way of bridging won’t bring anything useful to you until you decide to deploy more than one Ethernet port, as it unites “bridge” and “switch” configuration into one and lets the RouterOS itself decide which functionality to execute in hardware and which in software. But you can change the settings if you want, so if the documentation is not clear enough, try to read the same in another wording in this post.

[minhcoi]

Splash
mla, minhcoi - Have you tried to Netinstall your device;

Because device canot stable so I tried to Netinstall but doesnt work.

[coliflower]

Hello Sindy,

thank you !
In this case, maybe I should to got the way of future und to adapt my configuration on both wAP-ac to the new bridge … any recommendation how to start, what to read, etc. ?

Thanks !

The change in bridging is to do with hardware switching I thought, and since the wAP-ac doesn’t use a switch chip you shouldn’t be having any problems
Can you share your config?

Yes, can do it if I am back from my business-trip.

[coliflower]

Hello Sindy,

thank you !
In this case, maybe I should to got the way of future und to adapt my configuration on both wAP-ac to the new bridge … any recommendation how to start, what to read, etc. ?

Thanks !

The change in bridging is to do with hardware switching I thought, and since the wAP-ac doesn’t use a switch chip you shouldn’t be having any problems
Can you share your config?

@coliflower, @LIV2 has put in another words what I’ve already written: the new way of bridging won’t bring anything useful to you until you decide to deploy more than one Ethernet port, as it unites “bridge” and “switch” configuration into one and lets the RouterOS itself decide which functionality to execute in hardware and which in software. But you can change the settings if you want, so if the documentation is not clear enough, try to read the same in another wording in this post.

Thank you Sindy,
I will read and check … Who knows when I need some additional Switch or to replace the current one

[sid5632]

TomjNorthIdaho, sid5632, pe1chl, SPKA16, XaTTa6bl4 - This is intended behavior, because it is required in order to access CHR (when used on cloud services not hosted by yourself and you do not have access to the console).

Please look at my comments on [Ticket#2018012422000218] [MT Support] CHR keeps recreating unwanted ether1 dhcp-client

Creating it initially makes sense, but recreating it automatically after the user has deliberately chosen to remove it and do something else is just plain STUPIDITY.
Your support person did seem to agree with me eventually.

[jackx]

I have downgraded all RouterBOARD 941-2nD to version 6.39.3 (bugfix) firmware 3.41 because version 6.41.1 causes slowdown that renders the devices too slow to even use their web interface.

[TomjNorthIdaho]

strods,sid5632, pe1chl, SPKA16, XaTTa6bl4

strods - please go ahead and create a new thread on this topic and we can follow this topic there.


Re: … This is intended behavior…
Who decided to make all CHRs only operate as DHCP-CLIENTS , and deny you the ability to disable dhcp-client?
There is no other operating system or router or any type of network device I can think of that forces you to only be a DHCP-Client.
You can’t disable it - You can’t remove it - You can’t turn it off - You can’t even factory default reset it without it comming back.
Just think about the world-wide impact if every network device, every router, every switch, every PC was suddenly forced to be a DHCP-CLIENT after a software upgrade , and there was no option to change/disable it ?

Re: Also this was the behavior also before 6.41.1 RouterOS release.
No, it was not.
The problem was not there prior to v6.4 (v6.39x and older work correctly)
The problem is there at v6.4 and later

Re: Please in future for such cases either contact support or create a new forum topic.
please go ahead and create a new thread on this topic and we can follow this topic there.

Re: … think that this release has some bug …
Lets just call it a new un-documented feature


North Idaho Tom Jones

[russman]

@strods

It didn’t generate a support file automatically. It didn’t crash the router, this is all regarding link negotiation via 10/100/1000M RJ45 SFP modules. Before the aforementioned update, the non-mikrotik modules would link up if the port was manually set to 1Gbps but wouldn’t let anything connect under any speed but 1Gbps even though the module supported it. The mikrotik one just did some odd things with auto-negotiation below 1Gbps and the speed reported that was fixed with the firmware update. After the update however, now only the mikrotik SFP will work regardless of link negotiation settings applied (auto and manual).

Testing was performed with:

• Mikrotik S-RJ01
• UBNT UF-RJ45-1G
• FiberStore SFP-GB-GE-T (#34976)

[sindy]

The supout.rif contains telemetry which is needed to analyze the issue. It is not mandatory that it is created “spontaneously” after a crash. So insert the previously-supported SFP and manually create the supout.rif for support.

[onlineuser]

onlineuser - It might affect your situation, however, we can not give you precise yes or no answer. If the problem that you have is caused by delayed/slow responses to/from OVPN server, then this might help and your problem might go away;

It looks good. At the first connection establishment the connection will be established.
Another feature would be that when there are more than one outgoing ovpn client only one by one connection will be established - this would be better for the CPU when 4k keys will be used on slower devices.