Page 1 of 1

v6.40rc [release candidate] is released!

Posted: Fri Apr 28, 2017 4:04 pm
by strods
We have released MikroTik RouterOS v6.40rc in release candidate channel for testing!

What's new in 6.40rc2 (2017-Apr-28 05:24):

*) 6to4 - fixed wrong IPv6 “link-local” address generation;
*) arp - fixed “make-static”;
*) capsman - fixed EAP identity reporting in “registration-table”;
*) dns - remove all dynamic cache RRs of same type when adding static entry;
*) ethernet - fixed forced 10Mbps full-duplex linking on 100Mbps Ethernet ports;
*) firewall - fixed “address-list” entry changing from IP to DNS and vice versa;
*) firewall - “address-list” entry “creation-time” adjusted to timezone;
*) firewall - fixed cosmetic "inactive" flag when item was disabled;
*) ike1 - fixed crash on xauth message;
*) ike1 - fixed minor memory leak on peer configuration change;
*) ipsec - enabled modp2048 DH group by default;
*) ipsec - optimized logging under IPSec topic;
*) ipv6 - fixed address becoming invalid when interface was removed from bridge/mesh;
*) log - work on false CPU/RAM overclocked alarms;
*) pppoe - fixed warning on PPPoE server, when changing interface to non-slave interface;
*) quickset - added "Band" setting to "CPE" and "PTP CPE" modes;
*) routing - allow to disable "all" interface entry in BFD;
*) sniffer - fixed VLAN tags when sniffing all interfaces;
*) snmp - fixed limited walk;
*) switch - fixed disabling of MAC learning on CRS1xx/CRS2xx;
*) tile - fixed EoIP keepalive when tunnel is made over VLAN interface;
*) winbox - added "eap-identity" to CAPsMAN registration table;
*) winbox - added "no-dad" setting to IPv6 addresses;
*) winbox - added TR069 support;
*) winbox - do not allow to open multiple same sub-menus at the same time;
*) wireless - fixed 802.11u wireless request processing;
*) wireless - fixed EAP PEAP success processing;

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

Re: v6.40rc [release candidate] is released!

Posted: Fri Apr 28, 2017 4:34 pm
by Phaere
*) switch - fixed disabling of MAC learning on CRS1xx/CRS2xx;
Can we get some extra info about this fix? Symptoms etc.
Thanks.

Re: v6.40rc [release candidate] is released!

Posted: Fri Apr 28, 2017 5:29 pm
by biatche
hoping to see STP implementations sooner than later. wouldn't mind using an rc in production just for this.

Re: v6.40rc [release candidate] is released!

Posted: Fri Apr 28, 2017 6:09 pm
by cheeze
I kinda want to ask what the scope was for the new STP implementation.

Is it meant to basically run like per vlan rapid spanning tree protocol that is similar to Cisco? Basically instantiate rapid STP and then have the instance communicate with tagged packets?

Per conversations that were had with support, does that mean that multiple STP is not going to be looked at?

If it is going to be rapid spanning tree protocol that is similar to Cisco, then what will the limitations be. For example, will there be an instance limit? Or will it be open to be added to as many bridges as possible?

Lastly, will the implementation be available per bridge? or will one have to still add a master port? That way one can have some bridges without spanning tree and others with spanning tree....

Thank you

Re: v6.40rc [release candidate] is released!

Posted: Fri Apr 28, 2017 7:06 pm
by biatche
I kinda want to ask what the scope was for the new STP implementation.

Is it meant to basically run like per vlan rapid spanning tree protocol that is similar to Cisco? Basically instantiate rapid STP and then have the instance communicate with tagged packets?

Per conversations that were had with support, does that mean that multiple STP is not going to be looked at?

If it is going to be rapid spanning tree protocol that is similar to Cisco, then what will the limitations be. For example, will there be an instance limit? Or will it be open to be added to as many bridges as possible?

Lastly, will the implementation be available per bridge? or will one have to still add a master port? That way one can have some bridges without spanning tree and others with spanning tree....

Thank you
All I'm hoping for is an implementation that works between all MT devices and hopefully 3rd parties also, particularly with multiple bridges & vlans. I'd think having MSTP would solve the whole conundrum.

Right now, with the present reverted implementation, it's not clear to me whether RSTP+vlan would work between MT devices that communicate with CRS125 in between. Does the CRS125 support RSTP+vlan right now? I hope an official MT staff would comment on this.

Re: v6.40rc [release candidate] is released!

Posted: Fri Apr 28, 2017 10:34 pm
by anuser
*) capsman - fixed EAP identity reporting in “registration-table”;
*) winbox - added "eap-identity" to CAPsMAN registration table;
Thank you very much for this one! It´s working now as expected

Re: v6.40rc [release candidate] is released!

Posted: Sat Apr 29, 2017 8:27 pm
by Njumaen
on the hAPac the "Partition" menu is shown but you can not partition because of only 16MiB Total HDD Size...

"Repartition" of course fails with an error message.

Re: v6.40rc [release candidate] is released!

Posted: Sat Apr 29, 2017 10:12 pm
by jondavy
into /tool graphing Is recording the graphs with wrong time

Re: v6.40rc [release candidate] is released!

Posted: Tue May 02, 2017 10:43 am
by Deantwo
*) ipsec - optimized logging under IPSec topic;
Hoping that means no more spammy "R_U_THERE" log messages.
Not sure when I can give this version a try though.

Re: v6.40rc [release candidate] is released!

Posted: Tue May 02, 2017 5:02 pm
by anuser
WAP AC with 6.40rc2
Within Webfig System:Resources.PCI shows: "unknown device (rev: 0)" for Name

Re: v6.40rc [release candidate] is released!

Posted: Wed May 03, 2017 10:36 am
by strods
Version 6.40rc4 has been released. Changes since previous release:

What's new in 6.40rc4 (2017-May-03 05:15):

*) conntrack - load IPv6 connection tracking independently of IPv4;
*) console - fixed "No such file or directory" warnings on upgrade reboots;
*) defconf - discard default configuration startup query with RouterOS upgrade;
*) defconf - discard default configuration startup query with configuration change from Webfig;
*) dns - made loading thousands of static entries faster;
*) fetch - fixed user and password argument parsing from URL for FTP;
*) log - work on false CPU/RAM overclocked alarms;
*) lte - added additional driver support for DWR-910;
*) smb - fixed external drive folder sharing when "/flash" folder existed;
*) smb - fixed invalid default share after reboot when "/flash" folder existed;
*) upnp - fixed firewall nat rule update when external IP address changes;

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.

Issues with v6.40 and RB2011

Posted: Wed May 03, 2017 10:47 am
by tanel
So just as a small note i'll mention that i lost quite some hours debugging the issues i got when upgrading to v6.40- at one site i have 5 RB2011 devices and one of them (of course the main router) didnt't reply after update. After trying some ideas and local guys i had to drive onsite and discovered that the router is starting up, starting services and then in approx 30 seconds it wrote stopping services and then rebooting- over ethernet i couldnt access it and over serial console i got the login prompt but it didnt accept any user / password.
After reseting the router to clean conf i was able to log in but many IP related things were missing (DHCP server, DHCP client etc and under packages was only one package- main) and taskbar was not showing software version etc. After multiple tries i reverted to previous version - 6.39.5 and everything started working automagically.

tt

Re: v6.40rc [release candidate] is released!

Posted: Wed May 03, 2017 1:36 pm
by zryny4
IPv6 address list problem:
[admin@hAP AC Lite] > /ipv6 firewall address-list print
Flags: X - disabled, D - dynamic
 #   LIST                     ADDRESS                                                  TIMEOUT
 0   allowed                  ::/0
[admin@hAP AC Lite] > /ipv6 firewall address-list remove numbers=0
[admin@hAP AC Lite] > /ipv6 firewall address-list add list=allowed address=2001:db8::/64
[admin@hAP AC Lite] > /ipv6 firewall address-list print
Flags: X - disabled, D - dynamic
 #   LIST                     ADDRESS                                                  TIMEOUT
 0   allowed                  ::/0
[admin@hAP AC Lite] > /ipv6 firewall address-list add list=allowed address=2001:db8::/64
failure: already have such entry

Re: v6.40rc [release candidate] is released!

Posted: Wed May 03, 2017 1:49 pm
by anuser
6.40rc2 + WAP AC:
I was told that an IPhone 6s wasn´t able to connect. (Test with an old Enterasys 3600 access point was succesful, though)

Re: v6.40rc [release candidate] is released!

Posted: Wed May 03, 2017 3:00 pm
by MartijnVdS
IPv6 address list problem:

[admin@hAP AC Lite] > /ipv6 firewall address-list add list=allowed address=2001:db8::/64
[admin@hAP AC Lite] > /ipv6 firewall address-list print
Flags: X - disabled, D - dynamic
# LIST ADDRESS TIMEOUT
0 allowed ::/0
[admin@hAP AC Lite] > /ipv6 firewall address-list add list=allowed address=2001:db8::/64
failure: already have such entry
[/code]
Well in a way it's right -- ::/0 contains all IPv6 addresses, including 2001:db8::/64

Re: v6.40rc [release candidate] is released!

Posted: Wed May 03, 2017 3:04 pm
by zryny4
IPv6 address list problem:

[admin@hAP AC Lite] > /ipv6 firewall address-list add list=allowed address=2001:db8::/64
[admin@hAP AC Lite] > /ipv6 firewall address-list print
Flags: X - disabled, D - dynamic
# LIST ADDRESS TIMEOUT
0 allowed ::/0
[admin@hAP AC Lite] > /ipv6 firewall address-list add list=allowed address=2001:db8::/64
failure: already have such entry
[/code]
Well in a way it's right -- ::/0 contains all IPv6 addresses, including 2001:db8::/64
Ok, but I don't want to access to my router from anywhere. Address 2001:db8::/64 -- only for example. If you add address list with any other address, you have your address list with address ::/0. You can remove it and recreate, but nothing changes -- you can have list with only ::/0.

Re: v6.40rc [release candidate] is released!

Posted: Wed May 03, 2017 3:24 pm
by uldis
6.40rc2 + WAP AC:
I was told that an IPhone 6s wasn´t able to connect. (Test with an old Enterasys 3600 access point was succesful, though)
Please post more details about your problem.
Maybe you could write to support@mikrotik.com about this problem and include a support output file from the router?

Re: v6.40rc [release candidate] is released!

Posted: Thu May 04, 2017 2:03 pm
by anuser
6.40rc2 + WAP AC:
I was told that an IPhone 6s wasn´t able to connect. (Test with an old Enterasys 3600 access point was succesful, though)
Please post more details about your problem.
Maybe you could write to support@mikrotik.com about this problem and include a support output file from the router?
I try to get the user with that iPhone 6s and create a support file out of the WAP AC while he tries to connect.

Re: v6.40rc [release candidate] is released!

Posted: Thu May 04, 2017 2:21 pm
by anuser
Does anyone experience problems with 2.4Ghz band? Therefore I pinged two clients from the CAPSMAN controller on the same „WAP AC“ access point (WAP AC with v6.40rc4), one connected with 2.4 (cap24) another with 5.0 Ghz (cap50):
So I tested with other clients i and access points in another building.

- building A:
++WAP AC with v6.40rc4:
++HAP AC Lite with v6.40rc4

=> On 5 Ghz everything looks nice for both access points, i.e. low latency.

=> On 2.4Ghz
====>"HAP AC lite" looks good, .i.e.low latency
====>"WAP AC" has higher latency + packet losses

Re: v6.40rc [release candidate] is released!

Posted: Fri May 05, 2017 1:59 pm
by ivicask
*) dns - made loading thousands of static entries faster;

Thank you MIkrotik for this, my routers starts/restart so much faster now (around 10k DNS entries)

Re: v6.40rc [release candidate] is released!

Posted: Mon May 08, 2017 9:02 pm
by enggheisar
update is very nice

Re: v6.40rc [release candidate] is released!

Posted: Tue May 09, 2017 2:09 pm
by strods
Version 6.40rc5 has been relased.

Changes since previous version;
What's new in 6.40rc5 (2017-May-08 09:20):

*) firewall - fixed IPv6 all address list entries becoming "::/0" (introduced in 6.40rc1);
*) ike2 - fixed rare kernel failure on address acquire;
*) log - added "poe-out" topic;
*) lte - added initial support for "NTT DoCoMo" modem;
*) wireless - always use "multicast-helper" when DHCP is being used;
*) wireless - fixed compatibility with "AR5212" wireless chips;
*) wireless - NAK any methods except MS-CHAPv2 as inner method in PEAP;

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

Re: v6.40rc [release candidate] is released!

Posted: Tue May 16, 2017 11:02 am
by strods
Version 6.40rc6 has been released.
Changes since previous version:
What's new in 6.40rc6 (2017-May-11 12:53):

*) capsman - set minimal "caps-man-names" and "caps-man-certificate-common-names" length to 1 char;
*) led - fixed ethernet LEDs on CCR1009 and RB1100AHx2 (introduced in v6.40rc1);
*) led - fixed turning off LED when interface is lost;
*) log - work on false CPU/RAM overclocked alarms;
*) lte - improved info channel background polling;
*) lte - replaced "user-command" with "at-chat" command;
*) snmp - added "ifindex" on interface traps;
*) wireless - added option to change "nv2-downlink-ratio" for nv2 protocol (CLI only);
*) wireless - added option to set "fixed-downlink" mode for nv2 protocol (CLI only);

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

Re: v6.40rc [release candidate] is released!

Posted: Tue May 16, 2017 12:25 pm
by nkourtzis
Version 6.40rc6 has been released.
What's new in 6.40rc6 (2017-May-11 12:53):

*) wireless - added option to change "nv2-downlink-ratio" for nv2 protocol (CLI only);
*) wireless - added option to set "fixed-downlink" mode for nv2 protocol (CLI only)
Mikrotik devs, well done! Thank you for finally giving some care to nv2. Please continue to do so, probably optimising the code in order to achieve higher performance on existing hardware.

Also, please see if you can split the "Wireless" tab of the wireless interfaces into two tabs, because on lower screen resolutions (common in the field) it does not fit when switched to advanced view.

Thank you!
Nicholas

Re: v6.40rc [release candidate] is released!

Posted: Tue May 16, 2017 1:43 pm
by doneware
*) snmp - added "ifindex" on interface traps;
this is something that many of us waited for.

Re: v6.40rc [release candidate] is released!

Posted: Tue May 16, 2017 5:18 pm
by Alessio Garavano
Version 6.40rc6 has been released.
Changes since previous version:
What's new in 6.40rc6 (2017-May-11 12:53):
*) wireless - added option to change "nv2-downlink-ratio" for nv2 protocol (CLI only);
*) wireless - added option to set "fixed-downlink" mode for nv2 protocol (CLI only);
GREAT NEWS!!! can explain more about the config?

In a quick example.... If i "send" Internet from point A(bridge) to B(slave), in A what is the "nv2-downlink-ratio" correct setting to send 80% of traffic capacity to B and receive only 20%?

Thanks and regards!

Re: v6.40rc [release candidate] is released!

Posted: Tue May 16, 2017 5:32 pm
by uldis
we have added basic info on that in the Nv2 wiki manual. Here is the info:
Nv2-mode - specifies to use dynamic or fixed downlink/uplink ratio. Default value is "dynamic-downlink"
Nv2-downlink-ratio - specifies the Nv2 downlink ratio. Uplink ratio is automatically calculated from the downlink-ratio value. When using dynamic-downlink mode the downlink-ratio is also used when link get fully saturated. Minimum value is 20 and maximum 80. Default value is 50.

Re: v6.40rc [release candidate] is released!

Posted: Tue May 16, 2017 5:49 pm
by soulflyhigh
*) wireless - added option to change "nv2-downlink-ratio" for nv2 protocol (CLI only);
*) wireless - added option to set "fixed-downlink" mode for nv2 protocol (CLI only);
/interface wireless> set 0 nv2-mode=       

Nv2Mode ::= dynamic-downlink | fixed-downlink
/interface wireless> set 0 nv2-downlink-ratio=

Nv2DownlinkRatio ::= 20..80    (integer number)
It seems that traffic doesn't pass through p2p link with Nv2DownlinkRatio set to 80 (station side connects to AP but no Rx traffic is coming to AP). Works as expected for 20-79 range.
After short test my conclusion is that old dynamic-downlink mode works better in terms of maximum throughput for p2p links simply because dynamic-downlink allows more than 80% traffic to go in one direction.
Still, this is nice step forward, would like to see some kind of manual control over client prioritization by time slots or percentages of AP's time. That would be REALLY good news.

Regards,
M.

Re: v6.40rc [release candidate] is released!

Posted: Tue May 16, 2017 6:24 pm
by LynxChaus
Version 6.40rc6 has been released.
*) snmp - added "ifindex" on interface traps;
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (483949061) 56 days, 0:18:10.61 SNMPv2-MIB::snmpTrapOID.0 = OID: IF-MIB::linkDown IF-MIB::ifIndex = INTEGER: 308 IF-MIB::ifAdminStatus = INTEGER: up(1) IF-MIB::ifOperStatus = INTEGER: down(2)
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (483949661) 56 days, 0:18:16.61 SNMPv2-MIB::snmpTrapOID.0 = OID: IF-MIB::linkUp IF-MIB::ifIndex = INTEGER: 308 IF-MIB::ifAdminStatus = INTEGER: up(1) IF-MIB::ifOperStatus = INTEGER: up(1)

It's already here - what you added?

Re: v6.40rc [release candidate] is released!

Posted: Tue May 16, 2017 11:49 pm
by honzam
Version 6.40rc6 has been released.
What's new in 6.40rc6 (2017-May-11 12:53):

*) wireless - added option to change "nv2-downlink-ratio" for nv2 protocol (CLI only);
*) wireless - added option to set "fixed-downlink" mode for nv2 protocol (CLI only)
Mikrotik devs, well done! Thank you for finally giving some care to nv2. Please continue to do so, probably optimising the code in order to achieve higher performance on existing hardware.
+100 Thanks!

Re: v6.40rc [release candidate] is released!

Posted: Wed May 17, 2017 8:15 am
by anuser
With 6.40rc6 my SNMP counters for uptime, interface traffic and CPU are dead for WAP AC and HAP AC devices.

Logging on devices says: „cannot bind to requested src-address“

After downgrading to 6.40rc5, SNMP access works again.

Re: v6.40rc [release candidate] is released!

Posted: Wed May 17, 2017 9:22 am
by blue
we have added basic info on that in the Nv2 wiki manual. Here is the info:
Nv2-mode - specifies to use dynamic or fixed downlink/uplink ratio. Default value is "dynamic-downlink"
Nv2-downlink-ratio - specifies the Nv2 downlink ratio. Uplink ratio is automatically calculated from the downlink-ratio value. When using dynamic-downlink mode the downlink-ratio is also used when link get fully saturated. Minimum value is 20 and maximum 80. Default value is 50.

Many, many, many thanks for this option. I love it on AirFiber,, and finally there it is for nv2! Working great on my backup link for AF24. Please keep on with nv2 development...

Re: v6.40rc [release candidate] is released!

Posted: Thu May 18, 2017 5:46 pm
by server8
Good job I hope this feature is a step to have soon the gps sync :-)
we have added basic info on that in the Nv2 wiki manual. Here is the info:
Nv2-mode - specifies to use dynamic or fixed downlink/uplink ratio. Default value is "dynamic-downlink"
Nv2-downlink-ratio - specifies the Nv2 downlink ratio. Uplink ratio is automatically calculated from the downlink-ratio value. When using dynamic-downlink mode the downlink-ratio is also used when link get fully saturated. Minimum value is 20 and maximum 80. Default value is 50.

Re: v6.40rc [release candidate] is released!

Posted: Thu May 18, 2017 6:25 pm
by pyjamasam
With 6.40rc6 my SNMP counters for uptime, interface traffic and CPU are dead for WAP AC and HAP AC devices.

Logging on devices says: „cannot bind to requested src-address“

After downgrading to 6.40rc5, SNMP access works again.
I am seeing this error as well. (My Dude server is the device running 6.40rc6 and it can no longer monitor itself due to SNMP not working. It can monitor other devices just fine, but SNMP no longer responds on it.)

chris.

Re: v6.40rc [release candidate] is released!

Posted: Fri May 19, 2017 11:04 am
by Bergante
I am seeing this error as well. (My Dude server is the device running 6.40rc6 and it can no longer monitor itself due to SNMP not working. It can monitor other devices just fine, but SNMP no longer responds on it.)
Same here. I have updated three devices, two of them have lost SNMP.

Re: v6.40rc [release candidate] is released!

Posted: Fri May 19, 2017 11:05 am
by server8
we have added basic info on that in the Nv2 wiki manual. Here is the info:
Nv2-mode - specifies to use dynamic or fixed downlink/uplink ratio. Default value is "dynamic-downlink"
Nv2-downlink-ratio - specifies the Nv2 downlink ratio. Uplink ratio is automatically calculated from the downlink-ratio value. When using dynamic-downlink mode the downlink-ratio is also used when link get fully saturated. Minimum value is 20 and maximum 80. Default value is 50.
Uldis if I use 2 radios on tha same routerboard (e.g, rb922) with the same Nv2-downlink-ratio the trasmission of both radios is syncronized?

Re: v6.40rc [release candidate] is released!

Posted: Fri May 19, 2017 11:56 am
by Resnais
Morning scene,

I have had 0 link downs on my SXT LTE since upgrading-to-v6.40rc6. Its only me, or they managed to sort something out? (hurray, already 3 days without disconnects!)

Image


Thank you!

Re: v6.40rc [release candidate] is released!

Posted: Fri May 19, 2017 11:58 am
by normis
Yes, SXT LTE has improvements in the RC.

Re: v6.40rc [release candidate] is released!

Posted: Fri May 19, 2017 11:59 am
by strods
Version 6.40rc8 has been released.

Changes since previous version:
What's new in 6.40rc8 (2017-May-19 07:00):

*) btest - fixed crash when packet size has been changed during test;
*) defconf - added IPv6 firewall configuration (IPv6 package must be enabled on reset);
*) defconf - replaced IPv4 firewall configuration with improved one;
*) export - added "terse" option;
*) firewall - do not allow to set "rate" value to 0 for "limit" parameter (CLI only);
*) wireless - do not skip >2462 channels if interface is WDS slave;

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

Re: v6.40rc [release candidate] is released!

Posted: Fri May 19, 2017 1:54 pm
by rpingar
we tested latest rc8 and SNMP is not working

Re: v6.40rc [release candidate] is released!

Posted: Fri May 19, 2017 1:54 pm
by Bergante
6.40rc8, SNMP still broken.

From a RB2011 I've just updated:

SNMP, warning, cannot bind to requested src-address

Re: v6.40rc [release candidate] is released!

Posted: Fri May 19, 2017 2:07 pm
by strods
Currently SNMP is broken for those devices which has no IPv6 package enabled. We hope to include fix in next rc release.

Re: v6.40rc [release candidate] is released!

Posted: Fri May 19, 2017 5:03 pm
by patrick7
Good reason to enable IPv6!

Re: v6.40rc [release candidate] is released!

Posted: Fri May 19, 2017 8:01 pm
by idlemind
For those that are curious about the new firewall rules:
  script: #| RouterMode:
          #|  * WAN port is protected by firewall and enabled DHCP client
          #| LAN Configuration:
          #|     switch group: ether2 (master), ether3, ether4, ether5
          #|     IP address 192.168.88.1/24 is set on LAN port
          #|     DHCP Server: enabled;
          #|     DNS: enabled;
          #| WAN (gateway) Configuration:
          #|     gateway:  ether1 ;
          #|     ip4 firewall:  enabled;
          #|     ip6 firewall:  enabled;
          #|     NAT:   enabled;
          
          :log info Starting_defconf_script_;
          :global action;
          #-------------------------------------------------------------------------------
          # Apply configuration.
          # these commands are executed after installation or configuration reset
          #-------------------------------------------------------------------------------
          :if ($action = "apply") do={
          # wait for interfaces
          :local count 0; 
          :while ([/interface ethernet find] = "") do={ 
          :if ($count = 30) do={
          :log warning "DefConf: Unable to find ethernet interfaces";
          /quit;
          }
          :delay 1s; :set count ($count +1); 
          };
          
           /interface ethernet {
             set ether2 name=ether2-master;
             set ether3 master-port=ether2-master;
             set ether4 master-port=ether2-master;
             set ether5 master-port=ether2-master;
           }
             /ip pool add name="default-dhcp" ranges=192.168.88.10-192.168.88.254;
             /ip dhcp-server
               add name=defconf address-pool="default-dhcp" interface=ether2-master lease-time=10m disabled=no;
             /ip dhcp-server network
               add address=192.168.88.0/24 gateway=192.168.88.1 comment="defconf";
            /ip address add address=192.168.88.1/24 interface=ether2-master comment="defconf";
           /ip dns {
               set allow-remote-requests=yes
               static add name=router address=192.168.88.1
           }
          
             /ip dhcp-client add interface=ether1 disabled=no comment="defconf";
           /interface list add name=WAN comment="defconf"
           /interface list add name=LAN comment="defconf"
           /interface list member add list=LAN interface=ether2-master comment="defconf"
           /interface list member add list=WAN interface=ether1 comment="defconf"
           /ip firewall nat add chain=srcnat out-interface-list=WAN action=masquerade comment="defconf: masquerade"
           /ip firewall {
             filter add chain=input action=accept protocol=icmp comment="defconf: accept ICMP after RAW"
             filter add chain=input action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untracked"
             filter add chain=input action=drop in-interface-list=!LAN comment="defconf: drop all not coming from LAN"
             filter add chain=forward action=fasttrack-connection connection-state=established,related comment="defconf: fasttrack"
             filter add chain=forward action=accept connection-state=established,related,untracked comment="defconf: accept established,related, untracked"
             filter add chain=forward action=drop connection-state=invalid comment="defconf: drop invalid"
             filter add chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN comment="defconf:  drop all from WAN not>
             address-list add list=bad_ipv4 address=0.0.0.0/8 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=172.16.0.0/12 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=192.168.0.0/16 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=10.0.0.0/8 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=169.254.0.0/16 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=127.0.0.0/8 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=224.0.0.0/4 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=198.18.0.0/15 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=192.0.0.0/24 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=192.0.2.0/24 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=198.51.100.0/24 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=203.0.113.0/24 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=100.64.0.0/10 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=240.0.0.0/4 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=192.88.99.0/24 comment="defconf: 6to4 relay Anycast RFC 3068"
             raw add chain=prerouting action=accept disabled=yes comment="defconf: enable for transparent firewall"
             raw add chain=prerouting action=drop in-interface-list=WAN src-address-list=bad_ipv4 comment="defconf: drop from bogon IP's"
             raw add chain=prerouting action=drop in-interface-list=LAN src-address=!192.168.88.0/24 comment="defconf: drop local if not from default IP range"
             raw add chain=prerouting action=drop protocol=udp port=0 comment="defconf: drop bad UDP"
             raw add chain=prerouting action=jump jump-target=icmp4 protocol=icmp comment="defconf: jump to ICMP chain"
             raw add chain=prerouting action=jump jump-target=bad_tcp protocol=tcp comment="defconf: jump to TCP chain"
             raw add chain=prerouting action=accept in-interface-list=LAN comment="defconf: accept everything else from LAN"
             raw add chain=prerouting action=drop comment="defconf: drop the rest"
             raw add chain=icmp4 action=accept protocol=icmp icmp-options=0:0 limit=5,10:packet comment="defconf: echo reply"
             raw add chain=icmp4 action=accept protocol=icmp icmp-options=3:0 comment="defconf: net unreachable"
             raw add chain=icmp4 action=accept protocol=icmp icmp-options=3:1 comment="defconf: host unreachable"
             raw add chain=icmp4 action=accept protocol=icmp icmp-options=3:2 comment="defconf: protocol unreachable"
             raw add chain=icmp4 action=accept protocol=icmp icmp-options=3:3 comment="defconf: port unreachable"
             raw add chain=icmp4 action=accept protocol=icmp icmp-options=3:4 comment="defconf: fragmentation needed"
             raw add chain=icmp4 action=accept protocol=icmp icmp-options=8:0 limit=5,10:packet comment="defconf: echo"
             raw add chain=icmp4 action=accept protocol=icmp icmp-options=11:0-255 comment="defconf: time exceeded "
             raw add chain=icmp4 action=drop protocol=icmp comment="defconf: drop other icmp"
             raw add chain=bad_tcp action=drop protocol=tcp tcp-flags=!fin,!syn,!rst,!ack comment="defconf: TCP flag filte"
             raw add chain=bad_tcp action=drop protocol=tcp tcp-flags=fin,syn comment="defconf"
             raw add chain=bad_tcp action=drop protocol=tcp tcp-flags=fin,rst comment="defconf"
             raw add chain=bad_tcp action=drop protocol=tcp tcp-flags=fin,!ack comment="defconf"
             raw add chain=bad_tcp action=drop protocol=tcp tcp-flags=fin,urg comment="defconf"
             raw add chain=bad_tcp action=drop protocol=tcp tcp-flags=syn,rst comment="defconf"
             raw add chain=bad_tcp action=drop protocol=tcp tcp-flags=rst,urg comment="defconf"
             raw add chain=bad_tcp action=drop protocol=tcp port=0 comment="defconf: TCP port 0 drop"
           }
           /ipv6 firewall {
             address-list add list=bad_ipv6 address=::1 comment="defconf: lo"
             address-list add list=bad_ipv6 address=fec0::/10 comment="defconf: site-local"
             address-list add list=bad_ipv6 address=::/96 comment="defconf: ipv4 compat"
             address-list add list=bad_ipv6 address=2001:db8::/32 comment="defconf: documentation"
             address-list add list=bad_ipv6 address=3ffe::/16 comment="defconf: 6bone"
             address-list add list=bad_ipv6 address=::224.0.0.0/100 comment="defconf: other"
             address-list add list=bad_ipv6 address=::127.0.0.0/104 comment="defconf: other"
             address-list add list=bad_ipv6 address=::/104 comment="defconf: other"
             address-list add list=bad_ipv6 address=::255.0.0.0/104 comment="defconf: other"
             raw add chain=prerouting action=accept disabled=yes comment="defconf: enable for transparent firewall"
             raw add chain=prerouting action=drop src-address-list=bad_ipv6 comment="defconf: drop packets with bad src ipv6"
             raw add chain=prerouting action=drop dst-address-list=bad_ipv6 comment="defconf: drop packets with bad dst ipv6"
             raw add chain=prerouting action=jump jump-target=icmp6 protocol=icmpv6 comment="defconf: jump to ICMPv6 chain"
             raw add chain=prerouting action=drop src-address=ff00::/8 comment="defconf: drop if src is multicast"
             raw add chain=prerouting action=accept in-interface-list=LAN dst-address=ff02::/16 comment="defconf: accept local multicast scope from LAN"
             raw add chain=prerouting action=drop dst-address=ff00::/8 comment="defconf: drop other multicast destinations"
             raw add chain=prerouting action=accept in-interface-list=LAN comment="defconf: accept everything else from LAN"
             raw add chain=prerouting action=accept limit=5,10:packet protocol=udp port=33434-33534 comment="defconf: accept UDP traceroute with 5,10 limit"
             raw add chain=prerouting action=accept protocol=udp dst-port=500,4500 comment="defconf: accept IKE"
             raw add chain=prerouting action=accept protocol=ipsec-ah comment="defconf: accept ipsec AH"
             raw add chain=prerouting action=accept protocol=ipsec-esp comment="defconf: accept ipsec ESP"
             raw add chain=prerouting action=accept protocol=139 comment="defconf: accept HIP"
             raw add chain=prerouting action=drop comment="defconf: drop the rest"
             raw add chain=icmp6 action=accept protocol=icmpv6 hop-limit=not-equal:255 dst-address=fe80::/10 comment="defconf: rfc4890 drop ll if hop-limit!=255"
             raw add chain=icmp6 action=accept protocol=icmpv6 icmp-options=1:0-255 comment="defconf: dst unreachable"
             raw add chain=icmp6 action=accept protocol=icmpv6 icmp-options=2:0-255 comment="defconf: packet too big"
             raw add chain=icmp6 action=accept protocol=icmpv6 icmp-options=3:0-1 comment="defconf: limit exceeded"
             raw add chain=icmp6 action=accept protocol=icmpv6 icmp-options=4:0-2 comment="defconf: bad header"
             raw add chain=icmp6 action=accept protocol=icmpv6 icmp-options=144:0-255 comment="defconf: Mobile home agent address discovery"
             raw add chain=icmp6 action=accept protocol=icmpv6 icmp-options=145:0-255 comment="defconf: Mobile home agent address discovery"
             raw add chain=icmp6 action=accept protocol=icmpv6 icmp-options=146:0-255 comment="defconf: Mobile prefix solic"
             raw add chain=icmp6 action=accept protocol=icmpv6 icmp-options=147:0-255 comment="defconf: Mobile prefix advert"
             raw add chain=icmp6 action=accept protocol=icmpv6 icmp-options=128:0-255 limit=5,10:packet comment="defconf: echo request limit 5,10"
             raw add chain=icmp6 action=accept protocol=icmpv6 icmp-options=129:0-255 limit=5,10:packet comment="defconf: echo reply limit 5,10"
             raw add chain=icmp6 action=accept in-interface-list=LAN protocol=icmpv6 icmp-options=133:0-255 limit=5,10:packet hop-limit=equal:255 comment="defconf>
             raw add chain=icmp6 action=accept in-interface-list=LAN protocol=icmpv6 icmp-options=134:0-255 limit=5,10:packet hop-limit=equal:255 comment="defconf>
             raw add chain=icmp6 action=accept in-interface-list=LAN protocol=icmpv6 icmp-options=135:0-255 limit=5,10:packet hop-limit=equal:255 comment="defconf>
             raw add chain=icmp6 action=accept in-interface-list=LAN protocol=icmpv6 icmp-options=136:0-255 limit=5,10:packet hop-limit=equal:255 comment="defconf>
             raw add chain=icmp6 action=drop protocol=icmpv6 comment="defconf: drop other icmp"
             raw add chain=icmp6 action=accept in-interface-list=LAN protocol=icmpv6 icmp-options=141:0-255 limit=5,10:packet hop-limit=equal:255 comment="defconf>
             raw add chain=icmp6 action=accept in-interface-list=LAN protocol=icmpv6 icmp-options=142:0-255 limit=5,10:packet hop-limit=equal:255 comment="defconf>
             filter add chain=input action=accept protocol=icmpv6 comment="defconf: accept ICMPv6 after RAW"
             filter add chain=input action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untracked"
             filter add chain=input action=accept protocol=udp port=33434-33534 comment="defconf: accept UDP traceroute"
             filter add chain=input action=drop in-interface-list=!LAN comment="defconf: drop all not coming from LAN"
             filter add chain=forward action=drop protocol=icmpv6 hop-limit=equal:1 comment="defconf: rfc4890 drop hop-limit=1"
             filter add chain=forward action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untracked"
             filter add chain=forward action=drop connection-state=invalid comment="defconf: drop invalid"
           }
           /ip neighbor discovery set [find name="ether1"] discover=no
           /tool mac-server disable [find];
           /tool mac-server mac-winbox disable [find];
           :foreach k in=[/interface find where !(slave=yes  || name~"ether1")] do={
             :local tmpName [/interface get $k name];
             /tool mac-server add interface=$tmpName disabled=no;
             /tool mac-server mac-winbox add interface=$tmpName disabled=no;
           }
          }
          #-------------------------------------------------------------------------------
          # Revert configuration.
          # these commands are executed if user requests to remove default configuration
          #-------------------------------------------------------------------------------
          :if ($action = "revert") do={
          # remove wan port protection
           /ip firewall raw remove [find comment~"defconf"]
           /ip firewall filter remove [find comment~"defconf"]
           /ip firewall address-list remove [find comment~"defconf"]
           /ipv6 firewall raw remove [find comment~"defconf"]
           /ipv6 firewall filter remove [find comment~"defconf"]
           /ipv6 firewall address-list remove [find comment~"defconf"]
           /ip firewall nat remove [find comment~"defconf"]
           /interface list member remove [find comment~"defconf"]
           /interface list remove [find comment~"defconf"]
           /tool mac-server remove [find interface!=all]
           /tool mac-server set [find] disabled=no
           /tool mac-server mac-winbox remove [find interface!=all]
           /tool mac-server mac-winbox set [find] disabled=no
           /ip neighbor discovery set [find ] discover=yes
             :local o [/ip dhcp-server network find comment="defconf"]
             :if ([:len $o] != 0) do={ /ip dhcp-server network remove $o }
             :local o [/ip dhcp-server find name="defconf" !disabled]
             :if ([:len $o] != 0) do={ /ip dhcp-server remove $o }
             /ip pool {
               :local o [find name="default-dhcp" ranges=192.168.88.10-192.168.88.254]
               :if ([:len $o] != 0) do={ remove $o }
             }
             :local o [/ip dhcp-client find comment="defconf"]
             :if ([:len $o] != 0) do={ /ip dhcp-client remove $o }
           /ip dns {
             set allow-remote-requests=no
             :local o [static find name=router address=192.168.88.1]
             :if ([:len $o] != 0) do={ static remove $o }
           }
           /ip address {
             :local o [find comment="defconf"]
             :if ([:len $o] != 0) do={ remove $o }
           }
           :foreach iface in=[/interface ethernet find] do={
             /interface ethernet set $iface name=[get $iface default-name]
             /interface ethernet set $iface master-port=none
           }
           /interface bridge port remove [find comment="defconf"]
           /interface bridge remove [find comment="defconf"]
          }
          :log info Defconf_script_finished;
I'm glad to see any change that moves us towards more IPv6 functionality. This is definitely a key item that was missing when comparing a MikroTik edge device against a stock install of OpenWRT. I'll be digesting these new rules over the next few days to see if any tweaks are necessary. I'm sure my other forum members will be doing the same.

Side-note: I upgraded my hEX Gr3 from 6.38.5 to 6.40rc8 without any issues. Configuration wasn't overly complex but did contain a number of VLANs, all dual-stacked. Also an IPv6 GRE tunnel wrapped in IPSec is functioning without modification or issue.

Re: v6.40rc [release candidate] is released!

Posted: Fri May 19, 2017 9:29 pm
by soomanyquestions
For those that are curious about the new firewall rules
So how will this affect the performance? Because on routerboard.com there is a really big performance hit the more firewall rules you add and this update adds like 20 new rules.

Re: v6.40rc [release candidate] is released!

Posted: Fri May 19, 2017 10:16 pm
by idlemind
For those that are curious about the new firewall rules
So how will this affect the performance? Because on routerboard.com there is a really big performance hit the more firewall rules you add and this update adds like 20 new rules.
Soomanyquestions, great question. I personally run IPv6 natively with my ISP. I'm not running the default configuration rules but my device is running approximately the same number of rules, both IPv4 and IPv6. This is of course on a hEX, 750G r3. It's running an IPSec site to site VPN (GRE wrapped in IPSec) via IPv6. It also acts as a router on a stick for a handful of VLANs on my local network while routing the traffic of a typical home-user with a typical 20mbps home connection. So I guess my answer is, I don't seem to notice any performance problems with a rule-set of this length on my hardware under my use case which I'd classify as a power user home edge device.

Below you'll find a link to a snap from my monitoring system (LibreNMS) showing CPU usage for the last 24 hours. I had to post the pic on imgur ... apparently this section on the forum doesn't allow uploads.

http://imgur.com/a/MwyH9

As a side note: My SNMPv3 over IPv6 works as smooth as a babies bottom. Sorry dudes and dudettes that are having issues with SNMP over IPv4.

Re: v6.40rc [release candidate] is released!

Posted: Fri May 19, 2017 10:29 pm
by uldis
we have added basic info on that in the Nv2 wiki manual. Here is the info:
Nv2-mode - specifies to use dynamic or fixed downlink/uplink ratio. Default value is "dynamic-downlink"
Nv2-downlink-ratio - specifies the Nv2 downlink ratio. Uplink ratio is automatically calculated from the downlink-ratio value. When using dynamic-downlink mode the downlink-ratio is also used when link get fully saturated. Minimum value is 20 and maximum 80. Default value is 50.
Uldis if I use 2 radios on tha same routerboard (e.g, rb922) with the same Nv2-downlink-ratio the trasmission of both radios is syncronized?
such feature is not made yet

Re: v6.40rc [release candidate] is released!

Posted: Sat May 20, 2017 10:51 pm
by soomanyquestions
For those that are curious about the new firewall rules
So how will this affect the performance? Because on routerboard.com there is a really big performance hit the more firewall rules you add and this update adds like 20 new rules.
Soomanyquestions, great question. I personally run IPv6 natively with my ISP. I'm not running the default configuration rules but my device is running approximately the same number of rules, both IPv4 and IPv6. This is of course on a hEX, 750G r3. It's running an IPSec site to site VPN (GRE wrapped in IPSec) via IPv6. It also acts as a router on a stick for a handful of VLANs on my local network while routing the traffic of a typical home-user with a typical 20mbps home connection. So I guess my answer is, I don't seem to notice any performance problems with a rule-set of this length on my hardware under my use case which I'd classify as a power user home edge device.

Below you'll find a link to a snap from my monitoring system (LibreNMS) showing CPU usage for the last 24 hours. I had to post the pic on imgur ... apparently this section on the forum doesn't allow uploads.

http://imgur.com/a/MwyH9

As a side note: My SNMPv3 over IPv6 works as smooth as a babies bottom. Sorry dudes and dudettes that are having issues with SNMP over IPv4.
Considering that the 750Gr3 should be able to handle many houndred mbps of nat speed, it really shouldnt have a problem with your 20mbps connection even with many rules. But thanks for the data!

Re: v6.40rc [release candidate] is released!

Posted: Sun May 21, 2017 10:57 pm
by smittie2000
*) wireless - added option to change "nv2-downlink-ratio" for nv2 protocol (CLI only);
*) wireless - added option to set "fixed-downlink" mode for nv2 protocol (CLI only);

Thanks very much for this. Tested it straight away it and works great. Throughput went way up for nv2 sector with 20 clients on. Latency stabilized mostly. It did however make client with low ccq on uplink almost useless and in dynamic mode the client is getting decent 4mpbs down and 1mbps up.

nv2 period size =3 ms
nv2 downlink-ratio= 65

Just want to know if that is normal or will final version not punish low ccq so badly? I will rather make a plan for that client and have stable latency and increased clients per sector.

Thanks
Mikrotik Devs

Re: v6.40rc [release candidate] is released!

Posted: Sun May 21, 2017 11:05 pm
by jarda
You should rather give a better antenna to that client. Or make any other structural change of the network if necessary.

Re: v6.40rc [release candidate] is released!

Posted: Mon May 22, 2017 11:09 am
by Bergante
Currently SNMP is broken for those devices which has no IPv6 package enabled. We hope to include fix in next rc release.
Confirmed. Enabling IPv6 fixed it for me.

Re: v6.40rc [release candidate] is released!

Posted: Mon May 22, 2017 11:13 am
by blue
Currently SNMP is broken for those devices which has no IPv6 package enabled. We hope to include fix in next rc release.
Confirmed. Enabling IPv6 fixed it for me.
For me also. It's a workaround.

BR...

Re: v6.40rc [release candidate] is released!

Posted: Mon May 22, 2017 12:05 pm
by dhoulbrooke
*) defconf - replaced IPv4 firewall configuration with improved one;
I've been looking at the new default firewall config - and the below doesn't seem quite right:
/ip firewall raw
add action=drop chain=prerouting comment="defconf: drop the rest"
This rule drops all traffic and nothing is passed to the clients behind the router.

Re: v6.40rc [release candidate] is released!

Posted: Mon May 22, 2017 2:22 pm
by mrz
Finally someone actually tried default configuration :))
Next RC will have rule set improvements.

Re: v6.40rc [release candidate] is released!

Posted: Mon May 22, 2017 5:19 pm
by Chupaka
Finally someone actually tried default configuration :))
you mean, even in MikroTik? :D

Re: v6.40rc [release candidate] is released!

Posted: Mon May 22, 2017 6:07 pm
by jarda
Mikrotik is well aware of it. They are just testing us...

Re: v6.40rc [release candidate] is released!

Posted: Tue May 23, 2017 8:18 pm
by asaf23
Seems like a mess in the response for info command at the LTE interface:
[asaf23@MikroTik] /interface lte> info
number: 0
         pin-status: no password required
      functionality: full
       manufacturer: 
              model: Huawei Technologies Co., Ltd.
           revision: ME909u-521
   current-operator: MTS RUS
     current-cellid: 150xxxxx
  access-technology: Evolved 3G (LTE)
     session-uptime: 49m2s
               imei: 12.636.12.01.00
               imsi: 25001xxxxxxxxxxx
               uicc: 89xxxxxxxxxxxxxx
  subscriber-number: ,"+7xxxxxxxxxxx",145
               rssi: -63dBm
               rsrp: -84dBm
               rsrq: -9dB
               sinr: 12dB
-- [Q quit|D dump|C-z pause]
manufacturer = null, model = manufacturer, revision = model, imei = revision.
And in the winbox after clicking "Info" button in the LTE interface dialog the winbox is closing suddenly.
Please confirm.
Best regards

Re: v6.40rc [release candidate] is released!

Posted: Wed May 24, 2017 8:56 pm
by boldsuck
Finally someone actually tried default configuration :))
That was the first thing I did after reading change log 6.40rc8.
Finally someone actually tried default configuration :))
Next RC will have rule set improvements.
Yes, please add:

/ipv6 firewall filter
add action=accept chain=input comment="Accept DHCPv6-Client prefix delegation." dst-port=546 protocol=udp src-address=fe80::/16

To get the iPv6-Prefix from ISP, we need DHCPv6-PD.

Re: v6.40rc [release candidate] is released!

Posted: Thu May 25, 2017 12:34 am
by uldis
*) wireless - added option to change "nv2-downlink-ratio" for nv2 protocol (CLI only);
*) wireless - added option to set "fixed-downlink" mode for nv2 protocol (CLI only);

Thanks very much for this. Tested it straight away it and works great. Throughput went way up for nv2 sector with 20 clients on. Latency stabilized mostly. It did however make client with low ccq on uplink almost useless and in dynamic mode the client is getting decent 4mpbs down and 1mbps up.

nv2 period size =3 ms
nv2 downlink-ratio= 65

Just want to know if that is normal or will final version not punish low ccq so badly? I will rather make a plan for that client and have stable latency and increased clients per sector.

Thanks
Mikrotik Devs
For the uplink you have left 45% and it looks like it is not enough for poor connections client to send the traffic to the AP. With dnamic-downlink mode most likely the client uses more than 45% and that is why you get more speed.

Re: v6.40rc [release candidate] is released!

Posted: Thu May 25, 2017 10:26 am
by marianob85
6.40rc8 - LTE modem huawei e3372 stops working. Modem is recognise but can not make any connection.
Works correct on 6.40rc6

Re: v6.40rc [release candidate] is released!

Posted: Thu May 25, 2017 11:32 am
by mrz
/ipv6 firewall filter
add action=accept chain=input comment="Accept DHCPv6-Client prefix delegation." dst-port=546 protocol=udp src-address=fe80::/16

To get the iPv6-Prefix from ISP, we need DHCPv6-PD.
Thanks, maybe you have more suggestions what to add or change?

Re: v6.40rc [release candidate] is released!

Posted: Thu May 25, 2017 8:28 pm
by boldsuck
Thanks, maybe you have more suggestions what to add or change?

I've been looking at the new default firewall config - and the below doesn't seem quite right:
/ip firewall raw
add action=drop chain=prerouting comment="defconf: drop the rest"
This rule drops all traffic and nothing is passed to the clients behind the router.
In
/ipv6 firewall raw
the same.

Cosmetic:
In WebFig, the four TCP flags are not displayed when the rule is added in the terminal. (v6.40rc8 on RB2011UAS)
/ip firewall raw
add action=drop chain=bad_tcp comment="defconf: TCP flag filte" protocol=tcp tcp-flags=!fin,!syn,!rst,!ack

Re: v6.40rc [release candidate] is released!

Posted: Fri May 26, 2017 8:37 am
by irghost
Version 6.40rc8 has been released.
*) defconf - added IPv6 firewall configuration (IPv6 package must be enabled on reset);
*) defconf - replaced IPv4 firewall configuration with improved one;
nice RC
it's messed up everything

Re: v6.40rc [release candidate] is released!

Posted: Fri May 26, 2017 11:15 am
by strods
Version 6.40rc13 has been released.
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 version:
*) bonding - do not add bonding interface if "could not set MTU" error is received;
*) defconf - added IPv6 firewall configuration (IPv6 package must be enabled on reset);
*) defconf - renamed 192.168.88.1 address static DNS entry from "router" to "router.lan";
*) export - removed spare "caller-id-type" value from compact export;
*) firewall - do not allow to set "rate" value to 0 for "limit" parameter;
*) gps - removed duplicate logs;
*) hotspot - require "dns-name" to contain "." symbol under Hotspot Server Profile configuration;
*) ike1 - removed xauth login length limitation;
*) ike2 - by default use "/24" netmask for peer IP address in split net;
*) ike2 - fixed situation when traffic selector prefix was parsed incorrectly;
*) ipsec - fixed generated policy priority;
*) ipsec - fixed peer "my-id" address reset;
*) ipsec - renamed "remote-dynamic-address" to "dynamic-address";
*) lte - fixed configless modem running state (introduced in 6.40rc);
*) ppp - fixed "change-mss" functionality (introduced in 6.39);
*) ppp - send correct IP address in RADIUS "accounting-stop" messages (introduced in 6.39);
*) pppoe-client - removed false warning from client interface if it starts running on non-slave interface;
*) proxy - fixed potential crash;
*) queue - fixed queuing when at least one child queue has "default-small" and other/s is/are different (introduced in 6.35);
*) quickset - fixed LTE "signal-strength" graphs;
*) quickset - use active user name and permissions when applying changes;
*) snmp - added ability to set "src-address";
*) tile - fixed rare encryption kernel failure when small packets are processed;
*) ups - show correct "line-voltage" value for usbhid UPS devices;
*) winbox - fixed LTE info button;
*) winbox - removed spare values from "loop-protect" setting for EoIPv6 tunnels;
*) wireless - added option to change "nv2-downlink-ratio" for nv2 protocol;
*) wireless - added option to set "fixed-downlink" mode for nv2 protocol;
*) wireless - reduced load on CPU for high speed wireless links;

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

Re: v6.40rc [release candidate] is released!

Posted: Fri May 26, 2017 12:59 pm
by irghost
Version 6.40rc13 has been released.


Changes since previous version:

*) defconf - added IPv6 firewall configuration (IPv6 package must be enabled on reset);
*) defconf - renamed 192.168.88.1 address static DNS entry from "router" to "router.lan";
Prefect
there is no problem with firewall ipv4-v6

Re: v6.40rc [release candidate] is released!

Posted: Fri May 26, 2017 1:29 pm
by GreySer
Version 6.40rc13 has been released.
RB3011 dead after update.

Re: v6.40rc [release candidate] is released!

Posted: Fri May 26, 2017 1:56 pm
by strods
GreySer - From which version did you upgrade your device?

Re: v6.40rc [release candidate] is released!

Posted: Fri May 26, 2017 1:58 pm
by GreySer
GreySer - From which version did you upgrade your device?
From the previous one RC.
It seems 6.40rc8 or rc9

Re: v6.40rc [release candidate] is released!

Posted: Fri May 26, 2017 2:07 pm
by Chupaka
Version 6.40rc13 has been released.
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.
what's so special in this version?..

Re: v6.40rc [release candidate] is released!

Posted: Fri May 26, 2017 2:33 pm
by strods
GreySer - Connect serial console to router, power it on and send output of serial console to support@mikrotik.com
Chupaka - Nothing! Just added this for the first time. Many users forget about such things and blame version, however problem is not related to it at all.

Re: v6.40rc [release candidate] is released!

Posted: Fri May 26, 2017 2:37 pm
by GreySer
GreySer - Connect serial console to router, power it on and send output of serial console to support@mikrotik.com
So lazily.
First I'll try netinstall. But after 17:00 msk.

Re: v6.40rc [release candidate] is released!

Posted: Fri May 26, 2017 3:33 pm
by MartinT
Version 6.40rc13 has been released.
*) queue - fixed queuing when at least one child queue has "default-small" and other/s is/are different (introduced in 6.35);
Can you point to some more info about this problem ?

Thanks in advance

Re: v6.40rc [release candidate] is released!

Posted: Fri May 26, 2017 3:44 pm
by strods
MartinT - Due to this problem it was possible that queue limit is set, for example, 10M, but you can not reach such high value in any way.

Re: v6.40rc [release candidate] is released!

Posted: Fri May 26, 2017 4:54 pm
by nkourtzis
*) wireless - reduced load on CPU for high speed wireless links;
Can you elaborate on this? What types of links are benefited and by how much?

Re: v6.40rc [release candidate] is released!

Posted: Fri May 26, 2017 5:00 pm
by antonsb
*) wireless - reduced load on CPU for high speed wireless links;
Can you elaborate on this? What types of links are benefited and by how much?
Reduced 802.11ac load on processor. This may reduce processor usage for other protocols too.

Re: v6.40rc [release candidate] is released!

Posted: Fri May 26, 2017 5:07 pm
by nkourtzis
*) wireless - reduced load on CPU for high speed wireless links;
Can you elaborate on this? What types of links are benefited and by how much?
Reduced 802.11ac load on processor. This may reduce processor usage for other protocols too.
Can this mean that NV2 on 802.11ac will also run better?

Re: v6.40rc [release candidate] is released!

Posted: Fri May 26, 2017 8:33 pm
by Ramas
Prefect
there is no problem with firewall ipv4-v6
Well,
i suggest to add this rule to IPv6 firewall (after "defconf: rfc4890 drop hop-limit=1"):
/ipv6 firewall filter
add action=accept chain=forward comment="defconf: accept ICMPv6 to LAN" protocol=icmpv6
In IPv6 networks, ICMP traffic needs to be allowed throughout the entire data path to support fragmentation. This means that even from external networks, you must allow at least ICMP Type 2 packets into your network.

Suggest to remove another RAW rule also:
/ip firewall raw
add action=drop chain=prerouting comment="defconf: drop local if not from default IP range" in-interface-list=LAN src-address=!192.168.88.0/24
I see troubles getting IP address from DHCP in local LAN.
I see in Log these messages when enabling logging for this rule:
18:13:48 firewall,info prerouting: in:bridge out:(none), src-mac *:*:*:*:*:*, proto UDP, 0.0.0.0:68->255.255.255.255:67, len 333
18:22:50 firewall,info prerouting: in:bridge out:(none), src-mac *:*:*:*:*:*, proto UDP, 0.0.0.0:68->255.255.255.255:67, len 333

After that default firewall config almoust ideal in my opinion.
For myself i changed rule in IPv4 firewall from
action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
to
action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related dscp=0
and in mangle added
/ip firewall mangle
add action=set-priority chain=postrouting comment="Respect DSCP tagging" new-priority=from-dscp-high-3-bits passthrough=yes
---
Ramas

Re: v6.40rc [release candidate] is released!

Posted: Fri May 26, 2017 9:09 pm
by ivicask
Hm, i upgraded my WAP AC to RC 13 and i cant connect to router anymore via HTTP or WINBOX via IP, i can only connect via WINBOX via MAC address.Also router it self doesn't have access to internet anymore(cant check for new version, connection timed out)Other than that everything else works, internet on rest of network, port forwarding and remote access etc..
I tried disabling all firewall rules for test that didint help.All interfaces have proper ip addresses just as before and i can ping router from CMD.What could possible cause this?I can try reverting router to previous version but only tomorrow..

Re: v6.40rc [release candidate] is released!

Posted: Sat May 27, 2017 9:07 pm
by Z12
Version 6.40rc13
RB2011 boot loop

upgrade from 6.40rc8

Re: v6.40rc [release candidate] is released!

Posted: Sun May 28, 2017 1:33 pm
by biatche
can anyone paste what the new default firewall config look like right now? i dont wanna install the latest rc as of yet.

Re: v6.40rc [release candidate] is released!

Posted: Sun May 28, 2017 1:58 pm
by dhoulbrooke
can anyone paste what the new default firewall config look like right now? i dont wanna install the latest rc as of yet.
Here you go:
           /ip firewall nat add chain=srcnat out-interface-list=WAN action=masquerade comment="defconf: masquerade"
           /ip firewall {
             filter add chain=input action=accept protocol=icmp comment="defconf: accept ICMP after RAW"
             filter add chain=input action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untracked"
             filter add chain=input action=drop in-interface-list=!LAN comment="defconf: drop all not coming from LAN"
             filter add chain=forward action=fasttrack-connection connection-state=established,related comment="defconf: fasttrack"
             filter add chain=forward action=accept connection-state=established,related,untracked comment="defconf: accept established,related, untracked"
             filter add chain=forward action=drop connection-state=invalid comment="defconf: drop invalid"
             filter add chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN comment="defconf:  drop all from WAN not DSTNATed"
             address-list add list=bad_ipv4 address=0.0.0.0/8 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=172.16.0.0/12 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=192.168.0.0/16 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=10.0.0.0/8 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=169.254.0.0/16 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=127.0.0.0/8 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=224.0.0.0/4 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=198.18.0.0/15 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=192.0.0.0/24 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=192.0.2.0/24 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=198.51.100.0/24 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=203.0.113.0/24 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=100.64.0.0/10 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=240.0.0.0/4 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=192.88.99.0/24 comment="defconf: 6to4 relay Anycast RFC 3068"
             raw add chain=prerouting action=accept disabled=yes comment="defconf: enable for transparent firewall"
             raw add chain=prerouting action=drop in-interface-list=WAN src-address-list=bad_ipv4 comment="defconf: drop from bogon IP's"
             raw add chain=prerouting action=drop in-interface-list=LAN src-address=!192.168.88.0/24 comment="defconf: drop local if not from default IP range"
             raw add chain=prerouting action=drop protocol=udp port=0 comment="defconf: drop bad UDP"
             raw add chain=prerouting action=jump jump-target=icmp4 protocol=icmp comment="defconf: jump to ICMP chain"
             raw add chain=prerouting action=jump jump-target=bad_tcp protocol=tcp comment="defconf: jump to TCP chain"
             raw add chain=prerouting action=accept in-interface-list=LAN comment="defconf: accept everything else from LAN"
             raw add chain=prerouting action=accept in-interface-list=WAN comment="defconf: accept everything else from WAN"
             raw add chain=prerouting action=drop comment="defconf: drop the rest"
             raw add chain=icmp4 action=accept protocol=icmp icmp-options=0:0 limit=5,10:packet comment="defconf: echo reply"
             raw add chain=icmp4 action=accept protocol=icmp icmp-options=3:0 comment="defconf: net unreachable"
             raw add chain=icmp4 action=accept protocol=icmp icmp-options=3:1 comment="defconf: host unreachable"
             raw add chain=icmp4 action=accept protocol=icmp icmp-options=3:2 comment="defconf: protocol unreachable"
             raw add chain=icmp4 action=accept protocol=icmp icmp-options=3:3 comment="defconf: port unreachable"
             raw add chain=icmp4 action=accept protocol=icmp icmp-options=3:4 comment="defconf: fragmentation needed"
             raw add chain=icmp4 action=accept protocol=icmp icmp-options=8:0 limit=5,10:packet comment="defconf: echo"
             raw add chain=icmp4 action=accept protocol=icmp icmp-options=11:0-255 comment="defconf: time exceeded "
             raw add chain=icmp4 action=drop protocol=icmp comment="defconf: drop other icmp"
             raw add chain=bad_tcp action=drop protocol=tcp tcp-flags=!fin,!syn,!rst,!ack comment="defconf: TCP flag filte"
             raw add chain=bad_tcp action=drop protocol=tcp tcp-flags=fin,syn comment="defconf"
             raw add chain=bad_tcp action=drop protocol=tcp tcp-flags=fin,rst comment="defconf"
             raw add chain=bad_tcp action=drop protocol=tcp tcp-flags=fin,!ack comment="defconf"
             raw add chain=bad_tcp action=drop protocol=tcp tcp-flags=fin,urg comment="defconf"
             raw add chain=bad_tcp action=drop protocol=tcp tcp-flags=syn,rst comment="defconf"
             raw add chain=bad_tcp action=drop protocol=tcp tcp-flags=rst,urg comment="defconf"
             raw add chain=bad_tcp action=drop protocol=tcp port=0 comment="defconf: TCP port 0 drop"
           }

Re: v6.40rc [release candidate] is released!

Posted: Sun May 28, 2017 8:00 pm
by biatche
can anyone paste what the new default firewall config look like right now? i dont wanna install the latest rc as of yet.
Here you go:
           /ip firewall nat add chain=srcnat out-interface-list=WAN action=masquerade comment="defconf: masquerade"
           /ip firewall {
             filter add chain=input action=accept protocol=icmp comment="defconf: accept ICMP after RAW"
             filter add chain=input action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untracked"
             filter add chain=input action=drop in-interface-list=!LAN comment="defconf: drop all not coming from LAN"
             filter add chain=forward action=fasttrack-connection connection-state=established,related comment="defconf: fasttrack"
             filter add chain=forward action=accept connection-state=established,related,untracked comment="defconf: accept established,related, untracked"
             filter add chain=forward action=drop connection-state=invalid comment="defconf: drop invalid"
             filter add chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN comment="defconf:  drop all from WAN not DSTNATed"
             address-list add list=bad_ipv4 address=0.0.0.0/8 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=172.16.0.0/12 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=192.168.0.0/16 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=10.0.0.0/8 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=169.254.0.0/16 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=127.0.0.0/8 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=224.0.0.0/4 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=198.18.0.0/15 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=192.0.0.0/24 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=192.0.2.0/24 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=198.51.100.0/24 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=203.0.113.0/24 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=100.64.0.0/10 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=240.0.0.0/4 comment="defconf: RFC6890"
             address-list add list=bad_ipv4 address=192.88.99.0/24 comment="defconf: 6to4 relay Anycast RFC 3068"
             raw add chain=prerouting action=accept disabled=yes comment="defconf: enable for transparent firewall"
             raw add chain=prerouting action=drop in-interface-list=WAN src-address-list=bad_ipv4 comment="defconf: drop from bogon IP's"
             raw add chain=prerouting action=drop in-interface-list=LAN src-address=!192.168.88.0/24 comment="defconf: drop local if not from default IP range"
             raw add chain=prerouting action=drop protocol=udp port=0 comment="defconf: drop bad UDP"
             raw add chain=prerouting action=jump jump-target=icmp4 protocol=icmp comment="defconf: jump to ICMP chain"
             raw add chain=prerouting action=jump jump-target=bad_tcp protocol=tcp comment="defconf: jump to TCP chain"
             raw add chain=prerouting action=accept in-interface-list=LAN comment="defconf: accept everything else from LAN"
             raw add chain=prerouting action=accept in-interface-list=WAN comment="defconf: accept everything else from WAN"
             raw add chain=prerouting action=drop comment="defconf: drop the rest"
             raw add chain=icmp4 action=accept protocol=icmp icmp-options=0:0 limit=5,10:packet comment="defconf: echo reply"
             raw add chain=icmp4 action=accept protocol=icmp icmp-options=3:0 comment="defconf: net unreachable"
             raw add chain=icmp4 action=accept protocol=icmp icmp-options=3:1 comment="defconf: host unreachable"
             raw add chain=icmp4 action=accept protocol=icmp icmp-options=3:2 comment="defconf: protocol unreachable"
             raw add chain=icmp4 action=accept protocol=icmp icmp-options=3:3 comment="defconf: port unreachable"
             raw add chain=icmp4 action=accept protocol=icmp icmp-options=3:4 comment="defconf: fragmentation needed"
             raw add chain=icmp4 action=accept protocol=icmp icmp-options=8:0 limit=5,10:packet comment="defconf: echo"
             raw add chain=icmp4 action=accept protocol=icmp icmp-options=11:0-255 comment="defconf: time exceeded "
             raw add chain=icmp4 action=drop protocol=icmp comment="defconf: drop other icmp"
             raw add chain=bad_tcp action=drop protocol=tcp tcp-flags=!fin,!syn,!rst,!ack comment="defconf: TCP flag filte"
             raw add chain=bad_tcp action=drop protocol=tcp tcp-flags=fin,syn comment="defconf"
             raw add chain=bad_tcp action=drop protocol=tcp tcp-flags=fin,rst comment="defconf"
             raw add chain=bad_tcp action=drop protocol=tcp tcp-flags=fin,!ack comment="defconf"
             raw add chain=bad_tcp action=drop protocol=tcp tcp-flags=fin,urg comment="defconf"
             raw add chain=bad_tcp action=drop protocol=tcp tcp-flags=syn,rst comment="defconf"
             raw add chain=bad_tcp action=drop protocol=tcp tcp-flags=rst,urg comment="defconf"
             raw add chain=bad_tcp action=drop protocol=tcp port=0 comment="defconf: TCP port 0 drop"
           }
thanks, with this ruleset, will i need
7x similar rules for: raw add chain=prerouting action=drop in-interface-list=LAN src-address=!192.168.88.0/24 comment="defconf: drop local if not from default IP range" ?

i have 7 different vlans for 7 different lan subnets.

Re: v6.40rc [release candidate] is released!

Posted: Mon May 29, 2017 7:48 am
by dhoulbrooke
thanks, with this ruleset, will i need
7x similar rules for: raw add chain=prerouting action=drop in-interface-list=LAN src-address=!192.168.88.0/24 comment="defconf: drop local if not from default IP range" ?

i have 7 different vlans for 7 different lan subnets.
You could still have the one rule and use an address list:

https://wiki.mikrotik.com/wiki/Manual:I ... dress_list

Re: v6.40rc [release candidate] is released!

Posted: Mon May 29, 2017 7:48 am
by sparker
Hello. When will it be possible to test mstp? :)

Re: v6.40rc [release candidate] is released!

Posted: Mon May 29, 2017 10:15 am
by biatche
Hello. When will it be possible to test mstp? :)
ive had numerous temptations to ask. so yeah lets see mstp, say next rc?

Re: v6.40rc [release candidate] is released!

Posted: Mon May 29, 2017 11:22 am
by joserudi
Fixed the correct ip but continues to stop users with time until you make a database rebuild

ppp - send correct IP address in RADIUS "accounting-stop" messages (introduced in 6.39);

Re: v6.40rc [release candidate] is released!

Posted: Mon May 29, 2017 11:50 am
by anuser
Version 6.40rc13 has been released.
*) wireless - added option to change "nv2-downlink-ratio" for nv2 protocol;
*) wireless - added option to set "fixed-downlink" mode for nv2 protocol;
*) wireless - reduced load on CPU for high speed wireless links;
Wireless with CAPSMAN forwarding seems to be improved for me, at least somehow. I currently have ~300 connected clients on ~25 WAP AC/HAP AC/HAP AC lite and find less "disconnected, group key timeout" messages on 2.4Ghz connected clients within logging. Before that release I had hundreds/too much of them. Did you change anything else with wireless package?

Re: v6.40rc [release candidate] is released!

Posted: Mon May 29, 2017 2:00 pm
by mrz
Prefect
there is no problem with firewall ipv4-v6
Well,
i suggest to add this rule to IPv6 firewall (after "defconf: rfc4890 drop hop-limit=1"):
/ipv6 firewall filter
add action=accept chain=forward comment="defconf: accept ICMPv6 to LAN" protocol=icmpv6
---
Ramas
Thanks for the input. We will improve FW rule set.

Re: v6.40rc [release candidate] is released!

Posted: Mon May 29, 2017 3:57 pm
by timking
Have emailed suppport but cannot set scan-list in /interface wireless to a bespoke value if you set it to eg bandb it actually sets it to bandb;bandb and then the radio stops working.
Can't set it in webfig either. Tools/telnet in webfig also broken.

Re: v6.40rc [release candidate] is released!

Posted: Mon May 29, 2017 4:22 pm
by jarda
Looks like SNMP problems with earlier RC versions are corrected. Thanks.

Re: v6.40rc [release candidate] is released!

Posted: Mon May 29, 2017 8:15 pm
by andreadg88
Hi,
have you identified a date that rel v.6.40 exit from release candidate roadmap?

Re: v6.40rc [release candidate] is released!

Posted: Mon May 29, 2017 9:38 pm
by jarda
None knows that.

Re: v6.40rc [release candidate] is released!

Posted: Tue May 30, 2017 9:47 am
by biatche
None knows that.
i do -- right after mstp.

i hope

Re: v6.40rc [release candidate] is released!

Posted: Tue May 30, 2017 10:03 am
by strods
Version 6.40rc14 has been released.
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 version:
*) chr - maximal system disk size now limited to 16GB;
*) fetch - added "src-address" parameter for HTTP and HTTPS;
*) pppoe-server - fixed "one-session-per-host" issue where 2 simultaneous sessions were possible from the same host;
*) snmp - fixed crash on interface table get;
*) winbox - added "reselect-channel" to CAPsMAN interfaces;
*) winbox - fixed firewall port selection with Winbox v2;

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

Re: v6.40rc [release candidate] is released!

Posted: Tue May 30, 2017 10:41 am
by GreySer
Version 6.40rc14 has been released.
RB2011 RB3011 bootlop fixed ? Safe to install ?

Re: v6.40rc [release candidate] is released!

Posted: Tue May 30, 2017 10:46 am
by strods
GreySer - There is not generic bootloop with RB2011 and RB3011. It must be caused either by problems during upgrade process (for example, power cycle during upgrade) or specific configuration. Please write to support@mikrotik.com and report your problem. Provide configuration files, explanation and serial output during reboot loop and even better - one from upgrade process.

Re: v6.40rc [release candidate] is released!

Posted: Tue May 30, 2017 10:59 am
by GreySer
GreySer - There is not generic bootloop with RB2011 and RB3011. It must be caused either by problems during upgrade process (for example, power cycle during upgrade) or specific configuration. Please write to support@mikrotik.com and report your problem. Provide configuration files, explanation and serial output during reboot loop and even better - one from upgrade process.
Updated now from 6.39.1 , succesfull.

Re: v6.40rc [release candidate] is released!

Posted: Wed May 31, 2017 11:18 am
by strods
Version 6.40rc15 has been released.
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 version:
!) ipsec - added support for dynamic "action=notrack" RAW rules for policies;
*) defconf - added accept ICMPv6 in forward and DHCP discover in RAW prerouting;
*) ike2 - added pfkey kernel return checks;
*) ipsec - added information in console XML for "mode-config" menu;
*) ipsec - fixed connections cleanup on policy or proposal modification;
*) ipsec - removed policy priority;
*) ppp - fixed MLPPP over multiple channels/interfaces (introduced in v6.39);

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

Re: v6.40rc [release candidate] is released!

Posted: Wed May 31, 2017 12:41 pm
by biatche
!) ipsec - added support for dynamic "action=notrack" RAW rules for policies;
can anybody share optimal firewall rules for l2tp/ipsec and ikev2 ipsec with regards to fasttrack

Re: v6.40rc [release candidate] is released!

Posted: Wed May 31, 2017 2:41 pm
by jKonstantin
Now 2017 year. Device rb750gr3 dont support metarouter because uses "SPI flash" category. Where UDP and LZO support in openvpn? Where fairy tale about ROS7? Zyxel is already support both.

Re: v6.40rc [release candidate] is released!

Posted: Wed May 31, 2017 5:36 pm
by mtivi
Now in ip firewall:
/ip firewall address-list
add address=100.64.0.0/10 comment="defconf: RFC6890" list=bad_ipv4
/ip firewall raw
add action=drop chain=prerouting comment="defconf: drop from bogon IP's" in-interface-list=WAN src-address-list=bad_ipv4
I don't like this.

This valid address for WAN interface for end user.

Many ISP use CGN network.

Re: v6.40rc [release candidate] is released!

Posted: Wed May 31, 2017 9:26 pm
by Ramas
The Shared Address Space address range is 100.64.0.0/10
Shared Address Space can only be used in Service Provider networks or on routing equipment that is able to do address translation across router the interfaces when addresses are identical on two different interfaces

---
Ramas

Re: v6.40rc [release candidate] is released!

Posted: Wed May 31, 2017 10:55 pm
by sup5
IP addresses from the shared transition space are given out to end-users/customers in case the provider lacks public IPv4-addresses.
This is commonly referred as NAT444.

Re: v6.40rc [release candidate] is released!

Posted: Thu Jun 01, 2017 10:00 am
by kujo
Hi!
Do we need add in last position of chain=bad_tcp RETURN rule?
/ip firewall raw add action=return chain=bad_tcp

Re: RE: Re: v6.40rc [release candidate] is released!

Posted: Thu Jun 01, 2017 7:11 pm
by alexjhart
Hi!
Do we need add in last position of chain=bad_tcp RETURN rule?
/ip firewall raw add action=return chain=bad_tcp
Return is the default when reaching the end of a custom chain, I assume that applies here too, making it unnecessary. So the answer would be no.

Re: v6.40rc [release candidate] is released!

Posted: Sat Jun 03, 2017 4:37 pm
by amokkatmt
How this " !) ipsec - added support for dynamic "action=notrack" RAW rules for policies;" can be disabled? I need to src-nat ipsec decrypted client traffic in roadwarrior setup. Because of those rules NAT is bypassed and things are broken.

Re: v6.40rc [release candidate] is released!

Posted: Sat Jun 03, 2017 5:16 pm
by Sob
I agree with previous post. It's not just NAT, what if I need "one-way tunnel", i.e. allow new connections from network A to network B, but not from network B to network A? Now I can allow one way, allow established connections and block the other. But these new dynamic raw rules break this. It's a nice feature, but it needs to be optional.

Re: v6.40rc [release candidate] is released!

Posted: Sun Jun 04, 2017 5:12 am
by x4nd3m4c
Just installed version 6.40rc15 to fix the PPPoE server problem on my RB1100AHx2 and now my OVPN client can't connect using TLS.
It does work with version 6.38.5
Please fix it.

Re: v6.40rc [release candidate] is released!

Posted: Mon Jun 05, 2017 7:35 pm
by boldsuck
New default-IPv6 firewall from v6.40rc15
/system default-configuration print:
/ipv6 firewall {
address-list add list=bad_ipv6 address=::1 comment="defconf: lo"
address-list add list=bad_ipv6 address=fec0::/10 comment="defconf: site-local"
address-list add list=bad_ipv6 address=::/96 comment="defconf: ipv4 compat"
address-list add list=bad_ipv6 address=2001:db8::/32 comment="defconf: documentation"
address-list add list=bad_ipv6 address=3ffe::/16 comment="defconf: 6bone"
address-list add list=bad_ipv6 address=::224.0.0.0/100 comment="defconf: other"
address-list add list=bad_ipv6 address=::127.0.0.0/104 comment="defconf: other"
address-list add list=bad_ipv6 address=::/104 comment="defconf: other"
address-list add list=bad_ipv6 address=::255.0.0.0/104 comment="defconf: other"
             
raw add chain=prerouting action=accept disabled=yes comment="defconf: enable for transparent firewall"
raw add chain=prerouting action=drop src-address-list=bad_ipv6 comment="defconf: drop packets with bad src ipv6"
raw add chain=prerouting action=drop dst-address-list=bad_ipv6 comment="defconf: drop packets with bad dst ipv6"
raw add chain=prerouting action=jump jump-target=icmp6 protocol=icmpv6 comment="defconf: jump to ICMPv6 chain"
raw add chain=prerouting action=drop src-address=ff00::/8 comment="defconf: drop if src is multicast"
raw add chain=prerouting action=accept dst-address=ff02::/16 comment="defconf: accept local multicast scope"
raw add chain=prerouting action=drop dst-address=ff00::/8 comment="defconf: drop other multicast destinations"
raw add chain=prerouting action=accept in-interface-list=WAN comment="defconf: accept everything else from WAN"
raw add chain=prerouting action=accept in-interface-list=LAN comment="defconf: accept everything else from LAN"
raw add chain=prerouting action=drop comment="defconf: drop the rest"
"defconf: rfc4890 drop ll if hop-limit!=255"
'action=accept'? If I understand RFC 4890 correctly, should be 'action=drop' here.
Perhaps a native English-speaking one understands this better:

Davies & Mohacsi Informational [Page 12]

RFC 4890 ICMPv6 Filtering Recommendations May 2007

4.2. Interaction of Link-Local Messages with Firewall/Routers and
Firewall/Bridges

Firewalls can be implemented both as IP routers (firewall/routers)
and as link layer bridges (e.g., Ethernet bridges) that are
transparent to the IP layer although they will actually be inspecting
the IP packets as they pass through (firewall/bridges).

Many of the messages used for establishment and maintenance of
communications on the local link will be sent with link-local
addresses for at least one of their source and destination. Routers
conforming to the IPv6 standards will not forward these packets;
there is no need to configure additional rules to prevent these
packets traversing a firewall/router, although administrators may
wish to configure rules that would drop these packets for insurance
and as a means of monitoring for attacks. Also, the specifications
of ICMPv6 messages intended for use only on the local link specify
various measures that would allow receivers to detect if the message
had passed through a router, including:

o Requiring that the hop limit in the IPv6 header is set to 255 on
transmission. Receivers verify that the hop limit is still 255,
to ensure that the packet has not passed through a router.

o Checking that the source address is a link-local unicast address.
 
raw add chain=icmp6 action=accept protocol=icmpv6 hop-limit=not-equal:255 dst-address=fe80::/10 comment="defconf: rfc4890 drop ll if hop-limit!=255"
raw add chain=icmp6 action=accept protocol=icmpv6 icmp-options=1:0-255 comment="defconf: dst unreachable"
raw add chain=icmp6 action=accept protocol=icmpv6 icmp-options=2:0-255 comment="defconf: packet too big"
raw add chain=icmp6 action=accept protocol=icmpv6 icmp-options=3:0-1 comment="defconf: limit exceeded"
raw add chain=icmp6 action=accept protocol=icmpv6 icmp-options=4:0-2 comment="defconf: bad header"
raw add chain=icmp6 action=accept protocol=icmpv6 icmp-options=144:0-255 comment="defconf: Mobile home agent address discovery"
raw add chain=icmp6 action=accept protocol=icmpv6 icmp-options=145:0-255 comment="defconf: Mobile home agent address discovery"
raw add chain=icmp6 action=accept protocol=icmpv6 icmp-options=146:0-255 comment="defconf: Mobile prefix solic"
raw add chain=icmp6 action=accept protocol=icmpv6 icmp-options=147:0-255 comment="defconf: Mobile prefix advert"
raw add chain=icmp6 action=accept protocol=icmpv6 icmp-options=128:0-255 limit=5,10:packet comment="defconf: echo request limit 5,10"
raw add chain=icmp6 action=accept protocol=icmpv6 icmp-options=129:0-255 limit=5,10:packet comment="defconf: echo reply limit 5,10"
raw add chain=icmp6 action=accept in-interface-list=LAN protocol=icmpv6 icmp-options=133:0-255 limit=5,10:packet hop-limit=equal:255 comment="defconf: rfc4890 router solic limit 5,10 only LAN"
raw add chain=icmp6 action=accept in-interface-list=LAN protocol=icmpv6 icmp-options=134:0-255 limit=5,10:packet hop-limit=equal:255 comment="defconf: rfc4890 router advert limit 5,10 only LAN"
Uncertain whether this is necessary? I accept Router Advertisements from my ISP here:

raw add chain=icmp6 action=accept in-interface=pppoe-out1 protocol=icmpv6 icmp-options=134:0-255 limit=5,10:packet hop-limit=equal:255 dst-address=ff02::/16 src-address=fe80::/16 comment="ISP Gateway: Router advert limit 5,10"
raw add chain=icmp6 action=accept in-interface-list=LAN protocol=icmpv6 icmp-options=135:0-255 limit=5,10:packet hop-limit=equal:255 comment="defconf: rfc4890 neighbor solic limit 5,10 only LAN"
raw add chain=icmp6 action=accept in-interface-list=LAN protocol=icmpv6 icmp-options=136:0-255 limit=5,10:packet hop-limit=equal:255 comment="defconf: rfc4890 neighbor advert limit 5,10 only LAN"
Must not the drop rule be the last in the raw icmp6 chain?
raw add chain=icmp6 action=drop protocol=icmpv6 comment="defconf: drop other icmp"
raw add chain=icmp6 action=accept in-interface-list=LAN protocol=icmpv6 icmp-options=141:0-255 limit=5,10:packet hop-limit=equal:255 comment="defconf: rfc4890 inverse ND solic limit 5,10 only LAN"
raw add chain=icmp6 action=accept in-interface-list=LAN protocol=icmpv6 icmp-options=142:0-255 limit=5,10:packet hop-limit=equal:255 comment="defconf: rfc4890 inverse ND advert limit 5,10 only LAN"
filter add chain=input action=accept protocol=icmpv6 comment="defconf: accept ICMPv6 after RAW"
filter add chain=input action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untracked"
filter add chain=input action=accept protocol=udp port=33434-33534 comment="defconf: accept UDP traceroute"
filter add chain=input action=accept protocol=udp dst-port=546 src-address=fe80::/16 comment="defconf: accept DHCPv6-Client prefix delegation."
filter add chain=input action=accept protocol=udp dst-port=500,4500 comment="defconf: accept IKE"
filter add chain=input action=accept protocol=ipsec-ah comment="defconf: accept ipsec AH"
filter add chain=input action=accept protocol=ipsec-esp comment="defconf: accept ipsec ESP"
filter add chain=input action=drop in-interface-list=!LAN comment="defconf: drop all not coming from LAN"
filter add chain=forward action=drop protocol=icmpv6 hop-limit=equal:1 comment="defconf: rfc4890 drop hop-limit=1"
filter add chain=forward action=accept protocol=icmpv6 comment="defconf: accept ICMPv6 after RAW"
filter add chain=forward action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untracked"
filter add chain=forward action=drop connection-state=invalid comment="defconf: drop invalid"
filter add chain=forward action=accept protocol=139 comment="defconf: accept HIP"
filter add chain=forward action=drop in-interface-list=!LAN comment="defconf: drop everything else not coming from LAN"
}

Re: v6.40rc [release candidate] is released!

Posted: Mon Jun 05, 2017 11:29 pm
by anuser
I noticed that "caps scanner" button within CAPSMAN => registration table. Hitting that button and selecting any master interface results in "ERROR: feature is not implemented"?

Re: v6.40rc [release candidate] is released!

Posted: Tue Jun 06, 2017 10:17 am
by itsieber
Hey Guys

Since the last update, all mi 5G Wifis don't coming up.

I have Reset all 5 AP's to factory. Also the factory config will only have the state "running up". And thats it.

2g don't have the Problems!

greets
Andy

Re: v6.40rc [release candidate] is released!

Posted: Tue Jun 06, 2017 3:09 pm
by strods
Version 6.39.2 [current] has been released:
viewtopic.php?f=21&t=122322

Re: v6.40rc [release candidate] is released!

Posted: Tue Jun 06, 2017 3:10 pm
by strods
Version 6.40rc18 has been released.
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 version:
*) conntrack - fixed IPv6 connection tracking enable/disable;
*) defconf - added IPv6 default firewall configuration (IPv6 package must be enabled on reset);
*) defconf - improved IPv4 default firewall configuration;
*) fastpath - improved performance when packets for slowpath are received;
*) hotspot - added "address-list" support in "walled-garden" IP section;
*) ike1 - added support for "framed-pool" RADIUS attribute;
*) ike1 - kill phase1 instead of rekey if "mode-config" is used;
*) ike1 - removed SAs on DPD;
*) ike1 - send phase1 delete;
*) ike2 - added RADIUS attributes "Framed-Pool", "Framed-Ip-Address", "Framed-Ip-Netmask";
*) ike2 - added support for "mode-config" static address;
*) ike2 - prefer traffic selector with "mode-config" address;
*) l2tp - fixed handling of pre-authenticated L2TP sessions with CHAP authentication;
*) log - improved "l2tp" logs;
*) log - optimized "wireless,info" topic logs;
*) lte - improved SMS delivery report;
*) ppp - improved MLPPP packet forwarding performance;
*) socks - fixed crash while processing many simultaneous sessions;
*) tr069-client - fixed lost HTTP header on authorization;
*) wireless - allow VirutalAP on Level0 (24h demo) license;

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

Re: v6.40rc [release candidate] is released!

Posted: Wed Jun 07, 2017 11:09 am
by nz_monkey
Thank you for all the work on IPSEC

Re: v6.40rc [release candidate] is released!

Posted: Wed Jun 07, 2017 12:30 pm
by nescafe2002
Regarding ipsec.. :)

Is connection tracking on ipsec traffic considered 'bad practice'?

I like to firewall my ipsec tunnels (block incoming, allow outgoing) and therefore need to accept established and related connections. Not sure how to handle this without connection tracking.

Edit:
Seems resolved in rc19:
*) ipsec - added "firewall=add-notrack" peer option (CLI only);

Re: v6.40rc [release candidate] is released!

Posted: Wed Jun 07, 2017 8:36 pm
by aboiles
Scheduler issue with v6.40 rc18.
Tested and confirmed only on CHR.
If the entry is set to run at startup with a recurrence, it will NOT run at all.
If the same entry is set to ONLY run at startup, it runs correctly.
If the same entry is set for recurrence ONLY, it runs correctly.
Change it to run both and it fails to run at all.

Re: v6.40rc [release candidate] is released!

Posted: Thu Jun 08, 2017 2:56 pm
by strods
Version 6.40rc19 has been released.
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 version:
*) ike1 - send phase1 delete;
*) ike2 - added RADIUS attributes "Framed-Pool", "Framed-Ip-Address", "Framed-Ip-Netmask";
*) ipsec - added "firewall=add-notrack" peer option (CLI only);
*) l2tp-server - added "one-session-per-host" option;
*) ovpn - improved performance when receiving too many options;
*) wireless - fixed registration table "signal-strength" reporting for chains when using nv2;

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

Re: v6.40rc [release candidate] is released!

Posted: Thu Jun 08, 2017 5:48 pm
by marianob85
Version 6.40rc19 ( upgraded from 6.40rc15)
No USB power on RB750Gr3

Re: v6.40rc [release candidate] is released!

Posted: Thu Jun 08, 2017 9:11 pm
by sup5
*) wireless - fixed registration table "signal-strength" reporting for chains when using nv2;
The TX-Power value has been fixed.
The RX-Power on Ch1 is still a copy of the value of Ch0

See the actual output of a wireless link.
Red Colour: wrong
Green Colour: corrrect

Site A:
[admin@LHG5] /interface wireless registration-table> pr stats
0 interface=wlan1 ap=yes [...]
signal-strength=-62dBm signal-to-noise=51dB
signal-strength-ch0=-62dBm signal-strength-ch1=-62dBm
tx-signal-strength-ch0=-68dBm tx-signal-strength-ch1=-77dBm
[...]

Site B:
[admin@SXT-5] /interface wireless registration-table> pr stats
0 interface=wlan1 radio-name="LHG" ap=no bridge=yes [...]
signal-strength=-67dBm signal-to-noise=50dB
signal-strength-ch0=-68dBm signal-strength-ch1=-68dBm
tx-signal-strength-ch0=-62dBm tx-signal-strength-ch1=-74dBm
[...]

Re: v6.40rc [release candidate] is released!

Posted: Fri Jun 09, 2017 7:25 pm
by idlemind
Now in ip firewall:
/ip firewall address-list
add address=100.64.0.0/10 comment="defconf: RFC6890" list=bad_ipv4
/ip firewall raw
add action=drop chain=prerouting comment="defconf: drop from bogon IP's" in-interface-list=WAN src-address-list=bad_ipv4
I don't like this.

This valid address for WAN interface for end user.

Many ISP use CGN network.
The Shared Address Space address range is 100.64.0.0/10
Shared Address Space can only be used in Service Provider networks or on routing equipment that is able to do address translation across router the interfaces when addresses are identical on two different interfaces

---
Ramas
I just upgraded my hEX to latest and I'm not seeing anything in the default configuruation script for enhancements to the IPv4 now.
          /ip firewall nat add chain=srcnat out-interface-list=WAN ipsec-policy=out,none action=masquerade comment="defconf: masquerade"
           /ip firewall {
             filter add chain=input action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untracked"
             filter add chain=input action=drop connection-state=invalid comment="defconf: drop invalid"
             filter add chain=input action=accept protocol=icmp comment="defconf: accept ICMP"
             filter add chain=input action=drop in-interface-list=!LAN comment="defconf: drop all not coming from LAN"
             filter add chain=forward action=accept ipsec-policy=in,ipsec comment="defconf: accept in ipsec policy"
             filter add chain=forward action=accept ipsec-policy=out,ipsec comment="defconf: accept out ipsec policy"
             filter add chain=forward action=fasttrack-connection connection-state=established,related comment="defconf: fasttrack"
             filter add chain=forward action=accept connection-state=established,related,untracked comment="defconf: accept established,related, untracked"
             filter add chain=forward action=drop connection-state=invalid comment="defconf: drop invalid"
             filter add chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN comment="defconf:  drop all from WAN not>
           }
Like the others have stated, this is valid address space. It can be used by a service provider to address their equipment, like a DNS server or NTP server for example. It also could be used for CPE addressing. In fact it should be preferred when a service provider does not have a device public addressing for IPv4 over using RFC1918 addressing. You are more likely to have issues with users when you use RFC1918 addressing instead of RFC6598 addressing. This brings me to my last point, if this configuration update is coming back the comment should be altered to reflect the either both RFC680 which simply indicates it's allocated addressing and or RFC6598, the actual document for it's use, or just RFC6598.

Thoughts?

Re: v6.40rc [release candidate] is released!

Posted: Sat Jun 10, 2017 11:33 pm
by msatter
Grrrrrrrrr spend a lot of time on 6.40RC18 because the IKe2 with Android was not working any more and it was working on the 6.40RC13.
Could not find the problem it and it looked if the data was not finding it's way to the NAT and in the connection tab I only had the IKe2 connection but not the addresses from the ipsec-pool. Updated to 6.40RC19 and all return working again.

I had some frustration with importing the exported configuration files because a few lines had fields that had empty values...this is something I have suggested before to fix however I don't think it will ever happen and I wrote about in the Winbox 3.11 topic.

Very frustrating to be able to export the config and when you want the import it won't go because of all kind of errors.

Update: I do now export and then import directly the just exported file to see if I can import it the next time so that have an correct configfile.

I have now a syntax error on the this configline: add address=/48 advertise=no from-pool=ISP-v6prefix interface=pppoe-out1 this is dynamic configured and as soon the IPv6 comes up the prefix will in front of the /48.
When I change the line to ::/48 then I get: failure: already have interface with such name

I don't need that address manual entered so I removed the complete line now.

Not nice, my RB750Gr3 crashed and had to be reset and I had to reload the .backup file that I had ready. First time it would not accept and luckily in on the second try it worked.

Finally completed the portknocking part for IKe2 and now the knocked open part can now be closed by a script running every minute. I kept down the CPU usage to not seek for to remove external address when the remove IKe2 connections addresstable is empty.

I had the pleasure to have an other empty field in the configscreen so that had to knock always twice. I now closed the the open field and now it works on the first knock sequence. I really hope that one time this lack of checking on applying will be complete.

Re: v6.40rc [release candidate] is released!

Posted: Mon Jun 12, 2017 10:14 am
by mrz
Now in ip firewall:
/ip firewall address-list
add address=100.64.0.0/10 comment="defconf: RFC6890" list=bad_ipv4
/ip firewall raw
add action=drop chain=prerouting comment="defconf: drop from bogon IP's" in-interface-list=WAN src-address-list=bad_ipv4
I don't like this.

This valid address for WAN interface for end user.

Many ISP use CGN network.
The Shared Address Space address range is 100.64.0.0/10
Shared Address Space can only be used in Service Provider networks or on routing equipment that is able to do address translation across router the interfaces when addresses are identical on two different interfaces

---
Ramas
I just upgraded my hEX to latest and I'm not seeing anything in the default configuruation script for enhancements to the IPv4 now.
          /ip firewall nat add chain=srcnat out-interface-list=WAN ipsec-policy=out,none action=masquerade comment="defconf: masquerade"
           /ip firewall {
             filter add chain=input action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untracked"
             filter add chain=input action=drop connection-state=invalid comment="defconf: drop invalid"
             filter add chain=input action=accept protocol=icmp comment="defconf: accept ICMP"
             filter add chain=input action=drop in-interface-list=!LAN comment="defconf: drop all not coming from LAN"
             filter add chain=forward action=accept ipsec-policy=in,ipsec comment="defconf: accept in ipsec policy"
             filter add chain=forward action=accept ipsec-policy=out,ipsec comment="defconf: accept out ipsec policy"
             filter add chain=forward action=fasttrack-connection connection-state=established,related comment="defconf: fasttrack"
             filter add chain=forward action=accept connection-state=established,related,untracked comment="defconf: accept established,related, untracked"
             filter add chain=forward action=drop connection-state=invalid comment="defconf: drop invalid"
             filter add chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN comment="defconf:  drop all from WAN not>
           }
Like the others have stated, this is valid address space. It can be used by a service provider to address their equipment, like a DNS server or NTP server for example. It also could be used for CPE addressing. In fact it should be preferred when a service provider does not have a device public addressing for IPv4 over using RFC1918 addressing. You are more likely to have issues with users when you use RFC1918 addressing instead of RFC6598 addressing. This brings me to my last point, if this configuration update is coming back the comment should be altered to reflect the either both RFC680 which simply indicates it's allocated addressing and or RFC6598, the actual document for it's use, or just RFC6598.

Thoughts?
ipv4 firewall was reverted.

Re: v6.40rc [release candidate] is released!

Posted: Mon Jun 12, 2017 6:27 pm
by idlemind
ipv4 firewall was reverted.
Thanks, mrz! Any improvement in the default firewall is worth while. You got us all excited with the IPv6 one so now we're playing with the changes in both IPv4 and IPv6. I look forward to seeing more improvements!

DHCPv6 Server
DHCP / DHCPv6 out of the box integration with DNS resolver (not the script approach)
... other stuff I can't think of at the moment!

Re: v6.40rc [release candidate] is released!

Posted: Tue Jun 13, 2017 7:59 am
by biatche

ipv4 firewall was reverted.
why was it reverted anyway

Re: v6.40rc [release candidate] is released!

Posted: Tue Jun 13, 2017 8:17 am
by BartoszP
@biatche:
Writing as moderator:
Could you PLEASE DO NOT CITE FULL POST if it is not needed. Can you count ratio of your words to citation ? It is almost 0%.
Do you think that it is necessary to make such long citations ? Do you think that full post need to be repeated post under post ? Do you think we have problem following thread ? If you need to emphasize on particular words from long post then just cite these words.
Please edit your post and treat this as prewarning.

Re: v6.40rc [release candidate] is released!

Posted: Tue Jun 13, 2017 12:35 pm
by strods
Version 6.40rc20 has been released.
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 version:
*) dhcp - added "debug" logs on MAC address change;
*) ike2 - added support for "Mikrotik_Address_List" RADIUS attribute;
*) lte - added "accounting" logs for LTE connections;
*) lte - improved reliability on SXT LTE;
*) wireless - fixed rare crash on cap disable;
*) wireless - fixed registration table "signal-strength" reporting for chains when using nv2;

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

Re: v6.40rc [release candidate] is released!

Posted: Tue Jun 13, 2017 1:28 pm
by msatter
@biatche:
Writing as moderator:
Could you PLEASE DO NOT CITE FULL POST if it is not needed. Can you count ratio of your words to citation ? It is almost 0%.
Do you think that it is necessary to make such long citations ? Do you think that full post need to be repeated post under post ? Do you think we have problem following thread ? If you need to emphasize on particular words from long post then just cite these words.
Please edit your post and treat this as prewarning.
Maybe the the forum can be updated to a new way of answering. Added could be "Answering to this posting" next to post reply and quote.

In the new posting on the top there is a automatically generated line that states "In reaction to post xxxxxx" and the xxxxxx is a number that is clickable and links to the post answered to.

Re: v6.40rc [release candidate] is released!

Posted: Tue Jun 13, 2017 1:29 pm
by normis
you can remove the unnecessary parts from the quote, leave only the author and relevant details.

Re: v6.40rc [release candidate] is released!

Posted: Tue Jun 13, 2017 1:47 pm
by th0massin0
Version 6.40rc20 has been released.
Before an upgrade:
Changes since previous version:
*) lte - added "accounting" logs for LTE connections;
*) lte - improved reliability on SXT LTE;
Does the SXT LTE fix is the same as is current (6.39.2) firmware or is it something else?

Re: v6.40rc [release candidate] is released!

Posted: Tue Jun 13, 2017 1:52 pm
by uldis
This RC version has some additional stability improvements to SXT LTE compared to v6.39.2

Re: v6.40rc [release candidate] is released!

Posted: Tue Jun 13, 2017 8:19 pm
by boldsuck
Why were the RAW rules omitted? There are problems because of the dynamic IPsec rules?

On RB2011 from v6.40rc8 - rc20
After System Reset_Configuration and new first setup on RB2011 + adding an pppoe-out client.
/system default-configuration
/ipv6 firewall
filter add chain=input action=drop in-interface-list=!LAN comment="defconf: drop everything else not coming from LAN"
filter add chain=forward action=drop in-interface-list=!LAN comment="defconf: drop everything else not coming from LAN" 

/ip firewall
filter add chain=input action=drop in-interface-list=!LAN comment="defconf: drop all not coming from LAN"
The setup script then returns:
> export
/ipv6 firewall
filter add chain=input action=drop in-interface-list=!LAN comment="defconf: drop everything else not coming from LAN"
filter add chain=forward action=drop in-interface-list=!LAN comment="defconf: drop everything else not coming from LAN"

/ip firewall
filter add chain=input action=drop in-interface=pppoe-out1 comment="defconf: drop all not coming from LAN"

Is not better to write directly WAN instead of !LAN at all 3 rules. The interface list for a zone based firewall are there.

Re: v6.40rc [release candidate] is released!

Posted: Tue Jun 13, 2017 10:27 pm
by biatche
@biatche:
Writing as moderator:
Could you PLEASE DO NOT CITE FULL POST if it is not needed. Can you count ratio of your words to citation ? It is almost 0%.
Do you think that it is necessary to make such long citations ? Do you think that full post need to be repeated post under post ? Do you think we have problem following thread ? If you need to emphasize on particular words from long post then just cite these words.
Please edit your post and treat this as prewarning.
i didnt bother to look at the content.. i just hit "reply with quote" button. maybe you could fix the way that button works. mrz multi quoted himself #122. so whatever, ill change it.

Re: v6.40rc [release candidate] is released!

Posted: Tue Jun 13, 2017 10:36 pm
by biatche
@biatche:
Writing as moderator:
Could you PLEASE DO NOT CITE FULL POST if it is not needed. Can you count ratio of your words to citation ? It is almost 0%.
Do you think that it is necessary to make such long citations ? Do you think that full post need to be repeated post under post ? Do you think we have problem following thread ? If you need to emphasize on particular words from long post then just cite these words.
Please edit your post and treat this as prewarning.
Maybe the the forum can be updated to a new way of answering. Added could be "Answering to this posting" next to post reply and quote.

In the new posting on the top there is a automatically generated line that states "In reaction to post xxxxxx" and the xxxxxx is a number that is clickable and links to the post answered to.
exactly. i typed all of it with haste, looking only at the content i typed. i didn't bother to look at all the automated quoted text. i believe that's what a moderator is here for in the case a forum button doesn't work as efficient as it can be.

Re: v6.40rc [release candidate] is released!

Posted: Wed Jun 14, 2017 1:04 am
by BartoszP
That is the problem ... you do not bother.Why should you ? Maybe moderator should edit your posts for your convenience as you do not bother ?
Do you think that driver job is just driving a car without necessity to follow traffic rules as police is for obeying them ?
Have you checked difference in funcionality of "Post replay" button versus "Reply with quote" ?
Cite.PNG

Re: v6.40rc [release candidate] is released!

Posted: Wed Jun 14, 2017 1:16 am
by brwainer
That is the problem ... you do not bother.Why should you ? Maybe moderator should edit your posts for your convenience as you do not bother ?
Do you think that driver job is just driving a car without necessity to follow traffic rules as police is for obeying them ?
Have you checked difference in funcionality of "Post replay" button versus "Reply with quote" ? Cite.PNG
Please cite or link the rules of the forum that indicate that full-quoting is not allowed. There is no visible forum rules either in the forum headers, footer, nor in the terms of registration given to a new user (at ucp.php?mode=register ). On every other forum I visit, full quoting is actually recommended and preferred unless the message you are quoting is more than a few paragraphs, or has embedded images. The terms say that Mikrotik (and moderators) can edit a post, but nowhere does it say that an account might face consequences for content that is allowed.

Re: v6.40rc [release candidate] is released!

Posted: Wed Jun 14, 2017 1:29 am
by Sob
Allowed or not, it's annoying. All that endless scrolling over quotes, just to see another "me too" type of reply below, that's just wrong. On the other hand, I do agree that multi-topic threads like this one are exceptions, and little more quotes than normal are fine. Still, no need to overdo it.

Btw, it would be probably wise if some moderator split this quoting discussion in another thread.

Re: v6.40rc [release candidate] is released!

Posted: Wed Jun 14, 2017 1:34 am
by brwainer
Allowed or not, it's annoying. All that endless scrolling over quotes, just to see another "me too" type of reply below, that's just wrong.
I can agree, especially on mobile, that full quoting can be annoying if the resulting reply is limited in content.
On the other hand, I do agree that multi-topic threads like this one are exceptions, and little more quotes than normal are fine. Still, no need to overdo it.
This is precisely where "Reply with Quote" should be used. When there are multiple on-topic discussions in a single thread, quoting allows the reader to maintain understanding of the context. Especially if you call out the part you are referring to exactly, such as this.
Btw, it would be probably wise if some moderator split this quoting discussion in another thread.
I agree, I responded off-topic in this thread since it was responding to a moderator whose message was off-topic.

Re: v6.40rc [release candidate] is released!

Posted: Wed Jun 14, 2017 1:37 am
by BartoszP
I do not say that quoting is not allowed. There is no such rule. I just ASK to not cite full post just under this post. Do you rally need this to follow the thread ? Aren't you able to go back to previous posts to read them ? It is not an argument that "other forums" used to use full post quoting.
I am asking users to make forum more ergonomic.
Forum's new default skin is quite wordy and tablet/smartphone friendly. It implies that nowadays IMHO it should be measured in meters not in post count. Aren't your fingers tired scrolling meters of screens just beause someone needs to cite post under post with no special need ?

Re: v6.40rc [release candidate] is released!

Posted: Wed Jun 14, 2017 1:47 am
by brwainer
I do not say that quoting is not allowed. There is no such rule.
Tue Jun 13, 2017 1:17 am:
@biatche:
Please edit your post and treat this as prewarning.
So why would that be a prewarning if it is allowed and there is no rule? I take no offense to what you are trying to do, I agree that it would be best if everyone used quoting only strategically. I have an issue that you called it a "prewarning" which coming from a moderator means that repeat offenses would become a warning and then a ban or other restriction. I was silent on the issue until I read that line.

Re: v6.40rc [release candidate] is released!

Posted: Wed Jun 14, 2017 7:45 am
by biatche
look people. its true that its annoying and convoluted. i didnt bother to check because i was in a hurry. i typed it and left my laptop immediately. at the same time, some 'reply with quote' buttons in other forums wouldn't quote the entire thing but only the last quote. in some others, its fully quoted but has some javascript sort of effect that makes it appear less convoluted.

whatever, its my fault, mrz didn't do anything incorrect. apologies that your eyes hurt. the forum design and rules are perfect.

now maybe we should just focus on 6.40 and not multiquotes.
@biatche:
Please edit your post and treat this as prewarning.

I wonder if mrz was given a prewarning too.

Re: v6.40rc [release candidate] is released!

Posted: Wed Jun 14, 2017 8:15 am
by biatche
wheres the delete post button? looking to delete this post.

Re: v6.40rc [release candidate] is released!

Posted: Wed Jun 14, 2017 9:05 am
by normis
What are you guys even talking about? Just use the forum Default Theme where long Quotes are automatically resized! It is your own choice to set the theme to one designed in the late nineties, and that comes without any such features.

This is how I see a very long inline quote. Notice the scroll on the right:
screen 7.jpg
You can't have two things - more javascript and less javascript! You want features, do not use custom skin. All forum features go into the default skin only.
I would also like to point out, that this topic is about RC releases and your posts are about to be deleted.

Re: RE: Re: v6.40rc [release candidate] is released!

Posted: Wed Jun 14, 2017 9:18 am
by amokkatmt
What are you guys even talking about?
Tapatalk (Android app for the phpBB) is atvertised when browsing forum from mobile browser. And it does not shrink quotes.

Re: RE: Re: v6.40rc [release candidate] is released!

Posted: Wed Jun 14, 2017 9:22 am
by normis
What are you guys even talking about?
Tapatalk (Android app for the phpBB) is atvertised when browsing forum from mobile browser. And it does not shrink quotes.
I have no control over what 3rd party tools do. Just don't use it.

Re: v6.40rc [release candidate] is released!

Posted: Wed Jun 14, 2017 9:25 am
by amokkatmt
Ok, it is 3rd party, but it is advertised and adviced to use by forum.mikrotik.com

Re: v6.40rc [release candidate] is released!

Posted: Wed Jun 14, 2017 9:31 am
by normis
it is advertised
This is the plugin misbehaving. Fixed it.

Re: v6.40rc [release candidate] is released!

Posted: Wed Jun 14, 2017 3:37 pm
by strods
Version 6.40rc21 has been released.
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 version:
!) wireless - added Nv2 AP synchronization feature (for experimental use)(CLI only);
*) capsman - added "current-registered-clients" and "current-authorized-clients" count for CAP interfaces (CLI only);
*) certificate - added "crl-use" setting to disable CRL use (CLI only);
*) CCR / CRS2xx - fixed Optech sfp-10G-tx module compatibility with SFP+ ports;
*) dude - fixed server crash;
*) export - added default "init-delay" setting for "/routerboard settings" menu;
*) ping - fixed ping getting stuck (after several thousands of ping attempts);
*) rb750gr3 - fixed USB power;
*) userman - lookup language files also in "/flash" directory;

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.

Visit this link in order to find out more about new wireless feature:
https://wiki.mikrotik.com/wiki/Manual:N ... ronization

Re: v6.40rc [release candidate] is released!

Posted: Wed Jun 14, 2017 4:00 pm
by macgaiver
Version 6.40rc21 has been released.
!) wireless - added Nv2 AP synchronization feature (for experimental use)(CLI only);
Visit this link in order to find out more about new wireless feature:
https://wiki.mikrotik.com/wiki/Manual:N ... ronization
And that is one unexpected development.... and just before the vacation....

Re: v6.40rc [release candidate] is released!

Posted: Wed Jun 14, 2017 4:09 pm
by CyberTod
!) wireless - added Nv2 AP synchronization feature (for experimental use)(CLI only);
Sounds very promising.

Re: v6.40rc [release candidate] is released!

Posted: Wed Jun 14, 2017 6:00 pm
by sakirozkan
Version 6.40rc21 has been released.
!) wireless - added Nv2 AP synchronization feature (for experimental use)(CLI only);

Visit this link in order to find out more about new wireless feature:
https://wiki.mikrotik.com/wiki/Manual:N ... ronization
Good experiment..

Re: v6.40rc [release candidate] is released!

Posted: Wed Jun 14, 2017 11:38 pm
by Zod
A step closer but requires AP's to be on the same frequency though :(

Re: v6.40rc [release candidate] is released!

Posted: Thu Jun 15, 2017 9:28 am
by uldis
A step closer but requires AP's to be on the same frequency though :(
There is no need for synchronization if your APs on the same tower uses different frequencies as then there is no big interference between them.

Re: v6.40rc [release candidate] is released!

Posted: Thu Jun 15, 2017 9:39 am
by CyberTod
Actually there is. If there are 2 antennas on the same tower and let's say 1m between them even on different frequency and some angle between them - there is interference, speaking from experience.

Re: v6.40rc [release candidate] is released!

Posted: Thu Jun 15, 2017 11:43 am
by mistry7
Hi,

i tested sync mode for nv2, but it did not run for me

I set AP1 to sync-master, client connectiong all OK
But when i set AP2 or AP3 to sync-slave, the Clients did not come back.
Log says nothing AP says runnig but no clients are connecting
on AP1 Master i see nothing that communication with AP2 or AP3 for sync is done.

mistry7

Re: v6.40rc [release candidate] is released!

Posted: Thu Jun 15, 2017 1:01 pm
by doush
A step closer but requires AP's to be on the same frequency though :(
There is no need for synchronization if your APs on the same tower uses different frequencies as then there is no big interference between them.
@Uldis
You should know better than this.
There is interference even if you are 200mhz away from an AP.

Re: v6.40rc [release candidate] is released!

Posted: Thu Jun 15, 2017 1:07 pm
by uldis
Hi,

i tested sync mode for nv2, but it did not run for me

I set AP1 to sync-master, client connectiong all OK
But when i set AP2 or AP3 to sync-slave, the Clients did not come back.
Log says nothing AP says runnig but no clients are connecting
on AP1 Master i see nothing that communication with AP2 or AP3 for sync is done.

mistry7
Please enable the wireless,debug logs on the Master AP and also on the Slave APs.
What does the wireless monitor interface say on the AP2 or AP3?

Re: v6.40rc [release candidate] is released!

Posted: Thu Jun 15, 2017 1:08 pm
by uldis
A step closer but requires AP's to be on the same frequency though :(
There is no need for synchronization if your APs on the same tower uses different frequencies as then there is no big interference between them.
@Uldis
You should know better than this.
There is interference even if you are 200mhz away from an AP.
If the APs are very close together then yes.
At the moment the current implementation works only on the same wireless frequency. We could think how to sync the APs that are on different frequencies but located on the same tower and connected to the same ethernet network.

Re: v6.40rc [release candidate] is released!

Posted: Thu Jun 15, 2017 1:49 pm
by CyberTod
If the APs are very close together then yes.
At the moment the current implementation works only on the same wireless frequency. We could think how to sync the APs that are on different frequencies but located on the same tower and connected to the same ethernet network.
That is exactly what we need. Sync on the same tower of course, but on different frequencies too. The fact that you are thinking about testing with different frequencies too is very good to hear.

Re: v6.40rc [release candidate] is released!

Posted: Thu Jun 15, 2017 2:16 pm
by soulflyhigh
If the APs are very close together then yes.
At the moment the current implementation works only on the same wireless frequency. We could think how to sync the APs that are on different frequencies but located on the same tower and connected to the same ethernet network.
That is exactly what we need. Sync on the same tower of course, but on different frequencies too. The fact that you are thinking about testing with different frequencies too is very good to hear.
I completely agree with this.
Even if some additional (GPS capable) piece of hardware is needed (per site/tower) it would be worth it.
With properly implemented synchronization SNR goes up, throughput goes up, everybody is happy :) .

Regards,
M.

Re: v6.40rc [release candidate] is released!

Posted: Thu Jun 15, 2017 2:29 pm
by honzam
At the moment the current implementation works only on the same wireless frequency. We could think how to sync the APs that are on different frequencies but located on the same tower and connected to the same ethernet network.
+1

Re: v6.40rc [release candidate] is released!

Posted: Thu Jun 15, 2017 6:20 pm
by HaQs
+1 for nv2 sync all MT wireles on this some tower

Re: v6.40rc [release candidate] is released!

Posted: Thu Jun 15, 2017 6:50 pm
by mistry7
Hi,

i tested sync mode for nv2, but it did not run for me

I set AP1 to sync-master, client connectiong all OK
But when i set AP2 or AP3 to sync-slave, the Clients did not come back.
Log says nothing AP says runnig but no clients are connecting
on AP1 Master i see nothing that communication with AP2 or AP3 for sync is done.

mistry7
Please enable the wireless,debug logs on the Master AP and also on the Slave APs.
What does the wireless monitor interface say on the AP2 or AP3?
You give the Answer some topics later, it works only on the same Frequenzy, this config is not possile, at the moment.

Re: v6.40rc [release candidate] is released!

Posted: Thu Jun 15, 2017 7:14 pm
by xrayd
Version 6.40rc21 has been released.

!) wireless - added Nv2 AP synchronization feature (for experimental use)(CLI only);
Very good news!! Thanks! :)
I've been waiting for ages!

Re: v6.40rc [release candidate] is released!

Posted: Thu Jun 15, 2017 7:43 pm
by bajodel
.. [CUT].. We could think how to sync the APs that are on different frequencies but located on the same tower and connected to the same ethernet network.
absolutely +1

Another thing; on current stable/rc scheduler has some issues, if you create new item it works but if you create from 'copy' it never runs on scheduled time.

Re: v6.40rc [release candidate] is released!

Posted: Fri Jun 16, 2017 9:09 am
by server8
Same channel means that the slave APs listen the radio of the master AP before to talk, it's a good trick but it's light years far away from the commercial solutions of the other vendors :-(

Re: v6.40rc [release candidate] is released!

Posted: Fri Jun 16, 2017 9:23 am
by aTan
Version 6.40rc21 has been released.
*) dude - fixed server crash;
I guess it is not [Ticket#2017021722001071].

Re: v6.40rc [release candidate] is released!

Posted: Fri Jun 16, 2017 5:42 pm
by UpRunTech
We could think how to sync the APs that are on different frequencies but located on the same tower and connected to the same ethernet network.
You could take some ideas from or use PTP (https://en.wikipedia.org/wiki/Precision_Time_Protocol) to synchronise the APs internal clocks over ethernet and hence transmission times from a collection of APs on a tower without having to mess with GPS. You only need relative not absolute time synchronisation. How well it works depends on how quickly you can get an incoming ethernet frame timestamped - but the articles all suggest sub-microsecond is possible.

Re: v6.40rc [release candidate] is released!

Posted: Fri Jun 16, 2017 6:20 pm
by idlemind
*) ping - fixed ping getting stuck (after several thousands of ping attempts);
As always, I love to see the progress you guys make day by day. With that said and while you're in mucking around with ping. Can you update it to support IPv6 name resolution. I suspect someone is using a legacy system call ...
[admin@rtr1] > ping count=2 www.google.com 
  SEQ HOST                                     SIZE TTL TIME  STATUS                                                                                                                                                                    
    0 172.217.8.196                              56  56 15ms 
    1 172.217.8.196                              56  56 23ms 
    sent=2 received=2 packet-loss=0% min-rtt=15ms avg-rtt=19ms max-rtt=23ms 

[admin@rtr1] > ping count=2 ipv6.google.com   
invalid value for argument address:
    invalid value of mac-address, mac address required
    invalid value for argument ipv6-address
    failure: dns name exists, but no appropriate record
[admin@rtr1] > 
Can't post attachments in this thread so ... http://imgur.com/a/pRfJW

My previous post here on the forums regarding this: viewtopic.php?f=2&t=120802&p=593973&hil ... ng#p593973

Re: v6.40rc [release candidate] is released!

Posted: Sat Jun 17, 2017 6:12 am
by 0ldman
Another vote for sync even for adjacent channels.

Most of us *have* a lot of hardware on the tower. As it is I've got three feeds and one access point on one tower. I've got to turn the tx power down to keep noise from being an issue, which is just good practice, but sync would allow more headroom and allow use of more than four channels on the 5GHz band.

We're catching hell trying to find a clean channel in the 5GHz band on our loaded towers. Even with the entire 5GHz band, which means some of my hardware isn't Mikrotik, it still takes careful planning to pull it off without issues. This means that if someone starts interfering on a particular channel I've got problems. Sync would mean I could put them closer together even if I don't reuse the same channel.

Re: v6.40rc [release candidate] is released!

Posted: Sat Jun 17, 2017 12:33 pm
by 0ldman
I decided to try it out on a few of my towers in a relatively noisy area. I've got six 2.4GHz access points within about 6 miles of each other.

When I try to enable nv2-sync I don't get any error messages, no messages related to nv2 at all aside from the confirmation of the command, but the sync-slaves will not allow any connections until I set them back to dynamic downlink mode.

On a positive note, 40rc21 seems to have better performance on nv2 than the previous builds.

Re: v6.40rc [release candidate] is released!

Posted: Sat Jun 17, 2017 12:50 pm
by mistry7
Hi Oldman,


did you see the need of sync-secret?


Master AP:

/interface wireless set wlan1 nv2-mode=sync-master nv2-sync-secret=Tower1

Slave AP:

/interface wireless set wlan1 nv2-mode=sync-slave nv2-sync-secret=Tower1

mistry7

Re: v6.40rc [release candidate] is released!

Posted: Sat Jun 17, 2017 3:04 pm
by Zod
A step closer but requires AP's to be on the same frequency though :(
There is no need for synchronization if your APs on the same tower uses different frequencies as then there is no big interference between them.
You ARE joking right ? Does Mikrotik really think that is the case ??? Have they ever run sectors in the field ? Even with RF Armour and 20' vertical and 6' horizontal separation it is a BIG problem. It absolutely DOES matter particularly if you run 802-N cards !

This explains why Mikrotik are a year behind the competition on Sync, and why I, and many other WISPs are being forced to abandon thousands of Mikrotik radios and start installing Cambium, or Ubiquiti, or Mimosa, or Telrad instead.

So sad.

Re: v6.40rc [release candidate] is released!

Posted: Sat Jun 17, 2017 11:11 pm
by mistry7
@zod

Yes mikrotik is thinking Wireless Works that way

Re: v6.40rc [release candidate] is released!

Posted: Sun Jun 18, 2017 1:02 am
by Zod
@zod

Yes mikrotik is thinking Wireless Works that way
Yes - that is painfully evident. They seem to be living in the B/G days when near channel interference didn't impact us very much. Sticking their heads in the sand and ignoring reality is not a valid business strategy !!!

Funny but I'd think they would know how their own N cards work ? Well I still have a thousand of them out there that we are ripping down and replacing with anything BUT Mikrotik as quickly as I can afford to - I guess I can send them a few hundred - maybe they can plug them in and ignore the performance impact of near channel noise like they have for the past year or more.

I really regret choosing Mikrotik over all the other options for the past 15 years.... This is just pathetic.

Re: v6.40rc [release candidate] is released!

Posted: Sun Jun 18, 2017 8:28 am
by mistry7
Hi Zod,


I dont realy regret my choose, when i look to the competiors they all
have there Problems....

GPS Sync is now working with Airmax AC not yesterday
I dont had to reflash more then 100 CPE because of malware, another WISPs has to.


What i am realy missing is Spectral-scan and Spectral-history
I used these functions every day, interferrence is now Panic on AC-Equipment without
These Tools!

Re: v6.40rc [release candidate] is released!

Posted: Sun Jun 18, 2017 12:31 pm
by server8
GPS Sync is now working with Airmax AC not yesterday
mistry7 you are wrong https://community.ubnt.com/t5/airMAX-AC ... 63941#M454 :-)

Cambium epmp2000 has rock solid GPS sync with interference filter and it has beamforming in rx and the new expensive medusa hardware has beamformig tx/rx and mu-mimo up to 7 streams (theoretical 500Mb/s@20mhz +200Mb/s for real)

We have +5000 mikrotik CPE installed changing all the hardware is too expensive so we are waiting for mikrotik gps sync or we 'll "elevate" to cambium when 'll be available for mikrotik hardware

Re: v6.40rc [release candidate] is released!

Posted: Sun Jun 18, 2017 2:23 pm
by Zod
Hi Zod,

GPS Sync is now working with Airmax AC not yesterday
I dont had to reflash more then 100 CPE because of malware, another WISPs has to.

What i am realy missing is Spectral-scan and Spectral-history
I used these functions every day, interferrence is now Panic on AC-Equipment without
These Tools!
I agree that the worms/viruses are a problem for ubiquiti based networks, but if the network is designed right they should not be able to get to the radios to infect them.

Spectral history would be a nice feature to have - have you seen Mimosa's ? But sync is absolutely essential.

Re: v6.40rc [release candidate] is released!

Posted: Tue Jun 20, 2017 12:12 pm
by Tonda
rb750gr3 - fixed USB power;
What exactly does this mean?

Re: v6.40rc [release candidate] is released!

Posted: Tue Jun 20, 2017 12:17 pm
by msatter
rb750gr3 - fixed USB power;
What exactly does this mean?
viewtopic.php?f=21&t=121198&start=100#p602070

It can mean different things and most likely it the starting of USB stuff.

Re: v6.40rc [release candidate] is released!

Posted: Tue Jun 20, 2017 2:45 pm
by strods
Version 6.40rc24 has been released.
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 version:
*) capsman - added "current-registered-clients" and "current-authorized-clients" count for CAP interfaces;
*) discovery - fixed timeouts for LLDP neighbours;
*) ethernet - fixed rare linking problem with forced 10Mbps full-duplex mode;
*) metarouter - fixed display of bogus error message on startup;
*) modem - added support for ZTE TE W120;
*) ovpn - added support for topology subnet for IP mode;
*) ovpn - added support for "push-continuation";
*) ovpn - fixed duplicate default gateway presence when receiving extra routes;
*) packages - increased automatic download retry interval to 5 minutes if there is no free disk space;
*) ppp - use interface name instead of IP as default route gateway;
*) proxy - fixed rare program crash after closing client connection;
*) quickset - added special firewall exception rules for IPSec;
*) quickset - fixed incorrect VPN address value on arm and tilera;
*) routerboard - added "caps-mode" option for "reset-configuration" (CLI only);
*) routerboard - added "caps-mode-script" for default-configuration print;
*) sms - decode reports in readable format;
*) snmp - added CAPsMAN interface statistics;
*) snmp - fixed wireless interface walk table id ordering;
*) winbox - added "session-uptime" to LTE interface;
*) winbox - added "src-address-list" & "dst-address-list" to HotSpot Walled Garden;
*) winbox - fixed wireless interface "amsdu-threshold" max limit;
*) winbox - moved LTE info fields to status tab;

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

Re: v6.40rc [release candidate] is released!

Posted: Tue Jun 20, 2017 2:57 pm
by juanvi
Removed

Re: v6.40rc [release candidate] is released!

Posted: Tue Jun 20, 2017 4:27 pm
by mietus
Any more details?

*) ethernet - fixed rare linking problem with forced 10Mbps full-duplex mode;

Re: v6.40rc [release candidate] is released!

Posted: Tue Jun 20, 2017 4:37 pm
by biatche
still no mstp?..

Re: v6.40rc [release candidate] is released!

Posted: Tue Jun 20, 2017 4:45 pm
by idlemind
*) quickset - added special firewall exception rules for IPSec;
I saw that the default configuration firewall rules were back at least in 6.40rc21. My upgrade to 6.40rc24 went smoothly. Are the references to untracked connections an issue? I know in some of the earlier versions of the rules were using RAW tables, this is likely what caused the inclusion of untracked.

Next, In the IPv6 firewall filter rules you are accepting UDP 500 and 4500 along with IPsec-AH and IPsec-ESP on input and forward. In the IPv4 firewall filter you are using the IPsec policy feature of the firewall filter. Is their a reason for the difference? It seems IPv6 firewall filter supports IPsec-policy as well. Along with this I'm not sure why there isn't an ipsec-policy=in,none in the IPv4 firewall to allow the ESP packets to come in or is it expected they'll get picked up by established, related?

^^ I run this release on a hex gr3 for reference.

Re: v6.40rc [release candidate] is released!

Posted: Wed Jun 21, 2017 1:22 pm
by 0ldman
I did. I used a good password, a stupid password, the word password, Tower1... nada.

So far I can't get anything to sync. The access points see each other in a scan with a signal of around -75dB. If I set any one of these as a client they will connect to the others.

edit: Just got it to work. Apparently if nv2 is set to auto it will not sync.

I had a rather massive drop in bandwidth, but it appeared to sync. I may need to try different channels. When I reverted the slave back to the previous channel bandwidth on both links more than doubled.
Hi Oldman,


did you see the need of sync-secret?


Master AP:

/interface wireless set wlan1 nv2-mode=sync-master nv2-sync-secret=Tower1

Slave AP:

/interface wireless set wlan1 nv2-mode=sync-slave nv2-sync-secret=Tower1

mistry7

Re: v6.40rc [release candidate] is released!

Posted: Wed Jun 21, 2017 10:01 pm
by mducharme
While you are working on IPv6 stuff, can you please add 'set priority' as an action in IPv6 firewall? We badly need this functionality as we use it extensively with IPv4. Thanks!

Re: v6.40rc [release candidate] is released!

Posted: Wed Jun 21, 2017 10:40 pm
by FIPTech
We could think how to sync the APs that are on different frequencies but located on the same tower and connected to the same ethernet network.
You could take some ideas from or use PTP (https://en.wikipedia.org/wiki/Precision_Time_Protocol) to synchronise the APs internal clocks over ethernet and hence transmission times from a collection of APs on a tower without having to mess with GPS. You only need relative not absolute time synchronisation. How well it works depends on how quickly you can get an incoming ethernet frame timestamped - but the articles all suggest sub-microsecond is possible.
For this to work, there are two solutions :

- the radio clock need to have an input for a sync reference, and a sync generator is needed to generate the sync carrier on the right frequency.

- the radio clock need a VCO clock, voltage controlled oscillator, so that it is possible to adjust the transmit frequency very precisely.

In both cases, the hardware need to be designed for this with some kinds of analog and or digital PLLs. It is not possible to just change the firmware and get those functions.

a sub microsecond reference is not necessary. If the oscillator in the radio is stable enough, then using the right PLL circuit and filters it is possible to keep synchronization using a quite loose external reference. This work by heavy filtering of the external clock, in combination with the stability of the internal clock of the radio module. The less internal clock drift, the more the external clock can have short range drift.

Today, there are low cost clocks circuits with low drift available, they are used for example inside GSM phones. The cost of sync is mainly at the design side, because of the relative math complexity.

I think that PTP would be enough for WIFI sync. The only advantage of the GPS is that it gives an absolute reference, without a physical link between towers. GPS reference is an absolute one. It gives the exact same synchronization that can be useful for large synced networks like PDH, SONET, SDH, GSM, or SyncE.

GPS is useful for GSM for example, because it does allow exact synchronization of distant towers, This sync is mandatory to allow transparent roaming from a tower to another one (thanks to this the GSM receiver does not need to adjust it's internal reference clock when roaming, it does only need to change the channel. With sync between towers the receiver can do this instantaneously without audio cut because the PLL does not need to adjust the frequency for the new tower. Only a channel frequency change is necessary, based on the same running clock, and a fast phase adjustment is enough to lock very fastly on the new carrier.

To my knowledge for Wifi, there is no need for this kind of sync because the receivers always fully resync to the new channel during roaming. They are not able to roam transparently on the new carrier, even if there are some existing 802.11 protocols to speed up roaming, the receiver need to lock on the frequency channel before to be able to roam. Fast roaming 802.11 protocols are only here to help the receiver to make decisions about witch AP to choose, when to do it, and then reduce the time needed for key management and exchange. They are not designed to adjust a reference clock at the radio level.

So for wifi, sync is only useful i think to reduce interferences on the same sync tower or the same roof. Not to sync a wide network.

This is why i don't see the point in using an absolute reference distributed by satellite (GPS). A relative reference is enough, and this reference can be distributed with PTP and a specialized PLL hardware in the radio module.

This could be low cost using PTP and a dedicated PPL circuit in the radio module to inject a master reference clock in all slaves.

Re: v6.40rc [release candidate] is released!

Posted: Thu Jun 22, 2017 7:26 am
by nvwifi
So for wifi, sync is only useful i think to reduce interferences on the same sync tower or the same roof. Not to sync a wide network.
Mimosa is claiming tower to tower sync for micropop's that can see each other. That's wifi(ish) right?

$100 Omnitiks sound a lot nicer than $900 A5's for micropop's every 600 ft in a heavy folliage city.

I could swear in Denver that Uldis said tower to tower micropop sync would be possible as long as they were on the same frequency (like Mimosa is doing). Is this being worked on?

Re: v6.40rc [release candidate] is released!

Posted: Thu Jun 22, 2017 8:21 am
by server8
To use radio to sync the AP is crazy if you have an interference on the channel (in dense urban area is very easy) you lost the slave or slaves..... GPS sync reduce interference on the tower, reduce interference beetwen the towers, allow dense deployment and the last but not least allow sync beetween operatoros that use MKT and the same duty cycle.

Without GPS sync MKT 'll loose the WISP wireless market very soon :-(

Re: v6.40rc [release candidate] is released!

Posted: Thu Jun 22, 2017 11:14 am
by FIPTech
To use radio to sync the AP is crazy if you have an interference on the channel (in dense urban area is very easy) you lost the slave or slaves..... GPS sync reduce interference on the tower, reduce interference beetwen the towers, allow dense deployment and the last but not least allow sync beetween operatoros that use MKT and the same duty cycle.

Without GPS sync MKT 'll loose the WISP wireless market very soon :-(
GPS is good but does have drawbacks :

- it does not remove the need for a precise VCO oscillator and a PLL circuitry in the radio module to slave the carrier frequency.

- it's quite expensive, each tower needs a GPS receiver

- it depends about the US government, the Europe system Galileo is still not yet ready. So a multi constellation GPS, using GPS and Glonas, is better for systems who needs long term usability and short term reliability. This rise a bit the GPS module price.

In the end, as soon as you design or use a radio module that can accept a GPS reference frequency input, it's not a big challenge neither cost to add PTP sync. If the hardware is rightly designed, PTP is only a software addition.

I think that to satisfy product cost, it should be doable to design a product that can use a choice of GPS input, and PTP (precision time protocol) input. Because the circuitry needed for time reference input in the radio module is mandatory in both cases. Then it would be the user choice to use GPS or PTP input, depending if towers can be linked through Ethernet wire or not.

Last, it should be doable to distribute PTP not only by Ethernet wire, but as well through another radio channel, for example LTE. This remove a bit more the need for GPS sync.

https://en.wikipedia.org/wiki/Precision_Time_Protocol

Sync Ethernet is another possibility to distribute a clock, but needs expensive SyncE SFP. Not really a low cost solution...
This mean that PTP is certainly preferable, in conjunction with a low short term drift local oscillator in the radio module to compensate for PTP and distribution channel jitter.

How does work the actual Mikrotik sync implementation ? Is it working at the TDM level, trimming NV2 time slots to compensate for carriers drifts ?

Using a true carrier sync gives another advantage even for 802.11 : using synced receivers, it would be possible to have instantaneous roaming on different channels. The same as for GSM networks for example. But this is another story and is perhaps not really super useful, because there are 802.11(802.11 r,k,v) protocols that gives today a quite fast roaming, fast enough to be able to make VOIP calls without loosing audio during roamings. But is is important to understand that syncing transmitters on different channels, will help receivers to switch faster from one channel to another one, because they do not need to lock their reference clock to the new channel carrier. A simple (and fast) phase adjustment should be enough to lock on the new channel.

Re: v6.40rc [release candidate] is released!

Posted: Thu Jun 22, 2017 12:50 pm
by mrz
*) quickset - added special firewall exception rules for IPSec;
Next, In the IPv6 firewall filter rules you are accepting UDP 500 and 4500 along with IPsec-AH and IPsec-ESP on input and forward. In the IPv4 firewall filter you are using the IPsec policy feature ...
Quickset rules are explicitly for L2TP/IPSec, IPv6 rules are generic for any type of IPSec configuration.

Re: v6.40rc [release candidate] is released!

Posted: Thu Jun 22, 2017 7:28 pm
by idlemind
Quickset rules are explicitly for L2TP/IPSec, IPv6 rules are generic for any type of IPSec configuration.
What's the thought process for the difference in posture? I'd imagine you'd want your policies to be consistent across IP stacks.

Re: v6.40rc [release candidate] is released!

Posted: Mon Jun 26, 2017 9:42 pm
by scampbell
NV2 Sync appears to be working ok on my trial site, but...

While you can only configure it with CLI to work, if you change anything else in Winbox relating to Wireless it loses the CLI configured NV2 settings on close.

Can we get this fixed ASAP please ?

Also /interface wireless monitor 0 shows the Synch on the slaves it would not display anything relating to the Synch clients on the master - is this correct ?

On synch-master:

/interface wireless> mon 0
status: running-ap
channel: 5745/20/ac
wireless-protocol: nv2
noise-floor: -108dBm
registered-clients: 1
authenticated-clients: 1
notify-external-fdb: no
-- [Q quit|C-z pause]

On Synch-slave:
/interface wireless> mon 0
;;; West Sector
status: running-ap
channel: 5745/20/an
wireless-protocol: nv2
noise-floor: -113dBm
registered-clients: 1
authenticated-clients: 1
nv2-sync-state: synced
nv2-sync-master: 00:0C:42:8D:45:83
nv2-sync-distance: 1
nv2-sync-period-size: 2
nv2-sync-downlink-ratio: 50

current-tx-powers: 6Mbps:27(27/30),9Mbps:27(27/30),12Mbps:27(27/30),18Mbps:27(27/30),
24Mbps:27(27/30),36Mbps:27(27/30),48Mbps:25(25/28),54Mbps:24(24/27),
HT20-0:27(27/30),HT20-1:27(27/30),HT20-2:27(27/30),HT20-3:27(27/30),
HT20-4:27(27/30),HT20-5:27(27/30),HT20-6:25(25/28),HT20-7:23(23/26)
notify-external-fdb: no
-- [Q quit|C-z pause

Re: v6.40rc [release candidate] is released!

Posted: Tue Jun 27, 2017 6:34 am
by UpRunTech
For this to work, there are two solutions :
- the radio clock need to have an input for a sync reference, and a sync generator is needed to generate the sync carrier on the right frequency.
- the radio clock need a VCO clock, voltage controlled oscillator, so that it is possible to adjust the transmit frequency very precisely.
I think you have the wrong idea about the sync. My impression is that protocols like NV2 are TDMA. The purpose of syncing the transmitters on a tower would be to coordinate that they are transmitting and listening in unison to ensure weak signals from a client aren't drowned out by an adjacent AP. The Time of Day clocks in each AP probably run at microsecond or better accuracy so all you are trying to do is make sure that the transmit interrupt (or DMA transfer to a radio's own tx buffer) all happens in the same instant. It isn't to try and make sure their transmit centre frequency is locked precisely to 2.412GHz for instance.

Re: v6.40rc [release candidate] is released!

Posted: Tue Jun 27, 2017 8:39 am
by uldis
scampbell, everything is correct - on the Master AP it will not show any information on the monitor. The only info on the Master you will see in the log entry that Slave AP wanted to sync.
On the Slave AP it will show to what AP it synced.

We will try to fix the Winbox support for those new nv2 settings in one of the next RC versions.

Re: v6.40rc [release candidate] is released!

Posted: Tue Jun 27, 2017 3:24 pm
by strods
Version 6.40rc25 has been released.
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 version:
*) chr - fixed MAC address assignment when hot plugging NIC on XenServer;
*) fastpath - fixed router rebooting itself (introduced in 6.40rc24);
*) firewall - added "none-dynamic" and "none-static" options for "address-list-timeout" parameter (CLI only);
*) firewall - removed unique address list name limit;
*) ipsec - do not deduct "dst-address" from "sa-dst-address" for "/0" policies;
*) lte - added support for Huawei E3531-6;
*) modem - fixed info command when it is executed at the same time as modem restarts/disconnects;
*) tile - fixed copying large amount of text over serial console;
*) trafficgen - added "lost-ratio" to statistics;
*) webfig - fixed wireless "scan-list" parameter not being saved after applying changes;

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

Re: v6.40rc [release candidate] is released!

Posted: Tue Jun 27, 2017 7:34 pm
by biatche
will we be seeing MSTP in 6.40 (a latter RC) perhaps? is it in planning?

Re: v6.40rc [release candidate] is released!

Posted: Tue Jun 27, 2017 7:50 pm
by andriys
will we be seeing MSTP in 6.40 (a latter RC) perhaps? is it in planning?
Has it been promised?
In case it has, can you provide a link, please?
If not, please stop spamming with the topic not directly related to the 6.40rc series.

Re: v6.40rc [release candidate] is released!

Posted: Tue Jun 27, 2017 9:48 pm
by brwainer
Has it been promised?
In case it has, can you provide a link, please?
6.39 (Stable) Changelog:
!) bridge - reverted bridge BPDU processing back to pre-v6.38 behaviour; (v6.40 will have another separate VLAN-aware bridge implementation)
viewtopic.php?f=21&t=121196

The changelog doesn't promise MSTP specifically, but I think what biatche is asking is a valid question: Is the new "VLAN-aware bridge implementation" still planned for 6.40, or will it be pushed out to a later update?

Re: v6.40rc [release candidate] is released!

Posted: Tue Jun 27, 2017 10:39 pm
by biatche
will we be seeing MSTP in 6.40 (a latter RC) perhaps? is it in planning?
Has it been promised?
In case it has, can you provide a link, please?
If not, please stop spamming with the topic not directly related to the 6.40rc series.
viewtopic.php?f=1&t=120946#p595389

bottom quote

discuss. oh right, my mistake. some form of VLAN-aware STP implementation. not MSTP.

Re: v6.40rc [release candidate] is released!

Posted: Wed Jun 28, 2017 12:33 pm
by vlatko
I'm interested in nv2 AP sync, but not yet able to test new options
Please someone from the microtik to explain in details
If at one location we have 4 mikrotrik sectors that are mutually visible in the signal range from for example, -60 to -70dbi.
On the site is also present on all channels a disturbing noise ranging from -70dbi to better (lets say -80dbi average)
What is minimal necessary difference betwen sync signal and disturbing noise on same channel to properly sync funcionality.
also in this harsh conditions we have possibly aggregated troughput for all 4 sectors in range 4x25Mbps=100Mbps average
what is expected aggregated troughput on all 4 sectors in ap sync case
thanks

Re: v6.40rc [release candidate] is released!

Posted: Wed Jun 28, 2017 1:47 pm
by FIPTech
For this to work, there are two solutions :
- the radio clock need to have an input for a sync reference, and a sync generator is needed to generate the sync carrier on the right frequency.
- the radio clock need a VCO clock, voltage controlled oscillator, so that it is possible to adjust the transmit frequency very precisely.
I think you have the wrong idea about the sync. My impression is that protocols like NV2 are TDMA. The purpose of syncing the transmitters on a tower would be to coordinate that they are transmitting and listening in unison to ensure weak signals from a client aren't drowned out by an adjacent AP. The Time of Day clocks in each AP probably run at microsecond or better accuracy so all you are trying to do is make sure that the transmit interrupt (or DMA transfer to a radio's own tx buffer) all happens in the same instant. It isn't to try and make sure their transmit centre frequency is locked precisely to 2.412GHz for instance.
Yes NV2 is TDMA modulation. So Mikrotik NV2 sync seems to be similar in design with OpenTDMF sync. In this case, APs synchronize their slot boundaries. This is possible using a something like IEEE 1588 PTP protocol for example to share a quite precise (in the microsecond range) clock reference.

Some interesting details here :

https://www.microsoft.com/en-us/researc ... aready.pdf

https://www.microsoft.com/en-us/researc ... less-lans/

This kind of synchronization does not need carrier sync. This mean that there is no hardware modification at the radio level. So the cost is kept low.

But this is only working with a TDMA protocol, and still does not allow very fast roaming for clients, because when they roam they need to lock on a new channel carrier, not in sync with the previous one. So the PLL in the receiver needs some time to lock on the new frequency. If carrier are synced, even if APs are on different frequencies, receivers can lock almost instantaneously on the new channel.

In the GSM network for example, all towers and receivers are in sync at the carrier level. This mean that the receiver can switch to another channel very fast, this mean that there is no audio cut.
Wimax as well can use this kind of sync.

It seems to me that carrier sync gives more advantages as well to reduce interferences between adjacent antennas and adjacent base sites.

Re: v6.40rc [release candidate] is released!

Posted: Thu Jun 29, 2017 3:28 pm
by uldis
vlatko, Minimal difference between noise and signal - depends on nature of noise - if it is continuous wave or "packet" based. If your AP is able to "see" in scan master AP in the presence of noise signal, you are fine.
You can not predict throughput because it is not clear what is the effect of interfering signal. You should try and use what gives the best results.

Re: v6.40rc [release candidate] is released!

Posted: Fri Jun 30, 2017 7:01 am
by sparker
will we be seeing MSTP in 6.40 (a latter RC) perhaps? is it in planning?
Has it been promised?
In case it has, can you provide a link, please?
If not, please stop spamming with the topic not directly related to the 6.40rc series.
+1
v6.40 will have another separate VLAN-aware bridge implementation
Are looking forward to

Re: v6.40rc [release candidate] is released!

Posted: Fri Jun 30, 2017 9:40 am
by FIPTech
We could think how to sync the APs that are on different frequencies but located on the same tower and connected to the same ethernet network.
You could take some ideas from or use PTP (https://en.wikipedia.org/wiki/Precision_Time_Protocol) to synchronise the APs internal clocks over ethernet and hence transmission times from a collection of APs on a tower without having to mess with GPS. You only need relative not absolute time synchronisation. How well it works depends on how quickly you can get an incoming ethernet frame timestamped - but the articles all suggest sub-microsecond is possible.
Some other interesting background for synchronization :

http://community.cambiumnetworks.com/t5 ... td-p/37884

https://www.cse.wustl.edu/~jain/cse574- ... index.html

Synchronization is a complex subject, with many different possibilities, from full absolute carrier sync, to relative sync, to TDMA sync, where some other capabilities can be implemented to enhance for example interference detection (channel frequency changes, adaptive transmission power...).

Re: v6.40rc [release candidate] is released!

Posted: Fri Jun 30, 2017 4:12 pm
by strods
Version 6.40rc28 has been released.
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 version:
*) console - fixed different command auto complete on <tab>;
*) ethernet - fixed occasional broken interface order after reset/first boot;
*) export - added router model and serial number to configuration export;
*) export - fixed "/interface list" verbose export;
*) export - fixed "/ipv6 route" compact export;
*) export - fixed MPLS "dynamic-label-range" export;
*) export - fixed SNMP "src-address" for compact export;
*) fastpath - improved removing process of dynamic interface;
*) hAP ac lite - removed nonexistent "wlan-led";
*) lte - added info command support for the Jaton LTE modem;
*) ppp - added initial support for ZTE K4203-Z;
*) ppp - added initial support for ZTE ME3630-E;
*) safe-mode - fixed session handling when Safe Mode is used on multiple sessions at the same time;
*) supout - fixed IPv6 firewall section;

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

Re: v6.40rc [release candidate] is released!

Posted: Sat Jul 01, 2017 2:27 pm
by synard
hi
i'm using mikrotik v6.40rc28.

something wrong with address list.
when im using script to add address list and timeout limit has reach 0. it doesn't remove. still in there.
i tried to add manually it's also the same.
but when i using filter, it's work. please fix this in next release.

Re: v6.40rc [release candidate] is released!

Posted: Sat Jul 01, 2017 5:08 pm
by biatche
while doing some testing on dual wan (a lot of plugging and unplugging of ethernet cable / disabling of interfaces), i've also found that /ip route entries may SOMETIMES show as 'unreachable' but via command line it appears to be reachable. so probably a visual bug in winbox... fixed by reopening the ip > route window.

Re: v6.40rc [release candidate] is released!

Posted: Sat Jul 01, 2017 5:13 pm
by pe1chl
Please do some minimal work on the IPv6 routing to allow running IPv6 on 2 internet connections.
At the minimum: implement "/ipv6 route rule" to allow having 2 route tables each with their own default route, selected by (internal) source address.
Better: also implement "/ipv6 firewall nat" with netmap or similar action to allow a static internal address to be mapped to alternative external addresses.
I think the functionality is already in the current kernel, it only requires UI work.

Re: v6.40rc [release candidate] is released!

Posted: Sat Jul 01, 2017 5:16 pm
by pe1chl
More IPv6: updating and activation of licenses do not work over IPv6. Please fix that so it is possible to run a router with only IPv6 connectivity to the internet.

Re: v6.40rc [release candidate] is released!

Posted: Sat Jul 01, 2017 7:16 pm
by bajodel
Please do some minimal work on the IPv6 routing..
+1

Re: v6.40rc [release candidate] is released!

Posted: Sun Jul 02, 2017 1:42 am
by idlemind
Please do some minimal work on the IPv6 routing..
+1
+1, moar IPv6 :)

Re: v6.40rc [release candidate] is released!

Posted: Mon Jul 03, 2017 4:30 pm
by anuser
Version 6.40rc20 has been released.
*) wireless - fixed rare crash on cap disable;
.
problems still appears (currently with v6.40rc28) => Ticket#2017042722000941

Re: v6.40rc [release candidate] is released!

Posted: Tue Jul 04, 2017 12:12 pm
by strods
Version 6.40rc32 has been released.
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 version:
*) dhcpv4-client - added "gateway-address" script parameter;
*) dhcpv4-server - fixed lease renew for DHCP clients that sends renewal with "ciaddr = 0.0.0.0";
*) fasttrack - fixed fasttrack over interfaces with dynamic MAC address;

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

Re: v6.40rc [release candidate] is released!

Posted: Tue Jul 04, 2017 1:02 pm
by mysz0n
It has been a while since the last DUDE update/
Have you stopped working on the dude? or are you working on some major update?

Re: v6.40rc [release candidate] is released!

Posted: Tue Jul 04, 2017 7:17 pm
by zyzelis
IF mikrotik guys are working with dhcp part of ROS, its time to answer - when mikrotik will implement dhcp option 82?
Actually is interested lease issue by circuit-id.
Mikrotik stuff, c'mon you did half of work, go on and finish.

Re: v6.40rc [release candidate] is released!

Posted: Tue Jul 04, 2017 11:59 pm
by Kindis
*) fasttrack - fixed fasttrack over interfaces with dynamic MAC address;
This fixed fasttrack over bonded interfaces using dynamic mac. Great work :)

Re: v6.40rc [release candidate] is released!

Posted: Wed Jul 05, 2017 12:40 am
by juliokato
IF mikrotik guys are working with dhcp part of ROS, its time to answer - when mikrotik will implement dhcp option 82?
Actually is interested lease issue by circuit-id.
Mikrotik stuff, c'mon you did half of work, go on and finish.
Me too interested.

Re: v6.40rc [release candidate] is released!

Posted: Wed Jul 05, 2017 12:43 am
by Chupaka
IF mikrotik guys are working with dhcp part of ROS, its time to answer - when mikrotik will implement dhcp option 82?
Actually is interested lease issue by circuit-id.
we've been using this since 2008 :) you just need external RADIUS :D

Re: v6.40rc [release candidate] is released!

Posted: Wed Jul 05, 2017 2:28 pm
by sindudas
Bug on Winbox, configuring VLAN on a CRS326-24G-2S+ With firmware 6.39.2 and 6.40rc32.

If you try to set a new VLAN with all ports, on winbox you only can put 25 interfaces, but switch has 27 including CPU.
Setting via CLI its possible, but when you open on Winbox, the field Ports shows in Red.

Re: v6.40rc [release candidate] is released!

Posted: Wed Jul 05, 2017 4:12 pm
by strods
sindudas - You should be able to add up to 30 interfaces. Are you sure that simply menu did not go out of your computer display?

Re: v6.40rc [release candidate] is released!

Posted: Wed Jul 05, 2017 9:13 pm
by andlommy
RB2011 in a bootloop after v6.40rc13 upgraded from v6.40 rc9 :(

Re: v6.40rc [release candidate] is released!

Posted: Wed Jul 05, 2017 10:04 pm
by zyzelis
IF mikrotik guys are working with dhcp part of ROS, its time to answer - when mikrotik will implement dhcp option 82?
Actually is interested lease issue by circuit-id.
we've been using this since 2008 :) you just need external RADIUS :D
Hi chupaka,
i have read your posts in forum acc to radius.:) Congrats ;)
But if mikrotik targets to be KisKo alternative, shouldn't they implement their own option82 in dhcp-server, or own radius server, like cisco does?

Re: v6.40rc [release candidate] is released!

Posted: Thu Jul 06, 2017 6:46 am
by IntrusDave
I have a scripting issue.

if one script sets a global, another script is not able to see it. However, I can see them on the console.

Script 1
:global test "test"
Script 2
:put $test
running the scripts from the console, I would expect Script 2 to output "test", but it's output is blank.
However, running ":put $test" on the console, outputs "test"

the Wiki states:
Scripting language has two types of variables:

global - accessible from all scripts created by current user, defined by global keyword;
local - accessible only within the current scope, defined by local keyword.

Re: v6.40rc [release candidate] is released!

Posted: Thu Jul 06, 2017 6:54 am
by mrz
script 2 must be:
:global test;
:put $test

Re: v6.40rc [release candidate] is released!

Posted: Thu Jul 06, 2017 7:19 am
by IntrusDave
script 2 must be:
:global test;
:put $test
OoooOoooohhhhh! Okay :)

Re: v6.40rc [release candidate] is released!

Posted: Thu Jul 06, 2017 11:47 am
by sindudas
sindudas - You should be able to add up to 30 interfaces. Are you sure that simply menu did not go out of your computer display?
I'm really sure that it can't be selected more than 25. It turns the down arrow in grey, disabled.
My screen is much bigger, it is not a display problem, but it does not allow to add more.

Re: v6.40rc [release candidate] is released!

Posted: Thu Jul 06, 2017 11:53 am
by sindudas
sindudas - You should be able to add up to 30 interfaces. Are you sure that simply menu did not go out of your computer display?
Image

Re: v6.40rc [release candidate] is released!

Posted: Thu Jul 06, 2017 12:39 pm
by Chupaka
Forbidden

You don't have permission to access /link/mikrotik-vlan-add.jpeg on this server.

Re: v6.40rc [release candidate] is released!

Posted: Thu Jul 06, 2017 2:30 pm
by pe1chl
Did you try commandline or webfig to add ports?
[edit: I see you did]

Re: v6.40rc [release candidate] is released!

Posted: Thu Jul 06, 2017 2:38 pm
by sindudas
Forbidden

You don't have permission to access /link/mikrotik-vlan-add.jpeg on this server.
It should work now. Sorry, it was geoip restrictions :oops:

Re: v6.40rc [release candidate] is released!

Posted: Fri Jul 07, 2017 3:28 pm
by strods
New topic for 6.40rc has been made:
viewtopic.php?f=21&t=123335