Community discussions

MikroTik App
 
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: 248
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: 218
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.
 
upower3
Member
Member
Posts: 425
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: 551
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: 274
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: 425
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
Long time Member
Long time Member
Posts: 601
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.
 
User avatar
Paternot
Forum Veteran
Forum Veteran
Posts: 953
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
Member
Posts: 345
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 [emoji16]

Enviado de meu XT1580 usando Tapatalk

 
User avatar
juliokato
Member Candidate
Member Candidate
Posts: 228
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 [emoji16]

Enviado de meu XT1580 usando Tapatalk
Maybe renaming the V6.41RC to V7, since they introduced many new features. 8)
 
jarda
Forum Guru
Forum Guru
Posts: 7756
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: 10196
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: 94
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 ?
 
pe1chl
Forum Guru
Forum Guru
Posts: 10196
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: 10196
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: 55
Joined: Fri Apr 11, 2014 9:32 pm

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 :?
 
jondavy
Member Candidate
Member Candidate
Posts: 143
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: 425
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: 2865
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.
 
User avatar
juliokato
Member Candidate
Member Candidate
Posts: 228
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.
 
upower3
Member
Member
Posts: 425
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: 1623
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 Guru
Forum Guru
Posts: 1140
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: 2865
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" :-)
 
upower3
Member
Member
Posts: 425
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
Member
Posts: 366
Joined: Thu Sep 29, 2016 9:13 am

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: 218
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.
 
User avatar
Cha0s
Forum Guru
Forum Guru
Posts: 1140
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: 425
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?
 
User avatar
juliokato
Member Candidate
Member Candidate
Posts: 228
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?
 
andriys
Forum Guru
Forum Guru
Posts: 1526
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
Member
Posts: 345
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?
 
Grickos
newbie
Posts: 35
Joined: Thu Aug 06, 2015 2:57 am
Location: Croatia

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
Forum Veteran
Forum Veteran
Posts: 700
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?
 
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: 116
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
 
User avatar
zajadacz
just joined
Posts: 20
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.
 
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 3:51 pm

Looking at the connection marking this morning --- if I delete the connection from tracking, it will get tracked and marked properly. It seems with rc61 it allows the connections to start being tracked before it checks for marking after reboot. I should be able to temporarily fix this with a script but curious if this is a bug in rc61 or there is another way to implement marking now?
 
uldis
MikroTik Support
MikroTik Support
Posts: 3446
Joined: Mon May 31, 2004 2:55 pm

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

Mon Dec 11, 2017 9:00 am

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?
Do you have support output files from older RC where the static bridge ports were working ok? Did you make a new support output file after the upgrade where the bridge ports disappeared?

About wireless disconnection Only the AP was upgraded the to the newest RC version or also the Clients as well? What are the disconnect messages? Do you have a support output files?

Send all that info to support@mikrotik.com
 
User avatar
alexvdbaan
Trainer
Trainer
Posts: 40
Joined: Sun Feb 22, 2015 12:12 pm
Location: Amsterdam, Netherlands
Contact:

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

Mon Dec 11, 2017 1:29 pm

Hi Guys,

I have been playing around with the CRS326 and the new bridge implementation. I am quite happy with the direction of the new bridge, everything should become a lot easier. However as a few people before me have posted, getting it all to work with the current info on the wiki is challenging.

My network
Image

The trunking from the CCR1009 comes in nicely at the 3 CRS326 switches. All my vlans turn nicely into access ports. My management vlan (666) is getting an IP address through DHCP. When connecting from the CCR1009, I can manage my switches through that IP. However when trying to mac winbox or ip winbox to my swithes from devices behind accessport vlan 666 this doesnt work. I have tried many different options. I was wondering is someone would be able to look at my config and suggest a possible solution. I can manage all my other devices behind the switches (caps/routers/etc)

Config CRS326
/interface bridge
add admin-mac=64:D1:54:DA:33:50 auto-mac=no name=#master protocol-mode=none \
    pvid=666 vlan-filtering=yes
/interface ethernet
set [ find default-name=ether2 ] comment="1-10 Cust1 7/8/9/10"
set [ find default-name=ether3 ] comment="1-09 untagged 250 voice proper"
set [ find default-name=ether4 ] comment="reserved Cust1"
set [ find default-name=ether5 ] comment="1-05 Cust2"
set [ find default-name=ether6 ] comment="Reserved Cust2"
set [ find default-name=ether7 ] comment="1-11 Cust3"
set [ find default-name=ether8 ] comment="1-12 Cust3"
set [ find default-name=ether9 ] comment="1-13 Cust3"
set [ find default-name=ether10 ] comment="1-14 Cust3"
set [ find default-name=ether11 ] comment="1-17 Cust3"
set [ find default-name=ether12 ] comment="1-18 Cust3"
set [ find default-name=ether13 ] comment="2-1 Cust4"
set [ find default-name=ether14 ] comment="2-3 Cust4"
set [ find default-name=ether15 ] comment="2-7 Cust4"
set [ find default-name=ether16 ] comment="2-11 Cust4"
set [ find default-name=ether17 ] comment="2-13 Cust4"
set [ find default-name=sfp-sfpplus1 ] speed=1Gbps
/interface vlan
add interface=sfp-sfpplus1 name=s1.250 vlan-id=250
add interface=sfp-sfpplus1 name=s1.550 vlan-id=550
add interface=sfp-sfpplus1 name=s1.552 vlan-id=552
add interface=sfp-sfpplus1 name=s1.553 vlan-id=553
add interface=sfp-sfpplus1 name=s1.554 vlan-id=554
add interface=sfp-sfpplus1 name=s1.666 vlan-id=666
/interface list
add name=MAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/interface bridge port
add bridge=#master interface=ether2 pvid=552
add bridge=#master interface=ether3 pvid=250
add bridge=#master interface=ether4 pvid=552
add bridge=#master interface=ether5 pvid=550
add bridge=#master interface=ether6 pvid=550
add bridge=#master interface=ether7 pvid=553
add bridge=#master interface=ether8 pvid=553
add bridge=#master interface=ether9 pvid=553
add bridge=#master interface=ether10 pvid=553
add bridge=#master interface=ether11 pvid=553
add bridge=#master interface=ether12 pvid=553
add bridge=#master interface=ether13 pvid=554
add bridge=#master interface=ether14 pvid=554
add bridge=#master interface=ether15 pvid=554
add bridge=#master interface=ether16 pvid=554
add bridge=#master interface=ether17 pvid=554
add bridge=#master interface=ether18
add bridge=#master interface=ether19
add bridge=#master interface=ether20 pvid=666
add bridge=#master interface=ether21 pvid=666
add bridge=#master interface=ether22 pvid=666
add bridge=#master interface=ether23 pvid=666
add bridge=#master interface=ether24 pvid=666
add bridge=#master interface=sfp-sfpplus2
add bridge=#master interface=ether1 pvid=552
add bridge=#master interface=sfp-sfpplus1
/interface bridge vlan
add bridge=#master tagged=sfp-sfpplus1,sfp-sfpplus2 untagged=ether2,ether4 \
    vlan-ids=552
add bridge=#master tagged=sfp-sfpplus1,sfp-sfpplus2 untagged=ether3 vlan-ids=\
    250
add bridge=#master tagged=sfp-sfpplus1,sfp-sfpplus2 untagged=ether5,ether6 \
    vlan-ids=550
add bridge=#master tagged=sfp-sfpplus1,sfp-sfpplus2 untagged=\
    ether7,ether8,ether9,ether10,ether11,ether12 vlan-ids=553
add bridge=#master tagged=sfp-sfpplus1,sfp-sfpplus2 untagged=\
    ether13,ether14,ether15,ether16,ether17 vlan-ids=554
add bridge=#master tagged=sfp-sfpplus1 untagged=\
    ether20,ether21,ether22,ether23,ether24 vlan-ids=666
/interface list member
add interface=s1.666 list=MAN
add interface=s1.552 list=MAN
Cheers, Alex
 
bjornr
just joined
Posts: 23
Joined: Thu Apr 16, 2015 11:00 am

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

Mon Dec 11, 2017 1:42 pm

I was under the impression that one of the benefits of the new setup is being able to apply VLANs to the bridge and not to a physical interface without loss of speed. For what it's worth, a config similar to viewtopic.php?t=125251#p616970 works quite OK in my lab network.
 
User avatar
alexvdbaan
Trainer
Trainer
Posts: 40
Joined: Sun Feb 22, 2015 12:12 pm
Location: Amsterdam, Netherlands
Contact:

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

Mon Dec 11, 2017 2:35 pm

Hi bjornr,

If I look at your setup it seems that the primary difference is that you also list your bridge as tagged in the vlan port settings. Could you share your bridge default vlan setting?

Mine is:
/interface bridge
add admin-mac=64:D1:54:DA:33:50 auto-mac=no name=#master protocol-mode=none pvid=666 vlan-filtering=yes
Thanks, Alex
 
bjornr
just joined
Posts: 23
Joined: Thu Apr 16, 2015 11:00 am

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

Mon Dec 11, 2017 2:52 pm

Sure thing!
/interface bridge
add fast-forward=no igmp-snooping=no name=bridge priority=0x1000 protocol-mode=none vlan-filtering=yes
The docs I referenced uses pvid=1 for the bridge and for holding the VLANs, so my bridge sets no pvid. Instead, I've assigned the IP directly to a VLAN:
/interface vlan
add interface=bridge name=vlan4 vlan-id=4
and
/ip address
add address=192.168.0.4/24 interface=vlan4 network=192.168.0.0
Also note that the docs I referenced sets pvid 1 untagged on all trunk interfaces.

(Edit: Fixed BBCode markup)
 
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!

Tue Dec 12, 2017 12:57 am

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?
Do you have support output files from older RC where the static bridge ports were working ok? Did you make a new support output file after the upgrade where the bridge ports disappeared?

About wireless disconnection Only the AP was upgraded the to the newest RC version or also the Clients as well? What are the disconnect messages? Do you have a support output files?

Send all that info to support@mikrotik.com

Uldis, sorry, I have not support files. Right now I'm trying do several reboot with disappeared ports after another upgrade to rc61, but ports still exists. I have made suppout files with working configurations on both versions. Maybe time of working is to short. Next reboot will be done tomorrow.

SXT ac have actual this same problem on rc56 - maybe channel overlapping with diffrent networks - I will give a feedback.
 
User avatar
alexvdbaan
Trainer
Trainer
Posts: 40
Joined: Sun Feb 22, 2015 12:12 pm
Location: Amsterdam, Netherlands
Contact:

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

Tue Dec 12, 2017 11:54 am

Sure thing!
/interface bridge
add fast-forward=no igmp-snooping=no name=bridge priority=0x1000 protocol-mode=none vlan-filtering=yes
The docs I referenced uses pvid=1 for the bridge and for holding the VLANs, so my bridge sets no pvid. Instead, I've assigned the IP directly to a VLAN
Thanks bjornr,

Yesterday I played around with your example, it looks like you have VLAN's originating in the ROS641.rc61 and pushing them forward. In my usecase I have the VLAN's originating in a previous hop. In the updated diagram below I have further clarified. I have tried to play with two scenarios's.

In scenario 1 I have added the interface vlans to the physical port that carries the VLAN's from the previous hop. In this configuration, devices in my management lan can see the gateway at CCR1009 and mac winbox and ip winbox. I can set a dhcpclient on the vlan interface 666 on crs326. From the management vlan I cannot see mac winbox, cannot access mac winbox or ip winbox the dhcp received IP. I can only manage through Romon to the CCR1009 and connect back to the CRS326

In scenario 2 I have added the vlans as you said, to the bridge and removed them from sfp1. In this scenario my management vlan hosts can access a fixed ip set on vlan 666 interface and mac winbox. The dhcp client does not work anymore, there is no communication with CCR1009. If I try to add vlan 666 to sfp1 I stil l cannot access CCR1009. However in IP neigbors I do see the CCR1009.

For now that leaves me with scenario 1 since that I a usable scanario with Romon. Am wondering is others also have experience here with this problem?
Here you can find my updated diagram: https://superyupkent.stackstorage.com/s/IA9etV8NMlY70Wy

Thanks Alex
 
bjornr
just joined
Posts: 23
Joined: Thu Apr 16, 2015 11:00 am

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

Tue Dec 12, 2017 12:00 pm

Sure thing!
/interface bridge
add fast-forward=no igmp-snooping=no name=bridge priority=0x1000 protocol-mode=none vlan-filtering=yes
The docs I referenced uses pvid=1 for the bridge and for holding the VLANs, so my bridge sets no pvid. Instead, I've assigned the IP directly to a VLAN
Thanks bjornr,

Yesterday I played around with your example, it looks like you have VLAN's originating in the ROS641.rc61 and pushing them forward.
No, my VLANs (and their IP addresses) are defined on an RB850G connected to the CRS326.
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Tue Dec 12, 2017 4:46 pm

Sure thing!
/interface bridge
add fast-forward=no igmp-snooping=no name=bridge priority=0x1000 protocol-mode=none vlan-filtering=yes
The docs I referenced uses pvid=1 for the bridge and for holding the VLANs, so my bridge sets no pvid. Instead, I've assigned the IP directly to a VLAN
Thanks bjornr,

Yesterday I played around with your example, it looks like you have VLAN's originating in the ROS641.rc61 and pushing them forward. In my usecase I have the VLAN's originating in a previous hop. In the updated diagram below I have further clarified. I have tried to play with two scenarios's.

In scenario 1 I have added the interface vlans to the physical port that carries the VLAN's from the previous hop. In this configuration, devices in my management lan can see the gateway at CCR1009 and mac winbox and ip winbox. I can set a dhcpclient on the vlan interface 666 on crs326. From the management vlan I cannot see mac winbox, cannot access mac winbox or ip winbox the dhcp received IP. I can only manage through Romon to the CCR1009 and connect back to the CRS326

In scenario 2 I have added the vlans as you said, to the bridge and removed them from sfp1. In this scenario my management vlan hosts can access a fixed ip set on vlan 666 interface and mac winbox. The dhcp client does not work anymore, there is no communication with CCR1009. If I try to add vlan 666 to sfp1 I stil l cannot access CCR1009. However in IP neigbors I do see the CCR1009.

For now that leaves me with scenario 1 since that I a usable scanario with Romon. Am wondering is others also have experience here with this problem?
Here you can find my updated diagram: https://superyupkent.stackstorage.com/s/IA9etV8NMlY70Wy

Thanks Alex
Your CCR1009 running 6.40 should be configured with either software based bridges for VLANs or the Ethernet switch per normal methods.

Your CRS326 should be configured with the new VLAN aware bridges. This means:
  • A single bridge
  • All VLAN interfaces created with interface equal to the bridge
By default spanning-tree operates over the native VLAN on a port. You'll want to ensure the CCR1009 is configured for STP on the ports connecting to the CRS326 switches. I prefer a priority of 4096 on my root bridge and higher on my non-root bridges but to each his own there. In either case you want the PVID to match across the board. In the CCR1009 you'll want VLAN1 as the untagged port for all 3 downstream ports with STP on. In the CRS326, set PVID to 1 on the bridge and add the bridge as untagged to /interface bridge vlan for VLAN 1. Ensure STP is also enabled with protocol-mode on the bridge.

Because I don't like the Ethernet switch interface, it was poo poo. I'll give you an example with software bridges on your CCR1009:
/interface bridge add name=br1 protocol-mode=stp priority=0x1000

/interface vlan add interface=br1 vlan-id=552 name=br1-vlan552
/interface vlan add interface=br1 vlan-id=666 name=br1-vlan666

/ip address interface=br1-vlan552 address=10.5.52.1/24
/ip address interface=br1-vlan666 address=172.25.20.1/24

/interface bridge port add bridge=br1 interface=eth-crs326-1
/interface bridge port add bridge=br1 interface=eth-crs326-2
/interface bridge port add bridge=br1 interface=eth-crs326-3
For the CRS side:
/interface bridge add name=br1 vlan-filtering=yes priority=0x3000 protocol-mode=stp pvid=1
/interface bridge vlan set [ find where vlan-ids=1 and bridge=br1 ] untagged=br1 tagged=""
/interface bridge vlan add bridge=br1 vlan-ids=552 tagged=br1,sfp1 untagged=""
/interface bridge vlan add bridge=br1 vlan-ids=666 tagged=br1,sfp1 untagged=""

/interface vlan add interface=br1 vlan-id=552 name=br1-vlan552
# ^^ add your dhcp client or ip address to the VLAN interface of br1-vlan552
Wrote this from memory w/o plugging the commands in so might be a typo or two.
 
KBV
Frequent Visitor
Frequent Visitor
Posts: 79
Joined: Mon Nov 10, 2014 7:02 pm

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

Tue Dec 12, 2017 8:51 pm

Hi!
I have a simple configuration of the router rb3011 - two software bridges and do not use the master port (there are vlans on ethernet interfaces).
The update to version 6.41rc62 is done correctly, but in one of the networks packet loss starts.
Communication with the nodes of this network arbitrarily disappears and appears again.
There are no changes in the bridge settings - but the problem appears.
Using or not using the hw-offload does not affect the situation.

In the previous version 6.41rc56 was the same.
I read the thread and did not find the description of a similar problem. It surprises me.
 
KBV
Frequent Visitor
Frequent Visitor
Posts: 79
Joined: Mon Nov 10, 2014 7:02 pm

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

Wed Dec 13, 2017 10:16 am

Using or not using the hw-offload does not affect the situation.
I'm sorry. It seems the problem only occurs when I turn on the hw-offload.
 
anuser
Long time Member
Long time Member
Posts: 601
Joined: Sat Nov 29, 2014 7:27 pm

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

Wed Dec 13, 2017 10:38 am

I use CAPSMAN based forwarding with around 80 WAP AC / HAP AC devices. I updated the access points to v6.41rc61 and now all access points disconnect concurrently from the controller from time to time: "lost connection, send timeout"
 
pe1chl
Forum Guru
Forum Guru
Posts: 10196
Joined: Mon Jun 08, 2015 12:09 pm

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

Wed Dec 13, 2017 12:10 pm

I read the thread and did not find the description of a similar problem. It surprises me.
I have described my efforts and I have problems as well, also in a configuration where different VLANs are in different bridges in the 6.40 version and I tried migration to 6.41RC.
For me it works just after the migration but it falls apart when I convert it to the 6.41 solution (all the VLANs in a single bridge, and with HW acceleration).
I went back to 6.40 and found I had issues there as well with HW acceleration, but only on switch2.
 
User avatar
lemointernet
just joined
Posts: 3
Joined: Wed Jul 05, 2017 12:23 pm

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

Wed Dec 13, 2017 5:34 pm

Any final version release date ?
 
planetcoop
Member Candidate
Member Candidate
Posts: 140
Joined: Thu May 15, 2014 2:32 pm
Location: Sacramento, CA

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

Wed Dec 13, 2017 5:36 pm

Support,

I have found an issue with v6.41rc61 and DHCP. I have several networks and ip pools configured but have found that upgrading to the rc61 build the dhcp server is handing out DNS server that the ccr1036 is using. This is not the same list of DNS server client should use. I have test reverted to rc58 and 6.40.5 to correct the issue. Loading rc61 will recreate the issue.

Thank you,
Planetcoop
 
Samot
Member Candidate
Member Candidate
Posts: 113
Joined: Sat Nov 25, 2017 10:01 pm

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

Wed Dec 13, 2017 6:21 pm

Support,

I have found an issue with v6.41rc61 and DHCP. I have several networks and ip pools configured but have found that upgrading to the rc61 build the dhcp server is handing out DNS server that the ccr1036 is using. This is not the same list of DNS server client should use. I have test reverted to rc58 and 6.40.5 to correct the issue. Loading rc61 will recreate the issue.

Thank you,
Planetcoop
So is this list of DNS servers configured in the DHCP Networks for this DHCP Server/Pool? I'm running a couple systems on 6.41rc61 and have DHCP Servers on two interfaces that assign DNS to the clients. I'm not having an issue with it.
 
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!

Wed Dec 13, 2017 10:12 pm

Support,

I have found an issue with v6.41rc61 and DHCP. I have several networks and ip pools configured but have found that upgrading to the rc61 build the dhcp server is handing out DNS server that the ccr1036 is using. This is not the same list of DNS server client should use. I have test reverted to rc58 and 6.40.5 to correct the issue. Loading rc61 will recreate the issue.

Thank you,
Planetcoop

See topic at link viewtopic.php?f=1&t=128454
 
alexjhart
Member Candidate
Member Candidate
Posts: 197
Joined: Thu Jan 20, 2011 8:03 pm

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

Thu Dec 14, 2017 2:28 am

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?
Do you have support output files from older RC where the static bridge ports were working ok? Did you make a new support output file after the upgrade where the bridge ports disappeared?

About wireless disconnection Only the AP was upgraded the to the newest RC version or also the Clients as well? What are the disconnect messages? Do you have a support output files?

Send all that info to support@mikrotik.com

Uldis, sorry, I have not support files. Right now I'm trying do several reboot with disappeared ports after another upgrade to rc61, but ports still exists. I have made suppout files with working configurations on both versions. Maybe time of working is to short. Next reboot will be done tomorrow.

SXT ac have actual this same problem on rc56 - maybe channel overlapping with diffrent networks - I will give a feedback.
I believe I also have run into this behavior. I had two different routers (configured similarly) both have several (but not all) ports disappear (not in print or export) from the bridge on system reboot. Though after adding them back and rebooting again, they were in there.

For me, the ports in the first switch chip that I had configured remained (2 and 3) but those in the second went away (5-9) on a 3011. Not sure if that is helpful information for you Uldis?
 
planetcoop
Member Candidate
Member Candidate
Posts: 140
Joined: Thu May 15, 2014 2:32 pm
Location: Sacramento, CA

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

Thu Dec 14, 2017 2:32 am

Support,

I have found an issue with v6.41rc61 and DHCP. I have several networks and ip pools configured but have found that upgrading to the rc61 build the dhcp server is handing out DNS server that the ccr1036 is using. This is not the same list of DNS server client should use. I have test reverted to rc58 and 6.40.5 to correct the issue. Loading rc61 will recreate the issue.

Thank you,
Planetcoop

See topic at link viewtopic.php?f=1&t=128454
yup, that is the issue....
 
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 Dec 14, 2017 5:17 pm

Hi,

I have a router CCR1036 directly connected to a switch CRS226 via vlan trunk on bridge1 (with rstp) through sfpplus1 port. There is a IP device connected to ether1 access port on CRS226. WAN is ether8 port on CCR1036. I can do ping from both, CCR1036 and CRS226, to IP device.

I succesfully run L2TP/IPsec and OVPN services, both are working, but I can't ping from both to IP device when connected from VPN client. I tried to setup proxy-arp on bridge1, sfpplus1, vlan10 and ether8 interfaces, but nothing helped me to rich IP device from VPN client.
### CCR1036 ###
 
/interface bridge
add name=bridge1 vlan-filtering=no

/interface bridge port
add bridge=bridge1 interface=sfpplus1

/interface bridge vlan
add bridge=bridge1 tagged=bridge1,sfpplus1 vlan-ids=10

/interface vlan
add interface=bridge1 vlan-id=10 name=vlan10

/interface bridge
set bridge1 vlan-filtering=yes

### CRS226 ###

/interface bridge
add name=bridge1 vlan-filtering=no

/interface bridge port
add bridge=bridge1 interface=sfpplus1
add bridge=bridge1 interface=ether1

/interface ethernet switch ingress-vlan-translation
add ports=ether1 customer-vid=0 new-customer-vid=10 sa-learning=yes

/interface ethernet switch egress-vlan-tag
add tagged-ports=switch1-cpu,sfpplus1 vlan-id=10

/interface ethernet switch vlan
add ports=switch1-cpu,sfpplus1,ether1 vlan-id=10 learn=yes

/interface ethernet switch
set drop-if-invalid-or-src-port-not-member-of-vlan-on-ports=ether1

/interface vlan
add interface=bridge1 vlan-id=10 name=vlan10
Where should be problem please? Running v6.41rc61

Pavel
Last edited by kait on Thu Dec 14, 2017 8:35 pm, edited 2 times in total.
 
idlemind
Forum Guru
Forum Guru
Posts: 1146
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Thu Dec 14, 2017 8:31 pm

Hi,

is proxy-arp on v6.41rc61 working? I have CCR1036 directly connected to CRS226. I have vlan trunk on bridge between them. On CRS226 I have acces port and connected device with IP, i can ping IP from router and switch.

I configured L2TP/IPsec and OVPN services, both are working, but I can't ping the device IP from VPN client. Where should be problem? I tried to setup proxy-arp on bridge, on vlan interfaces on router and also on switch, but nothing helped.

Pavel
While not directly answering your question. Please do not use overlapping IP space for your VPN. I know some of the wiki articles set it up that way. By changing to a non overlapping IP space it will just work, no Proxy-ARP magic needed.
 
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 Dec 14, 2017 8:42 pm

Hi,

is proxy-arp on v6.41rc61 working? I have CCR1036 directly connected to CRS226. I have vlan trunk on bridge between them. On CRS226 I have acces port and connected device with IP, i can ping IP from router and switch.

I configured L2TP/IPsec and OVPN services, both are working, but I can't ping the device IP from VPN client. Where should be problem? I tried to setup proxy-arp on bridge, on vlan interfaces on router and also on switch, but nothing helped.

Pavel
While not directly answering your question. Please do not use overlapping IP space for your VPN. I know some of the wiki articles set it up that way. By changing to a non overlapping IP space it will just work, no Proxy-ARP magic needed.
Hi idlemind,

I modified my post to make it clearer. I use, for example: ppp 10.10.10.0/24, vlan10 192.168.10.0/24.

Pavel
 
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!

Fri Dec 15, 2017 11:18 am

Hi,

I have a router CCR1036 directly connected to a switch CRS226 via vlan trunk on bridge1 (with rstp) through sfpplus1 port. There is a IP device connected to ether1 access port on CRS226. WAN is ether8 port on CCR1036. I can do ping from both, CCR1036 and CRS226, to IP device.

I succesfully run L2TP/IPsec and OVPN services, both are working, but I can't ping from both to IP device when connected from VPN client. I tried to setup proxy-arp on bridge1, sfpplus1, vlan10 and ether8 interfaces, but nothing helped me to rich IP device from VPN client.
### CCR1036 ###
 
/interface bridge
add name=bridge1 vlan-filtering=no

/interface bridge port
add bridge=bridge1 interface=sfpplus1

/interface bridge vlan
add bridge=bridge1 tagged=bridge1,sfpplus1 vlan-ids=10

/interface vlan
add interface=bridge1 vlan-id=10 name=vlan10

/interface bridge
set bridge1 vlan-filtering=yes

### CRS226 ###

/interface bridge
add name=bridge1 vlan-filtering=no

/interface bridge port
add bridge=bridge1 interface=sfpplus1
add bridge=bridge1 interface=ether1

/interface ethernet switch ingress-vlan-translation
add ports=ether1 customer-vid=0 new-customer-vid=10 sa-learning=yes

/interface ethernet switch egress-vlan-tag
add tagged-ports=switch1-cpu,sfpplus1 vlan-id=10

/interface ethernet switch vlan
add ports=switch1-cpu,sfpplus1,ether1 vlan-id=10 learn=yes

/interface ethernet switch
set drop-if-invalid-or-src-port-not-member-of-vlan-on-ports=ether1

/interface vlan
add interface=bridge1 vlan-id=10 name=vlan10
Where should be problem please? Running v6.41rc61

Pavel
My ppp subnet is, let's say, 10.10.10.0/24 and vlan10 subnet is 192.168.10.0/24.

ppp local: 10.10.10.1/24
ppp remote: 10.10.10.2/24
vlan10 on CCR1036: 192.168.10.1/24
IP device on access port on CRS226: 192.168.10.2/24
### ping from CCR1036 to IP device on CRS226 through vlan10 interface ###
[user@CCR1036] > ping 192.168.10.2 src-address=192.168.10.1 
  SEQ HOST                                     SIZE TTL TIME  STATUS                                                                                           
    0 192.168.10.2                               56  64 0ms  
    sent=1 received=1 packet-loss=0% min-rtt=0ms avg-rtt=0ms max-rtt=0ms 

### ping from CCR1036 to IP device on CRS226 through ppp local interface ###
[user@CCR1036] > ping 192.168.10.2 src-address=10.10.10.1 
  SEQ HOST                                     SIZE TTL TIME  STATUS                                                                                           
    0 192.168.10.2                                            timeout                                                                                          
    sent=1 received=0 packet-loss=100% 
So I'm not surprised I can't ping from ppp remote 10.10.10.2 to IP device, when ping from ppp local to IP device is not working. Do I miss something?
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1623
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Fri Dec 15, 2017 1:55 pm

What's new in 6.41rc66 (2017-Dec-14 13:53):

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:

!) routerboot - RouterBOOT version numbering system merged with RouterOS;
*) capsman - added possibility to downgrade CAP with upgrade command from CAPsMAN;
*) crs326 - improved transmit performance from SFP+ to Ethernet ports;
*) dhcp-server - added basic RADIUS accounting;
*) ike1 - disallow peer creation using base mode;
*) ike2 - added support for multiple split networks;
*) ike2 - do not allow to configure nat-traversal;
*) ipsec - improved hardware accelerated IPSec performance on 750Gr3;
*) ppp - fixed "change-mss" functionality when MSS option is missing on forwarded packets;
*) ppp - fixed L2TP and PPTP encryption negotiation process on configuration changes;
*) pppoe-client - properly re-establish MLPPP session when one of the lines stopped transmitting packets;
*) quickset - fixed LTE quickset mode APN field;
*) route - improved reliability on routing table update;
*) snmp - fixed bulk requests when non-repeaters are used;
*) wireless - added support for CHARGEABLE_USER_ID in EAP Accounting;
*) wireless - updated "UK 5.8 Fixed" and "Australia" 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
Chupaka
Forum Guru
Forum Guru
Posts: 8709
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

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

Fri Dec 15, 2017 2:03 pm

*) dhcp-server - added basic RADIUS accounting;
Wow!.. What does it account?
 
msatter
Forum Guru
Forum Guru
Posts: 2897
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

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

Fri Dec 15, 2017 4:06 pm

Today I put rc66 on my 750Gr3, it was the first time I used this reiteration of 6.41RC.

After reboot I put bridge and ports (interfaces) because it was not done and my old config worked till the 750Gr3 crashed after about 3 minutes and lost his config. It went back to default config after a reset, because I could not connect to the 750Gr3 in any way.

Put backup back that I made with 6.40.5 and added again the bridge and ports and it crashed again after a few minutes. Went back to 6.40.5 and restored the backup so that was my adventure with the reiteration of 6.41.

I have a autosupout.rif file will e-mail that to support.
 
Grickos
newbie
Posts: 35
Joined: Thu Aug 06, 2015 2:57 am
Location: Croatia

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

Fri Dec 15, 2017 5:17 pm

DHCP server, DNS setings still does not work.
 
User avatar
ErfanDL
Member
Member
Posts: 366
Joined: Thu Sep 29, 2016 9:13 am

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

Fri Dec 15, 2017 5:50 pm

*) wireless - added support for CHARGEABLE_USER_ID in EAP Accounting;
What does this feature do?
 
andriys
Forum Guru
Forum Guru
Posts: 1526
Joined: Thu Nov 24, 2011 1:59 pm
Location: Kharkiv, Ukraine

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

Fri Dec 15, 2017 6:21 pm

*) wireless - added support for CHARGEABLE_USER_ID in EAP Accounting;
What does this feature do?
Implements rfc4372, I guess.
 
Neovr
newbie
Posts: 38
Joined: Wed Aug 27, 2008 10:13 pm

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

Fri Dec 15, 2017 10:07 pm

*) route - improved reliability on routing table update;
more info?
 
hapi
Member Candidate
Member Candidate
Posts: 232
Joined: Fri Mar 11, 2011 11:21 am
Location: Czech Republic

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

Sun Dec 17, 2017 12:07 am

v6.41rc61 and v6.41rc66

AP - RB921GS-5HPacD (a/n/ac)
CL - RB411+R52

in nstreme not connecting to ap. In NV2 is ok. Other RB SXT is connecting ok in nstreme.
 
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!

Sun Dec 17, 2017 1:41 am

DHCP server, DNS setings still does not work.

In my case, DNS servers are both from dhcp server and client, at all hosts in networks.
MT, please revert back it. I have several networks and some of them use DNS parental control access to the internet. I must use nat redirects and access lists.
 
Zloy2452
just joined
Posts: 12
Joined: Fri Dec 08, 2017 4:12 pm

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

Sun Dec 17, 2017 3:31 am

I have to stick with rc56 until DNS issue got fixed. Please, Mikrotik, we need a fix as soon as it possible!
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1623
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Mon Dec 18, 2017 8:29 am

If you are experiencing problems with DHCP on latest RouterOS version, then please do the following:
1) Run this command on router - "/system logging add topics=dhcp"
2) Renew DHCP client;
3) Generate supout file;
4) Send this file to support@mikrotik.com and provide problem description.

We are not being able to reproduce such problem between two RouterOS devices. If DHCP client is not receiving/adding DHCP parameters, then this must be something specific and in order to fix this we need to see this on an actual example.
 
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!

Mon Dec 18, 2017 10:57 am

If you are experiencing problems with DHCP on latest RouterOS version, then please do the following:
1) Run this command on router - "/system logging add topics=dhcp"
2) Renew DHCP client;
3) Generate supout file;
4) Send this file to support@mikrotik.com and provide problem description.

We are not being able to reproduce such problem between two RouterOS devices. If DHCP client is not receiving/adding DHCP parameters, then this must be something specific and in order to fix this we need to see this on an actual example.


Done, suppout file you have on e-mail, [Ticket#2017121822002736]
I have this problem on all my MT devices with rc61 and rc66.
 
onnoossendrijver
Member
Member
Posts: 486
Joined: Mon Jul 14, 2008 11:10 am
Location: The Netherlands

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

Mon Dec 18, 2017 11:05 am

*) ipsec - improved hardware accelerated IPSec performance on 750Gr3;
Can you tell me more about this?
 
JimmyNyholm
Member Candidate
Member Candidate
Posts: 248
Joined: Mon Apr 25, 2016 2:16 am
Location: Sweden

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

Mon Dec 18, 2017 11:13 am

In this new bridge implementation what is Actually correct.
[admin@MikroTik] /interface ethernet switch port> print
Flags: I - invalid
# NAME SWITCH VLAN-MODE VLAN-HEADER DEFAULT-VLAN-ID INGRESS-RATE EGRESS-RATE
0 sfp-sfpplus2 switch1 secure leave-as-is 1 5.0Mbps 15.0Mbps
1 sfp-sfpplus3 switch1 secure leave-as-is 1 5.0Mbps 15.0Mbps
2 sfp-sfpplus4 switch1 secure leave-as-is 1 5.0Mbps 15.0Mbps
3 sfp-sfpplus5 switch1 secure leave-as-is 1 5.0Mbps 15.0Mbps
4 sfp-sfpplus6 switch1 secure leave-as-is 1 5.0Mbps 15.0Mbps
5 sfp-sfpplus7 switch1 secure leave-as-is 1 5.0Mbps 15.0Mbps
6 sfp-sfpplus8 switch1 secure leave-as-is 1 5.0Mbps 15.0Mbps
7 sfp-sfpplus9 switch1 secure leave-as-is 1 5.0Mbps 15.0Mbps
8 sfp-sfpplus10 switch1 secure leave-as-is 1 5.0Mbps 15.0Mbps
9 sfp-sfpplus11 switch1 secure leave-as-is 1 5.0Mbps 15.0Mbps
10 sfp-sfpplus12 switch1 secure leave-as-is 1 5.0Mbps 15.0Mbps
11 sfp-sfpplus13 switch1 secure leave-as-is 1 5.0Mbps 15.0Mbps
12 sfp-sfpplus14 switch1 secure leave-as-is 1 5.0Mbps 15.0Mbps
13 sfp-sfpplus15 switch1 secure leave-as-is 1 5.0Mbps 15.0Mbps
14 sfp-sfpplus16 switch1 secure leave-as-is 1 5.0Mbps 15.0Mbps
15 ether1 switch1 secure leave-as-is 1
16 sfp-sfpplus1 switch1 secure leave-as-is 1
17 switch1-cpu switch1 secure leave-as-is 1
[admin@MikroTik] /interface ethernet switch port> /interface bridge port print
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload
# INTERFACE BRIDGE HW PVID PRIORITY PATH-COST INTERNAL-PATH-COST HORIZON
0 I H sfp-sfpplus2 bridge1 yes 64 0x80 10 10 none
1 I H sfp-sfpplus1 bridge1 yes 64 0x80 10 10 none
2 I H sfp-sfpplus3 bridge1 yes 64 0x80 10 10 none
3 I H sfp-sfpplus4 bridge1 yes 64 0x80 10 10 none
4 I H sfp-sfpplus5 bridge1 yes 64 0x80 10 10 none
5 I H sfp-sfpplus6 bridge1 yes 64 0x80 10 10 none
6 I H sfp-sfpplus7 bridge1 yes 64 0x80 10 10 none
7 I H sfp-sfpplus8 bridge1 yes 64 0x80 10 10 none
8 I H sfp-sfpplus9 bridge1 yes 64 0x80 10 10 none
9 I H sfp-sfpplus10 bridge1 yes 64 0x80 10 10 none
10 I H sfp-sfpplus11 bridge1 yes 64 0x80 10 10 none
11 I H sfp-sfpplus12 bridge1 yes 64 0x80 10 10 none
12 I H sfp-sfpplus13 bridge1 yes 64 0x80 10 10 none
13 I H sfp-sfpplus14 bridge1 yes 64 0x80 10 10 none
14 I H sfp-sfpplus15 bridge1 yes 64 0x80 10 10 none
15 I H sfp-sfpplus16 bridge1 yes 64 0x80 10 10 none
[admin@MikroTik] /interface ethernet switch port>

Are all features that are not reflected to switch menu to be considered overridden by bridge and feature that bridge don't have to be considered functioning in switch menu.... The current state is very unintuitive please release some clean up so we may have a look and feel about your release of this bridge functions. I've read the updated wiki and even though it have section with pre and post 41rc switch menu is used for all nice features on the switch chip.

In the above setting pvid on /interface/bridge/port is not setting it hardware wise at /interface/ethernet/switch/port so my real question is: Are there any corner cases when ingress frames will be assigned vlan 1?
Another observation setting /interface/bride/port acceptable-frame-types is not reflected back on /interface/ethernet/switch/port: Do I need to set the switch port counterpart setting to be on the safe side in corner cases as well.

Function wise the new implementation seems to work good but the system as a whole is not ready because I as user and admin can't read the manual nor see the intention in the currently available release candidate. Do you understand the confusion?

PS: Output is from a CRS317-1G-16S+ Hence my questioning running RouterOs on a switch...
 
Grickos
newbie
Posts: 35
Joined: Thu Aug 06, 2015 2:57 am
Location: Croatia

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

Mon Dec 18, 2017 6:33 pm

If you are experiencing problems with DHCP on latest RouterOS version, then please do the following:
1) Run this command on router - "/system logging add topics=dhcp"
2) Renew DHCP client;
3) Generate supout file;
4) Send this file to support@mikrotik.com and provide problem description.

We are not being able to reproduce such problem between two RouterOS devices. If DHCP client is not receiving/adding DHCP parameters, then this must be something specific and in order to fix this we need to see this on an actual example.
I only send settings and logs.
It is easy to reproduce the problem because it is so behaving on all router boards.
+++++++++++  DHCP server  +++++++++++++ 

/ip dhcp-server network> print
Flags: D - dynamic 
 #   ADDRESS            GATEWAY         DNS-SERVER      WINS-SERVER     DOMAIN   
 0   192.168.0.0/24     192.168.0.1     192.168.0.1                     
 1   192.168.30.0/24    192.168.30.1    192.168.30.1                    
 2   192.168.90.0/24    192.168.90.1    192.168.90.1                    

 /ip dns> print
                      servers: 213.191.128.8,8.8.8.8,4.2.2.2
              dynamic-servers: 
        allow-remote-requests: yes
          max-udp-packet-size: 4096
         query-server-timeout: 2s
          query-total-timeout: 10s
       max-concurrent-queries: 100
  max-concurrent-tcp-sessions: 20
                   cache-size: 2048KiB
                cache-max-ttl: 1w
                   cache-used: 168KiB

+++++++++++++++++   DHCP Client  ++++++++++++++++

/ip dhcp-client> print detail
Flags: X - disabled, I - invalid 
 0   interface=ether1 add-default-route=yes default-route-distance=0 use-peer-dns=yes use-peer-ntp=yes dhcp-options=hostname,clientid status=bound 
     address=192.168.0.5/24 gateway=192.168.0.1 dhcp-server=192.168.0.1 primary-dns=192.168.0.1 secondary-dns=213.191.128.8 primary-ntp=161.53.123.5 
     secondary-ntp=66.199.22.67 expires-after=23h51m19s 

/ip dns> print
                      servers: 
              dynamic-servers: 192.168.0.1,213.191.128.8,8.8.8.8,4.2.2.2
        allow-remote-requests: no
          max-udp-packet-size: 4096
         query-server-timeout: 2s
          query-total-timeout: 10s
       max-concurrent-queries: 100
  max-concurrent-tcp-sessions: 20
                   cache-size: 2048KiB
                cache-max-ttl: 1w
                   cache-used: 9KiB

				   
+++++++++++++++Log Debug++++++++++++

17:04:11 dhcp,debug,state dhcp-client on ether1 entering <renewing...> state 
17:04:11 dhcp,debug,packet dhcp-client on ether1 sending request with id 2667306647 to 192.168.0.1 
17:04:11 dhcp,debug,packet     ciaddr = 192.168.0.5 
17:04:11 dhcp,debug,packet     chaddr = 6C:3B:6B:00:00:01 
17:04:11 dhcp,debug,packet     Msg-Type = request 
17:04:11 dhcp,debug,packet     Parameter-List = Subnet-Mask,Classless-Route,Router,Static-Route,Domain-Server,NTP-Server,CAPWAP-Server,Vendor-Specific 
17:04:11 dhcp,debug,packet     Host-Name = "name" 
17:04:11 dhcp,debug,packet     Client-Id = 01-6C-3B-6B-00:00:01 
17:04:11 dhcp,debug,packet dhcp-client on ether1 received ack with id 2667306647 from 192.168.0.1 
17:04:11 dhcp,debug,packet     ciaddr = 192.168.0.5 
17:04:11 dhcp,debug,packet     yiaddr = 192.168.0.5 
17:04:11 dhcp,debug,packet     siaddr = 192.168.0.1 
17:04:11 dhcp,debug,packet     chaddr = 6C:3B:6B:00:00:01 
17:04:11 dhcp,debug,packet     Msg-Type = ack 
17:04:11 dhcp,debug,packet     Server-Id = 192.168.0.1 
17:04:11 dhcp,debug,packet     Address-Time = 86400 
17:04:11 dhcp,debug,packet     Subnet-Mask = 255.255.255.0 
17:04:11 dhcp,debug,packet     Router = 192.168.0.1 
17:04:11 dhcp,debug,packet     Domain-Server = 192.168.0.1,213.191.128.8,8.8.8.8,4.2.2.2 
17:04:11 dhcp,debug,packet     NTP-Server = 161.53.123.5,66.199.22.67 
17:04:11 dhcp,debug,state dhcp-client on ether1 entering <bound> state 
17:08:34 dhcp,debug,state dhcp-client on ether1 entering <renewing...> state 
17:08:34 dhcp,debug,packet dhcp-client on ether1 sending request with id 2667306647 to 192.168.0.1 
17:08:34 dhcp,debug,packet     ciaddr = 192.168.0.5 
17:08:34 dhcp,debug,packet     chaddr = 6C:3B:6B:00:00:01 
17:08:34 dhcp,debug,packet     Msg-Type = request 
17:08:34 dhcp,debug,packet     Parameter-List = Subnet-Mask,Classless-Route,Router,Static-Route,Domain-Server,NTP-Server,CAPWAP-Server,Vendor-Specific 
17:08:34 dhcp,debug,packet     Host-Name = "name" 
17:08:34 dhcp,debug,packet     Client-Id = 01-6C-3B-6B-00-00-01 
17:08:34 dhcp,debug,packet dhcp-client on ether1 received ack with id 2667306647 from 192.168.0.1 
17:08:34 dhcp,debug,packet     ciaddr = 192.168.0.5 
17:08:34 dhcp,debug,packet     yiaddr = 192.168.0.5 
17:08:34 dhcp,debug,packet     siaddr = 192.168.0.1 
17:08:34 dhcp,debug,packet     chaddr = 6C:3B:6B:00:00:01 
17:08:34 dhcp,debug,packet     Msg-Type = ack 
17:08:34 dhcp,debug,packet     Server-Id = 192.168.0.1 
17:08:34 dhcp,debug,packet     Address-Time = 86400 
17:08:34 dhcp,debug,packet     Subnet-Mask = 255.255.255.0 
17:08:34 dhcp,debug,packet     Router = 192.168.0.1 
17:08:34 dhcp,debug,packet     Domain-Server = 192.168.0.1,213.191.128.8,8.8.8.8,4.2.2.2 
17:08:34 dhcp,debug,packet     NTP-Server = 161.53.123.5,66.199.22.67 
17:08:34 dhcp,debug,state dhcp-client on ether1 entering <bound> state
 
msatter
Forum Guru
Forum Guru
Posts: 2897
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

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

Mon Dec 18, 2017 8:03 pm

*) ipsec - improved hardware accelerated IPSec performance on 750Gr3;
Can you tell me more about this?
I tried to run this version on my 750Gr3 but became totally unreachable after a few minutes.

When I put a heavy load on IPSEC by using several connections the load is not distributed and the first core goes to 100% and the fourth sometimes follows. I hoped this change would distribute the load better.
 
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!

Mon Dec 18, 2017 8:19 pm

If you are experiencing problems with DHCP on latest RouterOS version, then please do the following:
1) Run this command on router - "/system logging add topics=dhcp"
2) Renew DHCP client;
3) Generate supout file;
4) Send this file to support@mikrotik.com and provide problem description.

We are not being able to reproduce such problem between two RouterOS devices. If DHCP client is not receiving/adding DHCP parameters, then this must be something specific and in order to fix this we need to see this on an actual example.
I only send settings and logs.
It is easy to reproduce the problem because it is so behaving on all router boards.
+++++++++++  DHCP server  +++++++++++++ 

/ip dhcp-server network> print
Flags: D - dynamic 
 #   ADDRESS            GATEWAY         DNS-SERVER      WINS-SERVER     DOMAIN   
 0   192.168.0.0/24     192.168.0.1     192.168.0.1                     
 1   192.168.30.0/24    192.168.30.1    192.168.30.1                    
 2   192.168.90.0/24    192.168.90.1    192.168.90.1                    

 /ip dns> print
                      servers: 213.191.128.8,8.8.8.8,4.2.2.2
              dynamic-servers: 
        allow-remote-requests: yes
          max-udp-packet-size: 4096
         query-server-timeout: 2s
          query-total-timeout: 10s
       max-concurrent-queries: 100
  max-concurrent-tcp-sessions: 20
                   cache-size: 2048KiB
                cache-max-ttl: 1w
                   cache-used: 168KiB

+++++++++++++++++   DHCP Client  ++++++++++++++++

/ip dhcp-client> print detail
Flags: X - disabled, I - invalid 
 0   interface=ether1 add-default-route=yes default-route-distance=0 use-peer-dns=yes use-peer-ntp=yes dhcp-options=hostname,clientid status=bound 
     address=192.168.0.5/24 gateway=192.168.0.1 dhcp-server=192.168.0.1 primary-dns=192.168.0.1 secondary-dns=213.191.128.8 primary-ntp=161.53.123.5 
     secondary-ntp=66.199.22.67 expires-after=23h51m19s 

/ip dns> print
                      servers: 
              dynamic-servers: 192.168.0.1,213.191.128.8,8.8.8.8,4.2.2.2
        allow-remote-requests: no
          max-udp-packet-size: 4096
         query-server-timeout: 2s
          query-total-timeout: 10s
       max-concurrent-queries: 100
  max-concurrent-tcp-sessions: 20
                   cache-size: 2048KiB
                cache-max-ttl: 1w
                   cache-used: 9KiB

				   
+++++++++++++++Log Debug++++++++++++

17:04:11 dhcp,debug,state dhcp-client on ether1 entering <renewing...> state 
17:04:11 dhcp,debug,packet dhcp-client on ether1 sending request with id 2667306647 to 192.168.0.1 
17:04:11 dhcp,debug,packet     ciaddr = 192.168.0.5 
17:04:11 dhcp,debug,packet     chaddr = 6C:3B:6B:00:00:01 
17:04:11 dhcp,debug,packet     Msg-Type = request 
17:04:11 dhcp,debug,packet     Parameter-List = Subnet-Mask,Classless-Route,Router,Static-Route,Domain-Server,NTP-Server,CAPWAP-Server,Vendor-Specific 
17:04:11 dhcp,debug,packet     Host-Name = "name" 
17:04:11 dhcp,debug,packet     Client-Id = 01-6C-3B-6B-00:00:01 
17:04:11 dhcp,debug,packet dhcp-client on ether1 received ack with id 2667306647 from 192.168.0.1 
17:04:11 dhcp,debug,packet     ciaddr = 192.168.0.5 
17:04:11 dhcp,debug,packet     yiaddr = 192.168.0.5 
17:04:11 dhcp,debug,packet     siaddr = 192.168.0.1 
17:04:11 dhcp,debug,packet     chaddr = 6C:3B:6B:00:00:01 
17:04:11 dhcp,debug,packet     Msg-Type = ack 
17:04:11 dhcp,debug,packet     Server-Id = 192.168.0.1 
17:04:11 dhcp,debug,packet     Address-Time = 86400 
17:04:11 dhcp,debug,packet     Subnet-Mask = 255.255.255.0 
17:04:11 dhcp,debug,packet     Router = 192.168.0.1 
17:04:11 dhcp,debug,packet     Domain-Server = 192.168.0.1,213.191.128.8,8.8.8.8,4.2.2.2 
17:04:11 dhcp,debug,packet     NTP-Server = 161.53.123.5,66.199.22.67 
17:04:11 dhcp,debug,state dhcp-client on ether1 entering <bound> state 
17:08:34 dhcp,debug,state dhcp-client on ether1 entering <renewing...> state 
17:08:34 dhcp,debug,packet dhcp-client on ether1 sending request with id 2667306647 to 192.168.0.1 
17:08:34 dhcp,debug,packet     ciaddr = 192.168.0.5 
17:08:34 dhcp,debug,packet     chaddr = 6C:3B:6B:00:00:01 
17:08:34 dhcp,debug,packet     Msg-Type = request 
17:08:34 dhcp,debug,packet     Parameter-List = Subnet-Mask,Classless-Route,Router,Static-Route,Domain-Server,NTP-Server,CAPWAP-Server,Vendor-Specific 
17:08:34 dhcp,debug,packet     Host-Name = "name" 
17:08:34 dhcp,debug,packet     Client-Id = 01-6C-3B-6B-00-00-01 
17:08:34 dhcp,debug,packet dhcp-client on ether1 received ack with id 2667306647 from 192.168.0.1 
17:08:34 dhcp,debug,packet     ciaddr = 192.168.0.5 
17:08:34 dhcp,debug,packet     yiaddr = 192.168.0.5 
17:08:34 dhcp,debug,packet     siaddr = 192.168.0.1 
17:08:34 dhcp,debug,packet     chaddr = 6C:3B:6B:00:00:01 
17:08:34 dhcp,debug,packet     Msg-Type = ack 
17:08:34 dhcp,debug,packet     Server-Id = 192.168.0.1 
17:08:34 dhcp,debug,packet     Address-Time = 86400 
17:08:34 dhcp,debug,packet     Subnet-Mask = 255.255.255.0 
17:08:34 dhcp,debug,packet     Router = 192.168.0.1 
17:08:34 dhcp,debug,packet     Domain-Server = 192.168.0.1,213.191.128.8,8.8.8.8,4.2.2.2 
17:08:34 dhcp,debug,packet     NTP-Server = 161.53.123.5,66.199.22.67 
17:08:34 dhcp,debug,state dhcp-client on ether1 entering <bound> state

Don't waste your time. I 've got an answer from MT today:
-----------------------------------------------
Hello,

Is DHCP client receiving DNS server specified under DHCP server network settings and DNS servers used by router itself?

If this is correct, then this is how RouterOS works. We will in future add option which will allow to enable/disable such functionality.

Best regards,
Martins S.
-----------------------------------------------

For me it is very unusable and reckless. I will revert back to rc56 until option which will allow to enable/disable such functionality will be implemented.
 
Zloy2452
just joined
Posts: 12
Joined: Fri Dec 08, 2017 4:12 pm

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

Mon Dec 18, 2017 8:44 pm

RafGan, thank you for posting this! I have mailed Mikrotik about this issue today, but have not received any answer from them by now.
If so, I will not upgrade from rc56, until they add an option to disable this new "mega-useful" feature. It's very pity that they have broken a thing, which had been working perfect for ages.
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4047
Joined: Wed May 11, 2011 6:08 pm

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

Mon Dec 18, 2017 9:38 pm

Don't waste your time. I 've got an answer from MT today:
-----------------------------------------------
Hello,

Is DHCP client receiving DNS server specified under DHCP server network settings and DNS servers used by router itself?

If this is correct, then this is how RouterOS works. We will in future add option which will allow to enable/disable such functionality.

Best regards,
Martins S.
-----------------------------------------------
They're just trying to achieve feature parity with the RADNSS "functionality" in IPv6. :roll:
 
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!

Mon Dec 18, 2017 11:06 pm

They're just trying to achieve feature parity with the RADNSS "functionality" in IPv6. :roll:
Maybe, but better is the enemy of good. Things, that works great a lot of time, should not be changed at the same time of major implements in one version of OS. DHCP server is a certain service in network. Also, infos for users (administrators) are very important.
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1623
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Tue Dec 19, 2017 10:00 am

At the moment DHCP DNS server problem reports in this post has been mixed up. There are reports that DNS servers are not assigned, too many servers are assigned and there is reference to DNS server assignment process discussed in support ticket to DHCP clients in general.

Explanation is this:
1) In the past and now (also before 6.41rc), if DHCP server network configuration does not contain DNS server settings, then same DNS servers which are used by router are assigned also for DHCP clients. This is the behavior for which we will consider implementing enable/disable functionality;
2) For DHCP clients only DNS servers provided in DHCP server network configuration must be assigned (at the moment this is broken and we will try to fix this).

If there is an actual case where DNS server is configured on DHCP server network settings but suddenly is not assigned for DHCP client when server uses 6.41rc version, then please report to support@mikrotik.com.
 
User avatar
emils
Forum Veteran
Forum Veteran
Posts: 906
Joined: Thu Dec 11, 2014 8:53 am

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

Tue Dec 19, 2017 11:18 am

Can you tell me more about this?
I tried to run this version on my 750Gr3 but became totally unreachable after a few minutes.

When I put a heavy load on IPSEC by using several connections the load is not distributed and the first core goes to 100% and the fourth sometimes follows. I hoped this change would distribute the load better.

The fix addresses exactly this issue. Were you able to recover the router after the loss of reachability? Are you able to reproduce the issue somehow?

*) route - improved reliability on routing table update;
more info?

There were some rare incidents that caused routing table update process to crash and start all over again. This fixes the issue.
 
msatter
Forum Guru
Forum Guru
Posts: 2897
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

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

Tue Dec 19, 2017 11:47 am

I tried to run this version on my 750Gr3 but became totally unreachable after a few minutes.

When I put a heavy load on IPSEC by using several connections the load is not distributed and the first core goes to 100% and the fourth sometimes follows. I hoped this change would distribute the load better.
The fix addresses exactly this issue. Were you able to recover the router after the loss of reachability? Are you able to reproduce the issue somehow?
My ticket number is: 2017121522004034 and I sent in an autosupport and support file

It crashed twice and a third time is expected when I update again from 6.40.5.

The router restarts and no normal way to connect. Even a notebook connected directly does not see a network.
 
User avatar
eworm
Forum Guru
Forum Guru
Posts: 1070
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

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

Tue Dec 19, 2017 2:30 pm

Successfully updated a CRS109-8G-1S-2HnD to version 6.41rc66, then installed the firmware update to version 6.41rc65 and rebooted. Now the device is stuck at 'staring services', which is displayed on the lcd display. No link on interfaces...
Anybody seen this? Is there any chance to recover without reset?
 
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!

Tue Dec 19, 2017 2:37 pm

Successfully updated a CRS109-8G-1S-2HnD to version 6.41rc66, then installed the firmware update to version 6.41rc65 and rebooted. Now the device is stuck at 'staring services', which is displayed on the lcd display. No link on interfaces...
Anybody seen this? Is there any chance to recover without reset?
If you can make a serial connection, you can check the boot process ...
Perhaps, there is no way to recover only by netinstall.
 
User avatar
eworm
Forum Guru
Forum Guru
Posts: 1070
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

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

Tue Dec 19, 2017 3:05 pm

Successfully updated a CRS109-8G-1S-2HnD to version 6.41rc66, then installed the firmware update to version 6.41rc65 and rebooted. Now the device is stuck at 'staring services', which is displayed on the lcd display. No link on interfaces...
Anybody seen this? Is there any chance to recover without reset?
If you can make a serial connection, you can check the boot process ...
Perhaps, there is no way to recover only by netinstall.
I connected a serial cable and messages are shown at boot time:
RouterBOOT booter 6.41rc65

CRS109-8G-1S-2HnD

CPU frequency: 600 MHz
 Memory speed: 200 MHz
  Memory size: 128 MiB
    NAND size: 128 MiB
       
Press any key within 2 seconds to enter setup..

loading kernel... OK
setting up elf image... OK
jumping to kernel code
Starting...
Starting services...
Followed by a login prompt:
MikroTik 6.41rc66 (testing)
e-mt-01 Login:
I can log in but most commands just hang.

CPU is at 100% with 99.5% to 100% for management.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10196
Joined: Mon Jun 08, 2015 12:09 pm

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

Tue Dec 19, 2017 4:19 pm

From what earlier version did you upgrade? 6.41RC too or before?
It looks like it is time for netinstall and restore backup.
 
User avatar
eworm
Forum Guru
Forum Guru
Posts: 1070
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

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

Tue Dec 19, 2017 5:13 pm

From what earlier version did you upgrade? 6.41RC too or before?
The device ran nearly every rc release from 6.41 series.
It looks like it is time for netinstall and restore backup.
Done. :D
Let's hope this does not happen more often.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10196
Joined: Mon Jun 08, 2015 12:09 pm

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

Tue Dec 19, 2017 5:26 pm

Let's hope this does not happen more often.
When it has more than 16MB flash (which unfortunately is quite common lately) you can partition the flash and
keep the previous version in the other partition. It is then easier to recover from such mishaps.
 
msatter
Forum Guru
Forum Guru
Posts: 2897
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

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

Tue Dec 19, 2017 9:14 pm

I hope Mikrotik won't rush 6.41 to be there before the end of the year and 2018 seems to be a good bridge year to the last digit of this year. :wink:
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4047
Joined: Wed May 11, 2011 6:08 pm

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

Thu Dec 21, 2017 5:40 pm

What's new in 6.41rc66 (2017-Dec-14 13:53):
*) dhcp-server - added basic RADIUS accounting;
The RADIUS accounting packets for DHCP sessions do not include the User-Name attribute, which should be set as the MAC address of the client, just as it had been sent in the authentication request.

Freeradius also logs warnings about this because the User-Name is part of its hashing for generating unique-session-id
 
JimmyNyholm
Member Candidate
Member Candidate
Posts: 248
Joined: Mon Apr 25, 2016 2:16 am
Location: Sweden

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

Thu Dec 21, 2017 8:11 pm

CRS317-1G-16S+RM is powered by a next generation switching chip, giving you wire speed performance for all sixteen 10GbE ports with any Ethernet frame size. New features such as hardware-based Spanning Tree Protocol and Link Aggregation (LACP) provide enhanced protection and true professional performance for your demanding network.
When can we se this hardware based LACP in Router Os?
If it's already there and I am a fool not to have found it then please tell me how to?
 
User avatar
eworm
Forum Guru
Forum Guru
Posts: 1070
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

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

Thu Dec 21, 2017 9:01 pm

Looks like demo Routerboards find final version 6.41... Is the release being prepare right now?
 
freemannnn
Forum Veteran
Forum Veteran
Posts: 700
Joined: Sun Oct 13, 2013 7:29 pm

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

Thu Dec 21, 2017 9:12 pm

Looks like demo Routerboards find final version 6.41... Is the release being prepare right now?

lol i didnt know this site all these years. thanx.
6.41...christmas present. if yes...nice
 
User avatar
honzam
Forum Guru
Forum Guru
Posts: 2394
Joined: Wed Feb 27, 2008 10:27 pm
Location: Czech Republic

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

Thu Dec 21, 2017 11:00 pm

Looks like demo Routerboards find final version 6.41... Is the release being prepare right now?
And demo3 http://demo3.mt.lv/webfig/#System:Packa ... or_Updates
:-)
 
skuykend
Member Candidate
Member Candidate
Posts: 274
Joined: Tue Oct 06, 2015 7:28 am

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

Fri Dec 22, 2017 1:16 am

Looks like demo Routerboards find final version 6.41... Is the release being prepare right now?
And no mention of the bridge update!
 
mducharme
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

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

Fri Dec 22, 2017 4:30 am

Looks like demo Routerboards find final version 6.41... Is the release being prepare right now?
And no mention of the bridge update!
The list of changes there is from some older version, it's not showing the correct change list.
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1623
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Fri Dec 22, 2017 3:00 pm

Version 6.41 has been released:
viewtopic.php?f=21&t=128915

Who is online

Users browsing this forum: akakua, DenisPDA and 12 guests