Page 2 of 2

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

Posted: Tue Oct 24, 2017 5:46 pm
by c02
need user auth and custom apn for wap lte eu - please relase 6.41rc48 - thx !

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

Posted: Wed Oct 25, 2017 3:28 pm
by frakas
Hello,
Products: CRS326-24G-2S+RM
RouterOS: 6.41rc47

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

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

AC

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

Posted: Thu Oct 26, 2017 10:18 am
by chubbs596
Has anyone tested ROMON in 6.41rc47?
Seems that is not working.

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

Any ideas? Maybe Mikrotik can comment on this

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

Posted: Thu Oct 26, 2017 10:27 am
by chubbs596
Has anyone tested ROMON in 6.41rc47? Doesn't seem to work

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

Posted: Thu Oct 26, 2017 1:05 pm
by nescafe2002
RoMON works fine here (both router and endpoint on 6.41rc47).

Have you tried playing with new discovery settings? Not sure if these are related. RoMON works fine even with discovery-interface-list=none..
go to
/ip neighbor discovery-settings menu
and set discover-interface-list=all

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

Posted: Fri Oct 27, 2017 8:43 pm
by eworm
The support promised the next rc release will have a fix for my crash. That was one and a half week ago...
Will we have a release any time soon?

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

Posted: Sat Oct 28, 2017 9:15 am
by Jotne
The support promised the next rc release will have a fix for my crash. That was one and a half week ago...
Will we have a release any time soon?
It will be released when its ready.
RC is for test only. Not ment for production environment.

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

Posted: Sat Oct 28, 2017 7:02 pm
by skuykend
The support promised the next rc release will have a fix for my crash. That was one and a half week ago...
Will we have a release any time soon?
Hopefully a new RC early next week, but they pretty much shut down development during a MUM, which started Thursday.

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

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

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

I unplugged both power cords then powered it back up and has been running fine for the last 12 hours.

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

Posted: Sun Oct 29, 2017 7:17 pm
by skuykend
No ports/wlan working with default config for RB951G on rc47. Pretty sure was working on rc44 Will have to Netinstall.

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

Posted: Mon Oct 30, 2017 6:00 pm
by mhugo
Hardware offload for Vlans using the bridge ports on CRS212 does not seem to work?

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

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

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

/Mikael

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

Posted: Mon Oct 30, 2017 6:57 pm
by JimmyNyholm
Hardware offload for Vlans using the bridge ports on CRS212 does not seem to work?

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

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

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

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

/interface vlan is routeros os routing capable interface... connect to bridge interface to connect routeros to underlying switch infrastructure.

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

Posted: Wed Nov 01, 2017 1:26 am
by mhugo
Seems to be some chip issue when adding vlans in bridge on 212. Verified by Mikrotik trainer who will contact MT tomorrow.

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

Posted: Wed Nov 01, 2017 3:04 pm
by strods
What's new in 6.41rc50 (2017-Oct-30 10:13):

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


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

Changes since previous 6.41rc release:

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

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

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

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

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

Posted: Thu Nov 02, 2017 3:26 am
by doneware
What's new in 6.41rc50 (2017-Oct-30 10:13):
*) wireless - new driver with initial support for 160 and 80+80 MHz channel width;
stop right there. this stuff above literally translates to wave2, right?

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

Posted: Thu Nov 02, 2017 6:07 am
by brwainer
stop right there. this stuff above literally translates to wave2, right?
I thought 802.11ac Wave2 was MU-MIMO as well as 160MHz / 80+80MHz channels? And to date, I believe all the the wireless chipsets that Mikrotik has shipped in products are Wave1. But maybe this is a little accidental show-of-hand towards new products, which of course would need software support.

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

Posted: Thu Nov 02, 2017 8:03 am
by nz_monkey

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

:D

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

Posted: Thu Nov 02, 2017 12:50 pm
by Mackiavelly
What's new in 6.41rc50 (2017-Oct-30 10:13):

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

a very bad idea, this field generally needs to remove the limits, so that I myself can set the desired value, for example, even 15-20 seconds

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

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

We also have to use 5 seconds.

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

Posted: Thu Nov 02, 2017 5:46 pm
by mducharme
We currently have to use 6 seconds for RADIUS timeout in many cases - a limit of 3 seconds is not enough.

We have some sites on bidirectional satellite links with local PPPoE servers - in case a UDP accounting packet was missed and the RADIUS server thinks the customer trying to log in was already logged in (ex. sharing their credentials with a neighbor), it has to connect to the router to pull the list of PPPoE interfaces via SNMP to see if the customer is actually still logged in before sending a reply. Due to the satellite link, this process takes up to 6000 ms.

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

Posted: Thu Nov 02, 2017 6:14 pm
by juliokato
What's new in 6.41rc50 (2017-Oct-30 10:13):

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

just wanted to understand who thought the 3-second limit is enough.

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

Posted: Thu Nov 02, 2017 6:20 pm
by idlemind
What's new in 6.41rc50 (2017-Oct-30 10:13):
*) radius - limited RADIUS timeout maximum value to 3 seconds;
a very bad idea, this field generally needs to remove the limits, so that I myself can set the desired value, for example, even 15-20 seconds
Yup, seems like MT was overstepping. Seems like something that should be a default value adjustment that is still configurable.

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

Posted: Thu Nov 02, 2017 7:25 pm
by mhugo
Hi,

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

/Mikael

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

Posted: Thu Nov 02, 2017 9:38 pm
by cmekcik
Hi,

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

/Mikael
having the same issue on CRS317. i use classic RouterOS vlan trunking on crs317 because i can not pass VLANs to routers with current version of RouterOS
BTW anybody share you config for this situation (VLANs from current to RC). documentation about CRS317 is like "Warning: This article applies to CRS1xx and CRS2xx series switches and not to CRS3xx series switches."

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

Posted: Thu Nov 02, 2017 9:40 pm
by cmekcik
del

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

Posted: Fri Nov 03, 2017 7:33 am
by stackflow
When would the final version to be released?

Does the hardware off-load feature supports wireless bridging of HAP AC PRO?

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

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

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

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

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

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

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

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

Posted: Fri Nov 03, 2017 4:27 pm
by JimmyNyholm
What's new in 6.41rc50 (2017-Oct-30 10:13):
*) radius - limited RADIUS timeout maximum value to 3 seconds;
do not do this, our system on average 1~5 seconds to process the radius package
please leave this field customizable
+1 we are using OTP that validates a bit slow sometimes we want 10 seconds... Don't do this.

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

Posted: Fri Nov 03, 2017 10:26 pm
by upower3
They've done that already.
Done what? In released version? With no roll back? Hey, you must be kidding me! :)

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

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

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

I do appreciate MT for their passion to create better platform but big changes is something risky, so isolating BIG changes is kind of good idea, I think.

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

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

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

There is also a bugfix only channel (currently at 6.39.3) which may be more stable for production implementations, so they have given other options.

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

Posted: Fri Nov 03, 2017 10:52 pm
by idlemind
They've done that already.
Done what? In released version? With no roll back? Hey, you must be kidding me! :)

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

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

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

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

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

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

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

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

New bridge keeps IP addresses up

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

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

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

Please make an option to keep the bridge interface down until at least one port is active.

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

Posted: Sat Nov 04, 2017 1:08 am
by Cha0s
Has the routerboot firmware version naming changed in 6.41rc?

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

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

It would also be nice to keep the routerboot changelog up to date, or include the changes into ROS changelog itself (since you get the fw update via ROS anyway).
https://wiki.mikrotik.com/wiki/RouterBOOT_changelog

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

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

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

Posted: Sat Nov 04, 2017 2:48 pm
by Cha0s
I missed that entry in the changelog :oops:

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

Personally I've upgraded tons of routerboards' routerboot firmware over the years. I've never ever had a single issue with it nor I've ever read anyone else having a bootloop or any other problem with routerboot firmware.

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

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

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

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

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

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

Else some companies/users may ban the upgrade to newly version for their older infrastructure, just to be on the save side. This appears risky, to do that step without any rollback possibility (so you may lost you remote device).

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

Posted: Sun Nov 05, 2017 2:09 am
by eworm
For me the more important question about boot firmware is: Will the firmware version change with every RouterOS release even if no changes are made? Suppose you installed RouterOS 6.41, then upgraded firmware to 6.41. RouterOS 6.41.1 ships with no changes to the firmware. Is the available firmware version 6.41 or 6.41.1?

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

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

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

Posted: Mon Nov 06, 2017 8:50 pm
by anuser
What's new in 6.41rc50 (2017-Oct-30 10:13):
*) wireless - new driver with initial support for 160 and 80+80 MHz channel width;
So, is this an updated driver (kernel module) from the ASIC vendor (e.g. Atheros) which has also some bugfixes/features from the vendor?

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

Posted: Tue Nov 07, 2017 2:33 pm
by biatche
at the moment, is bridge+vlan still cli only?

is the new bridge implementation without issues now?

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

Posted: Tue Nov 07, 2017 2:38 pm
by upower3
is the new bridge implementation without issues now?
I'd say we'll when 1) it'll be released and 2) when we'll live with it at least several releases.
Just to be on the safe side.

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

Posted: Tue Nov 07, 2017 3:20 pm
by strods
What's new in 6.41rc52 (2017-Nov-07 08:48):

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


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

Changes since previous 6.41rc release:

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

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

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

Posted: Tue Nov 07, 2017 3:41 pm
by fposavec
*) wireless - added passive scan functionality (CLI only);

Any info on this?

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

Posted: Tue Nov 07, 2017 3:51 pm
by soulflyhigh
*) wireless - added passive scan functionality (CLI only);

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

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

Regards,
M.

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

Posted: Tue Nov 07, 2017 5:21 pm
by idlemind
What's new in 6.41rc50 (2017-Oct-30 10:13):

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


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

Changes since previous 6.41rc release:

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

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

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

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

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

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

Anyway, RADIUS timeout (even set to 3s) is too high and requires debugging and network improvements since router should not wait so long for a reply from RADIUS server.

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

Posted: Wed Nov 08, 2017 12:18 am
by eworm
For me the more important question about boot firmware is: Will the firmware version change with every RouterOS release even if no changes are made? Suppose you installed RouterOS 6.41, then upgraded firmware to 6.41. RouterOS 6.41.1 ships with no changes to the firmware. Is the available firmware version 6.41 or 6.41.1?
RouterOS 6.41rc52 ships with firmware version 6.41rc50... So looks like nothing changed except the version bump.

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

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

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

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

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

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

But after I upgraded the firmware I got this:
Current Firmware: 6.41rc52
Upgrade Firmware: 6.41rc50
http://prntscr.com/h7w38h

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

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

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

But after I upgraded the firmware I got this:
Current Firmware: 6.41rc52
Upgrade Firmware: 6.41rc50
http://prntscr.com/h7w38h
Oh, funny... I have a system that is running RouterOS 6.41rc52, with current and upgrade firmware at 6.41rc50. Started a firmware upgrade, after a reboot I can confirm your results.
Well, that will make my upgrade notification scripts go crazy... :-p

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

Posted: Fri Nov 10, 2017 11:34 am
by JimmyNyholm
When do we get LACP with Hardware offload in this new bridge implementation in routeros on switch devices such as CRS326-24G-2S+ and CRS-317-1G-16s+
Creating a bond and attaching it to the bride is done in software now and good know the cpu's in the switches is weak as hell.

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

Posted: Fri Nov 10, 2017 1:06 pm
by kamillo
To add to JimmyNyholm's comment: I'm still waiting for LACP hardware support (offload) in CRS125

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

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

But yes, this is definitely needed in urgency.

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

Posted: Sun Nov 12, 2017 3:38 pm
by ryba84
*) interface - added option to join and exclude "/interface list" from one and another;
How this works? Firewall is not using included list.

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

Posted: Mon Nov 13, 2017 10:37 am
by pe1chl
*) interface - added option to join and exclude "/interface list" from one and another;
How this works? Firewall is not using included list.
The default firewall is using lists now. When you have upgraded from versions previous to 6.40 all the time and never
reset the configuration, your firewall is still using the old method. However, when you reset everything to defaults you
will find it uses lists WAN and LAN to identify the interfaces.
It depends on the amount of work you have put in your config if it is worth the trouble, of course.

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

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

Wysłane z mojego SM-J710F przy użyciu Tapatalka

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

Posted: Mon Nov 13, 2017 6:53 pm
by mrz
@ryba84 report problem to support and attach supout rif file.

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

Posted: Tue Nov 14, 2017 12:09 pm
by rac
I tryed to configure VLANs using the bridge hw offloading feature (CRS326). Basically:

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

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

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

B) I cannot access the RouterOS using a VLAN port. But I didn't found, how to configure VLAN for the switch host port?

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

Posted: Tue Nov 14, 2017 7:47 pm
by biatche
I tryed to configure VLANs using the bridge hw offloading feature (CRS326). Basically:

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

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

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

B) I cannot access the RouterOS using a VLAN port. But I didn't found, how to configure VLAN for the switch host port?
you need to add your bridge interface to tagged ports.

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

Posted: Tue Nov 14, 2017 10:03 pm
by raffav
Hi
i am unable set a untagged management ip address using a RB450G and a CRS125
i had followed the wifi but i dont get it

any one can help

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

Posted: Wed Nov 15, 2017 12:05 am
by marekm
*) w60g - general work on PtMP implementation for 60 GHz connections;
Devices in the Wireless Wire kit come with Level 3 licenses - will it work with more than one client, or is it necessary to buy a Level 4 license to test 60GHz PtMP?

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

Posted: Wed Nov 15, 2017 1:03 am
by biatche
Been a long day.

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

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

Simply reverting to 6.40.5 gave me good stable expected rates.

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

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

Update: Contacted support and MT is already aware of the issue.

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

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

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

But after I upgraded the firmware I got this:
Current Firmware: 6.41rc52
Upgrade Firmware: 6.41rc50
http://prntscr.com/h7w38h
Same here, 951g2hnd
 routerboard: yes
             model: 951G-2HnD
     serial-number: 4F4********
     firmware-type: ar9344
  factory-firmware: 3.10
  current-firmware: 6.41rc52
  upgrade-firmware: 6.41rc50

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

Posted: Wed Nov 15, 2017 8:28 pm
by pe1chl
I have installed it on an old RB750 I use for some test.
It shows:
Firmware type: ar7240
Factory firmware: 3.02
Current firmware: 3.33
Update firmware:
I.e. there is nothing after upgrade firmware and the upgrade button does nothing (no log entry).

Edit: I installed 6.40.5, upgraded the firmware to 3.41 from there, then went back to 6.41 (2 partitions on the router...) and
the issue is still the same.

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

Posted: Thu Nov 16, 2017 11:34 am
by eworm
Oh, funny... I have a system that is running RouterOS 6.41rc52, with current and upgrade firmware at 6.41rc50. Started a firmware upgrade, after a reboot I can confirm your results.
Well, that will make my upgrade notification scripts go crazy... :-p
Possibly a read-only property "upgrade-available" is the easiest way to solve this?

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

Posted: Thu Nov 16, 2017 11:53 am
by kait
Hi, I raise a new topic Bridge HW-Offload and VLAN-Filtering with CRS226-24G-2S+RM at v6.41rc52 here viewtopic.php?f=1&t=127805 , maybe someone can explain issue.

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

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

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

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

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

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

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

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

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

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

Posted: Fri Nov 17, 2017 10:38 am
by pe1chl
I would say your network could be redesigned so that the RADIUS requests do not have to go over the satellite. Apparently you are using the MikroTik as a local access concentrator for several customers that then use the same satellite link. It would help a lot to have the RADIUS service local to that location. Of course usermanager is very limited, but a small computer with a RADIUS server and maybe some other services for the customer (a webproxy, a local webserver, VoIP PBX, etc) could help the customers living with this high-latency link.

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

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

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

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

Putting in a local RADIUS server is not a good solution, so if this is not reverted, we will need to stay at RouterOS 6.40.x and under permanently at 15 sites, never being able to upgrade. This makes me a bit nervous, but is preferable to the alternative of having to buy 15 RADIUS servers each of which will be put in remote areas in outdoor shelters with no environmental controls.

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

Posted: Fri Nov 17, 2017 12:03 pm
by Chupaka
One more solution: if it works good - do not upgrade :)

Worked for me when MikroTik broke VLANs over bonding :)

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

Posted: Fri Nov 17, 2017 12:35 pm
by biatche
I atest to mducharme's complaints. There's no harm reverting the RADIUS timeout value change is there? Could issue a warning of some sort for those who set values in excess of recommended.

Waiting for MT's good news now.

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

Posted: Fri Nov 17, 2017 9:48 pm
by mducharme
FYI, Cisco docs say the maximum RADIUS timeout on their gear is 1000 seconds. Juniper maximum is 90 seconds. Both seem a bit extreme, but that just shows how far from a 3 second maximum other vendors are.

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

Posted: Fri Nov 17, 2017 10:00 pm
by idlemind
These complaints are exactly why arbitrary hard setting a value is bad when it can be valid within a range. This includes what a developer personally feels is acceptable.

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

Posted: Sat Nov 18, 2017 4:58 am
by neg2led
I think we might be missing the forest for the trees here, guys.

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

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

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

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

MT: What's your explanation for why mducharme's configuration here works on 6.40 but not on 6.41?
mducharme: Have you opened a support ticket for this regression & provided supout.rifs etc? This isn't an official support channel, and it sounds like you should be talking to support if you aren't already.

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

Posted: Sat Nov 18, 2017 5:39 pm
by blajah
I have installed it on an old RB750 I use for some test.
It shows:
Firmware type: ar7240
Factory firmware: 3.02
Current firmware: 3.33
Update firmware:
I.e. there is nothing after upgrade firmware and the upgrade button does nothing (no log entry).

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

!) routerboot - RouterBOOT version numbering system merged with RouterOS;

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

Posted: Sat Nov 18, 2017 10:12 pm
by pe1chl
That is why I mention that there is an issue with the RB750 firmware - as this is the release candidate topic and developers are hopefully reading it before doing a release.

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

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

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

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

Posted: Sun Nov 19, 2017 11:24 am
by pe1chl
No I haven't, only because I would have to upgrade to 6.41 at one of those satellite sites (15 of our 45 sites are connected via satellite).
You have 15 sites of a problematic type for which it costs $1000 to make a support visit and you don't have a way to test a similar site from home (a subscription to the same satellite service)?
Really? It all does not seem very professional...

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

Posted: Sun Nov 19, 2017 9:05 pm
by mducharme
You have 15 sites of a problematic type for which it costs $1000 to make a support visit and you don't have a way to test a similar site from home (a subscription to the same satellite service)?
Really? It all does not seem very professional...
The dishes are 2.4 or 3.8 meters, so they are big (larger than a home satellite service). It is not easy like putting up an Xplornet dish on a home, these are very big and very heavy, they cannot be roof or wall mounted, unless maybe the roof was concrete and very thick, able to support the weight. So the dish would generally need to be on the ground with a concrete pad for stability and fencing to avoid people standing in front of the beam. Even if we had a place to install such a thing in our downtown urban office building, each dish has its own upload channel, so there would need to be one assigned to a "test dish" but all are in use since actual sites are priority. Therefore to operate a test dish with no channels we would need to shut down one of the 15 sites to free up a channel to bring up a test dish. It would be great to have a test system, it would make certain things easier, but it is just not feasible for all those reasons, so we have lived without it.
satellitepicture.PNG

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

Posted: Sun Nov 19, 2017 11:54 pm
by msatter
I see a lot of postings about the Radius timeout and maybe Mikrotik is willing to add an option to choose for extended timeout.

Normal 3 seconds and when the extended timeout option is ticked let's say 90 seconds.

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

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

https://wiki.linuxfoundation.org/networking/netem

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

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

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

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

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

A safer way would be to clear sessions if the interim-update interval is exceeded by, say, 4 times, but with an interim update interval of half an hour, customers could be down for up to two hours before the old session would clear.

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

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

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

This 'issue' is caused by a quite loaded Radius and Database server during this peak duration (NAS reboots => several thousand users to aithenticate immediatelly). A radius timout of max. 3 seconds only makes things worse here. The load on the radius increases!

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

Posted: Fri Nov 24, 2017 3:09 pm
by strods
What's new in 6.41rc56 (2017-Nov-24 10:03):

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


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

Changes since previous 6.41rc release:

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

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

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

Posted: Fri Nov 24, 2017 3:14 pm
by Chupaka
*) firewall - added "tls-host" firewall matcher (CLI only);
Sweet. No more Layer 7 for HTTPS blocking :)
How it works? Which packet matches? Does it support wildcards?

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

Posted: Fri Nov 24, 2017 3:24 pm
by pietroscherer
*) firewall - added "tls-host" firewall matcher (CLI only);
Sweet. No more Layer 7 for HTTPS blocking :)
How it works? Which packet matches? Does it support wildcards?
+1 :D

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

Posted: Fri Nov 24, 2017 4:23 pm
by pe1chl
*) firewall - added "tls-host" firewall matcher (CLI only);
Sweet. No more Layer 7 for HTTPS blocking :)
How it works? Which packet matches? Does it support wildcards?
I presume this is just a special case of a Layer 7 with some pre-defined pattern, and only works when SNI is used.

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

Posted: Fri Nov 24, 2017 4:27 pm
by Cha0s
*) firewall - added "tls-host" firewall matcher (CLI only);
Sweet. No more Layer 7 for HTTPS blocking :)
How it works? Which packet matches? Does it support wildcards?
I presume this is just a special case of a Layer 7 with some pre-defined pattern, and only works when SNI is used.
It could be an iptables module specific to that function instead of abstracting a L7 filter. Like this https://github.com/Lochnair/xt_tls

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

Posted: Fri Nov 24, 2017 4:46 pm
by honzam
*) wireless - added passive scan option for wireless scan mode;
Any info about this? passive scan has been implemented for a long time

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

Posted: Sat Nov 25, 2017 12:53 am
by troffasky
*) firewall - added "tls-host" firewall matcher (CLI only);
Sweet. No more Layer 7 for HTTPS blocking :)
How it works? Which packet matches? Does it support wildcards?
I presume this is just a special case of a Layer 7 with some pre-defined pattern, and only works when SNI is used.
No need for SNI, CN of certificate is in plaintext whether SNI is used or not.

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

Posted: Sat Nov 25, 2017 12:59 am
by bjornr
Upgrading a CRS326-24G-2S+ to 6.41rc56 broke DHCP relaying through it, the requests are passed through but the responses (OFFERs) are never seen by the client. Reverting to rc52 fixed this issue.

Don't know exactly what caused this, but if it helps identifying the issue I'm employing VLANs, bonding interfaces, and DHCP relaying. Configs or supout can be available upon request.

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

Posted: Sat Nov 25, 2017 3:28 am
by Paternot
*) wireless - added passive scan option for wireless scan mode;
Any info about this? passive scan has been implemented for a long time
It's not clear, from the changelog, but: If I remember it right, Mikrotik didn't support passive scan with 802.11ac, only b, g, n. Maybe this is it, at long last. :D

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

Posted: Sat Nov 25, 2017 11:47 am
by nz_monkey
*) firewall - added "tls-host" firewall matcher (CLI only);
Sweet. No more Layer 7 for HTTPS blocking :)
How it works? Which packet matches? Does it support wildcards?
At a guess, its based on xt_tls which can support wildcards, see https://github.com/Lochnair/xt_tls

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

Posted: Mon Nov 27, 2017 12:24 pm
by nkourtzis
*) wireless - added passive scan option for wireless scan mode;
Any info about this? passive scan has been implemented for a long time
It's not clear, from the changelog, but: If I remember it right, Mikrotik didn't support passive scan with 802.11ac, only b, g, n. Maybe this is it, at long last. :D
If this is it, then we only now have to wait for spectral scan and power adjustment in 802.11ac and we will be seeing sweet dreams.

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

Posted: Tue Nov 28, 2017 3:07 pm
by nkourtzis
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...

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

Posted: Tue Nov 28, 2017 3:28 pm
by pe1chl
nkourtzis wrote:
Can it possibly be that we approaching the end of v6 development? Just wondering...

I am wondering when they dare to release 6.41 as a "current" version with this risky "New bridge implementation" that will likely cause problems once it is widely deployed into many different field configurations (that combine VLAN tagging on switch and bridge now).
You may be right in that this could actually be released as part of "v7" so people are aware there are many changes and testing (rather than routine updating) is required.

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

Posted: Tue Nov 28, 2017 8:12 pm
by biatche
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..

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

Posted: Wed Nov 29, 2017 11:04 pm
by JimmyNyholm
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.

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

Posted: Thu Nov 30, 2017 12:51 am
by biatche
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.

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

Posted: Thu Nov 30, 2017 11:35 am
by nkourtzis
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.

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

Posted: Thu Nov 30, 2017 11:56 am
by upower3
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.

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

Posted: Fri Dec 01, 2017 10:58 am
by bajodel
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.

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

Posted: Fri Dec 01, 2017 11:11 am
by skuykend
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.

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

Posted: Fri Dec 01, 2017 11:37 am
by upower3
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.

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

Posted: Fri Dec 01, 2017 4:48 pm
by eriitguy
Hello!

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


Thank you!

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

Posted: Mon Dec 04, 2017 12:14 pm
by anuser
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.

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

Posted: Mon Dec 04, 2017 2:27 pm
by biatche
Dear mikrotik, why has development slowed down? In the past we used to see a new rc every 3-5 days.

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

Posted: Mon Dec 04, 2017 2:44 pm
by Paternot
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.

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

Posted: Mon Dec 04, 2017 2:54 pm
by raffav
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


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

Posted: Mon Dec 04, 2017 4:33 pm
by juliokato
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)

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

Posted: Mon Dec 04, 2017 4:56 pm
by jarda
V7 should have new kernel and totally new implementation of some functionalities. Do not skip so far...

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

Posted: Mon Dec 04, 2017 5:55 pm
by pe1chl
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.

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

Posted: Mon Dec 04, 2017 6:00 pm
by biatche
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...

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

Posted: Mon Dec 04, 2017 6:32 pm
by WojtusW5
Hi, small off-top when 6.41 will be as current version ?
Is there an initial deadline ?

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

Posted: Mon Dec 04, 2017 7:16 pm
by pe1chl
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.

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

Posted: Mon Dec 04, 2017 7:26 pm
by biatche
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.

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

Posted: Mon Dec 04, 2017 8:35 pm
by pe1chl
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...

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

Posted: Wed Dec 06, 2017 10:07 am
by abis
Dear mikrotik, why has development slowed down? In the past we used to see a new rc every 3-5 days.
Good point :?

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

Posted: Wed Dec 06, 2017 2:57 pm
by jondavy
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)

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

Posted: Wed Dec 06, 2017 3:07 pm
by upower3
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 :)

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

Posted: Wed Dec 06, 2017 3:10 pm
by BartoszP
+1 for upower3's idea of ROS 7.00.

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

Posted: Wed Dec 06, 2017 3:19 pm
by juliokato
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.

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

Posted: Wed Dec 06, 2017 3:28 pm
by upower3
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?

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

Posted: Wed Dec 06, 2017 3:32 pm
by strods
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.

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

Posted: Wed Dec 06, 2017 3:44 pm
by Cha0s
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).

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

Posted: Wed Dec 06, 2017 4:04 pm
by BartoszP
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" :-)

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

Posted: Wed Dec 06, 2017 4:14 pm
by upower3
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.

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

Posted: Wed Dec 06, 2017 4:17 pm
by ErfanDL
What are you doing MTK ?! release the stable version ! not spam version's

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

Posted: Wed Dec 06, 2017 4:19 pm
by nkourtzis
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.

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

Posted: Wed Dec 06, 2017 4:21 pm
by Cha0s
or at least make the ROS upgrade process to automatically upgrade Routerboot also.
+1

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

Posted: Wed Dec 06, 2017 4:22 pm
by upower3
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").

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

Posted: Wed Dec 06, 2017 4:25 pm
by kometchtech
*) 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?

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

Posted: Wed Dec 06, 2017 4:54 pm
by juliokato
or at least make the ROS upgrade process to automatically upgrade Routerboot also.
+1
ok, but how is the process downgrade?

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

Posted: Wed Dec 06, 2017 5:23 pm
by andriys
*) 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.

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

Posted: Wed Dec 06, 2017 5:29 pm
by raffav
any one figure out how to set up this:
"firewall - added "tls-host" firewall matcher "

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

Posted: Wed Dec 06, 2017 5:50 pm
by kmok1
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?

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

Posted: Thu Dec 07, 2017 2:28 am
by kometchtech
*) 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?

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

Posted: Thu Dec 07, 2017 6:42 pm
by Grickos
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.

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

Posted: Thu Dec 07, 2017 6:49 pm
by freemannnn
my dns server (ip-dns) where lost after upgrade to rc61

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

Posted: Thu Dec 07, 2017 7:31 pm
by RafGan
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?

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

Posted: Fri Dec 08, 2017 11:37 am
by fanMikroTik
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

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

Posted: Fri Dec 08, 2017 12:00 pm
by Son1c
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

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

Posted: Sat Dec 09, 2017 3:56 pm
by linek1980
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

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

Posted: Sat Dec 09, 2017 4:03 pm
by noyo
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

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

Posted: Sat Dec 09, 2017 11:46 pm
by zajadacz
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

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

Posted: Sun Dec 10, 2017 11:10 am
by Ryan207
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.

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

Posted: Sun Dec 10, 2017 3:51 pm
by Ryan207
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?

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

Posted: Mon Dec 11, 2017 9:00 am
by uldis
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

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

Posted: Mon Dec 11, 2017 1:29 pm
by alexvdbaan
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

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

Posted: Mon Dec 11, 2017 1:42 pm
by bjornr
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.

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

Posted: Mon Dec 11, 2017 2:35 pm
by alexvdbaan
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

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

Posted: Mon Dec 11, 2017 2:52 pm
by bjornr
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)

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

Posted: Tue Dec 12, 2017 12:57 am
by RafGan
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.

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

Posted: Tue Dec 12, 2017 11:54 am
by alexvdbaan
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

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

Posted: Tue Dec 12, 2017 12:00 pm
by bjornr
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.

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

Posted: Tue Dec 12, 2017 4:46 pm
by idlemind
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.

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

Posted: Tue Dec 12, 2017 8:51 pm
by KBV
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.

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

Posted: Wed Dec 13, 2017 10:16 am
by KBV
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.

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

Posted: Wed Dec 13, 2017 10:38 am
by anuser
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"

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

Posted: Wed Dec 13, 2017 12:10 pm
by pe1chl
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.

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

Posted: Wed Dec 13, 2017 5:34 pm
by lemointernet
Any final version release date ?

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

Posted: Wed Dec 13, 2017 5:36 pm
by planetcoop
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

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

Posted: Wed Dec 13, 2017 6:21 pm
by Samot
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.

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

Posted: Wed Dec 13, 2017 10:12 pm
by RafGan
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

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

Posted: Thu Dec 14, 2017 2:28 am
by alexjhart
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?

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

Posted: Thu Dec 14, 2017 2:32 am
by planetcoop
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....

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

Posted: Thu Dec 14, 2017 5:17 pm
by kait
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

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

Posted: Thu Dec 14, 2017 8:31 pm
by idlemind
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.

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

Posted: Thu Dec 14, 2017 8:42 pm
by kait
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

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

Posted: Fri Dec 15, 2017 11:18 am
by kait
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?

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

Posted: Fri Dec 15, 2017 1:55 pm
by strods
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.

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

Posted: Fri Dec 15, 2017 2:03 pm
by Chupaka
*) dhcp-server - added basic RADIUS accounting;
Wow!.. What does it account?

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

Posted: Fri Dec 15, 2017 4:06 pm
by msatter
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.

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

Posted: Fri Dec 15, 2017 5:17 pm
by Grickos
DHCP server, DNS setings still does not work.

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

Posted: Fri Dec 15, 2017 5:50 pm
by ErfanDL
*) wireless - added support for CHARGEABLE_USER_ID in EAP Accounting;
What does this feature do?

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

Posted: Fri Dec 15, 2017 6:21 pm
by andriys
*) wireless - added support for CHARGEABLE_USER_ID in EAP Accounting;
What does this feature do?
Implements rfc4372, I guess.

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

Posted: Fri Dec 15, 2017 10:07 pm
by Neovr
*) route - improved reliability on routing table update;
more info?

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

Posted: Sun Dec 17, 2017 12:07 am
by hapi
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.

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

Posted: Sun Dec 17, 2017 1:41 am
by RafGan
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.

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

Posted: Sun Dec 17, 2017 3:31 am
by Zloy2452
I have to stick with rc56 until DNS issue got fixed. Please, Mikrotik, we need a fix as soon as it possible!

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

Posted: Mon Dec 18, 2017 8:29 am
by strods
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.

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

Posted: Mon Dec 18, 2017 10:57 am
by RafGan
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.

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

Posted: Mon Dec 18, 2017 11:05 am
by onnoossendrijver
*) ipsec - improved hardware accelerated IPSec performance on 750Gr3;
Can you tell me more about this?

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

Posted: Mon Dec 18, 2017 11:13 am
by JimmyNyholm
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...

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

Posted: Mon Dec 18, 2017 6:33 pm
by Grickos
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

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

Posted: Mon Dec 18, 2017 8:03 pm
by msatter
*) 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.

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

Posted: Mon Dec 18, 2017 8:19 pm
by RafGan
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.

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

Posted: Mon Dec 18, 2017 8:44 pm
by Zloy2452
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.

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

Posted: Mon Dec 18, 2017 9:38 pm
by ZeroByte
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:

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

Posted: Mon Dec 18, 2017 11:06 pm
by RafGan
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.

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

Posted: Tue Dec 19, 2017 10:00 am
by strods
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.

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

Posted: Tue Dec 19, 2017 11:18 am
by emils
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.

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

Posted: Tue Dec 19, 2017 11:47 am
by msatter
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.

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

Posted: Tue Dec 19, 2017 2:30 pm
by eworm
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?

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

Posted: Tue Dec 19, 2017 2:37 pm
by kometchtech
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.

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

Posted: Tue Dec 19, 2017 3:05 pm
by eworm
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.

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

Posted: Tue Dec 19, 2017 4:19 pm
by pe1chl
From what earlier version did you upgrade? 6.41RC too or before?
It looks like it is time for netinstall and restore backup.

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

Posted: Tue Dec 19, 2017 5:13 pm
by eworm
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.

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

Posted: Tue Dec 19, 2017 5:26 pm
by pe1chl
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.

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

Posted: Tue Dec 19, 2017 9:14 pm
by msatter
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:

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

Posted: Thu Dec 21, 2017 5:40 pm
by ZeroByte
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

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

Posted: Thu Dec 21, 2017 8:11 pm
by JimmyNyholm
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?

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

Posted: Thu Dec 21, 2017 9:01 pm
by eworm
Looks like demo Routerboards find final version 6.41... Is the release being prepare right now?

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

Posted: Thu Dec 21, 2017 9:12 pm
by freemannnn
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

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

Posted: Thu Dec 21, 2017 11:00 pm
by honzam
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
:-)

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

Posted: Fri Dec 22, 2017 1:16 am
by skuykend
Looks like demo Routerboards find final version 6.41... Is the release being prepare right now?
And no mention of the bridge update!

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

Posted: Fri Dec 22, 2017 4:30 am
by mducharme
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.

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

Posted: Fri Dec 22, 2017 3:00 pm
by strods
Version 6.41 has been released:
viewtopic.php?f=21&t=128915