Close netinstall, open it again and press install a second time. This time it will work.The device is seen in netinstall, when press the install button it last 12 seconds and then go back ready with no actual install.
Close netinstall, open it again and press install a second time. This time it will work.The device is seen in netinstall, when press the install button it last 12 seconds and then go back ready with no actual install.
/interface ethernet poe monitor [find name=ether5] once do={:put $"poe-out-current"}
Works OK for me (both CCR1009 and RB3011)I can't edit any NAT rule via webfig (tried different browsers on MAC and PC). Seems like a bug.
Tried that, same thing, can't edit it. My co-worker on a Linux box can't edit it either. Really strange problem, I think it's happened after the upgrade. There're about 38 items in the NAT page. The other Mikrotik unit that is also showing this problem also has a large number of NAT rules (RB1100AHx2, powerpc, 6.39.1 (stable))Works OK for me (both CCR1009 and RB3011)I can't edit any NAT rule via webfig (tried different browsers on MAC and PC). Seems like a bug.
Try to clear the browser cache...
I can't edit any NAT rule via webfig (tried different browsers on MAC and PC). Seems like a bug. I can edit everything else on any other window. Just under firewall->NAT that I can't. I click on any NAT rule and nothing happens. I can create new rules but not edit existing ones.
-> firewall -> NAT
RB3011UiAS
6.39.2 (stable)
arm
It happened in two different units. Upgraded via system->packages
The bugfix channel is supposed to only offer the most stable releases, ideally without any known regressions. A new release in the current channel does not (and should never) automatically promote the previous current to bugfix. In my opinion the 6.38.x release series was somewhat buggy, so I'm happy Mikrotik have not promoted it to bugfix.Where are the 6.38.x releases? I think all the 6.38.x must be Bugfix if my logic is right.
Probably wrong arch, try this:..
Can not install dude-6.39.2: system 6.39.2 is not installed, but is required
Any ideas?
/interface ipip set [ find ipsec-secret=1234 local-address=1.1.1.1 remote-address=2.2.2.2 ] local-address=3.3.3.3
You have some scripting to change the tunnel endpoint address in that case? And also at the server side?Upgraded to 6.39.2. IPSec tunnel stopped working.
I saw that if my clients who have dynamic external ip with IPIP tunnel configured with ipsec passphrase cannot initialize phase1 with send error.
It is because of dynamic entry in ipsec policies and peers not changing to new one.
Hello! The problem is solved! Found online program Nelinstall. Is the bootloader firmware in the access point. Connect it to the laptop directly, then rebooted while pressing the "reset" button. Point booted and appeared in the program. I downloaded from the site of the original firmware version 5.26 (Legacy) uploaded it to the spot, "MIRACLE!!!" Point rebooted and worked!!! I think now .to upgrade or not to v6.39.2 or not worth it )))HELP!!!! HELP!!!! HELP!!!!
SXT r2 5nD
v6.39.2
Yesterday went to the spot, saw that there was an upgrade to version v6.39.2, pressed "update and restart".The firmware is loaded, point and rebooted... now it won't turn on!!! The point itself is working, but it is not detected by Winbox.Tried to restart - nothing helps. What to do???
WebFig auto-logins you by default until you change the default admin password or disable or rename the default admin user. This is a documented behavior.In fact it seems you don't even have to authenticate the first time, there seems to be no session checking going on at all.
Thank you! I was actually reading through the manual and discovered my error, and was coming back here to correct it. I suppose I had never noticed before as I had only set the password once for each unit (4 here on site). This is great, thanks again!WebFig auto-logins you by default until you change the default admin password or disable or rename the default admin user. This is a documented behavior.In fact it seems you don't even have to authenticate the first time, there seems to be no session checking going on at all.
the tunnels are usually down just or a moment and then they are re-established. Strange is, that this messages are only in RB1100AHx2 router log, not other other side. The settings are same on both sides, some just tunnels have NAT-T, some not, but this occur for both cases.ipsec, error memory failed to pre-process ph2 packet.
ipsec, error memory peer sent packet for dead phase2
ipsec, error memory peer sent packet for dead phase2
[admin@Mikrotik] > /system resource cpu print oid
0 load=.1.3.6.1.2.1.25.3.3.1.2.0
1 load=.1.3.6.1.2.1.25.3.3.1.2.1
2 load=.1.3.6.1.2.1.25.3.3.1.2.2
3 load=.1.3.6.1.2.1.25.3.3.1.2.3
4 load=.1.3.6.1.2.1.25.3.3.1.2.4
5 load=.1.3.6.1.2.1.25.3.3.1.2.5
6 load=.1.3.6.1.2.1.25.3.3.1.2.6
7 load=.1.3.6.1.2.1.25.3.3.1.2.7
8 load=.1.3.6.1.2.1.25.3.3.1.2.8
# snmpwalk -v2c -c public 192.168.88.1 .1.3.6.1.2.1.25.3.3.1.2
iso.3.6.1.2.1.25.3.3.1.2.1 = INTEGER: 0
iso.3.6.1.2.1.25.3.3.1.2.2 = INTEGER: 0
iso.3.6.1.2.1.25.3.3.1.2.3 = INTEGER: 0
iso.3.6.1.2.1.25.3.3.1.2.4 = INTEGER: 0
iso.3.6.1.2.1.25.3.3.1.2.5 = INTEGER: 1
iso.3.6.1.2.1.25.3.3.1.2.6 = INTEGER: 5
iso.3.6.1.2.1.25.3.3.1.2.7 = INTEGER: 0
iso.3.6.1.2.1.25.3.3.1.2.8 = INTEGER: 0
iso.3.6.1.2.1.25.3.3.1.2.9 = INTEGER: 0
Thank you for this confirmation. I know guys ypu do your best to fix problems, and your work is really appreciated by all the users around.l0pes, upower3 - Both these problems are reproduced and will be fixed in upcoming RouterOS releases.
This could be the result of Fasttrack rules that are not correct (although usually the observed behaviour is reverse: it starts to work when you run packet sniffer or torch).Can anybody else confirm - we are noticing a serious problem with EoIP and Packet Sniffer / Torch. If we run a packet capture or torch, all EoIP traffic stops. When we stop the capture or torch, EoIP traffic works again. This appears to be a bug?
By the way, is there any approach how to reset fasttrack state? i suspect I can see how it keep process traffic with old rules even when there are some changes or new rules added?This could be the result of Fasttrack rules that are not correct (although usually the observed behaviour is reverse: it starts to work when you run packet sniffer or torch).
We don't have FastTrack rules - we are an ISP and fasttrack has no benefit for us. We have sites with up to a hundred customers on EoIP tunnel and they all go down if someone runs a torch or sniffer.This could be the result of Fasttrack rules that are not correct (although usually the observed behaviour is reverse: it starts to work when you run packet sniffer or torch).Can anybody else confirm - we are noticing a serious problem with EoIP and Packet Sniffer / Torch. If we run a packet capture or torch, all EoIP traffic stops. When we stop the capture or torch, EoIP traffic works again. This appears to be a bug?
Not sure if this was directed towards me but I did and the current bug-fix didn't do the trick.Looks like it worth to switch to bugfix branch and proceed with it.
Frankly, I keep seeing this on every ROS version so far for every small device (951, 941, 926 etc), so looks like they should just hide this option for these devices. Not a big deal, anyway, not breaking anything.On hAPac (RB926UiGS-5HacT2HnT) it'n not possible to disable all LEDs.
Winbox System/LEDs/Settings ->immediate results in
"Couldn't change LED Settings - This feature is not supported on this board (6)"
Sure. No big issue...I feel your pain but hope MT guys will fix more serious things first.
Reinstall RouterOS via Netinstall.Any suggestions?
You must carefully read the instructions on how long to press the button.I've tried that but, as I said, holding down reset button does nothing except flashing SFP led a few times and then reset again.
You said you tried to reset your device, not using Netinstall. Anyways, when some device does not boot, your set of options is rather limited:I've tried that but, as I said, holding down reset button does nothing
I did. I've tried to hold it until SFP starts flashing fast (this is the only LED that shows something actullay is happening). Nothing.You must carefully read the instructions on how long to press the button.I've tried that but, as I said, holding down reset button does nothing except flashing SFP led a few times and then reset again.
Well, thank you very much for that but, since it is clear that this is not my fault, I am not going to throw 100 eur in the garbage. I just clicked "Upgrade" button and nothing else.[*] Go buy another device.[/list]
Well, I did actually read everything I could find before coming here. Reset button does not help in any way.Check this wiki page out to learn what backup bootloader is, and how reset button works (hint- it does different things depending on when it is pressed and how long it is being hold).
Meaning: you should try steps above before buying a replacement. Nothing else.Well, thank you very much for that but, since it is clear that this is not my fault, I am not going to throw 100 eur in the garbage. I just clicked "Upgrade" button and nothing else.[*] Go buy another device.[/list]
/system logging action
add memory-lines=100 name=ipsec target=memory
/system logging
add action=ipsec topics=ipsec,!debug
15:11:37 ipsec <IP A> notify: R_U_THERE_ACK
15:11:37 ipsec sendto Information notify.
15:11:37 ipsec receive Information.
15:11:37 ipsec <IP B> notify: R_U_THERE_ACK
15:11:38 ipsec receive Information.
15:11:38 ipsec <IP C> notify: R_U_THERE
15:11:38 ipsec sendto Information notify.
15:11:38 ipsec sendto Information notify.
15:11:38 ipsec receive Information.
15:11:38 ipsec <IP C> notify: R_U_THERE
15:11:38 ipsec sendto Information notify.
15:11:38 ipsec receive Information.
15:11:38 ipsec <IP C> notify: R_U_THERE_ACK
15:11:39 ipsec sendto Information notify.
15:11:39 ipsec receive Information.
15:11:39 ipsec <IP C> notify: R_U_THERE_ACK
15:11:57 ipsec receive Information.
15:11:57 ipsec <IP A> notify: R_U_THERE
15:11:57 ipsec sendto Information notify.
15:11:57 ipsec sendto Information notify.
15:11:57 ipsec sendto Information notify.
15:11:57 ipsec receive Information.
15:11:57 ipsec <IP A> notify: R_U_THERE_ACK
15:11:57 ipsec receive Information.
15:11:57 ipsec <IP B> notify: R_U_THERE_ACK
15:11:58 ipsec receive Information.
15:11:58 ipsec <IP C> notify: R_U_THERE
15:11:58 ipsec sendto Information notify.
15:11:58 ipsec receive Information.
15:11:58 ipsec <IP C> notify: R_U_THERE
15:11:58 ipsec sendto Information notify.
15:11:58 ipsec sendto Information notify.
15:11:58 ipsec receive Information.
15:11:58 ipsec <IP C> notify: R_U_THERE_ACK
15:11:59 ipsec sendto Information notify.
15:11:59 ipsec receive Information.
15:11:59 ipsec <IP C> notify: R_U_THERE_ACK
15:12:17 ipsec receive Information.
15:12:17 ipsec <IP A> notify: R_U_THERE
15:12:17 ipsec sendto Information notify.
15:12:17 ipsec sendto Information notify.
15:12:17 ipsec sendto Information notify.
15:12:17 ipsec receive Information.
15:12:17 ipsec <IP B> notify: R_U_THERE_ACK
15:12:17 ipsec receive Information.
15:12:17 ipsec <IP A> notify: R_U_THERE_ACK
15:12:18 ipsec receive Information.
15:12:18 ipsec <IP C> notify: R_U_THERE
15:12:18 ipsec sendto Information notify.
15:12:18 ipsec sendto Information notify.
15:12:18 ipsec receive Information.
15:12:18 ipsec <IP C> notify: R_U_THERE
15:12:18 ipsec sendto Information notify.
15:12:18 ipsec receive Information.
15:12:18 ipsec <IP C> notify: R_U_THERE_ACK
15:12:19 ipsec sendto Information notify.
15:12:19 ipsec receive Information.
15:12:19 ipsec <IP C> notify: R_U_THERE_ACK
15:12:37 ipsec receive Information.
15:12:37 ipsec <IP A> notify: R_U_THERE
15:12:37 ipsec sendto Information notify.
15:12:37 ipsec sendto Information notify.
15:12:37 ipsec sendto Information notify.
15:12:37 ipsec receive Information.
15:12:37 ipsec <IP B> notify: R_U_THERE_ACK
15:12:37 ipsec receive Information.
15:12:37 ipsec <IP A> notify: R_U_THERE_ACK
15:12:38 ipsec receive Information.
15:12:38 ipsec <IP C> notify: R_U_THERE
15:12:38 ipsec sendto Information notify.
15:12:38 ipsec sendto Information notify.
15:12:38 ipsec receive Information.
15:12:38 ipsec <IP C> notify: R_U_THERE
15:12:38 ipsec sendto Information notify.
15:12:38 ipsec receive Information.
15:12:38 ipsec <IP C> notify: R_U_THERE_ACK
15:12:39 ipsec sendto Information notify.
15:12:39 ipsec receive Information.
15:12:39 ipsec <IP C> notify: R_U_THERE_ACK
15:12:57 ipsec receive Information.
15:12:57 ipsec <IP A> notify: R_U_THERE
15:12:57 ipsec sendto Information notify.
15:12:57 ipsec sendto Information notify.
15:12:57 ipsec sendto Information notify.
15:12:57 ipsec receive Information.
15:12:57 ipsec <IP B> notify: R_U_THERE_ACK
15:12:57 ipsec receive Information.
15:12:57 ipsec <IP A> notify: R_U_THERE_ACK
15:12:58 ipsec receive Information.
15:12:58 ipsec <IP C> notify: R_U_THERE
15:12:58 ipsec sendto Information notify.
15:12:58 ipsec sendto Information notify.
15:12:58 ipsec receive Information.
15:12:58 ipsec <IP C> notify: R_U_THERE
15:12:58 ipsec sendto Information notify.
15:12:58 ipsec receive Information.
15:12:58 ipsec <IP C> notify: R_U_THERE_ACK
15:12:59 ipsec sendto Information notify.
15:12:59 ipsec receive Information.
15:12:59 ipsec <IP C> notify: R_U_THERE_ACK
Well I can understand that he wants to have ipsec logs in a separate logging action. I also sometimes make separateNot really sure where is the problem, if you do not want to see ispec logs, then remove/disable this entry
add action=ipsec topics=ipsec,!debug
That would leave the logging action unused.Not really sure where is the problem, if you do not want to see ispec logs, then remove/disable this entry
add action=ipsec topics=ipsec,!debug
I would be surprised if they have a topic that isn't listed in the log, but sure I will try it out tomorrow.Maybe they are in the "notice" level? Try adding "!notice".
14:59:20 ipsec sendto Information notify.
14:59:20 ipsec receive Information.
14:59:20 ipsec <IP A> notify: R_U_THERE_ACK
14:59:39 ipsec receive Information.
14:59:39 ipsec <IP A> notify: R_U_THERE
14:59:39 ipsec sendto Information notify.
14:59:40 ipsec sendto Information notify.
14:59:40 ipsec receive Information.
14:59:40 ipsec <IP A> notify: R_U_THERE_ACK
14:59:59 ipsec receive Information.
14:59:59 ipsec <IP A> notify: R_U_THERE
14:59:59 ipsec sendto Information notify.
15:00:00 ipsec sendto Information notify.
15:00:00 ipsec receive Information.
15:00:00 ipsec <IP A> notify: R_U_THERE_ACK
15:00:20 ipsec sendto Information notify.
15:00:21 ipsec <IP A> DPD: remote (ISAKMP-SA <IP B>[500]<=><IP A>[500] spi=4ab151a42b54a0c4:9a01fa76c1e10987) seems to be dead.
15:00:21 ipsec purged IPsec-SA spi=0x9805042
15:00:21 ipsec purged IPsec-SA spi=0xd7a4b4
15:00:21 ipsec purged IPsec-SA spi=0xe9fbe69
15:00:21 ipsec purged IPsec-SA spi=0x73063ec
15:00:21 ipsec purged ISAKMP-SA <IP B>[500]<=><IP A>[500] spi=4ab151a42b54a0c4:9a01fa76c1e10987.
15:00:27 ipsec sent phase1 packet <IP B>[500]<=><IP A>[500] b3f71d77b6b5680e:0000000000000000
15:00:27 ipsec received Vendor ID: CISCO-UNITY
15:00:27 ipsec received Vendor ID: DPD
15:00:28 ipsec sent phase1 packet <IP B>[500]<=><IP A>[500] b3f71d77b6b5680e:0ee9cf89d80c8924
15:00:28 ipsec sent phase1 packet <IP B>[500]<=><IP A>[500] b3f71d77b6b5680e:0ee9cf89d80c8924
15:00:28 ipsec ph2 possible after ph1 creation
15:00:28 ipsec initiate new phase 2 negotiation: <IP B>[500]<=><IP A>[500]
15:00:28 ipsec sent phase2 packet <IP B>[500]<=><IP A>[500] b3f71d77b6b5680e:0ee9cf89d80c8924:bdb16d2f
15:00:28 ipsec IPsec-SA established: ESP/Tunnel <IP A>[500]-><IP B>[500] spi=0x4a17936
15:00:28 ipsec IPsec-SA established: ESP/Tunnel <IP B>[500]-><IP A>[500] spi=0x8d8c73c
15:00:28 ipsec ph2 possible after ph1 creation
15:00:28 ipsec initiate new phase 2 negotiation: <IP B>[500]<=><IP A>[500]
15:00:28 ipsec sent phase2 packet <IP B>[500]<=><IP A>[500] b3f71d77b6b5680e:0ee9cf89d80c8924:8a4f2dc1
15:00:28 ipsec IPsec-SA established: ESP/Tunnel <IP A>[500]-><IP B>[500] spi=0xe3f85b5
15:00:28 ipsec IPsec-SA established: ESP/Tunnel <IP B>[500]-><IP A>[500] spi=0x975fad7
15:00:48 ipsec receive Information.
15:00:48 ipsec <IP A> notify: R_U_THERE
15:00:48 ipsec sendto Information notify.
15:00:48 ipsec sendto Information notify.
15:00:48 ipsec receive Information.
15:00:48 ipsec <IP A> notify: R_U_THERE_ACK
15:01:08 ipsec sendto Information notify.
15:01:08 ipsec receive Information.
15:01:08 ipsec <IP A> notify: R_U_THERE
15:01:08 ipsec sendto Information notify.
15:01:08 ipsec receive Information.
15:01:08 ipsec <IP A> notify: R_U_THERE_ACK
That's awesome to read. Thank you very much, 'tik! Looking forward to v6.40 coming out of RC!Problem already solved in v6.40rc now DPD logs have ipsec,debug topics.
Ah awesome, thank you. I guess I haven't tried the newest version of the release candidates.Problem already solved in v6.40rc now DPD logs have ipsec,debug topics.
Good link, thank you, but the news is not that nice, if the routing behavior changed between bugfix and current branches. Will wait for comments!The way load balancing was configured in 6.37 doesn't work in 6.39.2.
Using https://mum.mikrotik.com/presentations/US12/steve.pdf leads to the same issue.