Community discussions

  • 1
  • 4
  • 5
  • 6
  • 7
  • 8
  • 12
 
pcjc
just joined
Posts: 20
Joined: Wed Aug 02, 2017 4:29 pm

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

Mon Oct 02, 2017 6:36 pm

I decided to try the 6.41rc release on my new CRS326-24G-2S+.

Two notes..

1. Same with 6.40 release firmware, the LAN activity light on Port 1 RJ45 blinks on (appears to reflect activity on the bridge link?), which appears to be a bug (or is this a hardware fault I should return the unit for?)

2. I cannot set the MTU of the bridge (which replaced the old switch configuration) to support jumbo frames. (I can create a new bridge with high MTU, but get an error "Couldn't change Interface <bridge1> - could not set mtu (6)" when attempting to do so on the bridge with all my ports on.

The ports are all hardware offloaded. Do I need to set a high MTU on the bridge / interfaces within the bridge in order to be able to pass jumbo frames? (That is what I am trying to achieve).
 
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!

Mon Oct 02, 2017 6:40 pm

It's been 4 hours and the CRS326-24G-2S+ (on 6.41rc37) is now beheaving well:
- RSTP now works stable between CRS326 and CRS125 (also on 6.41rc37)
- it's now possible to edit MAC addresses on CRS326 ethernet ports (and the device doesn't stuck on reboot)
- no port flapping (yet)

very curious about this:
*) wireless - improved WPA2 key exchange reliability;
 
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!

Tue Oct 03, 2017 11:33 am

What's new in 6.41rc37 (2017-Oct-02 06:47):

Changes since previous 6.41rc release:

*) fetch - accept all HTTP 2xx status codes;
Thank you for this fix!

I don't know how it was planned but noticed that it failed at 204 status code:
[admin@CHR] > /tool fetch url="http://httpstat.us/204"
  status: failed

action failed (6)
 
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!

Tue Oct 03, 2017 11:40 am

normis, thank you for observation:
[admin@CHR] > /tool fetch url="https://httpstatuses.com/204"
      status: finished
  downloaded: 3KiBC-z pause]
    duration: 1s
It working as expected!
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 24002
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

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

Tue Oct 03, 2017 11:44 am

There actually is a bug with 204, we will address it. Your previous URL works with "curl -v" so it should work in Fetch too.
No answer to your question? How to write posts
 
msatter
Forum Guru
Forum Guru
Posts: 1123
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

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

Tue Oct 03, 2017 12:31 pm

Maybe it is possible to extra spaces to end of the "KiB" to erase the remainder of the previous text: "C-z pause]" with fetch.
Two RB760iGS (hEX S) in series. One does PPPoE/IKEv2 and the other does the rest of the tasks.
Running:
RouterOS 6.46Beta / Winbox 3.19 / MikroTik APP 1.2.8
Having an Android device, use https://github.com/M66B/NetGuard/releases (no root required)
 
jrpaz
Frequent Visitor
Frequent Visitor
Posts: 76
Joined: Wed Jun 05, 2013 5:54 am

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

Tue Oct 03, 2017 2:32 pm

I have a Novotel 730 which was added in 6.41r6 & it still is function it reboots when ever I try to pass traffic through it. I already emailed support hopefully they can help me figure this out.
 
niqx
just joined
Posts: 2
Joined: Thu Oct 01, 2015 10:28 am

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

Tue Oct 03, 2017 3:34 pm

Hello Friends,

A small note, but very important for us that uses ALOT of vlans.

We're currently benching CRS317 and we're missing out the option to set notes/comments under /interface bridge vlan.

This is because we'll have alot of config here and since we're alot of people managing the same devices it's key to leave notes. :-)
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1405
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Tue Oct 03, 2017 4:00 pm

What's new in 6.41rc38 (2017-Oct-03 11:51):

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:

*) arm - minor improvements on CPU load distribution for RB1100 series devices;
*) bgp - added 32-bit private ASN support;
*) lte - added Passthrough support (CLI only);
*) snmp - fixed "/system license" parameters for CHR;
*) upnp - add "src-address" parameter on NAT rule if it is specified on UPnP request;
*) upnp - deny UPnP request if port is already used by the router;

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.
 
lukoramu
just joined
Posts: 18
Joined: Mon Jan 07, 2013 11:11 am

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

Tue Oct 03, 2017 4:46 pm

*) bridge - initial support for "/interface list" as a bridge port (CLI only);
Try this:
/in bridge port add interface=all
It's fun! (Spoiler alert - netinstall.exe) ;-)
But actually, this feature is really what I was waiting for for a long time. I just hope these interface lists will be available for "tagged" and "untagged" attributes in "/in br vlan" section !
 
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!

Tue Oct 03, 2017 5:55 pm

strods,

What is difference between earlier RC, for example:

What's new in 6.41rc38 (2017-Oct-03 11:51):
*) lte - added Passthrough support (CLI only);
What's new in 6.41rc31 (2017-Sep-20 06:56):
*) lte - added Passthrough support (CLI only);
 
nescafe2002
Long time Member
Long time Member
Posts: 601
Joined: Tue Aug 11, 2015 12:46 pm
Location: Netherlands

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

Tue Oct 03, 2017 6:00 pm

viewtopic.php?f=21&t=123936&start=100#p614799
If you see the same changelog entry in multiple rc versions then it is a new feature which is being implemented and changelog entry is simply moved up on each rc when additional work on it has been done.
 
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!

Tue Oct 03, 2017 6:14 pm

viewtopic.php?f=21&t=123936&start=100#p614799
If you see the same changelog entry in multiple rc versions then it is a new feature which is being implemented and changelog entry is simply moved up on each rc when additional work on it has been done.
Thank you!
 
uldis
MikroTik Support
MikroTik Support
Posts: 3424
Joined: Mon May 31, 2004 2:55 pm

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

Tue Oct 03, 2017 6:16 pm

strods,

What is difference between earlier RC, for example:

What's new in 6.41rc38 (2017-Oct-03 11:51):
*) lte - added Passthrough support (CLI only);
What's new in 6.41rc31 (2017-Sep-20 06:56):
*) lte - added Passthrough support (CLI only);
We are constantly improving and fixing bugs for this feature.
 
User avatar
Jotne
Forum Guru
Forum Guru
Posts: 1155
Joined: Sat Dec 24, 2016 11:17 am
Location: Magrathean

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

Wed Oct 04, 2017 8:16 am

We are constantly improving and fixing bugs for this feature.
Then the correct should be:

What's new in 6.41rc38 (2017-Oct-03 11:51):
*) lte - updated Passthrough support (CLI only);

What's new in 6.41rc31 (2017-Sep-20 06:56):
*) lte - added Passthrough support (CLI only);
 
How to use Splunk to monitor your MikroTik Router

MikroTik->Splunk
 
 
hapi
Member Candidate
Member Candidate
Posts: 222
Joined: Fri Mar 11, 2011 11:21 am
Location: Czech Republic

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

Wed Oct 04, 2017 8:58 am

Why our sfp modules don't show tx power in mikrotik? Same module in signamax switch show tx power. THX.

Signamax
Connector Type	SFP - LC
Fiber Type	Reserved
Tx Central Wavelength	1310
Baud Rate	1G
Vendor OUI	00:00:00
Vendor Name	Mikrotik
Vendor PN	S-35LC20D
Vendor Rev	1.0
Vendor SN	SK151211B35234
Date Code	151205
Temperature [Degrees Centigrade]	33.75
Vcc [Volt]	3.30
Mon1 (Bias) [mA]	1
Mon2 (TX PWR) [dBm]	-5.19
Mon3 (RX PWR) [dBm]	-17.42
CRS326-24G-2S+
[admin@BS568] > interface ethernet monitor sfp-sfpplus1 
                    name: sfp-sfpplus1
                  status: link-ok
        auto-negotiation: disabled
                    rate: 1Gbps
             full-duplex: yes
         tx-flow-control: yes
         rx-flow-control: yes
      sfp-module-present: yes
             sfp-rx-loss: no
            sfp-tx-fault: no
                sfp-type: SFP-or-SFP+
      sfp-connector-type: LC
     sfp-link-length-9um: 20000m
         sfp-vendor-name: Mikrotik
  sfp-vendor-part-number: S-53LC20D
     sfp-vendor-revision: 1.0
       sfp-vendor-serial: SK151211B54444
  sfp-manufacturing-date: 15-12-05
          sfp-wavelength: 1550nm
         sfp-temperature: 40C
      sfp-supply-voltage: 3.296V
     sfp-tx-bias-current: 0mA
            sfp-rx-power: -9.752dBm
         eeprom-checksum: good
                  eeprom: 0000: 03 04 07 00 00 00 02 00  00 00 00 01 0d 00 14 c8  ........ ........
                          0010: 00 00 00 00 4d 69 6b 72  6f 74 69 6b 20 20 20 20  ....Mikr otik    
                          0020: 20 20 20 20 00 00 00 00  53 2d 35 33 4c 43 32 30      .... S-53LC20
                          0030: 44 20 20 20 20 20 20 20  31 2e 30 00 06 0e 00 e4  D        1.0.....
                          0040: 00 1a 00 00 53 4b 31 35  31 32 31 31 42 35 34 34  ....SK15 1211B544
                          0050: 34 34 20 20 31 35 31 32  30 35 20 20 68 f0 04 34  44  1512 05  h..4
                          0060: 1f a0 7b 0b 1a 66 2c 8c  00 00 52 52 52 52 00 52  ..{..f,. ..RRRR.R
                          0070: 00 40 52 52 00 40 52 52  52 52 52 ff ff ff ff 00  .@RR.@RR RRR.....
                          0080: 55 00 d8 00 46 00 00 00  8d cc 74 04 88 b8 79 18  U...F... ..t...y.
                          0090: af c8 00 00 88 b8 00 00  13 94 04 eb 13 94 04 eb  ........ ........
                          00a0: 18 a6 00 10 13 94 00 10  00 00 00 00 00 00 00 00  ........ ........
                          00b0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ........ ........
                          00c0: 00 00 00 00 3f 80 00 00  00 00 00 00 01 00 00 00  ....?... ........
                          00d0: 01 00 00 00 01 00 00 00  01 00 00 00 00 00 00 40  ........ .......@
                          00e0: 28 64 80 c6 00 65 0b b3  05 89 7d 7d 7d 7d 00 7d  (d...e.. ..}}}}.}
                          00f0: 00 00 7d 7d 00 00 7d 7d  7d 7d 07 ff ff ff ff 00  ..}}..}} }}......
Last edited by hapi on Wed Oct 04, 2017 9:39 am, edited 1 time in total.
 
User avatar
skylark
MikroTik Support
MikroTik Support
Posts: 94
Joined: Wed Feb 10, 2016 3:55 pm

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

Wed Oct 04, 2017 9:15 am

Hello hapi,

DDM info seems quite good from SFP transceiver, why do you have auto-negotiation disabled and what is connected to opposite side? Have you tried to turn auto-negotiation=on?
 
hapi
Member Candidate
Member Candidate
Posts: 222
Joined: Fri Mar 11, 2011 11:21 am
Location: Czech Republic

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

Wed Oct 04, 2017 9:41 am

oh my mistake, it is CRS326-24G-2S+. Modul not function on 10Gbit = auto-negotation is disable and force 1Gbit otherwise they will not join on fiber.

TX power still not show.

v6.41rc38
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1405
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Wed Oct 04, 2017 10:12 am

Jotne - Main idea of rc changelog is to see the difference between current and rc version. Think of an upgrade like you would upgrade from 6.40.4 to 6.41rc no from 6.41rc to 6.41rc.

Anyway, if you have more questions about changelog structure, then please create new forum topic about this or write to support@mikrotik.com

Main idea of this topic is to polish new features in 6.41rc version so that the version would become 6.41 (current) release.
 
Grickos
newbie
Posts: 32
Joined: Thu Aug 06, 2015 2:57 am

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

Wed Oct 04, 2017 6:19 pm

After upgrade to 6.41RC38, WAP R-2nD processor 100%, self nonstop reboot the system. I used Netinstall to run it.
The others Roterboard are work ok
 
hapi
Member Candidate
Member Candidate
Posts: 222
Joined: Fri Mar 11, 2011 11:21 am
Location: Czech Republic

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

Wed Oct 04, 2017 6:46 pm

Another sfp modul, also no tx power, why? Will be fixed?
[admin@BS568] > interface ethernet monitor sfp-sfpplus1 
                    name: sfp-sfpplus1
                  status: link-ok
        auto-negotiation: disabled
                    rate: 1Gbps
             full-duplex: yes
         tx-flow-control: yes
         rx-flow-control: yes
      sfp-module-present: yes
             sfp-rx-loss: no
            sfp-tx-fault: no
                sfp-type: SFP-or-SFP+
      sfp-connector-type: LC
     sfp-link-length-9um: 3000m
         sfp-vendor-name: UBNT
  sfp-vendor-part-number: UF-SM-1G-S
       sfp-vendor-serial: FT17012008409
  sfp-manufacturing-date: 17-01-12
          sfp-wavelength: 1550.32nm
         sfp-temperature: 39C
      sfp-supply-voltage: 3.263V
     sfp-tx-bias-current: 19mA
            sfp-rx-power: -7.271dBm
         eeprom-checksum: good
                  eeprom: 0000: 03 04 07 00 00 00 40 00  00 00 00 01 0d 00 03 1e  ......@. ........
                          0010: 00 00 00 00 55 42 4e 54  20 20 20 20 20 20 20 20  ....UBNT         
                          0020: 20 20 20 20 00 00 00 00  55 46 2d 53 4d 2d 31 47      .... UF-SM-1G
                          0030: 2d 53 20 20 20 20 20 20  20 20 20 20 06 0e 20 37  -S           .. 7
                          0040: 20 0a 00 00 46 54 31 37  30 31 32 30 30 38 34 30   ...FT17 01200840
                          0050: 39 20 20 20 31 37 30 31  31 32 00 00 68 90 01 79  9   1701 12..h..y
                          0060: 20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20                   
                          0070: 20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20                   
                          0080: 5a 00 d3 00 55 00 d8 00  94 70 69 78 90 88 6d 60  Z...U... .pix..m`
                          0090: c3 50 00 00 af c8 00 32  18 a6 03 e8 13 94 04 eb  .P.....2 ........
                          00a0: 27 10 00 28 1f 07 00 32  00 00 00 00 00 00 00 00  '..(...2 ........
                          00b0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ........ ........
                          00c0: 00 00 00 00 3f 80 00 00  00 00 00 00 01 00 00 00  ....?... ........
                          00d0: 01 00 00 00 01 00 00 00  01 00 00 00 00 00 00 99  ........ ........
                          00e0: 27 c3 7f 78 25 76 0a 81  09 cd 00 00 00 00 22 00  '..x%v.. ......".
                          00f0: 00 40 00 00 00 40 00 00  00 00 00 ff ff ff ff 00  .@...@.. ........
 
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!

Wed Oct 04, 2017 9:25 pm

..cut.. SFP transceiver, why do you have auto-negotiation disabled and what is connected to opposite side? Have you tried to turn auto-negotiation=on?
On RB3011 sfp to a CRS326-24G-2S+ via DAC cable doesn't work if you set auto-negotiation , furthermore the RB3011 doesn't detect if link go down (CRS instead correctly detects it).
All this on latest rc but also in previous 6.41rc and also 6.40.3/4
 
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 Oct 05, 2017 2:07 pm

Is it me or how do I search for learned mac-addresses with this new bridge implementation. Host table is almost always empty but local mac's but everything works.
This has been the same all this 41rc branch....

Is there a way to increase timeout on learning ( I have also asked for the option to disable learning or limit number of addresses learned.)

EDIT: Found all macs in /interfaces ethernet switch host

In this new implementation shouldn't these to tables be the same /bridge host and /interface ethernet switch host ???
 
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 06, 2017 10:25 am

In ROS this 6.41rc (38) branch with new bridge implementation with (H)ard ware flag. if I want to use switch chip's filter function.
is this rules applied to (I want the Silicon Hardware ones...)

/interface/bridge/filter
or
/interface/ethernet/switch/rule

Am I right to believe that the switch menu will go away completely and all stuff there will be moved/added to bridge menu. My concern is where we currently stand?
 
pe1chl
Forum Guru
Forum Guru
Posts: 5373
Joined: Mon Jun 08, 2015 12:09 pm

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

Fri Oct 06, 2017 12:33 pm

I am a bit lost on the direction and state of the new bridge implementation...
I use the switch on (mostly RB2011) routers fully configured with VLAN tagging, and with VLAN subinterfaces on the CPU port, like this:
/interface ethernet
set [ find default-name=ether3 ] master-port=ether2
set [ find default-name=ether4 ] master-port=ether2
set [ find default-name=ether5 ] master-port=ether2

/interface vlan
add interface=ether2 name=ether2.vlan12 vlan-id=12
add interface=ether2 name=ether2.vlan19 vlan-id=19
add interface=ether2 name=ether2.vlan20 vlan-id=20
add interface=ether2 name=ether2.vlan24 vlan-id=24
add interface=ether2 name=ether2.vlan44 vlan-id=44
add interface=ether2 name=ether2.vlan58 vlan-id=58

/interface ethernet switch port
set 2 vlan-mode=secure
set 3 vlan-mode=secure
set 4 default-vlan-id=58 vlan-header=always-strip vlan-mode=secure
set 5 default-vlan-id=58 vlan-header=always-strip vlan-mode=secure

/interface ethernet switch vlan
add independent-learning=no ports=switch1-cpu,ether2,ether3  switch=switch1 vlan-id=44
add independent-learning=no ports=switch1-cpu,ether2,ether3,ether4,ether5 switch=switch1 vlan-id=58
add independent-learning=no ports=switch1-cpu,ether2 switch=switch1 vlan-id=20
add independent-learning=no ports=switch1-cpu,ether3 switch=switch1 vlan-id=19
add independent-learning=no ports=switch1-cpu,ether3 switch=switch1 vlan-id=12
add independent-learning=no ports=switch1-cpu,ether2 switch=switch1 vlan-id=24
What is the current state of the "switch to bridge" migration in 6.41rc? Is it going to convert such a configuration properly
and will it still work the same way? I.e. with hardware switching between the ports on tagged and untagged VLANs even
when some ports are tagged and others untagged in the same VLAN? And will it still drop traffic from VLAN tags not
configured for that port?
 
Denkinger
just joined
Posts: 1
Joined: Sun Oct 08, 2017 12:17 am

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

Sun Oct 08, 2017 12:24 am

After upgrade to 6.41RC38, WAP R-2nD processor 100%, self nonstop reboot the system. I used Netinstall to run it.
The others Roterboard are work ok
Good evening,

Same problem here...
And I think router os runs a little bit slow on that device.
 
C3H5N3O9
just joined
Posts: 2
Joined: Tue Oct 03, 2017 1:16 am

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

Sun Oct 08, 2017 10:49 pm

Can't use proxy-arp fonctionality on bridge with new bridge implementation in 6.41rc, in fact, when we try to use ppptp tunnel with proxy-arp on bridge, host behind tunnel on lan can't ping. After a downgrade in 6.40.4 everything work well.
 
poizzon
Member Candidate
Member Candidate
Posts: 112
Joined: Fri Jun 21, 2013 12:53 pm

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

Sun Oct 08, 2017 11:59 pm

Hello, after upgrading RBwAPR-2nD & R11e-LTE to version 6.41rc38, I received a critical error after which the router has been permanently rebooting.

if you want a relative version older than that, you need to log in with a static IP address, quickly roll over the main package, and quickly downgrade, or use netsintall


p.s. firmware version : 3.39.

Does upgrade to firmware up to version 3.41, does the RC start up normally?
--
poi
 
ivicask
Member Candidate
Member Candidate
Posts: 230
Joined: Tue Jul 07, 2015 2:40 pm
Location: Croatia, Zagreb

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

Mon Oct 09, 2017 10:18 am

Hello, after upgrading RBwAPR-2nD & R11e-LTE to version 6.41rc38, I received a critical error after which the router has been permanently rebooting.

if you want a relative version older than that, you need to log in with a static IP address, quickly roll over the main package, and quickly downgrade, or use netsintall


p.s. firmware version : 3.39.

Does upgrade to firmware up to version 3.41, does the RC start up normally?
Can confirm this, same new WAP LTE constant reboots, Critical process died, etc in logs, works fine with older version.
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1405
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Wed Oct 11, 2017 12:35 pm

What's new in 6.41rc44 (2017-Oct-11 08:21):

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:

!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
*) bridge - added comment support for VLANs;
*) bridge - added support for "/interface list" as a bridge port;
*) crs317 - added initial support for HW offloaded MPLS forwarding;
*) crs3xx - fixed 100% CPU usage after interface related changes (introduced in v6.41rc31);
*) dhcpv4-client - add dynamic DHCP client for mobile clients which require it;
*) fetch - accept all HTTP 2xx status codes;
*) firewall - do not NAT address to 0.0.0.0 after reboot if to-address is used but not specified;
*) ike1 - fixed RSA authentication for Windows clients behind NAT;
*) interface - added default "/interface list" "dynamic" which contains dynamic interfaces;
*) interface - added option to join and exclude "/interface list" from one and another;
*) ipsec - added DH groups 19, 20 and 21 support for phase1 and phase2;
*) ipsec - fixed lost value for "remote-certificate" parameter after disable/enable;
*) ipsec - fixed policy enable/disable;
*) ipsec - improved reliability on certificate usage;
*) ipsec - skip invalid policies for phase2;
*) l2tp - improved reliability on packet processing in FastPath;
*) log - fixed interface name in log messages;
*) log - properly recognize MikroTik specific RADIUS attributes;
*) lte - added "/interface lte apn" menu (Passthrough requires reconfiguration);
*) lte - added Passthrough support (CLI only);
*) lte - fixed modem initialization after reboot;
*) lte - limited minimal default route distance to 1;
*) mac-server - use "/interface list" instead of interface name under MAC server settings;
*) neighbor - show neighbors on actual bridge port instead of bridge itself
*) sms - include timestamps in SMS delivery reports;
*) sms - properly initialize SMS storage;
*) snmp - show only available OIDs under "/system health print oid";
*) winbox - allow shorten bytes to k,M,G in Hotspot user limits;
*) winbox - do not show duplicate "Switch" menus for CRS326;
*) winbox - fixed "/certificate sign" process;
*) wireless - added "allow-signal-out-off-range" option for Access List entries;

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.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5373
Joined: Mon Jun 08, 2015 12:09 pm

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

Wed Oct 11, 2017 2:18 pm

What's new in 6.41rc44 (2017-Oct-11 08:21):
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.
What about configurations like mentioned in posting #275 in this topic? Are they supported now?
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Wed Oct 11, 2017 2:45 pm

Fairly in depth post, to highlight a few things (community and strods correct me if I'm wrong).

The independent learning = no option doesn't exist anymore. You're going to get independent MAC databases per VLAN. I'm curious as to why you weren't doing that before, was it a hardware limitation?

Frame tagging exists in the implementation:
/interface bridge port set 0 frame-types=
FrameTypes ::= admit-all | admit-only-untagged-and-priority-tagged | admit-only-vlan-tagged
I'd argue that setting a PVID and "admit-only-untagged-and-priority-tagged" is better than VLAN mode secure and always-strip.

The rest of the configuration is just basic VLAN configuration which is well supported.

The only two points I personally can't speak for is how well the automatic conversion will go during the upgrade and the state of each of those features on the RB2011. I don't own that hardware.

Personally, I'd make sure I have a back-door after the upgrade. Maybe take a port out of the "switch-chip" by removing master-port and set it up as a routed interface that you can plug a laptop into and easily get access to the device. This also could be a WAN port, allow SSH to the device from your home or another office's IP so you can hop in that way if needed (or leave it open by src IP and use a good password / ssh key and come in via a mobile hotspot or starbucks). This would allow you to tweak the bridge config as needed.
 
User avatar
Cha0s
Forum Veteran
Forum Veteran
Posts: 875
Joined: Tue Oct 11, 2005 4:53 pm

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

Wed Oct 11, 2017 3:36 pm

!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
Is this feature feature optional if someone does not want their router to contact cloud.mikrotik.com every minute?

Is it just cosmetic (ie: "this interface is 'WAN' just FYI") or is it actually used somewhere (ie: in firewall rules as an interface list) ?

Does in any way affect the functionality of other features in ROS?
 
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!

Wed Oct 11, 2017 3:44 pm

!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
Is this feature feature optional if someone does not want their router to contact cloud.mikrotik.com every minute?

Is it just cosmetic (ie: "this interface is 'WAN' just FYI") or is it actually used somewhere (ie: in firewall rules as an interface list) ?

Does in any way affect the functionality of other features in ROS?
Specifying our own host instead of 8.8.8.8 and cloud.mikrotik.com, may be usefully in the future.


Thank you!
 
andriys
Forum Guru
Forum Guru
Posts: 1080
Joined: Thu Nov 24, 2011 1:59 pm
Location: Kharkiv, Ukraine

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

Wed Oct 11, 2017 3:49 pm

Is it just cosmetic (ie: "this interface is 'WAN' just FYI") or is it actually used somewhere (ie: in firewall rules as an interface list) ?
My understanding is it will populate the interface lists you specify with the actual interfaces. Those lists can then be used in firewall filter, NAT, etc.

I'd also expect this feature to be used in the defconf, but we'd better wait for an official announcement.
 
User avatar
Cha0s
Forum Veteran
Forum Veteran
Posts: 875
Joined: Tue Oct 11, 2005 4:53 pm

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

Wed Oct 11, 2017 3:51 pm

!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
Is this feature feature optional if someone does not want their router to contact cloud.mikrotik.com every minute?

Is it just cosmetic (ie: "this interface is 'WAN' just FYI") or is it actually used somewhere (ie: in firewall rules as an interface list) ?

Does in any way affect the functionality of other features in ROS?
Specifying our own host instead of 8.8.8.8 and cloud.mikrotik.com, may be usefully in the future.


Thank you!
Yes that would actually be cool IMHO.

I generally don't like features that 'call the vendor's home'. I prefer solutions that respect the user's privacy.
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Wed Oct 11, 2017 4:05 pm

!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
Is the test IPv6 compliant. It needs to be. The address 8.8.8.8 is an IPv4 static, fail. The DNS name cloud.mikrotik.com only has an A record.

If you truly want to detect for Internet you need to use both IPv4 and IPv6 literals and a dual-stacked DNS name. We (the networking community) MUST NOT design features that are IPv4 only. The standards bodies have adopted an IPv6 first approach. I'm very sad to see this feature does not follow that stance. Some ISPs have already had to go to an IPv6 only design due to IPv4 exhaustion. Many others are doing layered IPv4 NAT (CGN) to provide psuedo IPv4 connectivity. (Look at the US cellular market). As a customer, this lack of market awareness is troubling. A feature that clearly targets home or small business routers should be IPv6 aware given the climate of connectivity.

As many forum members will likely state, this feature is of little value to them. It may find some play in the home router arena but even then it seems like overkill. I am curious as to how this test is valid. Packets sourced from my LAN IP all have access to 8.8.8.8 and cloud.mikrotik.com via the static default route and NAT rules. Does the special interface have coding that inspects the routing table?

All in all, seems like another case of MikroTik's roadmap being out of touch with actual customer needs. You don't drive sales by developing features that don't provide any value. You need to provide features that demonstrate how MikroTik routers can be used to develop solutions that create positive business outcomes. We can sell business outcomes to purchasers. Simplifying VLAN configuration and implementing RSTP and MSTP. Those are great examples of features that create value that can be translated into positive business outcomes.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5373
Joined: Mon Jun 08, 2015 12:09 pm

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

Wed Oct 11, 2017 4:33 pm

Is it just cosmetic (ie: "this interface is 'WAN' just FYI") or is it actually used somewhere (ie: in firewall rules as an interface list) ?
My understanding is it will populate the interface lists you specify with the actual interfaces. Those lists can then be used in firewall filter, NAT, etc.

I'd also expect this feature to be used in the defconf, but we'd better wait for an official announcement.
The defconf already changed in version 6.40! It now uses the "WAN" interface list in the firewall instead of ether1.
 
jrpaz
Frequent Visitor
Frequent Visitor
Posts: 76
Joined: Wed Jun 05, 2013 5:54 am

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

Wed Oct 11, 2017 4:48 pm

The Novotel 730L is still unable to stay connected it constantly loses DHCP leases even after this release.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5373
Joined: Mon Jun 08, 2015 12:09 pm

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

Wed Oct 11, 2017 5:01 pm

Fairly in depth post, to highlight a few things (community and strods correct me if I'm wrong).

The independent learning = no option doesn't exist anymore. You're going to get independent MAC databases per VLAN. I'm curious as to why you weren't doing that before, was it a hardware limitation?
Well that setting is not so important, I think. I probably unchecked it once because it would be like the switches I am accustomed with, and then just copied the same setting over and over.
Frame tagging exists in the implementation:
/interface bridge port set 0 frame-types=
FrameTypes ::= admit-all | admit-only-untagged-and-priority-tagged | admit-only-vlan-tagged
I'd argue that setting a PVID and "admit-only-untagged-and-priority-tagged" is better than VLAN mode secure and always-strip.

The rest of the configuration is just basic VLAN configuration which is well supported.
Are you sure? I do not yet see the option to restrict certain tagged VLANs to certain ports. And what about tagging untagged frames with a certain VLAN tag?
My config does not use the untagged VLAN at the CPU port, but it does have untagged external ports. Those have to be in some VLAN.
Now, the switch easily manages that with the default-vlan-id=xx vlan-header=always-strip setting, but can the bridge do the same thing? And will it
be hardware accellerated? (I do not want traffic between an untagged port and the tagged VLAN with the same ID on another port to be CPU-bridged)
The only two points I personally can't speak for is how well the automatic conversion will go during the upgrade and the state of each of those features on the RB2011. I don't own that hardware.
Well it hopefully will not be very different between models that have a switch chip so I could do some experiments on a RB750.
Personally, I'd make sure I have a back-door after the upgrade. Maybe take a port out of the "switch-chip" by removing master-port and set it up as a routed interface that you can plug a laptop into and easily get access to the device.
Normally there is a local network with DHCP service on port 10 for emergency maintenance and of course these routers also have a serial port, but unfortunately they are located on sites all over the country that have limited access. We will clearly have to be very careful when updating to 6.41
 
Zaffo
just joined
Posts: 3
Joined: Tue Jun 27, 2017 7:52 pm

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

Wed Oct 11, 2017 5:05 pm

After an upgrade from the previous rc38 to v6.41rc44 my mAP lite crashes when the ethernet cable is plugged in. First log entry after unplugging the cable states "router rebooted because some critical program crashed". Device is configured as a pocket router/AP and has one L2TP/IPsec and two ovpn clients.

After disabling the PPP clients I can connect ether1 without problems. When I now enable either one of the ovpn clients the device crashes some time after the connection is established. The L2TP/IPsec client gives no problem.
 
User avatar
strods
MikroTik Support
MikroTik Support
Topic Author
Posts: 1405
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

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

Wed Oct 11, 2017 5:13 pm

As for detect-interface feature. Please take a look at wiki page which was provided in changelog:
https://wiki.mikrotik.com/wiki/Manual:D ... figuration

"detect-interface-list (interface list; Default: none) All interfaces in the list will be monitored by Detect Internet"

As you can see - default value is none
 
R1CH
Forum Veteran
Forum Veteran
Posts: 869
Joined: Sun Oct 01, 2006 11:44 pm

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

Wed Oct 11, 2017 5:18 pm

!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
Is this feature feature optional if someone does not want their router to contact cloud.mikrotik.com every minute?

Is it just cosmetic (ie: "this interface is 'WAN' just FYI") or is it actually used somewhere (ie: in firewall rules as an interface list) ?

Does in any way affect the functionality of other features in ROS?
Specifying our own host instead of 8.8.8.8 and cloud.mikrotik.com, may be usefully in the future.


Thank you!
Changing the hosts is not just useful, it's a requirement. Just imagine, you can DDoS cloud.mikrotik.com and every router using this feature goes offline!
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8280
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

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

Wed Oct 11, 2017 5:28 pm

Just imagine, you can DDoS cloud.mikrotik.com and every router using this feature goes offline!
ports still will be 'WAN', so nothing terrible should happen :)
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.
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Wed Oct 11, 2017 6:00 pm

Just imagine, you can DDoS cloud.mikrotik.com and every router using this feature goes offline!
ports still will be 'WAN', so nothing terrible should happen :)
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.

Dumb feature.

It's like VTP, was great on the drawing board and then it was used to wipe peoples VLAN databases. It took a few years but now Cisco disavows that feature.
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Wed Oct 11, 2017 6:12 pm

Fairly in depth post, to highlight a few things (community and strods correct me if I'm wrong).

The independent learning = no option doesn't exist anymore. You're going to get independent MAC databases per VLAN. I'm curious as to why you weren't doing that before, was it a hardware limitation?
Well that setting is not so important, I think. I probably unchecked it once because it would be like the switches I am accustomed with, and then just copied the same setting over and over.
Frame tagging exists in the implementation:
/interface bridge port set 0 frame-types=
FrameTypes ::= admit-all | admit-only-untagged-and-priority-tagged | admit-only-vlan-tagged
I'd argue that setting a PVID and "admit-only-untagged-and-priority-tagged" is better than VLAN mode secure and always-strip.

The rest of the configuration is just basic VLAN configuration which is well supported.
Are you sure? I do not yet see the option to restrict certain tagged VLANs to certain ports. And what about tagging untagged frames with a certain VLAN tag?
My config does not use the untagged VLAN at the CPU port, but it does have untagged external ports. Those have to be in some VLAN.
Now, the switch easily manages that with the default-vlan-id=xx vlan-header=always-strip setting, but can the bridge do the same thing? And will it
be hardware accellerated? (I do not want traffic between an untagged port and the tagged VLAN with the same ID on another port to be CPU-bridged)
The only two points I personally can't speak for is how well the automatic conversion will go during the upgrade and the state of each of those features on the RB2011. I don't own that hardware.
Well it hopefully will not be very different between models that have a switch chip so I could do some experiments on a RB750.
Personally, I'd make sure I have a back-door after the upgrade. Maybe take a port out of the "switch-chip" by removing master-port and set it up as a routed interface that you can plug a laptop into and easily get access to the device.
Normally there is a local network with DHCP service on port 10 for emergency maintenance and of course these routers also have a serial port, but unfortunately they are located on sites all over the country that have limited access. We will clearly have to be very careful when updating to 6.41
PVID = Default VLAN (Primary VLAN ID).

So you can accomplish an untagged port by changing the PVID of a bridge port to whatever VLAN ID you need. You also have the /interface bridge vlan table. In that table you specify which ports have a VLAN tagged or untagged. So like secure mode, you set admit-only-tagged-frames and then only add that bridge port to the VLANs tagged lists that you want.

As far as the acceleration goes, it is model dependent. The goal is to manage hardware offload based on the switch chips available features. I got that answer from MikroTik support. The translation is that if it can do it now in the switch chip it should do it in the future with HW offload on dynamically. How long it takes to get to that state for all models, well time will tell.

The master-port option is removed so you can't really use the old configurations. MikroTik has been tight lipped about which switch chips it has enabled HW offload for. None of my test gear (hex, wap ac and cap lite) are setup in a way that I'm seeing HW offload actually turned on yet for the Ethernet ports. That said I can still pull over 300mbps across VLANs on my hex. InterVLAN routing was and always will be CPU bound and I don't really have much traffic that hits the bridges, I used software bridges in the past because the switch chip in the hex is basically a single flat layer 2 domain (no vlans).

Without meaningful release notes that tell us when each switch chip is enabled for HW offload the only thing we know is that they are developing off of CRS3xx in house. The best thing might be to target a single location that uses a RB2011 or setup a lab RB2011 and monitor the RCs progress for your particular set of options so you know when that happens or cool your heals until 6.41 goes GA.
 
lukoramu
just joined
Posts: 18
Joined: Mon Jan 07, 2013 11:11 am

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

Wed Oct 11, 2017 6:19 pm

Just imagine, you can DDoS cloud.mikrotik.com and every router using this feature goes offline!
ports still will be 'WAN', so nothing terrible should happen :)
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.

Dumb feature.

It's like VTP, was great on the drawing board and then it was used to wipe peoples VLAN databases. It took a few years but now Cisco disavows that feature.
Hmm.. Why do you guys think that "detect-internet" feature will do ANY of that?...
What I'm getting from wiki page, it's just an informational feature: you type
/interface detect-internet state
and you get some info, that this feature gathered..
 
idlemind
Forum Guru
Forum Guru
Posts: 1101
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

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

Wed Oct 11, 2017 6:31 pm

Just imagine, you can DDoS cloud.mikrotik.com and every router using this feature goes offline!
ports still will be 'WAN', so nothing terrible should happen :)
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.

Dumb feature.

It's like VTP, was great on the drawing board and then it was used to wipe peoples VLAN databases. It took a few years but now Cisco disavows that feature.
Hmm.. Why do you guys think that "detect-internet" feature will do ANY of that?...
What I'm getting from wiki page, it's just an informational feature: you type
/interface detect-internet state
and you get some info, that this feature gathered..
The magic is in the other settings:
[admin@211-rtr1] > interface detect-internet set 
Change properties of one or several items.

detect-interface-list -- 
internet-interface-list -- 
lan-interface-list -- 
wan-interface-list -- 
If you see the wiki the lists is what does the work, set Internet interface list to something like WAN, add all interfaces to the detect-interface-list and boom you have a problem. If the LAN interface is detected to be a WAN interface it can then be elevated to an Internet interface. I'd have to setup a lab but I'd imagine it's possible to do the necessary spoofing just with routing.
 
andriys
Forum Guru
Forum Guru
Posts: 1080
Joined: Thu Nov 24, 2011 1:59 pm
Location: Kharkiv, Ukraine

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

Wed Oct 11, 2017 6:52 pm

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.
My understanding is detect-internet is aimed to be used on home-users' routers, which are definitely not supposed to be running any of the dynamic routing protocols (and are not by default). Honestly, I don't see anything wrong with it. Much better to have all ports protected, and treat some of them as WAN-facing (and others as LAN-facing) when certain criteria is met, than exposing your router to the DNS amplification attacks by simply adding PPPoE interface without also modifying the existing (default) firewall rules (a common problem that multiple people complained about up until recently).
 
pe1chl
Forum Guru
Forum Guru
Posts: 5373
Joined: Mon Jun 08, 2015 12:09 pm

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

Wed Oct 11, 2017 7:20 pm

PVID = Default VLAN (Primary VLAN ID).

So you can accomplish an untagged port by changing the PVID of a bridge port to whatever VLAN ID you need. You also have the /interface bridge vlan table. In that table you specify which ports have a VLAN tagged or untagged. So like secure mode, you set admit-only-tagged-frames and then only add that bridge port to the VLANs tagged lists that you want.
Ok, that sounds good. From earlier discussion I got the impression that from now on the bridge would be one big VLAN-transparent thing, whereas in my existing practice (not the above example) I would normally put VLAN subinterfaces on ports and make the subinterfaces part of a bridge, rather than putting entire ports in the bridge and adding VLAN subinterfaces to the bridge.
However, with detailed VLAN configuration for bridge ports that could be a good solution.

I think I'll have to experiment with converting some setups on a test router...
  • 1
  • 4
  • 5
  • 6
  • 7
  • 8
  • 12

Who is online

Users browsing this forum: No registered users and 7 guests