v6.41 [current]

mkx · Fri Jan 19, 2018 4:32 pm

The workaround is to add TCP MSS rule to your firewall rules

Would you care to paste appropriate command to implement that workaround here? Thank you!

Chupaka · Fri Jan 19, 2018 4:35 pm

https://wiki.mikrotik.com/wiki/Manual:I ... Change_MSS

mkx · Fri Jan 19, 2018 5:07 pm

I'll appreciate much if someone can explain to me all that stuff...

As I already wrote, my VLAN-infested RBs are still on 6.40.5, so things might have changed. However, my setup is something like this:

/interface ethernet switch port
set 0 vlan-mode=secure
set 1 vlan-mode=secure
set 2 default-vlan-id=42 vlan-header=add-if-missing vlan-mode=secure
set 3 vlan-mode=secure
set 4 default-vlan-id=2 vlan-header=add-if-missing vlan-mode=secure
set 5 vlan-header=add-if-missing vlan-mode=fallback

/interface ethernet switch vlan
# .. I guess this is the old style of defining which ethernet port is member of which VLAN

add independent-learning=no ports=switch1-cpu,ether1,ether2,ether3,ether4 switch=switch1 vlan-id=42
add independent-learning=no ports=ether1,ether2,ether5,ether4 switch=switch1 vlan-id=3999
add independent-learning=no ports=switch1-cpu,ether1,ether2 switch=switch1 vlan-id=41
add independent-learning=no ports=switch1-cpu,ether1,ether2 switch=switch1 vlan-id=40
add independent-learning=no ports=switch1-cpu,ether1,ether2,ether5,ether4 switch=switch1 vlan-id=2

N.b. port 0 is switch CPU interface. Only some ports have PVID set. I have other VLAN-capable switches that serve most access ethernet ports.

/interface vlan
add interface=bridge name=vlan-2 vlan-id=2
add interface=bridge name=vlan-40 vlan-id=40
add interface=bridge name=vlan-41 vlan-id=41
add interface=bridge name=vlan-42 vlan-id=42

/interface bridge port
add bridge=bridge interface=ether1

You can see that VLAN 3999 does not enter the router's bridge, it's dealt with completely by switch chip.

/ip address
add address=192.168.42.1/23 interface=vlan-42 network=192.168.42.0
add address=192.168.41.1/24 interface=vlan-41 network=192.168.41.0
add address=192.168.40.1/24 interface=vlan-40 network=192.168.40.0
add address=192.168.1.240/24 interface=vlan-2 network=192.168.1.0

The router has 4 different addresses, one per VLAN where routing is needed and none where it's not (VLAN 3999).

The bridge itself acts like a passive wire in my case, it passes packets between the member interfaces (vlan-* interfaces, switch-cpu and two wifi interfaces I didn't show in config). It's up to configuration of individual interfaces to drop any VLANs not interesting and tag packets without VLAN tags (PVID).

It's up to IP filter rules to restrict access to ROS itself, so management access is not restricted on per-port basis, but rather on IP address basis (or any other filter ROS offers, which incidentally includes inbound port as well).

One might say that this kind of bridge setup is not entirely safe. My answer is that probably the very same administrator is configuring all aspects of a given router and it doesn't matter at what particular point/interface (s)he limits inappropriate traffic to enter/leave the routerboard device.

@bobr: in your case, the problem of no management access is probably due to the fact that management computer, connecting to eth5, does not use VLAN-tagged packets and consequently gets tagged with VLAN ID 1 (PVID setting). You either need to configure your management computer to use VLANs or configure eth5 with PVID=110 (and make sure also that VLAN segement gets routed/NATed to internet if so desired).

vipnet · Fri Jan 19, 2018 6:21 pm

The problem is already fixed in 6.42rc.

The workaround is to add TCP MSS rule to your firewall rules

adding tcp mss to my firewall doesn't work router os 6.41

eworm · Fri Jan 19, 2018 9:08 pm

The problem is already fixed in 6.42rc.

The workaround is to add TCP MSS rule to your firewall rules
adding tcp mss to my firewall doesn't work router os 6.41

Neither works for me. Did anybody succeed to fix this with a firewall rule?

armarsh · Fri Jan 19, 2018 9:37 pm

i have a problem with my router. When i upgrade from 6.40 to 6.41 i cant login in to routerboard, it said cannot connect to 20561 port

Clauu · Fri Jan 19, 2018 11:13 pm

Hello, same problem with some sites not accesible on all devices with 6.41.. changed tcp mss without any luck so.. please advice.
L.E: So as a quick fix, edit the ppp profile and modify 'Change TCP MSS' from default/yes to no. This should fix the issue.

JimmyNyholm · Sat Jan 20, 2018 2:04 pm

The problem is already fixed in 6.42rc.

The workaround is to add TCP MSS rule to your firewall rules

Witch will disable fastpath on your router yes!?

sindy · Sat Jan 20, 2018 2:21 pm

Which will disable fastpath on your router, yes!?

It won't. TCP MSS has to be adjusted only in the first two packets of each session, and the fasttracking rule only applies on the following ones anyway (TCP state established is reached after the SYN,ACK has been processed).

JimmyNyholm · Sat Jan 20, 2018 2:30 pm

Which will disable fastpath on your router, yes!?
It won't. TCP MSS has to be adjusted only in the first two packets of each session, and the fasttracking rule only applies on the following ones anyway (TCP state established is reached after the SYN,ACK has been processed).

I wasn't talking about fast track this is for firewall state tracking but more optimisted.
FastPath is NO FIREWALL enabled forward only as fast as you can with as little cpu resources that you can. This is SPEED

IF I only use the device for routing I would like fastpath to stay active. That was my objection as to do mangle rules.
IF I use firewall then surly to get any performance fasttrack would be good but this is orders of magnitude slower then fastpath.

Chupaka · Sat Jan 20, 2018 2:50 pm

Witch will disable fastpath on your router yes!?

If it's critical for you - just stay with 6.40 or earlier

JimmyNyholm · Sat Jan 20, 2018 3:14 pm

If it's critical for you - just stay with 6.40 or earlier

Am doing just that, was just stating the obvious.

gosha · Sat Jan 20, 2018 4:16 pm

After upgrading smoothly SSTP VPN is working fine but there is no route to internal LAN.

Until this upgrade everything was running OK, is there any issue or extra configuration to be done with SSTP interface?

I have the same problem but not only SSTP affected, PPtP is not working too. Even more strange that if remote ip is from another network, it will work...

Clauu · Sat Jan 20, 2018 8:06 pm

Hello, same problem with some sites not accesible on all devices with 6.41.. changed tcp mss without any luck so.. please advice.
L.E: So as a quick fix, edit the ppp profile and modify 'Change TCP MSS' from default/yes to no. This should fix the issue.

As an update, seems that changing that it will break another sites.. so isn't a viable solution.
Without upgrading to rc6.42, any other ideas please?

gosha · Sat Jan 20, 2018 9:03 pm

Can I downgrade in case if firmware was upgraded to 6.41? Which previous version to choose?

Sun Jan 21, 2018 2:41 pm

Yes. Easily by downgrade when device works. More difficultly when it does not work using netinstall. You can choose whatever version you want just it cannot be lower than original version from manufacturing.

bobr · Sun Jan 21, 2018 2:49 pm

@mkx:

my VLAN-infested RBs are still on 6.40.5, so things might have changed

do you have a vlan filtering ability and hw-offload in your bridge configurations? 'cause if no - yep, things are changed and, if my memory serves me, in 6.40.5 brigde had no vlan filtering ability yet and master-port functionality is still present there.
with master-port the things were pretty clear. but now, without master-port the configs are slight different. I even say - much different. so, all my questions are related exactly to those changes. for someone to explain to me, how did new functionality changed the behaviour of all those vlans stuff.

in your case, the problem of no management access is probably due to the fact that management computer, connecting to eth5, does not use VLAN-tagged packets and consequently gets tagged with VLAN ID 1 (PVID setting). You either need to configure your management computer to use VLANs or configure eth5 with PVID=110 (and make sure also that VLAN segement gets routed/NATed to internet if so desired).

I think, you should re-read my post more precisely:

/interface ethernet switch port
# ether5 port
set 3 default-vlan-id=110 vlan-header=always-strip vlan-mode=check
# switch1-cpu port
set 4 default-vlan-id=1 vlan-mode=check

or did I do something wrong?

anyway - thanks - you're the only one person here who tried to help! :

:

sindy · Sun Jan 21, 2018 5:36 pm

you're the only one person here who tried to help!

Maybe because it is new for everybody so no one feels competent enough yet to advise in this high-profile topic? This was at least my reason to wait for someone more competent to answer.
Also, in my opinion such a question would deserve its own topic due to the size of the answer.

So if you want my personal understanding, which may differ from the real implementation, here you go:
The bridge concept of 6.41 was declared as a way towards uniting bridge and switch configuration in one. So the first thing to do if you start from scratch is not to do any /interface ethernet switch setings at all as they are likely in conflict with those done the new way.

Creation of a bridge interface creates both the bridge in software (as in the old way, including the ability to attach an IP configuration directly to it) and a group of swicth ports (which is empty at the beginning untill you assign some ports to it).

So the first step is to create the bridge (with any flavour of STP switched off for now and with vlan-filtering switched off as well):

/interface bridge
add fast-forward=no name=bridge1 protocol-mode=none vlan-filtering=no pvid=1

If you eventually assign an IP configuration to this bridge1, it will be using VLAN ID 1 because pvid is set to 1.

Next, you assign the member ports of that bridge, both those at the switch and those at the CPU including eventual virtual ones (like L2 tunnels). I'm not sure whether hw=yes won't cause a conflict and the manual says it is enabled automatically if possible, so let's not specify any value:

/interface bridge port
add bridge=bridge1 interface=ether2-uplink pvid=1
add bridge=bridge1 interface=ether3 pvid=1
add bridge=bridge1 interface=ether4 pvid=300
add bridge=bridge1 interface=ether5 pvid=110

Those Ethernet ports which are going to become access ports must have the corresponding PVID set.

As you want to create an IP interface to be accessed via VLAN ID 110, you have to create a corresponding virtual interface as a member of that bridge:

/interface vlan
add interface=bridge1 name=vlan110 vlan-id=110

Of course, let's assign the IP configuration to it as well:

/ip address
add address=192.168.110.211/24 interface=vlan110 network=192.168.110.0

And now - what you had to do in switch configuration before has to be done in bridge configuration now. Note that several VLAN IDs may be grouped at each line and bear in mind that all VLANs in the same group must have the same topology across the whole network if you want MSTP to work. I assume that the configuration below only becomes necessary and relevant once you change the vlan-filtering to yes, i.e. that already the steps above should cause everything you wanted to work except the vlan-filtering, but I may be wrong:

/interface bridge vlan
add bridge=bridge1 vlan-ids=110 tagged=bridge1,ether2-uplink untagged=ether5
add bridge=bridge1 vlan-ids=200 tagged=ether2-uplink,ether3
add bridge=bridge1 vlan-ids=300 tagged=ether2-uplink,ether3 untagged=ether4

Note that for VLAN ID 110, the bridge itself is indicated as a tagged member port of itself. This seems to be necessary to allow frames to be forwarded between the virtual interfaces (bridge and vlan) and the physical interfaces, in another words, between the CPU and the switch. This is the most confusing point for me. I don't know understand why it is not done automatically.

Also note that the vlan110 virtual interface does not need to be indicated as a member here.

With the settings above done, you can activate vlan-filtering at the bridge:

/interface bridge set bridge1 vlan-filtering=yes

After doing that, packets with VLAN IDs other than those for which a given interface is a member of the bridge will not be forwarded to/from that interface.

nmt1900 · Sun Jan 21, 2018 10:45 pm

I have similar (bad) experience with the new bridge and VLAN tagging. The first attempt to convert my initial multi-bridge setup to a single bridge with VLAN tags failed.
I reverted to my pre-6.41 configuration (separate bridge for each VLAN and switch configured for the VLANs and tagged/untagged ports) and have to try again some time.

Same thing here.

Had everything working with VLAN filtering on test setup (CRS326), but when I tried to apply new single bridge setup (same as test setup) in production environment, nothing worked - no matter whether it was done by modifying old multibridge configuration or setup fresh after reset.

Worst anomaly was bridge losing ports after reboot - interestingly enough not all were lost. When I fired up test setup at the office again - same one which was working (!) - then surprise, surprise, bridge had only few of attached ports left over there too.

Maybe it's better to wait for 6.42 - CRS326 seems to be capable of adequate performance for our current needs even in multibridge setup...

Clauu · Sun Jan 21, 2018 11:52 pm

Until release of 6.42'stable', has anybody any solution to this?

Hello, same problem with some sites not accesible on all devices with 6.41.. changed tcp mss(iptables firewall) without any luck so.. please advice.

We are seeing a strange problem with 6.41 in the fact that it prevents one particular HTTPS website from being accessable. This is the case if either 6.41 is running on the PPP server/router or indeed if 6.41 is running on the client's Mikrotik router.
The website in question is https://safeseas.ie/ssi/login.jsp and we have replicated the problem on many iterations of 6.41 across multiple sites. In each case rolling back fixes the issue.
Feedback would be welcome
Same problem with http://fl.yantarenergosbyt.ru/
On 6.39.3 all good, on 6.41 and newer - cant open site.
I see this problem if MT set like pppoe-client. If internet from dhcp-client - site available.
We have same problems with PPP server/router with http://fl.yantarenergosbyt.ru/ and https://www.verbojuridico.com.br/default.aspx

please team MK new relese

AKuntsevich · Mon Jan 22, 2018 9:51 am

The problem is already fixed in 6.42rc.

The workaround is to add TCP MSS rule to your firewall rules

Yes, now fixed in rc11.
Before tested on rc9 - problem still here.

Clauu · Mon Jan 22, 2018 10:17 am

I understand that in rc it is fixed, but i(we) need a solution without installing the rc version. Adding a firewall rule didn't change anything.

Mon Jan 22, 2018 11:39 am

If mangle rule did not fix the problem then either your rule is incorrect or it is not TCP MSS problem.

eworm · Mon Jan 22, 2018 12:52 pm

Looks like this works for me:

/ppp profile
set [ find default ] change-tcp-mss=no
/ip firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu out-interface=all-ppp protocol=tcp tcp-flags=syn

Then reconnect your ppp connection try to access the affected sites.
Can anybody confirm?

Clauu · Mon Jan 22, 2018 9:42 pm

Seems fine your suggestion, thanks!

Lansman · Tue Jan 23, 2018 12:10 pm

I have the same experience. After the upgrade, no connection via ethernet or wifi works. Wifi is off. Winbox cannot show it. I asked another RB on the LAN which properly upgraded to show its neighbours, and the dead RB is listed with a MAC address of 00:00:00:00:00:00. The dead device is up in the air, been operating for a few years, and properly installed to protect it from rain and weather. It will not be fun to replace. It will not be fun to hit a reset button. Any ideas will be appreciated.

I upgraded my RB750Gr3 from 6.40.5 to 6.41, and now I cannot connect to it via wire or wireless. Did I miss anything here?

Thanks.

......................................
******* UPDATE**********
.....................................

I placed this laptop at ground level. I climbed to the RB Metal 2SHPn. I dismounted it and cut off the shielded ethernet connector. I brought the Metal inside. If you remember, nothing could see the Metal. It had no MAC address, and wifi was off after upgrade. I knew I must use Netinstall, but you must watch your laptop when setting up Netinstall. You must see that you are loading the new OS. I had to try many times, but finally I saw the Metal in Netinstall. I told it to go install the new OS and keep the old config. It did. All the old user settings were kept. Then I had to go back up with the Metal, and tighten the Metal back on the old mast. Then put a new connector on the shielded cat 5 cable. I did that after renewing the fusing electrical tape over the N connector and antenna. I still must put better water protection over that connector. The antenna is a nice OMNI, about 4 dBd gain.

This is a lot of work for an automatic upgrade. Be warned. Mikrotik does not automatically fully check automatic upgrades to be sure it will work. After an upgrade, you may have lost all connection to your Router Board until you can get at the reset button and have a nearby computer to do a Netinstall.

inversistemas · Tue Jan 23, 2018 6:02 pm

Since my RB3011 was upgraded from 6.40 to 6.41 my bridges aren't working as usual, and I still don't understand well enought about "hw-offload" and "switch chip", I just feel that "master-ports" was working fine.

> My setup is:
interface type vlan / name: vlan20-4 / vlan ID: 20 / interface: ethernet4
interface type vlan / name: vlan20-3 / vlan ID: 20 / interface: ethernet3

interface type bridge / name: bridge20 / STP protocol: RSTP / VLAN filtering disabled

bridge port / bridge name:bridge20 / interface name: vlan20-4 / Hardware offload: checked / Edge: auto / ingress filtering: unchecked / Frame: admit all
bridge port / bridge name:bridge20 / interface name: vlan20-3 / Hardware offload: checked / Edge: auto / ingress filtering: unchecked / Frame: admit all

but, with this, my bridge is not working...

any help? any idea?

sindy · Tue Jan 23, 2018 6:14 pm

but, with this, my bridge is not working...

Please read this post and if it does not help, create a new topic and place here a link to it, I'll try to guide you.

UMarcus · Tue Jan 23, 2018 6:15 pm

Hello,
i had update all my Devices (CRS124, HAP and HAP Lite) to 6.41.

Now I get errors like 'port received packet with own address as source address' and a packet storm. Network is down.

The configuration is 3x HAP and 2 HAP lite as CAP and the CRS124 as CAPSMAN and 5 VLAN Networks.

This only happens if both HAP lite connected !
If i remove one of them the network is running without issues. If i reconnect the second HAP Lite it takes a short time than i get this packet storm.

I already reset the HAP Lite and reconfigure it but without luck.

Any ideas how to investigate and fix that or is it a bug in the new 6.41 ?

Thanks
regards
Marcus

eworm · Tue Jan 23, 2018 6:32 pm

Now I get errors like 'port received packet with own address as source address' and a packet storm. Network is down.

I have seen this once, but could not reproduce since. No idea what happened and why.

macsrwe · Tue Jan 23, 2018 8:34 pm

Can you please explain, when Mikrotik will amend the CRS3xx releases, so that the supout.rif not gets written to volatile memory, but onto flash instead ?

When you type the command to take the supout, begin the file name with flash/.

Wed Jan 24, 2018 3:25 pm

Could we expect that 6.40.5 will become "bugfix" or 6.40.6 with fixes from 6.41?

6.40.5 is the last with "old-known-bridge-implementation" technology and not all want to upgrade to "new-better-but-not-too-familiarized" one.

bajodel · Wed Jan 24, 2018 9:25 pm

Could we expect that 6.40.5 will become "bugfix" or 6.40.6 with fixes from 6.41?
6.40.5 is the last with "old-known-bridge-implementation" technology and not all want to upgrade to "new-better-but-not-too-familiarized" one.

+1 .. absolutely, and keep 6.40.x on bugfix for long time

karlisi · Thu Jan 25, 2018 8:35 am

Could we expect that 6.40.5 will become "bugfix" or 6.40.6 with fixes from 6.41?

6.40.5 is the last with "old-known-bridge-implementation" technology and not all want to upgrade to "new-better-but-not-too-familiarized" one.

+1001

bobr · Thu Jan 25, 2018 9:05 am

Could we expect that 6.40.5 will become "bugfix" or 6.40.6 with fixes from 6.41?
6.40.5 is the last with "old-known-bridge-implementation" technology and not all want to upgrade to "new-better-but-not-too-familiarized" one.

+1 .. absolutely, and keep 6.40.x on bugfix for long time

+1001

Quite agree. Or make all that stuff with new bridge-to-L2 behaviour and features more transparent and understandable. 'Cause before 6.41 you made master port and then went to Switch in winbox and did all the stuff for L2, including VLANs, there. And now the things are not as clear.

Fri Jan 26, 2018 3:41 am

Re: v6.41 [current] (problem - clients lost DHCP default route after upgrade)

Is anybody else experiencing this issue ?

When I upgrade wireless remote Mikrotik DHCP clients, I experience problems after the remote client reboots.

The most important issue I am seeing is that the remote clients no longer have a DHCP default-route.
FYI - The wlan is software bridged to WAN & The WAN is a DHCP client -and- the WAN IP addresses are part of my Live-Internet-IPs

Example:
I upgraded a remote client from 6.40.5
Here is part of the export (prior to the upgrade - still on 6.40.5)
/ip dhcp-client
add default-route-distance=0 dhcp-options=hostname,clientid disabled=no interface=WAN

After the remote client is upgraded to 6.41
/ip dhcp-client
add dhcp-options=hostname,clientid disabled=no interface=WAN

As you can see , the default-route-distance=0 is now missing.

Below is larger portion of the export prior to upgrading:
/ip dhcp-client
add default-route-distance=0 dhcp-options=hostname,clientid disabled=no interface=WAN
/ip dhcp-server network
add address=192.168.56.0/24 gateway=192.168.56.1
/ip dns
set max-udp-packet-size=512 servers=66.35.8.72,66.35.8.73
/ip firewall nat
add action=masquerade chain=srcnat
/ip ipsec policy
set 0 dst-address=0.0.0.0/0 src-address=0.0.0.0/0
/ip proxy
set cache-path=web-proxy1 max-cache-size=none parent-proxy=0.0.0.0
/ip route
add distance=1 pref-src=192.168.56.111 type=blackhole
add distance=1 pref-src=192.168.56.119 type=blackhole
add distance=1 pref-src=192.168.56.118 type=blackhole
add distance=1 pref-src=192.168.56.120 type=blackhole
add distance=1 pref-src=192.168.56.106 type=blackhole
add distance=1 pref-src=192.168.56.114 type=blackhole
add distance=1 pref-src=192.168.56.115 type=blackhole
add distance=1 pref-src=192.168.56.100 type=blackhole
add distance=1 pref-src=192.168.56.101 type=blackhole
add distance=1 pref-src=192.168.56.102 type=blackhole
add distance=1 pref-src=192.168.56.103 type=blackhole
add distance=1 pref-src=192.168.56.104 type=blackhole
add distance=1 pref-src=192.168.56.105 type=blackhole
add distance=1 pref-src=192.168.56.117 type=blackhole
add distance=1 pref-src=192.168.56.107 type=blackhole
add distance=1 pref-src=192.168.56.109 type=blackhole
add distance=1 pref-src=192.168.56.108 type=blackhole
add distance=1 pref-src=192.168.56.110 type=blackhole
add distance=1 pref-src=192.168.56.113 type=blackhole
add distance=1 pref-src=192.168.56.112 type=blackhole
add distance=1 pref-src=192.168.56.116 type=blackhole
add distance=1 dst-address=10.0.0.0/8 gateway=192.168.56.3
add distance=1 dst-address=10.0.0.0/8 type=blackhole
add distance=1 dst-address=172.16.0.0/12 gateway=192.168.56.3
add distance=1 dst-address=172.16.0.0/12 type=blackhole
add distance=1 dst-address=192.168.0.0/16 gateway=192.168.56.3
add distance=1 dst-address=192.168.0.0/16 type=blackhole
/ip route rule
add action=drop interface=WAN src-address=192.168.0.0/16
add action=drop interface=WAN src-address=10.0.0.0/8
add action=drop interface=WAN src-address=172.16.0.0/12
add action=drop dst-address=10.0.0.0/8 interface=WAN
add action=drop dst-address=172.16.0.0/12 interface=WAN

-and now for some additional export information after the firmware upgrade:
/ip dhcp-client
add dhcp-options=hostname,clientid disabled=no interface=WAN
/ip dhcp-server network
add address=192.168.56.0/24 gateway=192.168.56.1
/ip dns
set max-udp-packet-size=512 servers=66.35.8.72,66.35.8.73
/ip firewall nat
add action=masquerade chain=srcnat
/ip ipsec policy
set 0 dst-address=0.0.0.0/0 src-address=0.0.0.0/0
/ip proxy
set cache-path=web-proxy1 max-cache-size=none parent-proxy=0.0.0.0
/ip route
add distance=1 pref-src=192.168.56.111 type=blackhole
add distance=1 pref-src=192.168.56.119 type=blackhole
add distance=1 pref-src=192.168.56.118 type=blackhole
add distance=1 pref-src=192.168.56.120 type=blackhole
add distance=1 pref-src=192.168.56.106 type=blackhole
add distance=1 pref-src=192.168.56.114 type=blackhole
add distance=1 pref-src=192.168.56.115 type=blackhole
add distance=1 pref-src=192.168.56.100 type=blackhole
add distance=1 pref-src=192.168.56.101 type=blackhole
add distance=1 pref-src=192.168.56.102 type=blackhole
add distance=1 pref-src=192.168.56.103 type=blackhole
add distance=1 pref-src=192.168.56.104 type=blackhole
add distance=1 pref-src=192.168.56.105 type=blackhole
add distance=1 pref-src=192.168.56.117 type=blackhole
add distance=1 pref-src=192.168.56.107 type=blackhole
add distance=1 pref-src=192.168.56.109 type=blackhole
add distance=1 pref-src=192.168.56.108 type=blackhole
add distance=1 pref-src=192.168.56.110 type=blackhole
add distance=1 pref-src=192.168.56.113 type=blackhole
add distance=1 pref-src=192.168.56.112 type=blackhole
add distance=1 pref-src=192.168.56.116 type=blackhole
add distance=1 dst-address=10.0.0.0/8 gateway=192.168.56.3
add distance=1 dst-address=10.0.0.0/8 type=blackhole
add distance=1 dst-address=172.16.0.0/12 gateway=192.168.56.3
add distance=1 dst-address=172.16.0.0/12 type=blackhole
add distance=1 dst-address=192.168.0.0/16 gateway=192.168.56.3
add distance=1 dst-address=192.168.0.0/16 type=blackhole
/ip route rule
add action=drop interface=WAN src-address=192.168.0.0/16
add action=drop interface=WAN src-address=10.0.0.0/8
add action=drop interface=WAN src-address=172.16.0.0/12
add action=drop dst-address=10.0.0.0/8 interface=WAN
add action=drop dst-address=172.16.0.0/12 interface=WAN

North Idaho Tom Jones

Chupaka · Fri Jan 26, 2018 8:16 am

Nope, working okay for me. "default-route-distance=" is missing because its default value changed to 1, I think, and 0 is changed to 1 automagically

pe1chl · Fri Jan 26, 2018 11:30 am

distance can only be 0 for "directly connected" routes (the automatically generated routes that correspond to the address/net of an interface), all other routes including your default route have a distance of at least 1. So distance=0 is invalid.

Chupaka · Fri Jan 26, 2018 1:35 pm

distance can only be 0 for "directly connected" routes (the automatically generated routes that correspond to the address/net of an interface), all other routes including your default route have a distance of at least 1. So distance=0 is invalid.

It's invalid from 6.41, but earlier it was working

pe1chl · Fri Jan 26, 2018 5:12 pm

It's invalid from 6.41, but earlier it was working

What do you mean with "working"? In 6.40.5 I cannot add a static route with distance=0.
You mean a DHCP client with default-route-distance=0 was adding a route with distance=0?
That must have been a bug that has been fixed...

What problem does that cause? Remember subnet size always has higher precedence than distance,
so for a route to 0.0.0.0/0 the distance really doesn't matter relative to those blackhole routes, those will
still be used even when the default route has distance=1 or distance=2 or higher!

Distance setting for the default route is just there to have the possibility of having several internet interfaces
with different default route distance so it is know which one has preference. distance=0 is not required for that.

kfaessen · Fri Jan 26, 2018 6:21 pm

Does anyone know how to get the certificates working in 6.41? It worked in all the previous versions but the https service tells me now that it's Invalid and I assumed that it's caused by the changes in the certificates.

I have a wildcard certificate at comodo and I have imported all the linked root certificates. The CRL's are also downloaded automatically of all the certificates, so that seems fine to me. However the https service still complains invalid (without telling what is invalid)

Edit: I have figured it out, it appeared that port 443 is blocked by something else, when I changed the port to 8443 it worked. Now I need to figure out what is blocking port 443.

Related configuration (I have changed my domain name in the text, it's obvious not test.com)

[admin@MikroTik] > /certificate print
Flags: K - private-key, D - dsa, L - crl, C - smart-card-key, A - authority, I - issued, R - revoked, E - expired, T - trusted
 #       NAME                                    COMMON-NAME               SUBJECT-ALT-NAME                   FINGERPRINT
 0 K L T wildcard.test.com                       *.test.com                DNS:*.test.com                     09133...
 1     T AddTrustExternalCARoot                  AddTrust External CA      Root                               687fa...
 2   L T COMODORSAAddTrustCA                     COMODO RSA                Certification Authority            4f32d...
 3   L T COMODORSADomainValidationSecureServerCA COMODO RSA                Domain Validation Secure Server CA 02ab5...

[admin@MikroTik] > /ip service print detail
Flags: X - disabled, I - invalid
 0 XI name="telnet"  port=23   address=""
 1 XI name="ftp"     port=21   address=""
 2    name="www"     port=80   address=192.168.1.0/24
 3    name="ssh"     port=22   address=""
 4 I  name="www-ssl" port=443  address=192.168.1.0/24 certificate=wildcard.test.com
 5 XI name="api"     port=8728 address=""
 6    name="winbox"  port=8291 address=""
 7    name="api-ssl" port=8729 address="" certificate=*C

SDFadfasdfadsf · Sat Jan 27, 2018 7:17 pm

log overwriting broke? It looks like after mem log is full, new logs are all "item add", "item removed" garbage. These logs should have been firewall drop actions.

genesispro · Sat Jan 27, 2018 8:21 pm

I think I found a minor winbox bug @6.41
It allows me to add the same interface list to a bridge port multiple times

Biker111 · Sun Jan 28, 2018 5:12 am

Deleted ...

Chupaka · Sun Jan 28, 2018 9:04 am

You mean a DHCP client with default-route-distance=0 was adding a route with distance=0?
That must have been a bug that has been fixed...

Yep, that's exactly what happened. And that change could introduce some other bug, for example

pe1chl · Sun Jan 28, 2018 12:22 pm

You mean a DHCP client with default-route-distance=0 was adding a route with distance=0?
That must have been a bug that has been fixed...
Yep, that's exactly what happened. And that change could introduce some other bug, for example

What is that "other bug"? I still don't get why you would want to have a default route with distance=0

pe1chl · Sun Jan 28, 2018 1:12 pm

I found a limitation in the configuration for ip neighbor using interface-list instead of explicit settings...

In the old 6.40.5 situation on a CCR1009 I had this setting:

/ip neighbor discovery
set ether2 discover=no
set ether7 discover=no
set ether8 discover=no
/ip neighbor discovery settings
set default-for-dynamic=yes

When updating to 6.41 RouterOS has created an interface list "discover" and added all static interfaces
except the ones named above to it, and set /ip neighbor discovery-settings set discover-interface-list=disover

This of course did not work until another reboot. But that is a known bug.
However, now there is no way to include the set default-for-dynamic=yes setting which handles discovery
on the dynamically created (incoming L2TP/IPsec) interfaces!)
I tried adding "dynamic" for the "include" setting of the interface list "discover" but that does not do it.
(even did another reboot after that change).
Neiighbor discovery no longer works for my dynamic interfaces unless I enable it on "all" which of course enables
it on the 3 abovementioned interfaces as well.

macsrwe · Sun Jan 28, 2018 5:38 pm

You mean a DHCP client with default-route-distance=0 was adding a route with distance=0?
That must have been a bug that has been fixed...
Yep, that's exactly what happened. And that change could introduce some other bug, for example
What is that "other bug"? I still don't get why you would want to have a default route with distance=0

For example, I had an initialization script for a class of routers that was initially generated two years ago from an export of a working hand configuration. The export process created a DHCP client with default-route-distance=0 specified (something I would not have specified by hand, but was present in the export). I went to use it yesterday, and it failed to import, because MikroTik made this fix. So, bug.

pe1chl · Sun Jan 28, 2018 7:59 pm

it failed to import, because MikroTik made this fix. So, bug.

It should probably just ignore the distance=0 in the input and use the default distance=1
However, this is always a tough decision: should it silently ignore invalid parameters that were valid in the past, potentially confusing users, or should
it issue error messages.
My solution would be:
- in normal command mode it should issue error messages
- in import mode it should ignore those parameters even when error messages occur

This is a generic gripe I have about import (and running of script after reset-configuration): it should be able to continue processing when minor errors occur.
This is just a special case of that.

Chupaka · Mon Jan 29, 2018 12:23 pm

What is that "other bug"? I still don't get why you would want to have a default route with distance=0

Well, the "other bug" I thought of was "the remote clients no longer have a DHCP default-route" %)

tay · Mon Jan 29, 2018 7:42 pm

hi everybody

My opinion is too bad over version 6.41 , i didnt find master port.........
best regards

raffav · Mon Jan 29, 2018 8:41 pm

hi everybody

My opinion is too bad over version 6.41 , i didnt find master port.........
best regards

Read the changes log before posting
Master port was removed, now is all on bridge interface

Enviado de meu XT1580 usando Tapatalk

anuser · Wed Jan 31, 2018 7:15 pm

*) capsman - use "adaptive-noise-immunity" value from CAP local configuration;

I cannot find that option. Can someone please give some hints?

Update: That should be sufficient, right?

/interface wireless cap set enabled=no 
/interface wireless set adaptive-noise-immunity=ap-and-client-mode wlan2 
/interface wireless set adaptive-noise-immunity=ap-and-client-mode wlan1
/interface wireless cap set enabled=yes

spikehome · Thu Feb 01, 2018 10:34 am

today i updated my 2011 from 3.41 to 6.41
but one of the routers give now the msg when i do the command system routerboard print
error - contact MikroTik support and send a supout file (2)
also when i connect with winbox and go to system routerboard
the page is empty
it seems the update is not good.
The file is at my router
the commands to update are not working
how can i force to install the routeros manualy?

also i cannot make the supout.rif file with the command:
/system sup-output name=supout.rif
get then the same error.
error - contact MikroTik support and send a supout file (2)

Fri Feb 02, 2018 7:22 am

Version 6.41.1 has been released:
viewtopic.php?f=21&t=130356

Who is online