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

pe1chl · Wed Oct 11, 2017 10:27 pm

!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet

I enabled the detection for "all" interfaces on a CHR test system that has 2 ethernet interfaces that both have internet connectivity,
but their status remains at "wan" and does not go to "internet".
There are two default routes, one in the main table and one in an extra table which is selected by an IP route rule on the
source address of the second interface. Pinging 8.8.8.8 and cloud.mikrotik.com works fine.
I would have expected at least one of them to show "internet", maybe not both when this policy routing is not recognized yet.

boyko · Thu Oct 12, 2017 12:20 am

I just updated to the latest RC and the bridge conversion did not take in account the spoofed MAC address on the WAN port. I had to manually adjust that on the newly created bridge. This needs to be handled before the final release or people are going to have issues with it.

ShturmN · Thu Oct 12, 2017 3:00 am

I'm update to 6.41rc44 my sxt 5 and now:
https://s.mail.ru/6XPP/7BwY2UJm3

pe1chl · Thu Oct 12, 2017 10:16 am

!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
I enabled the detection for "all" interfaces on a CHR test system that has 2 ethernet interfaces

Another issue: although the interfaces have been setup with static addresses, after enabling this feature
the router is sending DHCP requests at a rate of 1 per second.

Chupaka · Thu Oct 12, 2017 11:06 am

Opposite, inject a route to 8.8.8.8 into a dynamic protocol running on someones environment that relies on this feature. It'll toggle the interface to WAN, apply security policies, likely dropping all traffic until detect-interface flaps back to LAN. Then it flaps to WAN when it relearns the route and flap and flap and flap.

so, some peering partner injects a route to block himself? it's either bad or dumb peering partner

whitbread · Thu Oct 12, 2017 2:52 pm

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

R3 is configured as station bridge with VLAN's 3 and 1002. Both VLAN's are terminated with IP-Adresses at R3.

/interface vlan
add interface="WLAN1" name="WLAN1 VLAN1002" vlan-id=1002
add interface="WLAN1" name="WLAN1 VLAN3" vlan-id=3
/ip address
add address=192.168.88.3/24 interface="WLAN1 VLAN1002" network=192.168.88.0
add address=192.168.3.3/24 interface="WLAN1 VLAN3" network=192.168.3.0

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

R1 is configured the same way using VLAN-interfaces.

/interface vlan
add interface="P05  Trunk R2" name="P05 R2 VLAN3" vlan-id=3
add interface="P05  Trunk R2" name="P05 R2 VLAN1002" vlan-id=1002
add interface="P05  Trunk R2" name="P05 R2 VLAN1013" vlan-id=1013
/ip address
add address=192.168.88.1/24 interface="P05 R2 VLAN1002" network=192.168.88.0
add address=192.168.89.1/24 interface="P05 R2 VLAN1013" network=192.168.89.0
add address=192.168.3.1/24 interface="P05 R2 VLAN3" network=192.168.3.0

I can connect R3 from R1 on both VLAN's. Connection to R2 works only on VLAN1013 as this interface is not part of the bridge. VLAN1002 has no IP on R2.

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

But how do I reach R2 itself on VLAN3 ?

<1> If I use VLAN interfaces on Trunk port and bridge VLAN inferface I can not connect.

/interface vlan
add interface="P2  Trunk R1" name="P2 R1 VLAN1002" vlan-id=1002
add interface="P2  Trunk R1" name="P2 R1 VLAN1013" vlan-id=1013
add interface="P2  Trunk R1" name="P2 R1 VLAN3" vlan-id=3
/interface bridge
add fast-forward=no igmp-snooping=no name="Bridge one4all" protocol-mode=none vlan-filtering=yes
/interface bridge port
add bridge="Bridge one4all" ingress-filtering=yes interface="P3" pvid=3
add bridge="Bridge one4all" interface="WLAN2 AP" pvid=3
add bridge="Bridge one4all" frame-types=admit-only-vlan-tagged interface="WLAN3  Bridge"
add bridge="Bridge one4all" interface="P2 R1 VLAN1002" pvid=1002
add bridge="Bridge one4all" interface="P2 R1 VLAN3" pvid=3
/interface bridge vlan
add bridge="Bridge one4all" tagged="WLAN3  Bridge" vlan-ids=3
add bridge="Bridge one4all" tagged="WLAN3  Bridge" vlan-ids=1002
/ip address
add address=192.168.89.2/24 interface="P2 R1 VLAN1013" network=192.168.89.0
add address=192.168.3.2/24 interface="P2 R1 VLAN3" network=192.168.3.0

<2> I tried it without VLAN inferfaces but I don't see any possibility to reach R2 then.

/interface vlan
add interface="P2  Trunk R1" name="P2 R1 VLAN1013" vlan-id=1013
/interface bridge
add fast-forward=no igmp-snooping=no name="Bridge one4all" protocol-mode=none vlan-filtering=yes
/interface bridge port
add bridge="Bridge one4all" frame-types=admit-only-vlan-tagged ingress-filtering=yes interface="P2  Trunk R1"
add bridge="Bridge one4all" ingress-filtering=yes interface="P3" pvid=3
add bridge="Bridge one4all" interface="WLAN2 AP" pvid=3
add bridge="Bridge one4all" frame-types=admit-only-vlan-tagged interface="WLAN3  Bridge"
/interface bridge vlan
add bridge="Bridge one4all" tagged="WLAN3  Bridge,P2  Trunk R1" vlan-ids=3
add bridge="Bridge one4all" tagged="WLAN3  Bridge,P2  Trunk R1" vlan-ids=1002

Either way I can connect to R3 on both VLAN's and to a Client physically connected to R2 (VLAN3).
R2 is reachable on VLAN1013, but this interface is not part of the bridge.

How can I reach R2 via VLAN3?!?

Any help is highly appreciated.

idlemind · Fri Oct 13, 2017 1:32 am

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

R3 is configured as station bridge with VLAN's 3 and 1002. Both VLAN's are terminated with IP-Adresses at R3.
Code: Select all
/interface vlan
add interface="WLAN1" name="WLAN1 VLAN1002" vlan-id=1002
add interface="WLAN1" name="WLAN1 VLAN3" vlan-id=3
/ip address
add address=192.168.88.3/24 interface="WLAN1 VLAN1002" network=192.168.88.0
add address=192.168.3.3/24 interface="WLAN1 VLAN3" network=192.168.3.0
I can connect to both VLAN's from R1 but not from R2.

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

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

But how do I reach R2 itself on VLAN3 ?

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

How can I reach R2 via VLAN3?!?

Any help is highly appreciated.

Long story short, read the bridge wiki page.

You need to tag the VLANs on the bridge itself in /int bridge vlan and the VLAN interfaces need to have the interface property set to the bridge in question not some random Ethernet interface.

whitbread · Fri Oct 13, 2017 11:06 am

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

But I am still curious if I choose the correct way to work with untagged i.e. PVID1-traffic. Both trunk ports have PVID1. The whole configuration works only if I set both trunk ports as tagged in bridge vlan setting for PVID1.
As soon as I set both trunk ports as untagged in bridge vlan settings for PVID1 no connection is possible. This situation persists until I do a reboot or disable and enable the whole bridge. Is this meant to be like this?

Gennadiy51 · Fri Oct 13, 2017 11:18 am

!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
I enabled the detection for "all" interfaces on a CHR test system that has 2 ethernet interfaces
Another issue: although the interfaces have been setup with static addresses, after enabling this feature
the router is sending DHCP requests at a rate of 1 per second.

I'm blocking the provider port, because of the high number of requests on the WAN port. The provider is very unhappy with this!
What should I do?

blimbach · Fri Oct 13, 2017 12:34 pm

This Version is really bad on my hapac capsman:

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

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

How to downgrade to an older rc? I cannot find a download-link.

kamillo · Fri Oct 13, 2017 1:13 pm

How to downgrade to an older rc? I cannot find a download-link.

Go to https://mikrotik.com/download

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

https://download2.mikrotik.com/routeros/6.41rc38/routeros-mipsbe-6.41rc38.npk

blimbach · Fri Oct 13, 2017 1:39 pm

Thank you, downgrading fixed the Problem to me.

jrpaz · Fri Oct 13, 2017 3:43 pm

Same issue with the RB750gr3 had to downgrade back #sad

emils · Fri Oct 13, 2017 4:06 pm

If you experience critical program crashes or kernel panics on latest release candidate versions, please send supout.rif (autosupout.rif) files to support@mikrotik.com before downgrading.

pe1chl · Fri Oct 13, 2017 5:36 pm

Another issue: although the interfaces have been setup with static addresses, after enabling this feature
the router is sending DHCP requests at a rate of 1 per second.
I'm blocking the provider port, because of the high number of requests on the WAN port. The provider is very unhappy with this!
What should I do?

I would advise keeping the detect-internet feature disabled until this problem is fixed.
For now it is only safe when your internet port obtains its address using DHCP. When the detect-internet sees
a DHCP reply it then remains quiet (probably for half the leasetime at least). But when there is no DHCP reply
it goes haywire.

whitbread · Fri Oct 13, 2017 6:36 pm

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

What I do like actually is that it gives information about the ports open via MAC.

Mon Oct 16, 2017 9:03 am

Version 6.41rc release includes fixes in WPA2 protocol:
viewtopic.php?f=21&t=126695

alkar · Mon Oct 16, 2017 1:27 pm

Hi,
when v6.41rc will be as "current" ?
We bought 2 x CRS317-1G-16S+RM and couldn't set up harware vlan via winbox.
It is difficult to manage hundreds of vlans in a text teminal.

Mon Oct 16, 2017 3:02 pm

when v6.41rc will be as "current" ?
We bought 2 x CRS317-1G-16S+RM and couldn't set up harware vlan via winbox.

Based on experience with some previous RouterOS versions, I'd say that hitting the Current update channel and receiving WinBox support for some options are two unrelated things. It's possible that 6.41 becomes current with these options still being CLI-only.

I'm wondering though, what stops you from staying on 6.40.x or 6.39.x and configuring what you need in a "traditional" way?

Kubuxu · Mon Oct 16, 2017 3:18 pm

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

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

Bridge setup:

/interface add bridge auto-mac=no comment="main bridge" igmp-snooping=no name=bridge vlan-filtering=yes
/interface vlan
add interface=bridge name=bridge-vlan100 vlan-id=100
add interface=bridge name=bridge-vlan200 vlan-id=200
/interface bridge port
add bridge=bridge interface=eth2-PC
add bridge=bridge interface=eth3-notebook pvid=100
/interface bridge vlan
add bridge=bridge tagged=bridge,eth2-PC untagged=eth3-notebook vlan-ids=100
add bridge=bridge tagged=eth2-PC,bridge vlan-ids=200

This works but traffic from eth2-PC to eth3-notebook always goes through CPU bridge (hardware offload is disabled as for the vlan-filtering=yes which is not supported on switch chip in 3011.
This is true, switch chip in 3011 can't add VLAN tags to packets but it can use 'Default VLAN ID' for access ports.

/interface ethernet switch
port set eth2-PC vlan-mode=check
port set eth3-notebook vlan-mode=check vlan-header=always-strip default-vlan-id=100
vlan add switch=switch1 ports=eth2-PC,eth3-notebook,switch1-cpu vlan-id=100
vlan add switch=switch1 ports=eth2-PC,switch1-cpu vlan-id=200

If I add this part of the setup I get 3 DUPs on pings between eth2-PC <-> eth3-notebook (VLAN100<->VLAN100) and it is generally unstable. This is because the RouterOS disabled hardware offloading and the host table of hardware switch is empty (and stays that way) and then it works as a hub (that is only explanation I have), thus pushing the packets through all connected interfaces.

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

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

I really hope this can be resolved, this significantly cuts down on capabilities of 3011 which might as well have no VLAN aware switch chip/swich host table at this point.

idlemind · Mon Oct 16, 2017 4:22 pm

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

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

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

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

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

I really hope this can be resolved, this significantly cuts down on capabilities of 3011 which might as well have no VLAN aware switch chip/swich host table at this point.

Per a case I opened with MikroTik support, expect existing hardware features to slowly be turned on in the new environment. That said, any inter-VLAN traffic, traffic from VLAN100 to VLAN200 from a routing perspective will always be done across the CPU. I believe the reference platform they are using for development is the CRS3xx products. I'd expect to see other platforms covered over time. I run a 750Gr3 (hex) to perform inter-VLAN routing and it gets 300mbps+ throughput and has worked fine in my LAN considering everything else is constrained by a much slower Internet connection. Your mileage may very with other platforms and their CPU.

Kubuxu · Mon Oct 16, 2017 5:23 pm

That said, any inter-VLAN traffic, traffic from VLAN100 to VLAN200 from a routing perspective will always be done across the CPU.

I know that, but this is VLAN100<->VLAN100 which should be possible to be done in the switch.

expect existing hardware features to slowly be turned on in the new environment

Let's hope in future it will allow to use 3011 switch capabilities with any VLAN.

alkar · Tue Oct 17, 2017 4:04 pm

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

I'm wondering though, what stops you from staying on 6.40.x or 6.39.x and configuring what you need in a "traditional" way?

A "traditional" way in CRS317 not working. Switch menu shown all ports as Unknown.
viewtopic.php?f=17&t=125758

idlemind · Tue Oct 17, 2017 5:00 pm

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

But I am still curious if I choose the correct way to work with untagged i.e. PVID1-traffic. Both trunk ports have PVID1. The whole configuration works only if I set both trunk ports as tagged in bridge vlan setting for PVID1.
As soon as I set both trunk ports as untagged in bridge vlan settings for PVID1 no connection is possible. This situation persists until I do a reboot or disable and enable the whole bridge. Is this meant to be like this?

I'd have to see your configuration to be certain but it shouldn't be a problem as long as VLAN1 is only untagged or tagged not both on the port. Additionally, VLAN1 either needs to be untagged (default) or tagged for the bridge interface as well.

Thu Oct 19, 2017 12:42 pm

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

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

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

Changes since previous 6.41rc release:

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

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

planetcoop · Thu Oct 19, 2017 5:41 pm

"/ip neighbors" seems to not work on 6.41rc47 on tile...

mrz · Thu Oct 19, 2017 5:49 pm

go to
/ip neighbor discovery-settings menu
and set discover-interface-list=all

raffav · Thu Oct 19, 2017 5:54 pm

go to
/ip neighbor discovery-settings menu
and set discover-interface-list=all

this function is not available on winbox yet correct ?

mrz · Thu Oct 19, 2017 5:58 pm

yes, currently only terminal. Default value is "!dynamic", but you can set it to "all".

raffav · Thu Oct 19, 2017 6:00 pm

thanks

pe1chl · Thu Oct 19, 2017 7:22 pm

*) discovery - use "/interface list" instead of interface name under neighbour discovery settings;

Discovery packets are now sent with source 0.0.0.0 instead of interface address as before. Maybe due to this change?
This causes firewall issues, we drop "bogon" packets (packets from an address list with certain reserved addresses including 0.0.0.0)
before the rule that accepts discovery packets.

raffav · Thu Oct 19, 2017 9:45 pm

Mikrotik team

is it difficult to create some type of address-list or something similar to use on ipsec polices in future release ?

alexsolovyev · Thu Oct 19, 2017 10:49 pm

Applying the default configuration seems to be broken in 6.41rc47. I'm getting an empty config after clicking on the "OK" button after resetting the configuration. It's working in 6.40.4

chubbs596 · Fri Oct 20, 2017 2:26 am

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

Also, can someone explain how QinQ vlans would be programmed in the new Bridge vlan implementation?

idlemind · Fri Oct 20, 2017 3:18 am

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

Also, can someone explain how QinQ vlans would be programmed in the new Bridge vlan implementation?

Put a bridge in your bridge?

roswitina · Fri Oct 20, 2017 9:43 am

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

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

I go back to the current firmware 6.40.4.

rosi

Fri Oct 20, 2017 10:09 am

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

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

I go back to the current firmware 6.40.4.

rosi

Please make a support output file after the crash and send it to support@mikrotik.com

bajodel · Fri Oct 20, 2017 11:24 am

Has anyone tested ROMON in 6.41rc47?
Seems that is not working.
Also, can someone explain how QinQ vlans would be programmed in the new Bridge vlan implementation?
Put a bridge in your bridge?

and if I need a single service tag on packets ?
I've never played with new bridge but I suppose there is a place where I can set the tag type..

roswitina · Fri Oct 20, 2017 1:09 pm

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

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

I go back to the current firmware 6.40.4.

rosi
Please make a support output file after the crash and send it to support@mikrotik.com

I'm doing it. I install v6.41RC47 and wait for the next crash.
Rosi

linek1980 · Fri Oct 20, 2017 1:30 pm

oct/19 15:40:31 system,info router rebooted
oct/19 15:40:31 system,error,critical router rebooted because some critical program crashed
oct/19 15:40:39 bridge,info hardware offloading activated on bridge "bridge" ports: ether2
oct/19 15:40:39 bridge,info hardware offloading activated on bridge "bridge" ports: ether3
oct/19 15:40:39 bridge,info hardware offloading activated on bridge "bridge" ports: ether4
oct/19 15:40:39 bridge,info hardware offloading activated on bridge "bridge" ports: ether5
oct/19 15:40:41 interface,info ether1 link up (speed 100M, full duplex)

Chupaka · Fri Oct 20, 2017 2:11 pm

Please make a support output file after the crash and send it to support@mikrotik.com

Fri Oct 20, 2017 3:09 pm

In RouterOS v6.41 everything QinQ related has to configured with bridge "vlan-filtering=no" using VLAN interfaces and their "use-service-tag" option.

JimmyNyholm · Fri Oct 20, 2017 6:19 pm

In RouterOS v6.41 everything QinQ related has to configured with bridge "vlan-filtering=no" using VLAN interfaces and their "use-service-tag" option.

And if one do that all qinq switching will get software switched or what?

idlemind · Fri Oct 20, 2017 7:00 pm

In RouterOS v6.41 everything QinQ related has to configured with bridge "vlan-filtering=no" using VLAN interfaces and their "use-service-tag" option.
And if one do that all qinq switching will get software switched or what?

Wouldn't it have been in software before? Are their models that supported QinQ in hardware under the switch chip menu?

whitbread · Sat Oct 21, 2017 8:15 am

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

Is this a software limitation of the current RC development and will be implemented in the near future?

guipoletto · Sun Oct 22, 2017 1:46 am

I would like to know if this new bridge implementation affects something on hardware that does not have an integrated switch-chip (Rb333, CCR, rb1200{ports5-10}, etc).
Are any performance gains to be expected?

hapi · Sun Oct 22, 2017 2:00 pm

*) wireless - log "signal-strength" when successfully connected to AP;

Can you add a signal to the log and to the client when it was disconnected?

biatche · Mon Oct 23, 2017 9:37 am

*) wireless - log "signal-strength" when successfully connected to AP;
Can you add a signal to the log and to the client when it was disconnected?

Do that for capsman too.

darencrew · Mon Oct 23, 2017 8:24 pm

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

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

In my opinion, the new "/ip neighbor discovery-settings set discover-interface-list" is not totally useless but is too generic, so it should better be a new feature (or more exactly a macro) and not a replacement feature.

darzupan · Tue Oct 24, 2017 9:11 am

Hi

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

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

Another problem

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

What could be a problem?

Best regards

c02 · Tue Oct 24, 2017 5:46 pm

need user auth and custom apn for wap lte eu - please relase 6.41rc48 - thx !

frakas · Wed Oct 25, 2017 3:28 pm

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

This is my configuration: ether1 is untagged vlan 40 and ether24 is Trunk (all vlan is tagged)

/interface bridge
add fast-forward=no igmp-snooping=no name=bridge-vlans vlan-filtering=yes
/interface vlan
add interface=bridge-vlans name=vlan40 vlan-id=40
add interface=bridge-vlans name=vlan41 vlan-id=41
add interface=bridge-vlans name=vlan42 vlan-id=42
/interface bridge port
add bridge=bridge-vlans interface=ether1 pvid=40
add bridge=bridge-vlans interface=ether24-Trunk 
/interface bridge vlan
add bridge=bridge-vlans tagged="bridge-vlans,ether24-Trunk"  vlan-ids=40
add bridge=bridge-vlans tagged="bridge-vlans,ether24-Trunk" vlan-ids=41
add bridge=bridge-vlans tagged="bridge-vlans,ether24-Trunk" vlan-ids=42
/ip address
add address=192.168.40.254/24 interface=vlan40 network=192.168.40.0
add address=192.168.41.254/24 interface=vlan41 network=192.168.41.0
add address=192.168.42.254/24 interface=vlan42 network=192.168.42.0
set name=R1

Ether24 connects to another CRS326 with the same configuration. The only difference is the only ip on vlan40 (192.168.40.253).

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

AC

chubbs596 · Thu Oct 26, 2017 10:18 am

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

Also, can someone explain how QinQ vlans would be programmed in the new Bridge vlan implementation?
Put a bridge in your bridge?

Yea sure that will work but cant see that that is the correct way to do this as you loose the hardware offload on this type off config.

Any ideas? Maybe Mikrotik can comment on this

chubbs596 · Thu Oct 26, 2017 10:27 am

Has anyone tested ROMON in 6.41rc47? Doesn't seem to work

nescafe2002 · Thu Oct 26, 2017 1:05 pm

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

Have you tried playing with new discovery settings? Not sure if these are related. RoMON works fine even with discovery-interface-list=none..

go to
/ip neighbor discovery-settings menu
and set discover-interface-list=all

eworm · Fri Oct 27, 2017 8:43 pm

The support promised the next rc release will have a fix for my crash. That was one and a half week ago...
Will we have a release any time soon?

Jotne · Sat Oct 28, 2017 9:15 am

The support promised the next rc release will have a fix for my crash. That was one and a half week ago...
Will we have a release any time soon?

It will be released when its ready.
RC is for test only. Not ment for production environment.

skuykend · Sat Oct 28, 2017 7:02 pm

The support promised the next rc release will have a fix for my crash. That was one and a half week ago...
Will we have a release any time soon?

Hopefully a new RC early next week, but they pretty much shut down development during a MUM, which started Thursday.

skuykend · Sat Oct 28, 2017 7:14 pm

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

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

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

skuykend · Sun Oct 29, 2017 7:17 pm

No ports/wlan working with default config for RB951G on rc47. Pretty sure was working on rc44 Will have to Netinstall.

mhugo · Mon Oct 30, 2017 6:00 pm

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

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

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

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

/Mikael

JimmyNyholm · Mon Oct 30, 2017 6:57 pm

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

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

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

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

/Mikael

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

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

mhugo · Wed Nov 01, 2017 1:26 am

Seems to be some chip issue when adding vlans in bridge on 212. Verified by Mikrotik trainer who will contact MT tomorrow.

Wed Nov 01, 2017 3:04 pm

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

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

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

Changes since previous 6.41rc release:

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

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

jondavy · Wed Nov 01, 2017 7:40 pm

What's new in 6.41rc50 (2017-Oct-30 10:13):
*) radius - limited RADIUS timeout maximum value to 3 seconds;

do not do this, our system on average 1~5 seconds to process the radius package
please leave this field customizable

doneware · Thu Nov 02, 2017 3:26 am

What's new in 6.41rc50 (2017-Oct-30 10:13):
*) wireless - new driver with initial support for 160 and 80+80 MHz channel width;

stop right there. this stuff above literally translates to wave2, right?

brwainer · Thu Nov 02, 2017 6:07 am

stop right there. this stuff above literally translates to wave2, right?

I thought 802.11ac Wave2 was MU-MIMO as well as 160MHz / 80+80MHz channels? And to date, I believe all the the wireless chipsets that Mikrotik has shipped in products are Wave1. But maybe this is a little accidental show-of-hand towards new products, which of course would need software support.

Thu Nov 02, 2017 8:03 am

stop right there. this stuff above literally translates to wave2, right?

Wave2 you say... You mean like this:
https://fccid.io/TV7CPGI5ACD2ND/Interna ... os-3602640

Mackiavelly · Thu Nov 02, 2017 12:50 pm

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

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

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

ivanfm · Thu Nov 02, 2017 1:18 pm

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

We also have to use 5 seconds.

mducharme · Thu Nov 02, 2017 5:46 pm

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

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

juliokato · Thu Nov 02, 2017 6:14 pm

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

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

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

idlemind · Thu Nov 02, 2017 6:20 pm

What's new in 6.41rc50 (2017-Oct-30 10:13):
*) radius - limited RADIUS timeout maximum value to 3 seconds;
a very bad idea, this field generally needs to remove the limits, so that I myself can set the desired value, for example, even 15-20 seconds

Yup, seems like MT was overstepping. Seems like something that should be a default value adjustment that is still configurable.

mhugo · Thu Nov 02, 2017 7:25 pm

Hi,

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

/Mikael

cmekcik · Thu Nov 02, 2017 9:38 pm

Hi,

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

/Mikael

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

cmekcik · Thu Nov 02, 2017 9:40 pm

stackflow · Fri Nov 03, 2017 7:33 am

When would the final version to be released?

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

upower3 · Fri Nov 03, 2017 2:49 pm

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

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

idlemind · Fri Nov 03, 2017 4:00 pm

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

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

They've done that already. This was initially implemented in 6.40 (rc36 I believe) and and then pulled for 6.40 stable. I really don't think it will be necessary to that again.

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

JimmyNyholm · Fri Nov 03, 2017 4:27 pm

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

+1 we are using OTP that validates a bit slow sometimes we want 10 seconds... Don't do this.

upower3 · Fri Nov 03, 2017 10:26 pm

They've done that already.

Done what? In released version? With no roll back? Hey, you must be kidding me!

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

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

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

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

skuykend · Fri Nov 03, 2017 10:44 pm

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

They had some of the new bridge code in 6.40rc and reverted it for the final 6.40, then put it back in for 6.41rc. At this point a lot of their new devices are starting to rely on it though.

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

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

idlemind · Fri Nov 03, 2017 10:52 pm

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

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

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

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

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

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

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

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

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

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

amorsen · Sat Nov 04, 2017 12:32 am

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

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

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

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

Cha0s · Sat Nov 04, 2017 1:08 am

Has the routerboot firmware version naming changed in 6.41rc?

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

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

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

Sat Nov 04, 2017 11:49 am

Has the routerboot firmware version naming changed in 6.41rc?

Yes, it has. It happened in 6.41rc47 (see here):

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

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

I'd rather vote for keeping it separate. I believe it's simply safer, and if you have a boot-loop you will at least have an idea of what failed- loader or OS.

Cha0s · Sat Nov 04, 2017 2:48 pm

I missed that entry in the changelog

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

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

upower3 · Sat Nov 04, 2017 7:48 pm

Yes, look at the forum thread for 6.40rc, in 6.40rc36 the new bridge implementation was introduced. It was reverted in 6.40rc41 so that 6.40 could be released to stable without it.

I know that. I'm awre of new bridge implementation and keep my eyes on it, but you missed the point: when MT ships the release I'd prefer to keep two releases, one with just new bridging, another one with the rest of current changelog but without bridging (or in reversed order, first one with just changes, then with just bridge).

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

upower3 · Sat Nov 04, 2017 7:56 pm

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

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

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

eworm · Sun Nov 05, 2017 2:09 am

For me the more important question about boot firmware is: Will the firmware version change with every RouterOS release even if no changes are made? Suppose you installed RouterOS 6.41, then upgraded firmware to 6.41. RouterOS 6.41.1 ships with no changes to the firmware. Is the available firmware version 6.41 or 6.41.1?

upower3 · Sun Nov 05, 2017 7:32 am

For me the more important question about boot firmware is: Will the firmware version change with every RouterOS release even if no changes are made? Suppose you installed RouterOS 6.41, then upgraded firmware to 6.41. RouterOS 6.41.1 ships with no changes to the firmware. Is the available firmware version 6.41 or 6.41.1?

Good question. If you look at f/w changelog you'll notice there is not that many changes that affects your device. So apply each firmware upgrade released is an overkill, and should be bound to specific models.
At the same time, I've never heard about need to downgrade the f/w.
So I'd like to have a noitification inside ROS, that for my hardware I should upgrade firmware, and if my hardware if unaffected then why should I do that f/w upgrade?

anuser · Mon Nov 06, 2017 8:50 pm

What's new in 6.41rc50 (2017-Oct-30 10:13):
*) wireless - new driver with initial support for 160 and 80+80 MHz channel width;

So, is this an updated driver (kernel module) from the ASIC vendor (e.g. Atheros) which has also some bugfixes/features from the vendor?

biatche · Tue Nov 07, 2017 2:33 pm

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

is the new bridge implementation without issues now?

upower3 · Tue Nov 07, 2017 2:38 pm

is the new bridge implementation without issues now?

I'd say we'll when 1) it'll be released and 2) when we'll live with it at least several releases.
Just to be on the safe side.

Tue Nov 07, 2017 3:20 pm

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

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

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

Changes since previous 6.41rc release:

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

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

fposavec · Tue Nov 07, 2017 3:41 pm

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

Any info on this?

soulflyhigh · Tue Nov 07, 2017 3:51 pm

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

Any info on this?

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

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

Regards,
M.

idlemind · Tue Nov 07, 2017 5:21 pm

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

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

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

Changes since previous 6.41rc release:

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

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

MikroTik Support Number: 2017110722001161

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

After upgrading one of my WAP AC's to 6.41rc50 from 6.41rc44 this has been happening. I'll be trying 6.41rc52 to see if it resolves the issue before reverting back to 6.41rc44.

nov/06 18:36:22 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -70 
nov/06 18:37:21 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 18:37:21 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71 
nov/06 18:37:26 wireless,info DC:3A:5E:95:9B:BF@wlan1: reassociating 
nov/06 18:37:26 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, ok 
nov/06 18:37:26 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
nov/06 18:51:34 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 18:51:34 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -60 
nov/06 19:04:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, group key exchange timeout 
nov/06 19:04:24 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, group key exchange timeout 
nov/06 19:04:39 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -90 
nov/06 19:04:46 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -61 
nov/06 19:35:22 wireless,info E8:DE:27:14:C5:39@wlan2: connected, signal strength -65 
nov/06 19:35:22 wireless,info E8:DE:27:14:C5:39@wlan1: disconnected, registered to other interface 
nov/06 19:54:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, group key exchange timeout 
nov/06 19:54:26 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
nov/06 19:54:34 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 19:54:35 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67 
nov/06 20:02:20 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 20:02:20 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -77 
nov/06 20:05:41 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 20:05:41 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -68 
nov/06 20:09:24 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, group key exchange timeout 
nov/06 20:09:34 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -80 
nov/06 20:09:36 wireless,info AC:18:26:4C:A6:EC@wlan1: reassociating 
nov/06 20:09:36 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, ok 
nov/06 20:09:36 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -75 
nov/06 20:09:41 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, unicast key exchange timeout 
nov/06 20:10:00 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -76 
nov/06 20:10:15 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 20:10:16 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71 
nov/06 20:10:21 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 20:10:21 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64 
nov/06 20:10:21 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received deauth: class 2 frame received (6) 
nov/06 20:10:34 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -61 
nov/06 20:19:23 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 20:19:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66 
nov/06 20:19:24 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, group key exchange timeout 
nov/06 20:19:29 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 20:20:47 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67 
nov/06 20:20:50 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -82 
nov/06 20:22:32 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 20:22:32 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -75 
nov/06 20:27:05 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 20:27:11 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -63 
nov/06 20:27:16 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 20:27:25 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -60 
nov/06 20:29:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, group key exchange timeout 
nov/06 20:29:25 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67 
nov/06 20:31:39 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 20:31:44 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71 
nov/06 20:34:24 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, group key exchange timeout 
nov/06 20:34:44 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -79 
nov/06 20:34:47 wireless,info AC:18:26:4C:A6:EC@wlan1: reassociating 
nov/06 20:34:47 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, ok 
nov/06 20:34:47 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -84 
nov/06 20:34:52 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, unicast key exchange timeout 
nov/06 20:35:28 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -76 
nov/06 20:36:51 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 20:36:52 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67 
nov/06 20:36:57 wireless,info DC:3A:5E:95:9B:BF@wlan1: reassociating 
nov/06 20:36:57 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, ok 
nov/06 20:36:57 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
nov/06 20:39:11 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 20:39:11 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66 
nov/06 20:48:42 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 20:49:01 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66 
nov/06 21:33:26 wireless,info E8:DE:27:14:C5:39@wlan2: reassociating 
nov/06 21:33:26 wireless,info E8:DE:27:14:C5:39@wlan2: disconnected, ok 
nov/06 21:33:26 wireless,info E8:DE:27:14:C5:39@wlan2: connected, signal strength -65 
nov/06 21:44:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, group key exchange timeout 
nov/06 21:44:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout 
nov/06 21:44:27 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -72 
nov/06 21:44:27 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -60, wants bridge 
nov/06 21:44:31 wireless,info DC:3A:5E:95:9B:BF@wlan1: reassociating 
nov/06 21:44:31 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, ok 
nov/06 21:44:31 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -60 
nov/06 21:45:54 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 21:45:54 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -60 
nov/06 21:49:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, group key exchange timeout 
nov/06 21:49:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout 
nov/06 21:49:25 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64 
nov/06 21:49:26 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -59, wants bridge 
nov/06 21:53:43 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 21:53:44 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -60 
nov/06 21:57:18 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 21:57:37 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66 
nov/06 22:01:16 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 22:01:17 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
nov/06 22:01:23 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 22:01:23 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
nov/06 22:04:36 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 22:04:37 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71 
nov/06 22:04:42 wireless,info DC:3A:5E:95:9B:BF@wlan1: reassociating 
nov/06 22:04:42 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, ok 
nov/06 22:04:42 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67 
nov/06 22:07:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 22:07:25 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
nov/06 22:11:45 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 22:11:46 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71 
nov/06 22:11:51 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 22:11:51 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -60 
nov/06 22:11:51 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received deauth: class 2 frame received (6) 
nov/06 22:12:04 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
nov/06 22:19:15 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 22:19:21 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -59 
nov/06 22:19:26 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 22:19:34 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -60 
nov/06 22:31:40 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 22:31:41 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -75 
nov/06 22:39:04 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 22:39:05 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -69 
nov/06 22:39:10 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 22:39:41 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67 
nov/06 22:51:22 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 22:51:23 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67 
nov/06 22:59:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout 
nov/06 22:59:24 wireless,info 68:C4:4D:EE:F0:DF@wlan2: disconnected, group key exchange timeout 
nov/06 22:59:40 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -76, wants bridge 
nov/06 23:03:18 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 23:03:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -70 
nov/06 23:03:29 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 23:03:37 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -61 
nov/06 23:12:12 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 23:12:13 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -68 
nov/06 23:12:18 wireless,info DC:3A:5E:95:9B:BF@wlan1: reassociating 
nov/06 23:12:18 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, ok 
nov/06 23:12:18 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -60 
nov/06 23:12:23 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 23:12:31 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -60 
nov/06 23:15:43 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -71 
nov/06 23:16:00 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 23:16:01 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -70 
nov/06 23:16:06 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 23:16:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -72 
nov/06 23:16:29 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 23:16:48 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
nov/06 23:16:50 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -44 
nov/06 23:17:01 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
nov/06 23:17:06 wireless,info DC:3A:5E:95:9B:BF@wlan1: reassociating 
nov/06 23:17:06 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, ok 
nov/06 23:17:06 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -72 
nov/06 23:17:11 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 23:17:37 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -75 
nov/06 23:18:50 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 23:18:56 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66 
nov/06 23:19:01 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 23:19:14 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66 
nov/06 23:19:19 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 23:19:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
nov/06 23:19:28 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66 
nov/06 23:20:15 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 23:20:16 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66 
nov/06 23:20:21 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 23:20:34 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
nov/06 23:21:08 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 23:21:09 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
nov/06 23:24:49 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 23:24:53 wireless,info 68:C4:4D:EE:F0:DF@wlan2: connected, signal strength -52 
nov/06 23:24:55 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -61 
nov/06 23:25:39 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -64 
nov/06 23:28:13 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -52 
nov/06 23:28:28 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 23:28:34 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64 
nov/06 23:28:47 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
nov/06 23:29:04 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -50 
nov/06 23:29:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout 
nov/06 23:29:24 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, group key exchange timeout 
nov/06 23:29:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
nov/06 23:29:36 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 23:29:58 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -69, wants bridge 
nov/06 23:30:00 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -70 
nov/06 23:30:09 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -60 
nov/06 23:30:12 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -79 
nov/06 23:30:15 wireless,info AC:18:26:4C:A6:EC@wlan1: reassociating 
nov/06 23:30:15 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, ok 
nov/06 23:30:15 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -83 
nov/06 23:30:17 wireless,info AC:18:26:4C:A6:EC@wlan1: reassociating 
nov/06 23:30:17 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, ok 
nov/06 23:30:17 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -79 
nov/06 23:30:18 wireless,info AC:18:26:4C:A6:EC@wlan1: reassociating 
nov/06 23:30:18 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, ok 
nov/06 23:30:18 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -82 
nov/06 23:30:23 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, unicast key exchange timeout 
nov/06 23:30:43 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
nov/06 23:33:35 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 23:33:59 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64 
nov/06 23:34:04 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 23:34:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout 
nov/06 23:34:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
nov/06 23:34:29 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -59 
nov/06 23:34:40 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -64, wants bridge 
nov/06 23:35:01 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -78 
nov/06 23:35:06 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, unicast key exchange timeout 
nov/06 23:35:33 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -74 
nov/06 23:35:34 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, received deauth: class 2 frame received (6) 
nov/06 23:38:46 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -77 
nov/06 23:38:53 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, unicast key exchange timeout 
nov/06 23:39:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
nov/06 23:40:18 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -64 
nov/06 23:40:39 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67 
nov/06 23:41:50 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -59 
nov/06 23:42:22 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
nov/06 23:42:24 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -50 
nov/06 23:43:00 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
nov/06 23:43:13 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -64 
nov/06 23:44:07 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 23:44:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
nov/06 23:44:30 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71 
nov/06 23:45:29 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: reassociating 
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: disconnected, ok 
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: connected, signal strength -65 
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: reassociating 
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: disconnected, ok 
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: connected, signal strength -64 
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: reassociating 
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: disconnected, ok 
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: connected, signal strength -64 
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: reassociating 
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: disconnected, ok 
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: connected, signal strength -67 
nov/06 23:46:01 wireless,info E8:DE:27:14:C5:39@wlan1: connected, signal strength -66 
nov/06 23:46:01 wireless,info E8:DE:27:14:C5:39@wlan2: disconnected, registered to other interface 
nov/06 23:49:29 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 23:49:34 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
nov/06 23:52:55 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
nov/06 23:53:21 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -45 
nov/06 23:54:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
nov/06 23:54:55 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -70 
nov/06 23:55:00 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 23:55:32 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64 
nov/06 23:55:37 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
nov/06 23:56:32 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71 
nov/06 23:58:28 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -44 
nov/06 23:59:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
nov/06 23:59:31 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62 
00:02:46 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
00:02:47 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66 
00:02:53 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
00:02:54 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66 
00:04:18 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
00:04:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -63 
00:06:40 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
00:07:22 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64 
00:09:15 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -43 
00:09:20 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, unicast key exchange timeout 
00:09:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout 
00:09:28 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -71, wants bridge 
00:10:51 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -46 
00:11:18 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
00:11:56 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67 
00:12:01 wireless,info DC:3A:5E:95:9B:BF@wlan1: reassociating 
00:12:01 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, ok 
00:12:01 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -73 
00:12:06 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
00:12:28 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
00:12:37 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67 
00:13:25 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
00:13:26 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67 
00:13:28 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
00:13:59 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
00:14:00 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -70 
00:17:05 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -52 
00:17:10 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, unicast key exchange timeout 
00:17:19 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
00:17:44 wireless,info 68:C4:4D:EE:F0:DF@wlan1: connected, signal strength -87 
00:17:44 wireless,info 68:C4:4D:EE:F0:DF@wlan2: disconnected, registered to other interface 
00:18:01 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -76 
00:18:06 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
00:18:20 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71 
00:20:29 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62 
00:25:26 wireless,info 68:C4:4D:EE:F0:DF@wlan1: disconnected, received deauth: sending station leaving (3) 
00:25:39 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
00:25:47 wireless,info 68:C4:4D:EE:F0:DF@wlan2: connected, signal strength -78 
00:28:09 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
00:29:09 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -62 
00:31:50 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62 
00:33:04 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
00:33:41 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -62 
00:34:43 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -64 
00:36:37 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
00:36:45 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
00:36:50 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71 
00:36:58 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
00:41:46 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
00:41:47 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64 
00:41:52 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
00:42:28 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -63 
00:43:26 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
00:43:32 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67 
00:43:59 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62 
00:44:06 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -75 
00:44:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
00:44:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout 
00:44:29 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
00:44:35 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -70 
00:44:42 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
00:44:42 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -69, wants bridge 
00:44:43 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64 
00:47:02 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
00:47:07 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67 
00:49:05 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
00:51:33 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
00:51:39 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -62 
00:58:36 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -63 
00:59:20 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
00:59:25 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -62 
00:59:29 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -79 
01:00:36 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
01:04:15 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
01:05:30 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
01:05:31 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67 
01:05:35 wireless,info DC:3A:5E:95:9B:BF@wlan1: reassociating 
01:05:35 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, ok 
01:05:35 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -59 
01:09:41 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
01:09:46 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -61 
01:09:51 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -66 
01:12:10 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
01:12:16 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64 
01:14:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
01:16:06 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
01:16:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -60 
01:16:53 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -65 
01:19:15 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
01:19:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, group key exchange timeout 
01:19:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout 
01:19:24 wireless,info E8:DE:27:14:C5:39@wlan1: disconnected, group key exchange timeout 
01:19:39 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -65, wants bridge 
01:19:46 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64 
01:20:00 wireless,info E8:DE:27:14:C5:39@wlan2: connected, signal strength -65 
01:20:16 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -68 
01:20:32 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
01:21:10 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66 
01:21:15 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
01:21:33 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -62 
01:24:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
01:26:12 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
01:26:18 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -61 
01:26:48 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -64 
01:26:58 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62 
01:28:41 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
01:31:10 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -66 
01:31:55 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
01:32:01 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -58 
01:32:06 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
01:32:33 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -63 
01:32:36 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
01:32:37 wireless,info DC:3A:5E:95:9B:BF@wlan1: reassociating 
01:32:37 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, ok 
01:32:37 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -70 
01:32:40 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
01:34:36 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
01:34:37 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
01:35:55 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
01:35:55 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -68 
01:37:39 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -67 
01:39:21 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
01:39:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
01:39:26 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -70 
01:40:44 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
01:40:45 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71 
01:41:44 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -66 
01:43:01 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
01:43:39 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
01:43:44 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
01:43:46 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
01:44:02 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71 
01:51:20 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -63 
01:56:28 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
02:03:30 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -63 
02:07:27 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -66 
02:08:36 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
02:09:04 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
02:12:32 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -64 
02:13:26 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
02:13:35 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
02:13:40 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -59 
02:16:29 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -63 
02:21:36 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
02:24:24 wireless,info 10:02:B5:B0:AD:47@wlan2: disconnected, group key exchange timeout 
02:28:10 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -69 
02:29:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
02:33:33 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -66 
02:34:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
02:41:05 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
02:41:10 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -62 
02:41:15 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62 
02:44:55 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -63 
02:46:23 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
02:47:47 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
02:47:53 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -63 
02:49:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
02:51:07 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
02:51:08 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -58 
02:53:25 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -63 
02:54:24 wireless,info 00:0F:60:08:1F:5B@wlan1: disconnected, group key exchange timeout 
02:54:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, group key exchange timeout 
02:54:28 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66 
02:56:09 wireless,info 00:0F:60:08:1F:5B@wlan1: connected, signal strength -53 
02:56:14 wireless,info 00:0F:60:08:1F:5B@wlan1: disconnected, unicast key exchange timeout 
02:56:15 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
02:56:38 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -70 
02:58:35 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
02:59:25 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -66 
03:04:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, group key exchange timeout 
03:04:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
03:04:36 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64 
03:07:12 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62 
03:10:22 wireless,info 00:0F:60:08:1F:5B@wlan1: connected, signal strength -55 
03:12:23 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
03:15:39 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -64 
03:17:00 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
03:17:19 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -63 
03:22:30 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
03:31:02 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -64 
03:32:36 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
03:34:45 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62 
03:36:05 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -70 
03:39:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
03:39:50 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
03:46:38 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -64 
03:48:09 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
03:50:55 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
03:50:56 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
03:51:43 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -64 
03:52:42 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
03:52:48 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64 
03:55:40 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
03:55:46 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -63 
04:04:20 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -61 
04:04:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
04:04:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, group key exchange timeout 
04:04:28 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
04:07:16 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -80 
04:09:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
04:09:29 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
04:19:36 wireless,info 68:C4:4D:EE:F0:DF@wlan1: connected, signal strength -78 
04:19:37 wireless,info 68:C4:4D:EE:F0:DF@wlan2: disconnected, registered to other interface 
04:28:35 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62 
04:33:40 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
04:34:46 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -65 
04:40:34 wireless,info 68:C4:4D:EE:F0:DF@wlan1: disconnected, received deauth: sending station leaving (3) 
04:40:37 wireless,info 68:C4:4D:EE:F0:DF@wlan2: connected, signal strength -82 
04:47:01 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62 
04:52:10 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
04:56:33 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -65 
05:01:40 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
05:10:05 wireless,info B8:A1:75:48:3C:29@wlan1: connected, signal strength -64 
05:10:10 wireless,info B8:A1:75:48:3C:29@wlan1: disconnected, unicast key exchange timeout 
05:10:42 wireless,info B8:A1:75:48:3C:29@wlan1: connected, signal strength -76 
05:11:48 wireless,info 68:C4:4D:EE:F0:DF@wlan1: connected, signal strength -81 
05:11:51 wireless,info 68:C4:4D:EE:F0:DF@wlan2: disconnected, registered to other interface 
05:14:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
05:14:37 wireless,info B8:A1:75:48:3C:29@wlan1: disconnected, received disassoc: sending station leaving (8) 
05:14:38 wireless,info B8:A1:75:48:3C:29@wlan1: connected, signal strength -75 
05:16:33 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -72 
05:16:48 wireless,info B8:A1:75:48:3C:29@wlan1: disconnected, received disassoc: sending station leaving (8) 
05:17:48 wireless,info B8:A1:75:48:3C:29@wlan1: connected, signal strength -69 
05:17:53 wireless,info B8:A1:75:48:3C:29@wlan1: disconnected, unicast key exchange timeout 
05:18:04 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
05:18:25 wireless,info B8:A1:75:48:3C:29@wlan1: connected, signal strength -86 
05:19:48 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
05:19:48 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
05:20:17 wireless,info 68:C4:4D:EE:F0:DF@wlan1: disconnected, received deauth: sending station leaving (3) 
05:20:26 wireless,info 68:C4:4D:EE:F0:DF@wlan2: connected, signal strength -77 
05:22:44 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -63 
05:23:35 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -75 
05:25:54 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
05:25:54 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -62 
05:27:52 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
05:31:33 wireless,info 68:C4:4D:EE:F0:DF@wlan1: connected, signal strength -84 
05:31:33 wireless,info 68:C4:4D:EE:F0:DF@wlan2: disconnected, registered to other interface 
05:44:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
05:46:52 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -64 
05:48:56 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -64 
05:49:54 wireless,info 68:C4:4D:EE:F0:DF@wlan1: disconnected, received deauth: sending station leaving (3) 
05:49:57 wireless,info 68:C4:4D:EE:F0:DF@wlan1: connected, signal strength -78 
05:50:02 wireless,info 68:C4:4D:EE:F0:DF@wlan1: disconnected, received deauth: sending station leaving (3) 
05:50:09 wireless,info 68:C4:4D:EE:F0:DF@wlan2: connected, signal strength -81 
05:54:05 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
05:55:14 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
05:56:23 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64 
05:56:28 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
05:56:39 wireless,info 68:C4:4D:EE:F0:DF@wlan1: connected, signal strength -80 
05:56:42 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71 
05:56:42 wireless,info 68:C4:4D:EE:F0:DF@wlan2: disconnected, registered to other interface 
05:56:45 wireless,info 68:C4:4D:EE:F0:DF@wlan1: disconnected, received deauth: sending station leaving (3) 
05:56:47 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
05:56:48 wireless,info 68:C4:4D:EE:F0:DF@wlan2: connected, signal strength -78 
05:56:49 wireless,info B8:A1:75:48:3C:29@wlan1: disconnected, extensive data loss 
05:57:00 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -74 
05:57:05 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
05:57:22 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
05:57:23 wireless,info DC:3A:5E:95:9B:BF@wlan2: connected, signal strength -77 
06:01:07 wireless,info 68:C4:4D:EE:F0:DF@wlan1: connected, signal strength -78 
06:01:07 wireless,info 68:C4:4D:EE:F0:DF@wlan2: disconnected, registered to other interface 
06:02:37 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -73 
06:03:37 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
06:04:01 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -65 
06:09:12 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
06:13:16 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62 
06:16:31 wireless,info 68:C4:4D:EE:F0:DF@wlan1: disconnected, received deauth: sending station leaving (3) 
06:16:39 wireless,info 68:C4:4D:EE:F0:DF@wlan2: connected, signal strength -79 
06:17:02 wireless,info 68:C4:4D:EE:F0:DF@wlan1: connected, signal strength -73 
06:17:03 wireless,info 68:C4:4D:EE:F0:DF@wlan2: disconnected, registered to other interface 
06:18:00 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -75 
06:18:21 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
06:19:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
06:23:34 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -80 
06:24:23 wireless,info 68:C4:4D:EE:F0:DF@wlan1: disconnected, received deauth: sending station leaving (3) 
06:24:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
06:24:34 wireless,info 68:C4:4D:EE:F0:DF@wlan1: connected, signal strength -72 
06:26:38 wireless,info 68:C4:4D:EE:F0:DF@wlan1: disconnected, received deauth: sending station leaving (3) 
06:26:41 wireless,info 68:C4:4D:EE:F0:DF@wlan2: connected, signal strength -83 
06:33:36 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -87 
06:41:37 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62 
06:44:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout 
06:44:29 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -65, wants bridge 
06:46:41 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
06:49:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
06:49:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout 
06:49:26 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -68, wants bridge 
06:49:34 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -76 
06:54:24 wireless,info 00:0F:60:08:1F:5B@wlan1: disconnected, group key exchange timeout 
06:54:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
06:54:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout 
06:54:28 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -67, wants bridge 
06:54:54 wireless,info 00:0F:60:08:1F:5B@wlan1: connected, signal strength -55 
07:00:00 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -72 
07:00:32 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
07:00:33 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -73 
07:01:08 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
07:01:21 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -79 
07:08:28 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62 
07:09:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
07:09:25 wireless,info E8:DE:27:14:C5:39@wlan2: reassociating 
07:09:25 wireless,info E8:DE:27:14:C5:39@wlan2: disconnected, ok 
07:09:25 wireless,info E8:DE:27:14:C5:39@wlan2: connected, signal strength -65 
07:11:52 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -70 
07:13:59 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8) 
07:16:38 wireless,info 68:C4:4D:EE:F0:DF@wlan1: connected, signal strength -84 
07:16:41 wireless,info 68:C4:4D:EE:F0:DF@wlan2: disconnected, registered to other interface 
07:16:57 wireless,info 68:C4:4D:EE:F0:DF@wlan2: connected, signal strength -87 
07:16:57 wireless,info 68:C4:4D:EE:F0:DF@wlan1: disconnected, registered to other interface 
07:17:05 wireless,info 68:C4:4D:EE:F0:DF@wlan2: disconnected, extensive data loss 
07:19:24 wireless,info 00:0F:60:08:1F:5B@wlan1: disconnected, group key exchange timeout 
07:19:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout 
07:19:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
07:19:26 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -58 
07:19:26 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -66, wants bridge 
07:19:56 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
07:19:58 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -55 
07:20:10 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
07:20:18 wireless,info 00:0F:60:08:1F:5B@wlan1: connected, signal strength -54 
07:20:55 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -61 
07:24:24 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, group key exchange timeout 
08:52:30 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -65 
08:53:11 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3) 
08:54:58 wireless,info 2C:F0:A2:1F:56:4B@wlan1: connected, signal strength -79 
08:56:18 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -76 
08:56:51 wireless,info E8:DE:27:14:C5:39@wlan2: disconnected, extensive data loss 
08:57:22 wireless,info 10:02:B5:B0:AD:47@wlan2: connected, signal strength -70 
08:57:30 wireless,info E8:DE:27:14:C5:39@wlan2: connected, signal strength -62

Update, problem persists in 6.41rc52.

09:39:09 system,info verified routeros-mipsbe-6.41rc52.npk 
09:39:09 system,info installed routeros-mipsbe-6.41rc52 
09:39:09 system,info router rebooted 
09:39:12 bridge,info "br1" mac address changed to F6:20:18:E8:60:F6 
09:39:15 wireless,info F4:30:B9:B3:0F:ED@wlan1: connected, signal strength -59 
09:39:16 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66 
09:39:16 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -69, wants bridge 
09:39:21 wireless,info 00:0F:60:08:1F:5B@wlan1: connected, signal strength -54 
09:39:23 wireless,info B8:3E:59:B3:9B:0B@wlan2: connected, signal strength -46 
09:39:24 interface,info ether1 link up (speed 1G, full duplex) 
09:39:33 wireless,info E8:DE:27:14:C5:39@wlan2: connected, signal strength -65 
09:40:00 wireless,info E8:DE:27:14:C5:39@wlan2: disconnected, received deauth: sending station leaving (3) 
09:40:11 system,info,account user admin logged in from 10.211.11.11 via ssh 
09:40:13 wireless,info 10:02:B5:B0:AD:47@wlan2: connected, signal strength -70 
09:41:47 system,info cloud change time Nov/07/2017-09:40:30 => Nov/07/2017-09:41:47 
09:43:21 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8) 
09:43:27 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -70 
09:44:37 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -68 
09:44:42 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, unicast key exchange timeout 
09:44:46 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -70 
09:44:51 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, unicast key exchange timeout 
09:45:13 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -73 
09:45:36 wireless,info F4:30:B9:B3:0F:ED@wlan1: disconnected, group key exchange timeout 
09:45:36 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, group key exchange timeout 
09:45:36 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout 
09:45:36 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout 
09:45:51 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -69, wants bridge 
09:45:55 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -79 
09:46:00 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66 
09:46:05 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
09:46:46 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -63 
09:46:51 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
09:48:18 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -72 
09:48:23 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
09:49:04 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65 
09:49:09 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
09:49:22 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -63 
09:49:27 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout 
09:49:41 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65

Final Update: Reverting to 6.41rc44 fixed my issues. I'll wait until >6.41rc52 before trying again on those devices. 6.41rc52 is functioning fine on my test 750Gr3 though (no wifi chips there).

Tue Nov 07, 2017 11:34 pm

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

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

eworm · Wed Nov 08, 2017 12:18 am

For me the more important question about boot firmware is: Will the firmware version change with every RouterOS release even if no changes are made? Suppose you installed RouterOS 6.41, then upgraded firmware to 6.41. RouterOS 6.41.1 ships with no changes to the firmware. Is the available firmware version 6.41 or 6.41.1?

RouterOS 6.41rc52 ships with firmware version 6.41rc50... So looks like nothing changed except the version bump.

idlemind · Wed Nov 08, 2017 6:44 pm

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

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

Or people had other RADIUS services (devices) connecting to it. You know, because that never happens. #genius. Depending on the IOS version Cisco will timeout at 5 seconds. MikroTik employees. If you are confronted with the choice between allowing something to be configurable with a sensible default vs a static unchanging value always choose configurable.

Cha0s · Wed Nov 08, 2017 7:49 pm

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

I've upgraded a mAP-Lite from 6.40.4 to 6.41rc52.

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

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

eworm · Wed Nov 08, 2017 10:44 pm

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

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

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

Oh, funny... I have a system that is running RouterOS 6.41rc52, with current and upgrade firmware at 6.41rc50. Started a firmware upgrade, after a reboot I can confirm your results.
Well, that will make my upgrade notification scripts go crazy... :-p

JimmyNyholm · Fri Nov 10, 2017 11:34 am

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

kamillo · Fri Nov 10, 2017 1:06 pm

To add to JimmyNyholm's comment: I'm still waiting for LACP hardware support (offload) in CRS125

biatche · Sat Nov 11, 2017 5:00 am

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

Forum police @andirys will probably ask you to post in feature request.

But yes, this is definitely needed in urgency.

ryba84 · Sun Nov 12, 2017 3:38 pm

*) interface - added option to join and exclude "/interface list" from one and another;

How this works? Firewall is not using included list.

pe1chl · Mon Nov 13, 2017 10:37 am

*) interface - added option to join and exclude "/interface list" from one and another;
How this works? Firewall is not using included list.

The default firewall is using lists now. When you have upgraded from versions previous to 6.40 all the time and never
reset the configuration, your firewall is still using the old method. However, when you reset everything to defaults you
will find it uses lists WAN and LAN to identify the interfaces.
It depends on the amount of work you have put in your config if it is worth the trouble, of course.

ryba84 · Mon Nov 13, 2017 6:36 pm

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

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

mrz · Mon Nov 13, 2017 6:53 pm

@ryba84 report problem to support and attach supout rif file.

rac · Tue Nov 14, 2017 12:09 pm

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

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

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

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

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

biatche · Tue Nov 14, 2017 7:47 pm

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

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

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

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

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

you need to add your bridge interface to tagged ports.

raffav · Tue Nov 14, 2017 10:03 pm

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

any one can help

marekm · Wed Nov 15, 2017 12:05 am

*) w60g - general work on PtMP implementation for 60 GHz connections;

Devices in the Wireless Wire kit come with Level 3 licenses - will it work with more than one client, or is it necessary to buy a Level 4 license to test 60GHz PtMP?

biatche · Wed Nov 15, 2017 1:03 am

Been a long day.

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

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

Simply reverting to 6.40.5 gave me good stable expected rates.

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

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

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

blajah · Wed Nov 15, 2017 7:15 pm

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

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

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

Same here, 951g2hnd

 routerboard: yes
             model: 951G-2HnD
     serial-number: 4F4********
     firmware-type: ar9344
  factory-firmware: 3.10
  current-firmware: 6.41rc52
  upgrade-firmware: 6.41rc50

pe1chl · Wed Nov 15, 2017 8:28 pm

I have installed it on an old RB750 I use for some test.
It shows:

Firmware type: ar7240
Factory firmware: 3.02
Current firmware: 3.33
Update firmware:

I.e. there is nothing after upgrade firmware and the upgrade button does nothing (no log entry).

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

eworm · Thu Nov 16, 2017 11:34 am

Oh, funny... I have a system that is running RouterOS 6.41rc52, with current and upgrade firmware at 6.41rc50. Started a firmware upgrade, after a reboot I can confirm your results.
Well, that will make my upgrade notification scripts go crazy... :-p

Possibly a read-only property "upgrade-available" is the easiest way to solve this?

kait · Thu Nov 16, 2017 11:53 am

Hi, I raise a new topic Bridge HW-Offload and VLAN-Filtering with CRS226-24G-2S+RM at v6.41rc52 here viewtopic.php?f=1&t=127805 , maybe someone can explain issue.

mducharme · Thu Nov 16, 2017 11:49 pm

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

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

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

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

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

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

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

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

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

pe1chl · Fri Nov 17, 2017 10:38 am

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

mducharme · Fri Nov 17, 2017 11:48 am

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

It is not just one location - we have 15 such locations. We would need 15 RADIUS servers. These locations have no air conditioning and so the internal shelter goes up to 40C in the summer and down to -30C in the winter. Local RADIUS server is NOT a good idea.

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

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

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

Chupaka · Fri Nov 17, 2017 12:03 pm

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

Worked for me when MikroTik broke VLANs over bonding

biatche · Fri Nov 17, 2017 12:35 pm

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

Waiting for MT's good news now.

mducharme · Fri Nov 17, 2017 9:48 pm

FYI, Cisco docs say the maximum RADIUS timeout on their gear is 1000 seconds. Juniper maximum is 90 seconds. Both seem a bit extreme, but that just shows how far from a 3 second maximum other vendors are.

idlemind · Fri Nov 17, 2017 10:00 pm

These complaints are exactly why arbitrary hard setting a value is bad when it can be valid within a range. This includes what a developer personally feels is acceptable.

neg2led · Sat Nov 18, 2017 4:58 am

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

MT say that the reduction here shouldn't make a difference. In this post by strods from page 7, strods says that neither of the routerOS RADIUS client processes will wait more than 3 seconds even if the timeout setting is greater than 3 seconds - important part in bold for emphasis;

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

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

Ignoring the part about RADIUS taking more than 3 seconds being unacceptable for the time being, as described by strods, this change should not have resulted in a regression of functionality, as the RADIUS client inside routerOS was not honoring timeouts above 3 seconds to begin with. Based on what mducharme says above, this does not appear to be the case.

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

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

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

blajah · Sat Nov 18, 2017 5:39 pm

I have installed it on an old RB750 I use for some test.
It shows:
Code: Select all
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;

pe1chl · Sat Nov 18, 2017 10:12 pm

That is why I mention that there is an issue with the RB750 firmware - as this is the release candidate topic and developers are hopefully reading it before doing a release.

mducharme · Sun Nov 19, 2017 3:09 am

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

Exactly, my own observations of the behavior of earlier versions do not jibe with what strods claims to be the case. It seems extremely unlikely that it was coincidental that the issue vanished when I made the change, given the circumstances.

mducharme: Have you opened a support ticket for this regression & provided supout.rifs etc? This isn't an official support channel, and it sounds like you should be talking to support if you aren't already.

No I haven't, only because I would have to upgrade to 6.41 at one of those satellite sites (15 of our 45 sites are connected via satellite). However I don't need a test to tell me what effect limiting the maximum value will have when we are currently using 6000 ms, and given my previous experiences. We could maybe get by with 5000ms, possibly even 4000ms, but if the RADIUS server thinks the customer is still logged in, it will only authenticate in 3000ms if the stars are in perfect alignment due to the extra time required to pull the list of logged in customers. Due to the power requirements of the satellite amplifiers they cannot be connected to the UPS, so when the power goes down at the site (some sites are on unreliable diesel) the satellite feed goes down immediately. If customers log off during this time (common b/c they usually lose power as well), the RADIUS disconnect notification doesn't make it to the RADIUS server because, with the satellite link down, there is no way for the packet to reach its destination. When the site comes back up again, the RADIUS server sees the customers trying to log in again and it thinks they are already logged in, so before it sends the 'accept' or 'reject' it has to go to the router and check to see if they actually are still logged in. Customers sometimes share their PPPoE credentials with friends to try to give them free service, so this check is necessary to protect against that.

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

pe1chl · Sun Nov 19, 2017 11:24 am

No I haven't, only because I would have to upgrade to 6.41 at one of those satellite sites (15 of our 45 sites are connected via satellite).

You have 15 sites of a problematic type for which it costs $1000 to make a support visit and you don't have a way to test a similar site from home (a subscription to the same satellite service)?
Really? It all does not seem very professional...

mducharme · Sun Nov 19, 2017 9:05 pm

You have 15 sites of a problematic type for which it costs $1000 to make a support visit and you don't have a way to test a similar site from home (a subscription to the same satellite service)?
Really? It all does not seem very professional...

The dishes are 2.4 or 3.8 meters, so they are big (larger than a home satellite service). It is not easy like putting up an Xplornet dish on a home, these are very big and very heavy, they cannot be roof or wall mounted, unless maybe the roof was concrete and very thick, able to support the weight. So the dish would generally need to be on the ground with a concrete pad for stability and fencing to avoid people standing in front of the beam. Even if we had a place to install such a thing in our downtown urban office building, each dish has its own upload channel, so there would need to be one assigned to a "test dish" but all are in use since actual sites are priority. Therefore to operate a test dish with no channels we would need to shut down one of the 15 sites to free up a channel to bring up a test dish. It would be great to have a test system, it would make certain things easier, but it is just not feasible for all those reasons, so we have lived without it.

satellitepicture.PNG

msatter · Sun Nov 19, 2017 11:54 pm

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

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

troffasky · Mon Nov 20, 2017 7:18 pm

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

Don't need a satellite dish to emulate the behaviour of a typical satellite link:

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

LynxChaus · Mon Nov 20, 2017 11:10 pm

We could maybe get by with 5000ms, possibly even 4000ms, but if the RADIUS server thinks the customer is still logged in, it will only authenticate in 3000ms if the stars are in perfect alignment due to the extra time required to pull the list of logged in customers.

125ms need to reach satellite and 125ms to reach earth. Why you need HUGE timeout ? You bounce signal multiple times to orbit and back?

Due to the power requirements of the satellite amplifiers they cannot be connected to the UPS, so when the power goes down at the site (some sites are on unreliable diesel) the satellite feed goes down immediately. If customers log off during this time (common b/c they usually lose power as well), the RADIUS disconnect notification doesn't make it to the RADIUS server because, with the satellite link down, there is no way for the packet to reach its destination. When the site comes back up again, the RADIUS server sees the customers trying to log in again and it thinks they are already logged in, so before it sends the 'accept' or 'reject' it has to go to the router and check to see if they actually are still logged in. Customers sometimes share their PPPoE credentials with friends to try to give them free service, so this check is necessary to protect against that.

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

You need only ONE snmpget to understand what happens with equipment and connected users - check sysUpTimeInstance (.1.3.6.1.2.1.1.3.0) and if it goes back - assume "power lost, all users disconnected" and drop it manually in radius. it's not rocket science.

mducharme · Tue Nov 21, 2017 1:19 am

125ms need to reach satellite and 125ms to reach earth. Why you need HUGE timeout ? You bounce signal multiple times to orbit and back?

Ping to the site across the satellite link is at least 600ms round trip, so 300ms each way. I have never seen latency drop below that. You are suggesting that round trip latency should be 250 ms or slightly higher, but that is just not realistic.

You need only ONE snmpget to understand what happens with equipment and connected users - check sysUpTimeInstance (.1.3.6.1.2.1.1.3.0) and if it goes back - assume "power lost, all users disconnected" and drop it manually in radius. it's not rocket science.

That requires extra programming, and won't work in some scenarios. The RADIUS server itself (FreeRADIUS) already has the SNMP check built in to poll the list of interfaces in event that it thinks the customer is already logged in - this did not need to be scripted as it is a built in feature, the RADIUS server does this SNMP check while the NAS is waiting for the 'accept' or 'reject'. What you are describing is an external script that would keep track of the uptime for each router and be able to tell if one went back and just disconnect the sessions for that router. It is certainly possible but such a script would have to be carefully tested. That also wouldn't help with a scenario where the router did not go down but the satellite lost power. A brief power outage would not knock the router offline, so the sysuptime would not go back. Unfortunately this also happens fairly frequently, so a solution that doesn't address this would not help.

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

sup5 · Tue Nov 21, 2017 4:20 am

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

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

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

Fri Nov 24, 2017 3:09 pm

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

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

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

Changes since previous 6.41rc release:

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

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

Chupaka · Fri Nov 24, 2017 3:14 pm

*) firewall - added "tls-host" firewall matcher (CLI only);

Sweet. No more Layer 7 for HTTPS blocking

How it works? Which packet matches? Does it support wildcards?

pietroscherer · Fri Nov 24, 2017 3:24 pm

*) firewall - added "tls-host" firewall matcher (CLI only);
Sweet. No more Layer 7 for HTTPS blocking
How it works? Which packet matches? Does it support wildcards?

+1

pe1chl · Fri Nov 24, 2017 4:23 pm

*) firewall - added "tls-host" firewall matcher (CLI only);
Sweet. No more Layer 7 for HTTPS blocking
How it works? Which packet matches? Does it support wildcards?

I presume this is just a special case of a Layer 7 with some pre-defined pattern, and only works when SNI is used.

Cha0s · Fri Nov 24, 2017 4:27 pm

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

It could be an iptables module specific to that function instead of abstracting a L7 filter. Like this https://github.com/Lochnair/xt_tls

honzam · Fri Nov 24, 2017 4:46 pm

*) wireless - added passive scan option for wireless scan mode;

Any info about this? passive scan has been implemented for a long time

troffasky · Sat Nov 25, 2017 12:53 am

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

No need for SNI, CN of certificate is in plaintext whether SNI is used or not.

bjornr · Sat Nov 25, 2017 12:59 am

Upgrading a CRS326-24G-2S+ to 6.41rc56 broke DHCP relaying through it, the requests are passed through but the responses (OFFERs) are never seen by the client. Reverting to rc52 fixed this issue.

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

Paternot · Sat Nov 25, 2017 3:28 am

*) wireless - added passive scan option for wireless scan mode;
Any info about this? passive scan has been implemented for a long time

It's not clear, from the changelog, but: If I remember it right, Mikrotik didn't support passive scan with 802.11ac, only b, g, n. Maybe this is it, at long last.

Sat Nov 25, 2017 11:47 am

*) firewall - added "tls-host" firewall matcher (CLI only);
Sweet. No more Layer 7 for HTTPS blocking
How it works? Which packet matches? Does it support wildcards?

At a guess, its based on xt_tls which can support wildcards, see https://github.com/Lochnair/xt_tls

nkourtzis · Mon Nov 27, 2017 12:24 pm

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

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.

nkourtzis · Tue Nov 28, 2017 3:07 pm

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

Can it possibly be that we approaching the end of v6 development? Just wondering...

pe1chl · Tue Nov 28, 2017 3:28 pm

nkourtzis wrote:
Can it possibly be that we approaching the end of v6 development? Just wondering...

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

biatche · Tue Nov 28, 2017 8:12 pm

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

Can it possibly be that we approaching the end of v6 development? Just wondering...

Was wondering just the same.. yet ROS still lacks many basic features..

JimmyNyholm · Wed Nov 29, 2017 11:04 pm

New bridge implementation need:

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

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

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

biatche · Thu Nov 30, 2017 12:51 am

New bridge implementation need:

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

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

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

Agreed, these are some of the basic features i was talking about.

nkourtzis · Thu Nov 30, 2017 11:35 am

New bridge implementation need:

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

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

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

Also add Q-in-Q support.

upower3 · Thu Nov 30, 2017 11:56 am

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

True, now wise to roll up this "breaking" changes in "ordinary" release. Many people used to apply updates without reading out readme-s, or without huge testing, and this will break many setups around the world.

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

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

This change (take for granted it'll break some setups around the world) will impact MT's reputation while won't give any benefits to customers. Many people won't give a damn if they have master/slave or bridge to employ h/w packet processing, but they surely be quite unhappy (and will spread the word) when their setup be break out of sudden.

bajodel · Fri Dec 01, 2017 10:58 am

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

skuykend · Fri Dec 01, 2017 11:11 am

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

+1
That seems quite clever. May bug a few, but would allow MikroTik to continue going forward much less risky.

upower3 · Fri Dec 01, 2017 11:37 am

For admins ready to 6.41 it would be simple enough as manually switch.

It would be quite useful to create another forum topic to let users report their setups that failed to convert from master-slave to new bridge implementation. At least, this may be good to add these situation into config converter.

eriitguy · Fri Dec 01, 2017 4:48 pm

Hello!

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

Thank you!

anuser · Mon Dec 04, 2017 12:14 pm

I had problems with several Samsung Galaxy S7 Edge running Android 7 with wAP AC and central CAPSMAN controller running 6.40.5. The smartphones connected, but they had no internet. I updated the wAP AC from 6.40.5 to 6.41rc56. The CAPSMAN controller is still runing at 6.40.5
Now the smartphones can connect and have internet access. With version 6.40.5 again, they had problems again.

biatche · Mon Dec 04, 2017 2:27 pm

Dear mikrotik, why has development slowed down? In the past we used to see a new rc every 3-5 days.

Paternot · Mon Dec 04, 2017 2:44 pm

Dear mikrotik, why has development slowed down? In the past we used to see a new rc every 3-5 days.

I noticed that too. But 6.41 is a big step, with bridge hardware offloading and whatnot. I believe they are testing the (numerous) bugs already found, and preparing for another RC - or the gold one.

raffav · Mon Dec 04, 2017 2:54 pm

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

Enviado de meu XT1580 usando Tapatalk

juliokato · Mon Dec 04, 2017 4:33 pm

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

Enviado de meu XT1580 usando Tapatalk

Maybe renaming the V6.41RC to V7, since they introduced many new features.

Mon Dec 04, 2017 4:56 pm

V7 should have new kernel and totally new implementation of some functionalities. Do not skip so far...

pe1chl · Mon Dec 04, 2017 5:55 pm

V7 should have new kernel and totally new implementation of some functionalities. Do not skip so far...

That is never going to work! They need to separate some of the changes into subreleases and packages, including RC versions, or this version is never going to materialize.
I vote for releasing a V7 based on 6.41RC with a new kernel (first as an RC), then make that a "current" version and await the reports of all the new minor problems, then (or partly in parallel) release all the "totally new implementations of some functionalities" as optional packages like it was done before with wireless and routing.
So the people interested in new functionality and prepared to be confronted with some bugs can test in parallel with the baseline users.

biatche · Mon Dec 04, 2017 6:00 pm

V7 should have new kernel and totally new implementation of some functionalities. Do not skip so far...
That is never going to work! They need to separate some of the changes into subreleases and packages, including RC versions, or this version is never going to materialize.
I vote for releasing a V7 based on 6.41RC with a new kernel (first as an RC), then make that a "current" version and await the reports of all the new minor problems, then (or partly in parallel) release all the "totally new implementations of some functionalities" as optional packages like it was done before with wireless and routing.
So the people interested in new functionality and prepared to be confronted with some bugs can test in parallel with the baseline users.

What's actually the issue having 6.41 with the new bridge implementation? If it works it works...

WojtusW5 · Mon Dec 04, 2017 6:32 pm

Hi, small off-top when 6.41 will be as current version ?
Is there an initial deadline ?

pe1chl · Mon Dec 04, 2017 7:16 pm

What's actually the issue having 6.41 with the new bridge implementation? If it works it works...

Yes, if it works... but yesterday I spent quite some time trying to migrate an existing complex configuration consisting of
multiple bridges for different VLANs to the new 6.41RC and I have so far been unable to do so.
Ok, to be honest it still worked after merely upgrading it, but with the existing split bridges with VLAN subinterfaces as ports.
I tried to migrate to a single bridge with VLANs inside and several tagged and untagged member ports, and it simply did not work.
So a blind upgrade to 6.41 would probably survive, merely losing the switching (master-port) hardware assistance.
However there is still work to do (maybe on the software, maybe on my configuration skills) before several similar routers can run 6.41.

biatche · Mon Dec 04, 2017 7:26 pm

What's actually the issue having 6.41 with the new bridge implementation? If it works it works...
Yes, if it works... but yesterday I spent quite some time trying to migrate an existing complex configuration consisting of
multiple bridges for different VLANs to the new 6.41RC and I have so far been unable to do so.
Ok, to be honest it still worked after merely upgrading it, but with the existing split bridges with VLAN subinterfaces as ports.
I tried to migrate to a single bridge with VLANs inside and several tagged and untagged member ports, and it simply did not work.
So a blind upgrade to 6.41 would probably survive, merely losing the switching (master-port) hardware assistance.
However there is still work to do (maybe on the software, maybe on my configuration skills) before several similar routers can run 6.41.

Why not show the configuration in case theres a "bug" and "use-case" that they aren't aware of that isnt working?

In any case... seeing the slow progress as of late is worry-some.. a feeling says that maybe they've hid a roadblock in the development... maybe just a false feeling, but in any case its really unusual.

pe1chl · Mon Dec 04, 2017 8:35 pm

Why not show the configuration in case theres a "bug" and "use-case" that they aren't aware of that isnt working?

Well I first want to investigate a bit more in both 6.40 and 6.41 what can be done to first make this config more optimal and then migrate it.
Doing so I found problems with 6.40 as well and it may be that the problem I found in 6.40 is also affecting 6.41
In general the situations is: I have 4 different bridges each with a different local network in it, and they each have a virtual WiFi interface in
them, one or more untagged ethernet ports, and two ports where there is a VLAN subinterface for each of the networks, the VLAN interfaces are in the bridges (trunk to external switches).
This I am trying to migrate to a new 6.41 config where there is one bridge with 3 VLANs in it (one of the networks is the "untagged" VLAN) and the ports
are either untagged members of the VLANs (or the bridge itself) or tagged members. On the bridge itself there are 3 VLAN subinterfaces for the router access
to the bridge. And then there are 3 ethernet ports that are outside all the bridges.
It works for 2 of the VLANs but not the third. There is something weird going on.
When trying on 6.40 to do some things in the switch that are now done in the bridge (hoping it would auto-migrate easier), I found that while on my RB2011 everthing works just fine on switch1, the same setup on switch2 (several VLANs on the switch, untagged ports, one port outside the switch) would not work. It appears the switch2 will not do "always strip" with a default VLAN tag...

abis · Wed Dec 06, 2017 10:07 am

Dear mikrotik, why has development slowed down? In the past we used to see a new rc every 3-5 days.

Good point

jondavy · Wed Dec 06, 2017 2:57 pm

mikrotik team, no matter how long it takes, ios, junos does not have a weekly update, more are stable, the important thing is that the software stays stable,
so keep it up

upower3 · Wed Dec 06, 2017 3:07 pm

mikrotik team, no matter how long it takes, ios, junos does not have a weekly update, more are stable, the important thing is that the software stays stable,
so keep it up 8)

Given that routine current update about to introduce new bridge implementation that potentially break router config (and even downgrade won't help since the config will be already broken by autoconvert process), I won't call it "stable" or vote for keeping it up, actually.

What I'd vote for it to have one notable release (maybe even 7.00?) with only and just this bridge implementation and other ongoing releases (6.41, 642 etc) with other changes and fixes. Just to be on the safe side.

May I also add up, remember how MT once broken their dyndns server for the whole newyear's holidays until someone came to Riga's office and turn it on? I can imagine pre-new-year release with this bridge implementation that will break you devices so you'll have warm and nice new year eve visiting each of your remote device personally :)

Wed Dec 06, 2017 3:10 pm

+1 for upower3's idea of ROS 7.00.

juliokato · Wed Dec 06, 2017 3:19 pm

Dear mikrotik, why has development slowed down? In the past we used to see a new rc every 3-5 days.
Good point

Maybe freezing due to the holidays at the end of the year?
Many companies do this.

upower3 · Wed Dec 06, 2017 3:28 pm

Dear mikrotik, why has development slowed down? In the past we used to see a new rc every 3-5 days.
Good point :?
Maybe freezing due to the holidays at the end of the year?
Many companies do this.

Posting some roadmap for hardware development and also for ROS development would be nice replacement for new ROS release.

I'd like to know where MT will go next year or two, should we expect it on enterprise market (yes, with enterprise-class equipment), or it'll target on SOHO, low-cost ISP's and home markets? Which models can we rely on, which ROS features planned to be be further developed? MT used to introduce nice devices, but they looks merely like proof of concept sometimes. Say, no enterprise will even get many switches unless they'll be promised these devices won't be abandoned for years.

Personally, I'd like to see stacking for switches. I'd also would like to see Metarouter back, maybe even for routers with x86/x64 architecture (two PSU, fanless and quiet) so I can put it in the remote office and run some Asterisk on it - nice idea, isn't it?

But looks like eveyone at MT is at conferences now, or maybe went to Bali to have some rest. Strange, this time of the year is hot for sales and for marketing, isn't it?

Wed Dec 06, 2017 3:32 pm

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

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

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

Changes since previous 6.41rc release:

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

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

Cha0s · Wed Dec 06, 2017 3:44 pm

I agree with upower3. A roadmap for software and hardware development would be most welcome.

Knowing where MikroTik is heading is essential when investing in their hardware (and subsequently in their software).

Wed Dec 06, 2017 4:04 pm

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

In Poland we say: "Hit the table and the scissors will make a sound"

upower3 · Wed Dec 06, 2017 4:14 pm

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

Please explain the process of transformation. Say if I have eth2 as Master-port, and eth3..eth5 as Slaves, and used eth2 in firewall rule, will this rule be changes to one that will use newly-created bridge? Will IP be reassigned from master port to bridge create from these master and its slave ports?

Important questions, when it comes to upgrade! Even if we go with manual changing (tuning) of existing configuration so we'll be sure we can go with upgrade to 6.41, I'd really love to know the auto-convert algorithm.

ErfanDL · Wed Dec 06, 2017 4:17 pm

What are you doing MTK ?! release the stable version ! not spam version's

nkourtzis · Wed Dec 06, 2017 4:19 pm

Dears at Mikrotik,

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

I am sure many will second me on this point.

Cha0s · Wed Dec 06, 2017 4:21 pm

or at least make the ROS upgrade process to automatically upgrade Routerboot also.

+1

upower3 · Wed Dec 06, 2017 4:22 pm

without knowing whether there are any changes in the version or not, is not ideal.

Mostly there are no changes for all but really new devices or hardware. The only thing you might need this upgrade is when you add new hardware (like SFP module) or you can see you MT works unusually bad.

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

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

You can also do really good thing by simple posting Changelogs for f/w with explanation who should care for (like "this f/w release used to support new 10G SFP module named ABC123, so don't care if you're not using it").

kometchtech · Wed Dec 06, 2017 4:25 pm

*) capsman - use "adaptive-noise-immunity" value from CAP local configuration;

I'd like to know a bit more about this change.
Although "adaptive-noise-immunity" is read from CAP, it is correct by recognizing that setting value at that time will be read by setting with CAP Wireless beforehand and then activating Manager Is it?

juliokato · Wed Dec 06, 2017 4:54 pm

or at least make the ROS upgrade process to automatically upgrade Routerboot also.
+1

ok, but how is the process downgrade?

Wed Dec 06, 2017 5:23 pm

*) capsman - use "adaptive-noise-immunity" value from CAP local configuration;
I'd like to know a bit more about this change.

I believe this is similar to how antenna gain setting is being handled. Simply set the desired value of the adaptive-noise-immunity option in your radio interface configuration before turning CAP mode on, and that value will be used for this particular radio when you join it to your CAPs manager.

raffav · Wed Dec 06, 2017 5:29 pm

any one figure out how to set up this:

"firewall - added "tls-host" firewall matcher "

kmok1 · Wed Dec 06, 2017 5:50 pm

I have been testing the RC version on an RB750. If I goto / system routerboard, upgrade-firmware has been blank in the past several RC releases. Is this the new norm?

kometchtech · Thu Dec 07, 2017 2:28 am

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

Thank you for the information.

Do you know what kind of method to confirm that this setting is valid?
If you are okay, can you tell me about the way?

Grickos · Thu Dec 07, 2017 6:42 pm

The DHCP server does not work properly.
DNS was set up
/ ip dhcp-server network
add address = 192.168.0.0 / 24 dns-server = 192.168.0.1 gateway = 192.168.0.1.
It behaves as if it was not assigned a DNS server. Assigns addresses that are entered in / ip dns.

freemannnn · Thu Dec 07, 2017 6:49 pm

my dns server (ip-dns) where lost after upgrade to rc61

RafGan · Thu Dec 07, 2017 7:31 pm

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

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

New bugs?

fanMikroTik · Fri Dec 08, 2017 11:37 am

MK,

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

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

viewtopic.php?t=102908

Son1c · Fri Dec 08, 2017 12:00 pm

MK,

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

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

viewtopic.php?t=102908

+1

linek1980 · Sat Dec 09, 2017 3:56 pm

MK,

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

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

viewtopic.php?t=102908

+1 it must be repaired

noyo · Sat Dec 09, 2017 4:03 pm

MK,

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

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

viewtopic.php?t=102908

+1

zajadacz · Sat Dec 09, 2017 11:46 pm

MK,

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

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

viewtopic.php?t=102908

+1

Ryan207 · Sun Dec 10, 2017 11:10 am

As RafGan mentioned...the bridge ports disappear.

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

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