v6.41 [current]

Kindis · Mon Jan 01, 2018 6:14 pm

everything works fine except that in the 951g I need fasttrack and I had to go back (downgrade) to the 6.40.5 only in the rborder ,since I have 300 Mb fiber and without the fastrack so, I got it just 200
I guess they'll fix that soon, until then we'll have to use the 6.40.5 to fastracker the connection

FastTrack on both my 750Gr3 and 3011 was not working at upgrade. Upgraded firmware (router boot) to latest and restarted. Still did not work but after yet another restart without any change to ROS or firmware everything started working again. Did you try to upgrade firmware after you went to 6.41 and also restart a third time?

Temorizador · Mon Jan 01, 2018 6:30 pm

everything works fine except that in the 951g I need fasttrack and I had to go back (downgrade) to the 6.40.5 only in the rborder ,since I have 300 Mb fiber and without the fastrack so, I got it just 200
I guess they'll fix that soon, until then we'll have to use the 6.40.5 to fastracker the connection
FastTrack on both my 750Gr3 and 3011 was not working at upgrade. Upgraded firmware (router boot) to latest and restarted. Still did not work but after yet another restart without any change to ROS or firmware everything started working again. Did you try to upgrade firmware after you went to 6.41 and also restart a third time?

No, i dont reset the mikrotik once it has been upgraded,if is this u question . but i delete fastrack from filter rules and rebbor the rb , went create a nuew rule to activate fasttrtack, not work although he told me the packages and the bytes... so I went back to 6.40.5.
But if you confirm that if you reset and configure to hand the configuration, the fastrack work ,I can test it

someone has tried it and it has worked ? it's going well all for you ?
-------------------------------------------------------------------------------
No , no resetee el mikrotik una vez upgradeado , pero si que elimine fastrack de filter rules y reinicie . Luego volvi ha crear la regla de fasttrtack pero seria sin funcionar aunque me augmentaba los paquetes y bytes ...asi que volvi a la 6.40.5.
Pero si me confirmas que si se resetea y se configura a mano desde cero toda la configuracion luego el fastrack funciona, puedo provar

alguien lo ha provado y le ha funcionado , te va todo bien compi ?

___________________________________________________________________________

bbs2web · Mon Jan 01, 2018 6:50 pm

RouterOS 6.41 does not honor received MSS value in TCP SYN packet. We are subsequently unable to connect to our routers through a VPN connection from our offices.

pe03 --- MPLS --- br01 --- ccr1 --- Linux system running PPTP

Traffic capture on pe03 shows TCP SYN packet arriving with TCP options where MSS is set as 1312 bytes. Replies aren't visible on this router as they are MPLS switched to br01. Reviewing a packet capture on interface facing 'customer' on br01 or upstream interface on ccr1 shows pe03 sending back an ACK with MSS incorrectly set as 1460 bytes.

First packet (SYN) sending correct MSS of 1312 bytes:

Reply acknowledgement from pe03 showing incorrect MSS of 1460 bytes having been set:

Kindis · Mon Jan 01, 2018 8:08 pm

everything works fine except that in the 951g I need fasttrack and I had to go back (downgrade) to the 6.40.5 only in the rborder ,since I have 300 Mb fiber and without the fastrack so, I got it just 200
I guess they'll fix that soon, until then we'll have to use the 6.40.5 to fastracker the connection
FastTrack on both my 750Gr3 and 3011 was not working at upgrade. Upgraded firmware (router boot) to latest and restarted. Still did not work but after yet another restart without any change to ROS or firmware everything started working again. Did you try to upgrade firmware after you went to 6.41 and also restart a third time?

No, i dont reset the mikrotik once it has been upgraded,if is this u question . but i delete fastrack from filter rules and rebbor the rb , went create a nuew rule to activate fasttrtack, not work although he told me the packages and the bytes... so I went back to 6.40.5.
But if you confirm that if you reset and configure to hand the configuration, the fastrack work ,I can test it

someone has tried it and it has worked ? it's going well all for you ?
-------------------------------------------------------------------------------
No , no resetee el mikrotik una vez upgradeado , pero si que elimine fastrack de filter rules y reinicie . Luego volvi ha crear la regla de fasttrtack pero seria sin funcionar aunque me augmentaba los paquetes y bytes ...asi que volvi a la 6.40.5.
Pero si me confirmas que si se resetea y se configura a mano desde cero toda la configuracion luego el fastrack funciona, puedo provar

alguien lo ha provado y le ha funcionado , te va todo bien compi ?

___________________________________________________________________________

No I did not reset. After upgrade to 6.41 I upgraded routerboot to latest firmware (also 6.41). Both upgrades includes a reboot. After about a day I noticed that FastTrack did not work on both my 750 and 3011. Did a simple reboot and everything started working again. Nothing more that that solved my issue.

Mon Jan 01, 2018 11:23 pm

Traffic capture on pe03 shows TCP SYN packet arriving with TCP options where MSS is set as 1312 bytes. Replies aren't visible on this router as they are MPLS switched to br01. Reviewing a packet capture on interface facing 'customer' on br01 or upstream interface on ccr1 shows pe03 sending back an ACK with MSS incorrectly set as 1460 bytes.

That's normal and is in accordance with the existing standards. MSS is NOT negotiated, but rather each side of the connection just informs the other side of the connection (by using the MSS TCP option) about the maximum segment size it is able to receive. For each TCP connection different MSS values may be used in each direction of data flow. There's no requirement for the MSS value set by the initiator to be "reflected" by the responder; thus MSS clamping, if required, should be applied in each direction of data flow independently.

estdata · Tue Jan 02, 2018 12:11 am

I think that version 6.41 mess of the inside of the
I installed a and came out of that system-routerboard > under notice

Warning: the default and the cpu Frenquency

Temorizador · Tue Jan 02, 2018 1:06 am

everything works fine except that in the 951g I need fasttrack and I had to go back (downgrade) to the 6.40.5 only in the rborder ,since I have 300 Mb fiber and without the fastrack so, I got it just 200
I guess they'll fix that soon, until then we'll have to use the 6.40.5 to fastracker the connection
FastTrack on both my 750Gr3 and 3011 was not working at upgrade. Upgraded firmware (router boot) to latest and restarted. Still did not work but after yet another restart without any change to ROS or firmware everything started working again. Did you try to upgrade firmware after you went to 6.41 and also restart a third time?

No, i dont reset the mikrotik once it has been upgraded,if is this u question . but i delete fastrack from filter rules and rebbor the rb , went create a nuew rule to activate fasttrtack, not work although he told me the packages and the bytes... so I went back to 6.40.5.
But if you confirm that if you reset and configure to hand the configuration, the fastrack work ,I can test it

someone has tried it and it has worked ? it's going well all for you ?
-------------------------------------------------------------------------------
No , no resetee el mikrotik una vez upgradeado , pero si que elimine fastrack de filter rules y reinicie . Luego volvi ha crear la regla de fasttrtack pero seria sin funcionar aunque me augmentaba los paquetes y bytes ...asi que volvi a la 6.40.5.
Pero si me confirmas que si se resetea y se configura a mano desde cero toda la configuracion luego el fastrack funciona, puedo provar

alguien lo ha provado y le ha funcionado , te va todo bien compi ?

___________________________________________________________________________
No I did not reset. After upgrade to 6.41 I upgraded routerboot to latest firmware (also 6.41). Both upgrades includes a reboot. After about a day I noticed that FastTrack did not work on both my 750 and 3011. Did a simple reboot and everything started working again. Nothing more that that solved my issue.

Ok ty i dotn undestand to start

,sorry my english , tomorrow to morning i will upgrade try again and i will try as you said, ty for explanation

,

____________________________________________________

Ok gracias, no entendí al principio

, lo siento por mi ingles , mañana por la mañana upgradeare de nuevo u provare como mehas dicho, gracias por la explicacion

Kindis · Tue Jan 02, 2018 1:15 am

everything works fine except that in the 951g I need fasttrack and I had to go back (downgrade) to the 6.40.5 only in the rborder ,since I have 300 Mb fiber and without the fastrack so, I got it just 200
I guess they'll fix that soon, until then we'll have to use the 6.40.5 to fastracker the connection
FastTrack on both my 750Gr3 and 3011 was not working at upgrade. Upgraded firmware (router boot) to latest and restarted. Still did not work but after yet another restart without any change to ROS or firmware everything started working again. Did you try to upgrade firmware after you went to 6.41 and also restart a third time?

No, i dont reset the mikrotik once it has been upgraded,if is this u question . but i delete fastrack from filter rules and rebbor the rb , went create a nuew rule to activate fasttrtack, not work although he told me the packages and the bytes... so I went back to 6.40.5.
But if you confirm that if you reset and configure to hand the configuration, the fastrack work ,I can test it

someone has tried it and it has worked ? it's going well all for you ?
-------------------------------------------------------------------------------
No , no resetee el mikrotik una vez upgradeado , pero si que elimine fastrack de filter rules y reinicie . Luego volvi ha crear la regla de fasttrtack pero seria sin funcionar aunque me augmentaba los paquetes y bytes ...asi que volvi a la 6.40.5.
Pero si me confirmas que si se resetea y se configura a mano desde cero toda la configuracion luego el fastrack funciona, puedo provar

alguien lo ha provado y le ha funcionado , te va todo bien compi ?

___________________________________________________________________________
No I did not reset. After upgrade to 6.41 I upgraded routerboot to latest firmware (also 6.41). Both upgrades includes a reboot. After about a day I noticed that FastTrack did not work on both my 750 and 3011. Did a simple reboot and everything started working again. Nothing more that that solved my issue.
Ok ty i dotn undestand to start ,sorry my english , tomorrow to morning i will upgrade try again and i will try as you said, ty for explanation ,

____________________________________________________

Ok gracias, no entendí al principio , lo siento por mi ingles , mañana por la mañana upgradeare de nuevo u provare como mehas dicho, gracias por la explicacion

Good luck. Just remember to upgrade routerboot firmware too after ROS upgrade (system > Router board). After you press upgrade you restart. After this I had to restart again to get FastTrack working.

moep · Tue Jan 02, 2018 2:22 pm

Hello,

I run multiple IPSec Tunnels from two central sites to remote sites. Inside of the IPSec-tunnel is a IPIP-tunnel to do OSPF via multiple paths.
With v6.41 I tried to switch over the peers to a new IKEv2 enabled peer.

On the main site, I copied the 0.0.0.0/0 peer and changed the exchange mode to IKEv2 and left the rest as it was.
On the remote sites, I switched the existing peer to IKEv2.

All tunnels came up and seemed to be running, but after expiry of the SA (after ~30 Minutes, as configured), the IPIP tunnel experienced a disconnect, which was never there with IKEv1.
This disonnect lasts about 10 seconds. After that, the IPIP-tunnel came back online and OSPF found a neighbor. All this repeats every 30 Minutes for every remote site.
When I change back the exchange-mode to IKEv1, everything works like a charm. No disconnects after 30 Minutes whatsoever.

Is this a (known) bug or do I have to change something at peer or policy level for IKEv2?

sindy · Tue Jan 02, 2018 4:41 pm

RFC 7296 leaves no space for the behaviour you describe:

SAs should be rekeyed proactively, i.e., the new SA should be established before the old one expires and becomes unusable. Enough time should elapse between the time the new SA is established and the old one becomes unusable so that traffic can be switched over to the new SA.

So to me such behaviour is a clear bug and you should report it to support@mikrotik.com. Maybe, to help narrow the search, before sending the report you should watch the SA list between the 28th and 30th minute to see whether the new SA has already been negotiated - normally (i.e. when IKEv1 is used), a new (pair of) SA is generated 5 minutes before the old one's expiration.

BlackVS · Tue Jan 02, 2018 6:48 pm

Found a first anomaly:
Neighbor discovery does not work with the generated 'discover', 'mac-winbox' or 'mactel' interface lists. Other lists seem to work.
After list deletion and recreation by hand, it works.

The same. After disabling-enabling all "discover" list items started to work...

mducharme · Tue Jan 02, 2018 11:03 pm

Found a first anomaly:
Neighbor discovery does not work with the generated 'discover', 'mac-winbox' or 'mactel' interface lists. Other lists seem to work.
After list deletion and recreation by hand, it works.
The same. After disabling-enabling all "discover" list items started to work...

A second reboot after the upgrade also fixes this.

estdata · Tue Jan 02, 2018 11:37 pm

What is problems . I upgrading my routerboard RB2011UAS wireless model. version 6.7 -> 6.41

Please , tell me , What is problems ?`

<img src="https://www.upload.ee/image/7838585/routerboard.png" border="0" alt="routerboard.png" />
https://www.upload.ee/image/7838585/routerboard.png

kmok1 · Tue Jan 02, 2018 11:55 pm

Hello,

I am unsure this has been posted. V6.41 on MIPS-BE devices so far.

1) Reboot upgraded device.
2) Second line in log states ""bridge1" mac address changed to XX" where XX seens to be a randomized MAC address.
3) In / interface bridge print, it shows the bridge's mac address as the first active mac address in the group of ports.

Is this a bug?

Also, in the older devices like RB Groove 5Hn, / system routerboard print shows blank for "upgrade-firmware" while hEX POE shows 6.41.

sindy · Wed Jan 03, 2018 12:05 am

All tunnels came up and seemed to be running, but after expiry of the SA (after ~30 Minutes, as configured), the IPIP tunnel experienced a disconnect, which was never there with IKEv1.
This disonnect lasts about 10 seconds. After that, the IPIP-tunnel came back online and OSPF found a neighbor. All this repeats every 30 Minutes for every remote site.
...
Is this a (known) bug or do I have to change something at peer or policy level for IKEv2?

I've just tested a similar, not identical, setup where an IKEv2 established SA has been replaced by a new one while a single RTP flow was running through it. Instead of your IP-IP tunnel, I am using a "lan-to-lan" (subnet-subnet) IPsec policy. I could see the old and new SA to exist in parallel for a short period of time, yet the RTP flow was completely missing at the output of the IPsec tunnel between sequence numbers 53955 and 54045, i.e. for 90 20-ms packets which is 1800 ms. Bad enough alone, but if the IP-IP tunnel needs some time to re-establish after a failure, it could explain your 10 seconds outage.

Reporting that to support myself.

ziegenberg · Wed Jan 03, 2018 12:11 am

Hello estdata!

What is problems . I upgrading my routerboard RB2011UAS wireless model. version 6.7 -> 6.41

Please , tell me , What is problems ?`

The first message says, that you should reboot your routerboard, so the firmware update can be completed. You should reboot and then we can see, if the other messages are still there.

greetings, Daniel

estdata · Wed Jan 03, 2018 12:28 am

Hello estdata!

What is problems . I upgrading my routerboard RB2011UAS wireless model. version 6.7 -> 6.41

Please , tell me , What is problems ?`

The first message says, that you should reboot your routerboard, so the firmware update can be completed. You should reboot and then we can see, if the other messages are still there.

greetings, Daniel

Yes, I've done the upgrade and restart have done several times in the

xrobau · Wed Jan 03, 2018 4:24 am

I've noticed two things, but one of them may be actually hardware related.

The first is that ONE of my interfaces is refusing to link at 1gb. Even though it's set to advertise everything, it's not advertising 1gb:

In my efforts to see what the problem is, 'Cable Test' now no longer works. It just says 'Cable OK', and that's it.

Hardware is a RouterBOARD 962UiGS-5HacT2HnT, with upgraded Routerboard Firmware

zervan · Wed Jan 03, 2018 9:16 am

What is problems . I upgrading my routerboard RB2011UAS wireless model. version 6.7 -> 6.41

Please , tell me , What is problems ?

Set frequency to 600 MHz, uncheck "Protected Routerboot", reboot.

Chupaka · Wed Jan 03, 2018 11:35 am

Re: wireless - log "signal-strength" when successfully connected to AP;

Clients do appear to log the signal strength when they connect to an AP
-however-
NV2 APs do NOT log the the signal strength when a NV2 client connects

It would be nice if NV2 APs could also log the signal strength of connecting NV2 clients

The same thing with CAPsMAN - please add signal strength to its messages also

Nuubo · Wed Jan 03, 2018 12:44 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?

emils · Wed Jan 03, 2018 1:23 pm

Hello,

I run multiple IPSec Tunnels from two central sites to remote sites. Inside of the IPSec-tunnel is a IPIP-tunnel to do OSPF via multiple paths.
With v6.41 I tried to switch over the peers to a new IKEv2 enabled peer.

On the main site, I copied the 0.0.0.0/0 peer and changed the exchange mode to IKEv2 and left the rest as it was.
On the remote sites, I switched the existing peer to IKEv2.

All tunnels came up and seemed to be running, but after expiry of the SA (after ~30 Minutes, as configured), the IPIP tunnel experienced a disconnect, which was never there with IKEv1.
This disonnect lasts about 10 seconds. After that, the IPIP-tunnel came back online and OSPF found a neighbor. All this repeats every 30 Minutes for every remote site.
When I change back the exchange-mode to IKEv1, everything works like a charm. No disconnects after 30 Minutes whatsoever.

Is this a (known) bug or do I have to change something at peer or policy level for IKEv2?

I am unable to reproduce such issue. Could you please send supout.rif files from both main and remote sites to support@mikrotik.com?

sindy · Wed Jan 03, 2018 2:39 pm

Emils,

just so that several support people don't have to deal with same or similar issue, please check Ticket#2018010322000212.

Pavel

Nuubo · Wed Jan 03, 2018 4:23 pm

After several tests I found the issue:

VPN fails if VPN network is configured in the same subnet as LAN bridge. I could add VPN profile to bridge but it didn´t work so finally I decided to delete bridge and I did the same configuration I had before bridge (LAN port independent and same subnet as VPN). VPN is working again.

I consider this is a bug, I checked VPN profile configuration and I didn´t find anything that can avoid the VPN function when you connect to the same subnet as internal bridge for several ports.

By the way, why not keeping switch masterport and slave interfaces option as previous RouterOS releases?

Wed Jan 03, 2018 4:34 pm

It is a known problem that proxy-arp on bridge do not work after upgrade, You have to set it manually again after upgrade. This problem should be already solved in v6.42rc

Nuubo · Wed Jan 03, 2018 5:22 pm

Thanks for your answer.
I tried to reconfigure proxy-arp also but it didn´t work even after reboot. I will wait for 6.42 (for the remaining Mikrotik we have)

105547111 · Wed Jan 03, 2018 8:08 pm

It is a known problem that proxy-arp on bridge do not work after upgrade, You have to set it manually again after upgrade. This problem should be already solved in v6.42rc

Shoudn't this also be included in an upcoming 6.41.1 also?

Chupaka · Wed Jan 03, 2018 10:31 pm

Shoudn't this also be included in an upcoming 6.41.1 also?

It will be, of course

105547111 · Wed Jan 03, 2018 11:45 pm

I just found in my only 751G doesn't contain a new bootloader version its blank....

msatter · Thu Jan 04, 2018 12:09 am

I just found in my only 751G doesn't contain a new bootloader version its blank....

viewtopic.php?f=21&t=128915&start=50#p633665

Will be fixed in 6.41.1
*) routerboot - fixed missing upgrade firmware for "ar7240" devices;

RLithgo · Thu Jan 04, 2018 1:56 am

I am currently running 6.38 and don't have any issues. I am a little concerned over the 6.41 upgrade.
Has anyone else gone from 6.38 (or earlier) to 6.41 and if so, was it smooth sailing?

5nik · Thu Jan 04, 2018 1:59 am

Hello, after upgrade 6.40.5 -> 6.41 on hAP ac IPIP6 tunel interfaces not running. Reset configuration doesn't help.

bbs2web · Thu Jan 04, 2018 6:34 am

You're right, the actual issue appears to be that RouterOS does not appear to process or honor ICMP 'fragmentation needed' messages. The following capture is on a MPLS speaking 6.41 RouterOS device where MPLS switched packets are not captured and subsequently only shows incoming packets which use Penultimate Hop Popping (PHP):

The above is to validate that ICMP messages arrive correctly at 41.79.22.34. Herewith a packet capture on the MPLS ingress point, showing 41.79.22.34 continuing to send packets with a payload of 1312 bytes after it receives ICMP 'fragmentation needed' messages which indicate that the maximum MTU is 1348 bytes (-40 bytes = 1308 payload):

Traffic capture on pe03 shows TCP SYN packet arriving with TCP options where MSS is set as 1312 bytes. Replies aren't visible on this router as they are MPLS switched to br01. Reviewing a packet capture on interface facing 'customer' on br01 or upstream interface on ccr1 shows pe03 sending back an ACK with MSS incorrectly set as 1460 bytes.
That's normal and is in accordance with the existing standards. MSS is NOT negotiated, but rather each side of the connection just informs the other side of the connection (by using the MSS TCP option) about the maximum segment size it is able to receive. For each TCP connection different MSS values may be used in each direction of data flow. There's no requirement for the MSS value set by the initiator to be "reflected" by the responder; thus MSS clamping, if required, should be applied in each direction of data flow independently.

jardap · Thu Jan 04, 2018 11:07 am

Hello, I've got another issue. After upgrade from v6.40.5 to v6.41 my DUDE server (running on RB1100Dx4) reporting cpu,disk and memory services down on all MK devices. Pls anybody can help me?
Thnx
Jarda

Flag,Time,Message
,Jan/01 22:15:06,syslog: Service disk on CHO51VKAP2 - 172.27.220.251 is now down (down)
,Jan/01 22:15:06,Service disk on CHO51VKAP2 - 172.27.220.251 is now down (down)
,Jan/01 22:15:07,syslog: Service memory on CHO51VKAP2 - 172.27.220.251 is now down (down)
,Jan/01 22:15:07,Service memory on CHO51VKAP2 - 172.27.220.251 is now down (down)
,Jan/01 22:15:23,syslog: Service cpu on CHO51VKAP2 - 172.27.220.251 is now down (down)
,Jan/01 22:15:23,Service cpu on CHO51VKAP2 - 172.27.220.251 is now down (down)
,Jan/01 22:16:37,syslog: Service disk on 172.27.220.253 is now up ()
,Jan/01 22:16:37,Service disk on 172.27.220.253 is now up ()
,Jan/01 22:16:37,syslog: Service disk on MK router - 172.27.220.4 is now down (down)
,Jan/01 22:16:37,Service disk on MK router - 172.27.220.4 is now down (down)
,Jan/01 22:16:40,syslog: Service disk on 172.27.220.254 is now up ()
,Jan/01 22:16:40,Service disk on 172.27.220.254 is now up ()
,Jan/01 22:16:42,syslog: Service memory on CHO51VKAP1 - 172.27.220.250 is now down (down)
,Jan/01 22:16:42,Service memory on CHO51VKAP1 - 172.27.220.250 is now down (down)
,Jan/01 22:16:50,syslog: Service memory on 172.27.220.253 is now up ()
,Jan/01 22:16:50,Service memory on 172.27.220.253 is now up ()
,Jan/01 22:19:07,syslog: Service cpu on 172.27.220.254 is now down (down)
,Jan/01 22:19:07,Service cpu on 172.27.220.254 is now down (down)
,Jan/01 22:19:10,syslog: Service disk on 172.27.220.254 is now down (down)
,Jan/01 22:19:10,Service disk on 172.27.220.254 is now down (down)
,Jan/01 22:19:50,syslog: Service memory on 172.27.220.253 is now down (down)
,Jan/01 22:19:50,Service memory on 172.27.220.253 is now down (down)

BlackVS · Thu Jan 04, 2018 11:15 am

Probably known problem with discovery - do any from listed below:

Found a first anomaly:
Neighbor discovery does not work with the generated 'discover', 'mac-winbox' or 'mactel' interface lists. Other lists seem to work.
After list deletion and recreation by hand, it works.
The same. After disabling-enabling all "discover" list items started to work...
A second reboot after the upgrade also fixes this.

Or check firewall rules - may be migrating wasn't smooth and packets blocked by default rules...

Thu Jan 04, 2018 11:31 am

In order to keep this 6.41 version topic as clean as possible, please before posting a question or problem report, check 6.42rc version changelog. In most cases problems are already resolved:

Note that rc version topic first post is a changelog of first rc version released. Later updates are posted further into topic:
viewtopic.php?f=21&t=129034
viewtopic.php?f=21&t=129034#p634998

pe1chl · Thu Jan 04, 2018 11:48 am

You're right, the actual issue appears to be that RouterOS does not appear to process or honor ICMP 'fragmentation needed' messages.

That would be correct, it is not the task of the router to act upon these messages, it is the responsibility of the end system to do so. It should only process those messages when they refer to traffic originated from the router itself.
Of course the router must forward the ICMP messages to the correct end system, this is often a problem with tunneling protocols and with too many "Gibson paranoia" firewalls inbetween.

raymondr15 · Thu Jan 04, 2018 2:07 pm

Hi,

I noticed after upgrading to v6.41 that ether3 & ether5 were showing the exact same TX throughput all the time, I checked bridge settings and played around to see if there was a configuration issue from the upgrade, a saw that ether3's "auto isolate" was disabled, I reenabled it and as soon as I did, I lost all access from any port on the bridge interface, only discovery was working, couldn't even login via winbox mac. After rebooting the router, everything came back up fine??

Whats this about? Bug?

rognick · Thu Jan 04, 2018 11:48 pm

Hello,
I am on the way to acquiring the RB750Gr3 + wap ac and I am confused if the RB750Gr3 can be configured for IPTV.

Can someone help me to clarify if RB750Gr3 with v6.41 can be configured IPTV and VLAN tagging / untagging?
Yes, it certainly can. Here's an example configuration for an ISP which uses VLAN 500 for Internet and VLAN 600 for IPTV.
https://wiki.mikrotik.com/wiki/Mikrotik ... ee/soonwai

Hey soonwai! So thanks to you, I was able to config my RB750Gr3

I checked and vlan-filtering = yes
at momet everything is ok.
I do not know if it was supposed to work on both bridge to do vlan-filtering

There is a difference between the above example and the new tagging / untagging settings
https://wiki.mikrotik.com/wiki/Manual:I ... s_Ports.29

Thanks!

jardap · Fri Jan 05, 2018 12:15 am

Unfortunately this problem is not mentioned at 6.42rc topic and 6.42rc5 did not resolve my problem. Dude is still getting information about cpu,memory and disk overloading.

In order to keep this 6.41 version topic as clean as possible, please before posting a question or problem report, check 6.42rc version changelog. In most cases problems are already resolved:

Fri Jan 05, 2018 12:41 am

jardap - have you reported this to support@mikrotik.com with problem description and supout files?

pcjc · Fri Jan 05, 2018 11:44 am

Just in the process of downgrading back to 6.40.5....

On the RB2011 it doesn't appear possible to create a working bridge (hw offload) config as efficient as the previous software revision, where we could use switch hardware offload on both the 1000M ports and 100M ports - then bridge those switches together with the SFP port.
The additional complexity is that I had a vlan trunk port on the 1000M switch (Business + Guest vlan wifi) - as well as the other untagged (business) ports. The initial 6.41 configuration I had appeared to be working, but with NO hardware offload, and things traversing the 1000M switch (e.g. ping) appeared to get 3x extra duplicate packets received.

kor3k · Fri Jan 05, 2018 1:04 pm

hello,

have a problem with this release.

we have two CRS-326 connected together through 4 ether ports, both have same configuration:

4 connecting ether ports are bound into a bonding
that bonding is part of a bridge

before upgrade (6.40.5), everything worked fine.
but after upgrade to 6.41, both CRSs start throw "bridge port received packet with own address as source address" error and both freeze up (because of packet storm).

what is wrong? how can i fix it?

kor3k

JimmyNyholm · Fri Jan 05, 2018 3:25 pm

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

Reading Wiki and reading Questions here on the Forum. As there is no version setting for IGMP snooping I assume it's on IGMPv2? or is it IGMPv3? It can't be IGMPv1 still?

As you se the Confusion is obvious and there is a ton of other stuff to think about when talking multicast that is not obvious at first.

Fri Jan 05, 2018 6:01 pm

..."bridge port received packet with own address as source address"

You have two routes/interfaces for packets received by this bridge.
I have noticed something similar configuring CAPSMAN with CAP's device WiFi interface assigned staticaly to "locally-forwarded" CAP's bridge in CAP device and virtually created in CAPSMAN and included in CAPSMAN's bridge.

kor3k · Fri Jan 05, 2018 6:52 pm

..."bridge port received packet with own address as source address"
You have two routes/interfaces for packets received by this bridge.
I have noticed something similar configuring CAPSMAN with CAP's device WiFi interface assigned staticaly to "locally-forwarded" CAP's bridge in CAP device and virtually created in CAPSMAN and included in CAPSMAN's bridge.

thanks for pointing this out.

actually, we are using capsman in our network.
and i think in the same setup as you describe.

each CAP's wlan is "locally-forwarded" into CAP's bridge, but each wlan also has 2 VirtualAPs, which are "capsman-forwarded" into CAPSMAN's bridge.
and these two CRS-326 with bonding are in the middle of the network (backbone switches), but they are not caps managers.
the whole network is bridged.

how did you solve the issue? do you know why this is happening? seems like a bug to me.

bbs2web · Fri Jan 05, 2018 10:28 pm

Seeing that I am connecting to this router, it would subsequently confirm that RouterOS does not honour ICMP fragmentation needed messages.

ie: I connect via Winbox or SSH (port 2200), initial packets go back and forth until a payload exceeds the remote VPN MTU. ICMP 'fragmentation needed' message is received by RouterOS, which contains maximum MTU, so RouterOS should fragment at that boundary, instead of continuing with original MSS received during TCP establishment...

You're right, the actual issue appears to be that RouterOS does not appear to process or honor ICMP 'fragmentation needed' messages.
That would be correct, it is not the task of the router to act upon these messages, it is the responsibility of the end system to do so. It should only process those messages when they refer to traffic originated from the router itself.
Of course the router must forward the ICMP messages to the correct end system, this is often a problem with tunneling protocols and with too many "Gibson paranoia" firewalls inbetween.

YeOldeSwitcheroo · Sat Jan 06, 2018 12:53 am

Could you please disable HW offloading when bridge filter rules are added?

The problem is that they're incompatible with each other (at least it seems that way). I just bought a hEX, set it to bridge mode (which enables HW offloading for all those ports, because the hEX board supports it) and then added a filter that drops UDP packets to port 67 & 68 (DHCP).

The counters for the filter increase, but they have zero effect. All those packets are still forwarded, regardless of chain. Disabling HW offloading and leaving only rules for the forward chain has the desired effect.

skuykend · Sat Jan 06, 2018 2:07 am

Just in the process of downgrading back to 6.40.5....

On the RB2011 it doesn't appear possible to create a working bridge (hw offload) config as efficient as the previous software revision, where we could use switch hardware offload on both the 1000M ports and 100M ports - then bridge those switches together with the SFP port.
The additional complexity is that I had a vlan trunk port on the 1000M switch (Business + Guest vlan wifi) - as well as the other untagged (business) ports. The initial 6.41 configuration I had appeared to be working, but with NO hardware offload, and things traversing the 1000M switch (e.g. ping) appeared to get 3x extra duplicate packets received.

I'm using all ports on my RB2011 as a switch with vlans (tagged and untagged) and am getting HW offloading and not seeing any duplicate packets. I posted my config in this thread: viewtopic.php?f=2&t=129057&p=634278#p634278

linux25 · Sat Jan 06, 2018 4:13 am

This is for mikrotik, you disappointed me with your product and updates, i have problems with flapping eth, your updates worse my problem, is not for my cable connection, your product sucks, i don't buy ever again your product.
I tell you friends, don't go in roads with mikrotik. Good luck.

Sun Jan 07, 2018 9:58 pm

....how did you solve the issue? do you know why this is happening? seems like a bug to me.

If you configure "Local forwarding" in CAP then you HAVE TO remove WiFi interfaces from bridge you are dynamically assigning them to.
As you see on pictures all WLAN interfaces are "D" = dynamically added.
You also have to not assign them to any bridge on CAPSMAN as the traffic is already sent to local bridge so assigning WIFI interface in CAPSMAN sends the second packet to bridge on CAPSMAN and then you have two same packets in the LAN.

BR_LFD.PNG

kor3k · Mon Jan 08, 2018 12:00 am

BartoszP, thank you. but i have found out today that capsman is not the cause of the problem.
we have all wlans and virtualAPs as dynamic bridge ports on capsman and all caps.

i have two CRS-326 connected through ether2-3.
on both i reset config and disable all interfaces except for ether1-3, then create a bonding on ether2-3 and a bridge.

bonding1
- ether2
- ether3

bridge1
- bonding1
- ether1

this starts throwing "bridge port received packet with own address as source address" error on the one with the root bridge.
when i remove the bonding from the bridge on either side, it stops.

we are using bondings on different models too (RB2011,CRS125,CCR1036) and they are working fine, only CRS-326 have these symptoms.

pcjc · Mon Jan 08, 2018 2:02 am

I'm using all ports on my RB2011 as a switch with vlans (tagged and untagged) and am getting HW offloading and not seeing any duplicate packets. I posted my config in this thread: viewtopic.php?f=2&t=129057&p=634278#p634278
[/quote]

My 6.41 configuration (before I downgraded) looked fairly similar to yours, and was (almost) what the upgrade gave me when migrating 6.40.5 -> 6.41 (had to make a few tweaks for things which weren't well converted). If I get a chance to try again, I'll see if I can reproduce the problem on 6.41 again.
One thing I tried (but could not do), was to create a bridge for each switch chip (with auto hardware off-load), and then create a bridge to join those hardware groups and the SFP interface. This didn't work, since the Mikrotik software won't allow adding the "child" bridges (e.g. HW offload to the switch chip CPU ports) into the "parent" bridge). I'm not sure I prefer the new method of configuring switches / bridges. As a HW guy, I'm quite happy with being aware of the underlying hardware configuration with the switch chips etc.. (although the "master port" terminology not that helpful - since really it is the switch cpu port interface being bridged by the software).

F1le · Mon Jan 08, 2018 3:03 am

First thing which happened after upgrade to 6.41 from 6.40.5 was all the time SFP connection drop. I have to go to the router unplug it and plug it again. Running on :

RB962UIGS 5HACT2HNT HAP AC

During 4h after upgrade it happened twice till now. On 6.40.5 it was running rock solid on SFP.

frank333 · Mon Jan 08, 2018 8:54 pm

Simple queues do not work, or the way in which they are written has changed.

Chupaka · Tue Jan 09, 2018 10:43 am

Simple queues do not work, or the way in which they are written has changed.

Changed compared to what?

frank333 · Tue Jan 09, 2018 12:14 pm

Hi, Chupaka, compared to the previous version 6.40.5.
I also have problems with PPPoE Client, every time the ISP changes ip I have to use the backup file, because the only reboot leaves the connection active but not working.
All I have to do is to downgrade to 6.40.5.

scampbell · Tue Jan 09, 2018 9:19 pm

I have upgraded a CRS125, wAP AC and RB751U all to 6.41 on the same network.

All devices upgraded OK and are working but only two devices showed the new 6.41 Routerboard F/W. The RB751U interestingly shows a blank where you would expect to see the new F/W (6.41). Is this a limtitation of the older hardware or a bug I wonder ?

(Tried rebooting the RB751U and no change either under Winbox or CLI).

RoS6.41-rb751U.PNG

mszru · Tue Jan 09, 2018 10:05 pm

The RB751U interestingly shows a blank where you would expect to see the new F/W (6.41). Is this a limtitation of the older hardware or a bug I wonder ?

It was reported earlier in this topic and already fixed in 6.42rc.

tkgit · Wed Jan 10, 2018 7:01 am

Limited troughput between RB951G & RB751u2HnD,
I use cat5e cable and as seen in the pict it's 100Mbps FD link,

I tried to connect my laptop to RB951(connected to ONT-UFB) then did BW speed test and the result is same
http://pic.nperf.com/r/224638898-QnI4M7V4.png
eventhough when I tried direct connect from ONT-UFB to my laptop the result is
http://pic.nperf.com/r/224477017-k6qrDvc7.png

any comment? what should I do/

kometchtech · Wed Jan 10, 2018 7:28 am

Limited troughput between RB951G & RB751u2HnD,
I use cat5e cable and as seen in the pict it's 100Mbps FD link,

I tried to connect my laptop to RB951(connected to ONT-UFB) then did BW speed test and the result is same
http://pic.nperf.com/r/224638898-QnI4M7V4.png
eventhough when I tried direct connect from ONT-UFB to my laptop the result is
http://pic.nperf.com/r/224477017-k6qrDvc7.png

any comment? what should I do/

It seems that the CPU usage rate of RB751u2HnD is 100%, but are you using functions such as FW?
If that is the case, I think that it is better to use the profile etc. to see which function is used.

tkgit · Wed Jan 10, 2018 7:39 am

Limited troughput between RB951G & RB751u2HnD,
I use cat5e cable and as seen in the pict it's 100Mbps FD link,

I tried to connect my laptop to RB951(connected to ONT-UFB) then did BW speed test and the result is same
http://pic.nperf.com/r/224638898-QnI4M7V4.png
eventhough when I tried direct connect from ONT-UFB to my laptop the result is
http://pic.nperf.com/r/224477017-k6qrDvc7.png

any comment? what should I do/
It seems that the CPU usage rate of RB751u2HnD is 100%, but are you using functions such as FW?
If that is the case, I think that it is better to use the profile etc. to see which function is used.

tried again

maxpower · Wed Jan 10, 2018 12:32 pm

Previously there were 2 possible ways to implement VLAN functionality:
1) Via the switch chip VLAN functionality which was 100% hardware (switch > vlan)
2) Via the CPU functionality which was 100% software (create multiple bridges for each VLAN (untagged ports), and one bridge for tagged ports)

Solution 1 was not very useful if device have 2 separate switch chips.

What changed now with hardware offload?

Steveocee · Wed Jan 10, 2018 1:35 pm

Just want to say good job on the HW offload functions. I managed to get this onto my "old" RB750 which sits on my desk at work and the offload makes a huge difference from 1 interface to another so hopefully this amazing performance increase scales up to far larger switches. CPU usage was also down from 98% to 2-3% whilst running tests.

hwoffloadtest by Steve Carter, on Flickr

Wed Jan 10, 2018 2:05 pm

Just want to say good job on the HW offload functions. I managed to get this onto my "old" RB750 which sits on my desk at work and the offload makes a huge difference from 1 interface to another so hopefully this amazing performance increase scales up to far larger switches. CPU usage was also down from 98% to 2-3% whilst running tests.

Yes, sometimes good features simply needs to be forced upon you,
This functionality was there for 7+ years, simply instead of bridge you needed to use "master-port" option in interface settings.

Wed Jan 10, 2018 4:23 pm

Even though I believe this is good for most of the users, I do not understand well why I should loose the straightforward way of organising switches and bridges as I want. But I am also preparing to give a try...

pe1chl · Wed Jan 10, 2018 4:37 pm

Even though I believe this is good for most of the users, I do not understand well why I should loose the straightforward way of organising switches and bridges as I want.

The reason it was done (I think) is to allow standards like RSTP and IGMP snooping to work in both bridge and switch.
And it should also make things a little bit clearer.
However, I agree that everything that was previously done (and allowed) in switch configuration should be migrated to bridge in such a way that the original switch menu can be completely deleted.
As it is now, it is confusing. I have VLAN configuration on my switches and it has to be migrated to bridge without losing hardware acceleration. As of now this does not work, so switch config remains necessary.

Steveocee · Wed Jan 10, 2018 7:04 pm

Just want to say good job on the HW offload functions. I managed to get this onto my "old" RB750 which sits on my desk at work and the offload makes a huge difference from 1 interface to another so hopefully this amazing performance increase scales up to far larger switches. CPU usage was also down from 98% to 2-3% whilst running tests.
Yes, sometimes good features simply needs to be forced upon you,
This functionality was there for 7+ years, simply instead of bridge you needed to use "master-port" option in interface settings.

It is a clean, easy to use implementation of something that was although working, clunky. The option to "add all" to bridge is also brilliant, a real step forwards in user friendliness.

thobias · Thu Jan 11, 2018 1:04 pm

*) ipsec - allow to specify "remote-peer" address as DNS name;

How can I use this to set up a site to site vpn tunnel with dynamic ip in one end?
I can't seem to set DNS-name as SA-address in ipsec->policy.

sindy · Thu Jan 11, 2018 1:36 pm

You cannot set a dns name as sa-dst-address in a manually configured IPsec policy. The feature can be used with mode-config peers, i.e. the "vpn clients" which generate policy dynamically based on the information received from the peer. It is possible to associate an address pool of more than a single address to a user name, so when this user establishes an IPsec connection, it gets the whole subnet via mode-config, and it generates the policy dynamically, based on this subnet. In this case, the generated policy sets the current IP address of the peer as sa-dst-address.

Dalo · Thu Jan 11, 2018 11:32 pm

I have updated the following boards to 6.41 RB750GR3, RB960PGS, RB3011 and CRS112-8G. All of them were successfully provisioned to this new version with no issues. Specially for the CRS112 I noticed a huge improvement in the throughput speed as a simple switch (no IP.Firewall), with 6.40.5 I usually got +-400Mbps, once the update to 6.41 now the clients can reach +-850Mbps as a bridge, hw offload, IGMP Snooping and Fast Forward. Certainly for my application, this update is working brilliant.

AlexanderMartynenko · Fri Jan 12, 2018 9:41 am

Hi Guys,
After update to 6.41 Router OS I have a problem with EoIP tunnel. On PH2 State it shows - no phase 2 - status.
Is any ideas how to fix it?

MartinT · Fri Jan 12, 2018 2:16 pm

*) ospf - fixed OSPF v2 and v3 neighbor election;

Could anybody from Mikrotik explain more this fix ? From which version it is broken and which network-type are afected ? Thanks.

akliouev · Fri Jan 12, 2018 4:28 pm

It appears that running both a L2TP and an OVPN server is impossible on a HAP ac
When enabling OVPN established L2TP sessions are getting kicked out and new sessions are failing to establish. It looks like enabling OVPN just shuts down or filters out L2TP trafic

JimmyNyholm · Fri Jan 12, 2018 6:24 pm

Can someone explain why eoip interface has a l2mtu setting of 65535 in this version and not changeble.

If I do bridging it is this value that is the max l2 recieved right? and it sould after adding headers fragment if outgoing interface after routelookup has a smaller ip mtu?

marceloru · Mon Jan 15, 2018 5:48 am

I was with version 6.39.3 in a ccr 1036 working as PPPOE server, all correct, I update to version 6.41 and I have problems with access to some ftp sites, among them ftp://200.47.24.13/, I return to the version 6.39.3 again and the problem disappears.-

version 6.40.5 also have problems MTU and packets bigger than 1400 bytes lost a lot, 6.39.9 work ok

wuyizhao · Mon Jan 15, 2018 9:32 am

HAP AC Lite upgrade 6.41 cannot be started.
Usr lights are always bright.
How to fix it?

kamillo · Mon Jan 15, 2018 10:58 am

You can try Netinstall to reinstall RouterOS:

https://wiki.mikrotik.com/wiki/Manual:Netinstall

mkx · Tue Jan 16, 2018 11:03 pm

Previously there were 2 possible ways to implement VLAN functionality:
1) Via the switch chip VLAN functionality which was 100% hardware (switch > vlan)
2) Via the CPU functionality which was 100% software (create multiple bridges for each VLAN (untagged ports), and one bridge for tagged ports)

Solution 1 was not very useful if device have 2 separate switch chips?

Then there's the third possibility, which was a hybrid one: use switch chip VLAN functionality for ethernet ports and CPU functionality for adding other interfaces (e.g. WLAN with VLAN tags such as virtual AP) or other switch chips. And you don't have to create multiple bridges, one is enough.

My observation is that CPU bridge is VLAN-transparent. If you want to do something specific to a particular VLAN, you have to create a VLAN virtual interface and then do whatever needs to be done using that particular VLAN virtual interface. E.g. if you want to route between two different VLANs, you create two VLAN virtual devices, one for each VLAN. They both belong to "the" bridge. Then you bind different IP addresses to each VLAN virtual device and then you can do the routing between the two interfaces.
However, if you want to switch traffic between e.g. WLAN with VLAN id 42 and ethernet with VLAN id 42, you don't need to do anything apart from having WLAN interface and "switch CPU" port belong to same (CPU) bridge.

I don't have any RB with more than one switch chip, but I guess this is the optimum way of spanning all of the ethernet ports: let switch chip deal with traffic between ports belonging to the same switch chip and have single bridge, spanning all "switch cpu" ports. From switch chip point of view, this CPU bridge appears to be normal ethernet port connecting it to some virtual switch (implemented in SW). One just needs to be careful about VLAN setup of these ports. Bridging without (many) rules should not bog down CPU too much, at least that's what MikroTik wants to show with test results - I'm just not sure how the "brigding - fast path" results compare to switch chip performance on the same hardware.

It would be good to know if anything changed in 6.41 with regard to switch/bridge functionality.

pe1chl · Wed Jan 17, 2018 12:33 pm

My observation is that CPU bridge is VLAN-transparent. If you want to do something specific to a particular VLAN, you have to create a VLAN virtual interface and then do whatever needs to be done using that particular VLAN virtual interface. E.g. if you want to route between two different VLANs, you create two VLAN virtual devices, one for each VLAN. They both belong to "the" bridge. Then you bind different IP addresses to each VLAN virtual device and then you can do the routing between the two interfaces.
However, if you want to switch traffic between e.g. WLAN with VLAN id 42 and ethernet with VLAN id 42, you don't need to do anything apart from having WLAN interface and "switch CPU" port belong to same (CPU) bridge.

The disadvantage of that method is that it allows VLAN communication of any VLAN id between those ports. You cannot easily forward one VLAN and disallow another.
When some security is desired, it is better to explicitly bridge the wanted VLAN subinterfaces.

Chupaka · Wed Jan 17, 2018 12:59 pm

The disadvantage of that method is that it allows VLAN communication of any VLAN id between those ports. You cannot easily forward one VLAN and disallow another.
When some security is desired, it is better to explicitly bridge the wanted VLAN subinterfaces.

Huh?..

/interface bridge
add name=bridge1 vlan-filtering=yes
add name=bridge2 vlan-filtering=yes

/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge2 interface=ether2

/interface bridge vlan
add bridge=bridge1 tagged=ether1 vlan-ids=10
add bridge=bridge2 tagged=ether2 vlan-ids=10

sindy · Wed Jan 17, 2018 1:40 pm

@Chupaka,
my experience shows that for the last part,

/interface bridge vlan
add bridge=bridge1 tagged=ether1,bridge1 vlan-ids=10
add bridge=bridge2 tagged=ether2,bridge2 vlan-ids=10

is necessary. Without the bridge itself being listed as a tagged member of the VLAN, some things did not work for me, so I looked at the manual page and example #3 was showing this (unlike the other two). I was not the only one to bump into this, but I have no explanation why this is necessary. And if it is necessary only in particular cases, why.

pe1chl · Wed Jan 17, 2018 2:00 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.

Chupaka · Wed Jan 17, 2018 2:05 pm

@sindy, yep, if you need those VLANs locally. It was just a short example of possible way

sindy · Wed Jan 17, 2018 2:18 pm

if you need those VLANs locally

Can you elaborate? It sounds as if the VLAN wouldn't reach the CPU if the bridge itself is not stated among member interfaces, but in such case, if you have a dual-switch machine and you assign ports from both switches to the same bridge, wouldn't you have to do the same even if you don't need to access the VLAN locally, just want it to flow between ports of different switches?

The second point is what the difference in CPU load is whether you list the bridge itself among VLAN members or not. If it is none or negligible if you do list it but don't actually access the VLAN locally, why this setting has been put to configuration at all?

Lansman · Wed Jan 17, 2018 2:47 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.

Chupaka · Wed Jan 17, 2018 4:10 pm

Can you elaborate? It sounds as if the VLAN wouldn't reach the CPU if the bridge itself is not stated among member interfaces, but in such case, if you have a dual-switch machine and you assign ports from both switches to the same bridge, wouldn't you have to do the same even if you don't need to access the VLAN locally, just want it to flow between ports of different switches?

I just wanted to point that if you don't need to send packets to the router itself, you may use something like this for isolating two VLANs with the same VlanID:

/interface bridge
add name=bridge1 vlan-filtering=yes
add name=bridge2 vlan-filtering=yes

/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge2 interface=ether2
add bridge=bridge1 interface=ether3
add bridge=bridge2 interface=ether4

/interface bridge vlan
add bridge=bridge1 tagged=ether1,ether3 vlan-ids=10
add bridge=bridge2 tagged=ether2,ether4 vlan-ids=10

As for adding ports from different switches (where software switching is needed) - I think, the router itself should decide and automatically add bridge to the list (or kind of that), because user don't have to know exact hardware implementation, so he shouldn't guess why something is not working.

P.S. I haven't tested anything above, just my thoughts

mkx · Wed Jan 17, 2018 11:31 pm

The disadvantage of that method is that it allows VLAN communication of any VLAN id between those ports. You cannot easily forward one VLAN and disallow another.
When some security is desired, it is better to explicitly bridge the wanted VLAN subinterfaces.

Switch chip sees all VLANs employed by member ethernet ports and switch administrator has to configure VLANs per port properly. It doesn't matter if some additional VLAN comes from another switch via bridge (=switch cpu port).
In addition to that, traditionaly you had to define which VLANs do pass through switch cpu port and you can restrict some VLANs from "escaping" out of a particular switch chip if so desired.

I'm not sure if this part is different in 6.41 or not, my VLAN-infested RBs are still on 6.40.5.

vipnet · Thu Jan 18, 2018 3:09 am

pppoe client dont open after update.

ISPIE001 · Thu Jan 18, 2018 12:04 pm

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

AKuntsevich · Thu Jan 18, 2018 2:01 pm

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.

Chupaka · Thu Jan 18, 2018 2:39 pm

Huh... Sounds like

*) ppp - fixed "change-mss" functionality when MSS option is missing on forwrded packets;

fredcom · Thu Jan 18, 2018 8:15 pm

Hi guys,

is there a way to change the values for these settings? *) lte - changed default values to "add-default-route=yes", "use-peer-dns=yes" and "default-route-distance=2";
Basically, I want to change the DNS servers, but first I need to disable using peer DNS, if I understand correctly. And Winbox won't let me, saying "couldn't change DHCP Client <lte1> - cannot change dynamic entry (6)"

I'm using RBM11G and Huawei ME909s-120.

Thanks.

sindy · Thu Jan 18, 2018 8:21 pm

Well, it is just the default value of use-peer-dns what has been changed, so just specify use-peer-dns=no when creating the interface and you should be good?

fredcom · Thu Jan 18, 2018 9:05 pm

Well, it is just the default value of use-peer-dns what has been changed, so just specify use-peer-dns=no when creating the interface and you should be good?

The problem is that it seems it's impossible to delete and then create lte interface from Interface list window. But you've actually set me on the correct path - there is a new button on the LTE tab, where you can setup LTE APNs - this is where the Use Peer DNS can be unchecked.

Thanks.

bobr · Fri Jan 19, 2018 10:19 am

Hello to all!
I need help with clarifying some things about new bridge behaviour and switch and switch VLANs and all the around stuff.
First of all - explain to me please, how does bridge interface PVID and bridge ports PVID and switch ports PVID and the VLAN ID of the VLAN interfaces added in interface table( I call them "L3 VLANs" ) correlating with each other and when I should use bridge interface PVID and should I at all?

Then I need help with creating of access ports using switch VLANs and new bridge behaviour, when I want to use the switch functions for VLANs instead of creating them on a bridge and to use no bridge VLAN filtering. What I want? While playing a lab experiments I've decide to create a simple schema: make RB 750 to able to rule a management VLAN and a few over-the-network VLANs.

VLANs:
110 - management. Need to be accessible via ether5 locally
200 - vlan which just need to go through as tagged to...e.g. - ether3
300 - vlan which need to to go through as tagged to...e.g. - ether3 and be accessible via ether4(ether4 as access port for this vlan)

ehter2 - uplink port
ehter5 - local mangement port
192.168.110.211/24 - IP address for this RB 750 in a management network(on a management vlan interface).
Other IPs on interfaces are just dummy.

Pretty simple, hugh? But I can't get further than make able to work the management vlan via uplink port. I can't even get ehter5 local management port working as access port to be able to log into my RB 750 from a laptop connected to it(suppose, laptop has a 192.168.110.220/24 IP without any gateways configured on it's ehternet interface).
Here is my simple config.

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

/interface ethernet
set [ find default-name=ether2 ] name=ether2-uplink

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

/interface bridge port
add bridge=bridge1 interface=ether2-uplink hw=yes pvid=1
add bridge=bridge1 interface=ether3 hw=yes pvid=1
add bridge=bridge1 interface=ether4 hw=yes pvid=1
add bridge=bridge1 interface=ether5 hw=yes pvid=1

/ip neighbor discovery-settings
set discover-interface-list=all

/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

/interface ethernet switch vlan
add ports=ether2-uplink,ether5,switch1-cpu switch=switch1 vlan-id=110

/ip address
add address=192.168.88.1/24 interface=ether1 network=192.168.88.0
add address=192.168.1.88/24 interface=ether4 network=192.168.1.0
add address=192.168.110.211/24 interface=vlan110 network=192.168.110.0

/ip route
add distance=1 gateway=192.168.110.254

/system clock
set time-zone-name=Europe/Kiev

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

dsiecinski · Fri Jan 19, 2018 10:25 am

I just want raport after upgrade issues

Upgraded RB3011 from 6.35 to 6.41

after upgrade my scheduler scripts not working

and when I copy script from scheduler to terminal and paste it ... very interesting thing happened
because if run it in terminal allways at firs time I got error "no such item (4)"

it looks like this:

[dsiecinski@Mikrotik] > /interface pptp-client enable pptp-out1
no such item (4)
[dsiecinski@Mikrotik] > /interface pptp-client enable pptp-out1
[dsiecinski@Mikrotik] >

fun is that commands is not difrerent

but work allways after second trie

bobr · Fri Jan 19, 2018 11:18 am

dsiecinski, I think you need to report it to Mikrotik directly...

vipnet · Fri Jan 19, 2018 3:55 pm

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

Chupaka · Fri Jan 19, 2018 3:57 pm

The problem is already fixed in 6.42rc.

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

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