Community discussions

 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Sep 19, 2017 5:11 pm

I'll just wait for the stable version.
Weak. Be brave!
 
User avatar
juliokato
Member Candidate
Member Candidate
Posts: 229
Joined: Mon Oct 26, 2015 4:27 pm
Location: Brazil

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Sep 19, 2017 5:26 pm

I can't, I have over 400 RB with USB LTE MODEM in production and the RC version has STP bridge bugs. While it is not stable I can wait another year :lol:
I apologize my grammatical errors, my english not so good, I am not a native speaker.
Wiki is maintained in English. I use Google translator. 8)
 
JimmyNyholm
Member Candidate
Member Candidate
Posts: 249
Joined: Mon Apr 25, 2016 2:16 am
Location: Sweden

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Sep 19, 2017 7:11 pm

Just to be on the safe side. Running CRS317-1G-16+ On the 6.41rc30 looking in switch menu there is no ports and no switch is that correct?
The New implementation is doing "switchy stuff" in bridge section but should I make switch settings in switch section and does that work when Ros doesn't find any chip or ports in this menu.

Where does the Dynamic Vlan of 3501 come from?
This bridge1 port is this the routeros entry point? (ie: if I add Ip adtress or vlan interface in interface section?)
bridge1 doesn't need to be in a vlan for that vlan to forward frames to the member ports?.

Why do I ask this silly questions... because I'm experiencing strange behaviour. And the Wiki is utterly outdated on this developing area and there is no other source for this kind of information.
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Sep 19, 2017 8:47 pm

Wiki has been updated. The links are in the thread. I think it's under interface bridge.

You are correct. The switch menu is a thing of the past. It is all done via the new HW offload VLAN aware bridge.

This provides a single consistent way to use RouterOS and it manages leveraging underlying hardware dynamically. This is visible by the H flag in interface bridge port.

Now let's go to school. A VLAN is a layer 2 technology like a switch. Therefore a VLAN interface is not required for a bridge to forward a frame. The switch simply has to know which ports are a member of that VLAN and whether it should traffic tagged or untagged on that port.

A VLAN interface is a way to perform routing for traffic on a VLAN in RouterOS.

A VLAN interface should have it's master interface set to the bridge interface.

The bridges VLAN and port tables are where you manage which ports transmit tagged and untagged frames on which ports. A dynamic entry is sourced from an entry in one table that's not present in another. This could be seen by placing a bridge ports PVID in a VLAN not present in the VLAN table. A dynamic entry is created in the VLAN table to express that.
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8310
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Sep 20, 2017 9:06 am

By the way, maybe it's possible to add an action (probably to Bridge DST-NAT - it's suitable, according to Packet Flow diagram) to set/unset VLAN tag on the packet (to do kind of MAC-based/protocol-based VLAN)?
Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

For every complex problem, there is a solution that is simple, neat, and wrong.

MikroTik. Your life. Your routing.
 
mszru
just joined
Posts: 18
Joined: Wed Aug 10, 2016 10:42 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Sep 20, 2017 10:44 am

...bridge1 doesn't need to be in a vlan for that vlan to forward frames to the member ports?.
It didn't work for me until I added the bridge1 itself to the tagged ports list.

I have temporarily setup hAP lite (RB941-2nD) as a VLAN aware switch which forwards both untagged and tagged (vlan=100) frames. I didn't do anything in the "Switch" menu. The configuration was done in the "Bridge" menu only:
1) Added ether1, ether2, ether3 and ether4 as member ports for bridge1 in "Bridge" -> "Ports" and for each member port I set pvid=1 and frame-types=admit-all
interface bridge port 
add interface=ether1 bridge=bridge1 pvid=1 frame-types=admit-all hw=yes
add interface=ether2 bridge=bridge1 pvid=1 frame-types=admit-all hw=yes
add interface=ether3 bridge=bridge1 pvid=1 frame-types=admit-all hw=yes
add interface=ether4 bridge=bridge1 pvid=1 frame-types=admit-all hw=yes
2) In the "Bridge" -> "VLANs" made all members ports aware of vlan 100 tagged frames (including bridge1 itself).
interface bridge vlan add bridge=bridge1 vlan-ids=100 tagged=bridge1,ether1,ether2,ether3,ether4 untagged=""
3) Enabled VLAN Filtering for bridge1 in the "Bridge" -> "Bridge" menu.
interface bridge set bridge1 vlan-filtering=yes pvid=1
4) [optional] Added vlan100 interface to the bridge1 to be able to manage the router from that VLAN.
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1407
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Sep 20, 2017 4:42 pm

What's new in 6.41rc31 (2017-Sep-20 06:56):

Important note!!! Backup before upgrade!
RouterOS (v6.40rc36-rc40 and) v6.41rc1+ contains new bridge implementation that supports hardware offloading (hw-offload).
This update will convert all interface "master-port" configuration into new bridge configuration, and eliminate "master-port" option as such.
Bridge will handle all Layer2 forwarding and the use of switch-chip (hw-offload) will be automatically turned on based on appropriate conditions.
The rest of RouterOS Switch specific configuration remains untouched in usual menus for now.
Please, note that downgrading to previous RouterOS versions will not restore "master-port" configuration, so use backups to restore configuration on downgrade.


Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;
2) Make sure the device will not lose power during upgrade process;
3) Device has enough free storage space for all RouterOS packages to be downloaded.

Changes since previous 6.41rc release:

*) crs317 - added initial support for HW offloaded MPLS forwarding;
*) lte - added "/interface lte apn" menu (Passthrough requires reconfiguration) (CLI only);
*) lte - added Passthrough support (CLI only);
*) lte - added support for ZTE ME3630 E1C with additional "/port" for GPS usage;
*) lte - automatically add "/ip dhcp-client" configuration on interface;
*) lte - changed default values to "add-default-route=yes", "use-peer-dns=yes" and "default-route-distance=2";
*) ppp - fixed serial port loading (introduced in v6.41rc);
*) sfp - fixed temperature readings for various SFP modules;
*) snmp - fixed "/system license" parameters for CHR;
*) wireless - improved reliability on "rx-rate" selection process;

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after crash.
 
cheeze
Member Candidate
Member Candidate
Posts: 146
Joined: Tue Jul 31, 2012 7:44 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Sep 21, 2017 12:27 am

What's new in 6.41rc31 (2017-Sep-20 06:56):

Important note!!! Backup before upgrade!
RouterOS (v6.40rc36-rc40 and) v6.41rc1+ contains new bridge implementation that supports hardware offloading (hw-offload).
This update will convert all interface "master-port" configuration into new bridge configuration, and eliminate "master-port" option as such.
Bridge will handle all Layer2 forwarding and the use of switch-chip (hw-offload) will be automatically turned on based on appropriate conditions.
The rest of RouterOS Switch specific configuration remains untouched in usual menus for now.
Please, note that downgrading to previous RouterOS versions will not restore "master-port" configuration, so use backups to restore configuration on downgrade.


Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;
2) Make sure the device will not lose power during upgrade process;
3) Device has enough free storage space for all RouterOS packages to be downloaded.

Changes since previous 6.41rc release:

*) crs317 - added initial support for HW offloaded MPLS forwarding;
*) lte - added "/interface lte apn" menu (Passthrough requires reconfiguration) (CLI only);
*) lte - added Passthrough support (CLI only);
*) lte - added support for ZTE ME3630 E1C with additional "/port" for GPS usage;
*) lte - automatically add "/ip dhcp-client" configuration on interface;
*) lte - changed default values to "add-default-route=yes", "use-peer-dns=yes" and "default-route-distance=2";
*) ppp - fixed serial port loading (introduced in v6.41rc);
*) sfp - fixed temperature readings for various SFP modules;
*) snmp - fixed "/system license" parameters for CHR;
*) wireless - improved reliability on "rx-rate" selection process;

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after crash.
strods, are we looking feature complete for 6.41 yet? I'm just curious if it's down to polishing and bug fixes or if there's more that's intending to be added.

I know I'm not the only one very eager for it.
 
biatche
Member Candidate
Member Candidate
Posts: 128
Joined: Tue Oct 13, 2015 6:50 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Sep 21, 2017 12:58 am


strods, are we looking feature complete for 6.41 yet? I'm just curious if it's down to polishing and bug fixes or if there's more that's intending to be added.

I know I'm not the only one very eager for it.
one thing that i've never understood about mikrotik is why they add new features to RC.there should be testing or beta channel, rc channel (feature locked), stable(bugfix), mainline(current)

this would make far more sense
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Posts: 945
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Sep 21, 2017 2:24 am

One thing that I've never understood about MikroTik is why they add new features to the RC. There should be testing or beta channel, rc channel (feature locked), stable(bugfix), and mainline(current).
Which is why I won't touch updates with a 10 foot pole.
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Sep 21, 2017 6:53 am

One thing that I've never understood about MikroTik is why they add new features to the RC. There should be testing or beta channel, rc channel (feature locked), stable(bugfix), and mainline(current).
Which is why I won't touch updates with a 10 foot pole.

Mmmmm hacker bait. :)
 
andriys
Forum Guru
Forum Guru
Posts: 1180
Joined: Thu Nov 24, 2011 1:59 pm
Location: Kharkiv, Ukraine

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Sep 21, 2017 9:52 am

there should be testing or beta channel, rc channel (feature locked), stable(bugfix), mainline(current)
This is just a naming convention, you just have to get used to it.

In any case, please do NOT pollute this thread with the naming convention nonsense again. If you feel like you are in absolutely need to discuss, here is one of the many threads to reply to: viewtopic.php?f=2&t=123032.
 
biatche
Member Candidate
Member Candidate
Posts: 128
Joined: Tue Oct 13, 2015 6:50 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Sep 21, 2017 10:37 am

there should be testing or beta channel, rc channel (feature locked), stable(bugfix), mainline(current)
This is just a naming convention, you just have to get used to it.

In any case, please do NOT pollute this thread with the naming convention nonsense again. If you feel like you are in absolutely need to discuss, here is one of the many threads to reply to: viewtopic.php?f=2&t=123032.
to you its a naming convention, but the rc are often very "alpha status", and rc can be misleading to new users who by norm perceive that rc's are "generally stable". why do you think cheeze asked if its down to polishing and bugfixes? its because rc naming convention makes it confusing for some users. no one would have to question if rc actually meant rc, alpha meant alpha, beta meant beta, and then we won't be having this discussion.

and thanks to polluted nonsense or not, we finally received MSTP after so many years, have you forgotten, mr forum police?
 
User avatar
bajodel
Long time Member
Long time Member
Posts: 545
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Sep 21, 2017 10:47 am

Just updated a CRS125 test unit to 6.41rc31 (from 6.40.3); firmware upgrade and master-port-TO-new-bridge config auto-conversion went smoothly.
NOTE: CRS125 config has custom MAC addresses set for all interfaces and this has not compromised upgrade/conversion, on CRS326 instead custom MAC addresses can be set but IMHO the device hang at first reboot (pay attention).
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 24217
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Sep 21, 2017 10:59 am

to you its a naming convention, but the rc are often very "alpha status", and rc can be misleading to new users who by norm perceive that rc's are "generally stable"
We are aware of this, but in RouterOS world, "stable" is the only version you should use in important locations where you don't want new features. We update this branch rarely and only after long and rigorous testing. Current is more like RC (current = running release), and RC is more like Beta or "nightly build" in Windows land.
No answer to your question? How to write posts
 
willglynn
just joined
Posts: 2
Joined: Mon May 01, 2017 4:18 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Sep 22, 2017 4:37 am

The previous switch settings supported MAC learning limits:
/interface ethernet switch port
set ether6 learn-limit=1
set ether7 learn-limit=1
Is this feature still available with the new bridge implementation?
 
JimmyNyholm
Member Candidate
Member Candidate
Posts: 249
Joined: Mon Apr 25, 2016 2:16 am
Location: Sweden

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Sep 22, 2017 12:36 pm

The previous switch settings supported MAC learning limits:
/interface ethernet switch port
set ether6 learn-limit=1
set ether7 learn-limit=1
Is this feature still available with the new bridge implementation?
Not as faar as I can se for the moment..
And while we speak of it would it be Possible to add this to the new implementation and possibly enhance it with ie: learn-limit=1 learn-clear-at-interface-down=no learn-replace-after-inactivity=15min
and or even cooler lear-radius-auth=yes (with all the magic options as answer properties in the radius answer
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1407
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Sep 22, 2017 2:24 pm

What's new in 6.41rc32 (2017-Sep-21 13:51):

Important note!!! Backup before upgrade!
RouterOS (v6.40rc36-rc40 and) v6.41rc1+ contains new bridge implementation that supports hardware offloading (hw-offload).
This update will convert all interface "master-port" configuration into new bridge configuration, and eliminate "master-port" option as such.
Bridge will handle all Layer2 forwarding and the use of switch-chip (hw-offload) will be automatically turned on based on appropriate conditions.
The rest of RouterOS Switch specific configuration remains untouched in usual menus for now.
Please, note that downgrading to previous RouterOS versions will not restore "master-port" configuration, so use backups to restore configuration on downgrade.


Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;
2) Make sure the device will not lose power during upgrade process;
3) Device has enough free storage space for all RouterOS packages to be downloaded.

Changes since previous 6.41rc release:

!) bridge - general development of hw-offload bridge implementation (introduced in v6.40rc36);
*) bridge - added initial support for hardware "igmp-snooping" on CRS1xx/2xx;
*) bridge - implemented software based "igmp-snooping";
*) console - do not stop "/certificate sign" process if console times out in 1 minute;
*) lte - added "/interface lte apn" menu (Passthrough requires reconfiguration) (CLI only);
*) traceroute - improved "/tool traceroute" results processing;
*) wireless - log "signal-strength" when successfully connected to AP;

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after crash.
 
dschn
newbie
Posts: 25
Joined: Wed Nov 16, 2016 2:22 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Sep 22, 2017 5:10 pm

With v6.41rc31 my LTE connection was very slow, max. 7-10mbit/s and high pings >200ms. Also the E3372 LTE modem (still) loses connection when downloading larger amounts of data (via Steam for example) so you have to reboot the RB.
 
uldis
MikroTik Support
MikroTik Support
Posts: 3425
Joined: Mon May 31, 2004 2:55 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Sep 22, 2017 5:12 pm

With v6.41rc31 my LTE connection was very slow, max. 7-10mbit/s and high pings >200ms. Also the E3372 LTE modem (still) loses connection when downloading larger amounts of data (via Steam for example) so you have to reboot the RB.
What version you had before on your router where it was working ok?
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Posts: 945
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Sep 22, 2017 5:52 pm


The previous switch settings supported MAC learning limits:
/interface ethernet switch port set ether6 learn-limit=1
Is this feature still available with the new bridge implementation?
While we are speaking about this, could we enhance it with ie: learn-limit=1 learn-clear-at-interface-down=no learn-replace-after-inactivity=15min
and or even cooler lear-radius-auth=yes (with all the magic options as answer properties in the radius answer?
Yes, please. Cisco calls a learned MAC on reboot sticky (I think). Replace after a timeout is good too.
 
w0lt
Member
Member
Posts: 484
Joined: Wed Apr 02, 2008 2:12 pm
Location: Minnesota USA

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Sep 22, 2017 6:30 pm

What's new in 6.41rc32 (2017-Sep-21 13:51):

!) bridge - general development of hw-offload bridge implementation (introduced in v6.40rc36);
*) bridge - added initial support for hardware "igmp-snooping" on CRS1xx/2xx;
*) bridge - implemented software based "igmp-snooping";
Is it possible to get a better explanation or detail on the software based "igmp-snooping" ?
MTCNA - 2011

" The Bitterness of Poor Quality Remains Long After the Sweetness of Low Price is Forgotten "

Image
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Sep 22, 2017 10:17 pm

What's new in 6.41rc32 (2017-Sep-21 13:51):

!) bridge - general development of hw-offload bridge implementation (introduced in v6.40rc36);
*) bridge - added initial support for hardware "igmp-snooping" on CRS1xx/2xx;
*) bridge - implemented software based "igmp-snooping";
Is it possible to get a better explanation or detail on the software based "igmp-snooping" ?
The bridge will perform IGMP snooping in a way that requires the CPU to process to packets instead of customized and often accelerated (faster) hardware that is meant to do it at line-rate or near line-rate.
 
w0lt
Member
Member
Posts: 484
Joined: Wed Apr 02, 2008 2:12 pm
Location: Minnesota USA

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Sep 23, 2017 2:44 am

What's new in 6.41rc32 (2017-Sep-21 13:51):

!) bridge - general development of hw-offload bridge implementation (introduced in v6.40rc36);
*) bridge - added initial support for hardware "igmp-snooping" on CRS1xx/2xx;
*) bridge - implemented software based "igmp-snooping";
Is it possible to get a better explanation or detail on the software based "igmp-snooping" ?
The bridge will perform IGMP snooping in a way that requires the CPU to process to packets instead of customized and often accelerated (faster) hardware that is meant to do it at line-rate or near line-rate.
Probably should of phrased the question better... How to "correctly" configure software based IGMP-Snooping . :D

-tp
MTCNA - 2011

" The Bitterness of Poor Quality Remains Long After the Sweetness of Low Price is Forgotten "

Image
 
User avatar
honzam
Forum Guru
Forum Guru
Posts: 2288
Joined: Wed Feb 27, 2008 10:27 pm
Location: Czech Republic

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Sep 23, 2017 12:32 pm

*) wireless - log "signal-strength" when successfully connected to AP;
Very useful feature. Thank you. It could be possible to add the last signal when the state is disconnected?
LAN, FTTx, Wireless. ISP operator
 
Paternot
Long time Member
Long time Member
Posts: 607
Joined: Thu Jun 02, 2016 4:01 am
Location: Niterói / Brazil

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Sep 23, 2017 3:40 pm

*) wireless - log "signal-strength" when successfully connected to AP;
Very useful feature. Thank you. It could be possible to add the last signal when the state is disconnected?
Excelent idea!
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Posts: 945
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Sep 23, 2017 4:48 pm

*) wireless - log "signal-strength" when successfully connected to AP;
Very useful feature. Thank you. Would it be possible to add the last signal when the state was disconnected?
That might be extremely useful, if the data correlates to client's disconnecting around full power. We could point blame at something other than coverage.
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8310
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Sep 25, 2017 10:47 am

Probably should of phrased the question better... How to "correctly" configure software based IGMP-Snooping . :D
interface bridge set bla-bla igmp-snooping=yes
:)
This entry in changelog just means that there were some improvements in already implemented snooping.
Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

For every complex problem, there is a solution that is simple, neat, and wrong.

MikroTik. Your life. Your routing.
 
dschn
newbie
Posts: 25
Joined: Wed Nov 16, 2016 2:22 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Sep 25, 2017 11:24 am

What version you had before on your router where it was working ok?
I reverted back to 6.40.3 where speeds are normal, but that version too has the problem that the E3372 is unstable an looses LTE connection when there is some load. I hoped the latest RC would fix this...
 
uldis
MikroTik Support
MikroTik Support
Posts: 3425
Joined: Mon May 31, 2004 2:55 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Sep 25, 2017 12:06 pm

What version you had before on your router where it was working ok?
I reverted back to 6.40.3 where speeds are normal, but that version too has the problem that the E3372 is unstable an looses LTE connection when there is some load. I hoped the latest RC would fix this...
Please contact support@mikrotik.com for more information (include the modem number and revision). Also check what lte band it uses when you have normal speed and when you have slow speed.
 
Ulypka
Frequent Visitor
Frequent Visitor
Posts: 52
Joined: Wed Jan 09, 2013 8:26 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Sep 25, 2017 2:11 pm

have you planned add HW offload with vlan-filtering function?
 
biatche
Member Candidate
Member Candidate
Posts: 128
Joined: Tue Oct 13, 2015 6:50 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Sep 25, 2017 6:17 pm

have you planned add HW offload with vlan-filtering function?
careful now, forum police andyris might warn you to post in feature request thread.
 
User avatar
eworm
Member
Member
Posts: 396
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Sep 25, 2017 6:20 pm

I am having issues with CAPsMAN on 6.41rc13... Looks like cap interfaces with CAPsMAN forwarding do not pass any traffic.
The issue persists with 6.41rc16... Just downgraded to 6.41rc11 and wireless is up and running.
Updated to 6.41rc32 and everything works as expected. I can not tell what intermediate version fixed the issue though.
Thanks Uldis!
Manage RouterOS scripts and extend your devices' functionality: RouterOS Scripts
 
Ulypka
Frequent Visitor
Frequent Visitor
Posts: 52
Joined: Wed Jan 09, 2013 8:26 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Sep 25, 2017 7:11 pm

have you planned add HW offload with vlan-filtering function?
careful now, forum police andyris might warn you to post in feature request thread.
this is not a feature request, it's a question
will return the functionality that was lost in the new version.
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4051
Joined: Wed May 11, 2011 6:08 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Sep 27, 2017 12:23 am

I just put 6.41rc32 onto an RB2011UAS-2HnD and have a question.

The pre-upgrade configuration was with a bridge name=LAN with ports=ether2 and ether6, with those set as masters in the switch menu to ports ether3-5 and ether7-9 respectively.
ether1, ether10, and sfp1 were all stand-alone interfaces.

Long story short: after the upgrade, the bridge ports menu still only lists ether2 and ether6 as ports of the LAN bridge, but I am still able to reach the router from ether3 as if it were a member of the bridge. The bridge > hosts displays my laptop's MAC address on ether3 (correctly) but I can't see anything that would tell me ether3 should be bridged with ether2.

Am I missing something obvious that would show me ether3 as a member of the LAN bridge? (or as a member of some other hardware-accelerated bridge?)
When given a spoon,
you should not cling to your fork.
The soup will get cold.
 
skuykend
Member Candidate
Member Candidate
Posts: 270
Joined: Tue Oct 06, 2015 7:28 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Sep 27, 2017 3:54 am

I just put 6.41rc32 onto an RB2011UAS-2HnD and have a question.
I had a similar issue with a 951G. First boot with upgrade, was still able to connect from port 5. Rebooted one more time and lost connection until I switched to port 2.

Maybe the initial config needs one more reboot or switch reset to behave as expected.
 
rapidsky
just joined
Posts: 2
Joined: Wed Sep 20, 2017 9:33 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Sep 27, 2017 7:55 am

On the CRS326 running 6.41rc32 and firmware 3.41, adding some ports to bridge2 disables their hardware offload. This is Is this expected?
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload 
 #     INTERFACE                                BRIDGE                               HW  PVID PRIORITY  PATH-COST INTERNAL-PATH-COST    HORIZON
 0   H ether1                                   bridge1                              yes    1     0x80         10                 10       none
 1 I H ether2                                   bridge1                              yes    1     0x80         10                 10       none
 2 I H ether3                                   bridge1                              yes    1     0x80         10                 10       none
 3 I H ether4                                   bridge1                              yes    1     0x80         10                 10       none
 4 I H ether5                                   bridge1                              yes    1     0x80         10                 10       none
 5 I H ether6                                   bridge1                              yes    1     0x80         10                 10       none
 6 I H ether7                                   bridge1                              yes    1     0x80         10                 10       none
 7 I H ether8                                   bridge1                              yes    1     0x80         10                 10       none
 8 I H ether9                                   bridge1                              yes    1     0x80         10                 10       none
 9 I H ether10                                  bridge1                              yes    1     0x80         10                 10       none
10 I H ether11                                  bridge1                              yes    1     0x80         10                 10       none
11 I H ether12                                  bridge1                              yes    1     0x80         10                 10       none
12 I H ether13                                  bridge1                              yes    1     0x80         10                 10       none
13 I H ether14                                  bridge1                              yes    1     0x80         10                 10       none
14 I H ether15                                  bridge1                              yes    1     0x80         10                 10       none
15 I H ether16                                  bridge1                              yes    1     0x80         10                 10       none
16 I H sfp-sfpplus1                             bridge1                              yes    1     0x80         10                 10       none
17 I   ether17                                  bridge2                              yes    1     0x80         10                 10       none
18 I   ether18                                  bridge2                              yes    1     0x80         10                 10       none
19 I   ether19                                  bridge2                              yes    1     0x80         10                 10       none
20 I   ether20                                  bridge2                              yes    1     0x80         10                 10       none
21 I   ether21                                  bridge2                              yes    1     0x80         10                 10       none
22 I   ether22                                  bridge2                              yes    1     0x80         10                 10       none
23 I   ether23                                  bridge2                              yes    1     0x80         10                 10       none
24 I   ether24                                  bridge2                              yes    1     0x80         10                 10       none
25 I   sfp-sfpplus2                             bridge2                              yes    1     0x80         10                 10       none
 
User avatar
Jotne
Forum Guru
Forum Guru
Posts: 1303
Joined: Sat Dec 24, 2016 11:17 am
Location: jo.overland at gmail.com

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Sep 27, 2017 9:03 am

Not sure if this is related to RC build or its a general problem for MikroTik

I have a RB941-2nD for testing. Upgraded to latest RC and its running fine.
Then I see that there are new firmware available. So I click the upgrade button.
RB tells me "Do you really want to upgrade the firmware?"
I click yes, and nothing more happens.
Firmware is still the same, no changes anywhere.
So I did go to Terminal and did try the same.
There I got this message: 07:56:59 echo: system,info,critical Firmware upgraded successfully, please reboot for changes to take effect!
Ahh, Its need a reboot!!

1. Remove the really, its telling me "are you really so stupid that you like to upgrade?", change to "Do you want to upgrade firmware"
2. Add information that reboot is needed after the web upgrade.
 
How to use Splunk to monitor your MikroTik Router

MikroTik->Splunk
 
 
User avatar
floeff
newbie
Posts: 41
Joined: Sat Jan 28, 2017 6:39 pm
Location: Germany
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Sep 27, 2017 11:40 am

I might have hit a bug wrt. the bridge conversion.
hAP lite, RouterBOOT 3.41, RouterOS 6.40.
Device completely resetted, export only showed configuration of ether interfaces, nothing else (as intended).
ether1 not configured further, ether2 not configured further. ether3-4 configured with ether2 as master port.
My understanding is that the update to 6.41rc should create a HW offload bridge with ether2-5 in
It did create the bridge with a comment that this was created due to the upgrade, but that bridge contained no port at all.
Trivial to fix, but IMHO not as expected?
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1407
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Sep 27, 2017 2:33 pm

What's new in 6.41rc34 (2017-Sep-27 10:05):

Important note!!! Backup before upgrade!
RouterOS (v6.40rc36-rc40 and) v6.41rc1+ contains new bridge implementation that supports hardware offloading (hw-offload).
This update will convert all interface "master-port" configuration into new bridge configuration, and eliminate "master-port" option as such.
Bridge will handle all Layer2 forwarding and the use of switch-chip (hw-offload) will be automatically turned on based on appropriate conditions.
The rest of RouterOS Switch specific configuration remains untouched in usual menus for now.
Please, note that downgrading to previous RouterOS versions will not restore "master-port" configuration, so use backups to restore configuration on downgrade.


Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;
2) Make sure the device will not lose power during upgrade process;
3) Device has enough free storage space for all RouterOS packages to be downloaded.

Changes since previous 6.41rc release:

*) crs3xx - improved packet processing in slowpath;
*) defconf - fixed RouterOS default configuration (introduced in v6.40.3);
*) ethernet - removed "master-port" parameter;
*) log - fixed "unknown" interface name in log messages;
*) lte - added "/interface lte apn" menu (Passthrough requires reconfiguration) (CLI only);
*) lte - do not reset modem when it is not possible to access SMS storage;
*) snmp - fixed "ifHighSpeed" value of VLAN, VRRP and Bonding interfaces;
*) snmp - fixed "/caps-man registration-table" uptime values;
*) tile - improved hardware encryption processes;
*) vlan - do not allow VLAN MTU to be higher than L2MTU;
*) wireless - fixed rate selection process when "rate-set=configured" and NV2 protocol is used;

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after crash.
 
User avatar
bajodel
Long time Member
Long time Member
Posts: 545
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Sep 27, 2017 8:14 pm

Board: CRS326-24G-2S+
Previous ROS: 6.41rc32
Status: quite stable, all port in bridge w/ RSTP enabled and 2 active link to CRS125 (active/alternate)

Upgraded to 6.41rc34, every 3-5 minutes my laptop (direct patch cord to a CRS326 port) detects lost link; on a separate windows I've constant ping to my firewall and I can see ping fail (General Error = link down / no laptop eth conn). After some seconds link is back and ping go normal.

On 6.41rc32 (tested in the last 3 days) I've not seen any similar behaviour (and I've made no topology changes).
Now I've disabled RSTP (and removed redundant link to CRS125) and it'seems to be stable again (consider it's only 30 minutes now I'm testing this).

Even if these are lab equipments, I'm considering going back to 6.40.3 and stay there for some weeks ..probably this switch_2_bridge conversion is something which needs time to consolidate.
Some days ago I've netinstalled 2 time the CRS326 because it doesn't like MAC changes.
 
User avatar
bajodel
Long time Member
Long time Member
Posts: 545
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Sep 28, 2017 1:03 am

(see previous post) Confirmed.. after some hours, disablig RSTP it's now stable.
 
User avatar
bajodel
Long time Member
Long time Member
Posts: 545
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Sep 28, 2017 3:12 am

I've noticed one more thing (CRS326 - 6.41rc34 - RSTP now enabled):
>> keeping winbox logged to CRS326 the problem does not show up
>> closing winbox .. flapping starts
 
fanMikroTik
just joined
Posts: 7
Joined: Fri Sep 08, 2017 8:32 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Sep 30, 2017 10:07 am

Hw. Offload
After reboot I have this in log...

hardware offloading activated on bridge "bridge1" ports: wlan1,ether2
hardware offloading activated on bridge "bridge1" ports: wlan1,ether3

But port wlan1 status is inactive and not Hw. Offload... Is is correct?

Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload
0 XI ether1 bridge1 yes 1 0x80 10 10 none
1 H ether2 bridge1 yes 1 0x80 10 10 none 
2 H ether3 bridge1 yes 1 0x80 10 10 none 
3 XI ether4 bridge1 yes 1 0x80 10 10 none
4 wlan1 bridge1 yes 1 0x80 10 10 none 
 
JimmyNyholm
Member Candidate
Member Candidate
Posts: 249
Joined: Mon Apr 25, 2016 2:16 am
Location: Sweden

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Sep 30, 2017 8:33 pm

Hw. Offload
After reboot I have this in log...

hardware offloading activated on bridge "bridge1" ports: wlan1,ether2
hardware offloading activated on bridge "bridge1" ports: wlan1,ether3

But port wlan1 status is inactive and not Hw. Offload... Is is correct?

Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload
0 XI ether1 bridge1 yes 1 0x80 10 10 none
1 H ether2 bridge1 yes 1 0x80 10 10 none 
2 H ether3 bridge1 yes 1 0x80 10 10 none 
3 XI ether4 bridge1 yes 1 0x80 10 10 none
4 wlan1 bridge1 yes 1 0x80 10 10 none 
Not stating your board but from what I can tell wlan1 is a wlan interface right? this interface maybe is not connected in hardware to the same switch chip. Hence it's not hardware enabled. Look att the Block diagrams of your unit an you will se how it's built.
 
fanMikroTik
just joined
Posts: 7
Joined: Fri Sep 08, 2017 8:32 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Sep 30, 2017 9:09 pm

I think You are right (RB951Ui-2HnD), but I don't understand the log message including wlan1 port...
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Sep 30, 2017 10:53 pm

MikroTik can correct me on Monday but that's probably referring to the bridge level hardware offload feature or the port hw=yes setting. You can set it to yes regardless of it being a wlan or Ethernet interface.
 
teleweb
just joined
Posts: 2
Joined: Fri Jul 15, 2016 5:11 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Oct 02, 2017 3:56 am

Hi, we have a question about the new bridge / hw offloading implementation in CRS 317-1G-16S+

I have created 2 bridges: most ports added to bridge1, two ports added to bridge2.
Now I only see the H (or "Hw offload" checked) with the ports of bridge1.
Can you only have one bridge making use of hw offloading?
We have enabled "Fast forward" at the bridge level, and "Hardware offload" at the port level.

Thanks!
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1407
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Oct 02, 2017 11:23 am

What's new in 6.41rc37 (2017-Oct-02 06:47):

Important note!!! Backup before upgrade!
RouterOS (v6.40rc36-rc40 and) v6.41rc1+ contains new bridge implementation that supports hardware offloading (hw-offload).
This update will convert all interface "master-port" configuration into new bridge configuration, and eliminate "master-port" option as such.
Bridge will handle all Layer2 forwarding and the use of switch-chip (hw-offload) will be automatically turned on based on appropriate conditions.
The rest of RouterOS Switch specific configuration remains untouched in usual menus for now.
Please, note that downgrading to previous RouterOS versions will not restore "master-port" configuration, so use backups to restore configuration on downgrade.


Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;
2) Make sure the device will not lose power during upgrade process;
3) Device has enough free storage space for all RouterOS packages to be downloaded.

Changes since previous 6.41rc release:

!) bridge - general development of hw-offload bridge implementation (introduced in v6.40rc36);
*) bridge - initial support for "/interface list" as a bridge port (CLI only);
*) fetch - accept all HTTP 2xx status codes;
*) ike2 - fixed initiator DDoS cookie processing;
*) ike2 - fixed responder DDoS cookie first notify type check;
*) lte - fixed modem initialization after reboot;
*) ntp-client - properly start NTP client after reboot if manual server IP is not configured;
*) sfp - fixed OPTON module DDM information readings;
*) wireless - added "etsi1" regulatory domain information;
*) wireless - improved WPA2 key exchange reliability;
*) wireless - updated "norway" regulatory domain information;

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after crash.
 
User avatar
bajodel
Long time Member
Long time Member
Posts: 545
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Oct 02, 2017 2:11 pm

Upgraded CRS326-24G-2S+ to 6.41rc37 , after reboot in the log I've noticed all ports have been removed from bridge hw-offloading and re-inserted.
I've also noticed Firmware 3.43 was available for CRS326-24G-2S+ and I've upgraded it also and rebooted.

Now I've enabled RSTP again and I'm going to re-insert the redundant patch cord to CRS125 ..and see what happen now
 
pcjc
just joined
Posts: 20
Joined: Wed Aug 02, 2017 4:29 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Oct 02, 2017 6:36 pm

I decided to try the 6.41rc release on my new CRS326-24G-2S+.

Two notes..

1. Same with 6.40 release firmware, the LAN activity light on Port 1 RJ45 blinks on (appears to reflect activity on the bridge link?), which appears to be a bug (or is this a hardware fault I should return the unit for?)

2. I cannot set the MTU of the bridge (which replaced the old switch configuration) to support jumbo frames. (I can create a new bridge with high MTU, but get an error "Couldn't change Interface <bridge1> - could not set mtu (6)" when attempting to do so on the bridge with all my ports on.

The ports are all hardware offloaded. Do I need to set a high MTU on the bridge / interfaces within the bridge in order to be able to pass jumbo frames? (That is what I am trying to achieve).
 
User avatar
bajodel
Long time Member
Long time Member
Posts: 545
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Oct 02, 2017 6:40 pm

It's been 4 hours and the CRS326-24G-2S+ (on 6.41rc37) is now beheaving well:
- RSTP now works stable between CRS326 and CRS125 (also on 6.41rc37)
- it's now possible to edit MAC addresses on CRS326 ethernet ports (and the device doesn't stuck on reboot)
- no port flapping (yet)

very curious about this:
*) wireless - improved WPA2 key exchange reliability;
 
eriitguy
Member Candidate
Member Candidate
Posts: 197
Joined: Thu Jan 26, 2017 1:16 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Oct 03, 2017 11:33 am

What's new in 6.41rc37 (2017-Oct-02 06:47):

Changes since previous 6.41rc release:

*) fetch - accept all HTTP 2xx status codes;
Thank you for this fix!

I don't know how it was planned but noticed that it failed at 204 status code:
[admin@CHR] > /tool fetch url="http://httpstat.us/204"
  status: failed

action failed (6)
 
eriitguy
Member Candidate
Member Candidate
Posts: 197
Joined: Thu Jan 26, 2017 1:16 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Oct 03, 2017 11:40 am

normis, thank you for observation:
[admin@CHR] > /tool fetch url="https://httpstatuses.com/204"
      status: finished
  downloaded: 3KiBC-z pause]
    duration: 1s
It working as expected!
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 24217
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Oct 03, 2017 11:44 am

There actually is a bug with 204, we will address it. Your previous URL works with "curl -v" so it should work in Fetch too.
No answer to your question? How to write posts
 
msatter
Forum Guru
Forum Guru
Posts: 1243
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Oct 03, 2017 12:31 pm

Maybe it is possible to extra spaces to end of the "KiB" to erase the remainder of the previous text: "C-z pause]" with fetch.
Two RB760iGS (hEX S) in series. One does PPPoE and both do IKEv2.
Running:
RouterOS 7.0/6.46Beta / Winbox 3.20 / MikroTik APP 1.3.4
Having an Android device, use https://github.com/M66B/NetGuard/releases (no root required)
 
jrpaz
Frequent Visitor
Frequent Visitor
Posts: 82
Joined: Wed Jun 05, 2013 5:54 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Oct 03, 2017 2:32 pm

I have a Novotel 730 which was added in 6.41r6 & it still is function it reboots when ever I try to pass traffic through it. I already emailed support hopefully they can help me figure this out.
 
niqx
just joined
Posts: 2
Joined: Thu Oct 01, 2015 10:28 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Oct 03, 2017 3:34 pm

Hello Friends,

A small note, but very important for us that uses ALOT of vlans.

We're currently benching CRS317 and we're missing out the option to set notes/comments under /interface bridge vlan.

This is because we'll have alot of config here and since we're alot of people managing the same devices it's key to leave notes. :-)
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1407
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Oct 03, 2017 4:00 pm

What's new in 6.41rc38 (2017-Oct-03 11:51):

Important note!!! Backup before upgrade!
RouterOS (v6.40rc36-rc40 and) v6.41rc1+ contains new bridge implementation that supports hardware offloading (hw-offload).
This update will convert all interface "master-port" configuration into new bridge configuration, and eliminate "master-port" option as such.
Bridge will handle all Layer2 forwarding and the use of switch-chip (hw-offload) will be automatically turned on based on appropriate conditions.
The rest of RouterOS Switch specific configuration remains untouched in usual menus for now.
Please, note that downgrading to previous RouterOS versions will not restore "master-port" configuration, so use backups to restore configuration on downgrade.


Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;
2) Make sure the device will not lose power during upgrade process;
3) Device has enough free storage space for all RouterOS packages to be downloaded.

Changes since previous 6.41rc release:

*) arm - minor improvements on CPU load distribution for RB1100 series devices;
*) bgp - added 32-bit private ASN support;
*) lte - added Passthrough support (CLI only);
*) snmp - fixed "/system license" parameters for CHR;
*) upnp - add "src-address" parameter on NAT rule if it is specified on UPnP request;
*) upnp - deny UPnP request if port is already used by the router;

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after crash.
 
lukoramu
just joined
Posts: 18
Joined: Mon Jan 07, 2013 11:11 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Oct 03, 2017 4:46 pm

*) bridge - initial support for "/interface list" as a bridge port (CLI only);
Try this:
/in bridge port add interface=all
It's fun! (Spoiler alert - netinstall.exe) ;-)
But actually, this feature is really what I was waiting for for a long time. I just hope these interface lists will be available for "tagged" and "untagged" attributes in "/in br vlan" section !
 
eriitguy
Member Candidate
Member Candidate
Posts: 197
Joined: Thu Jan 26, 2017 1:16 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Oct 03, 2017 5:55 pm

strods,

What is difference between earlier RC, for example:

What's new in 6.41rc38 (2017-Oct-03 11:51):
*) lte - added Passthrough support (CLI only);
What's new in 6.41rc31 (2017-Sep-20 06:56):
*) lte - added Passthrough support (CLI only);
 
nescafe2002
Long time Member
Long time Member
Posts: 623
Joined: Tue Aug 11, 2015 12:46 pm
Location: Netherlands

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Oct 03, 2017 6:00 pm

viewtopic.php?f=21&t=123936&start=100#p614799
If you see the same changelog entry in multiple rc versions then it is a new feature which is being implemented and changelog entry is simply moved up on each rc when additional work on it has been done.
 
eriitguy
Member Candidate
Member Candidate
Posts: 197
Joined: Thu Jan 26, 2017 1:16 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Oct 03, 2017 6:14 pm

viewtopic.php?f=21&t=123936&start=100#p614799
If you see the same changelog entry in multiple rc versions then it is a new feature which is being implemented and changelog entry is simply moved up on each rc when additional work on it has been done.
Thank you!
 
uldis
MikroTik Support
MikroTik Support
Posts: 3425
Joined: Mon May 31, 2004 2:55 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Oct 03, 2017 6:16 pm

strods,

What is difference between earlier RC, for example:

What's new in 6.41rc38 (2017-Oct-03 11:51):
*) lte - added Passthrough support (CLI only);
What's new in 6.41rc31 (2017-Sep-20 06:56):
*) lte - added Passthrough support (CLI only);
We are constantly improving and fixing bugs for this feature.
 
User avatar
Jotne
Forum Guru
Forum Guru
Posts: 1303
Joined: Sat Dec 24, 2016 11:17 am
Location: jo.overland at gmail.com

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Oct 04, 2017 8:16 am

We are constantly improving and fixing bugs for this feature.
Then the correct should be:

What's new in 6.41rc38 (2017-Oct-03 11:51):
*) lte - updated Passthrough support (CLI only);

What's new in 6.41rc31 (2017-Sep-20 06:56):
*) lte - added Passthrough support (CLI only);
 
How to use Splunk to monitor your MikroTik Router

MikroTik->Splunk
 
 
hapi
Member Candidate
Member Candidate
Posts: 223
Joined: Fri Mar 11, 2011 11:21 am
Location: Czech Republic

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Oct 04, 2017 8:58 am

Why our sfp modules don't show tx power in mikrotik? Same module in signamax switch show tx power. THX.

Signamax
Connector Type	SFP - LC
Fiber Type	Reserved
Tx Central Wavelength	1310
Baud Rate	1G
Vendor OUI	00:00:00
Vendor Name	Mikrotik
Vendor PN	S-35LC20D
Vendor Rev	1.0
Vendor SN	SK151211B35234
Date Code	151205
Temperature [Degrees Centigrade]	33.75
Vcc [Volt]	3.30
Mon1 (Bias) [mA]	1
Mon2 (TX PWR) [dBm]	-5.19
Mon3 (RX PWR) [dBm]	-17.42
CRS326-24G-2S+
[admin@BS568] > interface ethernet monitor sfp-sfpplus1 
                    name: sfp-sfpplus1
                  status: link-ok
        auto-negotiation: disabled
                    rate: 1Gbps
             full-duplex: yes
         tx-flow-control: yes
         rx-flow-control: yes
      sfp-module-present: yes
             sfp-rx-loss: no
            sfp-tx-fault: no
                sfp-type: SFP-or-SFP+
      sfp-connector-type: LC
     sfp-link-length-9um: 20000m
         sfp-vendor-name: Mikrotik
  sfp-vendor-part-number: S-53LC20D
     sfp-vendor-revision: 1.0
       sfp-vendor-serial: SK151211B54444
  sfp-manufacturing-date: 15-12-05
          sfp-wavelength: 1550nm
         sfp-temperature: 40C
      sfp-supply-voltage: 3.296V
     sfp-tx-bias-current: 0mA
            sfp-rx-power: -9.752dBm
         eeprom-checksum: good
                  eeprom: 0000: 03 04 07 00 00 00 02 00  00 00 00 01 0d 00 14 c8  ........ ........
                          0010: 00 00 00 00 4d 69 6b 72  6f 74 69 6b 20 20 20 20  ....Mikr otik    
                          0020: 20 20 20 20 00 00 00 00  53 2d 35 33 4c 43 32 30      .... S-53LC20
                          0030: 44 20 20 20 20 20 20 20  31 2e 30 00 06 0e 00 e4  D        1.0.....
                          0040: 00 1a 00 00 53 4b 31 35  31 32 31 31 42 35 34 34  ....SK15 1211B544
                          0050: 34 34 20 20 31 35 31 32  30 35 20 20 68 f0 04 34  44  1512 05  h..4
                          0060: 1f a0 7b 0b 1a 66 2c 8c  00 00 52 52 52 52 00 52  ..{..f,. ..RRRR.R
                          0070: 00 40 52 52 00 40 52 52  52 52 52 ff ff ff ff 00  .@RR.@RR RRR.....
                          0080: 55 00 d8 00 46 00 00 00  8d cc 74 04 88 b8 79 18  U...F... ..t...y.
                          0090: af c8 00 00 88 b8 00 00  13 94 04 eb 13 94 04 eb  ........ ........
                          00a0: 18 a6 00 10 13 94 00 10  00 00 00 00 00 00 00 00  ........ ........
                          00b0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ........ ........
                          00c0: 00 00 00 00 3f 80 00 00  00 00 00 00 01 00 00 00  ....?... ........
                          00d0: 01 00 00 00 01 00 00 00  01 00 00 00 00 00 00 40  ........ .......@
                          00e0: 28 64 80 c6 00 65 0b b3  05 89 7d 7d 7d 7d 00 7d  (d...e.. ..}}}}.}
                          00f0: 00 00 7d 7d 00 00 7d 7d  7d 7d 07 ff ff ff ff 00  ..}}..}} }}......
Last edited by hapi on Wed Oct 04, 2017 9:39 am, edited 1 time in total.
 
User avatar
skylark
MikroTik Support
MikroTik Support
Posts: 106
Joined: Wed Feb 10, 2016 3:55 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Oct 04, 2017 9:15 am

Hello hapi,

DDM info seems quite good from SFP transceiver, why do you have auto-negotiation disabled and what is connected to opposite side? Have you tried to turn auto-negotiation=on?
 
hapi
Member Candidate
Member Candidate
Posts: 223
Joined: Fri Mar 11, 2011 11:21 am
Location: Czech Republic

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Oct 04, 2017 9:41 am

oh my mistake, it is CRS326-24G-2S+. Modul not function on 10Gbit = auto-negotation is disable and force 1Gbit otherwise they will not join on fiber.

TX power still not show.

v6.41rc38
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1407
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Oct 04, 2017 10:12 am

Jotne - Main idea of rc changelog is to see the difference between current and rc version. Think of an upgrade like you would upgrade from 6.40.4 to 6.41rc no from 6.41rc to 6.41rc.

Anyway, if you have more questions about changelog structure, then please create new forum topic about this or write to support@mikrotik.com

Main idea of this topic is to polish new features in 6.41rc version so that the version would become 6.41 (current) release.
 
Grickos
newbie
Posts: 32
Joined: Thu Aug 06, 2015 2:57 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Oct 04, 2017 6:19 pm

After upgrade to 6.41RC38, WAP R-2nD processor 100%, self nonstop reboot the system. I used Netinstall to run it.
The others Roterboard are work ok
 
hapi
Member Candidate
Member Candidate
Posts: 223
Joined: Fri Mar 11, 2011 11:21 am
Location: Czech Republic

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Oct 04, 2017 6:46 pm

Another sfp modul, also no tx power, why? Will be fixed?
[admin@BS568] > interface ethernet monitor sfp-sfpplus1 
                    name: sfp-sfpplus1
                  status: link-ok
        auto-negotiation: disabled
                    rate: 1Gbps
             full-duplex: yes
         tx-flow-control: yes
         rx-flow-control: yes
      sfp-module-present: yes
             sfp-rx-loss: no
            sfp-tx-fault: no
                sfp-type: SFP-or-SFP+
      sfp-connector-type: LC
     sfp-link-length-9um: 3000m
         sfp-vendor-name: UBNT
  sfp-vendor-part-number: UF-SM-1G-S
       sfp-vendor-serial: FT17012008409
  sfp-manufacturing-date: 17-01-12
          sfp-wavelength: 1550.32nm
         sfp-temperature: 39C
      sfp-supply-voltage: 3.263V
     sfp-tx-bias-current: 19mA
            sfp-rx-power: -7.271dBm
         eeprom-checksum: good
                  eeprom: 0000: 03 04 07 00 00 00 40 00  00 00 00 01 0d 00 03 1e  ......@. ........
                          0010: 00 00 00 00 55 42 4e 54  20 20 20 20 20 20 20 20  ....UBNT         
                          0020: 20 20 20 20 00 00 00 00  55 46 2d 53 4d 2d 31 47      .... UF-SM-1G
                          0030: 2d 53 20 20 20 20 20 20  20 20 20 20 06 0e 20 37  -S           .. 7
                          0040: 20 0a 00 00 46 54 31 37  30 31 32 30 30 38 34 30   ...FT17 01200840
                          0050: 39 20 20 20 31 37 30 31  31 32 00 00 68 90 01 79  9   1701 12..h..y
                          0060: 20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20                   
                          0070: 20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20                   
                          0080: 5a 00 d3 00 55 00 d8 00  94 70 69 78 90 88 6d 60  Z...U... .pix..m`
                          0090: c3 50 00 00 af c8 00 32  18 a6 03 e8 13 94 04 eb  .P.....2 ........
                          00a0: 27 10 00 28 1f 07 00 32  00 00 00 00 00 00 00 00  '..(...2 ........
                          00b0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ........ ........
                          00c0: 00 00 00 00 3f 80 00 00  00 00 00 00 01 00 00 00  ....?... ........
                          00d0: 01 00 00 00 01 00 00 00  01 00 00 00 00 00 00 99  ........ ........
                          00e0: 27 c3 7f 78 25 76 0a 81  09 cd 00 00 00 00 22 00  '..x%v.. ......".
                          00f0: 00 40 00 00 00 40 00 00  00 00 00 ff ff ff ff 00  .@...@.. ........
 
User avatar
bajodel
Long time Member
Long time Member
Posts: 545
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Oct 04, 2017 9:25 pm

..cut.. SFP transceiver, why do you have auto-negotiation disabled and what is connected to opposite side? Have you tried to turn auto-negotiation=on?
On RB3011 sfp to a CRS326-24G-2S+ via DAC cable doesn't work if you set auto-negotiation , furthermore the RB3011 doesn't detect if link go down (CRS instead correctly detects it).
All this on latest rc but also in previous 6.41rc and also 6.40.3/4
 
JimmyNyholm
Member Candidate
Member Candidate
Posts: 249
Joined: Mon Apr 25, 2016 2:16 am
Location: Sweden

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Oct 05, 2017 2:07 pm

Is it me or how do I search for learned mac-addresses with this new bridge implementation. Host table is almost always empty but local mac's but everything works.
This has been the same all this 41rc branch....

Is there a way to increase timeout on learning ( I have also asked for the option to disable learning or limit number of addresses learned.)

EDIT: Found all macs in /interfaces ethernet switch host

In this new implementation shouldn't these to tables be the same /bridge host and /interface ethernet switch host ???
 
JimmyNyholm
Member Candidate
Member Candidate
Posts: 249
Joined: Mon Apr 25, 2016 2:16 am
Location: Sweden

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Oct 06, 2017 10:25 am

In ROS this 6.41rc (38) branch with new bridge implementation with (H)ard ware flag. if I want to use switch chip's filter function.
is this rules applied to (I want the Silicon Hardware ones...)

/interface/bridge/filter
or
/interface/ethernet/switch/rule

Am I right to believe that the switch menu will go away completely and all stuff there will be moved/added to bridge menu. My concern is where we currently stand?
 
pe1chl
Forum Guru
Forum Guru
Posts: 5834
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Oct 06, 2017 12:33 pm

I am a bit lost on the direction and state of the new bridge implementation...
I use the switch on (mostly RB2011) routers fully configured with VLAN tagging, and with VLAN subinterfaces on the CPU port, like this:
/interface ethernet
set [ find default-name=ether3 ] master-port=ether2
set [ find default-name=ether4 ] master-port=ether2
set [ find default-name=ether5 ] master-port=ether2

/interface vlan
add interface=ether2 name=ether2.vlan12 vlan-id=12
add interface=ether2 name=ether2.vlan19 vlan-id=19
add interface=ether2 name=ether2.vlan20 vlan-id=20
add interface=ether2 name=ether2.vlan24 vlan-id=24
add interface=ether2 name=ether2.vlan44 vlan-id=44
add interface=ether2 name=ether2.vlan58 vlan-id=58

/interface ethernet switch port
set 2 vlan-mode=secure
set 3 vlan-mode=secure
set 4 default-vlan-id=58 vlan-header=always-strip vlan-mode=secure
set 5 default-vlan-id=58 vlan-header=always-strip vlan-mode=secure

/interface ethernet switch vlan
add independent-learning=no ports=switch1-cpu,ether2,ether3  switch=switch1 vlan-id=44
add independent-learning=no ports=switch1-cpu,ether2,ether3,ether4,ether5 switch=switch1 vlan-id=58
add independent-learning=no ports=switch1-cpu,ether2 switch=switch1 vlan-id=20
add independent-learning=no ports=switch1-cpu,ether3 switch=switch1 vlan-id=19
add independent-learning=no ports=switch1-cpu,ether3 switch=switch1 vlan-id=12
add independent-learning=no ports=switch1-cpu,ether2 switch=switch1 vlan-id=24
What is the current state of the "switch to bridge" migration in 6.41rc? Is it going to convert such a configuration properly
and will it still work the same way? I.e. with hardware switching between the ports on tagged and untagged VLANs even
when some ports are tagged and others untagged in the same VLAN? And will it still drop traffic from VLAN tags not
configured for that port?
 
Denkinger
just joined
Posts: 1
Joined: Sun Oct 08, 2017 12:17 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sun Oct 08, 2017 12:24 am

After upgrade to 6.41RC38, WAP R-2nD processor 100%, self nonstop reboot the system. I used Netinstall to run it.
The others Roterboard are work ok
Good evening,

Same problem here...
And I think router os runs a little bit slow on that device.
 
C3H5N3O9
just joined
Posts: 2
Joined: Tue Oct 03, 2017 1:16 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sun Oct 08, 2017 10:49 pm

Can't use proxy-arp fonctionality on bridge with new bridge implementation in 6.41rc, in fact, when we try to use ppptp tunnel with proxy-arp on bridge, host behind tunnel on lan can't ping. After a downgrade in 6.40.4 everything work well.
 
poizzon
Member Candidate
Member Candidate
Posts: 113
Joined: Fri Jun 21, 2013 12:53 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sun Oct 08, 2017 11:59 pm

Hello, after upgrading RBwAPR-2nD & R11e-LTE to version 6.41rc38, I received a critical error after which the router has been permanently rebooting.

if you want a relative version older than that, you need to log in with a static IP address, quickly roll over the main package, and quickly downgrade, or use netsintall


p.s. firmware version : 3.39.

Does upgrade to firmware up to version 3.41, does the RC start up normally?
--
poi
 
ivicask
Member Candidate
Member Candidate
Posts: 234
Joined: Tue Jul 07, 2015 2:40 pm
Location: Croatia, Zagreb

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Oct 09, 2017 10:18 am

Hello, after upgrading RBwAPR-2nD & R11e-LTE to version 6.41rc38, I received a critical error after which the router has been permanently rebooting.

if you want a relative version older than that, you need to log in with a static IP address, quickly roll over the main package, and quickly downgrade, or use netsintall


p.s. firmware version : 3.39.

Does upgrade to firmware up to version 3.41, does the RC start up normally?
Can confirm this, same new WAP LTE constant reboots, Critical process died, etc in logs, works fine with older version.
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1407
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Oct 11, 2017 12:35 pm

What's new in 6.41rc44 (2017-Oct-11 08:21):

Important note!!! Backup before upgrade!
RouterOS (v6.40rc36-rc40 and) v6.41rc1+ contains new bridge implementation that supports hardware offloading (hw-offload).
This update will convert all interface "master-port" configuration into new bridge configuration, and eliminate "master-port" option as such.
Bridge will handle all Layer2 forwarding and the use of switch-chip (hw-offload) will be automatically turned on based on appropriate conditions.
The rest of RouterOS Switch specific configuration remains untouched in usual menus for now.
Please, note that downgrading to previous RouterOS versions will not restore "master-port" configuration, so use backups to restore configuration on downgrade.


Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;
2) Make sure the device will not lose power during upgrade process;
3) Device has enough free storage space for all RouterOS packages to be downloaded.

Changes since previous 6.41rc release:

!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
*) bridge - added comment support for VLANs;
*) bridge - added support for "/interface list" as a bridge port;
*) crs317 - added initial support for HW offloaded MPLS forwarding;
*) crs3xx - fixed 100% CPU usage after interface related changes (introduced in v6.41rc31);
*) dhcpv4-client - add dynamic DHCP client for mobile clients which require it;
*) fetch - accept all HTTP 2xx status codes;
*) firewall - do not NAT address to 0.0.0.0 after reboot if to-address is used but not specified;
*) ike1 - fixed RSA authentication for Windows clients behind NAT;
*) interface - added default "/interface list" "dynamic" which contains dynamic interfaces;
*) interface - added option to join and exclude "/interface list" from one and another;
*) ipsec - added DH groups 19, 20 and 21 support for phase1 and phase2;
*) ipsec - fixed lost value for "remote-certificate" parameter after disable/enable;
*) ipsec - fixed policy enable/disable;
*) ipsec - improved reliability on certificate usage;
*) ipsec - skip invalid policies for phase2;
*) l2tp - improved reliability on packet processing in FastPath;
*) log - fixed interface name in log messages;
*) log - properly recognize MikroTik specific RADIUS attributes;
*) lte - added "/interface lte apn" menu (Passthrough requires reconfiguration);
*) lte - added Passthrough support (CLI only);
*) lte - fixed modem initialization after reboot;
*) lte - limited minimal default route distance to 1;
*) mac-server - use "/interface list" instead of interface name under MAC server settings;
*) neighbor - show neighbors on actual bridge port instead of bridge itself
*) sms - include timestamps in SMS delivery reports;
*) sms - properly initialize SMS storage;
*) snmp - show only available OIDs under "/system health print oid";
*) winbox - allow shorten bytes to k,M,G in Hotspot user limits;
*) winbox - do not show duplicate "Switch" menus for CRS326;
*) winbox - fixed "/certificate sign" process;
*) wireless - added "allow-signal-out-off-range" option for Access List entries;

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after crash.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5834
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Oct 11, 2017 2:18 pm

What's new in 6.41rc44 (2017-Oct-11 08:21):
RouterOS (v6.40rc36-rc40 and) v6.41rc1+ contains new bridge implementation that supports hardware offloading (hw-offload).
This update will convert all interface "master-port" configuration into new bridge configuration, and eliminate "master-port" option as such.
What about configurations like mentioned in posting #275 in this topic? Are they supported now?
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Oct 11, 2017 2:45 pm

Fairly in depth post, to highlight a few things (community and strods correct me if I'm wrong).

The independent learning = no option doesn't exist anymore. You're going to get independent MAC databases per VLAN. I'm curious as to why you weren't doing that before, was it a hardware limitation?

Frame tagging exists in the implementation:
/interface bridge port set 0 frame-types=
FrameTypes ::= admit-all | admit-only-untagged-and-priority-tagged | admit-only-vlan-tagged
I'd argue that setting a PVID and "admit-only-untagged-and-priority-tagged" is better than VLAN mode secure and always-strip.

The rest of the configuration is just basic VLAN configuration which is well supported.

The only two points I personally can't speak for is how well the automatic conversion will go during the upgrade and the state of each of those features on the RB2011. I don't own that hardware.

Personally, I'd make sure I have a back-door after the upgrade. Maybe take a port out of the "switch-chip" by removing master-port and set it up as a routed interface that you can plug a laptop into and easily get access to the device. This also could be a WAN port, allow SSH to the device from your home or another office's IP so you can hop in that way if needed (or leave it open by src IP and use a good password / ssh key and come in via a mobile hotspot or starbucks). This would allow you to tweak the bridge config as needed.
 
User avatar
Cha0s
Forum Veteran
Forum Veteran
Posts: 903
Joined: Tue Oct 11, 2005 4:53 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Oct 11, 2017 3:36 pm

!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
Is this feature feature optional if someone does not want their router to contact cloud.mikrotik.com every minute?

Is it just cosmetic (ie: "this interface is 'WAN' just FYI") or is it actually used somewhere (ie: in firewall rules as an interface list) ?

Does in any way affect the functionality of other features in ROS?
 
eriitguy
Member Candidate
Member Candidate
Posts: 197
Joined: Thu Jan 26, 2017 1:16 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Oct 11, 2017 3:44 pm

!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
Is this feature feature optional if someone does not want their router to contact cloud.mikrotik.com every minute?

Is it just cosmetic (ie: "this interface is 'WAN' just FYI") or is it actually used somewhere (ie: in firewall rules as an interface list) ?

Does in any way affect the functionality of other features in ROS?
Specifying our own host instead of 8.8.8.8 and cloud.mikrotik.com, may be usefully in the future.


Thank you!
 
andriys
Forum Guru
Forum Guru
Posts: 1180
Joined: Thu Nov 24, 2011 1:59 pm
Location: Kharkiv, Ukraine

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Oct 11, 2017 3:49 pm

Is it just cosmetic (ie: "this interface is 'WAN' just FYI") or is it actually used somewhere (ie: in firewall rules as an interface list) ?
My understanding is it will populate the interface lists you specify with the actual interfaces. Those lists can then be used in firewall filter, NAT, etc.

I'd also expect this feature to be used in the defconf, but we'd better wait for an official announcement.
 
User avatar
Cha0s
Forum Veteran
Forum Veteran
Posts: 903
Joined: Tue Oct 11, 2005 4:53 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Oct 11, 2017 3:51 pm

!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
Is this feature feature optional if someone does not want their router to contact cloud.mikrotik.com every minute?

Is it just cosmetic (ie: "this interface is 'WAN' just FYI") or is it actually used somewhere (ie: in firewall rules as an interface list) ?

Does in any way affect the functionality of other features in ROS?
Specifying our own host instead of 8.8.8.8 and cloud.mikrotik.com, may be usefully in the future.


Thank you!
Yes that would actually be cool IMHO.

I generally don't like features that 'call the vendor's home'. I prefer solutions that respect the user's privacy.
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Oct 11, 2017 4:05 pm

!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
Is the test IPv6 compliant. It needs to be. The address 8.8.8.8 is an IPv4 static, fail. The DNS name cloud.mikrotik.com only has an A record.

If you truly want to detect for Internet you need to use both IPv4 and IPv6 literals and a dual-stacked DNS name. We (the networking community) MUST NOT design features that are IPv4 only. The standards bodies have adopted an IPv6 first approach. I'm very sad to see this feature does not follow that stance. Some ISPs have already had to go to an IPv6 only design due to IPv4 exhaustion. Many others are doing layered IPv4 NAT (CGN) to provide psuedo IPv4 connectivity. (Look at the US cellular market). As a customer, this lack of market awareness is troubling. A feature that clearly targets home or small business routers should be IPv6 aware given the climate of connectivity.

As many forum members will likely state, this feature is of little value to them. It may find some play in the home router arena but even then it seems like overkill. I am curious as to how this test is valid. Packets sourced from my LAN IP all have access to 8.8.8.8 and cloud.mikrotik.com via the static default route and NAT rules. Does the special interface have coding that inspects the routing table?

All in all, seems like another case of MikroTik's roadmap being out of touch with actual customer needs. You don't drive sales by developing features that don't provide any value. You need to provide features that demonstrate how MikroTik routers can be used to develop solutions that create positive business outcomes. We can sell business outcomes to purchasers. Simplifying VLAN configuration and implementing RSTP and MSTP. Those are great examples of features that create value that can be translated into positive business outcomes.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5834
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Oct 11, 2017 4:33 pm

Is it just cosmetic (ie: "this interface is 'WAN' just FYI") or is it actually used somewhere (ie: in firewall rules as an interface list) ?
My understanding is it will populate the interface lists you specify with the actual interfaces. Those lists can then be used in firewall filter, NAT, etc.

I'd also expect this feature to be used in the defconf, but we'd better wait for an official announcement.
The defconf already changed in version 6.40! It now uses the "WAN" interface list in the firewall instead of ether1.
 
jrpaz
Frequent Visitor
Frequent Visitor
Posts: 82
Joined: Wed Jun 05, 2013 5:54 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Oct 11, 2017 4:48 pm

The Novotel 730L is still unable to stay connected it constantly loses DHCP leases even after this release.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5834
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Oct 11, 2017 5:01 pm

Fairly in depth post, to highlight a few things (community and strods correct me if I'm wrong).

The independent learning = no option doesn't exist anymore. You're going to get independent MAC databases per VLAN. I'm curious as to why you weren't doing that before, was it a hardware limitation?
Well that setting is not so important, I think. I probably unchecked it once because it would be like the switches I am accustomed with, and then just copied the same setting over and over.
Frame tagging exists in the implementation:
/interface bridge port set 0 frame-types=
FrameTypes ::= admit-all | admit-only-untagged-and-priority-tagged | admit-only-vlan-tagged
I'd argue that setting a PVID and "admit-only-untagged-and-priority-tagged" is better than VLAN mode secure and always-strip.

The rest of the configuration is just basic VLAN configuration which is well supported.
Are you sure? I do not yet see the option to restrict certain tagged VLANs to certain ports. And what about tagging untagged frames with a certain VLAN tag?
My config does not use the untagged VLAN at the CPU port, but it does have untagged external ports. Those have to be in some VLAN.
Now, the switch easily manages that with the default-vlan-id=xx vlan-header=always-strip setting, but can the bridge do the same thing? And will it
be hardware accellerated? (I do not want traffic between an untagged port and the tagged VLAN with the same ID on another port to be CPU-bridged)
The only two points I personally can't speak for is how well the automatic conversion will go during the upgrade and the state of each of those features on the RB2011. I don't own that hardware.
Well it hopefully will not be very different between models that have a switch chip so I could do some experiments on a RB750.
Personally, I'd make sure I have a back-door after the upgrade. Maybe take a port out of the "switch-chip" by removing master-port and set it up as a routed interface that you can plug a laptop into and easily get access to the device.
Normally there is a local network with DHCP service on port 10 for emergency maintenance and of course these routers also have a serial port, but unfortunately they are located on sites all over the country that have limited access. We will clearly have to be very careful when updating to 6.41
 
Zaffo
just joined
Posts: 3
Joined: Tue Jun 27, 2017 7:52 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Oct 11, 2017 5:05 pm

After an upgrade from the previous rc38 to v6.41rc44 my mAP lite crashes when the ethernet cable is plugged in. First log entry after unplugging the cable states "router rebooted because some critical program crashed". Device is configured as a pocket router/AP and has one L2TP/IPsec and two ovpn clients.

After disabling the PPP clients I can connect ether1 without problems. When I now enable either one of the ovpn clients the device crashes some time after the connection is established. The L2TP/IPsec client gives no problem.
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1407
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Oct 11, 2017 5:13 pm

As for detect-interface feature. Please take a look at wiki page which was provided in changelog:
https://wiki.mikrotik.com/wiki/Manual:D ... figuration

"detect-interface-list (interface list; Default: none) All interfaces in the list will be monitored by Detect Internet"

As you can see - default value is none
 
R1CH
Forum Veteran
Forum Veteran
Posts: 898
Joined: Sun Oct 01, 2006 11:44 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Oct 11, 2017 5:18 pm

!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
Is this feature feature optional if someone does not want their router to contact cloud.mikrotik.com every minute?

Is it just cosmetic (ie: "this interface is 'WAN' just FYI") or is it actually used somewhere (ie: in firewall rules as an interface list) ?

Does in any way affect the functionality of other features in ROS?
Specifying our own host instead of 8.8.8.8 and cloud.mikrotik.com, may be usefully in the future.


Thank you!
Changing the hosts is not just useful, it's a requirement. Just imagine, you can DDoS cloud.mikrotik.com and every router using this feature goes offline!
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8310
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Oct 11, 2017 5:28 pm

Just imagine, you can DDoS cloud.mikrotik.com and every router using this feature goes offline!
ports still will be 'WAN', so nothing terrible should happen :)
Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

For every complex problem, there is a solution that is simple, neat, and wrong.

MikroTik. Your life. Your routing.
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Oct 11, 2017 6:00 pm

Just imagine, you can DDoS cloud.mikrotik.com and every router using this feature goes offline!
ports still will be 'WAN', so nothing terrible should happen :)
Opposite, inject a route to 8.8.8.8 into a dynamic protocol running on someones environment that relies on this feature. It'll toggle the interface to WAN, apply security policies, likely dropping all traffic until detect-interface flaps back to LAN. Then it flaps to WAN when it relearns the route and flap and flap and flap.

Dumb feature.

It's like VTP, was great on the drawing board and then it was used to wipe peoples VLAN databases. It took a few years but now Cisco disavows that feature.
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Oct 11, 2017 6:12 pm

Fairly in depth post, to highlight a few things (community and strods correct me if I'm wrong).

The independent learning = no option doesn't exist anymore. You're going to get independent MAC databases per VLAN. I'm curious as to why you weren't doing that before, was it a hardware limitation?
Well that setting is not so important, I think. I probably unchecked it once because it would be like the switches I am accustomed with, and then just copied the same setting over and over.
Frame tagging exists in the implementation:
/interface bridge port set 0 frame-types=
FrameTypes ::= admit-all | admit-only-untagged-and-priority-tagged | admit-only-vlan-tagged
I'd argue that setting a PVID and "admit-only-untagged-and-priority-tagged" is better than VLAN mode secure and always-strip.

The rest of the configuration is just basic VLAN configuration which is well supported.
Are you sure? I do not yet see the option to restrict certain tagged VLANs to certain ports. And what about tagging untagged frames with a certain VLAN tag?
My config does not use the untagged VLAN at the CPU port, but it does have untagged external ports. Those have to be in some VLAN.
Now, the switch easily manages that with the default-vlan-id=xx vlan-header=always-strip setting, but can the bridge do the same thing? And will it
be hardware accellerated? (I do not want traffic between an untagged port and the tagged VLAN with the same ID on another port to be CPU-bridged)
The only two points I personally can't speak for is how well the automatic conversion will go during the upgrade and the state of each of those features on the RB2011. I don't own that hardware.
Well it hopefully will not be very different between models that have a switch chip so I could do some experiments on a RB750.
Personally, I'd make sure I have a back-door after the upgrade. Maybe take a port out of the "switch-chip" by removing master-port and set it up as a routed interface that you can plug a laptop into and easily get access to the device.
Normally there is a local network with DHCP service on port 10 for emergency maintenance and of course these routers also have a serial port, but unfortunately they are located on sites all over the country that have limited access. We will clearly have to be very careful when updating to 6.41
PVID = Default VLAN (Primary VLAN ID).

So you can accomplish an untagged port by changing the PVID of a bridge port to whatever VLAN ID you need. You also have the /interface bridge vlan table. In that table you specify which ports have a VLAN tagged or untagged. So like secure mode, you set admit-only-tagged-frames and then only add that bridge port to the VLANs tagged lists that you want.

As far as the acceleration goes, it is model dependent. The goal is to manage hardware offload based on the switch chips available features. I got that answer from MikroTik support. The translation is that if it can do it now in the switch chip it should do it in the future with HW offload on dynamically. How long it takes to get to that state for all models, well time will tell.

The master-port option is removed so you can't really use the old configurations. MikroTik has been tight lipped about which switch chips it has enabled HW offload for. None of my test gear (hex, wap ac and cap lite) are setup in a way that I'm seeing HW offload actually turned on yet for the Ethernet ports. That said I can still pull over 300mbps across VLANs on my hex. InterVLAN routing was and always will be CPU bound and I don't really have much traffic that hits the bridges, I used software bridges in the past because the switch chip in the hex is basically a single flat layer 2 domain (no vlans).

Without meaningful release notes that tell us when each switch chip is enabled for HW offload the only thing we know is that they are developing off of CRS3xx in house. The best thing might be to target a single location that uses a RB2011 or setup a lab RB2011 and monitor the RCs progress for your particular set of options so you know when that happens or cool your heals until 6.41 goes GA.
 
lukoramu
just joined
Posts: 18
Joined: Mon Jan 07, 2013 11:11 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Oct 11, 2017 6:19 pm

Just imagine, you can DDoS cloud.mikrotik.com and every router using this feature goes offline!
ports still will be 'WAN', so nothing terrible should happen :)
Opposite, inject a route to 8.8.8.8 into a dynamic protocol running on someones environment that relies on this feature. It'll toggle the interface to WAN, apply security policies, likely dropping all traffic until detect-interface flaps back to LAN. Then it flaps to WAN when it relearns the route and flap and flap and flap.

Dumb feature.

It's like VTP, was great on the drawing board and then it was used to wipe peoples VLAN databases. It took a few years but now Cisco disavows that feature.
Hmm.. Why do you guys think that "detect-internet" feature will do ANY of that?...
What I'm getting from wiki page, it's just an informational feature: you type
/interface detect-internet state
and you get some info, that this feature gathered..
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Oct 11, 2017 6:31 pm

Just imagine, you can DDoS cloud.mikrotik.com and every router using this feature goes offline!
ports still will be 'WAN', so nothing terrible should happen :)
Opposite, inject a route to 8.8.8.8 into a dynamic protocol running on someones environment that relies on this feature. It'll toggle the interface to WAN, apply security policies, likely dropping all traffic until detect-interface flaps back to LAN. Then it flaps to WAN when it relearns the route and flap and flap and flap.

Dumb feature.

It's like VTP, was great on the drawing board and then it was used to wipe peoples VLAN databases. It took a few years but now Cisco disavows that feature.
Hmm.. Why do you guys think that "detect-internet" feature will do ANY of that?...
What I'm getting from wiki page, it's just an informational feature: you type
/interface detect-internet state
and you get some info, that this feature gathered..
The magic is in the other settings:
[admin@211-rtr1] > interface detect-internet set 
Change properties of one or several items.

detect-interface-list -- 
internet-interface-list -- 
lan-interface-list -- 
wan-interface-list -- 
If you see the wiki the lists is what does the work, set Internet interface list to something like WAN, add all interfaces to the detect-interface-list and boom you have a problem. If the LAN interface is detected to be a WAN interface it can then be elevated to an Internet interface. I'd have to setup a lab but I'd imagine it's possible to do the necessary spoofing just with routing.
 
andriys
Forum Guru
Forum Guru
Posts: 1180
Joined: Thu Nov 24, 2011 1:59 pm
Location: Kharkiv, Ukraine

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Oct 11, 2017 6:52 pm

Opposite, inject a route to 8.8.8.8 into a dynamic protocol running on someones environment that relies on this feature. It'll toggle the interface to WAN, apply security policies, likely dropping all traffic until detect-interface flaps back to LAN. Then it flaps to WAN when it relearns the route and flap and flap and flap.
My understanding is detect-internet is aimed to be used on home-users' routers, which are definitely not supposed to be running any of the dynamic routing protocols (and are not by default). Honestly, I don't see anything wrong with it. Much better to have all ports protected, and treat some of them as WAN-facing (and others as LAN-facing) when certain criteria is met, than exposing your router to the DNS amplification attacks by simply adding PPPoE interface without also modifying the existing (default) firewall rules (a common problem that multiple people complained about up until recently).
 
pe1chl
Forum Guru
Forum Guru
Posts: 5834
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Oct 11, 2017 7:20 pm

PVID = Default VLAN (Primary VLAN ID).

So you can accomplish an untagged port by changing the PVID of a bridge port to whatever VLAN ID you need. You also have the /interface bridge vlan table. In that table you specify which ports have a VLAN tagged or untagged. So like secure mode, you set admit-only-tagged-frames and then only add that bridge port to the VLANs tagged lists that you want.
Ok, that sounds good. From earlier discussion I got the impression that from now on the bridge would be one big VLAN-transparent thing, whereas in my existing practice (not the above example) I would normally put VLAN subinterfaces on ports and make the subinterfaces part of a bridge, rather than putting entire ports in the bridge and adding VLAN subinterfaces to the bridge.
However, with detailed VLAN configuration for bridge ports that could be a good solution.

I think I'll have to experiment with converting some setups on a test router...
 
pe1chl
Forum Guru
Forum Guru
Posts: 5834
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Oct 11, 2017 10:27 pm

!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
I enabled the detection for "all" interfaces on a CHR test system that has 2 ethernet interfaces that both have internet connectivity,
but their status remains at "wan" and does not go to "internet".
There are two default routes, one in the main table and one in an extra table which is selected by an IP route rule on the
source address of the second interface. Pinging 8.8.8.8 and cloud.mikrotik.com works fine.
I would have expected at least one of them to show "internet", maybe not both when this policy routing is not recognized yet.
 
boyko
just joined
Posts: 9
Joined: Sun Feb 05, 2017 1:59 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Oct 12, 2017 12:20 am

I just updated to the latest RC and the bridge conversion did not take in account the spoofed MAC address on the WAN port. I had to manually adjust that on the newly created bridge. This needs to be handled before the final release or people are going to have issues with it.
 
ShturmN
just joined
Posts: 1
Joined: Thu Oct 12, 2017 2:49 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Oct 12, 2017 3:00 am

I'm update to 6.41rc44 my sxt 5 and now:
https://s.mail.ru/6XPP/7BwY2UJm3
 
pe1chl
Forum Guru
Forum Guru
Posts: 5834
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Oct 12, 2017 10:16 am

!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
I enabled the detection for "all" interfaces on a CHR test system that has 2 ethernet interfaces
Another issue: although the interfaces have been setup with static addresses, after enabling this feature
the router is sending DHCP requests at a rate of 1 per second.
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8310
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Oct 12, 2017 11:06 am

Opposite, inject a route to 8.8.8.8 into a dynamic protocol running on someones environment that relies on this feature. It'll toggle the interface to WAN, apply security policies, likely dropping all traffic until detect-interface flaps back to LAN. Then it flaps to WAN when it relearns the route and flap and flap and flap.
so, some peering partner injects a route to block himself? it's either bad or dumb peering partner :)
Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

For every complex problem, there is a solution that is simple, neat, and wrong.

MikroTik. Your life. Your routing.
 
whitbread
Member Candidate
Member Candidate
Posts: 108
Joined: Fri Nov 08, 2013 9:55 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Oct 12, 2017 2:52 pm

I am stuck with new bridge implementation using VLAN's either. What I want to accomplish is to pass tagged traffic through the router while reaching the router through the same VLAN.
I am using RB2011's and a RB951G with v.6.41RC44.
R1 is connected via cable to R2. R2 is connected via wireless bridge to R3. I need connection from R1 to R2 on VLAN's 3 and 1013 and from R1 to R3 on VLAN's 3 and 1002.

R3 is configured as station bridge with VLAN's 3 and 1002. Both VLAN's are terminated with IP-Adresses at R3.
/interface vlan
add interface="WLAN1" name="WLAN1 VLAN1002" vlan-id=1002
add interface="WLAN1" name="WLAN1 VLAN3" vlan-id=3
/ip address
add address=192.168.88.3/24 interface="WLAN1 VLAN1002" network=192.168.88.0
add address=192.168.3.3/24 interface="WLAN1 VLAN3" network=192.168.3.0

I can connect to both VLAN's from R1 but not from R2.

R1 is configured the same way using VLAN-interfaces.
/interface vlan
add interface="P05  Trunk R2" name="P05 R2 VLAN3" vlan-id=3
add interface="P05  Trunk R2" name="P05 R2 VLAN1002" vlan-id=1002
add interface="P05  Trunk R2" name="P05 R2 VLAN1013" vlan-id=1013
/ip address
add address=192.168.88.1/24 interface="P05 R2 VLAN1002" network=192.168.88.0
add address=192.168.89.1/24 interface="P05 R2 VLAN1013" network=192.168.89.0
add address=192.168.3.1/24 interface="P05 R2 VLAN3" network=192.168.3.0
I can connect R3 from R1 on both VLAN's. Connection to R2 works only on VLAN1013 as this interface is not part of the bridge. VLAN1002 has no IP on R2.

R2 is where I get stuck. I am trying to use a single bridge on this one as I am into using R2 as a CAP with local forwarding. So no parent VLAN interfaces will be possible.
Actually forwarding tagged traffic through R2 and connection to a Client physically connected to R2 (VLAN3) works fine.

But how do I reach R2 itself on VLAN3 ?

<1> If I use VLAN interfaces on Trunk port and bridge VLAN inferface I can not connect.
/interface vlan
add interface="P2  Trunk R1" name="P2 R1 VLAN1002" vlan-id=1002
add interface="P2  Trunk R1" name="P2 R1 VLAN1013" vlan-id=1013
add interface="P2  Trunk R1" name="P2 R1 VLAN3" vlan-id=3
/interface bridge
add fast-forward=no igmp-snooping=no name="Bridge one4all" protocol-mode=none vlan-filtering=yes
/interface bridge port
add bridge="Bridge one4all" ingress-filtering=yes interface="P3" pvid=3
add bridge="Bridge one4all" interface="WLAN2 AP" pvid=3
add bridge="Bridge one4all" frame-types=admit-only-vlan-tagged interface="WLAN3  Bridge"
add bridge="Bridge one4all" interface="P2 R1 VLAN1002" pvid=1002
add bridge="Bridge one4all" interface="P2 R1 VLAN3" pvid=3
/interface bridge vlan
add bridge="Bridge one4all" tagged="WLAN3  Bridge" vlan-ids=3
add bridge="Bridge one4all" tagged="WLAN3  Bridge" vlan-ids=1002
/ip address
add address=192.168.89.2/24 interface="P2 R1 VLAN1013" network=192.168.89.0
add address=192.168.3.2/24 interface="P2 R1 VLAN3" network=192.168.3.0
<2> I tried it without VLAN inferfaces but I don't see any possibility to reach R2 then.
/interface vlan
add interface="P2  Trunk R1" name="P2 R1 VLAN1013" vlan-id=1013
/interface bridge
add fast-forward=no igmp-snooping=no name="Bridge one4all" protocol-mode=none vlan-filtering=yes
/interface bridge port
add bridge="Bridge one4all" frame-types=admit-only-vlan-tagged ingress-filtering=yes interface="P2  Trunk R1"
add bridge="Bridge one4all" ingress-filtering=yes interface="P3" pvid=3
add bridge="Bridge one4all" interface="WLAN2 AP" pvid=3
add bridge="Bridge one4all" frame-types=admit-only-vlan-tagged interface="WLAN3  Bridge"
/interface bridge vlan
add bridge="Bridge one4all" tagged="WLAN3  Bridge,P2  Trunk R1" vlan-ids=3
add bridge="Bridge one4all" tagged="WLAN3  Bridge,P2  Trunk R1" vlan-ids=1002
Either way I can connect to R3 on both VLAN's and to a Client physically connected to R2 (VLAN3).
R2 is reachable on VLAN1013, but this interface is not part of the bridge.

How can I reach R2 via VLAN3?!?

Any help is highly appreciated. 8)
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Oct 13, 2017 1:32 am

I am stuck with new bridge implementation using VLAN's either. What I want to accomplish is to pass tagged traffic through the router while reaching the router through the same VLAN.
I am using RB2011's and a RB951G with v.6.41RC44.
R1 is connected via cable to R2. R2 is connected via wireless bridge to R3. I need connection from R1 to R2 on VLAN's 3 and 1013 and from R1 to R3 on VLAN's 3 and 1002.

R3 is configured as station bridge with VLAN's 3 and 1002. Both VLAN's are terminated with IP-Adresses at R3.
/interface vlan
add interface="WLAN1" name="WLAN1 VLAN1002" vlan-id=1002
add interface="WLAN1" name="WLAN1 VLAN3" vlan-id=3
/ip address
add address=192.168.88.3/24 interface="WLAN1 VLAN1002" network=192.168.88.0
add address=192.168.3.3/24 interface="WLAN1 VLAN3" network=192.168.3.0

I can connect to both VLAN's from R1 but not from R2.

R1 is configured the same way using VLAN-interfaces.
/interface vlan
add interface="P05  Trunk R2" name="P05 R2 VLAN3" vlan-id=3
add interface="P05  Trunk R2" name="P05 R2 VLAN1002" vlan-id=1002
add interface="P05  Trunk R2" name="P05 R2 VLAN1013" vlan-id=1013
/ip address
add address=192.168.88.1/24 interface="P05 R2 VLAN1002" network=192.168.88.0
add address=192.168.89.1/24 interface="P05 R2 VLAN1013" network=192.168.89.0
add address=192.168.3.1/24 interface="P05 R2 VLAN3" network=192.168.3.0
I can connect R3 from R1 on both VLAN's. Connection to R2 works only on VLAN1013 as this interface is not part of the bridge. VLAN1002 has no IP on R2.

R2 is where I get stuck. I am trying to use a single bridge on this one as I am into using R2 as a CAP with local forwarding. So no parent VLAN interfaces will be possible.
Actually forwarding tagged traffic through R2 and connection to a Client physically connected to R2 (VLAN3) works fine.

But how do I reach R2 itself on VLAN3 ?

<1> If I use VLAN interfaces on Trunk port and bridge VLAN inferface I can not connect.
/interface vlan
add interface="P2  Trunk R1" name="P2 R1 VLAN1002" vlan-id=1002
add interface="P2  Trunk R1" name="P2 R1 VLAN1013" vlan-id=1013
add interface="P2  Trunk R1" name="P2 R1 VLAN3" vlan-id=3
/interface bridge
add fast-forward=no igmp-snooping=no name="Bridge one4all" protocol-mode=none vlan-filtering=yes
/interface bridge port
add bridge="Bridge one4all" ingress-filtering=yes interface="P3" pvid=3
add bridge="Bridge one4all" interface="WLAN2 AP" pvid=3
add bridge="Bridge one4all" frame-types=admit-only-vlan-tagged interface="WLAN3  Bridge"
add bridge="Bridge one4all" interface="P2 R1 VLAN1002" pvid=1002
add bridge="Bridge one4all" interface="P2 R1 VLAN3" pvid=3
/interface bridge vlan
add bridge="Bridge one4all" tagged="WLAN3  Bridge" vlan-ids=3
add bridge="Bridge one4all" tagged="WLAN3  Bridge" vlan-ids=1002
/ip address
add address=192.168.89.2/24 interface="P2 R1 VLAN1013" network=192.168.89.0
add address=192.168.3.2/24 interface="P2 R1 VLAN3" network=192.168.3.0
<2> I tried it without VLAN inferfaces but I don't see any possibility to reach R2 then.
/interface vlan
add interface="P2  Trunk R1" name="P2 R1 VLAN1013" vlan-id=1013
/interface bridge
add fast-forward=no igmp-snooping=no name="Bridge one4all" protocol-mode=none vlan-filtering=yes
/interface bridge port
add bridge="Bridge one4all" frame-types=admit-only-vlan-tagged ingress-filtering=yes interface="P2  Trunk R1"
add bridge="Bridge one4all" ingress-filtering=yes interface="P3" pvid=3
add bridge="Bridge one4all" interface="WLAN2 AP" pvid=3
add bridge="Bridge one4all" frame-types=admit-only-vlan-tagged interface="WLAN3  Bridge"
/interface bridge vlan
add bridge="Bridge one4all" tagged="WLAN3  Bridge,P2  Trunk R1" vlan-ids=3
add bridge="Bridge one4all" tagged="WLAN3  Bridge,P2  Trunk R1" vlan-ids=1002
Either way I can connect to R3 on both VLAN's and to a Client physically connected to R2 (VLAN3).
R2 is reachable on VLAN1013, but this interface is not part of the bridge.

How can I reach R2 via VLAN3?!?

Any help is highly appreciated. 8)
Long story short, read the bridge wiki page.

You need to tag the VLANs on the bridge itself in /int bridge vlan and the VLAN interfaces need to have the interface property set to the bridge in question not some random Ethernet interface.
 
whitbread
Member Candidate
Member Candidate
Posts: 108
Joined: Fri Nov 08, 2013 9:55 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Oct 13, 2017 11:06 am

Oh boy - you are right: RTFM!
The bridge itself is kind of an interface. Now everything works.

But I am still curious if I choose the correct way to work with untagged i.e. PVID1-traffic. Both trunk ports have PVID1. The whole configuration works only if I set both trunk ports as tagged in bridge vlan setting for PVID1.
As soon as I set both trunk ports as untagged in bridge vlan settings for PVID1 no connection is possible. This situation persists until I do a reboot or disable and enable the whole bridge. Is this meant to be like this?
 
User avatar
Gennadiy51
newbie
Posts: 26
Joined: Fri Nov 06, 2009 4:33 pm
Location: Moldova, Chisinau

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Oct 13, 2017 11:18 am

!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
I enabled the detection for "all" interfaces on a CHR test system that has 2 ethernet interfaces
Another issue: although the interfaces have been setup with static addresses, after enabling this feature
the router is sending DHCP requests at a rate of 1 per second.
I'm blocking the provider port, because of the high number of requests on the WAN port. The provider is very unhappy with this!
What should I do?
X86 (Intel 566 MHz Slot1), RB450G, RB493G, hAP ac lite, hAP ac^2, hAP ac, wAP ac.
 
blimbach
just joined
Posts: 11
Joined: Fri Mar 04, 2016 3:39 pm
Location: Hennef, Germany

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Oct 13, 2017 12:34 pm

This Version is really bad on my hapac capsman:

oct/12/2017 17:11:40 system,error,critical router rebooted because some critical program crashed
oct/12/2017 17:41:47 system,error,critical router rebooted because some critical program crashed
oct/12/2017 17:52:04 system,error,critical router rebooted because some critical program crashed
oct/13/2017 06:56:57 system,error,critical router rebooted because some critical program crashed
oct/13/2017 07:01:37 system,error,critical router rebooted because some critical program crashed
oct/13/2017 07:20:52 system,error,critical router rebooted because some critical program crashed
oct/13/2017 07:24:24 system,error,critical router rebooted because some critical program crashed
oct/13/2017 07:37:33 system,error,critical router rebooted because some critical program crashed

<peep>.....<peep peep> every few minutes....

How to downgrade to an older rc? I cannot find a download-link.
 
kamillo
Member Candidate
Member Candidate
Posts: 155
Joined: Tue Jul 15, 2014 5:44 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Oct 13, 2017 1:13 pm

How to downgrade to an older rc? I cannot find a download-link.
Go to https://mikrotik.com/download

Grab a link to latest RC for your platform and edit url to the version you want.

https://download2.mikrotik.com/routeros/6.41rc38/routeros-mipsbe-6.41rc38.npk
 
blimbach
just joined
Posts: 11
Joined: Fri Mar 04, 2016 3:39 pm
Location: Hennef, Germany

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Oct 13, 2017 1:39 pm

Thank you, downgrading fixed the Problem to me.
 
jrpaz
Frequent Visitor
Frequent Visitor
Posts: 82
Joined: Wed Jun 05, 2013 5:54 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Oct 13, 2017 3:43 pm

Same issue with the RB750gr3 had to downgrade back #sad
 
User avatar
emils
MikroTik Support
MikroTik Support
Posts: 495
Joined: Thu Dec 11, 2014 8:53 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Oct 13, 2017 4:06 pm

If you experience critical program crashes or kernel panics on latest release candidate versions, please send supout.rif (autosupout.rif) files to support@mikrotik.com before downgrading.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5834
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Oct 13, 2017 5:36 pm

Another issue: although the interfaces have been setup with static addresses, after enabling this feature
the router is sending DHCP requests at a rate of 1 per second.
I'm blocking the provider port, because of the high number of requests on the WAN port. The provider is very unhappy with this!
What should I do?
I would advise keeping the detect-internet feature disabled until this problem is fixed.
For now it is only safe when your internet port obtains its address using DHCP. When the detect-internet sees
a DHCP reply it then remains quiet (probably for half the leasetime at least). But when there is no DHCP reply
it goes haywire.
 
whitbread
Member Candidate
Member Candidate
Posts: 108
Joined: Fri Nov 08, 2013 9:55 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Oct 13, 2017 6:36 pm

imho it is actually only good for a LAN router not for a router with direct uplink.

What I do like actually is that it gives information about the ports open via MAC. :D
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1407
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Oct 16, 2017 9:03 am

Version 6.41rc release includes fixes in WPA2 protocol:
viewtopic.php?f=21&t=126695
 
User avatar
alkar
just joined
Posts: 3
Joined: Sat Jul 04, 2015 8:29 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Oct 16, 2017 1:27 pm

Hi,
when v6.41rc will be as "current" ?
We bought 2 x CRS317-1G-16S+RM and couldn't set up harware vlan via winbox.
It is difficult to manage hundreds of vlans in a text teminal.
 
andriys
Forum Guru
Forum Guru
Posts: 1180
Joined: Thu Nov 24, 2011 1:59 pm
Location: Kharkiv, Ukraine

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Oct 16, 2017 3:02 pm

when v6.41rc will be as "current" ?
We bought 2 x CRS317-1G-16S+RM and couldn't set up harware vlan via winbox.
Based on experience with some previous RouterOS versions, I'd say that hitting the Current update channel and receiving WinBox support for some options are two unrelated things. It's possible that 6.41 becomes current with these options still being CLI-only.

I'm wondering though, what stops you from staying on 6.40.x or 6.39.x and configuring what you need in a "traditional" way?
 
Kubuxu
just joined
Posts: 2
Joined: Sat Sep 24, 2016 10:07 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Oct 16, 2017 3:18 pm

Hi,
I am trying to set up VLAN bridge for upstream and access to the router on RB3011 running 6.41rc44 but also offload the switching to the hardware switch.
I am able to successfully do one or the other but if I combine both setups for local pings I get 3 DUPs.

Setup in question:
Main router: 3011 running 6.41.rc44 with PPPoE upstream. For simplicity two LAN ports: eth2-PC trunk port VLANs: 100 and 200, eth3-notebook access port VLAN 100.

Bridge setup:
/interface add bridge auto-mac=no comment="main bridge" igmp-snooping=no name=bridge vlan-filtering=yes
/interface vlan
add interface=bridge name=bridge-vlan100 vlan-id=100
add interface=bridge name=bridge-vlan200 vlan-id=200
/interface bridge port
add bridge=bridge interface=eth2-PC
add bridge=bridge interface=eth3-notebook pvid=100
/interface bridge vlan
add bridge=bridge tagged=bridge,eth2-PC untagged=eth3-notebook vlan-ids=100
add bridge=bridge tagged=eth2-PC,bridge vlan-ids=200
This works but traffic from eth2-PC to eth3-notebook always goes through CPU bridge (hardware offload is disabled as for the vlan-filtering=yes which is not supported on switch chip in 3011.
This is true, switch chip in 3011 can't add VLAN tags to packets but it can use 'Default VLAN ID' for access ports.
/interface ethernet switch
port set eth2-PC vlan-mode=check
port set eth3-notebook vlan-mode=check vlan-header=always-strip default-vlan-id=100
vlan add switch=switch1 ports=eth2-PC,eth3-notebook,switch1-cpu vlan-id=100
vlan add switch=switch1 ports=eth2-PC,switch1-cpu vlan-id=200
If I add this part of the setup I get 3 DUPs on pings between eth2-PC <-> eth3-notebook (VLAN100<->VLAN100) and it is generally unstable. This is because the RouterOS disabled hardware offloading and the host table of hardware switch is empty (and stays that way) and then it works as a hub (that is only explanation I have), thus pushing the packets through all connected interfaces.

If I remove swich1-cpu from 'vlan add' statements connection between PC and notebook via VLAN 100 works (no DUPs) and is switched in hardware but packets are still broadcasted on every connected interface (same issue, hw-offload disabled, switch host table not populated). If I also remove VLAN filtering from the software bridge, which makes it enable hw-offload, the switch host table gets populated but then there is no separation in the software bridge.

This setup shows that switch chip in 3011 is able to perform basic VLAN filtering in hardware but using VLAN filtering on bridge makes in unusable (DUPs, loops or no hardware acceleration).

I really hope this can be resolved, this significantly cuts down on capabilities of 3011 which might as well have no VLAN aware switch chip/swich host table at this point.
Last edited by Kubuxu on Mon Oct 16, 2017 5:24 pm, edited 1 time in total.
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Oct 16, 2017 4:22 pm

Hi,
I am trying to set up VLAN bridge for upstream and access to the router on RB3011 running 6.41rc44 but also offload the switching to the hardware switch.
I am able to successfully do one or the other but if I combine both setups for local pings I get 3 DUPs.

Setup in question:
Main router: 3011 running 6.41.rc44 with PPPoE upstream. For simplicity two LAN ports: eth2-PC trunk port VLANs: 100 and 200, eth3-notebook access port VLAN 100.

Bridge setup:
/interface add bridge auto-mac=no comment="main bridge" igmp-snooping=no name=bridge vlan-filtering=yes
/interface vlan
add interface=bridge name=bridge-vlan100 vlan-id=100
add interface=bridge name=bridge-vlan200 vlan-id=200
/interface bridge port
add bridge=bridge interface=eth2-PC
add bridge=bridge interface=eth3-notebook pvid=100
/interface bridge vlan
add bridge=bridge tagged=bridge,eth2-PC untagged=eth3-notebook vlan-ids=100
add bridge=bridge tagged=eth2-PC,bridge vlan-ids=200
This works but traffic from eth2-PC to eth3-notebook always goes through CPU bridge (hardware offload is disabled as for the vlan-filtering=yes which is not supported on switch chip in 3011.
This is true, switch chip in 3011 can't add VLAN tags to packets but it can use 'Default VLAN ID' for access ports.
/interface ethernet switch
port set eth2-PC vlan-mode=check
port set eth3-notebook vlan-mode=check vlan-header=always-strip default-vlan-id=100
vlan add switch=switch1 ports=eth2-PC,eth3-notebook,switch1-cpu vlan-id=100
vlan add switch=switch1 ports=eth2-PC,switch1-cpu vlan-id=200
If I add this part of the setup I get 3 DUPs on pings between eth2-PC <-> eth3-notebook and it is generally unstable. This is because the RouterOS disabled hardware offloading and the host table of hardware switch is empty (and stays that way) and then it works as a hub (that is only explanation I have), thus pushing the packets through all connected interfaces.

If I remove swich1-cpu from 'vlan add' statements connection between PC and notebook via VLAN 100 works (no DUPs) and is switched in hardware but packets are still broadcasted on every connected interface (same issue, hw-offload disabled, switch host table not populated). If I also remove VLAN filtering from the software bridge, which makes it enable hw-offload, the switch host table gets populated but then there is no separation in the software bridge.

This setup shows that switch chip in 3011 is able to perform basic VLAN filtering in hardware but using VLAN filtering on bridge makes in unusable (DUPs, loops or no hardware acceleration).

I really hope this can be resolved, this significantly cuts down on capabilities of 3011 which might as well have no VLAN aware switch chip/swich host table at this point.
Per a case I opened with MikroTik support, expect existing hardware features to slowly be turned on in the new environment. That said, any inter-VLAN traffic, traffic from VLAN100 to VLAN200 from a routing perspective will always be done across the CPU. I believe the reference platform they are using for development is the CRS3xx products. I'd expect to see other platforms covered over time. I run a 750Gr3 (hex) to perform inter-VLAN routing and it gets 300mbps+ throughput and has worked fine in my LAN considering everything else is constrained by a much slower Internet connection. Your mileage may very with other platforms and their CPU.
 
Kubuxu
just joined
Posts: 2
Joined: Sat Sep 24, 2016 10:07 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Oct 16, 2017 5:23 pm

That said, any inter-VLAN traffic, traffic from VLAN100 to VLAN200 from a routing perspective will always be done across the CPU.
I know that, but this is VLAN100<->VLAN100 which should be possible to be done in the switch.
expect existing hardware features to slowly be turned on in the new environment
Let's hope in future it will allow to use 3011 switch capabilities with any VLAN.
 
User avatar
alkar
just joined
Posts: 3
Joined: Sat Jul 04, 2015 8:29 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Oct 17, 2017 4:04 pm

when v6.41rc will be as "current" ?
We bought 2 x CRS317-1G-16S+RM and couldn't set up harware vlan via winbox.
Based on experience with some previous RouterOS versions, I'd say that hitting the Current update channel and receiving WinBox support for some options are two unrelated things. It's possible that 6.41 becomes current with these options still being CLI-only.

I'm wondering though, what stops you from staying on 6.40.x or 6.39.x and configuring what you need in a "traditional" way?
A "traditional" way in CRS317 not working. Switch menu shown all ports as Unknown.
viewtopic.php?f=17&t=125758
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Oct 17, 2017 5:00 pm

Oh boy - you are right: RTFM!
The bridge itself is kind of an interface. Now everything works.

But I am still curious if I choose the correct way to work with untagged i.e. PVID1-traffic. Both trunk ports have PVID1. The whole configuration works only if I set both trunk ports as tagged in bridge vlan setting for PVID1.
As soon as I set both trunk ports as untagged in bridge vlan settings for PVID1 no connection is possible. This situation persists until I do a reboot or disable and enable the whole bridge. Is this meant to be like this?
I'd have to see your configuration to be certain but it shouldn't be a problem as long as VLAN1 is only untagged or tagged not both on the port. Additionally, VLAN1 either needs to be untagged (default) or tagged for the bridge interface as well.
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1407
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Oct 19, 2017 12:42 pm

What's new in 6.41rc47 (2017-Oct-18 10:38):

Important note!!! Backup before upgrade!
RouterOS (v6.40rc36-rc40 and) v6.41rc1+ contains new bridge implementation that supports hardware offloading (hw-offload).
This update will convert all interface "master-port" configuration into new bridge configuration, and eliminate "master-port" option as such.
Bridge will handle all Layer2 forwarding and the use of switch-chip (hw-offload) will be automatically turned on based on appropriate conditions.
The rest of RouterOS Switch specific configuration remains untouched in usual menus for now.
Please, note that downgrading to previous RouterOS versions will not restore "master-port" configuration, so use backups to restore configuration on downgrade.


Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;
2) Make sure the device will not lose power during upgrade process;
3) Device has enough free storage space for all RouterOS packages to be downloaded.

Changes since previous 6.41rc release:

!) bridge - general implementation of hw-offload bridge (introduced in v6.40rc36);
!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
!) routerboot - RouterBOOT version numbering system merged with RouterOS;
*) bridge - assume "point-to-point=yes" for all Full Duplex Ethernet interfaces when STP is used (as per standard);
*) console - removed "/setup";
*) crs3xx - added ingress/egress rate input limits;
*) discovery - use "/interface list" instead of interface name under neighbour discovery settings;
*) ethernet - fixed missing "sfp-tx-power" option (introduced in v6.41rc14);
*) ipsec - fixed incorrect esp proposal key size usage;
*) lte - temporarily disabled user authentication using user/password PAP/CHAP support for R11e-LTE (introduced in v6.41rc44);
*) lte - fixed PIN option after setting up the band;
*) lte - fixed error when trying to add APN profile without name;
*) lte - fixed rare crash when initializing LTE modem after reset;
*) netinstall - fixed missing default configuration prompt on first startup after reset/netinstall;
*) ssh - do not use DH group1 with strong-crypto enabled;
*) ssh - enforced 2048bit DH group on tile and x86 architectures;
*) winbox - added support for "_" symbol in terminal window;

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after crash.
 
planetcoop
Member Candidate
Member Candidate
Posts: 115
Joined: Thu May 15, 2014 2:32 pm
Location: Sacramento, CA

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Oct 19, 2017 5:41 pm

"/ip neighbors" seems to not work on 6.41rc47 on tile...
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 5934
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Oct 19, 2017 5:49 pm

go to
/ip neighbor discovery-settings menu
and set discover-interface-list=all
 
raffav
Member Candidate
Member Candidate
Posts: 288
Joined: Wed Oct 24, 2012 4:40 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Oct 19, 2017 5:54 pm

go to
/ip neighbor discovery-settings menu
and set discover-interface-list=all
this function is not available on winbox yet correct ?
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 5934
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Oct 19, 2017 5:58 pm

yes, currently only terminal. Default value is "!dynamic", but you can set it to "all".
 
raffav
Member Candidate
Member Candidate
Posts: 288
Joined: Wed Oct 24, 2012 4:40 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Oct 19, 2017 6:00 pm

thanks
 
pe1chl
Forum Guru
Forum Guru
Posts: 5834
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Oct 19, 2017 7:22 pm

*) discovery - use "/interface list" instead of interface name under neighbour discovery settings;
Discovery packets are now sent with source 0.0.0.0 instead of interface address as before. Maybe due to this change?
This causes firewall issues, we drop "bogon" packets (packets from an address list with certain reserved addresses including 0.0.0.0)
before the rule that accepts discovery packets.
 
raffav
Member Candidate
Member Candidate
Posts: 288
Joined: Wed Oct 24, 2012 4:40 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Oct 19, 2017 9:45 pm

Mikrotik team

is it difficult to create some type of address-list or something similar to use on ipsec polices in future release ?
 
alexsolovyev
just joined
Posts: 7
Joined: Thu Oct 19, 2017 10:38 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Oct 19, 2017 10:49 pm

Applying the default configuration seems to be broken in 6.41rc47. I'm getting an empty config after clicking on the "OK" button after resetting the configuration. It's working in 6.40.4
 
chubbs596
Frequent Visitor
Frequent Visitor
Posts: 51
Joined: Fri Dec 06, 2013 6:07 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Oct 20, 2017 2:26 am

Has anyone tested ROMON in 6.41rc47?
Seems that is not working.

Also, can someone explain how QinQ vlans would be programmed in the new Bridge vlan implementation?
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Oct 20, 2017 3:18 am

Has anyone tested ROMON in 6.41rc47?
Seems that is not working.

Also, can someone explain how QinQ vlans would be programmed in the new Bridge vlan implementation?
Put a bridge in your bridge?
 
roswitina
newbie
Posts: 26
Joined: Tue Mar 12, 2013 8:12 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Oct 20, 2017 9:43 am

I use 2011UiAS-2HnD with firmware 3.41.
After Urgrade to firmware v6.41rc44 and/or v6.41rc47 the router reboots every one to two hours.

in the log I have the following entry:
memory system,info router rebooted
memory system,error,critical router rebooted beause some critical program crashed

I go back to the current firmware 6.40.4.

rosi
 
uldis
MikroTik Support
MikroTik Support
Posts: 3425
Joined: Mon May 31, 2004 2:55 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Oct 20, 2017 10:09 am

I use 2011UiAS-2HnD with firmware 3.41.
After Urgrade to firmware v6.41rc44 and/or v6.41rc47 the router reboots every one to two hours.

in the log I have the following entry:
memory system,info router rebooted
memory system,error,critical router rebooted beause some critical program crashed

I go back to the current firmware 6.40.4.

rosi
Please make a support output file after the crash and send it to support@mikrotik.com
 
User avatar
bajodel
Long time Member
Long time Member
Posts: 545
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Oct 20, 2017 11:24 am

Has anyone tested ROMON in 6.41rc47?
Seems that is not working.
Also, can someone explain how QinQ vlans would be programmed in the new Bridge vlan implementation?
Put a bridge in your bridge?
and if I need a single service tag on packets ?
I've never played with new bridge but I suppose there is a place where I can set the tag type..
 
roswitina
newbie
Posts: 26
Joined: Tue Mar 12, 2013 8:12 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Oct 20, 2017 1:09 pm

I use 2011UiAS-2HnD with firmware 3.41.
After Urgrade to firmware v6.41rc44 and/or v6.41rc47 the router reboots every one to two hours.

in the log I have the following entry:
memory system,info router rebooted
memory system,error,critical router rebooted beause some critical program crashed

I go back to the current firmware 6.40.4.

rosi
Please make a support output file after the crash and send it to support@mikrotik.com
I'm doing it. I install v6.41RC47 and wait for the next crash.
Rosi
 
linek1980
newbie
Posts: 34
Joined: Thu Feb 03, 2011 1:39 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Oct 20, 2017 1:30 pm

oct/19 15:40:31 system,info router rebooted
oct/19 15:40:31 system,error,critical router rebooted because some critical program crashed
oct/19 15:40:39 bridge,info hardware offloading activated on bridge "bridge" ports: ether2
oct/19 15:40:39 bridge,info hardware offloading activated on bridge "bridge" ports: ether3
oct/19 15:40:39 bridge,info hardware offloading activated on bridge "bridge" ports: ether4
oct/19 15:40:39 bridge,info hardware offloading activated on bridge "bridge" ports: ether5
oct/19 15:40:41 interface,info ether1 link up (speed 100M, full duplex)
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8310
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Oct 20, 2017 2:11 pm

Please make a support output file after the crash and send it to support@mikrotik.com
Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

For every complex problem, there is a solution that is simple, neat, and wrong.

MikroTik. Your life. Your routing.
 
becs
MikroTik Support
MikroTik Support
Posts: 479
Joined: Thu Jul 07, 2011 8:26 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Oct 20, 2017 3:09 pm

In RouterOS v6.41 everything QinQ related has to configured with bridge "vlan-filtering=no" using VLAN interfaces and their "use-service-tag" option.
 
JimmyNyholm
Member Candidate
Member Candidate
Posts: 249
Joined: Mon Apr 25, 2016 2:16 am
Location: Sweden

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Oct 20, 2017 6:19 pm

In RouterOS v6.41 everything QinQ related has to configured with bridge "vlan-filtering=no" using VLAN interfaces and their "use-service-tag" option.
And if one do that all qinq switching will get software switched or what?
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Oct 20, 2017 7:00 pm

In RouterOS v6.41 everything QinQ related has to configured with bridge "vlan-filtering=no" using VLAN interfaces and their "use-service-tag" option.
And if one do that all qinq switching will get software switched or what?
Wouldn't it have been in software before? Are their models that supported QinQ in hardware under the switch chip menu?
 
whitbread
Member Candidate
Member Candidate
Posts: 108
Joined: Fri Nov 08, 2013 9:55 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Oct 21, 2017 8:15 am

I am still curious which devices will support HW-offloading when VLAN-Filtering is enabled. I understand, that most devices need to run inter VLAN switching via CPU, but currently all my devices (RB2011 et. al.) don't do HW-offloading at all.

Is this a software limitation of the current RC development and will be implemented in the near future?
 
guipoletto
Frequent Visitor
Frequent Visitor
Posts: 92
Joined: Mon Sep 19, 2011 5:31 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sun Oct 22, 2017 1:46 am

I would like to know if this new bridge implementation affects something on hardware that does not have an integrated switch-chip (Rb333, CCR, rb1200{ports5-10}, etc).
Are any performance gains to be expected?
 
hapi
Member Candidate
Member Candidate
Posts: 223
Joined: Fri Mar 11, 2011 11:21 am
Location: Czech Republic

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sun Oct 22, 2017 2:00 pm

*) wireless - log "signal-strength" when successfully connected to AP;
Can you add a signal to the log and to the client when it was disconnected?
 
biatche
Member Candidate
Member Candidate
Posts: 128
Joined: Tue Oct 13, 2015 6:50 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Oct 23, 2017 9:37 am

*) wireless - log "signal-strength" when successfully connected to AP;
Can you add a signal to the log and to the client when it was disconnected?
Do that for capsman too.
 
darencrew
just joined
Posts: 24
Joined: Thu Nov 23, 2006 6:12 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Oct 23, 2017 8:24 pm

On previous releases, a way to flush neighbor discovery entries was to disable and re-enable discovery interfaces.
Now, it has no more effects, entries disappear only after aged out.

If that's an expected behavior, as "/ip neighbor discovery" menu has disappeared on CLI, winbox "neighbor discovery interfaces" should probably go, and be replaced by the new "discovery-settings".

In my opinion, the new "/ip neighbor discovery-settings set discover-interface-list" is not totally useless but is too generic, so it should better be a new feature (or more exactly a macro) and not a replacement feature.
 
darzupan
just joined
Posts: 1
Joined: Fri Jan 21, 2011 12:45 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Oct 24, 2017 9:11 am

Hi

Yesterday i bought wap-lte kit eu upgraded to version 6.41rc47 I have a problem snmp lte not working I tried to custom oid not work
When it will be repaired

mtxrltemodem interface index 1.3.6.1.4.1.14988.1.1.16.1.1.1
mtxrltemodem signalrssi 1.3.6.1.4.1.14988.1.1.16.1.1.2
mtxrltemodem signalrsrq 1.3.6.1.4.1.14988.1.1.16.1.1.3
mtxrltemodem signalrsrp 1.3.6.1.4.1.14988.1.1.16.1.1.4
mtxrltemodem cell id 1.3.6.1.4.1.14988.1.1.16.1.1.5
mtxrltemodem signalsinr 1.3.6.1.4.1.14988.1.1.16.1.1.7

Another problem

On the SIM card I have private APN xxxx.si and APN internet but I can not connect to APN xxxx.si .. tried all possible settings but the connection is not established .. apn internet works
For APN xxxx.si I use the Huawei E3372 usb modem to MT CCR1009 this works fine in the same usb modem running on MT x86 ESXi is work. But the Wap-lte kit eu private apn doesn't work.
APN xxxx.si use to connect to the official network.

What could be a problem?


Best regards
 
c02
just joined
Posts: 5
Joined: Tue Jan 13, 2015 8:19 pm
Location: Austria
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Oct 24, 2017 5:46 pm

need user auth and custom apn for wap lte eu - please relase 6.41rc48 - thx !
 
User avatar
frakas
just joined
Posts: 1
Joined: Tue Oct 03, 2017 9:02 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Oct 25, 2017 3:28 pm

Hello,
Products: CRS326-24G-2S+RM
RouterOS: 6.41rc47

This is my configuration: ether1 is untagged vlan 40 and ether24 is Trunk (all vlan is tagged)
/interface bridge
add fast-forward=no igmp-snooping=no name=bridge-vlans vlan-filtering=yes
/interface vlan
add interface=bridge-vlans name=vlan40 vlan-id=40
add interface=bridge-vlans name=vlan41 vlan-id=41
add interface=bridge-vlans name=vlan42 vlan-id=42
/interface bridge port
add bridge=bridge-vlans interface=ether1 pvid=40
add bridge=bridge-vlans interface=ether24-Trunk 
/interface bridge vlan
add bridge=bridge-vlans tagged="bridge-vlans,ether24-Trunk"  vlan-ids=40
add bridge=bridge-vlans tagged="bridge-vlans,ether24-Trunk" vlan-ids=41
add bridge=bridge-vlans tagged="bridge-vlans,ether24-Trunk" vlan-ids=42
/ip address
add address=192.168.40.254/24 interface=vlan40 network=192.168.40.0
add address=192.168.41.254/24 interface=vlan41 network=192.168.41.0
add address=192.168.42.254/24 interface=vlan42 network=192.168.42.0
set name=R1
Ether24 connects to another CRS326 with the same configuration. The only difference is the only ip on vlan40 (192.168.40.253).

It seems to work everything until it connects servers and clients to different vlan. Packet routing does not always work.
Is there any known bug in my configuration?
Is there any other configuration possible to achieve the same goal?

AC
 
chubbs596
Frequent Visitor
Frequent Visitor
Posts: 51
Joined: Fri Dec 06, 2013 6:07 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Oct 26, 2017 10:18 am

Has anyone tested ROMON in 6.41rc47?
Seems that is not working.

Also, can someone explain how QinQ vlans would be programmed in the new Bridge vlan implementation?
Put a bridge in your bridge?
Yea sure that will work but cant see that that is the correct way to do this as you loose the hardware offload on this type off config.

Any ideas? Maybe Mikrotik can comment on this
 
chubbs596
Frequent Visitor
Frequent Visitor
Posts: 51
Joined: Fri Dec 06, 2013 6:07 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Oct 26, 2017 10:27 am

Has anyone tested ROMON in 6.41rc47? Doesn't seem to work
 
nescafe2002
Long time Member
Long time Member
Posts: 623
Joined: Tue Aug 11, 2015 12:46 pm
Location: Netherlands

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Oct 26, 2017 1:05 pm

RoMON works fine here (both router and endpoint on 6.41rc47).

Have you tried playing with new discovery settings? Not sure if these are related. RoMON works fine even with discovery-interface-list=none..
go to
/ip neighbor discovery-settings menu
and set discover-interface-list=all
 
User avatar
eworm
Member
Member
Posts: 396
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Oct 27, 2017 8:43 pm

The support promised the next rc release will have a fix for my crash. That was one and a half week ago...
Will we have a release any time soon?
Manage RouterOS scripts and extend your devices' functionality: RouterOS Scripts
 
User avatar
Jotne
Forum Guru
Forum Guru
Posts: 1303
Joined: Sat Dec 24, 2016 11:17 am
Location: jo.overland at gmail.com

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Oct 28, 2017 9:15 am

The support promised the next rc release will have a fix for my crash. That was one and a half week ago...
Will we have a release any time soon?
It will be released when its ready.
RC is for test only. Not ment for production environment.
 
How to use Splunk to monitor your MikroTik Router

MikroTik->Splunk
 
 
skuykend
Member Candidate
Member Candidate
Posts: 270
Joined: Tue Oct 06, 2015 7:28 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Oct 28, 2017 7:02 pm

The support promised the next rc release will have a fix for my crash. That was one and a half week ago...
Will we have a release any time soon?
Hopefully a new RC early next week, but they pretty much shut down development during a MUM, which started Thursday.
 
skuykend
Member Candidate
Member Candidate
Posts: 270
Joined: Tue Oct 06, 2015 7:28 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Oct 28, 2017 7:14 pm

CRS317 running 6.41rc47 for about 5 days then fault led came on, and other LED's stopped responding (seemed left at their previous state). I also lost access to the my management vlan/IP, but the switch seemed to be otherwise still working passing traffic. Just no access to the CPU.

I didn't think to try a console cable to see if I could get access to generate a support out, but will if it happens again.

I unplugged both power cords then powered it back up and has been running fine for the last 12 hours.
 
skuykend
Member Candidate
Member Candidate
Posts: 270
Joined: Tue Oct 06, 2015 7:28 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sun Oct 29, 2017 7:17 pm

No ports/wlan working with default config for RB951G on rc47. Pretty sure was working on rc44 Will have to Netinstall.
 
mhugo
newbie
Posts: 49
Joined: Mon Sep 19, 2005 11:48 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Oct 30, 2017 6:00 pm

Hardware offload for Vlans using the bridge ports on CRS212 does not seem to work?

/interface bridge
add igmp-snooping=no name=bridge1
add igmp-snooping=no name=bridge2
/interface vlan
add interface=sfp10 name=sfp10-vlan100 vlan-id=100
add interface=sfp10 name=sfp10-vlan101 vlan-id=101
/interface bridge port
add bridge=bridge1 interface=sfp2
add bridge=bridge1 interface=sfp10-vlan100
add bridge=bridge2 interface=sfp5
add bridge=bridge interface=sfp10-vlan101

The actual non-vlan members seems to be enabled for the hwoffload, but not the VLANS. Should this be done in another way?

Running 6.41rc47 on CRS212-1G-10S-1S+

/Mikael
 
JimmyNyholm
Member Candidate
Member Candidate
Posts: 249
Joined: Mon Apr 25, 2016 2:16 am
Location: Sweden

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Oct 30, 2017 6:57 pm

Hardware offload for Vlans using the bridge ports on CRS212 does not seem to work?

/interface bridge
add igmp-snooping=no name=bridge1
add igmp-snooping=no name=bridge2
/interface vlan
add interface=sfp10 name=sfp10-vlan100 vlan-id=100
add interface=sfp10 name=sfp10-vlan101 vlan-id=101
/interface bridge port
add bridge=bridge1 interface=sfp2
add bridge=bridge1 interface=sfp10-vlan100
add bridge=bridge2 interface=sfp5
add bridge=bridge interface=sfp10-vlan101

The actual non-vlan members seems to be enabled for the hwoffload, but not the VLANS. Should this be done in another way?

Running 6.41rc47 on CRS212-1G-10S-1S+

/Mikael
/inteface bridge vlan (here you define bridge vlan and member ports att taged or untaged. Here tag bridge self to.......

/interface vlan is routeros os routing capable interface... connect to bridge interface to connect routeros to underlying switch infrastructure.
 
mhugo
newbie
Posts: 49
Joined: Mon Sep 19, 2005 11:48 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Nov 01, 2017 1:26 am

Seems to be some chip issue when adding vlans in bridge on 212. Verified by Mikrotik trainer who will contact MT tomorrow.
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1407
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Nov 01, 2017 3:04 pm

What's new in 6.41rc50 (2017-Oct-30 10:13):

Important note!!! Backup before upgrade!
RouterOS (v6.40rc36-rc40 and) v6.41rc1+ contains new bridge implementation that supports hardware offloading (hw-offload).
This update will convert all interface "master-port" configuration into new bridge configuration, and eliminate "master-port" option as such.
Bridge will handle all Layer2 forwarding and the use of switch-chip (hw-offload) will be automatically turned on based on appropriate conditions.
The rest of RouterOS Switch specific configuration remains untouched in usual menus for now.
Please, note that downgrading to previous RouterOS versions will not restore "master-port" configuration, so use backups to restore configuration on downgrade.


Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;
2) Make sure the device will not lose power during upgrade process;
3) Device has enough free storage space for all RouterOS packages to be downloaded.

Changes since previous 6.41rc release:

!) bridge - general implementation of hw-offload bridge (introduced in v6.40rc36);
!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
*) bridge - set "igmp-snooping=no" by default on new bridges;
*) crs3xx - added ingress/egress rate input limits;
*) dhcp-client - limited DHCP client "default-route-distance" minimal value to 1;
*) dhcp-server - added "option-set" argument (CLI only);
*) discovery - use "/interface list" instead of interface name under neighbor discovery settings;
*) health - fixed bogus voltage readings on CCR1009;
*) ike1 - fixed crash after downgrade if DH groups 19,20,21 were used for phase1;
*) ike1 - fixed crash on xauth if user does not exist;
*) ipv6 - fixed IPv6 addresses constructed from prefix and static address entry;
*) lte - added "/interface lte apn" menu (Passthrough requires reconfiguration);
*) lte - added Passthrough support;
*) lte - fixed user authentication for R11e-LTE when new firmware is used;
*) m11g - improved ethernet performance on high load;
*) netinstall - fixed missing "/flash/etc" on first bootup;
*) quickset - renamed router IP static DNS name to "router.lan"
*) radius - limited RADIUS timeout maximum value to 3 seconds;
*) sms - fixed minor problem for SMS delivery;
*) webfig - added favicon file;
*) webfig - fixed terminal graphic user interface under Safari browser;
*) winbox - do not show unnecessary tabs from "Switch" menu;
*) wireless - new driver with initial support for 160 and 80+80 MHz channel width;

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after crash.
 
jondavy
Member Candidate
Member Candidate
Posts: 127
Joined: Tue May 12, 2009 11:14 pm
Location: Brasil

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Nov 01, 2017 7:40 pm

What's new in 6.41rc50 (2017-Oct-30 10:13):
*) radius - limited RADIUS timeout maximum value to 3 seconds;
do not do this, our system on average 1~5 seconds to process the radius package
please leave this field customizable
 
User avatar
doneware
Trainer
Trainer
Posts: 522
Joined: Mon Oct 08, 2012 8:39 pm
Location: Hungary

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Nov 02, 2017 3:26 am

What's new in 6.41rc50 (2017-Oct-30 10:13):
*) wireless - new driver with initial support for 160 and 80+80 MHz channel width;
stop right there. this stuff above literally translates to wave2, right?
#TR0359
 
brwainer
newbie
Posts: 47
Joined: Tue Feb 02, 2016 2:55 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Nov 02, 2017 6:07 am

stop right there. this stuff above literally translates to wave2, right?
I thought 802.11ac Wave2 was MU-MIMO as well as 160MHz / 80+80MHz channels? And to date, I believe all the the wireless chipsets that Mikrotik has shipped in products are Wave1. But maybe this is a little accidental show-of-hand towards new products, which of course would need software support.
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 1819
Joined: Mon Jan 14, 2008 1:53 pm
Location: Straya
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Nov 02, 2017 8:03 am


stop right there. this stuff above literally translates to wave2, right?
Wave2 you say... You mean like this:
https://fccid.io/TV7CPGI5ACD2ND/Interna ... os-3602640

:D
http://thebrotherswisp.com/ | Mikrotik MTCNA, MTCRE, MTCINE | Fortinet FTCNA, FCNSP, FCT | Extreme Networks ENA
 
Mackiavelly
just joined
Posts: 12
Joined: Wed Aug 31, 2016 12:59 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Nov 02, 2017 12:50 pm

What's new in 6.41rc50 (2017-Oct-30 10:13):

*) radius - limited RADIUS timeout maximum value to 3 seconds;

a very bad idea, this field generally needs to remove the limits, so that I myself can set the desired value, for example, even 15-20 seconds
 
ivanfm
newbie
Posts: 46
Joined: Sun May 20, 2012 5:07 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Nov 02, 2017 1:18 pm

What's new in 6.41rc50 (2017-Oct-30 10:13):
*) radius - limited RADIUS timeout maximum value to 3 seconds;
do not do this, our system on average 1~5 seconds to process the radius package
please leave this field customizable

We also have to use 5 seconds.
 
mducharme
Trainer
Trainer
Posts: 799
Joined: Tue Jul 19, 2016 6:45 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Nov 02, 2017 5:46 pm

We currently have to use 6 seconds for RADIUS timeout in many cases - a limit of 3 seconds is not enough.

We have some sites on bidirectional satellite links with local PPPoE servers - in case a UDP accounting packet was missed and the RADIUS server thinks the customer trying to log in was already logged in (ex. sharing their credentials with a neighbor), it has to connect to the router to pull the list of PPPoE interfaces via SNMP to see if the customer is actually still logged in before sending a reply. Due to the satellite link, this process takes up to 6000 ms.
 
User avatar
juliokato
Member Candidate
Member Candidate
Posts: 229
Joined: Mon Oct 26, 2015 4:27 pm
Location: Brazil

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Nov 02, 2017 6:14 pm

What's new in 6.41rc50 (2017-Oct-30 10:13):

*) radius - limited RADIUS timeout maximum value to 3 seconds;

just wanted to understand who thought the 3-second limit is enough.
I apologize my grammatical errors, my english not so good, I am not a native speaker.
Wiki is maintained in English. I use Google translator. 8)
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Nov 02, 2017 6:20 pm

What's new in 6.41rc50 (2017-Oct-30 10:13):
*) radius - limited RADIUS timeout maximum value to 3 seconds;
a very bad idea, this field generally needs to remove the limits, so that I myself can set the desired value, for example, even 15-20 seconds
Yup, seems like MT was overstepping. Seems like something that should be a default value adjustment that is still configurable.
 
mhugo
newbie
Posts: 49
Joined: Mon Sep 19, 2005 11:48 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Nov 02, 2017 7:25 pm

Hi,

Is it just me or did the new bridge implementation just vanish in 6.41rc50 - On CRS212-1G-10S-1S+ Im back with masterports and no hardware offload in menu?

/Mikael
 
cmekcik
just joined
Posts: 2
Joined: Mon Mar 27, 2017 7:13 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Nov 02, 2017 9:38 pm

Hi,

Is it just me or did the new bridge implementation just vanish in 6.41rc50 - On CRS212-1G-10S-1S+ Im back with masterports and no hardware offload in menu?

/Mikael
having the same issue on CRS317. i use classic RouterOS vlan trunking on crs317 because i can not pass VLANs to routers with current version of RouterOS
BTW anybody share you config for this situation (VLANs from current to RC). documentation about CRS317 is like "Warning: This article applies to CRS1xx and CRS2xx series switches and not to CRS3xx series switches."
 
cmekcik
just joined
Posts: 2
Joined: Mon Mar 27, 2017 7:13 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Nov 02, 2017 9:40 pm

del
 
stackflow
just joined
Posts: 10
Joined: Fri Nov 03, 2017 7:07 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 03, 2017 7:33 am

When would the final version to be released?

Does the hardware off-load feature supports wireless bridging of HAP AC PRO?
 
upower3
Member
Member
Posts: 384
Joined: Thu May 07, 2015 11:46 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 03, 2017 2:49 pm

Just wanted to tell you guys implementing very good thing, but new RC seems to be very long in development so far. It is not common to see 50 (!) RCs per release (and not yet 6.41 released this far), and this looks like it will be just dangerous to install in into prod for too many changes (beside new bridge implementation).

Would you mind to hear if I ask you to introduce two releases at the end: say, 6.41 with all changes but without new bridge implementation (so new changes will be tested beside all mess that can be involved with new bridging) , and another one, say 6.42 (or 6.411) with just bridge 'revolution'? This appears to be wise to monitor the effect of new bridge implementation without any other changes. Just in case, you know!
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 03, 2017 4:00 pm

Just wanted to tell you guys implementing very good thing, but new RC seems to be very long in development so far. It is not common to see 50 (!) RCs per release (and not yet 6.41 released this far), and this looks like it will be just dangerous to install in into prod for too many changes (beside new bridge implementation).

Would you mind to hear if I ask you to introduce two releases at the end: say, 6.41 with all changes but without new bridge implementation (so new changes will be tested beside all mess that can be involved with new bridging) , and another one, say 6.42 (or 6.411) with just bridge 'revolution'? This appears to be wise to monitor the effect of new bridge implementation without any other changes. Just in case, you know!
They've done that already. This was initially implemented in 6.40 (rc36 I believe) and and then pulled for 6.40 stable. I really don't think it will be necessary to that again.

I don't disagree with you that upgrading production environments will be precarious at best. This is a big change. That said with solid for thought and good evaluation of your configs you should be able to identify ways to safely perform the upgrade. An example would be pulling a port out of the bridge (switch chip) as a stand alone routed port. This would protect you from the conversion code. This could directly connect to another network path or simply be an Ethernet port you can plug a laptop into in a hurry.
 
JimmyNyholm
Member Candidate
Member Candidate
Posts: 249
Joined: Mon Apr 25, 2016 2:16 am
Location: Sweden

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 03, 2017 4:27 pm

What's new in 6.41rc50 (2017-Oct-30 10:13):
*) radius - limited RADIUS timeout maximum value to 3 seconds;
do not do this, our system on average 1~5 seconds to process the radius package
please leave this field customizable
+1 we are using OTP that validates a bit slow sometimes we want 10 seconds... Don't do this.
 
upower3
Member
Member
Posts: 384
Joined: Thu May 07, 2015 11:46 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 03, 2017 10:26 pm

They've done that already.
Done what? In released version? With no roll back? Hey, you must be kidding me! :)

What I talk about is the we shoudl split new bridge implementation from all these other changes, for good reason: bridge change is BIG one so this alone should be tested very serious. When it comes to big RB-based network, we'd want to check any consequnces and react accordingly. 6.40rc36 introduced h/w bridging but then it was rolled back, so no tests in the wild was done.

6.42 is full of other changes. This is why if you just upgrade RB to 6.42, you'll never know whay caused problem should they arise: new h/w bridge code or any of these changes you can see in the changelog.

And yes, when it comes to upgrade, say, 100 remote devices, I'd prefer to turn on serious new feature one at the time, don't you like this approach?

I do appreciate MT for their passion to create better platform but big changes is something risky, so isolating BIG changes is kind of good idea, I think.
 
skuykend
Member Candidate
Member Candidate
Posts: 270
Joined: Tue Oct 06, 2015 7:28 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 03, 2017 10:44 pm

They've done that already.
Done what? In released version? With no roll back? Hey, you must be kidding me! :)
They had some of the new bridge code in 6.40rc and reverted it for the final 6.40, then put it back in for 6.41rc. At this point a lot of their new devices are starting to rely on it though.

6.39rc went up to rc80, sometimes it takes a while to get it done.

There is also a bugfix only channel (currently at 6.39.3) which may be more stable for production implementations, so they have given other options.
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 03, 2017 10:52 pm

They've done that already.
Done what? In released version? With no roll back? Hey, you must be kidding me! :)

What I talk about is the we shoudl split new bridge implementation from all these other changes, for good reason: bridge change is BIG one so this alone should be tested very serious. When it comes to big RB-based network, we'd want to check any consequnces and react accordingly. 6.40rc36 introduced h/w bridging but then it was rolled back, so no tests in the wild was done.

6.42 is full of other changes. This is why if you just upgrade RB to 6.42, you'll never know whay caused problem should they arise: new h/w bridge code or any of these changes you can see in the changelog.

And yes, when it comes to upgrade, say, 100 remote devices, I'd prefer to turn on serious new feature one at the time, don't you like this approach?

I do appreciate MT for their passion to create better platform but big changes is something risky, so isolating BIG changes is kind of good idea, I think.
Yes, look at the forum thread for 6.40rc, in 6.40rc36 the new bridge implementation was introduced. It was reverted in 6.40rc41 so that 6.40 could be released to stable without it. We are now in 6.41rc and it is here to stay. In that release you got exactly what you were asking for. The bridge was brought in, you should've installed it, tried out and then when 6.40 went into production you'd get the old master implementation back. The way this particular change works, it's very difficult to keep both implementations in the code base and swap between them especially without introducing new confusion and issues.

To your point about feature isolation during upgrades. Network engineers are categorically terrible at this. I can't tell you how many devices I touch that have the firmware that was shipped on them still. The mentality of "but it works" just doesn't cut it. This turns into devices that are hacked with multiple year old vulnerabilities.

With that in mind do you mean to tell me that when you upgrade your Linux kernel you break out any major feature and only compile that single feature into your existing code-base, test for 6 months and then bring in other maintenance fixes? I guarantee you don't. Get real, updates are fast and frequent now.

You are literally asking MikroTik to maintain 2 branches of code, 1 with the new bridge and 1 without. At some point they'd have to reconcile any patch from 1 branch to the other. While version control tools definitely make this possible it's a stupid level of work especially when most customers need more than just the new bridge code. Not to mention all of the interdependent code. I for one wouldn't want my new bridge branch to be frozen and not get updates for 6 months just like I wouldn't want to stay on the old architecture just for updates only to be forced to flash cut over at some point in the future. While this branch management works and is used for some projects the common idea is that feature is merged into the rest of the changes for a particular release. That's industry standard across projects a lot bigger than RouterOS code wise. At some point reconciliation of code has to happen, it might as well be as early as possible. It's easy to pull a patch in a version control system and have a new build released or just fix the bug forward.

TLDR; the bridge is here to stay barring any catastrophic issues. I'd grab a test router of each model you have in production and start practicing the upgrade. Call the bugs out now, early, so you don't have to be submitting cases at midnight to MikroTik when you do try. I know change is hard and scary but with a robust testing process it can be far less scary. If you have a lot of hardware of various models and configurations across a big infrastructure you may want to take a look at a tool like Quali. It can be leveraged to build automated testing scenarios in a fashion that is commonly seen in the software world (automated build and release testing with a tool like Jenkins). The better your tests the safer every upgrade going forward will be.
 
amorsen
newbie
Posts: 31
Joined: Wed Jun 13, 2007 2:17 pm

New bridge keeps IP addresses up

Sat Nov 04, 2017 12:32 am

If you start with the standard configuration, ether2 has ether3-5 as slave ports, and none of the ports ether2 through ether5 have cables attached, any IP addresses assigned to ether2 will be inactive. After the upgrade to rc and the switch to the new bridge implementation, any addresses assigned to a bridge interface are always active, even if all ports are down.

This may seem like a trivial difference, but in our case it isn't. When a customer is moving sites, we can give them a router on the new site with the same LAN IP addresses as the old site. The addresses will not become active until someone actually plugs equipment into the router, but in the meantime we can test that the WAN link performs correctly. As soon as the customer is ready, often on a weekend or at night or some other time when I would rather avoid working, they move their equipment from the old site to the new site, and everything just works.

After the upgrade, that workflow breaks, and I or someone else has to be ready to configure the new router at precisely the moment the customer moves their equipment.

Please make an option to keep the bridge interface down until at least one port is active.
 
User avatar
Cha0s
Forum Veteran
Forum Veteran
Posts: 903
Joined: Tue Oct 11, 2005 4:53 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Nov 04, 2017 1:08 am

Has the routerboot firmware version naming changed in 6.41rc?

I put 6.41rc50 on a couple of routerboards to try it out and I see the routerboot firmware version can be upgraded to '6.41rc50' from 3.xx.
A huge jump! I don't recall seeing this in any of the changelogs for 6.41rc.

If routerboot firmware now follows the ROS version, I would very much like it to automatically get upgraded too during the upgrade of ROS.
Or at least give the user an option to do that in one go.
Having to do double reboots on every upgrade would not be very convenient :)

It would also be nice to keep the routerboot changelog up to date, or include the changes into ROS changelog itself (since you get the fw update via ROS anyway).
https://wiki.mikrotik.com/wiki/RouterBOOT_changelog
 
andriys
Forum Guru
Forum Guru
Posts: 1180
Joined: Thu Nov 24, 2011 1:59 pm
Location: Kharkiv, Ukraine

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Nov 04, 2017 11:49 am

Has the routerboot firmware version naming changed in 6.41rc?
Yes, it has. It happened in 6.41rc47 (see here):
!) routerboot - RouterBOOT version numbering system merged with RouterOS;
If routerboot firmware now follows the ROS version, I would very much like it to automatically get upgraded too during the upgrade of ROS.
Or at least give the user an option to do that in one go.
Having to do double reboots on every upgrade would not be very convenient :)
I'd rather vote for keeping it separate. I believe it's simply safer, and if you have a boot-loop you will at least have an idea of what failed- loader or OS.
 
User avatar
Cha0s
Forum Veteran
Forum Veteran
Posts: 903
Joined: Tue Oct 11, 2005 4:53 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Nov 04, 2017 2:48 pm

I missed that entry in the changelog :oops:

That's why I specifically mentioned to have it as an option.

Personally I've upgraded tons of routerboards' routerboot firmware over the years. I've never ever had a single issue with it nor I've ever read anyone else having a bootloop or any other problem with routerboot firmware.
 
upower3
Member
Member
Posts: 384
Joined: Thu May 07, 2015 11:46 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Nov 04, 2017 7:48 pm

Yes, look at the forum thread for 6.40rc, in 6.40rc36 the new bridge implementation was introduced. It was reverted in 6.40rc41 so that 6.40 could be released to stable without it.
I know that. I'm awre of new bridge implementation and keep my eyes on it, but you missed the point: when MT ships the release I'd prefer to keep two releases, one with just new bridging, another one with the rest of current changelog but without bridging (or in reversed order, first one with just changes, then with just bridge).

I've played with 6.40rc36 a bit but I can not take it for granted that it shown me the same behavior of system that it will be in the release so I can not rely on my observations. There are several side effects connected with new bridges, so customers need to do some tests an d may want to distinguish between effects from bridge and from other changelog entries (the changelog is huge this time, isn't it?)
 
upower3
Member
Member
Posts: 384
Joined: Thu May 07, 2015 11:46 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Nov 04, 2017 7:56 pm

...and yes, maybe I missed that, but I'd love to know the exact algorithm ROS will use to convert master-slave port configs into bridge-based one, and which changes be done as well to the whole config. If, for example, I have some routes that targeted to port name, will it be substituted with newly created bridge name?

It'll be wise to state that in some reference document and maybe discuss it so those who use RBs in large scale may predict what'll be done.

Else some companies/users may ban the upgrade to newly version for their older infrastructure, just to be on the save side. This appears risky, to do that step without any rollback possibility (so you may lost you remote device).
 
User avatar
eworm
Member
Member
Posts: 396
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sun Nov 05, 2017 2:09 am

For me the more important question about boot firmware is: Will the firmware version change with every RouterOS release even if no changes are made? Suppose you installed RouterOS 6.41, then upgraded firmware to 6.41. RouterOS 6.41.1 ships with no changes to the firmware. Is the available firmware version 6.41 or 6.41.1?
Manage RouterOS scripts and extend your devices' functionality: RouterOS Scripts
 
upower3
Member
Member
Posts: 384
Joined: Thu May 07, 2015 11:46 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sun Nov 05, 2017 7:32 am

For me the more important question about boot firmware is: Will the firmware version change with every RouterOS release even if no changes are made? Suppose you installed RouterOS 6.41, then upgraded firmware to 6.41. RouterOS 6.41.1 ships with no changes to the firmware. Is the available firmware version 6.41 or 6.41.1?
Good question. If you look at f/w changelog you'll notice there is not that many changes that affects your device. So apply each firmware upgrade released is an overkill, and should be bound to specific models.
At the same time, I've never heard about need to downgrade the f/w.
So I'd like to have a noitification inside ROS, that for my hardware I should upgrade firmware, and if my hardware if unaffected then why should I do that f/w upgrade?
 
anuser
Member
Member
Posts: 397
Joined: Sat Nov 29, 2014 7:27 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Nov 06, 2017 8:50 pm

What's new in 6.41rc50 (2017-Oct-30 10:13):
*) wireless - new driver with initial support for 160 and 80+80 MHz channel width;
So, is this an updated driver (kernel module) from the ASIC vendor (e.g. Atheros) which has also some bugfixes/features from the vendor?
 
biatche
Member Candidate
Member Candidate
Posts: 128
Joined: Tue Oct 13, 2015 6:50 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Nov 07, 2017 2:33 pm

at the moment, is bridge+vlan still cli only?

is the new bridge implementation without issues now?
 
upower3
Member
Member
Posts: 384
Joined: Thu May 07, 2015 11:46 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Nov 07, 2017 2:38 pm

is the new bridge implementation without issues now?
I'd say we'll when 1) it'll be released and 2) when we'll live with it at least several releases.
Just to be on the safe side.
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1407
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Nov 07, 2017 3:20 pm

What's new in 6.41rc52 (2017-Nov-07 08:48):

Important note!!! Backup before upgrade!
RouterOS (v6.40rc36-rc40 and) v6.41rc1+ contains new bridge implementation that supports hardware offloading (hw-offload).
This update will convert all interface "master-port" configuration into new bridge configuration, and eliminate "master-port" option as such.
Bridge will handle all Layer2 forwarding and the use of switch-chip (hw-offload) will be automatically turned on based on appropriate conditions.
The rest of RouterOS Switch specific configuration remains untouched in usual menus for now.
Please, note that downgrading to previous RouterOS versions will not restore "master-port" configuration, so use backups to restore configuration on downgrade.


Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;
2) Make sure the device will not lose power during upgrade process;
3) Device has enough free storage space for all RouterOS packages to be downloaded.

Changes since previous 6.41rc release:

!) bridge - general implementation of hw-offload bridge (introduced in v6.40rc36);
*) discovery - use "/interface list" instead of interface name under neighbor discovery settings;
*) hotspot - fixed Walled Garden IP functionality when address-list is used;
*) ovpn-server - do not periodically change automatically generated server MAC address;
*) poe - added new "poe-out" status "controller-error";
*) poe - fixed false positive excessive logs in auto-on mode when connected to 100 Mbps device powered from another power source;
*) poe - log PoE status related messages under debug topic;
*) ppp - do not disconnect PPP connection after "idle-timeout" even if traffic is being processed;
*) quickset - added support for "/interface list" in firewall, neighbor discovery, MAC-Telnet and MAC-Winbox;
*) quickset - fixed situation when Quickset automatically changes mode to CPE;
*) w60g - general work on PtMP implementation for 60 GHz connections;
*) wireless - added "indonesia3" regulatory domain information;
*) wireless - added passive scan functionality (CLI only);

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after crash.
 
User avatar
fposavec
newbie
Posts: 39
Joined: Thu Apr 21, 2011 12:59 pm
Location: Čakovec
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Nov 07, 2017 3:41 pm

*) wireless - added passive scan functionality (CLI only);

Any info on this?
 
User avatar
soulflyhigh
Member Candidate
Member Candidate
Posts: 173
Joined: Wed Sep 08, 2010 11:20 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Nov 07, 2017 3:51 pm

*) wireless - added passive scan functionality (CLI only);

Any info on this?
It does scan but it isn't passive.
"/interface wireless> scan 0 passive=yes" and the wlan is disconnected immediately.

@Mikrotik
Is this the same issue that this works only with pure 802.11 protocol and not with nstreme and nv2?

Regards,
M.
MTCRE, MTCTCE
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Nov 07, 2017 5:21 pm

What's new in 6.41rc50 (2017-Oct-30 10:13):

Important note!!! Backup before upgrade!
RouterOS (v6.40rc36-rc40 and) v6.41rc1+ contains new bridge implementation that supports hardware offloading (hw-offload).
This update will convert all interface "master-port" configuration into new bridge configuration, and eliminate "master-port" option as such.
Bridge will handle all Layer2 forwarding and the use of switch-chip (hw-offload) will be automatically turned on based on appropriate conditions.
The rest of RouterOS Switch specific configuration remains untouched in usual menus for now.
Please, note that downgrading to previous RouterOS versions will not restore "master-port" configuration, so use backups to restore configuration on downgrade.


Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;
2) Make sure the device will not lose power during upgrade process;
3) Device has enough free storage space for all RouterOS packages to be downloaded.

Changes since previous 6.41rc release:

!) bridge - general implementation of hw-offload bridge (introduced in v6.40rc36);
!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
*) bridge - set "igmp-snooping=no" by default on new bridges;
*) crs3xx - added ingress/egress rate input limits;
*) dhcp-client - limited DHCP client "default-route-distance" minimal value to 1;
*) dhcp-server - added "option-set" argument (CLI only);
*) discovery - use "/interface list" instead of interface name under neighbor discovery settings;
*) health - fixed bogus voltage readings on CCR1009;
*) ike1 - fixed crash after downgrade if DH groups 19,20,21 were used for phase1;
*) ike1 - fixed crash on xauth if user does not exist;
*) ipv6 - fixed IPv6 addresses constructed from prefix and static address entry;
*) lte - added "/interface lte apn" menu (Passthrough requires reconfiguration);
*) lte - added Passthrough support;
*) lte - fixed user authentication for R11e-LTE when new firmware is used;
*) m11g - improved ethernet performance on high load;
*) netinstall - fixed missing "/flash/etc" on first bootup;
*) quickset - renamed router IP static DNS name to "router.lan"
*) radius - limited RADIUS timeout maximum value to 3 seconds;
*) sms - fixed minor problem for SMS delivery;
*) webfig - added favicon file;
*) webfig - fixed terminal graphic user interface under Safari browser;
*) winbox - do not show unnecessary tabs from "Switch" menu;
*) wireless - new driver with initial support for 160 and 80+80 MHz channel width;

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after crash.
MikroTik Support Number: 2017110722001161

Client devices affected for sure: Roku 3 (2.4GHz), Motorola G Gen3 (2.4GHz)

After upgrading one of my WAP AC's to 6.41rc50 from 6.41rc44 this has been happening. I'll be trying 6.41rc52 to see if it resolves the issue before reverting back to 6.41rc44.
nov/06 18:36:22 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -70 
nov/06 18:37:21 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 18:37:21 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71 
nov/06 18:37:26 wireless,info DC:3A:5E:95:9B:BF@wlan1: reassociating 
nov/06 18:37:26 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, ok 
nov/06 18:37:26 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
nov/06 18:51:34 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 18:51:34 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -60 
nov/06 19:04:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, group key exchange timeout 
nov/06 19:04:24 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, group key exchange timeout 
nov/06 19:04:39 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -90 
nov/06 19:04:46 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -61 
nov/06 19:35:22 wireless,info E8:DE:27:14:C5:39@wlan2: connected, signal strength -65 
nov/06 19:35:22 wireless,info E8:DE:27:14:C5:39@wlan1: disconnected, registered to other interface 
nov/06 19:54:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, group key exchange timeout 
nov/06 19:54:26 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
nov/06 19:54:34 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 19:54:35 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67 
nov/06 20:02:20 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 20:02:20 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -77 
nov/06 20:05:41 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 20:05:41 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -68 
nov/06 20:09:24 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, group key exchange timeout 
nov/06 20:09:34 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -80 
nov/06 20:09:36 wireless,info AC:18:26:4C:A6:EC@wlan1: reassociating 
nov/06 20:09:36 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, ok 
nov/06 20:09:36 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -75 
nov/06 20:09:41 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, unicast key exchange timeout 
nov/06 20:10:00 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -76 
nov/06 20:10:15 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 20:10:16 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71 
nov/06 20:10:21 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 20:10:21 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64 
nov/06 20:10:21 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received deauth: class 2 frame received (6) 
nov/06 20:10:34 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -61 
nov/06 20:19:23 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 20:19:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66 
nov/06 20:19:24 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, group key exchange timeout 
nov/06 20:19:29 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 20:20:47 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67 
nov/06 20:20:50 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -82 
nov/06 20:22:32 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 20:22:32 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -75 
nov/06 20:27:05 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 20:27:11 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -63 
nov/06 20:27:16 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 20:27:25 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -60 
nov/06 20:29:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, group key exchange timeout 
nov/06 20:29:25 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67 
nov/06 20:31:39 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 20:31:44 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71 
nov/06 20:34:24 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, group key exchange timeout 
nov/06 20:34:44 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -79 
nov/06 20:34:47 wireless,info AC:18:26:4C:A6:EC@wlan1: reassociating 
nov/06 20:34:47 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, ok 
nov/06 20:34:47 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -84 
nov/06 20:34:52 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, unicast key exchange timeout 
nov/06 20:35:28 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -76 
nov/06 20:36:51 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 20:36:52 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67 
nov/06 20:36:57 wireless,info DC:3A:5E:95:9B:BF@wlan1: reassociating 
nov/06 20:36:57 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, ok 
nov/06 20:36:57 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
nov/06 20:39:11 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 20:39:11 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66 
nov/06 20:48:42 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 20:49:01 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66 
nov/06 21:33:26 wireless,info E8:DE:27:14:C5:39@wlan2: reassociating 
nov/06 21:33:26 wireless,info E8:DE:27:14:C5:39@wlan2: disconnected, ok 
nov/06 21:33:26 wireless,info E8:DE:27:14:C5:39@wlan2: connected, signal strength -65 
nov/06 21:44:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, group key exchange timeout 
nov/06 21:44:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout 
nov/06 21:44:27 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -72 
nov/06 21:44:27 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -60, wants bridge 
nov/06 21:44:31 wireless,info DC:3A:5E:95:9B:BF@wlan1: reassociating 
nov/06 21:44:31 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, ok 
nov/06 21:44:31 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -60 
nov/06 21:45:54 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 21:45:54 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -60 
nov/06 21:49:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, group key exchange timeout 
nov/06 21:49:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout 
nov/06 21:49:25 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64 
nov/06 21:49:26 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -59, wants bridge 
nov/06 21:53:43 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 21:53:44 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -60 
nov/06 21:57:18 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 21:57:37 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66 
nov/06 22:01:16 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 22:01:17 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
nov/06 22:01:23 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 22:01:23 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
nov/06 22:04:36 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 22:04:37 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71 
nov/06 22:04:42 wireless,info DC:3A:5E:95:9B:BF@wlan1: reassociating 
nov/06 22:04:42 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, ok 
nov/06 22:04:42 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67 
nov/06 22:07:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 22:07:25 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
nov/06 22:11:45 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 22:11:46 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71 
nov/06 22:11:51 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 22:11:51 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -60 
nov/06 22:11:51 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received deauth: class 2 frame received (6) 
nov/06 22:12:04 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
nov/06 22:19:15 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 22:19:21 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -59 
nov/06 22:19:26 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 22:19:34 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -60 
nov/06 22:31:40 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 22:31:41 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -75 
nov/06 22:39:04 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 22:39:05 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -69 
nov/06 22:39:10 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 22:39:41 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67 
nov/06 22:51:22 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 22:51:23 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67 
nov/06 22:59:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout 
nov/06 22:59:24 wireless,info 68:C4:4D:EE:F0:DF@wlan2: disconnected, group key exchange timeout 
nov/06 22:59:40 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -76, wants bridge 
nov/06 23:03:18 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 23:03:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -70 
nov/06 23:03:29 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 23:03:37 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -61 
nov/06 23:12:12 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 23:12:13 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -68 
nov/06 23:12:18 wireless,info DC:3A:5E:95:9B:BF@wlan1: reassociating 
nov/06 23:12:18 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, ok 
nov/06 23:12:18 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -60 
nov/06 23:12:23 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 23:12:31 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -60 
nov/06 23:15:43 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -71 
nov/06 23:16:00 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 23:16:01 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -70 
nov/06 23:16:06 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 23:16:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -72 
nov/06 23:16:29 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 23:16:48 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
nov/06 23:16:50 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -44 
nov/06 23:17:01 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
nov/06 23:17:06 wireless,info DC:3A:5E:95:9B:BF@wlan1: reassociating 
nov/06 23:17:06 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, ok 
nov/06 23:17:06 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -72 
nov/06 23:17:11 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 23:17:37 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -75 
nov/06 23:18:50 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 23:18:56 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66 
nov/06 23:19:01 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 23:19:14 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66 
nov/06 23:19:19 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 23:19:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
nov/06 23:19:28 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66 
nov/06 23:20:15 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 23:20:16 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66 
nov/06 23:20:21 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 23:20:34 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
nov/06 23:21:08 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 23:21:09 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
nov/06 23:24:49 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 23:24:53 wireless,info 68:C4:4D:EE:F0:DF@wlan2: connected, signal strength -52 
nov/06 23:24:55 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -61 
nov/06 23:25:39 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -64 
nov/06 23:28:13 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -52 
nov/06 23:28:28 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 23:28:34 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64 
nov/06 23:28:47 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
nov/06 23:29:04 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -50 
nov/06 23:29:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout 
nov/06 23:29:24 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, group key exchange timeout 
nov/06 23:29:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
nov/06 23:29:36 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 23:29:58 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -69, wants bridge 
nov/06 23:30:00 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -70 
nov/06 23:30:09 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -60 
nov/06 23:30:12 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -79 
nov/06 23:30:15 wireless,info AC:18:26:4C:A6:EC@wlan1: reassociating 
nov/06 23:30:15 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, ok 
nov/06 23:30:15 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -83 
nov/06 23:30:17 wireless,info AC:18:26:4C:A6:EC@wlan1: reassociating 
nov/06 23:30:17 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, ok 
nov/06 23:30:17 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -79 
nov/06 23:30:18 wireless,info AC:18:26:4C:A6:EC@wlan1: reassociating 
nov/06 23:30:18 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, ok 
nov/06 23:30:18 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -82 
nov/06 23:30:23 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, unicast key exchange timeout 
nov/06 23:30:43 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
nov/06 23:33:35 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 23:33:59 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64 
nov/06 23:34:04 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 23:34:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout 
nov/06 23:34:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
nov/06 23:34:29 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -59 
nov/06 23:34:40 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -64, wants bridge 
nov/06 23:35:01 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -78 
nov/06 23:35:06 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, unicast key exchange timeout 
nov/06 23:35:33 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -74 
nov/06 23:35:34 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, received deauth: class 2 frame received (6) 
nov/06 23:38:46 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -77 
nov/06 23:38:53 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, unicast key exchange timeout 
nov/06 23:39:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
nov/06 23:40:18 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -64 
nov/06 23:40:39 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67 
nov/06 23:41:50 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -59 
nov/06 23:42:22 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
nov/06 23:42:24 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -50 
nov/06 23:43:00 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
nov/06 23:43:13 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -64 
nov/06 23:44:07 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 23:44:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
nov/06 23:44:30 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71 
nov/06 23:45:29 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: reassociating 
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: disconnected, ok 
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: connected, signal strength -65 
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: reassociating 
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: disconnected, ok 
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: connected, signal strength -64 
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: reassociating 
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: disconnected, ok 
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: connected, signal strength -64 
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: reassociating 
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: disconnected, ok 
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: connected, signal strength -67 
nov/06 23:46:01 wireless,info E8:DE:27:14:C5:39@wlan1: connected, signal strength -66 
nov/06 23:46:01 wireless,info E8:DE:27:14:C5:39@wlan2: disconnected, registered to other interface 
nov/06 23:49:29 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 23:49:34 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
nov/06 23:52:55 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 23:53:21 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -45 
nov/06 23:54:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
nov/06 23:54:55 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -70 
nov/06 23:55:00 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 23:55:32 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64 
nov/06 23:55:37 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 23:56:32 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71 
nov/06 23:58:28 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -44 
nov/06 23:59:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
nov/06 23:59:31 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62 
00:02:46 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
00:02:47 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66 
00:02:53 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
00:02:54 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66 
00:04:18 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
00:04:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -63 
00:06:40 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
00:07:22 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64 
00:09:15 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -43 
00:09:20 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, unicast key exchange timeout 
00:09:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout 
00:09:28 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -71, wants bridge 
00:10:51 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -46 
00:11:18 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
00:11:56 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67 
00:12:01 wireless,info DC:3A:5E:95:9B:BF@wlan1: reassociating 
00:12:01 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, ok 
00:12:01 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -73 
00:12:06 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
00:12:28 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
00:12:37 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67 
00:13:25 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
00:13:26 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67 
00:13:28 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
00:13:59 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
00:14:00 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -70 
00:17:05 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -52 
00:17:10 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, unicast key exchange timeout 
00:17:19 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
00:17:44 wireless,info 68:C4:4D:EE:F0:DF@wlan1: connected, signal strength -87 
00:17:44 wireless,info 68:C4:4D:EE:F0:DF@wlan2: disconnected, registered to other interface 
00:18:01 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -76 
00:18:06 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
00:18:20 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71 
00:20:29 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62 
00:25:26 wireless,info 68:C4:4D:EE:F0:DF@wlan1: disconnected, received deauth: sending station leaving (3) 
00:25:39 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
00:25:47 wireless,info 68:C4:4D:EE:F0:DF@wlan2: connected, signal strength -78 
00:28:09 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
00:29:09 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -62 
00:31:50 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62 
00:33:04 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
00:33:41 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -62 
00:34:43 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -64 
00:36:37 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
00:36:45 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
00:36:50 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71 
00:36:58 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
00:41:46 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
00:41:47 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64 
00:41:52 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
00:42:28 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -63 
00:43:26 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
00:43:32 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67 
00:43:59 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62 
00:44:06 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -75 
00:44:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
00:44:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout 
00:44:29 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
00:44:35 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -70 
00:44:42 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
00:44:42 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -69, wants bridge 
00:44:43 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64 
00:47:02 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
00:47:07 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67 
00:49:05 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
00:51:33 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
00:51:39 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -62 
00:58:36 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -63 
00:59:20 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
00:59:25 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -62 
00:59:29 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -79 
01:00:36 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
01:04:15 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
01:05:30 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
01:05:31 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67 
01:05:35 wireless,info DC:3A:5E:95:9B:BF@wlan1: reassociating 
01:05:35 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, ok 
01:05:35 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -59 
01:09:41 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
01:09:46 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -61 
01:09:51 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -66 
01:12:10 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
01:12:16 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64 
01:14:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
01:16:06 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
01:16:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -60 
01:16:53 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -65 
01:19:15 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
01:19:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, group key exchange timeout 
01:19:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout 
01:19:24 wireless,info E8:DE:27:14:C5:39@wlan1: disconnected, group key exchange timeout 
01:19:39 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -65, wants bridge 
01:19:46 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64 
01:20:00 wireless,info E8:DE:27:14:C5:39@wlan2: connected, signal strength -65 
01:20:16 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -68 
01:20:32 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
01:21:10 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66 
01:21:15 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
01:21:33 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -62 
01:24:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
01:26:12 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
01:26:18 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -61 
01:26:48 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -64 
01:26:58 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62 
01:28:41 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
01:31:10 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -66 
01:31:55 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
01:32:01 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -58 
01:32:06 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
01:32:33 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -63 
01:32:36 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
01:32:37 wireless,info DC:3A:5E:95:9B:BF@wlan1: reassociating 
01:32:37 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, ok 
01:32:37 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -70 
01:32:40 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
01:34:36 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
01:34:37 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
01:35:55 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
01:35:55 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -68 
01:37:39 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -67 
01:39:21 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
01:39:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
01:39:26 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -70 
01:40:44 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
01:40:45 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71 
01:41:44 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -66 
01:43:01 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
01:43:39 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
01:43:44 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
01:43:46 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
01:44:02 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71 
01:51:20 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -63 
01:56:28 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
02:03:30 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -63 
02:07:27 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -66 
02:08:36 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
02:09:04 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
02:12:32 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -64 
02:13:26 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
02:13:35 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
02:13:40 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -59 
02:16:29 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -63 
02:21:36 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
02:24:24 wireless,info 10:02:B5:B0:AD:47@wlan2: disconnected, group key exchange timeout 
02:28:10 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -69 
02:29:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
02:33:33 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -66 
02:34:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
02:41:05 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
02:41:10 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -62 
02:41:15 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62 
02:44:55 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -63 
02:46:23 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
02:47:47 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
02:47:53 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -63 
02:49:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
02:51:07 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
02:51:08 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -58 
02:53:25 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -63 
02:54:24 wireless,info 00:0F:60:08:1F:5B@wlan1: disconnected, group key exchange timeout 
02:54:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, group key exchange timeout 
02:54:28 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66 
02:56:09 wireless,info 00:0F:60:08:1F:5B@wlan1: connected, signal strength -53 
02:56:14 wireless,info 00:0F:60:08:1F:5B@wlan1: disconnected, unicast key exchange timeout 
02:56:15 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
02:56:38 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -70 
02:58:35 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
02:59:25 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -66 
03:04:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, group key exchange timeout 
03:04:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
03:04:36 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64 
03:07:12 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62 
03:10:22 wireless,info 00:0F:60:08:1F:5B@wlan1: connected, signal strength -55 
03:12:23 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
03:15:39 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -64 
03:17:00 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
03:17:19 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -63 
03:22:30 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
03:31:02 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -64 
03:32:36 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
03:34:45 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62 
03:36:05 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -70 
03:39:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
03:39:50 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
03:46:38 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -64 
03:48:09 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
03:50:55 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
03:50:56 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
03:51:43 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -64 
03:52:42 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
03:52:48 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64 
03:55:40 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
03:55:46 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -63 
04:04:20 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -61 
04:04:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
04:04:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, group key exchange timeout 
04:04:28 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
04:07:16 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -80 
04:09:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
04:09:29 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
04:19:36 wireless,info 68:C4:4D:EE:F0:DF@wlan1: connected, signal strength -78 
04:19:37 wireless,info 68:C4:4D:EE:F0:DF@wlan2: disconnected, registered to other interface 
04:28:35 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62 
04:33:40 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
04:34:46 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -65 
04:40:34 wireless,info 68:C4:4D:EE:F0:DF@wlan1: disconnected, received deauth: sending station leaving (3) 
04:40:37 wireless,info 68:C4:4D:EE:F0:DF@wlan2: connected, signal strength -82 
04:47:01 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62 
04:52:10 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
04:56:33 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -65 
05:01:40 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
05:10:05 wireless,info B8:A1:75:48:3C:29@wlan1: connected, signal strength -64 
05:10:10 wireless,info B8:A1:75:48:3C:29@wlan1: disconnected, unicast key exchange timeout 
05:10:42 wireless,info B8:A1:75:48:3C:29@wlan1: connected, signal strength -76 
05:11:48 wireless,info 68:C4:4D:EE:F0:DF@wlan1: connected, signal strength -81 
05:11:51 wireless,info 68:C4:4D:EE:F0:DF@wlan2: disconnected, registered to other interface 
05:14:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
05:14:37 wireless,info B8:A1:75:48:3C:29@wlan1: disconnected, received disassoc: sending station leaving (8) 
05:14:38 wireless,info B8:A1:75:48:3C:29@wlan1: connected, signal strength -75 
05:16:33 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -72 
05:16:48 wireless,info B8:A1:75:48:3C:29@wlan1: disconnected, received disassoc: sending station leaving (8) 
05:17:48 wireless,info B8:A1:75:48:3C:29@wlan1: connected, signal strength -69 
05:17:53 wireless,info B8:A1:75:48:3C:29@wlan1: disconnected, unicast key exchange timeout 
05:18:04 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
05:18:25 wireless,info B8:A1:75:48:3C:29@wlan1: connected, signal strength -86 
05:19:48 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
05:19:48 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
05:20:17 wireless,info 68:C4:4D:EE:F0:DF@wlan1: disconnected, received deauth: sending station leaving (3) 
05:20:26 wireless,info 68:C4:4D:EE:F0:DF@wlan2: connected, signal strength -77 
05:22:44 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -63 
05:23:35 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -75 
05:25:54 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
05:25:54 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -62 
05:27:52 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
05:31:33 wireless,info 68:C4:4D:EE:F0:DF@wlan1: connected, signal strength -84 
05:31:33 wireless,info 68:C4:4D:EE:F0:DF@wlan2: disconnected, registered to other interface 
05:44:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
05:46:52 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -64 
05:48:56 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -64 
05:49:54 wireless,info 68:C4:4D:EE:F0:DF@wlan1: disconnected, received deauth: sending station leaving (3) 
05:49:57 wireless,info 68:C4:4D:EE:F0:DF@wlan1: connected, signal strength -78 
05:50:02 wireless,info 68:C4:4D:EE:F0:DF@wlan1: disconnected, received deauth: sending station leaving (3) 
05:50:09 wireless,info 68:C4:4D:EE:F0:DF@wlan2: connected, signal strength -81 
05:54:05 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
05:55:14 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
05:56:23 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64 
05:56:28 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
05:56:39 wireless,info 68:C4:4D:EE:F0:DF@wlan1: connected, signal strength -80 
05:56:42 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71 
05:56:42 wireless,info 68:C4:4D:EE:F0:DF@wlan2: disconnected, registered to other interface 
05:56:45 wireless,info 68:C4:4D:EE:F0:DF@wlan1: disconnected, received deauth: sending station leaving (3) 
05:56:47 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
05:56:48 wireless,info 68:C4:4D:EE:F0:DF@wlan2: connected, signal strength -78 
05:56:49 wireless,info B8:A1:75:48:3C:29@wlan1: disconnected, extensive data loss 
05:57:00 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -74 
05:57:05 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
05:57:22 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
05:57:23 wireless,info DC:3A:5E:95:9B:BF@wlan2: connected, signal strength -77 
06:01:07 wireless,info 68:C4:4D:EE:F0:DF@wlan1: connected, signal strength -78 
06:01:07 wireless,info 68:C4:4D:EE:F0:DF@wlan2: disconnected, registered to other interface 
06:02:37 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -73 
06:03:37 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
06:04:01 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -65 
06:09:12 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
06:13:16 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62 
06:16:31 wireless,info 68:C4:4D:EE:F0:DF@wlan1: disconnected, received deauth: sending station leaving (3) 
06:16:39 wireless,info 68:C4:4D:EE:F0:DF@wlan2: connected, signal strength -79 
06:17:02 wireless,info 68:C4:4D:EE:F0:DF@wlan1: connected, signal strength -73 
06:17:03 wireless,info 68:C4:4D:EE:F0:DF@wlan2: disconnected, registered to other interface 
06:18:00 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -75 
06:18:21 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
06:19:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
06:23:34 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -80 
06:24:23 wireless,info 68:C4:4D:EE:F0:DF@wlan1: disconnected, received deauth: sending station leaving (3) 
06:24:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
06:24:34 wireless,info 68:C4:4D:EE:F0:DF@wlan1: connected, signal strength -72 
06:26:38 wireless,info 68:C4:4D:EE:F0:DF@wlan1: disconnected, received deauth: sending station leaving (3) 
06:26:41 wireless,info 68:C4:4D:EE:F0:DF@wlan2: connected, signal strength -83 
06:33:36 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -87 
06:41:37 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62 
06:44:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout 
06:44:29 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -65, wants bridge 
06:46:41 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
06:49:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
06:49:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout 
06:49:26 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -68, wants bridge 
06:49:34 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -76 
06:54:24 wireless,info 00:0F:60:08:1F:5B@wlan1: disconnected, group key exchange timeout 
06:54:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
06:54:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout 
06:54:28 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -67, wants bridge 
06:54:54 wireless,info 00:0F:60:08:1F:5B@wlan1: connected, signal strength -55 
07:00:00 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -72 
07:00:32 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
07:00:33 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -73 
07:01:08 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
07:01:21 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -79 
07:08:28 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62 
07:09:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
07:09:25 wireless,info E8:DE:27:14:C5:39@wlan2: reassociating 
07:09:25 wireless,info E8:DE:27:14:C5:39@wlan2: disconnected, ok 
07:09:25 wireless,info E8:DE:27:14:C5:39@wlan2: connected, signal strength -65 
07:11:52 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -70 
07:13:59 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
07:16:38 wireless,info 68:C4:4D:EE:F0:DF@wlan1: connected, signal strength -84 
07:16:41 wireless,info 68:C4:4D:EE:F0:DF@wlan2: disconnected, registered to other interface 
07:16:57 wireless,info 68:C4:4D:EE:F0:DF@wlan2: connected, signal strength -87 
07:16:57 wireless,info 68:C4:4D:EE:F0:DF@wlan1: disconnected, registered to other interface 
07:17:05 wireless,info 68:C4:4D:EE:F0:DF@wlan2: disconnected, extensive data loss 
07:19:24 wireless,info 00:0F:60:08:1F:5B@wlan1: disconnected, group key exchange timeout 
07:19:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout 
07:19:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
07:19:26 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -58 
07:19:26 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -66, wants bridge 
07:19:56 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
07:19:58 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -55 
07:20:10 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
07:20:18 wireless,info 00:0F:60:08:1F:5B@wlan1: connected, signal strength -54 
07:20:55 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -61 
07:24:24 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, group key exchange timeout 
08:52:30 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -65 
08:53:11 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
08:54:58 wireless,info 2C:F0:A2:1F:56:4B@wlan1: connected, signal strength -79 
08:56:18 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -76 
08:56:51 wireless,info E8:DE:27:14:C5:39@wlan2: disconnected, extensive data loss 
08:57:22 wireless,info 10:02:B5:B0:AD:47@wlan2: connected, signal strength -70 
08:57:30 wireless,info E8:DE:27:14:C5:39@wlan2: connected, signal strength -62
Update, problem persists in 6.41rc52.
09:39:09 system,info verified routeros-mipsbe-6.41rc52.npk 
09:39:09 system,info installed routeros-mipsbe-6.41rc52 
09:39:09 system,info router rebooted 
09:39:12 bridge,info "br1" mac address changed to F6:20:18:E8:60:F6 
09:39:15 wireless,info F4:30:B9:B3:0F:ED@wlan1: connected, signal strength -59 
09:39:16 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66 
09:39:16 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -69, wants bridge 
09:39:21 wireless,info 00:0F:60:08:1F:5B@wlan1: connected, signal strength -54 
09:39:23 wireless,info B8:3E:59:B3:9B:0B@wlan2: connected, signal strength -46 
09:39:24 interface,info ether1 link up (speed 1G, full duplex) 
09:39:33 wireless,info E8:DE:27:14:C5:39@wlan2: connected, signal strength -65 
09:40:00 wireless,info E8:DE:27:14:C5:39@wlan2: disconnected, received deauth: sending station leaving (3) 
09:40:11 system,info,account user admin logged in from 10.211.11.11 via ssh 
09:40:13 wireless,info 10:02:B5:B0:AD:47@wlan2: connected, signal strength -70 
09:41:47 system,info cloud change time Nov/07/2017-09:40:30 => Nov/07/2017-09:41:47 
09:43:21 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
09:43:27 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -70 
09:44:37 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -68 
09:44:42 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, unicast key exchange timeout 
09:44:46 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -70 
09:44:51 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, unicast key exchange timeout 
09:45:13 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -73 
09:45:36 wireless,info F4:30:B9:B3:0F:ED@wlan1: disconnected, group key exchange timeout 
09:45:36 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, group key exchange timeout 
09:45:36 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout 
09:45:36 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
09:45:51 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -69, wants bridge 
09:45:55 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -79 
09:46:00 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66 
09:46:05 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
09:46:46 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -63 
09:46:51 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
09:48:18 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -72 
09:48:23 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
09:49:04 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
09:49:09 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
09:49:22 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -63 
09:49:27 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
09:49:41 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65
Final Update: Reverting to 6.41rc44 fixed my issues. I'll wait until >6.41rc52 before trying again on those devices. 6.41rc52 is functioning fine on my test 750Gr3 though (no wifi chips there).
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1407
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Nov 07, 2017 11:34 pm

RADIUS timeout value was reduced due to the fact that there is no point of higher value than 3s. Neither of RouterOS RADIUS services would wait more than 3s for a reply from RADIUS server. If you had value higher than 3 seconds, then either configuration will work with timeout set to 3s or it was not working properly even with higher value.

Anyway, RADIUS timeout (even set to 3s) is too high and requires debugging and network improvements since router should not wait so long for a reply from RADIUS server.
 
User avatar
eworm
Member
Member
Posts: 396
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Nov 08, 2017 12:18 am

For me the more important question about boot firmware is: Will the firmware version change with every RouterOS release even if no changes are made? Suppose you installed RouterOS 6.41, then upgraded firmware to 6.41. RouterOS 6.41.1 ships with no changes to the firmware. Is the available firmware version 6.41 or 6.41.1?
RouterOS 6.41rc52 ships with firmware version 6.41rc50... So looks like nothing changed except the version bump.
Manage RouterOS scripts and extend your devices' functionality: RouterOS Scripts
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Nov 08, 2017 6:44 pm

RADIUS timeout value was reduced due to the fact that there is no point of higher value than 3s. Neither of RouterOS RADIUS services would wait more than 3s for a reply from RADIUS server. If you had value higher than 3 seconds, then either configuration will work with timeout set to 3s or it was not working properly even with higher value.

Anyway, RADIUS timeout (even set to 3s) is too high and requires debugging and network improvements since router should not wait so long for a reply from RADIUS server.
Or people had other RADIUS services (devices) connecting to it. You know, because that never happens. #genius. Depending on the IOS version Cisco will timeout at 5 seconds. MikroTik employees. If you are confronted with the choice between allowing something to be configurable with a sensible default vs a static unchanging value always choose configurable.
 
User avatar
Cha0s
Forum Veteran
Forum Veteran
Posts: 903
Joined: Tue Oct 11, 2005 4:53 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Nov 08, 2017 7:49 pm

For me the more important question about boot firmware is: Will the firmware version change with every RouterOS release even if no changes are made? Suppose you installed RouterOS 6.41, then upgraded firmware to 6.41. RouterOS 6.41.1 ships with no changes to the firmware. Is the available firmware version 6.41 or 6.41.1?
RouterOS 6.41rc52 ships with firmware version 6.41rc50... So looks like nothing changed except the version bump.
I've upgraded a mAP-Lite from 6.40.4 to 6.41rc52.

The firmware prior to the upgrade was on v3.41.
So it showed me that the upgrade firmware is 6.41rc50.

But after I upgraded the firmware I got this:
Current Firmware: 6.41rc52
Upgrade Firmware: 6.41rc50
http://prntscr.com/h7w38h
 
User avatar
eworm
Member
Member
Posts: 396
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Nov 08, 2017 10:44 pm

For me the more important question about boot firmware is: Will the firmware version change with every RouterOS release even if no changes are made? Suppose you installed RouterOS 6.41, then upgraded firmware to 6.41. RouterOS 6.41.1 ships with no changes to the firmware. Is the available firmware version 6.41 or 6.41.1?
RouterOS 6.41rc52 ships with firmware version 6.41rc50... So looks like nothing changed except the version bump.
I've upgraded a mAP-Lite from 6.40.4 to 6.41rc52.

The firmware prior to the upgrade was on v3.41.
So it showed me that the upgrade firmware is 6.41rc50.

But after I upgraded the firmware I got this:
Current Firmware: 6.41rc52
Upgrade Firmware: 6.41rc50
http://prntscr.com/h7w38h
Oh, funny... I have a system that is running RouterOS 6.41rc52, with current and upgrade firmware at 6.41rc50. Started a firmware upgrade, after a reboot I can confirm your results.
Well, that will make my upgrade notification scripts go crazy... :-p
Manage RouterOS scripts and extend your devices' functionality: RouterOS Scripts
 
JimmyNyholm
Member Candidate
Member Candidate
Posts: 249
Joined: Mon Apr 25, 2016 2:16 am
Location: Sweden

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 10, 2017 11:34 am

When do we get LACP with Hardware offload in this new bridge implementation in routeros on switch devices such as CRS326-24G-2S+ and CRS-317-1G-16s+
Creating a bond and attaching it to the bride is done in software now and good know the cpu's in the switches is weak as hell.
 
kamillo
Member Candidate
Member Candidate
Posts: 155
Joined: Tue Jul 15, 2014 5:44 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 10, 2017 1:06 pm

To add to JimmyNyholm's comment: I'm still waiting for LACP hardware support (offload) in CRS125
 
biatche
Member Candidate
Member Candidate
Posts: 128
Joined: Tue Oct 13, 2015 6:50 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Nov 11, 2017 5:00 am

When do we get LACP with Hardware offload in this new bridge implementation in routeros on switch devices such as CRS326-24G-2S+ and CRS-317-1G-16s+
Creating a bond and attaching it to the bride is done in software now and good know the cpu's in the switches is weak as hell.
Forum police @andirys will probably ask you to post in feature request.

But yes, this is definitely needed in urgency.
 
ryba84
just joined
Posts: 10
Joined: Sat Feb 07, 2015 1:18 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sun Nov 12, 2017 3:38 pm

*) interface - added option to join and exclude "/interface list" from one and another;
How this works? Firewall is not using included list.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5834
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Nov 13, 2017 10:37 am

*) interface - added option to join and exclude "/interface list" from one and another;
How this works? Firewall is not using included list.
The default firewall is using lists now. When you have upgraded from versions previous to 6.40 all the time and never
reset the configuration, your firewall is still using the old method. However, when you reset everything to defaults you
will find it uses lists WAN and LAN to identify the interfaces.
It depends on the amount of work you have put in your config if it is worth the trouble, of course.
 
ryba84
just joined
Posts: 10
Joined: Sat Feb 07, 2015 1:18 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Nov 13, 2017 6:36 pm

Firewall uses interface lists, and this work for long time. But in new implementation You can include list in list, to use "master" list in firewall. This isn't working as expected. When Vpn clients are connecting, their dynamic interfaces are added to vpn-clients list. This list is included in some other list, which is used in firewall. Firewall should automaticly use this dynamic list to filter/nat/etc.., but this doesn't happen. Interfaces only from "master" list are working.

Wysłane z mojego SM-J710F przy użyciu Tapatalka
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 5934
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Nov 13, 2017 6:53 pm

@ryba84 report problem to support and attach supout rif file.
 
rac
just joined
Posts: 8
Joined: Fri Oct 15, 2010 4:47 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Nov 14, 2017 12:09 pm

I tryed to configure VLANs using the bridge hw offloading feature (CRS326). Basically:

/interface bridge port
add bridge=bridge interface=ether2 pvid=200
...
add bridge=bridge tagged=... untagged=ether02,.. vlan-ids=200
...
/interface bridge set bridge vlan-filtering=yes

I stuck in two tasks.
A) How to I secure the ports like "/interface ethernet switch port set ether3 vlan-mode=secure vlan-header=always-strip" on https://wiki.mikrotik.com/wiki/Manual:S ... Offloading?

I tried
/interface bridge port add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged ingress-filtering=yes interface=ether03 pvid=200
but I do not really understand if it does what I want.

B) I cannot access the RouterOS using a VLAN port. But I didn't found, how to configure VLAN for the switch host port?
 
biatche
Member Candidate
Member Candidate
Posts: 128
Joined: Tue Oct 13, 2015 6:50 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Nov 14, 2017 7:47 pm

I tryed to configure VLANs using the bridge hw offloading feature (CRS326). Basically:

/interface bridge port
add bridge=bridge interface=ether2 pvid=200
...
add bridge=bridge tagged=... untagged=ether02,.. vlan-ids=200
...
/interface bridge set bridge vlan-filtering=yes

I stuck in two tasks.
A) How to I secure the ports like "/interface ethernet switch port set ether3 vlan-mode=secure vlan-header=always-strip" on https://wiki.mikrotik.com/wiki/Manual:S ... Offloading?

I tried
/interface bridge port add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged ingress-filtering=yes interface=ether03 pvid=200
but I do not really understand if it does what I want.

B) I cannot access the RouterOS using a VLAN port. But I didn't found, how to configure VLAN for the switch host port?
you need to add your bridge interface to tagged ports.
 
raffav
Member Candidate
Member Candidate
Posts: 288
Joined: Wed Oct 24, 2012 4:40 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Nov 14, 2017 10:03 pm

Hi
i am unable set a untagged management ip address using a RB450G and a CRS125
i had followed the wifi but i dont get it

any one can help
 
marekm
Member Candidate
Member Candidate
Posts: 203
Joined: Tue Feb 01, 2011 11:27 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Nov 15, 2017 12:05 am

*) w60g - general work on PtMP implementation for 60 GHz connections;
Devices in the Wireless Wire kit come with Level 3 licenses - will it work with more than one client, or is it necessary to buy a Level 4 license to test 60GHz PtMP?
 
biatche
Member Candidate
Member Candidate
Posts: 128
Joined: Tue Oct 13, 2015 6:50 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Nov 15, 2017 1:03 am

Been a long day.

I'm tasting my first time experience on 10gbit sfp+ on CRS326. I have a 10gbit nic (also first time) connected directly to the CRS326 and couldn't figure out why iscsi rates to a single client in my test environment were unstable 10-40MB/sec, at times less than 10MB/sec, FAR slower than gigabit nic. Rates are stable on the gigabit ports (80MB/sec). I tested samba transfers on the sfp+, and speeds appear quick. So it's just iscsi where transfer rates are quite quirky.

After a lot of testing, trying to figure out where the point of issue is -- ixgbe driver, iscsi initiator/target, etc etc.. it finally hit me it could be the 6.41 bridge implementation.

Simply reverting to 6.40.5 gave me good stable expected rates.

So I'm simply reporting that sfp+ DEFINITELY have some hw offload issues or some other sort of issues. Sorry if my feedback isn't as clear as can be.

I hope you fellas are able to solve this on your own because I will not be able to test this again as the switch will be in live production this week.

Update: Contacted support and MT is already aware of the issue.
Last edited by biatche on Wed Nov 15, 2017 8:27 pm, edited 1 time in total.
 
User avatar
blajah
Member Candidate
Member Candidate
Posts: 224
Joined: Fri Jun 12, 2015 8:58 pm
Location: Belgrade, Serbia
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Nov 15, 2017 7:15 pm

For me the more important question about boot firmware is: Will the firmware version change with every RouterOS release even if no changes are made? Suppose you installed RouterOS 6.41, then upgraded firmware to 6.41. RouterOS 6.41.1 ships with no changes to the firmware. Is the available firmware version 6.41 or 6.41.1?
RouterOS 6.41rc52 ships with firmware version 6.41rc50... So looks like nothing changed except the version bump.
I've upgraded a mAP-Lite from 6.40.4 to 6.41rc52.

The firmware prior to the upgrade was on v3.41.
So it showed me that the upgrade firmware is 6.41rc50.

But after I upgraded the firmware I got this:
Current Firmware: 6.41rc52
Upgrade Firmware: 6.41rc50
http://prntscr.com/h7w38h
Same here, 951g2hnd
 routerboard: yes
             model: 951G-2HnD
     serial-number: 4F4********
     firmware-type: ar9344
  factory-firmware: 3.10
  current-firmware: 6.41rc52
  upgrade-firmware: 6.41rc50
I have bigger routing table.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5834
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Nov 15, 2017 8:28 pm

I have installed it on an old RB750 I use for some test.
It shows:
Firmware type: ar7240
Factory firmware: 3.02
Current firmware: 3.33
Update firmware:
I.e. there is nothing after upgrade firmware and the upgrade button does nothing (no log entry).

Edit: I installed 6.40.5, upgraded the firmware to 3.41 from there, then went back to 6.41 (2 partitions on the router...) and
the issue is still the same.
Last edited by pe1chl on Thu Nov 16, 2017 3:07 pm, edited 1 time in total.
 
User avatar
eworm
Member
Member
Posts: 396
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Nov 16, 2017 11:34 am

Oh, funny... I have a system that is running RouterOS 6.41rc52, with current and upgrade firmware at 6.41rc50. Started a firmware upgrade, after a reboot I can confirm your results.
Well, that will make my upgrade notification scripts go crazy... :-p
Possibly a read-only property "upgrade-available" is the easiest way to solve this?
Manage RouterOS scripts and extend your devices' functionality: RouterOS Scripts
 
kait
just joined
Posts: 15
Joined: Thu May 10, 2012 12:09 pm
Location: Czech Republic

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Nov 16, 2017 11:53 am

Hi, I raise a new topic Bridge HW-Offload and VLAN-Filtering with CRS226-24G-2S+RM at v6.41rc52 here viewtopic.php?f=1&t=127805 , maybe someone can explain issue.
 
mducharme
Trainer
Trainer
Posts: 799
Joined: Tue Jul 19, 2016 6:45 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Nov 16, 2017 11:49 pm

RADIUS timeout value was reduced due to the fact that there is no point of higher value than 3s. Neither of RouterOS RADIUS services would wait more than 3s for a reply from RADIUS server. If you had value higher than 3 seconds, then either configuration will work with timeout set to 3s or it was not working properly even with higher value.

Anyway, RADIUS timeout (even set to 3s) is too high and requires debugging and network improvements since router should not wait so long for a reply from RADIUS server.
This makes no sense to me whatsoever. We have had it happen several times (in a particular scenario documented further below) where we had the timeout at first set to 3000 ms and the customer could not connect (due to the unusually high latency for bidirectional satellite Internet), but immediately after increasing the timeout, the customer connected successfully (after repeated automated connection attempts up until the instant of change). You are saying this is a coincidence? It seems really hard to believe given how many times it failed before making the change (several hours) and how immediately the change corrected the issue (after hours of trying to connect every minute and failing, the first connection after the change (30 seconds later) was successful).

We are dealing with bi-directional satellite so we have 600ms latency just to get up into orbit and back again with a ping, and we are dealing with very limited bandwidth. We cannot do "network improvements" to fix this.

Here is the precise justification for why 3000 ms is not enough with all attainable 'network improvements' implemented:

The initial RADIUS request from the satellite site takes 300-400 ms to get to the radius server due to limitations of the speed of light, then it has to look up the customer etc, probably half a second or second later it sends a reply which takes another 300-400ms to get back to the satellite site (again due to the limitations of the speed of light). This is now two seconds. This part is fine with your new limit, but the next part is not:

If the RADIUS server thinks the customer is already logged in, it contacts the MikroTik with SNMP to find out if there is actually an interface named <pppoe-customername>, this contact begins to happen at around the 2000 ms mark.

At this point, the RADIUS server has to send the SNMP request over satellite, receive the SNMP response over satellite, parse the list to determine whether the customer is logged in or not, and send the Access-Accept or Access-Reject reply back to the MikroTik. This entire process cannot happen in 3000 ms total from the opening authentication, when the basic authentication already uses 2000ms, and where each one way satellite transit thereafter takes 300-400 ms due to the limitation of the speed of light.

Suggesting that we make "network improvements" to fix this is basically asking us to move the satellite in orbit closer to the planet, or make the speed of light faster. It is not something that we can do. We are already doing queueing everywhere to prioritize the RADIUS and SNMP requests. 3000 ms is just not enough when you start taking satellite setups like ours into account. We really need this change reverted, or at least a more reasonable maximum of 5000 or 6000ms used. We have fixed this issue successfully by increasing the timeout on our routers to 6000ms but you have removed this repair from us by limiting this setting.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5834
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 17, 2017 10:38 am

I would say your network could be redesigned so that the RADIUS requests do not have to go over the satellite. Apparently you are using the MikroTik as a local access concentrator for several customers that then use the same satellite link. It would help a lot to have the RADIUS service local to that location. Of course usermanager is very limited, but a small computer with a RADIUS server and maybe some other services for the customer (a webproxy, a local webserver, VoIP PBX, etc) could help the customers living with this high-latency link.
 
mducharme
Trainer
Trainer
Posts: 799
Joined: Tue Jul 19, 2016 6:45 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 17, 2017 11:48 am

I would say your network could be redesigned so that the RADIUS requests do not have to go over the satellite. Apparently you are using the MikroTik as a local access concentrator for several customers that then use the same satellite link. It would help a lot to have the RADIUS service local to that location. Of course usermanager is very limited, but a small computer with a RADIUS server and maybe some other services for the customer (a webproxy, a local webserver, VoIP PBX, etc) could help the customers living with this high-latency link.
It is not just one location - we have 15 such locations. We would need 15 RADIUS servers. These locations have no air conditioning and so the internal shelter goes up to 40C in the summer and down to -30C in the winter. Local RADIUS server is NOT a good idea.

What am I supposed to do, go and tell my manager "yes, it is great that MikroTik is forcing us to buy 15 local RADIUS servers for 15 sites that will probably fail within a year or two due to inadequate environmental controls, all because they decided to limit an integer to 3000 that previously allowed 6000"??

Every time there is a failure at one of those 15 sites we have to fly in for a cost of more than a thousand dollars round trip. There are only usually between 2 and 15 customers at a given site, so in many cases we are losing money because what we charge customers in total is much less than what we have to pay for service; although we are a non profit we should still be trying at least to break even.

Putting in a local RADIUS server is not a good solution, so if this is not reverted, we will need to stay at RouterOS 6.40.x and under permanently at 15 sites, never being able to upgrade. This makes me a bit nervous, but is preferable to the alternative of having to buy 15 RADIUS servers each of which will be put in remote areas in outdoor shelters with no environmental controls.
Last edited by mducharme on Fri Nov 17, 2017 12:15 pm, edited 1 time in total.
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8310
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 17, 2017 12:03 pm

One more solution: if it works good - do not upgrade :)

Worked for me when MikroTik broke VLANs over bonding :)
Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

For every complex problem, there is a solution that is simple, neat, and wrong.

MikroTik. Your life. Your routing.
 
biatche
Member Candidate
Member Candidate
Posts: 128
Joined: Tue Oct 13, 2015 6:50 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 17, 2017 12:35 pm

I atest to mducharme's complaints. There's no harm reverting the RADIUS timeout value change is there? Could issue a warning of some sort for those who set values in excess of recommended.

Waiting for MT's good news now.
 
mducharme
Trainer
Trainer
Posts: 799
Joined: Tue Jul 19, 2016 6:45 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 17, 2017 9:48 pm

FYI, Cisco docs say the maximum RADIUS timeout on their gear is 1000 seconds. Juniper maximum is 90 seconds. Both seem a bit extreme, but that just shows how far from a 3 second maximum other vendors are.
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 17, 2017 10:00 pm

These complaints are exactly why arbitrary hard setting a value is bad when it can be valid within a range. This includes what a developer personally feels is acceptable.
 
User avatar
neg2led
just joined
Posts: 8
Joined: Tue Feb 16, 2016 1:19 pm
Location: Melbourne, Australia
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Nov 18, 2017 4:58 am

I think we might be missing the forest for the trees here, guys.

MT say that the reduction here shouldn't make a difference. In this post by strods from page 7, strods says that neither of the routerOS RADIUS client processes will wait more than 3 seconds even if the timeout setting is greater than 3 seconds - important part in bold for emphasis;
RADIUS timeout value was reduced due to the fact that there is no point of higher value than 3s. Neither of RouterOS RADIUS services would wait more than 3s for a reply from RADIUS server. If you had value higher than 3 seconds, then either configuration will work with timeout set to 3s or it was not working properly even with higher value.

Anyway, RADIUS timeout (even set to 3s) is too high and requires debugging and network improvements since router should not wait so long for a reply from RADIUS server.
Ignoring the part about RADIUS taking more than 3 seconds being unacceptable for the time being, as described by strods, this change should not have resulted in a regression of functionality, as the RADIUS client inside routerOS was not honoring timeouts above 3 seconds to begin with. Based on what mducharme says above, this does not appear to be the case.

He reports that he's seeing different behavior with the timeout hard-set to 3sec, when compared to the 6sec available before. This is a regression in functionality and directly contrary to the information given by MT (strods) - in short, this is a bug. Either MT themselves are incorrect about the behaviour of the client when given timeouts above 3s (and mducharme's 6s timeout on older FW versions was making a difference), or something else has changed that otherwise breaks his admittedly unusual but completely valid configuration.

As mducharme has demonstrated, while unusual, it's not unreasonable for RADIUS to take some seconds to reply, and alternate vendors appear to have max timeouts in the 30-90 second range at the very least. We can argue about arbitrary configuration constraints until we're blue in the face, but it's not relevant to the issue at hand here.

MT: What's your explanation for why mducharme's configuration here works on 6.40 but not on 6.41?
mducharme: Have you opened a support ticket for this regression & provided supout.rifs etc? This isn't an official support channel, and it sounds like you should be talking to support if you aren't already.
 
User avatar
blajah
Member Candidate
Member Candidate
Posts: 224
Joined: Fri Jun 12, 2015 8:58 pm
Location: Belgrade, Serbia
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Nov 18, 2017 5:39 pm

I have installed it on an old RB750 I use for some test.
It shows:
Firmware type: ar7240
Factory firmware: 3.02
Current firmware: 3.33
Update firmware:
I.e. there is nothing after upgrade firmware and the upgrade button does nothing (no log entry).

Edit: I installed 6.40.5, upgraded the firmware to 3.41 from there, then went back to 6.41 (2 partitions on the router...) and
the issue is still the same.
Regarding all this with firmware, i have found this in changelog in RC channel:

!) routerboot - RouterBOOT version numbering system merged with RouterOS;
I have bigger routing table.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5834
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Nov 18, 2017 10:12 pm

That is why I mention that there is an issue with the RB750 firmware - as this is the release candidate topic and developers are hopefully reading it before doing a release.
 
mducharme
Trainer
Trainer
Posts: 799
Joined: Tue Jul 19, 2016 6:45 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sun Nov 19, 2017 3:09 am

He reports that he's seeing different behavior with the timeout hard-set to 3sec, when compared to the 6sec available before. This is a regression in functionality and directly contrary to the information given by MT (strods) - in short, this is a bug. Either MT themselves are incorrect about the behaviour of the client when given timeouts above 3s (and mducharme's 6s timeout on older FW versions was making a difference), or something else has changed that otherwise breaks his admittedly unusual but completely valid configuration.
Exactly, my own observations of the behavior of earlier versions do not jibe with what strods claims to be the case. It seems extremely unlikely that it was coincidental that the issue vanished when I made the change, given the circumstances.
mducharme: Have you opened a support ticket for this regression & provided supout.rifs etc? This isn't an official support channel, and it sounds like you should be talking to support if you aren't already.
No I haven't, only because I would have to upgrade to 6.41 at one of those satellite sites (15 of our 45 sites are connected via satellite). However I don't need a test to tell me what effect limiting the maximum value will have when we are currently using 6000 ms, and given my previous experiences. We could maybe get by with 5000ms, possibly even 4000ms, but if the RADIUS server thinks the customer is still logged in, it will only authenticate in 3000ms if the stars are in perfect alignment due to the extra time required to pull the list of logged in customers. Due to the power requirements of the satellite amplifiers they cannot be connected to the UPS, so when the power goes down at the site (some sites are on unreliable diesel) the satellite feed goes down immediately. If customers log off during this time (common b/c they usually lose power as well), the RADIUS disconnect notification doesn't make it to the RADIUS server because, with the satellite link down, there is no way for the packet to reach its destination. When the site comes back up again, the RADIUS server sees the customers trying to log in again and it thinks they are already logged in, so before it sends the 'accept' or 'reject' it has to go to the router and check to see if they actually are still logged in. Customers sometimes share their PPPoE credentials with friends to try to give them free service, so this check is necessary to protect against that.

We try to centralize as much as possible and minimize the equipment at the site, less equipment means less that can break - it is cheaper for me to fly to Hawaii than to go to some of our sites. The central RADIUS server is a necessity for us, and it is just not viable to optimize it more than we already have. We have already had to change some FreeRADIUS code to use snmpbulkwalk instead of snmpwalk to avoid needing 25-30 second timeouts, and I do not think we can reduce this any further given our previous efforts to provide QoS to prioritize RADIUS packets.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5834
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sun Nov 19, 2017 11:24 am

No I haven't, only because I would have to upgrade to 6.41 at one of those satellite sites (15 of our 45 sites are connected via satellite).
You have 15 sites of a problematic type for which it costs $1000 to make a support visit and you don't have a way to test a similar site from home (a subscription to the same satellite service)?
Really? It all does not seem very professional...
 
mducharme
Trainer
Trainer
Posts: 799
Joined: Tue Jul 19, 2016 6:45 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sun Nov 19, 2017 9:05 pm

You have 15 sites of a problematic type for which it costs $1000 to make a support visit and you don't have a way to test a similar site from home (a subscription to the same satellite service)?
Really? It all does not seem very professional...
The dishes are 2.4 or 3.8 meters, so they are big (larger than a home satellite service). It is not easy like putting up an Xplornet dish on a home, these are very big and very heavy, they cannot be roof or wall mounted, unless maybe the roof was concrete and very thick, able to support the weight. So the dish would generally need to be on the ground with a concrete pad for stability and fencing to avoid people standing in front of the beam. Even if we had a place to install such a thing in our downtown urban office building, each dish has its own upload channel, so there would need to be one assigned to a "test dish" but all are in use since actual sites are priority. Therefore to operate a test dish with no channels we would need to shut down one of the 15 sites to free up a channel to bring up a test dish. It would be great to have a test system, it would make certain things easier, but it is just not feasible for all those reasons, so we have lived without it.
satellitepicture.PNG
You do not have the required permissions to view the files attached to this post.
 
msatter
Forum Guru
Forum Guru
Posts: 1243
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sun Nov 19, 2017 11:54 pm

I see a lot of postings about the Radius timeout and maybe Mikrotik is willing to add an option to choose for extended timeout.

Normal 3 seconds and when the extended timeout option is ticked let's say 90 seconds.
Two RB760iGS (hEX S) in series. One does PPPoE and both do IKEv2.
Running:
RouterOS 7.0/6.46Beta / Winbox 3.20 / MikroTik APP 1.3.4
Having an Android device, use https://github.com/M66B/NetGuard/releases (no root required)
 
troffasky
Member
Member
Posts: 395
Joined: Wed Mar 26, 2014 4:37 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Nov 20, 2017 7:18 pm

You have 15 sites of a problematic type for which it costs $1000 to make a support visit and you don't have a way to test a similar site from home (a subscription to the same satellite service)?
Don't need a satellite dish to emulate the behaviour of a typical satellite link:

https://wiki.linuxfoundation.org/networking/netem
 
LynxChaus
just joined
Posts: 24
Joined: Tue Jul 08, 2014 2:24 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Nov 20, 2017 11:10 pm

We could maybe get by with 5000ms, possibly even 4000ms, but if the RADIUS server thinks the customer is still logged in, it will only authenticate in 3000ms if the stars are in perfect alignment due to the extra time required to pull the list of logged in customers.
125ms need to reach satellite and 125ms to reach earth. Why you need HUGE timeout ? You bounce signal multiple times to orbit and back?
Due to the power requirements of the satellite amplifiers they cannot be connected to the UPS, so when the power goes down at the site (some sites are on unreliable diesel) the satellite feed goes down immediately. If customers log off during this time (common b/c they usually lose power as well), the RADIUS disconnect notification doesn't make it to the RADIUS server because, with the satellite link down, there is no way for the packet to reach its destination. When the site comes back up again, the RADIUS server sees the customers trying to log in again and it thinks they are already logged in, so before it sends the 'accept' or 'reject' it has to go to the router and check to see if they actually are still logged in. Customers sometimes share their PPPoE credentials with friends to try to give them free service, so this check is necessary to protect against that.

We try to centralize as much as possible and minimize the equipment at the site, less equipment means less that can break - it is cheaper for me to fly to Hawaii than to go to some of our sites. The central RADIUS server is a necessity for us, and it is just not viable to optimize it more than we already have. We have already had to change some FreeRADIUS code to use snmpbulkwalk instead of snmpwalk to avoid needing 25-30 second timeouts, and I do not think we can reduce this any further given our previous efforts to provide QoS to prioritize RADIUS packets.
You need only ONE snmpget to understand what happens with equipment and connected users - check sysUpTimeInstance (.1.3.6.1.2.1.1.3.0) and if it goes back - assume "power lost, all users disconnected" and drop it manually in radius. it's not rocket science.
 
mducharme
Trainer
Trainer
Posts: 799
Joined: Tue Jul 19, 2016 6:45 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Nov 21, 2017 1:19 am

125ms need to reach satellite and 125ms to reach earth. Why you need HUGE timeout ? You bounce signal multiple times to orbit and back?
Ping to the site across the satellite link is at least 600ms round trip, so 300ms each way. I have never seen latency drop below that. You are suggesting that round trip latency should be 250 ms or slightly higher, but that is just not realistic.
You need only ONE snmpget to understand what happens with equipment and connected users - check sysUpTimeInstance (.1.3.6.1.2.1.1.3.0) and if it goes back - assume "power lost, all users disconnected" and drop it manually in radius. it's not rocket science.
That requires extra programming, and won't work in some scenarios. The RADIUS server itself (FreeRADIUS) already has the SNMP check built in to poll the list of interfaces in event that it thinks the customer is already logged in - this did not need to be scripted as it is a built in feature, the RADIUS server does this SNMP check while the NAS is waiting for the 'accept' or 'reject'. What you are describing is an external script that would keep track of the uptime for each router and be able to tell if one went back and just disconnect the sessions for that router. It is certainly possible but such a script would have to be carefully tested. That also wouldn't help with a scenario where the router did not go down but the satellite lost power. A brief power outage would not knock the router offline, so the sysuptime would not go back. Unfortunately this also happens fairly frequently, so a solution that doesn't address this would not help.

A safer way would be to clear sessions if the interim-update interval is exceeded by, say, 4 times, but with an interim update interval of half an hour, customers could be down for up to two hours before the old session would clear.
 
sup5
Member
Member
Posts: 322
Joined: Sat Jul 10, 2010 12:37 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Nov 21, 2017 4:20 am

Another issue with a max. of 3 seconds radius timeout is this:
When the NAS reboots or a bunch of users is handed over from one NAS to another (PPPoE failover scenarios), reauthentication of these users will take ages. So users will complain.

The NAS kicks the users before the radius was able to reply. With enhanced radius timout of like let's say 7 seconds the users are authenticated very quickly.

This 'issue' is caused by a quite loaded Radius and Database server during this peak duration (NAS reboots => several thousand users to aithenticate immediatelly). A radius timout of max. 3 seconds only makes things worse here. The load on the radius increases!
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1407
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 24, 2017 3:09 pm

What's new in 6.41rc56 (2017-Nov-24 10:03):

Important note!!! Backup before upgrade!
RouterOS (v6.40rc36-rc40 and) v6.41rc1+ contains new bridge implementation that supports hardware offloading (hw-offload).
This update will convert all interface "master-port" configuration into new bridge configuration, and eliminate "master-port" option as such.
Bridge will handle all Layer2 forwarding and the use of switch-chip (hw-offload) will be automatically turned on based on appropriate conditions.
The rest of RouterOS Switch specific configuration remains untouched in usual menus for now.
Please, note that downgrading to previous RouterOS versions will not restore "master-port" configuration, so use backups to restore configuration on downgrade.


Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;
2) Make sure the device will not lose power during upgrade process;
3) Device has enough free storage space for all RouterOS packages to be downloaded.

Changes since previous 6.41rc release:

!) bridge - general implementation of hw-offload bridge (introduced in v6.40rc36);
*) dhcp-client - limit and enforce DHCP client "default-route-distance" minimal value to 1;
*) dhcpv4-server - strip trailing "\0" in "hostname" if present;
*) filesystem - implemented additional system integrity checks on reboots;
*) firewall - added "tls-host" firewall matcher (CLI only);
*) hotspot - fixed "dst-port" to require valid "protocol" in "walled-garden ip";
*) ike2 - fixed PH1 lifetime reset on boot;
*) lte - fixed authentication for non LTE modes;
*) tr069-client - fixed "/interface lte apn" configuration parameters;
*) userman - allow to generate more than 999 users;
*) wireless - added passive scan option for wireless scan mode;

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after crash.
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8310
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 24, 2017 3:14 pm

*) firewall - added "tls-host" firewall matcher (CLI only);
Sweet. No more Layer 7 for HTTPS blocking :)
How it works? Which packet matches? Does it support wildcards?
Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

For every complex problem, there is a solution that is simple, neat, and wrong.

MikroTik. Your life. Your routing.
 
User avatar
pietroscherer
Trainer
Trainer
Posts: 169
Joined: Thu Mar 05, 2015 3:05 pm
Location: RS, Brazil
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 24, 2017 3:24 pm

*) firewall - added "tls-host" firewall matcher (CLI only);
Sweet. No more Layer 7 for HTTPS blocking :)
How it works? Which packet matches? Does it support wildcards?
+1 :D
Pietro Scherer
http://www.tchesolutions.com.br [ISPs Consulting and Training]
http://www.routermage.com [Backup and Automation System]
:D
 
pe1chl
Forum Guru
Forum Guru
Posts: 5834
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 24, 2017 4:23 pm

*) firewall - added "tls-host" firewall matcher (CLI only);
Sweet. No more Layer 7 for HTTPS blocking :)
How it works? Which packet matches? Does it support wildcards?
I presume this is just a special case of a Layer 7 with some pre-defined pattern, and only works when SNI is used.
 
User avatar
Cha0s
Forum Veteran
Forum Veteran
Posts: 903
Joined: Tue Oct 11, 2005 4:53 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 24, 2017 4:27 pm

*) firewall - added "tls-host" firewall matcher (CLI only);
Sweet. No more Layer 7 for HTTPS blocking :)
How it works? Which packet matches? Does it support wildcards?
I presume this is just a special case of a Layer 7 with some pre-defined pattern, and only works when SNI is used.
It could be an iptables module specific to that function instead of abstracting a L7 filter. Like this https://github.com/Lochnair/xt_tls
 
User avatar
honzam
Forum Guru
Forum Guru
Posts: 2288
Joined: Wed Feb 27, 2008 10:27 pm
Location: Czech Republic

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Nov 24, 2017 4:46 pm

*) wireless - added passive scan option for wireless scan mode;
Any info about this? passive scan has been implemented for a long time
LAN, FTTx, Wireless. ISP operator
 
troffasky
Member
Member
Posts: 395
Joined: Wed Mar 26, 2014 4:37 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Nov 25, 2017 12:53 am

*) firewall - added "tls-host" firewall matcher (CLI only);
Sweet. No more Layer 7 for HTTPS blocking :)
How it works? Which packet matches? Does it support wildcards?
I presume this is just a special case of a Layer 7 with some pre-defined pattern, and only works when SNI is used.
No need for SNI, CN of certificate is in plaintext whether SNI is used or not.
 
bjornr
just joined
Posts: 23
Joined: Thu Apr 16, 2015 11:00 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Nov 25, 2017 12:59 am

Upgrading a CRS326-24G-2S+ to 6.41rc56 broke DHCP relaying through it, the requests are passed through but the responses (OFFERs) are never seen by the client. Reverting to rc52 fixed this issue.

Don't know exactly what caused this, but if it helps identifying the issue I'm employing VLANs, bonding interfaces, and DHCP relaying. Configs or supout can be available upon request.
 
Paternot
Long time Member
Long time Member
Posts: 607
Joined: Thu Jun 02, 2016 4:01 am
Location: Niterói / Brazil

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Nov 25, 2017 3:28 am

*) wireless - added passive scan option for wireless scan mode;
Any info about this? passive scan has been implemented for a long time
It's not clear, from the changelog, but: If I remember it right, Mikrotik didn't support passive scan with 802.11ac, only b, g, n. Maybe this is it, at long last. :D
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 1819
Joined: Mon Jan 14, 2008 1:53 pm
Location: Straya
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Nov 25, 2017 11:47 am

*) firewall - added "tls-host" firewall matcher (CLI only);
Sweet. No more Layer 7 for HTTPS blocking :)
How it works? Which packet matches? Does it support wildcards?
At a guess, its based on xt_tls which can support wildcards, see https://github.com/Lochnair/xt_tls
http://thebrotherswisp.com/ | Mikrotik MTCNA, MTCRE, MTCINE | Fortinet FTCNA, FCNSP, FCT | Extreme Networks ENA
 
nkourtzis
Member Candidate
Member Candidate
Posts: 204
Joined: Tue Dec 11, 2012 12:56 am
Location: Greece

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Nov 27, 2017 12:24 pm

*) wireless - added passive scan option for wireless scan mode;
Any info about this? passive scan has been implemented for a long time
It's not clear, from the changelog, but: If I remember it right, Mikrotik didn't support passive scan with 802.11ac, only b, g, n. Maybe this is it, at long last. :D
If this is it, then we only now have to wait for spectral scan and power adjustment in 802.11ac and we will be seeing sweet dreams.
Passionate about networks
Enthusiastic about Mikrotik
MTCNA | MTCRE | MTCINE

No trees were killed to send this message,
but a large number of electrons were terribly inconvenienced.
 
nkourtzis
Member Candidate
Member Candidate
Posts: 204
Joined: Tue Dec 11, 2012 12:56 am
Location: Greece

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Nov 28, 2017 3:07 pm

Dear all, has the development of ROS slowed down or is it my wrong impresion? One RC sub-version every one to two weeks where it used to be every two to three days and even then, very sparse changelog. Even this thread has become relatively quiet.

Can it possibly be that we approaching the end of v6 development? Just wondering...
Passionate about networks
Enthusiastic about Mikrotik
MTCNA | MTCRE | MTCINE

No trees were killed to send this message,
but a large number of electrons were terribly inconvenienced.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5834
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Nov 28, 2017 3:28 pm

nkourtzis wrote:
Can it possibly be that we approaching the end of v6 development? Just wondering...

I am wondering when they dare to release 6.41 as a "current" version with this risky "New bridge implementation" that will likely cause problems once it is widely deployed into many different field configurations (that combine VLAN tagging on switch and bridge now).
You may be right in that this could actually be released as part of "v7" so people are aware there are many changes and testing (rather than routine updating) is required.
 
biatche
Member Candidate
Member Candidate
Posts: 128
Joined: Tue Oct 13, 2015 6:50 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Nov 28, 2017 8:12 pm

Dear all, has the development of ROS slowed down or is it my wrong impresion? One RC sub-version every one to two weeks where it used to be every two to three days and even then, very sparse changelog. Even this thread has become relatively quiet.

Can it possibly be that we approaching the end of v6 development? Just wondering...
Was wondering just the same.. yet ROS still lacks many basic features..
 
JimmyNyholm
Member Candidate
Member Candidate
Posts: 249
Joined: Mon Apr 25, 2016 2:16 am
Location: Sweden

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Nov 29, 2017 11:04 pm

New bridge implementation need:

Hardware LACP bonding.
Hardware setting per port of learning mode for mac-adresses max number and what to do when max is reached and or port/device restarted.
per port ingress and egress hardware rate limiting.
dhcp snooping with guard
arp snooping with guard
Option to hardware block malicious traffic in the above dhcp and arp concept.

In all essence be a real provider switch compairable to other switch vendors.

Other stuff is needed as well but that is for another day and discussion. This is what I think is needed before this new implementation is ready to hit the streets.
 
biatche
Member Candidate
Member Candidate
Posts: 128
Joined: Tue Oct 13, 2015 6:50 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Nov 30, 2017 12:51 am

New bridge implementation need:

Hardware LACP bonding.
Hardware setting per port of learning mode for mac-adresses max number and what to do when max is reached and or port/device restarted.
per port ingress and egress hardware rate limiting.
dhcp snooping with guard
arp snooping with guard
Option to hardware block malicious traffic in the above dhcp and arp concept.

In all essence be a real provider switch compairable to other switch vendors.

Other stuff is needed as well but that is for another day and discussion. This is what I think is needed before this new implementation is ready to hit the streets.
Agreed, these are some of the basic features i was talking about.
 
nkourtzis
Member Candidate
Member Candidate
Posts: 204
Joined: Tue Dec 11, 2012 12:56 am
Location: Greece

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Nov 30, 2017 11:35 am

New bridge implementation need:

Hardware LACP bonding.
Hardware setting per port of learning mode for mac-adresses max number and what to do when max is reached and or port/device restarted.
per port ingress and egress hardware rate limiting.
dhcp snooping with guard
arp snooping with guard
Option to hardware block malicious traffic in the above dhcp and arp concept.

In all essence be a real provider switch compairable to other switch vendors.

Other stuff is needed as well but that is for another day and discussion. This is what I think is needed before this new implementation is ready to hit the streets.

Also add Q-in-Q support.
Passionate about networks
Enthusiastic about Mikrotik
MTCNA | MTCRE | MTCINE

No trees were killed to send this message,
but a large number of electrons were terribly inconvenienced.
 
upower3
Member
Member
Posts: 384
Joined: Thu May 07, 2015 11:46 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Nov 30, 2017 11:56 am

I am wondering when they dare to release 6.41 as a "current" version with this risky "New bridge implementation" that will likely cause problems once it is widely deployed into many different field configurations (that combine VLAN tagging on switch and bridge now).
You may be right in that this could actually be released as part of "v7" so people are aware there are many changes and testing (rather than routine updating) is required.
True, now wise to roll up this "breaking" changes in "ordinary" release. Many people used to apply updates without reading out readme-s, or without huge testing, and this will break many setups around the world.

Being said, there are many h/w features that should be implemented as well, and upcoming situation (6.41 with its breakthrough features) won't be nice news for enterprise and ISP networks. Many company will find their network fail to work as before, and it'll be blamed on MT (well, this will be true), which will impact MT sales.

I just wonder if the new bridge implementation is something that can not wait for 7.x branch to be introduced? Something very urge to roll out?

This change (take for granted it'll break some setups around the world) will impact MT's reputation while won't give any benefits to customers. Many people won't give a damn if they have master/slave or bridge to employ h/w packet processing, but they surely be quite unhappy (and will spread the word) when their setup be break out of sudden.
 
User avatar
bajodel
Long time Member
Long time Member
Posts: 545
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Dec 01, 2017 10:58 am

In their shoes I would concurrently release a new 6.40.x in bugfix and stable, forcing all system to switch to bugfix channel as update default (6.40.x should then live in bugfix for long time).
For admins ready to 6.41 it would be simple enough as manually switch to current again; in this way all systems upgraded in a automatic/silent mode would be quite safe.
 
skuykend
Member Candidate
Member Candidate
Posts: 270
Joined: Tue Oct 06, 2015 7:28 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Dec 01, 2017 11:11 am

In their shoes I would concurrently release a new 6.40.x in bugfix and stable, forcing all system to switch to bugfix channel as update default (6.40.x should then live in bugfix for long time).
For admins ready to 6.41 it would be simple enough as manually switch to current again; in this way all systems upgraded in a automatic/silent mode would be quite safe.
+1
That seems quite clever. May bug a few, but would allow MikroTik to continue going forward much less risky.
 
upower3
Member
Member
Posts: 384
Joined: Thu May 07, 2015 11:46 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Dec 01, 2017 11:37 am

For admins ready to 6.41 it would be simple enough as manually switch.
It would be quite useful to create another forum topic to let users report their setups that failed to convert from master-slave to new bridge implementation. At least, this may be good to add these situation into config converter.
 
eriitguy
Member Candidate
Member Candidate
Posts: 197
Joined: Thu Jan 26, 2017 1:16 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Dec 01, 2017 4:48 pm

Hello!

Maybe a force backup creation before update with notification about such behavior in changelog?


Thank you!
 
anuser
Member
Member
Posts: 397
Joined: Sat Nov 29, 2014 7:27 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Dec 04, 2017 12:14 pm

I had problems with several Samsung Galaxy S7 Edge running Android 7 with wAP AC and central CAPSMAN controller running 6.40.5. The smartphones connected, but they had no internet. I updated the wAP AC from 6.40.5 to 6.41rc56. The CAPSMAN controller is still runing at 6.40.5
Now the smartphones can connect and have internet access. With version 6.40.5 again, they had problems again.
 
biatche
Member Candidate
Member Candidate
Posts: 128
Joined: Tue Oct 13, 2015 6:50 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Dec 04, 2017 2:27 pm

Dear mikrotik, why has development slowed down? In the past we used to see a new rc every 3-5 days.
 
Paternot
Long time Member
Long time Member
Posts: 607
Joined: Thu Jun 02, 2016 4:01 am
Location: Niterói / Brazil

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Dec 04, 2017 2:44 pm

Dear mikrotik, why has development slowed down? In the past we used to see a new rc every 3-5 days.
I noticed that too. But 6.41 is a big step, with bridge hardware offloading and whatnot. I believe they are testing the (numerous) bugs already found, and preparing for another RC - or the gold one.
 
raffav
Member Candidate
Member Candidate
Posts: 288
Joined: Wed Oct 24, 2012 4:40 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Dec 04, 2017 2:54 pm

What was the highest rc version ?
I also think they are fixing bugs, tweaking some functionality
Or maybe they are focus working on version 7

Enviado de meu XT1580 usando Tapatalk

 
User avatar
juliokato
Member Candidate
Member Candidate
Posts: 229
Joined: Mon Oct 26, 2015 4:27 pm
Location: Brazil

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Dec 04, 2017 4:33 pm

What was the highest rc version ?
I also think they are fixing bugs, tweaking some functionality
Or maybe they are focus working on version 7 Image

Enviado de meu XT1580 usando Tapatalk
Maybe renaming the V6.41RC to V7, since they introduced many new features. 8)
I apologize my grammatical errors, my english not so good, I am not a native speaker.
Wiki is maintained in English. I use Google translator. 8)
 
jarda
Forum Guru
Forum Guru
Posts: 7603
Joined: Mon Oct 22, 2012 4:46 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Dec 04, 2017 4:56 pm

V7 should have new kernel and totally new implementation of some functionalities. Do not skip so far...
 
pe1chl
Forum Guru
Forum Guru
Posts: 5834
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Dec 04, 2017 5:55 pm

V7 should have new kernel and totally new implementation of some functionalities. Do not skip so far...
That is never going to work! They need to separate some of the changes into subreleases and packages, including RC versions, or this version is never going to materialize.
I vote for releasing a V7 based on 6.41RC with a new kernel (first as an RC), then make that a "current" version and await the reports of all the new minor problems, then (or partly in parallel) release all the "totally new implementations of some functionalities" as optional packages like it was done before with wireless and routing.
So the people interested in new functionality and prepared to be confronted with some bugs can test in parallel with the baseline users.
 
biatche
Member Candidate
Member Candidate
Posts: 128
Joined: Tue Oct 13, 2015 6:50 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Dec 04, 2017 6:00 pm

V7 should have new kernel and totally new implementation of some functionalities. Do not skip so far...
That is never going to work! They need to separate some of the changes into subreleases and packages, including RC versions, or this version is never going to materialize.
I vote for releasing a V7 based on 6.41RC with a new kernel (first as an RC), then make that a "current" version and await the reports of all the new minor problems, then (or partly in parallel) release all the "totally new implementations of some functionalities" as optional packages like it was done before with wireless and routing.
So the people interested in new functionality and prepared to be confronted with some bugs can test in parallel with the baseline users.
What's actually the issue having 6.41 with the new bridge implementation? If it works it works...
 
WojtusW5
Frequent Visitor
Frequent Visitor
Posts: 64
Joined: Mon Oct 02, 2017 1:25 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Dec 04, 2017 6:32 pm

Hi, small off-top when 6.41 will be as current version ?
Is there an initial deadline ?
I invite you to visit my blog
https://mikrotikon.pl/
 
pe1chl
Forum Guru
Forum Guru
Posts: 5834
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Dec 04, 2017 7:16 pm

What's actually the issue having 6.41 with the new bridge implementation? If it works it works...
Yes, if it works... but yesterday I spent quite some time trying to migrate an existing complex configuration consisting of
multiple bridges for different VLANs to the new 6.41RC and I have so far been unable to do so.
Ok, to be honest it still worked after merely upgrading it, but with the existing split bridges with VLAN subinterfaces as ports.
I tried to migrate to a single bridge with VLANs inside and several tagged and untagged member ports, and it simply did not work.
So a blind upgrade to 6.41 would probably survive, merely losing the switching (master-port) hardware assistance.
However there is still work to do (maybe on the software, maybe on my configuration skills) before several similar routers can run 6.41.
 
biatche
Member Candidate
Member Candidate
Posts: 128
Joined: Tue Oct 13, 2015 6:50 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Dec 04, 2017 7:26 pm

What's actually the issue having 6.41 with the new bridge implementation? If it works it works...
Yes, if it works... but yesterday I spent quite some time trying to migrate an existing complex configuration consisting of
multiple bridges for different VLANs to the new 6.41RC and I have so far been unable to do so.
Ok, to be honest it still worked after merely upgrading it, but with the existing split bridges with VLAN subinterfaces as ports.
I tried to migrate to a single bridge with VLANs inside and several tagged and untagged member ports, and it simply did not work.
So a blind upgrade to 6.41 would probably survive, merely losing the switching (master-port) hardware assistance.
However there is still work to do (maybe on the software, maybe on my configuration skills) before several similar routers can run 6.41.
Why not show the configuration in case theres a "bug" and "use-case" that they aren't aware of that isnt working?

In any case... seeing the slow progress as of late is worry-some.. a feeling says that maybe they've hid a roadblock in the development... maybe just a false feeling, but in any case its really unusual.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5834
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Mon Dec 04, 2017 8:35 pm

Why not show the configuration in case theres a "bug" and "use-case" that they aren't aware of that isnt working?
Well I first want to investigate a bit more in both 6.40 and 6.41 what can be done to first make this config more optimal and then migrate it.
Doing so I found problems with 6.40 as well and it may be that the problem I found in 6.40 is also affecting 6.41
In general the situations is: I have 4 different bridges each with a different local network in it, and they each have a virtual WiFi interface in
them, one or more untagged ethernet ports, and two ports where there is a VLAN subinterface for each of the networks, the VLAN interfaces are in the bridges (trunk to external switches).
This I am trying to migrate to a new 6.41 config where there is one bridge with 3 VLANs in it (one of the networks is the "untagged" VLAN) and the ports
are either untagged members of the VLANs (or the bridge itself) or tagged members. On the bridge itself there are 3 VLAN subinterfaces for the router access
to the bridge. And then there are 3 ethernet ports that are outside all the bridges.
It works for 2 of the VLANs but not the third. There is something weird going on.
When trying on 6.40 to do some things in the switch that are now done in the bridge (hoping it would auto-migrate easier), I found that while on my RB2011 everthing works just fine on switch1, the same setup on switch2 (several VLANs on the switch, untagged ports, one port outside the switch) would not work. It appears the switch2 will not do "always strip" with a default VLAN tag...
 
abis
Frequent Visitor
Frequent Visitor
Posts: 51
Joined: Fri Apr 11, 2014 9:32 pm
Location: Romania

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Dec 06, 2017 10:07 am

Dear mikrotik, why has development slowed down? In the past we used to see a new rc every 3-5 days.
Good point :?
Image Image
 
jondavy
Member Candidate
Member Candidate
Posts: 127
Joined: Tue May 12, 2009 11:14 pm
Location: Brasil

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Dec 06, 2017 2:57 pm

mikrotik team, no matter how long it takes, ios, junos does not have a weekly update, more are stable, the important thing is that the software stays stable,
so keep it up 8)
 
upower3
Member
Member
Posts: 384
Joined: Thu May 07, 2015 11:46 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Dec 06, 2017 3:07 pm

mikrotik team, no matter how long it takes, ios, junos does not have a weekly update, more are stable, the important thing is that the software stays stable,
so keep it up 8)
Given that routine current update about to introduce new bridge implementation that potentially break router config (and even downgrade won't help since the config will be already broken by autoconvert process), I won't call it "stable" or vote for keeping it up, actually.

What I'd vote for it to have one notable release (maybe even 7.00?) with only and just this bridge implementation and other ongoing releases (6.41, 642 etc) with other changes and fixes. Just to be on the safe side.

May I also add up, remember how MT once broken their dyndns server for the whole newyear's holidays until someone came to Riga's office and turn it on? I can imagine pre-new-year release with this bridge implementation that will break you devices so you'll have warm and nice new year eve visiting each of your remote device personally :)
 
User avatar
BartoszP
Forum Guru
Forum Guru
Posts: 1715
Joined: Mon Jun 16, 2014 1:13 pm
Location: Poland

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Dec 06, 2017 3:10 pm

+1 for upower3's idea of ROS 7.00.
Real admins use real keyboards.
 
User avatar
juliokato
Member Candidate
Member Candidate
Posts: 229
Joined: Mon Oct 26, 2015 4:27 pm
Location: Brazil

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Dec 06, 2017 3:19 pm

Dear mikrotik, why has development slowed down? In the past we used to see a new rc every 3-5 days.
Good point :?
Maybe freezing due to the holidays at the end of the year?
Many companies do this.
I apologize my grammatical errors, my english not so good, I am not a native speaker.
Wiki is maintained in English. I use Google translator. 8)
 
upower3
Member
Member
Posts: 384
Joined: Thu May 07, 2015 11:46 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Dec 06, 2017 3:28 pm

Dear mikrotik, why has development slowed down? In the past we used to see a new rc every 3-5 days.
Good point :?
Maybe freezing due to the holidays at the end of the year?
Many companies do this.
Posting some roadmap for hardware development and also for ROS development would be nice replacement for new ROS release.

I'd like to know where MT will go next year or two, should we expect it on enterprise market (yes, with enterprise-class equipment), or it'll target on SOHO, low-cost ISP's and home markets? Which models can we rely on, which ROS features planned to be be further developed? MT used to introduce nice devices, but they looks merely like proof of concept sometimes. Say, no enterprise will even get many switches unless they'll be promised these devices won't be abandoned for years.

Personally, I'd like to see stacking for switches. I'd also would like to see Metarouter back, maybe even for routers with x86/x64 architecture (two PSU, fanless and quiet) so I can put it in the remote office and run some Asterisk on it - nice idea, isn't it?

But looks like eveyone at MT is at conferences now, or maybe went to Bali to have some rest. Strange, this time of the year is hot for sales and for marketing, isn't it?
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1407
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Dec 06, 2017 3:32 pm

What's new in 6.41rc61 (2017-Dec-06 08:15):

Important note!!! Backup before upgrade!
RouterOS (v6.40rc36-rc40 and) v6.41rc1+ contains new bridge implementation that supports hardware offloading (hw-offload).
This update will convert all interface "master-port" configuration into new bridge configuration, and eliminate "master-port" option as such.
Bridge will handle all Layer2 forwarding and the use of switch-chip (hw-offload) will be automatically turned on based on appropriate conditions.
The rest of RouterOS Switch specific configuration remains untouched in usual menus for now.
Please, note that downgrading to previous RouterOS versions will not restore "master-port" configuration, so use backups to restore configuration on downgrade.


Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;
2) Make sure the device will not lose power during upgrade process;
3) Device has enough free storage space for all RouterOS packages to be downloaded.

Changes since previous 6.41rc release:

!) bridge - general implementation of hw-offload bridge (introduced in v6.40rc36);
*) bridge - disable "hw-offload" when "horizon" or "external-fdb" is set;
*) bridge - fixed hw-offloaded IGMP Snooping service getting stopped;
*) capsman - use "adaptive-noise-immunity" value from CAP local configuration;
*) certificate - added option to store CRL in RAM (CLI only);
*) certificate - improved CRL update after system startup;
*) certificate - show invalid flag when local CRL file does not exist;
*) crs317 - fixed reliability on FAN controller;
*) dhcpv4-server - added "NETWORK_GATEWAY" option variable;
*) filesystem - implemented additional system integrity checks on reboots;
*) firewall - added "tls-host" firewall matcher;
*) lte - fixed Passthrough support;
*) lte - update info command with "location area code" (LAC);
*) lte - provide lte info "physical cell id" values (R11e-LTE only);
*) ppp - added initial support for PLE902;
*) sms - log decoded USSD responses;
*) snmp - fixed consecutive OID bulk get from the same table when non-repeaters are > 0;
*) system - show USB topology for the device info;
*) webfig - fixed router getting reset to default configuration;
*) winbox - added switch menu on RB1100AHx4;
*) winbox - do not show MetaROUTER stuff on RB1100AHx4;
*) wireless - check APs against connect-list rules starting with strongest signal;
*) wireless - do not show background scan frequencies in the monitor command channel field;
*) wireless - fixed channel selection when special channels used (introduced in v6.41rc);
*) wireless - increased the EAP message retransmit count;

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after crash.
 
User avatar
Cha0s
Forum Veteran
Forum Veteran
Posts: 903
Joined: Tue Oct 11, 2005 4:53 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Dec 06, 2017 3:44 pm

I agree with upower3. A roadmap for software and hardware development would be most welcome.

Knowing where MikroTik is heading is essential when investing in their hardware (and subsequently in their software).
 
User avatar
BartoszP
Forum Guru
Forum Guru
Posts: 1715
Joined: Mon Jun 16, 2014 1:13 pm
Location: Poland

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Dec 06, 2017 4:04 pm

What's new in 6.41rc61 (2017-Dec-06 08:15): ..
In Poland we say: "Hit the table and the scissors will make a sound" :-)
Real admins use real keyboards.
 
upower3
Member
Member
Posts: 384
Joined: Thu May 07, 2015 11:46 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Dec 06, 2017 4:14 pm

What's new in 6.41rc61 (2017-Dec-06 08:15):
Please explain the process of transformation. Say if I have eth2 as Master-port, and eth3..eth5 as Slaves, and used eth2 in firewall rule, will this rule be changes to one that will use newly-created bridge? Will IP be reassigned from master port to bridge create from these master and its slave ports?

Important questions, when it comes to upgrade! Even if we go with manual changing (tuning) of existing configuration so we'll be sure we can go with upgrade to 6.41, I'd really love to know the auto-convert algorithm.
 
User avatar
ErfanDL
Member Candidate
Member Candidate
Posts: 276
Joined: Thu Sep 29, 2016 9:13 am
Location: IRAN
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Dec 06, 2017 4:17 pm

What are you doing MTK ?! release the stable version ! not spam version's
 
nkourtzis
Member Candidate
Member Candidate
Posts: 204
Joined: Tue Dec 11, 2012 12:56 am
Location: Greece

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Dec 06, 2017 4:19 pm

Dears at Mikrotik,

PLEASE PLEASE PLEASE revert the Routerboot numbering following the ROS version numbers, or at least make the ROS upgrade process to automatically upgrade Routerboot also. Performing two reboots per unit on each version upgrade in order to keep both up-to-date, without knowing whether there are any changes in the version or not, is not ideal.

I am sure many will second me on this point.
Passionate about networks
Enthusiastic about Mikrotik
MTCNA | MTCRE | MTCINE

No trees were killed to send this message,
but a large number of electrons were terribly inconvenienced.
 
User avatar
Cha0s
Forum Veteran
Forum Veteran
Posts: 903
Joined: Tue Oct 11, 2005 4:53 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Dec 06, 2017 4:21 pm

or at least make the ROS upgrade process to automatically upgrade Routerboot also.
+1
 
upower3
Member
Member
Posts: 384
Joined: Thu May 07, 2015 11:46 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Dec 06, 2017 4:22 pm

without knowing whether there are any changes in the version or not, is not ideal.
Mostly there are no changes for all but really new devices or hardware. The only thing you might need this upgrade is when you add new hardware (like SFP module) or you can see you MT works unusually bad.

So to say, f/w upgrade is very rare thing so numbering after ROS releases is something... Strange, really!

Vote for revert to old f/w version numbering. Please!

You can also do really good thing by simple posting Changelogs for f/w with explanation who should care for (like "this f/w release used to support new 10G SFP module named ABC123, so don't care if you're not using it").
 
User avatar
kometchtech
Member Candidate
Member Candidate
Posts: 194
Joined: Sat Jun 15, 2013 4:25 am
Location: Japan
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Dec 06, 2017 4:25 pm

*) capsman - use "adaptive-noise-immunity" value from CAP local configuration;
I'd like to know a bit more about this change.
Although "adaptive-noise-immunity" is read from CAP, it is correct by recognizing that setting value at that time will be read by setting with CAP Wireless beforehand and then activating Manager Is it?
--
Routerboard Users Group JP
http://www.rb-ug.jp/
CCR1009-8G-1S-1S+, RB750Gr3, CRS226-24G-2S+, RB850Gx2, RB960PGS, CRS317-1G-16S+,
RB2011UAS, CRS125-24G-1S, RB962UiGS-5HacT2HnT, CRS212-1G-10S-1S+, RB3011UiAS
 
User avatar
juliokato
Member Candidate
Member Candidate
Posts: 229
Joined: Mon Oct 26, 2015 4:27 pm
Location: Brazil

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Dec 06, 2017 4:54 pm

or at least make the ROS upgrade process to automatically upgrade Routerboot also.
+1
ok, but how is the process downgrade?
I apologize my grammatical errors, my english not so good, I am not a native speaker.
Wiki is maintained in English. I use Google translator. 8)
 
andriys
Forum Guru
Forum Guru
Posts: 1180
Joined: Thu Nov 24, 2011 1:59 pm
Location: Kharkiv, Ukraine

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Dec 06, 2017 5:23 pm

*) capsman - use "adaptive-noise-immunity" value from CAP local configuration;
I'd like to know a bit more about this change.
I believe this is similar to how antenna gain setting is being handled. Simply set the desired value of the adaptive-noise-immunity option in your radio interface configuration before turning CAP mode on, and that value will be used for this particular radio when you join it to your CAPs manager.
 
raffav
Member Candidate
Member Candidate
Posts: 288
Joined: Wed Oct 24, 2012 4:40 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Dec 06, 2017 5:29 pm

any one figure out how to set up this:
"firewall - added "tls-host" firewall matcher "
 
kmok1
newbie
Posts: 43
Joined: Wed Nov 28, 2012 6:49 pm
Location: Windsor ON Canada
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Wed Dec 06, 2017 5:50 pm

I have been testing the RC version on an RB750. If I goto / system routerboard, upgrade-firmware has been blank in the past several RC releases. Is this the new norm?
 
User avatar
kometchtech
Member Candidate
Member Candidate
Posts: 194
Joined: Sat Jun 15, 2013 4:25 am
Location: Japan
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Dec 07, 2017 2:28 am

*) capsman - use "adaptive-noise-immunity" value from CAP local configuration;
I'd like to know a bit more about this change.
I believe this is similar to how antenna gain setting is being handled. Simply set the desired value of the adaptive-noise-immunity option in your radio interface configuration before turning CAP mode on, and that value will be used for this particular radio when you join it to your CAPs manager.

Thank you for the information.

Do you know what kind of method to confirm that this setting is valid?
If you are okay, can you tell me about the way?
--
Routerboard Users Group JP
http://www.rb-ug.jp/
CCR1009-8G-1S-1S+, RB750Gr3, CRS226-24G-2S+, RB850Gx2, RB960PGS, CRS317-1G-16S+,
RB2011UAS, CRS125-24G-1S, RB962UiGS-5HacT2HnT, CRS212-1G-10S-1S+, RB3011UiAS
 
Grickos
newbie
Posts: 32
Joined: Thu Aug 06, 2015 2:57 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Dec 07, 2017 6:42 pm

The DHCP server does not work properly.
DNS was set up
/ ip dhcp-server network
add address = 192.168.0.0 / 24 dns-server = 192.168.0.1 gateway = 192.168.0.1.
It behaves as if it was not assigned a DNS server. Assigns addresses that are entered in / ip dns.
 
freemannnn
Long time Member
Long time Member
Posts: 669
Joined: Sun Oct 13, 2013 7:29 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Dec 07, 2017 6:49 pm

my dns server (ip-dns) where lost after upgrade to rc61
 
RafGan
newbie
Posts: 29
Joined: Mon Jun 06, 2011 6:17 pm
Location: Poland / Silesia

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Dec 07, 2017 7:31 pm

My static ports in all bridges just disappear after reboot on CAPsMAN controller router.
RB2011UAS-2HnD ROS 6.41rc61.

Also on SXT ac, clients are diconnected from time to time (every few minutes). In rc56 was perfect.

New bugs?
Best Regards,
Raf G
 
fanMikroTik
just joined
Posts: 7
Joined: Fri Sep 08, 2017 8:32 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Dec 08, 2017 11:37 am

MK,

please can You think about it just a few minutes? 6.41rc61 still the same...!

2 years old bug with TX Rate on all smartphones with android. TX Rate is always only 54Mbps but RX Rate is 72.2Mbps-20MHz/1S/SGI.

viewtopic.php?t=102908
Last edited by fanMikroTik on Sat Dec 09, 2017 8:49 pm, edited 1 time in total.
 
Son1c
just joined
Posts: 9
Joined: Fri Mar 24, 2017 6:29 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Dec 08, 2017 12:00 pm

MK,

please do You think about it just a few minutes? 6.41rc61 still the same...!

2 years old bug with TX Rate on all smartphones with android. TX Rate is always only 54Mbps but RX Rate is 72.2Mbps-20MHz/1S/SGI.

viewtopic.php?t=102908
+1
 
linek1980
newbie
Posts: 34
Joined: Thu Feb 03, 2011 1:39 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Dec 09, 2017 3:56 pm

MK,

please do You think about it just a few minutes? 6.41rc61 still the same...!

2 years old bug with TX Rate on all smartphones with android. TX Rate is always only 54Mbps but RX Rate is 72.2Mbps-20MHz/1S/SGI.

viewtopic.php?t=102908
+1 it must be repaired
 
User avatar
noyo
Member Candidate
Member Candidate
Posts: 114
Joined: Sat Jan 28, 2012 12:25 am
Location: Mazury - Poland
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Dec 09, 2017 4:03 pm

MK,

please do You think about it just a few minutes? 6.41rc61 still the same...!

2 years old bug with TX Rate on all smartphones with android. TX Rate is always only 54Mbps but RX Rate is 72.2Mbps-20MHz/1S/SGI.

viewtopic.php?t=102908
+1
 
zajadacz
just joined
Posts: 18
Joined: Fri Jul 29, 2016 12:30 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sat Dec 09, 2017 11:46 pm

MK,

please can You think about it just a few minutes? 6.41rc61 still the same...!

2 years old bug with TX Rate on all smartphones with android. TX Rate is always only 54Mbps but RX Rate is 72.2Mbps-20MHz/1S/SGI.

viewtopic.php?t=102908
+1
 
Ryan207
just joined
Posts: 2
Joined: Sun Dec 10, 2017 10:45 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Sun Dec 10, 2017 11:10 am

As RafGan mentioned...the bridge ports disappear.

Upgraded to rc61 on my RB3011 and lost all local access, logged in remotely and saw all bridge ports were gone except for one undefined for ether3...which I deleted, readded all of them and works I think now but I noticed none of my connection marking is working anymore, I've yet to figure that part out.

I use connection marking then packet marking for my QoS setup, what changed in rc61 to break this or require a new config? Worked fine in rc56.

Who is online

Users browsing this forum: Google [Bot] and 16 guests