Maybe your clock crystal is too far off to keep synchronized.
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 ![]()
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)
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
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
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.
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.
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.
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.
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.
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
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
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
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.
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.
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.
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.
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.
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
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