v6.38 [current] is released!

pe1chl · Fri Jan 06, 2017 3:08 pm

a periodic "restart" of ntp (disable+delay+enable) solves the problem at the moment for about 5 minutes as the clock deviates again
devices that are using this ntp-server are still getting bad packets with "server-not-synchronized"

Maybe your clock crystal is too far off to keep synchronized.

moep · Fri Jan 06, 2017 3:21 pm

i did another reboot of the device
now the time stays correct and the other router syncs with this NTP server
i hope it stays that way

a periodic "restart" of ntp (disable+delay+enable) solves the problem at the moment for about 5 minutes as the clock deviates again
devices that are using this ntp-server are still getting bad packets with "server-not-synchronized"
Maybe your clock crystal is too far off to keep synchronized.

pe1chl · Fri Jan 06, 2017 4:35 pm

unfortunately the MikroTik NTP does not implement the management interface so it is difficult to see what is going on inside.
(of course, if it would be implemented, it would require subnet permission settings like in the SNMP service, or else it
would be abused for DDOS)

Fri Jan 06, 2017 4:46 pm

IPsec xAuth with Mode Config (ROS as Client): sometimes after a SA-Rekey the devices are losing their IP-Adresses and are not getting them back until ich do a manual peer "kill connections" which is obviously not the way to go. Until is do this, they have no IP-Address on the Interface making the tunnel anymore and display an invalid policy while at the same time having another identical dynamic policy which is not working because of the missing IP-Address.

Thanks problem confirmed, will try to fix in next v6.39rc version

kujo · Fri Jan 06, 2017 6:32 pm

Who then tested the limit of connections? it seems that the filter rule is not working with him! CHR 6.38

/ip firewall filter add connection-state=new chain=forward connection-nat-state=dst-nat dst-port=443 connection-limit=100,32

Sorry! Work well!! Need add not! To connection-limit

Sent from my iPhone using Tapatalk

sup5 · Fri Jan 06, 2017 8:05 pm

Important note!!!
To avoid STP/RSTP compatibility issues with older RouterOS versions upgrade RouterOS on all routers in Layer2 networks with VLAN and STP/RSTP configurations.

Is there a detailed description how (PV)(R)STP was handled prior ROS 6.38 versus it is being handled with ROS 6.38?

There should be a global setting to restore the old behaviour.
There are large networks which don't use the switch-chip-feature at all and cannot be upgraded at once.

kevini · Fri Jan 06, 2017 9:25 pm

I have the same issue with the Fasttrack on 6.38. With 6.37.3 I had my full 250mbit internet speed without any issues. With 6.38 it dropped to 30Mbit the packets are going through the FP but not at the rates expected.

I have 2 x Hex Gr2's and I use EOIP with IPsec between them. This cannot use the FP but with 6.38 this seems to make all the packets slow. When I disable the EOIP tunnel the speed comes back immediately.

I upgraded to 6.39rc and it works fine again with the EOIP tunnel. So it is either fixed or not merged from 6.38 yet.

Any suggestions? I'm going to upgrade to GR3's in the future to have everything on the FP but since my Comcast upload limits the speed for now it was not needed.

mariuslazar · Fri Jan 06, 2017 9:55 pm

Software 6.38 cpu usage for fasttrack connections very high. For example ( 951g-2hnd at 750mhz) bandwidth 300 Mbps 6.37.3 cpu usage 30-40, 6.38 cpu usage 80-85.

My 951G dropped from 305 Mb/s with ~50% CPU (6.37.3) to 210 Mb/s with 100% CPU (6.38). I had to downgrade to keep the speed up.

If I check the profiler I can see the "networking" is taking ~30%. On 6.37.3 it was about 1% on full speed.

AlexN · Sat Jan 07, 2017 12:19 am

There should be a global setting to restore the old behaviour.
There are large networks which don't use the switch-chip-feature at all and cannot be upgraded at once.

Totally agree. MikroTik team, please, implement this feature. This would be really helpful.

kubisek78 · Sat Jan 07, 2017 10:12 am

Another:

I have RB450G (router1/ovpn server) and 2011UAS (router2/client1) and RB751G (router3/client2). LAN networks of all routers are bridged over OVPN at the server side (and client1+client2 are bridged over EoIP beacause they are in same WAN).
I have found (after upgrading to 6.38 on all RBs) when any client is connected to the OVPN server, the download speed at the router1/server drops to approx 1Mbps (normally DSL 20/2).
When all ovpn clients are disconnected, the spped goes back to 20/2.
I also have found when any of the ovpn clients is connected, there is a lot of upload traffic through DSL pppoe interface. When I "cut" all clients, traffic dissapear and download speed rise to 20 Mb.

Reverting back to 6.37.3 - works perfectly.

ryan0803 · Sat Jan 07, 2017 12:48 pm

I had situation with 6.38 on my CRS
I have CRS-1009 router and CRS-125-24G switch. Both of them was ROS 6.37. I upgraded both to 6.38.
I am using Port based VLAN tagging described in http://wiki.mikrotik.com/wiki/Manual:Interface/VLAN / example #1 on my CRS-125-24
After 6.38 and all IP traffic stopped on my switch. When I disabled Vlan taggings IP traffic started on my management LAN.

I downgraded to 6.37 and Vlan problem disappeared.

İs this the problem you mentioned "To avoid STP/RSTP compatibility issues with older RouterOS versions upgrade RouterOS on all routers in Layer2 networks with VLAN and STP/RSTP configurations."

Thank you.

i have the same problem

i downgrade to 6.37.1 all problem just vanish

pe1chl · Sat Jan 07, 2017 12:56 pm

Please can 6.37.x be made the bugfix release?
There has to be a convenient way to update routers to this version that proves to be quite stable,
and avoid the current problems with 6.38 without having to go back to 6.36.4

darkprocess · Sat Jan 07, 2017 3:40 pm

There is some performance issues on 6.38
On my RB3011
ROS 6.37.3
Download 900Mb/s
Upload 200Mb/s
CPU 14% during speedtest

ROS 6.37.3
Download 260Mb/s
Upload 200Mb/s
CPU 67% during speedtest

I'm back to 6.37.3

heviejob · Sat Jan 07, 2017 8:48 pm

I had the same issue between rb750GL and rb850Gx2. After update to 6.83 on both PPPoE connections over VLANS stopped working. I fiddled for about an hour trying to get the VLANs to work and had to roll back to restore service. I think the changelog needs to be more detailed when such far-reaching changes are done.

GuntherDW · Sun Jan 08, 2017 7:13 am

I have the same issue with the Fasttrack on 6.38. With 6.37.3 I had my full 250mbit internet speed without any issues. With 6.38 it dropped to 30Mbit the packets are going through the FP but not at the rates expected.

Any suggestions? I'm going to upgrade to GR3's in the future to have everything on the FP but since my Comcast upload limits the speed for now it was not needed.

I have a RB750Gr3, almost new, received it around xmas. Updated from 6.37.3, got the 100/20 from my VDSL2 connection over PPPoE, with FP for around ~2-10% CPU usage.
It still says it's going over FP, but takes up to 40%.

This was a minute after I closed Torch to check for bandwith usage.
I did the same test 5 minutes after that and the CPU usage went back down to its previous 2-10%.
The wiki does state that "Torch/packet sniffer/.." type stuff will break the FP stuff, but it seems a bit more delayed now?

Long story short at first I was afraid that I was suffering from the same issue, but it turned out alright.
This is on a somewhat simple NAT home setup though. Modem into the RB to the internal network. Haven't really done anything with VLAN's or VPN's yet.

qiet72 · Sun Jan 08, 2017 2:32 pm

Same problem here, except downgrading to 6.37.3 also makes the vlan problem disappear. This was tested on a hAP ac. Other MikroTik and X86 devices do not seem to have this problem though.
The STP/RSTP compatibility issue does not seem to affect me though as I have 6.37.3 on hAP ac, 6.38 on X86 PC and hAP lite (smips) all connected to the same layer 2 network.

Qiet72

I had situation with 6.38 on my CRS
I have CRS-1009 router and CRS-125-24G switch. Both of them was ROS 6.37. I upgraded both to 6.38.
I am using Port based VLAN tagging described in http://wiki.mikrotik.com/wiki/Manual:Interface/VLAN / example #1 on my CRS-125-24
After 6.38 and all IP traffic stopped on my switch. When I disabled Vlan taggings IP traffic started on my management LAN.

I downgraded to 6.37 and Vlan problem disappeared.

İs this the problem you mentioned "To avoid STP/RSTP compatibility issues with older RouterOS versions upgrade RouterOS on all routers in Layer2 networks with VLAN and STP/RSTP configurations."

Thank you.

liamalxd · Sun Jan 08, 2017 4:39 pm

I think this started in 6.37.3, but it's still broken in 6.38. On my CCR 1009-8G-1S-1S+ the fan speed is not reported correctly in fan1-speed in /system health:

> system health print
fan-mode: auto
use-fan: main
active-fan: main
cpu-overtemp-check: yes
cpu-overtemp-threshold: 70C
cpu-overtemp-startup-delay: 1m
voltage: 24V
current: 825mA
temperature: 31C
cpu-temperature: 55C
power-consumption: 19.9W
psu1-state: ok
psu2-state: ok
fan1-speed: 0RPM

This used to report correctly and seems to start working if you set the use-fan to auxiliary and then back to main again, but breaks again upon a reboot.

pe1chl · Sun Jan 08, 2017 8:11 pm

The fan speed is reported as zero when it is below some threshold (but still running).
When it spins up due to higher outside temp it is displayed. Probably a bug, yes.

colinardo · Sun Jan 08, 2017 9:13 pm

Hi.
I discovered the following problem with the current 6.38 Release on a RB951G-2HnD with the auto certificate feature of CAPsMan:
If you request certificate with a CAP on the same device as the CAPsMAN, the device is unable to issue the private key for the certificate. The certificate for CAP is created ('I' can be seen in certificate list) but without private key ('K' is missing in certificate list), thus it cannot be used by CAP. Also if you manually create the certificate on the router itself with private key, it's not accepted, log says certificate is not valid anymore, but it actually is ... really weird!

Version 6.37.3 in contrast is working fine.

Best regards
@colinardo

manulu · Mon Jan 09, 2017 5:23 am

I have a problem once i've upgrade to
dude-install-6.38.exe
dude-6.38.npk
RB2011UiAS-2HnD
Windows 7 32

the error

no dude package

emikrotik · Mon Jan 09, 2017 8:30 am

Strange Bug:
After upgrading my CCR1009-8G-1S-1S+ from 6.37.3 to 6.38 the exported config mixed up the interface IDs:

/interface ethernet
set [ find default-name=ether5 ] l2mtu=1520 name=ether1-kbd
set [ find default-name=ether6 ] l2mtu=1520 name=ether2
set [ find default-name=ether7 ] l2mtu=1520 name=ether3
set [ find default-name=ether8 ] l2mtu=1520 name=ether4-inl
set [ find default-name=ether1 ] name=ether5-wan-lacp1-1
set [ find default-name=ether2 ] name=ether6-wan-lacp1-2
set [ find default-name=ether3 ] name=ether7-wan
set [ find default-name=ether4 ] name=ether8-wan

This was definitely NOT the actively running config since i did not rename the interfaces that crappy

Just to make sure that the export was wrong tried to load this config into the zeroed device but it failed.

after a manual correction to:

/interface ethernet
set [ find default-name=ether1 ] l2mtu=1520 name=ether1-kbd
set [ find default-name=ether2 ] l2mtu=1520
set [ find default-name=ether3 ] l2mtu=1520
set [ find default-name=ether4 ] l2mtu=1520 name=ether4-inl
set [ find default-name=ether5 ] name=ether5-wan-lacp1-1
set [ find default-name=ether6 ] name=ether6-wan-lacp1-2
set [ find default-name=ether7 ] name=ether7-wan
set [ find default-name=ether8 ] name=ether8-wan

everything worked fine.

Is there any explanation for this effect?

Cheers,

Christoph

Have also experienced this issue 3 times on 2 routers.

LIV2 · Mon Jan 09, 2017 9:23 am

On both my CRS125 and my mAP 2n installing 6.38 results in a unit that won't boot, for both I had to revert to an earlier version using netboot. is this a known issue?

Mon Jan 09, 2017 9:33 am

Hi.
I discovered the following problem with the current 6.38 Release on a RB951G-2HnD with the auto certificate feature of CAPsMan:
If you request certificate with a CAP on the same device as the CAPsMAN, the device is unable to issue the private key for the certificate. The certificate for CAP is created ('I' can be seen in certificate list) but without private key ('K' is missing in certificate list), thus it cannot be used by CAP. Also if you manually create the certificate on the router itself with private key, it's not accepted, log says certificate is not valid anymore, but it actually is ... really weird!

Version 6.37.3 in contrast is working fine.

Best regards
@colinardo

Thank you for the report, we will try to fix this problem in the v6.39.

Mon Jan 09, 2017 9:38 am

There is some performance issues on 6.38
On my RB3011
ROS 6.37.3
Download 900Mb/s
Upload 200Mb/s
CPU 14% during speedtest

ROS 6.37.3
Download 260Mb/s
Upload 200Mb/s
CPU 67% during speedtest

I'm back to 6.37.3

Please report to support@mikrotik.com with a support output file so we could check the configuration and try to reproduce your problem.

Mon Jan 09, 2017 9:40 am

Software 6.38 cpu usage for fasttrack connections very high. For example ( 951g-2hnd at 750mhz) bandwidth 300 Mbps 6.37.3 cpu usage 30-40, 6.38 cpu usage 80-85.
My 951G dropped from 305 Mb/s with ~50% CPU (6.37.3) to 210 Mb/s with 100% CPU (6.38). I had to downgrade to keep the speed up.

If I check the profiler I can see the "networking" is taking ~30%. On 6.37.3 it was about 1% on full speed.

Please report to support@mikrotik.com with a support output file so we could check the configuration and try to reproduce your problem.

kevini · Tue Jan 10, 2017 12:30 am

I submitted my info, I had the standard network diagram etc request which I don't have time to provide. Hopefully with all the people reporting the performance issues they resolve it soon.

zcache · Tue Jan 10, 2017 2:30 am

Hi all,
After upgrade to 6.38, I feel my routerbox temperature too high than before. As I often check before upgraded the temperature about 50-51 but now it is 60-62, anybody have same with me?
My box is: RB850Gx2, already downgrade cpu speed to 400MHz but not effective.
From the changelog:

*) rb850Gx2 - fixed pcb temperature monitor if temperature was above 60C;

Yes, but I wonder why the temperature rise up too high, 10 degree from previous version. Although the box working same function.

[admin@MikroTik] > system health print 
          voltage: 12V
      temperature: 49C
  cpu-temperature: 60C
[admin@MikroTik] >

kiler129 · Tue Jan 10, 2017 3:13 am

Yes, but I wonder why the temperature rise up too high, 10 degree from previous version. Although the box working same function.

From the change log I would assume your board temperature was like 60*C, but ROS was showing lower one (which was fixed in 6.38).

zcache · Tue Jan 10, 2017 5:14 am

Yes, but I wonder why the temperature rise up too high, 10 degree from previous version. Although the box working same function.
From the change log I would assume your board temperature was like 60*C, but ROS was showing lower one (which was fixed in 6.38).

Ohh!! I got it, that it mean the box has kidding me so long time... haha

moep · Tue Jan 10, 2017 8:01 am

I might have found some other IPsec related bugs:
1. sometimes the new "PH states" are not correct, traffic is flowing but there is "no PH2" or "ready to send" which often only reverts after phase1 rekey or new phase2
2. if the initiator is reconnecting too fast e.g. after PPPoE 24 hour reconnect and the old SAs are not flushed on responder, the initiator thinks he is connected and has SAs but the responder has an invalid policy and no traffic can flow.
EDIT
If a peer reconnects after PPoE 24h disconnect within DPD timeout and with a another IP address than before, there will be the situation described in 2.,
I tested this by setting delay before attempting to reconnect to a value greater than the DPD timeout which "solved" the problem. Bit this is clearly not the expected behaviour.
UPDATE
even my workaround did not solve the problem
UPDATE2:
now again a second reboot after the upgrade seems to solve this problem for now (testet with a script doing disable+enable)

as usual, please fix

thank you in advance

Psiho · Tue Jan 10, 2017 10:43 am

Hello! DHCP server in 6.38 and higher version include bug with synthetic NIC (Hyper-V) on my RB-951G. When virtual NIC trying to get offer from dhcp following message in log is appear:

- dhcp,warning,info,debug dhcp1 offering lease Virtual_NIC_IP for Virtual_NIC_MAC without success

As result i lost connect to Hyper-V HOST also. 6.39RC9 - same problem. Return to 6.37 and all become OK again.

majestic · Tue Jan 10, 2017 12:03 pm

Please can 6.37.x be made the bugfix release?
There has to be a convenient way to update routers to this version that proves to be quite stable,
and avoid the current problems with 6.38 without having to go back to 6.36.4

Agree. It would be nice if after every new release that a new repo say called old current/stable or something was created and used to store the previous version as it's very frustrating to have to use net install to switch back to the exact version we were running before.

Also net install has to be done onsite which is not very convenient. If it was more easier to return back to our old version rather then bugfix branch, I'm sure more people would be helping to try and debug issues.

notToNew · Tue Jan 10, 2017 12:22 pm

Please can 6.37.x be made the bugfix release?
There has to be a convenient way to update routers to this version that proves to be quite stable,
and avoid the current problems with 6.38 without having to go back to 6.36.4

No, please NOT!!! 6.36.4 is the only version which works with some older WIFI-Devices, like INTEL 2200.
This version should be supported until the new wireless-package is fixed.

pe1chl · Tue Jan 10, 2017 1:13 pm

Please can 6.37.x be made the bugfix release?
There has to be a convenient way to update routers to this version that proves to be quite stable,
and avoid the current problems with 6.38 without having to go back to 6.36.4
Agree. It would be nice if after every new release that a new repo say called old current/stable or something was created and used to store the previous version

I have suggested that in the 6.39rc thread already but I suspect it cannot be done in an existing release (e.g. by serving a different file from the update server)
so for the current release the marking of 6.37 as bugfix release is probably the only way.
Some people apparently require 6.36.4 but they can just stay at their existing install or use netinstall on new devices.
The currently most occuring situation is "updated to 6.38 then want to go back until new issues are fixed" and for that making 6.37.3 the bugfix release, if only
temporarily, would be easiest.

Tue Jan 10, 2017 1:23 pm

Hello! DHCP server in 6.38 and higher version include bug with synthetic NIC (Hyper-V) on my RB-951G. When virtual NIC trying to get offer from dhcp following message in log is appear:

- dhcp,warning,info,debug dhcp1 offering lease Virtual_NIC_IP for Virtual_NIC_MAC without success

As result i lost connect to Hyper-V HOST also. 6.39RC9 - same problem. Return to 6.37 and all become OK again.

We need more detailed report - provide us export file or support output file so we could try to reproduce this problem.

Psiho · Tue Jan 10, 2017 2:07 pm

Hello! DHCP server in 6.38 and higher version include bug with synthetic NIC (Hyper-V) on my RB-951G. When virtual NIC trying to get offer from dhcp following message in log is appear:

- dhcp,warning,info,debug dhcp1 offering lease Virtual_NIC_IP for Virtual_NIC_MAC without success

As result i lost connect to Hyper-V HOST also. 6.39RC9 - same problem. Return to 6.37 and all become OK again.
We need more detailed report - provide us export file or support output file so we could try to reproduce this problem.

To reproduce this problem you just need to try obtain IP by guest OS's NIC (Hyper-V) from DHCP server in 6.38 and higher version ROS. As for me - i must again do upgrade-downgrade cycle on Router in production. This may take a while - 1 day at least. What will take a less time?

DuduZZZ · Tue Jan 10, 2017 2:28 pm

Hello! DHCP server in 6.38 and higher version include bug with synthetic NIC (Hyper-V) on my RB-951G. When virtual NIC trying to get offer from dhcp following message in log is appear:

- dhcp,warning,info,debug dhcp1 offering lease Virtual_NIC_IP for Virtual_NIC_MAC without success

As result i lost connect to Hyper-V HOST also. 6.39RC9 - same problem. Return to 6.37 and all become OK again.
We need more detailed report - provide us export file or support output file so we could try to reproduce this problem.
To reproduce this problem you just need to try obtain IP by guest OS's NIC (Hyper-V) from DHCP server in 6.38 and higher version ROS. As for me - i must again do upgrade-downgrade cycle on Router in production. This may take a while - 1 day at least. What will take a less time?

I think you don't understand. Uldis request a supout.rif file. More information: http://www.mikrotik.com/support

Psiho · Tue Jan 10, 2017 2:40 pm

Ok, will try to do this tonight

janisk · Tue Jan 10, 2017 3:26 pm

your hyper-v client is a dhcp-client receiving the address from the DHCP server? Or vice versa - server that gives out addresses to mipsbe (or various) devices?

Psiho · Tue Jan 10, 2017 4:06 pm

your hyper-v client is a dhcp-client receiving the address from the DHCP server?

Yes. Mikrotik - DHCP server. Guest OS on HOST and HOST himself - clients

In addition - when described error is occurred, the affected clients remaining in "offering" state in DHCP server - Leases table with cycled 30s timeout. Seems like synthethic NIC dont answer on offer from DHCP, while real ones work as usual. In ROS 6.37 all work fine with both NIC.

gilester · Tue Jan 10, 2017 4:34 pm

your hyper-v client is a dhcp-client receiving the address from the DHCP server?
Yes. Mikrotik - DHCP server. Guest OS on HOST and HOST himself - clients

In addition - when described error is occurred, the affected clients remaining in "offering" state in DHCP server - Leases table with cycled 30s timeout. Seems like synthethic NIC dont answer on offer from DHCP, while real ones work as usual. In ROS 6.37 all work fine with both NIC.

We have observed exactly this with a UniFi UAP-LR and a Soekris Engineering Net4801 board. We have reverted to 6.37.3 to restore correct DHCP behaviour.

Thanks
Giles.

darkmanlv · Wed Jan 11, 2017 2:42 am

fastpath problem on 6.38 with hap ac, download speed dropped to 200 mbps from 500-800 mbps, cpu load is 100%

on 6.37.3 all ok

darkmanlv · Wed Jan 11, 2017 2:48 am

No, please NOT!!! 6.36.4 is the only version which works with some older WIFI-Devices, like INTEL 2200.
This version should be supported until the new wireless-package is fixed.

i have the same problem with hap lite, old toshiba notebook with intel 2200bg doesn`t work if upgrade to 6.37.xx or 6.38, works perfectly on 6.36.4

IanEKB · Wed Jan 11, 2017 9:01 am

Good day!
Error with updating status (reachable) in static routes. System displays "unreachable" for static route, but it is reachable.
Traffic did not go through a second ISP because of this. Changing Distance values did not help.

Fix: change checking gateway type to ARP from PING (WinBox displays reachable now). I turn option back to ping, but status reachable was saved.
Reload whether the status if ISP gateway is not available and will be available again? I not tested it.

Info: SFP-interface (SFP module: WDM SFP-G-03SC-B).

I do not know whether there was a problem in early versions.

P.S.: I am sorry for bad english.

notToNew · Wed Jan 11, 2017 9:31 am

No, please NOT!!! 6.36.4 is the only version which works with some older WIFI-Devices, like INTEL 2200.
This version should be supported until the new wireless-package is fixed.
i have the same problem with hap lite, old toshiba notebook with intel 2200bg doesn`t work if upgrade to 6.37.xx or 6.38, works perfectly on 6.36.4

I have >60 IP-Cams, which only work on 6.36.4. I hope no one asks me to replace them all just because of this

majestic · Wed Jan 11, 2017 9:54 am

Please can 6.37.x be made the bugfix release?
There has to be a convenient way to update routers to this version that proves to be quite stable,
and avoid the current problems with 6.38 without having to go back to 6.36.4

No, please NOT!!! 6.36.4 is the only version which works with some older WIFI-Devices, like INTEL 2200.
This version should be supported until the new wireless-package is fixed.

Adding an extra repo wouldn't effect anything, wouldn't touch the existing versions available, it only would give users an alternative to install, I.e old stable.

notToNew · Wed Jan 11, 2017 10:05 am

Adding an extra repo wouldn't effect anything, wouldn't touch the existing versions available, it only would give users an alternative to install, I.e old stable.

I agree! But the quoted question was not to add an extra version, it was about to replace the current bugfix-version. I support adding a new one!!

majestic · Wed Jan 11, 2017 10:07 am

Adding an extra repo wouldn't effect anything, wouldn't touch the existing versions available, it only would give users an alternative to install, I.e old stable.
I agree! But the quoted question was not to add an extra version, it was about to replace the current bugfix-version. I support adding a new one!!

My bad, wasn't intended. Should proof read what I type more

sorry about that.

MoDest · Wed Jan 11, 2017 10:26 am

It's good idea to add "creation time" column to firewall address list. I hope you do it and for firewall filters and NAT. With this will be easier to find outdated rules in big firewalls with many rules.

Wed Jan 11, 2017 10:32 am

You could use the note feature for that. Enter reason why each rule is made.

pe1chl · Wed Jan 11, 2017 10:42 am

You could use the note feature for that. Enter reason why each rule is made.

In some cases it could be nice to have a "countdown timer" with a rule like with address list members,
to temporarily open some thing without risk to forget to remove it later, but I do not consider it important
enough to make it into a feature request. The comment feature already is a very nice advantage of
RouterOS over competing products and even operating systems.

JuanRamiro · Wed Jan 11, 2017 10:51 am

After upgrading to 6.38, my pppoe connection to WAN speed test makes cpu go to 100%. FastTrack counters seem OK --> FastTrack seems to be configured properly.
Because of the cpu, the router no longer gets 300 mbps at 45% of CPU. Now I get up to 200 mbps at 100%.

notToNew · Wed Jan 11, 2017 10:57 am

You could use the note feature for that. Enter reason why each rule is made.
In some cases it could be nice to have a "countdown timer" with a rule like with address list members,
to temporarily open some thing without risk to forget to remove it later, but I do not consider it important
enough to make it into a feature request. The comment feature already is a very nice advantage of
RouterOS over competing products and even operating systems.

my whish is to get an "time"-object which I can add to any firewall-rules. The tiime-object should have an beginning and an end-datetime.
If added, the rule is only enabled within this time! This has several advantages: 1. Having the "countdown timer" you mentioned 2. Allowing me to enable several
"mainenance"-rules(with several vlans i have over 50 of them) by just extending the end-datetime of this "timeobject" named "Maintenance-AllowExternalAccess "....

pe1chl · Wed Jan 11, 2017 11:24 am

my whish is to get an "time"-object which I can add to any firewall-rules. The tiime-object should have an beginning and an end-datetime.

Well that is already available, but it appears that it allows only cyclic definitions and no date fields. That can probably be fixed rather easily.

notToNew · Wed Jan 11, 2017 11:36 am

Well that is already available, but it appears that it allows only cyclic definitions and no date fields. That can probably be fixed rather easily.

Somehow... it should be available as an own "object", just like the adress-list. If so, I can add several named "time-objects" and add them to te corresponding rules.

pe1chl · Wed Jan 11, 2017 11:43 am

That functionality is not available in netfilter I think, so it would have to be implemented entirely in the management layer.
(you maintain some time object but in reality it is modified in all rules that refer to it)
That is probably more work to implement. The "time" match has this functionality:

   time
       This matches if the packet arrival time/date is within a  given  range.
       All  options  are optional, but are ANDed when specified. All times are
       interpreted as UTC by default.

       --datestart YYYY[-MM[-DD[Thh[:mm[:ss]]]]]

       --datestop YYYY[-MM[-DD[Thh[:mm[:ss]]]]]
              Only match during the given time, which must be in ISO 8601  "T"
              notation.   The  possible  time  range is 1970-01-01T00:00:00 to
              2038-01-19T04:17:07.

              If --datestart or --datestop are not specified, it will  default
              to 1970-01-01 and 2038-01-19, respectively.

       --timestart hh:mm[:ss]

       --timestop hh:mm[:ss]
              Only  match during the given daytime. The possible time range is
              00:00:00 to 23:59:59. Leading zeroes are allowed (e.g.  "06:03")
              and correctly interpreted as base-10.

       [!] --monthdays day[,day...]
              Only match on the given days of the month. Possible values are 1
              to 31. Note that specifying 31  will  of  course  not  match  on
              months  which  do  not have a 31st day; the same goes for 28- or
              29-day February.

       [!] --weekdays day[,day...]
              Only match on the given weekdays. Possible values are Mon,  Tue,
              Wed,  Thu,  Fri,  Sat, Sun, or values from 1 to 7, respectively.
              You may also use two-character variants (Mo, Tu, etc.).

       --contiguous
              When --timestop is smaller than --timestart value, match this as
              a single time period instead distinct intervals.  See EXAMPLES.

       --kerneltz
              Use  the  kernel  timezone instead of UTC to determine whether a
              packet meets the time regulations.

As you can see, datestart and datestop fields could easily be added to give oneshot temporary rules
in addition to the daily/weekly rules that already are available.

notToNew · Wed Jan 11, 2017 3:04 pm

That functionality is not available in netfilter I think, so it would have to be implemented entirely in the management layer.

I know this from shorewall, It is really a nice feature and a nice addition to Mikrotik and I'd appreciate also this smaller solution.
My suggestion from above is just the more "global" version of this.

cristanboj · Wed Jan 11, 2017 3:45 pm

hi guys,

does anyone of you encountered problems in PCC after upgrading their Mikrotik OS?

PCC currently is not working anymore after upgrading . please help.

easyspot · Wed Jan 11, 2017 4:09 pm

GrooveA-52HPn:
Wifi working but scan, freq usage, align, snooper not working. Downgrade to 6.32.4 all working.
Solved: need to press start lol

Wed Jan 11, 2017 6:32 pm

hi guys,

does anyone of you encountered problems in PCC after upgrading their Mikrotik OS?

PCC currently is not working anymore after upgrading . please help.

Just a guess - did you enable fasttrack?

driven · Thu Jan 12, 2017 12:27 am

After upgrading to 6.38, my pppoe connection to WAN speed test makes cpu go to 100%. FastTrack counters seem OK --> FastTrack seems to be configured properly.
Because of the cpu, the router no longer gets 300 mbps at 45% of CPU. Now I get up to 200 mbps at 100%.

Confirm - at 6.38 (and possibly earlier, updated from 6.37) fasttrack is broken, dynamic rules are in "passtrough", as well as on devices that do not support this feature. Downgrade to 6.37 recovers it.

moep · Thu Jan 12, 2017 7:44 am

I might have found some other IPsec related bugs:
1. sometimes the new "PH states" are not correct, traffic is flowing but there is "no PH2" or "ready to send" which often only reverts after phase1 rekey or new phase2
2. if the initiator is reconnecting too fast e.g. after PPPoE 24 hour reconnect and the old SAs are not flushed on responder, the initiator thinks he is connected and has SAs but the responder has an invalid policy and no traffic can flow.
EDIT
If a peer reconnects after PPoE 24h disconnect within DPD timeout and with a another IP address than before, there will be the situation described in 2.,
I tested this by setting delay before attempting to reconnect to a value greater than the DPD timeout which "solved" the problem. Bit this is clearly not the expected behaviour.
UPDATE
even my workaround did not solve the problem
UPDATE2:
now again a second reboot after the upgrade seems to solve this problem for now (testet with a script doing disable+enable)
UPDATE3
second reboot does not solve this for long. after two days the problem is back. responder shows invalid dynamic policy while initiator thinks that he is connected.

as usual, please fix
thank you in advance

UPDATE4
it seems that a double reconnect with a delay makes it possible to "solve" it.
on first (re)connect the bad invalid policy is created on responder and not automatically flushed in time. on second (re)connect the bad policy is removed and a new valid one is created allowing traffic to flow.

sbeauchamp · Thu Jan 12, 2017 3:32 pm

does this fix the out of order packets on the CCR models when using the encryption hardware acceleration?

pe1chl · Thu Jan 12, 2017 4:14 pm

does this fix the out of order packets on the CCR models when using the encryption hardware acceleration?

No.

zennik · Fri Jan 13, 2017 1:17 am

I've noticed with all of my HAP and 2011 Routers I tested on the bench, 6.38 gets really pissy with IPsec after it's running for a few hours. With each one, after about 2-3 hours it just stops passing IPSec traffic, and I can't go into IP/IPSec in Winbox or CLI, and I can't do a config export unless I disable the security package and reboot.
Winbox just gives me no info on those tabs, and in CLI as soon as I go to do a 'print' under any category in IPsec, it just hangs.

pe1chl · Fri Jan 13, 2017 10:30 am

[quote="zennik"][/quote]
Not here. Post your config and/or send a supout.rif file to support.

berny · Fri Jan 13, 2017 11:32 pm

Not sure if bug...

I upgraded to 6.38, I already reset the config to default

When I download or run speed test, the speed (tx/rx) appears also on wlan1 interface, but my pc is connected only via ethernet5

JohnTRIVOLTA · Fri Jan 13, 2017 11:55 pm

I upgraded hEX/v3 - mmips/ to 6.38, firmware to 3.35 . This release broke my speed to 250Mbit/s max for tcp or udp per direction/rx or tx/, both speed 130-150 per direction, whats happenеd ?Only now the load of cpu have equal threads load 20-30%, previously only one thread work on 100% load but speed up 1300Mbit/s!

Mon Jan 16, 2017 5:33 pm

v6.38.1 is released
http://forum.mikrotik.com/viewtopic.php?f=21&t=116951

Who is online