Community discussions

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

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

Wed Oct 11, 2017 10:27 pm

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

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

Thu Oct 12, 2017 12:20 am

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

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

Thu Oct 12, 2017 3:00 am

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

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

Thu Oct 12, 2017 10:16 am

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

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

Thu Oct 12, 2017 11:06 am

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

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

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

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

Thu Oct 12, 2017 2:52 pm

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

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

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

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

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

But how do I reach R2 itself on VLAN3 ?

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

How can I reach R2 via VLAN3?!?

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

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

Fri Oct 13, 2017 1:32 am

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

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

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

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

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

But how do I reach R2 itself on VLAN3 ?

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

How can I reach R2 via VLAN3?!?

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

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

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

Fri Oct 13, 2017 11:06 am

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

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

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

Fri Oct 13, 2017 11:18 am

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

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

Fri Oct 13, 2017 12:34 pm

This Version is really bad on my hapac capsman:

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

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

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

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

Fri Oct 13, 2017 1:13 pm

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

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

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

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

Fri Oct 13, 2017 1:39 pm

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

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

Fri Oct 13, 2017 3:43 pm

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

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

Fri Oct 13, 2017 4:06 pm

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

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

Fri Oct 13, 2017 5:36 pm

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

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

Fri Oct 13, 2017 6:36 pm

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

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

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

Mon Oct 16, 2017 9:03 am

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

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

Mon Oct 16, 2017 1:27 pm

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

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

Mon Oct 16, 2017 3:02 pm

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

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

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

Mon Oct 16, 2017 3:18 pm

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

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

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

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

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

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

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

Mon Oct 16, 2017 4:22 pm

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

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

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

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

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

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

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

Mon Oct 16, 2017 5:23 pm

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

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

Tue Oct 17, 2017 4:04 pm

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

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

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

Tue Oct 17, 2017 5:00 pm

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

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

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

Thu Oct 19, 2017 12:42 pm

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

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


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

Changes since previous 6.41rc release:

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

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

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

Thu Oct 19, 2017 5:41 pm

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

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

Thu Oct 19, 2017 5:49 pm

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

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

Thu Oct 19, 2017 5:54 pm

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

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

Thu Oct 19, 2017 5:58 pm

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

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

Thu Oct 19, 2017 6:00 pm

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

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

Thu Oct 19, 2017 7:22 pm

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

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

Thu Oct 19, 2017 9:45 pm

Mikrotik team

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

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

Thu Oct 19, 2017 10:49 pm

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

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

Fri Oct 20, 2017 2:26 am

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

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

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

Fri Oct 20, 2017 3:18 am

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

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

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

Fri Oct 20, 2017 9:43 am

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

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

I go back to the current firmware 6.40.4.

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

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

Fri Oct 20, 2017 10:09 am

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

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

I go back to the current firmware 6.40.4.

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

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

Fri Oct 20, 2017 11:24 am

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

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

Fri Oct 20, 2017 1:09 pm

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

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

I go back to the current firmware 6.40.4.

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

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

Fri Oct 20, 2017 1:30 pm

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

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

Fri Oct 20, 2017 2:11 pm

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

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

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

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

Fri Oct 20, 2017 3:09 pm

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

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

Fri Oct 20, 2017 6:19 pm

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

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

Fri Oct 20, 2017 7:00 pm

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

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

Sat Oct 21, 2017 8:15 am

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

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

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

Sun Oct 22, 2017 1:46 am

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

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

Sun Oct 22, 2017 2:00 pm

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

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

Mon Oct 23, 2017 9:37 am

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

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

Mon Oct 23, 2017 8:24 pm

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

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

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

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

Tue Oct 24, 2017 9:11 am

Hi

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

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

Another problem

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

What could be a problem?


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

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

Tue Oct 24, 2017 5:46 pm

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

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

Wed Oct 25, 2017 3:28 pm

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

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

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

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

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

Thu Oct 26, 2017 10:18 am

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

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

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

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

Thu Oct 26, 2017 10:27 am

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

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

Thu Oct 26, 2017 1:05 pm

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

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

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

Fri Oct 27, 2017 8:43 pm

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

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

Sat Oct 28, 2017 9:15 am

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

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

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

Sat Oct 28, 2017 7:02 pm

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

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

Sat Oct 28, 2017 7:14 pm

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

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

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

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

Sun Oct 29, 2017 7:17 pm

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

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

Mon Oct 30, 2017 6:00 pm

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

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

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

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

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

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

Mon Oct 30, 2017 6:57 pm

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

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

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

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

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

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

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

Wed Nov 01, 2017 1:26 am

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

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

Wed Nov 01, 2017 3:04 pm

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

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


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

Changes since previous 6.41rc release:

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

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

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

Wed Nov 01, 2017 7:40 pm

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

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

Thu Nov 02, 2017 3:26 am

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

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

Thu Nov 02, 2017 6:07 am

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

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

Thu Nov 02, 2017 8:03 am


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

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

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

Thu Nov 02, 2017 12:50 pm

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

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

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

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

Thu Nov 02, 2017 1:18 pm

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

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

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

Thu Nov 02, 2017 5:46 pm

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

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

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

Thu Nov 02, 2017 6:14 pm

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

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

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

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

Thu Nov 02, 2017 6:20 pm

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

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

Thu Nov 02, 2017 7:25 pm

Hi,

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

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

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

Thu Nov 02, 2017 9:38 pm

Hi,

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

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

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

Thu Nov 02, 2017 9:40 pm

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

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

Fri Nov 03, 2017 7:33 am

When would the final version to be released?

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

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

Fri Nov 03, 2017 2:49 pm

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

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

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

Fri Nov 03, 2017 4:00 pm

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

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

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

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

Fri Nov 03, 2017 4:27 pm

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

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

Fri Nov 03, 2017 10:26 pm

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

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

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

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

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

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

Fri Nov 03, 2017 10:44 pm

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

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

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

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

Fri Nov 03, 2017 10:52 pm

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

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

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

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

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

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

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

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

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

New bridge keeps IP addresses up

Sat Nov 04, 2017 12:32 am

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

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

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

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

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

Sat Nov 04, 2017 1:08 am

Has the routerboot firmware version naming changed in 6.41rc?

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

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

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

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

Sat Nov 04, 2017 11:49 am

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

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

Sat Nov 04, 2017 2:48 pm

I missed that entry in the changelog :oops:

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

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

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

Sat Nov 04, 2017 7:48 pm

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

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

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

Sat Nov 04, 2017 7:56 pm

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

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

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

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

Sun Nov 05, 2017 2:09 am

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

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

Sun Nov 05, 2017 7:32 am

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

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

Mon Nov 06, 2017 8:50 pm

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

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

Tue Nov 07, 2017 2:33 pm

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

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

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

Tue Nov 07, 2017 2:38 pm

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

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

Tue Nov 07, 2017 3:20 pm

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

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


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

Changes since previous 6.41rc release:

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

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

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

Tue Nov 07, 2017 3:41 pm

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

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

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

Tue Nov 07, 2017 3:51 pm

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

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

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

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

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

Tue Nov 07, 2017 5:21 pm

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

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


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

Changes since previous 6.41rc release:

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

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

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

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

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

Tue Nov 07, 2017 11:34 pm

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

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

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

Wed Nov 08, 2017 12:18 am

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

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

Wed Nov 08, 2017 6:44 pm

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

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

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

Wed Nov 08, 2017 7:49 pm

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

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

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

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

Wed Nov 08, 2017 10:44 pm

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

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

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

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

Fri Nov 10, 2017 11:34 am

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

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

Fri Nov 10, 2017 1:06 pm

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

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

Sat Nov 11, 2017 5:00 am

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

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

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

Sun Nov 12, 2017 3:38 pm

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

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

Mon Nov 13, 2017 10:37 am

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

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

Mon Nov 13, 2017 6:36 pm

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

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

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

Mon Nov 13, 2017 6:53 pm

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

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

Tue Nov 14, 2017 12:09 pm

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

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

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

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

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

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

Tue Nov 14, 2017 7:47 pm

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

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

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

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

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

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

Tue Nov 14, 2017 10:03 pm

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

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

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

Wed Nov 15, 2017 12:05 am

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

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

Wed Nov 15, 2017 1:03 am

Been a long day.

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

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

Simply reverting to 6.40.5 gave me good stable expected rates.

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

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

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

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

Wed Nov 15, 2017 7:15 pm

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

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

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

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

Wed Nov 15, 2017 8:28 pm

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

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

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

Thu Nov 16, 2017 11:34 am

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

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

Thu Nov 16, 2017 11:53 am

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

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

Thu Nov 16, 2017 11:49 pm

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

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

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

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

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

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

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

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

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

Fri Nov 17, 2017 10:38 am

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

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

Fri Nov 17, 2017 11:48 am

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

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

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

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

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

Fri Nov 17, 2017 12:03 pm

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

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

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

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

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

Fri Nov 17, 2017 12:35 pm

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

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

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

Fri Nov 17, 2017 9:48 pm

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

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

Fri Nov 17, 2017 10:00 pm

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

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

Sat Nov 18, 2017 4:58 am

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

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

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

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

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

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

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

Sat Nov 18, 2017 5:39 pm

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

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

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

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

Sat Nov 18, 2017 10:12 pm

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

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

Sun Nov 19, 2017 3:09 am

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

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

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

Sun Nov 19, 2017 11:24 am

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

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

Sun Nov 19, 2017 9:05 pm

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

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

Sun Nov 19, 2017 11:54 pm

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

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

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

Mon Nov 20, 2017 7:18 pm

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

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

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

Mon Nov 20, 2017 11:10 pm

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

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

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

Tue Nov 21, 2017 1:19 am

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

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

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

Tue Nov 21, 2017 4:20 am

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

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

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

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

Fri Nov 24, 2017 3:09 pm

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

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


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

Changes since previous 6.41rc release:

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

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

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

Fri Nov 24, 2017 3:14 pm

*) firewall - added "tls-host" firewall matcher (CLI only);
Sweet. No more Layer 7 for HTTPS blocking :)
How it works? Which packet matches? Does it support wildcards?
Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

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

MikroTik. Your life. Your routing.
 
User avatar
pietroscherer
Trainer
Trainer
Posts: 170
Joined: Thu Mar 05, 2015 3:05 pm
Location: RS, Brazil
Contact:

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

Fri Nov 24, 2017 3:24 pm

*) firewall - added "tls-host" firewall matcher (CLI only);
Sweet. No more Layer 7 for HTTPS blocking :)
How it works? Which packet matches? Does it support wildcards?
+1 :D
Pietro Scherer
http://www.tchesolutions.com.br [ISPs Consulting and Training]
http://www.routermage.com [Backup and Automation System]
:D
 
pe1chl
Forum Guru
Forum Guru
Posts: 5913
Joined: Mon Jun 08, 2015 12:09 pm

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

Fri Nov 24, 2017 4:23 pm

*) firewall - added "tls-host" firewall matcher (CLI only);
Sweet. No more Layer 7 for HTTPS blocking :)
How it works? Which packet matches? Does it support wildcards?
I presume this is just a special case of a Layer 7 with some pre-defined pattern, and only works when SNI is used.
 
User avatar
Cha0s
Forum Veteran
Forum Veteran
Posts: 907
Joined: Tue Oct 11, 2005 4:53 pm

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

Fri Nov 24, 2017 4:27 pm

*) firewall - added "tls-host" firewall matcher (CLI only);
Sweet. No more Layer 7 for HTTPS blocking :)
How it works? Which packet matches? Does it support wildcards?
I presume this is just a special case of a Layer 7 with some pre-defined pattern, and only works when SNI is used.
It could be an iptables module specific to that function instead of abstracting a L7 filter. Like this https://github.com/Lochnair/xt_tls
 
User avatar
honzam
Forum Guru
Forum Guru
Posts: 2292
Joined: Wed Feb 27, 2008 10:27 pm
Location: Czech Republic

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

Fri Nov 24, 2017 4:46 pm

*) wireless - added passive scan option for wireless scan mode;
Any info about this? passive scan has been implemented for a long time
LAN, FTTx, Wireless. ISP operator
 
troffasky
Member
Member
Posts: 399
Joined: Wed Mar 26, 2014 4:37 pm

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

Sat Nov 25, 2017 12:53 am

*) firewall - added "tls-host" firewall matcher (CLI only);
Sweet. No more Layer 7 for HTTPS blocking :)
How it works? Which packet matches? Does it support wildcards?
I presume this is just a special case of a Layer 7 with some pre-defined pattern, and only works when SNI is used.
No need for SNI, CN of certificate is in plaintext whether SNI is used or not.
 
bjornr
just joined
Posts: 23
Joined: Thu Apr 16, 2015 11:00 am

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

Sat Nov 25, 2017 12:59 am

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

Don't know exactly what caused this, but if it helps identifying the issue I'm employing VLANs, bonding interfaces, and DHCP relaying. Configs or supout can be available upon request.
 
Paternot
Long time Member
Long time Member
Posts: 607
Joined: Thu Jun 02, 2016 4:01 am
Location: Niterói / Brazil

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

Sat Nov 25, 2017 3:28 am

*) wireless - added passive scan option for wireless scan mode;
Any info about this? passive scan has been implemented for a long time
It's not clear, from the changelog, but: If I remember it right, Mikrotik didn't support passive scan with 802.11ac, only b, g, n. Maybe this is it, at long last. :D
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 1820
Joined: Mon Jan 14, 2008 1:53 pm
Location: Straya
Contact:

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

Sat Nov 25, 2017 11:47 am

*) firewall - added "tls-host" firewall matcher (CLI only);
Sweet. No more Layer 7 for HTTPS blocking :)
How it works? Which packet matches? Does it support wildcards?
At a guess, its based on xt_tls which can support wildcards, see https://github.com/Lochnair/xt_tls
http://thebrotherswisp.com/ | Mikrotik MTCNA, MTCRE, MTCINE | Fortinet FTCNA, FCNSP, FCT | Extreme Networks ENA
 
nkourtzis
Member Candidate
Member Candidate
Posts: 206
Joined: Tue Dec 11, 2012 12:56 am
Location: Greece

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

Mon Nov 27, 2017 12:24 pm

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

No trees were killed to send this message,
but a large number of electrons were terribly inconvenienced.
 
nkourtzis
Member Candidate
Member Candidate
Posts: 206
Joined: Tue Dec 11, 2012 12:56 am
Location: Greece

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

Tue Nov 28, 2017 3:07 pm

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

Can it possibly be that we approaching the end of v6 development? Just wondering...
Passionate about networks
Enthusiastic about Mikrotik
MTCNA | MTCRE | MTCINE

No trees were killed to send this message,
but a large number of electrons were terribly inconvenienced.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5913
Joined: Mon Jun 08, 2015 12:09 pm

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

Tue Nov 28, 2017 3:28 pm

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

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

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

Tue Nov 28, 2017 8:12 pm

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

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

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

Wed Nov 29, 2017 11:04 pm

New bridge implementation need:

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

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

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

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

Thu Nov 30, 2017 12:51 am

New bridge implementation need:

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

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

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

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

Thu Nov 30, 2017 11:35 am

New bridge implementation need:

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

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

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

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

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

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

Thu Nov 30, 2017 11:56 am

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

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

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

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

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

Fri Dec 01, 2017 10:58 am

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

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

Fri Dec 01, 2017 11:11 am

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

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

Fri Dec 01, 2017 11:37 am

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

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

Fri Dec 01, 2017 4:48 pm

Hello!

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


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

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

Mon Dec 04, 2017 12:14 pm

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

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

Mon Dec 04, 2017 2:27 pm

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

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

Mon Dec 04, 2017 2:44 pm

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

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

Mon Dec 04, 2017 2:54 pm

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

Enviado de meu XT1580 usando Tapatalk

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

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

Mon Dec 04, 2017 4:33 pm

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

Enviado de meu XT1580 usando Tapatalk
Maybe renaming the V6.41RC to V7, since they introduced many new features. 8)
I apologize my grammatical errors, my english not so good, I am not a native speaker.
Wiki is maintained in English. I use Google translator. 8)
 
jarda
Forum Guru
Forum Guru
Posts: 7604
Joined: Mon Oct 22, 2012 4:46 pm

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

Mon Dec 04, 2017 4:56 pm

V7 should have new kernel and totally new implementation of some functionalities. Do not skip so far...
 
pe1chl
Forum Guru
Forum Guru
Posts: 5913
Joined: Mon Jun 08, 2015 12:09 pm

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

Mon Dec 04, 2017 5:55 pm

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

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

Mon Dec 04, 2017 6:00 pm

V7 should have new kernel and totally new implementation of some functionalities. Do not skip so far...
That is never going to work! They need to separate some of the changes into subreleases and packages, including RC versions, or this version is never going to materialize.
I vote for releasing a V7 based on 6.41RC with a new kernel (first as an RC), then make that a "current" version and await the reports of all the new minor problems, then (or partly in parallel) release all the "totally new implementations of some functionalities" as optional packages like it was done before with wireless and routing.
So the people interested in new functionality and prepared to be confronted with some bugs can test in parallel with the baseline users.
What's actually the issue having 6.41 with the new bridge implementation? If it works it works...
 
WojtusW5
Frequent Visitor
Frequent Visitor
Posts: 64
Joined: Mon Oct 02, 2017 1:25 pm

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

Mon Dec 04, 2017 6:32 pm

Hi, small off-top when 6.41 will be as current version ?
Is there an initial deadline ?
I invite you to visit my blog
https://mikrotikon.pl/
 
pe1chl
Forum Guru
Forum Guru
Posts: 5913
Joined: Mon Jun 08, 2015 12:09 pm

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

Mon Dec 04, 2017 7:16 pm

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

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

Mon Dec 04, 2017 7:26 pm

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

In any case... seeing the slow progress as of late is worry-some.. a feeling says that maybe they've hid a roadblock in the development... maybe just a false feeling, but in any case its really unusual.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5913
Joined: Mon Jun 08, 2015 12:09 pm

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

Mon Dec 04, 2017 8:35 pm

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

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

Wed Dec 06, 2017 10:07 am

Dear mikrotik, why has development slowed down? In the past we used to see a new rc every 3-5 days.
Good point :?
Image Image
 
jondavy
Member Candidate
Member Candidate
Posts: 127
Joined: Tue May 12, 2009 11:14 pm
Location: Brasil

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

Wed Dec 06, 2017 2:57 pm

mikrotik team, no matter how long it takes, ios, junos does not have a weekly update, more are stable, the important thing is that the software stays stable,
so keep it up 8)
 
upower3
Member
Member
Posts: 384
Joined: Thu May 07, 2015 11:46 am

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

Wed Dec 06, 2017 3:07 pm

mikrotik team, no matter how long it takes, ios, junos does not have a weekly update, more are stable, the important thing is that the software stays stable,
so keep it up 8)
Given that routine current update about to introduce new bridge implementation that potentially break router config (and even downgrade won't help since the config will be already broken by autoconvert process), I won't call it "stable" or vote for keeping it up, actually.

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

May I also add up, remember how MT once broken their dyndns server for the whole newyear's holidays until someone came to Riga's office and turn it on? I can imagine pre-new-year release with this bridge implementation that will break you devices so you'll have warm and nice new year eve visiting each of your remote device personally :)
 
User avatar
BartoszP
Forum Guru
Forum Guru
Posts: 1717
Joined: Mon Jun 16, 2014 1:13 pm
Location: Poland

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

Wed Dec 06, 2017 3:10 pm

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

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

Wed Dec 06, 2017 3:19 pm

Dear mikrotik, why has development slowed down? In the past we used to see a new rc every 3-5 days.
Good point :?
Maybe freezing due to the holidays at the end of the year?
Many companies do this.
I apologize my grammatical errors, my english not so good, I am not a native speaker.
Wiki is maintained in English. I use Google translator. 8)
 
upower3
Member
Member
Posts: 384
Joined: Thu May 07, 2015 11:46 am

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

Wed Dec 06, 2017 3:28 pm

Dear mikrotik, why has development slowed down? In the past we used to see a new rc every 3-5 days.
Good point :?
Maybe freezing due to the holidays at the end of the year?
Many companies do this.
Posting some roadmap for hardware development and also for ROS development would be nice replacement for new ROS release.

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

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

But looks like eveyone at MT is at conferences now, or maybe went to Bali to have some rest. Strange, this time of the year is hot for sales and for marketing, isn't it?
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1409
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Wed Dec 06, 2017 3:32 pm

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

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


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

Changes since previous 6.41rc release:

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

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after crash.
 
User avatar
Cha0s
Forum Veteran
Forum Veteran
Posts: 907
Joined: Tue Oct 11, 2005 4:53 pm

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

Wed Dec 06, 2017 3:44 pm

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

Knowing where MikroTik is heading is essential when investing in their hardware (and subsequently in their software).
 
User avatar
BartoszP
Forum Guru
Forum Guru
Posts: 1717
Joined: Mon Jun 16, 2014 1:13 pm
Location: Poland

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

Wed Dec 06, 2017 4:04 pm

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

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

Wed Dec 06, 2017 4:14 pm

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

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

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

Wed Dec 06, 2017 4:17 pm

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

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

Wed Dec 06, 2017 4:19 pm

Dears at Mikrotik,

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

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

No trees were killed to send this message,
but a large number of electrons were terribly inconvenienced.
 
User avatar
Cha0s
Forum Veteran
Forum Veteran
Posts: 907
Joined: Tue Oct 11, 2005 4:53 pm

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

Wed Dec 06, 2017 4:21 pm

or at least make the ROS upgrade process to automatically upgrade Routerboot also.
+1
 
upower3
Member
Member
Posts: 384
Joined: Thu May 07, 2015 11:46 am

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

Wed Dec 06, 2017 4:22 pm

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

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

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

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

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

Wed Dec 06, 2017 4:25 pm

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

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

Wed Dec 06, 2017 4:54 pm

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

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

Wed Dec 06, 2017 5:23 pm

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

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

Wed Dec 06, 2017 5:29 pm

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

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

Wed Dec 06, 2017 5:50 pm

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

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

Thu Dec 07, 2017 2:28 am

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

Thank you for the information.

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

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

Thu Dec 07, 2017 6:42 pm

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

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

Thu Dec 07, 2017 6:49 pm

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

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

Thu Dec 07, 2017 7:31 pm

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

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

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

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

Fri Dec 08, 2017 11:37 am

MK,

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

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

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

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

Fri Dec 08, 2017 12:00 pm

MK,

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

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

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

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

Sat Dec 09, 2017 3:56 pm

MK,

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

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

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

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

Sat Dec 09, 2017 4:03 pm

MK,

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

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

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

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

Sat Dec 09, 2017 11:46 pm

MK,

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

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

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

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

Sun Dec 10, 2017 11:10 am

As RafGan mentioned...the bridge ports disappear.

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

I use connection marking then packet marking for my QoS setup, what changed in rc61 to break this or require a new config? Worked fine in rc56.
 
Ryan207
just joined
Posts: 2
Joined: Sun Dec 10, 2017 10:45 am

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

Sun Dec 10, 2017 3:51 pm

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

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

Mon Dec 11, 2017 9:00 am

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

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

New bugs?
Do you have support output files from older RC where the static bridge ports were working ok? Did you make a new support output file after the upgrade where the bridge ports disappeared?

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

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

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

Mon Dec 11, 2017 1:29 pm

Hi Guys,

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

My network
Image

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

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

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

Mon Dec 11, 2017 1:42 pm

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

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

Mon Dec 11, 2017 2:35 pm

Hi bjornr,

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

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

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

Mon Dec 11, 2017 2:52 pm

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

(Edit: Fixed BBCode markup)
 
RafGan
newbie
Posts: 29
Joined: Mon Jun 06, 2011 6:17 pm
Location: Poland / Silesia

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

Tue Dec 12, 2017 12:57 am

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

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

New bugs?
Do you have support output files from older RC where the static bridge ports were working ok? Did you make a new support output file after the upgrade where the bridge ports disappeared?

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

Send all that info to support@mikrotik.com

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

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

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

Tue Dec 12, 2017 11:54 am

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

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

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

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

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

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

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

Tue Dec 12, 2017 12:00 pm

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

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

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

Tue Dec 12, 2017 4:46 pm

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

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

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

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

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

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

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

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

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

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

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

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

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

Tue Dec 12, 2017 8:51 pm

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

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

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

Wed Dec 13, 2017 10:16 am

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

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

Wed Dec 13, 2017 10:38 am

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

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

Wed Dec 13, 2017 12:10 pm

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

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

Wed Dec 13, 2017 5:34 pm

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

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

Wed Dec 13, 2017 5:36 pm

Support,

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

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

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

Wed Dec 13, 2017 6:21 pm

Support,

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

Thank you,
Planetcoop
So is this list of DNS servers configured in the DHCP Networks for this DHCP Server/Pool? I'm running a couple systems on 6.41rc61 and have DHCP Servers on two interfaces that assign DNS to the clients. I'm not having an issue with it.
 
RafGan
newbie
Posts: 29
Joined: Mon Jun 06, 2011 6:17 pm
Location: Poland / Silesia

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

Wed Dec 13, 2017 10:12 pm

Support,

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

Thank you,
Planetcoop

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

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

Thu Dec 14, 2017 2:28 am

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

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

New bugs?
Do you have support output files from older RC where the static bridge ports were working ok? Did you make a new support output file after the upgrade where the bridge ports disappeared?

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

Send all that info to support@mikrotik.com

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

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

For me, the ports in the first switch chip that I had configured remained (2 and 3) but those in the second went away (5-9) on a 3011. Not sure if that is helpful information for you Uldis?
-----
Alex Hart

The Brothers WISP
 
planetcoop
Member Candidate
Member Candidate
Posts: 115
Joined: Thu May 15, 2014 2:32 pm
Location: Sacramento, CA

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

Thu Dec 14, 2017 2:32 am

Support,

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

Thank you,
Planetcoop

See topic at link viewtopic.php?f=1&t=128454
yup, that is the issue....
 
kait
just joined
Posts: 15
Joined: Thu May 10, 2012 12:09 pm
Location: Czech Republic

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

Thu Dec 14, 2017 5:17 pm

Hi,

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

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

/interface bridge port
add bridge=bridge1 interface=sfpplus1

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

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

/interface bridge
set bridge1 vlan-filtering=yes

### CRS226 ###

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

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

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

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

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

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

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

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

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

Thu Dec 14, 2017 8:31 pm

Hi,

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

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

Pavel
While not directly answering your question. Please do not use overlapping IP space for your VPN. I know some of the wiki articles set it up that way. By changing to a non overlapping IP space it will just work, no Proxy-ARP magic needed.
 
kait
just joined
Posts: 15
Joined: Thu May 10, 2012 12:09 pm
Location: Czech Republic

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

Thu Dec 14, 2017 8:42 pm

Hi,

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

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

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

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

Pavel
 
kait
just joined
Posts: 15
Joined: Thu May 10, 2012 12:09 pm
Location: Czech Republic

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

Fri Dec 15, 2017 11:18 am

Hi,

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

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

/interface bridge port
add bridge=bridge1 interface=sfpplus1

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

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

/interface bridge
set bridge1 vlan-filtering=yes

### CRS226 ###

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

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

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

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

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

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

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

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

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

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

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

Fri Dec 15, 2017 1:55 pm

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

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


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

Changes since previous 6.41rc release:

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

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

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

Fri Dec 15, 2017 2:03 pm

*) dhcp-server - added basic RADIUS accounting;
Wow!.. What does it account?
Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

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

MikroTik. Your life. Your routing.
 
msatter
Forum Guru
Forum Guru
Posts: 1281
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

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

Fri Dec 15, 2017 4:06 pm

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

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

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

I have a autosupout.rif file will e-mail that to support.
Two RB760iGS (hEX S) in series. One does PPPoE and both do IKEv2.
Running:
RouterOS 6.46Beta59 / Winbox 3.20 / MikroTik APP 1.3.7
Having an Android device, use https://github.com/M66B/NetGuard/releases (no root required)
 
Grickos
newbie
Posts: 32
Joined: Thu Aug 06, 2015 2:57 am

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

Fri Dec 15, 2017 5:17 pm

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

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

Fri Dec 15, 2017 5:50 pm

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

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

Fri Dec 15, 2017 6:21 pm

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

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

Fri Dec 15, 2017 10:07 pm

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

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

Sun Dec 17, 2017 12:07 am

v6.41rc61 and v6.41rc66

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

in nstreme not connecting to ap. In NV2 is ok. Other RB SXT is connecting ok in nstreme.
 
RafGan
newbie
Posts: 29
Joined: Mon Jun 06, 2011 6:17 pm
Location: Poland / Silesia

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

Sun Dec 17, 2017 1:41 am

DHCP server, DNS setings still does not work.

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

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

Sun Dec 17, 2017 3:31 am

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

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

Mon Dec 18, 2017 8:29 am

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

We are not being able to reproduce such problem between two RouterOS devices. If DHCP client is not receiving/adding DHCP parameters, then this must be something specific and in order to fix this we need to see this on an actual example.
 
RafGan
newbie
Posts: 29
Joined: Mon Jun 06, 2011 6:17 pm
Location: Poland / Silesia

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

Mon Dec 18, 2017 10:57 am

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

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


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

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

Mon Dec 18, 2017 11:05 am

*) ipsec - improved hardware accelerated IPSec performance on 750Gr3;
Can you tell me more about this?
Linux/network engineer: ITIL, LPI1, CCNA R+S, CCNP R+S, JNCIA, JNCIS-SEC
 
JimmyNyholm
Member Candidate
Member Candidate
Posts: 249
Joined: Mon Apr 25, 2016 2:16 am
Location: Sweden

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

Mon Dec 18, 2017 11:13 am

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

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

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

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

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

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

Mon Dec 18, 2017 6:33 pm

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

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

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

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

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

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

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

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

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

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

Mon Dec 18, 2017 8:03 pm

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

When I put a heavy load on IPSEC by using several connections the load is not distributed and the first core goes to 100% and the fourth sometimes follows. I hoped this change would distribute the load better.
Two RB760iGS (hEX S) in series. One does PPPoE and both do IKEv2.
Running:
RouterOS 6.46Beta59 / Winbox 3.20 / MikroTik APP 1.3.7
Having an Android device, use https://github.com/M66B/NetGuard/releases (no root required)
 
RafGan
newbie
Posts: 29
Joined: Mon Jun 06, 2011 6:17 pm
Location: Poland / Silesia

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

Mon Dec 18, 2017 8:19 pm

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Mon Dec 18, 2017 8:44 pm

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

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

Mon Dec 18, 2017 9:38 pm

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

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

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

Best regards,
Martins S.
-----------------------------------------------
They're just trying to achieve feature parity with the RADNSS "functionality" in IPv6. :roll:
When given a spoon,
you should not cling to your fork.
The soup will get cold.
 
RafGan
newbie
Posts: 29
Joined: Mon Jun 06, 2011 6:17 pm
Location: Poland / Silesia

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

Mon Dec 18, 2017 11:06 pm

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

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

Tue Dec 19, 2017 10:00 am

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

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

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

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

Tue Dec 19, 2017 11:18 am

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

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

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

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

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

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

Tue Dec 19, 2017 11:47 am

I tried to run this version on my 750Gr3 but became totally unreachable after a few minutes.

When I put a heavy load on IPSEC by using several connections the load is not distributed and the first core goes to 100% and the fourth sometimes follows. I hoped this change would distribute the load better.
The fix addresses exactly this issue. Were you able to recover the router after the loss of reachability? Are you able to reproduce the issue somehow?
My ticket number is: 2017121522004034 and I sent in an autosupport and support file

It crashed twice and a third time is expected when I update again from 6.40.5.

The router restarts and no normal way to connect. Even a notebook connected directly does not see a network.
Two RB760iGS (hEX S) in series. One does PPPoE and both do IKEv2.
Running:
RouterOS 6.46Beta59 / Winbox 3.20 / MikroTik APP 1.3.7
Having an Android device, use https://github.com/M66B/NetGuard/releases (no root required)
 
User avatar
eworm
Member
Member
Posts: 402
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Dec 19, 2017 2:30 pm

Successfully updated a CRS109-8G-1S-2HnD to version 6.41rc66, then installed the firmware update to version 6.41rc65 and rebooted. Now the device is stuck at 'staring services', which is displayed on the lcd display. No link on interfaces...
Anybody seen this? Is there any chance to recover without reset?
Manage RouterOS scripts and extend your devices' functionality: RouterOS Scripts
 
User avatar
kometchtech
Member Candidate
Member Candidate
Posts: 194
Joined: Sat Jun 15, 2013 4:25 am
Location: Japan
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Dec 19, 2017 2:37 pm

Successfully updated a CRS109-8G-1S-2HnD to version 6.41rc66, then installed the firmware update to version 6.41rc65 and rebooted. Now the device is stuck at 'staring services', which is displayed on the lcd display. No link on interfaces...
Anybody seen this? Is there any chance to recover without reset?
If you can make a serial connection, you can check the boot process ...
Perhaps, there is no way to recover only by netinstall.
--
Routerboard Users Group JP
http://www.rb-ug.jp/
CCR1009-8G-1S-1S+, RB750Gr3, CRS226-24G-2S+, RB850Gx2, RB960PGS, CRS317-1G-16S+,
RB2011UAS, CRS125-24G-1S, RB962UiGS-5HacT2HnT, CRS212-1G-10S-1S+, RB3011UiAS
 
User avatar
eworm
Member
Member
Posts: 402
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Dec 19, 2017 3:05 pm

Successfully updated a CRS109-8G-1S-2HnD to version 6.41rc66, then installed the firmware update to version 6.41rc65 and rebooted. Now the device is stuck at 'staring services', which is displayed on the lcd display. No link on interfaces...
Anybody seen this? Is there any chance to recover without reset?
If you can make a serial connection, you can check the boot process ...
Perhaps, there is no way to recover only by netinstall.
I connected a serial cable and messages are shown at boot time:
RouterBOOT booter 6.41rc65

CRS109-8G-1S-2HnD

CPU frequency: 600 MHz
 Memory speed: 200 MHz
  Memory size: 128 MiB
    NAND size: 128 MiB
       
Press any key within 2 seconds to enter setup..

loading kernel... OK
setting up elf image... OK
jumping to kernel code
Starting...
Starting services...
Followed by a login prompt:
MikroTik 6.41rc66 (testing)
e-mt-01 Login:
I can log in but most commands just hang.

CPU is at 100% with 99.5% to 100% for management.
Manage RouterOS scripts and extend your devices' functionality: RouterOS Scripts
 
pe1chl
Forum Guru
Forum Guru
Posts: 5913
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Dec 19, 2017 4:19 pm

From what earlier version did you upgrade? 6.41RC too or before?
It looks like it is time for netinstall and restore backup.
 
User avatar
eworm
Member
Member
Posts: 402
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Dec 19, 2017 5:13 pm

From what earlier version did you upgrade? 6.41RC too or before?
The device ran nearly every rc release from 6.41 series.
It looks like it is time for netinstall and restore backup.
Done. :D
Let's hope this does not happen more often.
Manage RouterOS scripts and extend your devices' functionality: RouterOS Scripts
 
pe1chl
Forum Guru
Forum Guru
Posts: 5913
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Dec 19, 2017 5:26 pm

Let's hope this does not happen more often.
When it has more than 16MB flash (which unfortunately is quite common lately) you can partition the flash and
keep the previous version in the other partition. It is then easier to recover from such mishaps.
 
msatter
Forum Guru
Forum Guru
Posts: 1281
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: v6.41rc [release candidate] is released! New bridge implementation!

Tue Dec 19, 2017 9:14 pm

I hope Mikrotik won't rush 6.41 to be there before the end of the year and 2018 seems to be a good bridge year to the last digit of this year. :wink:
Two RB760iGS (hEX S) in series. One does PPPoE and both do IKEv2.
Running:
RouterOS 6.46Beta59 / Winbox 3.20 / MikroTik APP 1.3.7
Having an Android device, use https://github.com/M66B/NetGuard/releases (no root required)
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4051
Joined: Wed May 11, 2011 6:08 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Dec 21, 2017 5:40 pm

What's new in 6.41rc66 (2017-Dec-14 13:53):
*) dhcp-server - added basic RADIUS accounting;
The RADIUS accounting packets for DHCP sessions do not include the User-Name attribute, which should be set as the MAC address of the client, just as it had been sent in the authentication request.

Freeradius also logs warnings about this because the User-Name is part of its hashing for generating unique-session-id
When given a spoon,
you should not cling to your fork.
The soup will get cold.
 
JimmyNyholm
Member Candidate
Member Candidate
Posts: 249
Joined: Mon Apr 25, 2016 2:16 am
Location: Sweden

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Dec 21, 2017 8:11 pm

CRS317-1G-16S+RM is powered by a next generation switching chip, giving you wire speed performance for all sixteen 10GbE ports with any Ethernet frame size. New features such as hardware-based Spanning Tree Protocol and Link Aggregation (LACP) provide enhanced protection and true professional performance for your demanding network.
When can we se this hardware based LACP in Router Os?
If it's already there and I am a fool not to have found it then please tell me how to?
 
User avatar
eworm
Member
Member
Posts: 402
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Dec 21, 2017 9:01 pm

Looks like demo Routerboards find final version 6.41... Is the release being prepare right now?
Manage RouterOS scripts and extend your devices' functionality: RouterOS Scripts
 
freemannnn
Long time Member
Long time Member
Posts: 669
Joined: Sun Oct 13, 2013 7:29 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Dec 21, 2017 9:12 pm

Looks like demo Routerboards find final version 6.41... Is the release being prepare right now?

lol i didnt know this site all these years. thanx.
6.41...christmas present. if yes...nice
 
User avatar
honzam
Forum Guru
Forum Guru
Posts: 2292
Joined: Wed Feb 27, 2008 10:27 pm
Location: Czech Republic

Re: v6.41rc [release candidate] is released! New bridge implementation!

Thu Dec 21, 2017 11:00 pm

Looks like demo Routerboards find final version 6.41... Is the release being prepare right now?
And demo3 http://demo3.mt.lv/webfig/#System:Packa ... or_Updates
:-)
LAN, FTTx, Wireless. ISP operator
 
skuykend
Member Candidate
Member Candidate
Posts: 270
Joined: Tue Oct 06, 2015 7:28 am

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Dec 22, 2017 1:16 am

Looks like demo Routerboards find final version 6.41... Is the release being prepare right now?
And no mention of the bridge update!
 
mducharme
Trainer
Trainer
Posts: 868
Joined: Tue Jul 19, 2016 6:45 pm

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Dec 22, 2017 4:30 am

Looks like demo Routerboards find final version 6.41... Is the release being prepare right now?
And no mention of the bridge update!
The list of changes there is from some older version, it's not showing the correct change list.
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1409
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: v6.41rc [release candidate] is released! New bridge implementation!

Fri Dec 22, 2017 3:00 pm

Version 6.41 has been released:
viewtopic.php?f=21&t=128915

Who is online

Users browsing this forum: No registered users and 9 guests