Community discussions

 
biatche
Member Candidate
Member Candidate
Posts: 128
Joined: Tue Oct 13, 2015 6:50 am

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

Tue Nov 28, 2017 8:12 pm

Dear all, has the development of ROS slowed down or is it my wrong impresion? One RC sub-version every one to two weeks where it used to be every two to three days and even then, very sparse changelog. Even this thread has become relatively quiet.

Can it possibly be that we approaching the end of v6 development? Just wondering...
Was wondering just the same.. yet ROS still lacks many basic features..
 
JimmyNyholm
Member Candidate
Member Candidate
Posts: 249
Joined: Mon Apr 25, 2016 2:16 am
Location: Sweden

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

Wed Nov 29, 2017 11:04 pm

New bridge implementation need:

Hardware LACP bonding.
Hardware setting per port of learning mode for mac-adresses max number and what to do when max is reached and or port/device restarted.
per port ingress and egress hardware rate limiting.
dhcp snooping with guard
arp snooping with guard
Option to hardware block malicious traffic in the above dhcp and arp concept.

In all essence be a real provider switch compairable to other switch vendors.

Other stuff is needed as well but that is for another day and discussion. This is what I think is needed before this new implementation is ready to hit the streets.
 
biatche
Member Candidate
Member Candidate
Posts: 128
Joined: Tue Oct 13, 2015 6:50 am

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

Thu Nov 30, 2017 12:51 am

New bridge implementation need:

Hardware LACP bonding.
Hardware setting per port of learning mode for mac-adresses max number and what to do when max is reached and or port/device restarted.
per port ingress and egress hardware rate limiting.
dhcp snooping with guard
arp snooping with guard
Option to hardware block malicious traffic in the above dhcp and arp concept.

In all essence be a real provider switch compairable to other switch vendors.

Other stuff is needed as well but that is for another day and discussion. This is what I think is needed before this new implementation is ready to hit the streets.
Agreed, these are some of the basic features i was talking about.
 
nkourtzis
Member Candidate
Member Candidate
Posts: 202
Joined: Tue Dec 11, 2012 12:56 am
Location: Greece

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

Thu Nov 30, 2017 11:35 am

New bridge implementation need:

Hardware LACP bonding.
Hardware setting per port of learning mode for mac-adresses max number and what to do when max is reached and or port/device restarted.
per port ingress and egress hardware rate limiting.
dhcp snooping with guard
arp snooping with guard
Option to hardware block malicious traffic in the above dhcp and arp concept.

In all essence be a real provider switch compairable to other switch vendors.

Other stuff is needed as well but that is for another day and discussion. This is what I think is needed before this new implementation is ready to hit the streets.

Also add Q-in-Q support.
Passionate about networks
Enthusiastic about Mikrotik
MTCNA | MTCRE | MTCINE

No trees were killed to send this message,
but a large number of electrons were terribly inconvenienced.
 
upower3
Member
Member
Posts: 377
Joined: Thu May 07, 2015 11:46 am

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

Thu Nov 30, 2017 11:56 am

I am wondering when they dare to release 6.41 as a "current" version with this risky "New bridge implementation" that will likely cause problems once it is widely deployed into many different field configurations (that combine VLAN tagging on switch and bridge now).
You may be right in that this could actually be released as part of "v7" so people are aware there are many changes and testing (rather than routine updating) is required.
True, now wise to roll up this "breaking" changes in "ordinary" release. Many people used to apply updates without reading out readme-s, or without huge testing, and this will break many setups around the world.

Being said, there are many h/w features that should be implemented as well, and upcoming situation (6.41 with its breakthrough features) won't be nice news for enterprise and ISP networks. Many company will find their network fail to work as before, and it'll be blamed on MT (well, this will be true), which will impact MT sales.

I just wonder if the new bridge implementation is something that can not wait for 7.x branch to be introduced? Something very urge to roll out?

This change (take for granted it'll break some setups around the world) will impact MT's reputation while won't give any benefits to customers. Many people won't give a damn if they have master/slave or bridge to employ h/w packet processing, but they surely be quite unhappy (and will spread the word) when their setup be break out of sudden.
 
User avatar
bajodel
Long time Member
Long time Member
Posts: 545
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

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

Fri Dec 01, 2017 10:58 am

In their shoes I would concurrently release a new 6.40.x in bugfix and stable, forcing all system to switch to bugfix channel as update default (6.40.x should then live in bugfix for long time).
For admins ready to 6.41 it would be simple enough as manually switch to current again; in this way all systems upgraded in a automatic/silent mode would be quite safe.
 
skuykend
Member Candidate
Member Candidate
Posts: 270
Joined: Tue Oct 06, 2015 7:28 am

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

Fri Dec 01, 2017 11:11 am

In their shoes I would concurrently release a new 6.40.x in bugfix and stable, forcing all system to switch to bugfix channel as update default (6.40.x should then live in bugfix for long time).
For admins ready to 6.41 it would be simple enough as manually switch to current again; in this way all systems upgraded in a automatic/silent mode would be quite safe.
+1
That seems quite clever. May bug a few, but would allow MikroTik to continue going forward much less risky.
 
upower3
Member
Member
Posts: 377
Joined: Thu May 07, 2015 11:46 am

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

Fri Dec 01, 2017 11:37 am

For admins ready to 6.41 it would be simple enough as manually switch.
It would be quite useful to create another forum topic to let users report their setups that failed to convert from master-slave to new bridge implementation. At least, this may be good to add these situation into config converter.
 
eriitguy
Member Candidate
Member Candidate
Posts: 197
Joined: Thu Jan 26, 2017 1:16 pm

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

Fri Dec 01, 2017 4:48 pm

Hello!

Maybe a force backup creation before update with notification about such behavior in changelog?


Thank you!
 
anuser
Member
Member
Posts: 369
Joined: Sat Nov 29, 2014 7:27 pm

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

Mon Dec 04, 2017 12:14 pm

I had problems with several Samsung Galaxy S7 Edge running Android 7 with wAP AC and central CAPSMAN controller running 6.40.5. The smartphones connected, but they had no internet. I updated the wAP AC from 6.40.5 to 6.41rc56. The CAPSMAN controller is still runing at 6.40.5
Now the smartphones can connect and have internet access. With version 6.40.5 again, they had problems again.
 
biatche
Member Candidate
Member Candidate
Posts: 128
Joined: Tue Oct 13, 2015 6:50 am

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

Mon Dec 04, 2017 2:27 pm

Dear mikrotik, why has development slowed down? In the past we used to see a new rc every 3-5 days.
 
Paternot
Long time Member
Long time Member
Posts: 578
Joined: Thu Jun 02, 2016 4:01 am
Location: Niterói / Brazil

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

Mon Dec 04, 2017 2:44 pm

Dear mikrotik, why has development slowed down? In the past we used to see a new rc every 3-5 days.
I noticed that too. But 6.41 is a big step, with bridge hardware offloading and whatnot. I believe they are testing the (numerous) bugs already found, and preparing for another RC - or the gold one.
 
raffav
Member Candidate
Member Candidate
Posts: 278
Joined: Wed Oct 24, 2012 4:40 am

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

Mon Dec 04, 2017 2:54 pm

What was the highest rc version ?
I also think they are fixing bugs, tweaking some functionality
Or maybe they are focus working on version 7

Enviado de meu XT1580 usando Tapatalk

 
User avatar
juliokato
Member Candidate
Member Candidate
Posts: 229
Joined: Mon Oct 26, 2015 4:27 pm
Location: Brazil

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

Mon Dec 04, 2017 4:33 pm

What was the highest rc version ?
I also think they are fixing bugs, tweaking some functionality
Or maybe they are focus working on version 7 Image

Enviado de meu XT1580 usando Tapatalk
Maybe renaming the V6.41RC to V7, since they introduced many new features. 8)
I apologize my grammatical errors, my english not so good, I am not a native speaker.
Wiki is maintained in English. I use Google translator. 8)
 
jarda
Forum Guru
Forum Guru
Posts: 7601
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: 5557
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: 60
Joined: Mon Oct 02, 2017 1:25 pm

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

Mon Dec 04, 2017 6:32 pm

Hi, small off-top when 6.41 will be as current version ?
Is there an initial deadline ?
I invite you to visit my blog
https://mikrotikon.pl/
 
pe1chl
Forum Guru
Forum Guru
Posts: 5557
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: 5557
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
newbie
Posts: 49
Joined: Fri Apr 11, 2014 9:32 pm
Location: Romania

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

Wed Dec 06, 2017 10:07 am

Dear mikrotik, why has development slowed down? In the past we used to see a new rc every 3-5 days.
Good point :?
MTCNA, MTCWE
 
jondavy
Member Candidate
Member Candidate
Posts: 124
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: 377
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: 1702
Joined: Mon Jun 16, 2014 1:13 pm
Location: Poland

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

Wed Dec 06, 2017 3:10 pm

+1 for upower3's idea of ROS 7.00.
Real admins use real keyboards.
 
User avatar
juliokato
Member Candidate
Member Candidate
Posts: 229
Joined: Mon Oct 26, 2015 4:27 pm
Location: Brazil

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

Wed Dec 06, 2017 3:19 pm

Dear mikrotik, why has development slowed down? In the past we used to see a new rc every 3-5 days.
Good point :?
Maybe freezing due to the holidays at the end of the year?
Many companies do this.
I apologize my grammatical errors, my english not so good, I am not a native speaker.
Wiki is maintained in English. I use Google translator. 8)
 
upower3
Member
Member
Posts: 377
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: 1406
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Wed Dec 06, 2017 3:32 pm

What's new in 6.41rc61 (2017-Dec-06 08:15):

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


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

Changes since previous 6.41rc release:

!) bridge - general implementation of hw-offload bridge (introduced in v6.40rc36);
*) bridge - disable "hw-offload" when "horizon" or "external-fdb" is set;
*) bridge - fixed hw-offloaded IGMP Snooping service getting stopped;
*) capsman - use "adaptive-noise-immunity" value from CAP local configuration;
*) certificate - added option to store CRL in RAM (CLI only);
*) certificate - improved CRL update after system startup;
*) certificate - show invalid flag when local CRL file does not exist;
*) crs317 - fixed reliability on FAN controller;
*) dhcpv4-server - added "NETWORK_GATEWAY" option variable;
*) filesystem - implemented additional system integrity checks on reboots;
*) firewall - added "tls-host" firewall matcher;
*) lte - fixed Passthrough support;
*) lte - update info command with "location area code" (LAC);
*) lte - provide lte info "physical cell id" values (R11e-LTE only);
*) ppp - added initial support for PLE902;
*) sms - log decoded USSD responses;
*) snmp - fixed consecutive OID bulk get from the same table when non-repeaters are > 0;
*) system - show USB topology for the device info;
*) webfig - fixed router getting reset to default configuration;
*) winbox - added switch menu on RB1100AHx4;
*) winbox - do not show MetaROUTER stuff on RB1100AHx4;
*) wireless - check APs against connect-list rules starting with strongest signal;
*) wireless - do not show background scan frequencies in the monitor command channel field;
*) wireless - fixed channel selection when special channels used (introduced in v6.41rc);
*) wireless - increased the EAP message retransmit count;

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after crash.
 
User avatar
Cha0s
Forum Veteran
Forum Veteran
Posts: 882
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: 1702
Joined: Mon Jun 16, 2014 1:13 pm
Location: Poland

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

Wed Dec 06, 2017 4:04 pm

What's new in 6.41rc61 (2017-Dec-06 08:15): ..
In Poland we say: "Hit the table and the scissors will make a sound" :-)
Real admins use real keyboards.
 
upower3
Member
Member
Posts: 377
Joined: Thu May 07, 2015 11:46 am

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

Wed Dec 06, 2017 4:14 pm

What's new in 6.41rc61 (2017-Dec-06 08:15):
Please explain the process of transformation. Say if I have eth2 as Master-port, and eth3..eth5 as Slaves, and used eth2 in firewall rule, will this rule be changes to one that will use newly-created bridge? Will IP be reassigned from master port to bridge create from these master and its slave ports?

Important questions, when it comes to upgrade! Even if we go with manual changing (tuning) of existing configuration so we'll be sure we can go with upgrade to 6.41, I'd really love to know the auto-convert algorithm.
 
User avatar
ErfanDL
Member Candidate
Member Candidate
Posts: 269
Joined: Thu Sep 29, 2016 9:13 am
Location: IRAN
Contact:

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

Wed Dec 06, 2017 4:17 pm

What are you doing MTK ?! release the stable version ! not spam version's
 
nkourtzis
Member Candidate
Member Candidate
Posts: 202
Joined: Tue Dec 11, 2012 12:56 am
Location: Greece

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

Wed Dec 06, 2017 4:19 pm

Dears at Mikrotik,

PLEASE PLEASE PLEASE revert the Routerboot numbering following the ROS version numbers, or at least make the ROS upgrade process to automatically upgrade Routerboot also. Performing two reboots per unit on each version upgrade in order to keep both up-to-date, without knowing whether there are any changes in the version or not, is not ideal.

I am sure many will second me on this point.
Passionate about networks
Enthusiastic about Mikrotik
MTCNA | MTCRE | MTCINE

No trees were killed to send this message,
but a large number of electrons were terribly inconvenienced.
 
User avatar
Cha0s
Forum Veteran
Forum Veteran
Posts: 882
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: 377
Joined: Thu May 07, 2015 11:46 am

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

Wed Dec 06, 2017 4:22 pm

without knowing whether there are any changes in the version or not, is not ideal.
Mostly there are no changes for all but really new devices or hardware. The only thing you might need this upgrade is when you add new hardware (like SFP module) or you can see you MT works unusually bad.

So to say, f/w upgrade is very rare thing so numbering after ROS releases is something... Strange, really!

Vote for revert to old f/w version numbering. Please!

You can also do really good thing by simple posting Changelogs for f/w with explanation who should care for (like "this f/w release used to support new 10G SFP module named ABC123, so don't care if you're not using it").
 
User avatar
kometchtech
Member Candidate
Member Candidate
Posts: 194
Joined: Sat Jun 15, 2013 4:25 am
Location: Japan
Contact:

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

Wed Dec 06, 2017 4:25 pm

*) capsman - use "adaptive-noise-immunity" value from CAP local configuration;
I'd like to know a bit more about this change.
Although "adaptive-noise-immunity" is read from CAP, it is correct by recognizing that setting value at that time will be read by setting with CAP Wireless beforehand and then activating Manager Is it?
--
Routerboard Users Group JP
http://www.rb-ug.jp/
CCR1009-8G-1S-1S+, RB750Gr3, CRS226-24G-2S+, RB850Gx2, RB960PGS, CRS317-1G-16S+,
RB2011UAS, CRS125-24G-1S, RB962UiGS-5HacT2HnT, CRS212-1G-10S-1S+, RB3011UiAS
 
User avatar
juliokato
Member Candidate
Member Candidate
Posts: 229
Joined: Mon Oct 26, 2015 4:27 pm
Location: Brazil

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

Wed Dec 06, 2017 4:54 pm

or at least make the ROS upgrade process to automatically upgrade Routerboot also.
+1
ok, but how is the process downgrade?
I apologize my grammatical errors, my english not so good, I am not a native speaker.
Wiki is maintained in English. I use Google translator. 8)
 
andriys
Forum Guru
Forum Guru
Posts: 1115
Joined: Thu Nov 24, 2011 1:59 pm
Location: Kharkiv, Ukraine

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

Wed Dec 06, 2017 5:23 pm

*) capsman - use "adaptive-noise-immunity" value from CAP local configuration;
I'd like to know a bit more about this change.
I believe this is similar to how antenna gain setting is being handled. Simply set the desired value of the adaptive-noise-immunity option in your radio interface configuration before turning CAP mode on, and that value will be used for this particular radio when you join it to your CAPs manager.
 
raffav
Member Candidate
Member Candidate
Posts: 278
Joined: Wed Oct 24, 2012 4:40 am

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

Wed Dec 06, 2017 5:29 pm

any one figure out how to set up this:
"firewall - added "tls-host" firewall matcher "
 
kmok1
newbie
Posts: 43
Joined: Wed Nov 28, 2012 6:49 pm
Location: Windsor ON Canada
Contact:

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

Wed Dec 06, 2017 5:50 pm

I have been testing the RC version on an RB750. If I goto / system routerboard, upgrade-firmware has been blank in the past several RC releases. Is this the new norm?
 
User avatar
kometchtech
Member Candidate
Member Candidate
Posts: 194
Joined: Sat Jun 15, 2013 4:25 am
Location: Japan
Contact:

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

Thu Dec 07, 2017 2:28 am

*) capsman - use "adaptive-noise-immunity" value from CAP local configuration;
I'd like to know a bit more about this change.
I believe this is similar to how antenna gain setting is being handled. Simply set the desired value of the adaptive-noise-immunity option in your radio interface configuration before turning CAP mode on, and that value will be used for this particular radio when you join it to your CAPs manager.

Thank you for the information.

Do you know what kind of method to confirm that this setting is valid?
If you are okay, can you tell me about the way?
--
Routerboard Users Group JP
http://www.rb-ug.jp/
CCR1009-8G-1S-1S+, RB750Gr3, CRS226-24G-2S+, RB850Gx2, RB960PGS, CRS317-1G-16S+,
RB2011UAS, CRS125-24G-1S, RB962UiGS-5HacT2HnT, CRS212-1G-10S-1S+, RB3011UiAS
 
Grickos
newbie
Posts: 32
Joined: Thu Aug 06, 2015 2:57 am

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

Thu Dec 07, 2017 6:42 pm

The DHCP server does not work properly.
DNS was set up
/ ip dhcp-server network
add address = 192.168.0.0 / 24 dns-server = 192.168.0.1 gateway = 192.168.0.1.
It behaves as if it was not assigned a DNS server. Assigns addresses that are entered in / ip dns.
 
freemannnn
Long time Member
Long time Member
Posts: 655
Joined: Sun Oct 13, 2013 7:29 pm

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

Thu Dec 07, 2017 6:49 pm

my dns server (ip-dns) where lost after upgrade to rc61
 
RafGan
newbie
Posts: 29
Joined: Mon Jun 06, 2011 6:17 pm
Location: Poland / Silesia

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

Thu Dec 07, 2017 7:31 pm

My static ports in all bridges just disappear after reboot on CAPsMAN controller router.
RB2011UAS-2HnD ROS 6.41rc61.

Also on SXT ac, clients are diconnected from time to time (every few minutes). In rc56 was perfect.

New bugs?
Best Regards,
Raf G
 
fanMikroTik
just joined
Posts: 7
Joined: Fri Sep 08, 2017 8:32 am

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

Fri Dec 08, 2017 11:37 am

MK,

please can You think about it just a few minutes? 6.41rc61 still the same...!

2 years old bug with TX Rate on all smartphones with android. TX Rate is always only 54Mbps but RX Rate is 72.2Mbps-20MHz/1S/SGI.

viewtopic.php?t=102908
Last edited by fanMikroTik on Sat Dec 09, 2017 8:49 pm, edited 1 time in total.
 
Son1c
just joined
Posts: 9
Joined: Fri Mar 24, 2017 6:29 pm

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

Fri Dec 08, 2017 12:00 pm

MK,

please do You think about it just a few minutes? 6.41rc61 still the same...!

2 years old bug with TX Rate on all smartphones with android. TX Rate is always only 54Mbps but RX Rate is 72.2Mbps-20MHz/1S/SGI.

viewtopic.php?t=102908
+1
 
linek1980
newbie
Posts: 34
Joined: Thu Feb 03, 2011 1:39 pm

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

Sat Dec 09, 2017 3:56 pm

MK,

please do You think about it just a few minutes? 6.41rc61 still the same...!

2 years old bug with TX Rate on all smartphones with android. TX Rate is always only 54Mbps but RX Rate is 72.2Mbps-20MHz/1S/SGI.

viewtopic.php?t=102908
+1 it must be repaired
 
User avatar
noyo
Member Candidate
Member Candidate
Posts: 113
Joined: Sat Jan 28, 2012 12:25 am
Location: Mazury - Poland
Contact:

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

Sat Dec 09, 2017 4:03 pm

MK,

please do You think about it just a few minutes? 6.41rc61 still the same...!

2 years old bug with TX Rate on all smartphones with android. TX Rate is always only 54Mbps but RX Rate is 72.2Mbps-20MHz/1S/SGI.

viewtopic.php?t=102908
+1
 
zajadacz
just joined
Posts: 18
Joined: Fri Jul 29, 2016 12:30 pm

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

Sat Dec 09, 2017 11:46 pm

MK,

please can You think about it just a few minutes? 6.41rc61 still the same...!

2 years old bug with TX Rate on all smartphones with android. TX Rate is always only 54Mbps but RX Rate is 72.2Mbps-20MHz/1S/SGI.

viewtopic.php?t=102908
+1
 
Ryan207
just joined
Posts: 2
Joined: Sun Dec 10, 2017 10:45 am

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

Sun Dec 10, 2017 11:10 am

As RafGan mentioned...the bridge ports disappear.

Upgraded to rc61 on my RB3011 and lost all local access, logged in remotely and saw all bridge ports were gone except for one undefined for ether3...which I deleted, readded all of them and works I think now but I noticed none of my connection marking is working anymore, I've yet to figure that part out.

I use connection marking then packet marking for my QoS setup, what changed in rc61 to break this or require a new config? Worked fine in rc56.

Who is online

Users browsing this forum: No registered users and 9 guests