Community discussions

 
elgrandiegote
newbie
Posts: 40
Joined: Tue Feb 05, 2013 6:02 am
Location: Buenos Aires, Argentina

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 3:35 pm

Hi strods,

i've upgraded several devices from version 6.44.3 (RB3011, RB2011) but the problem is with the CHR, however i can connect via ssh without problem,
I use WinBox 3.18 without RADIUS
regards
ludvik - On some specific and very rare case Ethernet interface on TILE routers could lock up. Now this problem is resolved;
ndbjorne, kobuki, smileymattj - Bugfix version (long-term) will be released as soon as possible;
eworm, matiaszon, toxmost, Stanleyssm, wpeople, petrb, lomayani - I recommend that you provide supout file to support@mikrotik.com in order to get more information about the problem that you are experiencing;
pacman88 - CRS3xx switches now can better handle traffic passing through the switch if interface speeds are different;
nmt1900 - Can you reproduce this problem once more? Actually. sounds that this was simply a coincidence and the problem was caused by something else besides static ARP entries;
raystream, nichky, LetMeRepair, proximus, Cha0s, 3bs, Vlad2, sterod, mserge, STEVEUK1, elgrandiegote - We can not seem to reproduce the problem with Winbox login. Can you provide more details? From which version did you upgrade your router? Do you, for example, use RADIUS for Winbox authorisation?
SimWhite, nuffrespect, w0lt, snake27, Hyperlight - Please try to add a new firewall rule at every end of the tunnel and see if it starts to work properly? The rule should be located at the top (at least before drop rules) of input firewall filter rules chain (/ip firewall filter add chain=input action=accept protocol=gre src-address=[address that is configured as a remote-address on your GRE tunnel interface]);
rifkytech, bleblas, marcperea, mducharme, nerxu, jwilkinson6028 - If you cannot login into your router by using API please make sure that you have updated API authentication script (https://wiki.mikrotik.com/wiki/Manual:API#Initial_login);
anav - Is this problem related to RouterOS v6.45.1 or this is simply a configuration related question?
OndrejHolas - We will resolve this problem as soon as possible;
markos222 - Currently fix is available only in v6.45. Fix will be backported to long-term versions aswell;
adonato - MIPS and MMIPS are two differnet architectures. Is it RB750 or RB750Gr3? Please name precise model.
 
3bs
newbie
Posts: 48
Joined: Tue Aug 09, 2011 12:33 am
Location: Irkutsk, Russia

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 3:37 pm

Hey. What about low capacity of space in hAP lite? Watever I did, it says not enough space. Every time.
Try uninstall additional packages, then update. After update install packages.
WBR, 3bs =)
 
dakotabcn
newbie
Posts: 29
Joined: Thu Apr 21, 2016 11:16 pm

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 3:48 pm

I have downgraded to 6.44.3 the rb4011 with wifi due fails with L2TP connections
Mi computer connect with any problem, but other users no connect, the log report phase1 negotiation failed
Others router RB3011 have the same issue
All routers have NAT for Inet (the ftth/hfc router is wit NAT) and all computers have win8/10 with nat trasversal
This bug is vert bad, please repair

thx!
 
User avatar
lenciso
just joined
Posts: 9
Joined: Wed Aug 03, 2016 3:46 pm
Location: PERÚ

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 4:07 pm

I updated 2 RB2011 and 2 RB951 without problems.
Luiz Enciso
 
berzerker
just joined
Posts: 18
Joined: Thu Oct 26, 2017 6:55 am

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 4:08 pm

!) ike2 - added support for EAP authentication methods (eap-tls, eap-ttls, eap-peap, eap-mschapv2) as initiator;
Since this is "as initiator," can I assume this isn't supported for running as a roadwarrior config?

If so, when is support for that coming, if at all?
Road warrior client is always an initiator, so I do not see the reason why it shouldn't be supported.
Well, I'm receiving an error trying to add an identity for IKEv2 w/ EAP-TLS authentication, saying it's only supported as a client.
[admin@RB4011] /ip ipsec identity> add peer=ikev2 auth-method=eap eap-methods=eap-tls remote-certificate=ios-client generate-policy=port-strict
failure: only EAP client supported  
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 5934
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 4:11 pm

As far as I understand you are trying to configure server. Server requires RADIUS server with EAP support. Locally on the router it is not supported.
 
berzerker
just joined
Posts: 18
Joined: Thu Oct 26, 2017 6:55 am

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 4:19 pm

As far as I understand you are trying to configure server. Server requires RADIUS server with EAP support. Locally on the router it is not supported.
Ok...so that goes back to my original question. Will this be supported without the requirement of RADIUS, locally on ROS?
 
Gusse
just joined
Posts: 1
Joined: Fri Feb 22, 2019 2:17 am

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 4:21 pm

RESOLVED: OVPN Server Binding was causing some issues. I deleted the old one instances and made a new one, then it started to work again.

I noticed issues with Android OpenVPN client after upgrade. Before it worked ok, but now I get this. Log full of this TUN write error.
16:08:56.806 -- EVENT: ASSIGN_IP

16:08:56.884 -- Connected via tun

16:08:56.885 -- EVENT: CONNECTED info='xxxx@xxc.xxx:1194 (xxx.xxx.xxx.xxx) via /TCPv4 on tun/10.0.0.84/ gw=[10.0.0.85/]' trans=TO_CONNECTED

16:09:22.049 -- TUN write error: write_some: Invalid argument

16:09:22.054 -- TUN write error: write_some: Invalid argument
Last edited by Gusse on Tue Jul 02, 2019 5:48 pm, edited 1 time in total.
 
enzain
just joined
Posts: 20
Joined: Wed Jan 17, 2018 9:15 pm

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 4:22 pm

Some routers after upgrade not allow login

Username or password incorrect.
 
User avatar
Cha0s
Forum Veteran
Forum Veteran
Posts: 903
Joined: Tue Oct 11, 2005 4:53 pm

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 4:38 pm

Everyone who is experiencing problems with Winbox authorization - we will release a new Winbox loader with a fix for this problem as soon as possible. We are very sorry for any inconvenience caused.
While you are at it, will you fix the interfaces last up/down times on winbox that are in the future?
 
sindy
Forum Guru
Forum Guru
Posts: 3814
Joined: Mon Dec 04, 2017 9:19 pm

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 4:39 pm

It is wrong if initiator is remote router.
Can you be more verbose? "initiator" is a role of an IPsec peer, but there is no "initiator/responder" or "client/server" role related to GRE, both ends of the tunnel are sending no matter whether the remote end responds or not and no matter whether a corresponding IPsec policy is available or not, and no matter what is the role of the IPsec peer used by that policy. As there are no ports in GRE, and as the ID field is the same for all packets, an IP.A (local) ->IP.B (remote) packet passing the output chain should create a tracked connection, so a received packet IP.B->IP.A should match "connection-state=established" in the input chain.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 5934
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 4:54 pm

In terms of connection tracking there will be always the one that initiates/creates (call it whatever you like) new connection. If remote device trying to initiate connection it should not be accepted by "establish/related" rule because connection does not exist yet. That is what happened before the fix.
 
artem1
just joined
Posts: 1
Joined: Tue Jul 02, 2019 5:00 pm

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 5:05 pm

After upgrade my CHR on intel with aes-ni to 6.45.1 I see flag "Hardware AEAD" is gray (off) (in IPSEC on installed SA tab).
Before upgrade this flag was shown as enabled (black).
Enc: sha1+aes-cbc128
 
petern
just joined
Posts: 22
Joined: Wed Dec 13, 2017 5:58 pm

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 5:08 pm

Can you be more verbose? "initiator" is a role of an IPsec peer, but there is no "initiator/responder" or "client/server" role related to GRE, both ends of the tunnel are sending no matter whether the remote end responds or not and no matter whether a corresponding IPsec policy is available or not, and no matter what is the role of the IPsec peer used by that policy. As there are no ports in GRE, and as the ID field is the same for all packets, an IP.A (local) ->IP.B (remote) packet passing the output chain should create a tracked connection, so a received packet IP.B->IP.A should match "connection-state=established" in the input chain.
I think you have it the wrong way around. GRE itself may not have initiator/responder terminology, but connection-tracking does. Thus, if the GRE packet first comes from the remote side, you need to explicitly allow it and not rely on established, as it isn't yet an established connection. I've always used an explicit allow rule for this, as that's how it should work.
 
User avatar
Anumrak
Forum Guru
Forum Guru
Posts: 1041
Joined: Fri Jul 28, 2017 2:53 pm

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 5:19 pm

Hey. What about low capacity of space in hAP lite? Watever I did, it says not enough space. Every time.
Try uninstall additional packages, then update. After update install packages.
This is abnormal behavior. I'll wait for a fix for this.
 
sindy
Forum Guru
Forum Guru
Posts: 3814
Joined: Mon Dec 04, 2017 9:19 pm

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 5:36 pm

In terms of connection tracking there will be always the one that initiates/creates (call it whatever you like) new connection. If remote device trying to initiate connection it should not be accepted by "establish/related" rule because connection does not exist yet. That is what happened before the fix.
OK, so I assume you are saying that if the GRE packet comes from outside first (and, logically, doesn't match connection-state=established), no outgoing GRE packet will ever be sent because the local side only responds to connection attempts coming from the remote one inside the GRE tunnel, and the GRE packets carrying these connection attempts get dropped.

What about the GRE keepalives then? I've often created GRE tunnels with no actual payload traffic to use them for minutes and they did come up nevertheless, so I've always thought the keepalive packets are what creates the tracked connection.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
nmt1900
newbie
Posts: 27
Joined: Wed Feb 01, 2017 12:36 am

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 6:34 pm

nmt1900 - Can you reproduce this problem once more? Actually. sounds that this was simply a coincidence and the problem was caused by something else besides static ARP entries
Router has one bridge with 2 addresses/subnets on it without VLANs and ARP in reply-only mode.

Subnet 1 has DHCP with add-arp-for-leases=yes and it is main subnet with client devices in it.
Subnet 2 has only some other devices in it for testing and static ARP entries for these devices in router's ARP list.

This setup worked without problems before, but now there is a problem:
subnet 1 works OK, devices can access each other and public internet and this subnet can be accessed over incoming VPN connection
subnet 2 cannot be accessed from subnet 1 and devices in subnet 2 cannot access router, subnet 1 or public internet. Devices in it cannot be accessed over incoming VPN connection either. Other Mikrotik devices in subnet 2 can only be accessed by MAC telnet or RoMON when problem is present.

Devices from subnet 2 will regain access after their static ARP entries are removed and added back, but after some time problem comes back - just like ARP entries are aged out, but still existing in list.

Everything works OK, when ARP is set to enabled mode.
If ARP is left to reply-only mode and accept rule (subnet 1 and subnet 2 as both source and destination) is added to forward chain, then it looks like this rule also solves the problem. This was not needed before


Long story got shorter - I moved one device with static address and ARP entry from subnet 2 to subnet 1. For some weird reason additional dynamic ARP entry started popping up with old IP address and it did not went away although IP address did not exist at that time. Then I moved this device back to subnet 2 and only the right ARP entry remained. Problem disappeared after that.
Last edited by nmt1900 on Tue Jul 02, 2019 11:08 pm, edited 1 time in total.
 
buset1974
Frequent Visitor
Frequent Visitor
Posts: 50
Joined: Wed Sep 13, 2006 12:12 pm
Location: Jakarta

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 7:09 pm

i'am having "rebooted without proper shutdown by watchdog timer" again after upgrading to 6.45.1 on CCR-1036-8G-2S+ from 6.44.3
It's has ipv4 and ipv6 running on the routers
We have this kind of issues last years and already fixed and it happen again now, please check my tickets #2018060122002189
Please check what changed on 6.45.1 that caused this happen again.

thx
 
antonina2
just joined
Posts: 3
Joined: Tue Jul 02, 2019 7:19 pm

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 7:30 pm

Updated the router to the current version.
After the update, we can not work. :( LAN computers behind RB951 cannot connect to PPTP servers.
We stopped work. Help.

P.S. Sorry, I know English very bad.
 
sindy
Forum Guru
Forum Guru
Posts: 3814
Joined: Mon Dec 04, 2017 9:19 pm

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 7:33 pm

Updated the router to the current version.
After the update, we can not work. :( LAN computers behind RB951 cannot connect to PPTP servers.
We stopped work. Help.

P.S. Sorry, I know English very bad.
PPTP uses GRE to transport data. If the PPTP connections seem to be up but no data actually pass through them, look earlier in this thread for the firewall rule necessary to allow GRE to work. As the PPTP clients run on the LAN computers, not on the Mikrotik itself, the rule will have to be effective in the forward chain.
Last edited by sindy on Tue Jul 02, 2019 7:39 pm, edited 2 times in total.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
antonina2
just joined
Posts: 3
Joined: Tue Jul 02, 2019 7:19 pm

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 7:38 pm

PPTP uses GRE to transport data. If the PPTP connections seem to be up but no data actually pass through them, look earlier in this thread for the firewall rule necessary to allow GRE to work. As the PPTP clients run on the LAN computers, not on the Mikrotik itself, the rule will have to be effective in the forward chain.
I tried different rules from this branch, nothing helps. Could you give an example of the rule? Thanks.

1    ;;; defconf: accept established,related,untracked
      chain=input action=accept connection-state=established,related,untracked log=no log-prefix="" 

 2    ;;; defconf: drop invalid
      chain=input action=drop connection-state=invalid log=no log-prefix="" 

 3    ;;; defconf: accept ICMP
      chain=input action=accept protocol=icmp 

 4    ;;; defconf: drop all not coming from LAN
      chain=input action=drop in-interface-list=!LAN log=no log-prefix="" 

 5    ;;; defconf: accept in ipsec policy
      chain=forward action=accept log=no log-prefix="" ipsec-policy=in,ipsec 

 6    ;;; defconf: accept out ipsec policy
      chain=forward action=accept log=no log-prefix="" ipsec-policy=out,ipsec 

 7    ;;; defconf: fasttrack
      chain=forward action=fasttrack-connection connection-state=established,related 

 8    ;;; defconf: accept established,related, untracked
      chain=forward action=accept connection-state=established,related,untracked 

 9    ;;; defconf: drop invalid
      chain=forward action=drop connection-state=invalid log=no log-prefix="" 

10    ;;; defconf:  drop all from WAN not DSTNATed
      chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN log=no log-prefix="" 

11    ;;; Drop BOGONS List
      chain=input action=drop src-address-list=BOGONS in-interface-list=WAN log=yes log-prefix="" 
Last edited by antonina2 on Tue Jul 02, 2019 7:40 pm, edited 1 time in total.
 
sindy
Forum Guru
Forum Guru
Posts: 3814
Joined: Mon Dec 04, 2017 9:19 pm

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 7:40 pm

Could you give an example of the rule?
/ip firewall filter add chain=forward action=accept protocol=gre src-address=ip.address.of.the.PPTP.server

It must be at the right place in the forward chain. If you're not sure, create a dedicated topic and post the export of your configuration there. See my automatic signature for details.

The rule should be placed between rules 8 and 9 in your /ip firewall filter print above.

And more than that:
  • as we talk about multiple PPTP servers, you probably need to use src-address-list in the rule, which contains addresses of all the servers, not just a single src-address,
  • as we talk about the forward chain, you need another rule where the same address-list is used as dst-address-list, as the first packet to be tunneled via GRE may come from either direction.
Last edited by sindy on Tue Jul 02, 2019 7:50 pm, edited 1 time in total.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
jsadler
just joined
Posts: 1
Joined: Tue Sep 18, 2018 1:10 pm
Location: New Zealand

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 7:47 pm

I also have the Winbox Login Problem that has been mentioned....

I note that this is ***INTERMITTENT*** and so far it seems to only happen on links with higher latency.

I've upgraded approx 20 devices. This may or may not be a coincidence, however I have noted that devices that are nearby to my location are fine (approx 15) and don't have any login issues. Devices which are far away, eg international, or local but via LTE mobile data links (eg high latency) etc seem to have the issue (5 devices)

I've seen the login issue on CHR, LTAP and CRS, so I don't think it matters which hardware variant you are using.

When my login is failing, if I keep clicking connect in Winbox, it will usually connect after 5 to 10 attempts.

Note that the router logs the invalid connection attempt as a login failure for user xyz with the source IP of the winbox client, but other than that nothing else of interest is logged.

Cheers,
Jono.
 
User avatar
petrb
Frequent Visitor
Frequent Visitor
Posts: 96
Joined: Thu Jan 26, 2017 4:17 pm

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 7:53 pm

DHCPv6 PD with RADIUS not work with dhcp6c in linux/ubnt .... work in 6.44.3. Work with DHCPv6 client with mikrotik. Very simple radius configuration:

744d288d0d1e => Mikrotik DHCPv6 client works (can fail when prefix is changed and release action is not invoked)
f09fc24af7e8 => UBNT/Ubuntu tested linux dhcp6c FAIL - works in 6.44.3
dhcp,error item: radius authentication failed for f09fc24af7e8 ::/60: prefix changed ::/60 -> 2a01:5e0:31:1000::/60
select * from radcheck
f09fc24af7e8      | Auth-Type          | := | Accept 
744d288d0d1e      | Auth-Type          | := | Accept
select * from radreply
f09fc24af7e8      | Delegated-IPv6-Prefix | =  | 2a01:5e0:31:1000::/60
744d288d0d1e      | Delegated-IPv6-Prefix | =  | 2a01:5e0:31:2000::/60


EDIT: main difference between dhcp6 client in MK and other is in receive value "ia_pd prefix" in first solication and compare value with radius. MK client not send "ia_pd prefix". Linux send ::/64(::/60 in my exmaple).




cat /etc/dhcp6c.conf
interface ath0 {
	request domain-name-servers;
	send ia-na 1;
	send ia-pd 1;
	script "/usr/bin/dhcp6c-state";
};

id-assoc na 1 {
};

id-assoc pd 1 {
	prefix ::/60 infinity;
	prefix-interface eth0 {
		sla-id 0;
		sla-len 4;
	};
};
Did you read manual? .... What? .... Read the manual.
 
nightcom
newbie
Posts: 37
Joined: Wed Aug 30, 2017 12:47 am
Location: NL

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 8:21 pm

I see some of you have problems, just to make it more clear below is list of units that I upgraded to 6.45.1 without problems

RB3011UiAS-RM
hex RB750Gr3

Upgraded via Winbox 3.18
RB3011UiAS-RM / RB2011UiAS-in / RB750Gr3 + Dude / CRS326-24G-2S+RM
 
mserge
just joined
Posts: 9
Joined: Tue May 28, 2019 8:51 pm

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 8:41 pm

Everyone who is experiencing problems with Winbox authorization - we will release a new Winbox loader with a fix for this problem as soon as possible. We are very sorry for any inconvenience caused.
Any news about when will the new winbox be available?
 
kadety
just joined
Posts: 17
Joined: Tue Mar 12, 2019 1:42 pm

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 8:49 pm

Some routers after upgrade not allow login

Username or password incorrect.

I have the same problem. RB951G

Username or password incorrect.


Does anyone have a solution? Please
 
antonina2
just joined
Posts: 3
Joined: Tue Jul 02, 2019 7:19 pm

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 9:10 pm

/ip firewall filter add chain=forward action=accept protocol=gre src-address=ip.address.of.the.PPTP.server

It must be at the right place in the forward chain. If you're not sure, create a dedicated topic and post the export of your configuration there. See my automatic signature for details.

The rule should be placed between rules 8 and 9 in your /ip firewall filter print above.

And more than that:
  • as we talk about multiple PPTP servers, you probably need to use src-address-list in the rule, which contains addresses of all the servers, not just a single src-address,
  • as we talk about the forward chain, you need another rule where the same address-list is used as dst-address-list, as the first packet to be tunneled via GRE may come from either direction.
For me it does not work.

Experimentally found out.
We have always been disabled service-port
/ip firewall service-port
set ftp disabled=yes
set tftp disabled=yes
set irc disabled=yes
set h323 disabled=yes
set sip disabled=yes
set pptp disabled=yes
set udplite disabled=yes
set dccp disabled=yes
set sctp disabled=yes
Enabling pptp solved the problem.
Now the clients of the local network can connect to the pptp servers in the Internet.

2mrz & strods
This is a bug, or so it is conceived?
Why does this affect forward pptp?
/ip firewall service-port
set pptp disabled=yes
 
sindy
Forum Guru
Forum Guru
Posts: 3814
Joined: Mon Dec 04, 2017 9:19 pm

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 9:43 pm

This is a bug, or so it is conceived?
Please do read the previous posts of this topic. @strods has already explained that a bug (with its own CVE) was the previous behaviour, where incoming GRE was allowed to pass through the firewall even without a corresponding permissive rule in place.

Why does this affect forward pptp?
/ip firewall service-port
set pptp disabled=yes
It didn't come to my mind you could have the helpers disabled as by default they are enabled, so I was expecting a PPTP helper didn't exist at all, so I've suggested those rules above. My fault.

The whole /ip firewall service-port section deals with cases where communication using one protocol controls establishment of connections which use another protocol. So the firewall analyses the information in the control protocol and creates a connection-tracking record marked with connection-state=related in advance, before the first packet of that "controlled" connection arrives. So in the particular case of PPTP, when a PPTP control session between a client and the server gets established inside a TCP session (port 1723 on server side), the PPTP helper in the firewall prepares a tracked GRE connection between the IP addresses of the client and the server, so the rule action=accept chain=forward connection-state=established,related accepts these packets even though no rule explicitly permitting them exists in the forward chain.

/ip firewall connection-print where protocol~"gre" should show you a connection marked with E in the attributes column, which means Expected, which means connection-state=related.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
adonato
just joined
Posts: 19
Joined: Thu Mar 05, 2015 5:29 pm

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 10:07 pm

ludvik - On some specific and very rare case Ethernet interface on TILE routers could lock up. Now this problem is resolved;
ndbjorne, kobuki, smileymattj - Bugfix version (long-term) will be released as soon as possible;
eworm, matiaszon, toxmost, Stanleyssm, wpeople, petrb, lomayani - I recommend that you provide supout file to support@mikrotik.com in order to get more information about the problem that you are experiencing;
pacman88 - CRS3xx switches now can better handle traffic passing through the switch if interface speeds are different;
nmt1900 - Can you reproduce this problem once more? Actually. sounds that this was simply a coincidence and the problem was caused by something else besides static ARP entries;
raystream, nichky, LetMeRepair, proximus, Cha0s, 3bs, Vlad2, sterod, mserge, STEVEUK1, elgrandiegote - We can not seem to reproduce the problem with Winbox login. Can you provide more details? From which version did you upgrade your router? Do you, for example, use RADIUS for Winbox authorisation?
SimWhite, nuffrespect, w0lt, snake27, Hyperlight - Please try to add a new firewall rule at every end of the tunnel and see if it starts to work properly? The rule should be located at the top (at least before drop rules) of input firewall filter rules chain (/ip firewall filter add chain=input action=accept protocol=gre src-address=[address that is configured as a remote-address on your GRE tunnel interface]);
rifkytech, bleblas, marcperea, mducharme, nerxu, jwilkinson6028 - If you cannot login into your router by using API please make sure that you have updated API authentication script (https://wiki.mikrotik.com/wiki/Manual:API#Initial_login);
anav - Is this problem related to RouterOS v6.45.1 or this is simply a configuration related question?
OndrejHolas - We will resolve this problem as soon as possible;
markos222 - Currently fix is available only in v6.45. Fix will be backported to long-term versions aswell;
adonato - MIPS and MMIPS are two differnet architectures. Is it RB750 or RB750Gr3? Please name precise model.




Hello I have a RouterBOARD 750G r3


uptime: 14h59m39s
version: 6.44.3 (stable)
build-time: Apr/23/2019 12:37:03
factory-software: 6.36.1
free-memory: 167.8MiB
total-memory: 256.0MiB
cpu: MIPS 1004Kc V2.15
cpu-count: 4
cpu-frequency: 880MHz
cpu-load: 6%
free-hdd-space: 172.0KiB
total-hdd-space: 16.3MiB
write-sect-since-reboot: 146662
write-sect-total: 84183238
bad-blocks: 0%
architecture-name: mmips
board-name: hEX
platform: MikroTik

Sorry, bu Does anyone know what to do??
 
fmoses
just joined
Posts: 8
Joined: Tue Mar 15, 2005 8:04 pm
Location: Fenton MI USA
Contact:

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 10:14 pm

After upgrading to 6.45.1 PPPOE Profile bandwidth defaults are not creating simple queues. Radius auth is working but if the radius server does not send Mikrotik-Rate for a user ( meaning use the profiles default settings ) it does not. Only users with a defined Mikrotik-Rate get simple queues created... IE for higher bandwidth packages..
---------------
Fred Moses
 
gdemtcev
just joined
Posts: 2
Joined: Tue Jul 02, 2019 10:18 pm

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 10:22 pm

RouterOS version 6.45.1 (2019-Jun-27 10:23) has broken RADIUS PAP auth!!!

We have 500+ clients with Mikrotik devices and 27 june in our RADIUS server we see many errors from Mikrotik devices:

Mon Jul 1 11:04:53 2019 : Auth: Login incorrect (rlm_pap: CLEAR TEXT password check failed): [XX-XX-FA-92-17-09/XX-XX-FA-92-17-0] (from client internet-network port 2152726528 cli XX:XX::FA:92:17:09)
Mon Jul 1 11:12:29 2019 : Auth: Login incorrect (rlm_pap: CLEAR TEXT password check failed): [XX-XX-80-DC-6F-96/XX-XX-80-DC-6F-9L1\313\033\\ݍ\351\037\231,\205\201҅\236] (from client internet-network port 2152726529 cli XX:XX::80:DC:6F:96)
Mon Jul 1 11:12:40 2019 : Auth: Login incorrect (rlm_pap: CLEAR TEXT password check failed): [XX-XX-80-DC-6F-96/XX-XX-80-DC-6F-9\006o\377\255\202[\224>\264\351\3103%xe\234] (from client internet-network port 2152726530 cli XX:XX:80:DC:6F:96)
... and man many many logs ...

After update to 6.45.1 all request from Mikrotik to RADIUS have broken last symbol in password (PAP, plain text)

We reproduce this bug in our office on 5+ devices.

How i can open bug report to this error?
 
ivanfm
newbie
Posts: 46
Joined: Sun May 20, 2012 5:07 pm

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 10:56 pm

RouterOS version 6.45.1 (2019-Jun-27 10:23) has broken RADIUS PAP auth!!!

We have 500+ clients with Mikrotik devices and 27 june in our RADIUS server we see many errors from Mikrotik devices:

Mon Jul 1 11:04:53 2019 : Auth: Login incorrect (rlm_pap: CLEAR TEXT password check failed): [XX-XX-FA-92-17-09/XX-XX-FA-92-17-0] (from client internet-network port 2152726528 cli XX:XX::FA:92:17:09)
Mon Jul 1 11:12:29 2019 : Auth: Login incorrect (rlm_pap: CLEAR TEXT password check failed): [XX-XX-80-DC-6F-96/XX-XX-80-DC-6F-9L1\313\033\\ݍ\351\037\231,\205\201҅\236] (from client internet-network port 2152726529 cli XX:XX::80:DC:6F:96)
Mon Jul 1 11:12:40 2019 : Auth: Login incorrect (rlm_pap: CLEAR TEXT password check failed): [XX-XX-80-DC-6F-96/XX-XX-80-DC-6F-9\006o\377\255\202[\224>\264\351\3103%xe\234] (from client internet-network port 2152726530 cli XX:XX:80:DC:6F:96)
... and man many many logs ...

After update to 6.45.1 all request from Mikrotik to RADIUS have broken last symbol in password (PAP, plain text)

We reproduce this bug in our office on 5+ devices.

How i can open bug report to this error?
This reports should be made by e-mail to support@mikrotik.com .

I have already reported it for hotspot ( #2019070222007151 ) and other person also found same problem in wireless authentication : viewtopic.php?f=19&t=149811

I did not receive any response from my ticket .
 
OndrejHolas
just joined
Posts: 19
Joined: Mon Jul 30, 2018 5:54 pm

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 10:57 pm

CCR1009, 6.44.3 -> 6.45.1. After upgrade, bonding interface didn't go up. I use two levels of bonding: two low level bonding interfaces, each consisting of two ethernets, bundled to LACP LAG; and one upper level bonding interface, consisting of the two LAGs:

/interface bonding
add mode=802.3ad name=lacp1 slaves=ether5,ether6 transmit-hash-policy=layer-3-and-4
add mode=802.3ad name=lacp2 slaves=ether7,ether8 transmit-hash-policy=layer-3-and-4
add down-delay=1s mode=active-backup name=trunk1 primary=lacp1 slaves=lacp1,lacp2 transmit-hash-policy=layer-2-and-3 up-delay=5s

Up to version 6.44.3 this worked reliably. After upgrade to 6.45.1, the low level bondings (lacp1 and lacp2) go up after boot, but the upper level bonding (trunk1) doesn't notice link change from its slaves and remains down. Disconnecting and reconnecting cables, firmware upgrade, warm and cold reboots, nothing helps.

After disabling and re-enabling upper level bonding interface (/int disa trunk1; /int ena trunk1), it starts to work, including functional failover/failback after link state changes of slaves. Nevertheless, this works only until reboot.

Permanent workaround that worked for me:

/system scheduler
add name="trunk1 fix 6.45.1" on-event=":delay 10s;/int disa trunk1;/int ena trunk1" policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon start-time=startup

Submitted to support as Ticket#2019070222008098.

Ondrej
 
sindy
Forum Guru
Forum Guru
Posts: 3814
Joined: Mon Dec 04, 2017 9:19 pm

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 11:05 pm

Sorry, bu Does anyone know what to do??
adonato - instead of the package for mipsbe you've tried to install, download the package for mmips which is the architecture of your device as reported by /system resource print.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
gdemtcev
just joined
Posts: 2
Joined: Tue Jul 02, 2019 10:18 pm

Re: v6.45.1 [stable] is released!

Tue Jul 02, 2019 11:11 pm

RouterOS version 6.45.1 (2019-Jun-27 10:23) has broken RADIUS PAP auth!!!

We have 500+ clients with Mikrotik devices and 27 june in our RADIUS server we see many errors from Mikrotik devices:

Mon Jul 1 11:04:53 2019 : Auth: Login incorrect (rlm_pap: CLEAR TEXT password check failed): [XX-XX-FA-92-17-09/XX-XX-FA-92-17-0] (from client internet-network port 2152726528 cli XX:XX::FA:92:17:09)
Mon Jul 1 11:12:29 2019 : Auth: Login incorrect (rlm_pap: CLEAR TEXT password check failed): [XX-XX-80-DC-6F-96/XX-XX-80-DC-6F-9L1\313\033\\ݍ\351\037\231,\205\201҅\236] (from client internet-network port 2152726529 cli XX:XX::80:DC:6F:96)
Mon Jul 1 11:12:40 2019 : Auth: Login incorrect (rlm_pap: CLEAR TEXT password check failed): [XX-XX-80-DC-6F-96/XX-XX-80-DC-6F-9\006o\377\255\202[\224>\264\351\3103%xe\234] (from client internet-network port 2152726530 cli XX:XX:80:DC:6F:96)
... and man many many logs ...

After update to 6.45.1 all request from Mikrotik to RADIUS have broken last symbol in password (PAP, plain text)

We reproduce this bug in our office on 5+ devices.

How i can open bug report to this error?
This reports should be made by e-mail to support@mikrotik.com .

I have already reported it for hotspot ( #2019070222007151 ) and other person also found same problem in wireless authentication : viewtopic.php?f=19&t=149811

I did not receive any response from my ticket .
Already send, twice, but not response yet...(
 
User avatar
Panbambaryla
just joined
Posts: 7
Joined: Sat Jun 08, 2019 12:12 pm

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 12:59 am

Upgraded RB4011 from 6.44.3 to 6.45.1 - no issues
Well, actually there is one - the bridge MAC address has changed so the network discovery on Windows must be done again. In my case the bridge MAC addr is the same as for eth7 interface. Interesting what it depends on...
Best
Bam
Well, the bridge MAC address changes with RB4011 WiFI reboot so from time to time you will have to change your Windows network from public to private until it cycles all MAC addresses from your eth interfaces. Mikrotik, could you please explain if it is expected behaviour or rather some side effect of the latest firmware?
Best, Bam
Best, Bam
 
Spirch
newbie
Posts: 44
Joined: Sat May 03, 2014 5:04 am

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 4:16 am

wow 4 pages already, i'm happy to always wait a few days before installing things that can bring down my network or make thing difficult.

people still deploy stuff in mass without testing them?

time to wait a little bit longer and see the evolution of this thread
 
User avatar
Xymox
Member
Member
Posts: 387
Joined: Thu Jan 21, 2010 5:04 pm
Location: Phoenix, Arizona US
Contact:

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 5:07 am

Upgraded RB4011 from 6.44.3 to 6.45.1 - no issues
Well, actually there is one - the bridge MAC address has changed so the network discovery on Windows must be done again. In my case the bridge MAC addr is the same as for eth7 interface. Interesting what it depends on...
Best
Bam
Well, the bridge MAC address changes with RB4011 WiFI reboot so from time to time you will have to change your Windows network from public to private until it cycles all MAC addresses from your eth interfaces. Mikrotik, could you please explain if it is expected behaviour or rather some side effect of the latest firmware?
Best, Bam
I saw some real weirdness with the 4011.. Maybe the above is part of it. Briefly it was rebooting too. The unit has settled down and I am going to try and downgrade it back to 44.3..

Im running 45.1 on my home CCR and so far it seems fine, but, im just doing a home NAT setup, nothing involved at all.

YEA... Remember everybody, use partitions if your device supports them. Makes for a easy switch back. Before upgrading, copy to and save to a partition. THEN upgrade. You then have a fall back. I would like to be able to pick partitions from the LCD on units that have a LCD..
 
User avatar
strods
MikroTik Support
MikroTik Support
Posts: 1407
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 7:51 am

spacex - We will look into this problem;
Anumrak - Yes, hAP lite and similar routers are designed to run RouterOS bundle package and can be upgraded without any problems, as long as you do not store anything else on your router that might fill up the storage. If there is not enough space on the disk for upgrades - remove files, limit features that use disk and use separate packages instead of RouterOS bundle package;
boquepasha - Which RouterOS version is installed on the router from which you start MAC Telnet session? Is it at least RouterOS version 6.43?
elgrandiegote, enzain, jsadler, kadety - As mentioned in previous posts, we have already resolved this problem and will release Winbox 3.19 with a fix as soon as possible;
dakotabcn, artem1, petrb, fmoses, Xymox - I recommend that you provide supout file to support@mikrotik.com in order to get more information about the problem that you are experiencing;
Gusse - Can you reproduce this problem once more? Actually, sounds that this was simply a coincidence and the problem was caused by something else;
Cha0s - Unfortunately, this problem is not resolved yet;
mserge - I can not tell you precisely when it will be released, but it will happen as soon as possible (hopefully later today);
adonato - You have not replied which router do you have. Provide the output of the command ":put [/system resource get architecture]". It will tell you which architecture packages you must download in order to upgrade your router;
Panbambaryla - That is why you can set static MAC address on the bridge interface. If it is not set, then the bridge will use MAC address of the first interface which is loaded in RouterOS after a reboot;

Everyone - Please note that MikroTik team provide free support for you if you have a software or hardware related problem. Usually, we reply within three business days (sometimes it might take longer). All of the tickets that you have created will be replied to as soon as possible.
 
User avatar
Murmaider
Member Candidate
Member Candidate
Posts: 121
Joined: Fri Oct 30, 2015 10:10 am

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 9:34 am

170 updates and changes and not one BGP improvement...
 
boquepasha
just joined
Posts: 2
Joined: Tue Jul 02, 2019 2:43 pm

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 9:59 am

That might be the problem, strods. The device from where we were trying to mac-telnet our customer had version 6.42.3. We'll upgrade that device and tell you back with our findings.
 
User avatar
petrb
Frequent Visitor
Frequent Visitor
Posts: 96
Joined: Thu Jan 26, 2017 4:17 pm

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 10:33 am

Supout file was sent to the support. Thanks
Did you read manual? .... What? .... Read the manual.
 
User avatar
NetVicious
Member Candidate
Member Candidate
Posts: 109
Joined: Fri Nov 13, 2009 3:30 pm
Location: Spain

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 10:39 am

Hi!
As I read before on this thread It seems 6.45.1 has some problem with GRE.
I have some Mikrotik RB450G (call they A, B, C, .....) connected to one RB850Gxx2 (call him as master).

"Master" has one PPTP Server binding for each other (A, B, C).

After upgrading all the devices to 6.45.1, A and C cannot connect to "master" within PPTP, but B was working perfectly.

A, B and C had practically the same configuration.

After trying some changes, I did a downgrade on A and C and it's PPP started to work another time without doing any other change.

I did some screenshots of the logs

Log with 6.45.1 (pptp don't connects)
Image

Log with 6.44.3 (pptp connects correctly)
Image
. . //\/ e t . \/ i c i o u s ..
 
pe1chl
Forum Guru
Forum Guru
Posts: 5833
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 11:07 am

As I read before on this thread It seems 6.45.1 has some problem with GRE.
When you do make the effort of reading the topic first and seeing others with the same problem, why don't you go that tiny step further and read the replies that they got (also from MikroTik) about the cause of this "problem with GRE" and how you can solve it other dan by downgrading?
 
pe1chl
Forum Guru
Forum Guru
Posts: 5833
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 11:10 am

Upgraded RB4011 from 6.44.3 to 6.45.1 - no issues
Well, actually there is one - the bridge MAC address has changed so the network discovery on Windows must be done again. In my case the bridge MAC addr is the same as for eth7 interface. Interesting what it depends on...
Best
Bam
Well, the bridge MAC address changes with RB4011 WiFI reboot so from time to time you will have to change your Windows network from public to private until it cycles all MAC addresses from your eth interfaces. Mikrotik, could you please explain if it is expected behaviour or rather some side effect of the latest firmware?
Best, Bam
As always, when the MAC address of a bridge is important you should not configure it as "auto mac" but rather set its "admin mac address" manually.
You can just copy and paste the address it has now.
 
User avatar
NetVicious
Member Candidate
Member Candidate
Posts: 109
Joined: Fri Nov 13, 2009 3:30 pm
Location: Spain

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 11:30 am

As I read before on this thread It seems 6.45.1 has some problem with GRE.
When you do make the effort of reading the topic first and seeing others with the same problem, why don't you go that tiny step further and read the replies that they got (also from MikroTik) about the cause of this "problem with GRE" and how you can solve it other dan by downgrading?
Sorry. I did the downgrade as a fast attempt to fix the problem because I had users waiting to connect.
I read the thread after the downgrade.
I will try the temporal fix later when users are not working.
. . //\/ e t . \/ i c i o u s ..
 
User avatar
Anumrak
Forum Guru
Forum Guru
Posts: 1041
Joined: Fri Jul 28, 2017 2:53 pm

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 11:39 am

spacex - We will look into this problem;
Anumrak - Yes, hAP lite and similar routers are designed to run RouterOS bundle package and can be upgraded without any problems, as long as you do not store anything else on your router that might fill up the storage. If there is not enough space on the disk for upgrades - remove files, limit features that use disk and use separate packages instead of RouterOS bundle package;
boquepasha - Which RouterOS version is installed on the router from which you start MAC Telnet session? Is it at least RouterOS version 6.43?
elgrandiegote, enzain, jsadler, kadety - As mentioned in previous posts, we have already resolved this problem and will release Winbox 3.19 with a fix as soon as possible;
dakotabcn, artem1, petrb, fmoses, Xymox - I recommend that you provide supout file to support@mikrotik.com in order to get more information about the problem that you are experiencing;
Gusse - Can you reproduce this problem once more? Actually, sounds that this was simply a coincidence and the problem was caused by something else;
Cha0s - Unfortunately, this problem is not resolved yet;
mserge - I can not tell you precisely when it will be released, but it will happen as soon as possible (hopefully later today);
adonato - You have not replied which router do you have. Provide the output of the command ":put [/system resource get architecture]". It will tell you which architecture packages you must download in order to upgrade your router;
Panbambaryla - That is why you can set static MAC address on the bridge interface. If it is not set, then the bridge will use MAC address of the first interface which is loaded in RouterOS after a reboot;

Everyone - Please note that MikroTik team provide free support for you if you have a software or hardware related problem. Usually, we reply within three business days (sometimes it might take longer). All of the tickets that you have created will be replied to as soon as possible.
There are no files on the flash drive. Why I didn't need to remove other packages in previous upgrades?
 
andriys
Forum Guru
Forum Guru
Posts: 1180
Joined: Thu Nov 24, 2011 1:59 pm
Location: Kharkiv, Ukraine

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 11:40 am

I will try the temporal fix later when users are not working.
Temporary? Please read the topic once again, carefully. This version fixes a bug that allowed GRE to work even when your device was configured improperly. So you do not need to apply a temporary fix, but rather permanently fix your configuration.
 
User avatar
NetVicious
Member Candidate
Member Candidate
Posts: 109
Joined: Fri Nov 13, 2009 3:30 pm
Location: Spain

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 12:11 pm

@andriys. Sorry but I don't saw the official strods post answering a lot of posts of this threads with the info about GRE.

I said temporary fix because I have some RB450G with 6.45.1 running perfectly against a RB850Gx2 with 6.45.1 without any new firewall rule about GRE. That's why I though it's a temporary fix.
. . //\/ e t . \/ i c i o u s ..
 
User avatar
jetzcezt
just joined
Posts: 1
Joined: Wed Jul 03, 2019 12:10 pm

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 12:20 pm

Hello good People :) ,

if you are using PEAR2_Net_RouterOS-1.0.0b6 API by Vasil Rangelov (boenrobot), replace code on Client.php for 7 rows, start at line 292 until line 298, to be :
$request->setArgument('password',$password);
just that one line for make it usable again.
 
User avatar
strods
MikroTik Support
MikroTik Support
Posts: 1407
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 12:48 pm

Winbox 3.19 has been released:

viewtopic.php?f=21&p=737780#p737780
 
andriys
Forum Guru
Forum Guru
Posts: 1180
Joined: Thu Nov 24, 2011 1:59 pm
Location: Kharkiv, Ukraine

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 12:51 pm

@andriys. Sorry but I don't saw the official strods post answering a lot of posts of this threads with the info about GRE.
It was in a (rather long) post here.
And then a followup here.
 
joserudi
Frequent Visitor
Frequent Visitor
Posts: 66
Joined: Thu Nov 22, 2007 10:16 pm

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 12:56 pm

After upgrading to 6.45.1 PPPOE Profile bandwidth defaults are not creating simple queues. Radius auth is working but if the radius server does not send Mikrotik-Rate for a user ( meaning use the profiles default settings ) it does not. Only users with a defined Mikrotik-Rate get simple queues created... IE for higher bandwidth packages..
I have the same problem, PPPOE and HOTSPOT Profile defaults bandwith are not creating simple rules. Only its possible acroos radius-rate
 
User avatar
glee
just joined
Posts: 5
Joined: Fri Aug 18, 2017 5:44 pm

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 1:13 pm

Is there any ETA for long-term release which will fix vulnerabilities?
 
sindy
Forum Guru
Forum Guru
Posts: 3814
Joined: Mon Dec 04, 2017 9:19 pm

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 1:39 pm

@andriys. Sorry but I don't saw the official strods post answering a lot of posts of this threads with the info about GRE.

I said temporary fix because I have some RB450G with 6.45.1 running perfectly against a RB850Gx2 with 6.45.1 without any new firewall rule about GRE. That's why I though it's a temporary fix.
For these GRE (and EoIP, it's the same story as EoIP is an application using GRE) tunnels which work in 6.45.1 without modification, something at both ends must be sending initial connection requests to the tunnel (TCP SYN, DNS queries, whatever), so each end creates an established connection in its local firewall on its own. It may also be caused by keepalives configured on GRE itself if there is no spontaneous traffic. Tunnel ends where keepalive is disabled and all local side devices are just listening servers will not establish the GRE tunnel without the rule in chain input of ip firewall filter (if they are tunnel endponi devices themselves); for transit PPTP, and maybe also for locally terminated PPTP, the PPTP helper must be enabled in ip firewall service-port.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
notToNew
Member Candidate
Member Candidate
Posts: 147
Joined: Fri Feb 19, 2016 3:15 pm

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 1:43 pm

Is there any ETA for long-term release which will fix vulnerabilities?
You didnt read the thread, did you?
--------------------------------------------------------------------------------------------
CCR1036-12G-4S, several 952Ui-5ac2nD, ...
 
User avatar
glee
just joined
Posts: 5
Joined: Fri Aug 18, 2017 5:44 pm

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 2:08 pm

Is there any ETA for long-term release which will fix vulnerabilities?
You didnt read the thread, did you?
I did, so far there has been only "as soon as possible". It's been 6 days!
I don't get it why it is taking so long.. Fixes for CVE-2018-14847 were released for all channels at same day.
Last edited by glee on Wed Jul 03, 2019 2:41 pm, edited 1 time in total.
 
User avatar
Lifz
newbie
Posts: 40
Joined: Tue Feb 26, 2013 1:05 pm

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 2:14 pm

Is there any ETA for long-term release which will fix vulnerabilities?
You didnt read the thread, did you?
I did, so far there has been only "as soon as possible". It's been 3 days!
I don't get it why it is taking so long.. Fixes for CVE-2018-14847 were released for all channels at same day.
Long term: When a Stable release has been out for a while and seems to be stable enough, it gets promoted into the Long Term branch, replacing an older release, which is then moved to Archive. This consecutively adds new features.
 
jamesw
newbie
Posts: 27
Joined: Tue Jul 04, 2017 2:52 pm

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 2:23 pm

We are also facing the same issue with Hotspot / RADIUS authentication broken because the Password that is send to RADIUS is garbage/corrupt.

This is affecting 1000+ customers to a big issue.

Case raised; ticket #2019070322005393

Thanks for any help.

James
 
pe1chl
Forum Guru
Forum Guru
Posts: 5833
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 2:31 pm

Is there any ETA for long-term release which will fix vulnerabilities?
You can fix the vulnerabilities using a firewall rule...
 
LeftyTs
Frequent Visitor
Frequent Visitor
Posts: 71
Joined: Thu Nov 03, 2016 2:39 am
Location: Athens, Greece
Contact:

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 2:32 pm

In a CRS326, RoS complains about collisions in a half duplex interface. I have had problems before with this interface as it needed to be reset every few days [Ticket#2018122022004844]. I have even set the specific Ethernet interface to "full-duplex=no speed=10Mbps" and those warning messages should not exist as it is normal for collisions to occur in half duplex interfaces.

12:40:19 interface,warning ether16 excessive or late collision, link duplex mismatch?

In any case, there seems to be improvement from previous versions as the Gigabit interfaces have not stopped from working yet when I was testing the beta version.
 
User avatar
glee
just joined
Posts: 5
Joined: Fri Aug 18, 2017 5:44 pm

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 2:36 pm

Is there any ETA for long-term release which will fix vulnerabilities?
You didnt read the thread, did you?
I did, so far there has been only "as soon as possible". It's been 6 days!
I don't get it why it is taking so long.. Fixes for CVE-2018-14847 were released for all channels at same day.
Long term: When a Stable release has been out for a while and seems to be stable enough, it gets promoted into the Long Term branch, replacing an older release, which is then moved to Archive. This consecutively adds new features.
I would argue that releasing software that includes security fixes should be also released to all channels at same day since this will leave devices who are running on long-term channel exploitable. There wasn't even "Testing" channel release, so they really rushed it out only for Stable channel... why? I guess cause of the security fixes.. why not handle long-term same way?

Anywho I upgraded our lab two days ago to 6.45.1. These are my notes:

These models have been running OK.
  • CCR1016-12S-1S+
  • CRS317-1G-16S+
  • CRS226-24G-2S+
  • RB M33G with R11e-LTE and R11e-4G
  • wAP 60GHz
  • SXTsq 5GHz
  • RB3011UiAS
  • RB4011iGS+
  • hAP AC
  • cAP AC
Features tested with this release in lab.
  • Streaming Packet Sniffer
  • LTE
  • L2TP over IPsec
  • EoIP over IPSec
  • SSTP
  • IPSec
  • OSPF
  • VRRP
  • Bonding
  • Mangle
  • Queues
  • Wireless
  • CAPsMAN
  • SNMPv3
 
pe1chl
Forum Guru
Forum Guru
Posts: 5833
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 3:23 pm

I would argue that releasing software that includes security fixes should be also released to all channels at same day since this will leave devices who are running on long-term channel exploitable.
The portion of devices running the latest long-term version and being actively managed by someone/some team who would install a security update in the current long-term channel immediately once it becomes available is likely very, very, very small.

Especially as there is no automatic update mechanism (with its associated security fix channel) in RouterOS, most devices are not regularly updated and many run versions that are very old and have really critical vulnerabilities (compared to this one).
People that elect to run the long-term version also usually are quite conservative in updating it.

Furthermore, you can fix this one with a firewall rule. I have done so early on, and it has not yet revealed attempts to exploit it.
Of course that does not mean it will never happen.
 
User avatar
glee
just joined
Posts: 5
Joined: Fri Aug 18, 2017 5:44 pm

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 3:29 pm

I would argue that releasing software that includes security fixes should be also released to all channels at same day since this will leave devices who are running on long-term channel exploitable.
The portion of devices running the latest long-term version and being actively managed by someone/some team who would install a security update in the current long-term channel immediately once it becomes available is likely very, very, very small.

Especially as there is no automatic update mechanism (with its associated security fix channel) in RouterOS, most devices are not regularly updated and many run versions that are very old and have really critical vulnerabilities (compared to this one).
People that elect to run the long-term version also usually are quite conservative in updating it.

Furthermore, you can fix this one with a firewall rule. I have done so early on, and it has not yet revealed attempts to exploit it.
Of course that does not mean it will never happen.
We are running long-term for customers and we are automatically updating the devices via Ansible with three phases (1day; 5days; 10days delay). Few of our partners are doing the same.
Yes I know we can fix this with firewall rule, we just finished testing our Ansible playbooks for phase1 clients - ~300 devices OK. Going to deploy it to phase2 and phase3 rings now.
 
seregaelcin
just joined
Posts: 3
Joined: Wed Jul 03, 2019 3:23 pm

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 3:34 pm

After update 6.44.3->6.45.1 pptp-client doesn't work - connecting.... disconnecting....connecting.... disconnecting....
After downgrade 6.45.1->6.44.3 it works
 
Ulypka
Frequent Visitor
Frequent Visitor
Posts: 52
Joined: Wed Jan 09, 2013 8:26 am

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 3:36 pm

2018101022007579 still present

2019.07.03-10:17:52.91@10: 2300: recalculate OSPFv2 routes
2019.07.03-10:17:53.73@10: repairDelete: done, deleted 0
2019.07.03-10:17:53.74@10: repairAdd: done, added 4060
2019.07.03-10:17:54.90@10: 2302: recalculate OSPFv2 routes
2019.07.03-10:25:41.17@3:
2019.07.03-10:25:41.17@3:
2019.07.03-10:25:41.17@3: /nova/bin/route
2019.07.03-10:25:41.17@3: --- signal=12 --------------------------------------------
2019.07.03-10:25:41.17@3:
2019.07.03-10:25:41.17@3: r00=0x000000007fbef774 r01=0x000000007fbef77c r02=0x000000007fbef77c
2019.07.03-10:25:41.17@3: r03=0x000000007fbef848 r04=0x00000000002aeca8 r05=0x00000000003b9940
2019.07.03-10:25:41.17@3: r06=0x0000000000000000 r07=0x0000000000000000 r08=0x0000000000000000
2019.07.03-10:25:41.17@3: r09=0x0000000000000000 r10=0x00000000003b9958 r11=0x00000000003b995c
2019.07.03-10:25:41.17@3: r12=0x000000000057f5f0 r13=0x0000000000000000 r14=0x000000000057f5e8
2019.07.03-10:25:41.17@3: r15=0x0000000000000001 r16=0x0000000000000001 r17=0x00000000002aedcc
2019.07.03-10:25:41.17@3: r18=0x0000000000000001 r19=0x0000000000000000 r20=0x00000000005979e8
2019.07.03-10:25:41.17@3: r21=0x00000000ffffffff r22=0x0000000008ff0003 r23=0x00000000005979d8
2019.07.03-10:25:41.17@3: r24=0x000000007fbef728 r25=0x000000007fbef728 r26=0x00000000000197a0
2019.07.03-10:25:41.17@3: r27=0x0000000000250128 r28=0x0000000077d5b5f0 r29=0x0000000000000100
2019.07.03-10:25:41.17@3: r30=0x000000007fbef780 r31=0x000000007fbef77c r32=0x000000007fbef774
2019.07.03-10:25:41.17@3: r33=0x000000007fbef83c r34=0x000000007fbef848 r35=0x00000000003b9950
2019.07.03-10:25:41.17@3: r36=0x000000007fbef844 r37=0x00000000003b9954 r38=0x00000000002aeca8
2019.07.03-10:25:41.17@3: r39=0x00000000003b9940 r40=0x00000000003c60d8 r41=0x00000000000000fe
2019.07.03-10:25:41.17@3: r42=0x00000000003b9958 r43=0x00000000ac1a1005 r44=0x0000000000000001
2019.07.03-10:25:41.17@3: r45=0x0000000000028948 r46=0x00000000000288c8 r47=0x0000000000000086
2019.07.03-10:25:41.17@3: r48=0x0000000077ae1444 r49=0x00000000000653e0 r50=0x0000000077e5cd70
2019.07.03-10:25:41.17@3: r51=0x0000000077ec2040 r52=0x000000007fbefd90 tp=0x0000000077f22fa0
2019.07.03-10:25:41.17@3: sp=0x000000007fbef760 lr=0x00000000001726b0 pc=0x0000000077d5b618
2019.07.03-10:25:41.17@3: ics=0x0000000000000000 faultnum=0x000000000000001d
2019.07.03-10:25:41.17@3:
2019.07.03-10:25:41.17@3: maps:
2019.07.03-10:25:41.17@3: 00010000-00250000 r-xp 00000000 00:0f 659 /nova/bin/route
2019.07.03-10:25:41.17@3: 77af0000-77b20000 r-xp 00000000 00:0f 468 /lib/libgcc_s.so.1
2019.07.03-10:25:41.17@3: 77b30000-77d30000 r-xp 00000000 00:0f 465 /lib/libc-2.17.so
2019.07.03-10:25:41.17@3: 77d50000-77d70000 r-xp 00000000 00:0f 448 /lib/libuc++.so
2019.07.03-10:25:41.17@3: 77d80000-77da0000 r-xp 00000000 00:0f 451 /lib/libucrypto.so
2019.07.03-10:25:41.17@3: 77db0000-77dc0000 r-xp 00000000 00:0f 453 /lib/libufiber.so
2019.07.03-10:25:41.17@3: 77dd0000-77de0000 r-xp 00000000 00:0f 467 /lib/libdl-2.17.so
2019.07.03-10:25:41.17@3: 77e00000-77e10000 r-xp 00000000 00:0f 454 /lib/libubox.so
2019.07.03-10:25:41.17@3: 77e20000-77ec0000 r-xp 00000000 00:0f 450 /lib/libumsg.so
2019.07.03-10:25:41.17@3: 77ed0000-77f10000 r-xp 00000000 00:0f 462 /lib/ld-2.17.so
2019.07.03-10:25:41.17@3:
2019.07.03-10:25:41.17@3: stack: 0x7fbf0000 - 0x7fbef760
2019.07.03-10:25:41.17@3: 98 26 17 00 00 00 00 00 20 f8 be 7f 00 00 00 00 44 14 ae 77 58 99 3b 00 58 99 3b 00 80 f7 be 7f
2019.07.03-10:25:41.17@3: 00 00 00 00 00 00 00 00 01 00 00 00 05 10 1a ac 05 10 1a ac 00 00 00 00 cc f8 be 7f 00 00 00 00
2019.07.03-10:25:41.17@3:
2019.07.03-10:25:41.17@3: backtrace: 0x77e53ce0 0x77b08e28 0x77d5b618 0x001726b0 0x00172fd0 0x77e5cee0 0x77e56968 0x77e5b3b8 0x77db8170 0x77e59fd0 0x77e51b10 0x77e51be0 0x77e5eda8 0x0001dca0 0x77b4aa40 0x000215a8
2019.07.03-10:25:41.17@3: extra 0x7fbef96c
2019.07.03-10:25:41.17@3: virtual void nv::Looper::dispatchMessage(nv::message&)
2019.07.03-10:25:41.17@3: Handler: 0x00000081
2019.07.03-10:25:41.17@3: true--- nv::message --------
2019.07.03-10:25:41.17@3: bool [local::1002]=true
2019.07.03-10:25:41.17@3: bool [SYS_REPLYEXP]=true
2019.07.03-10:25:41.17@3: u32 [SYS_POLICY]=-16385 0xffffbfff 255.191.255.255
2019.07.03-10:25:41.17@3: u32 [STD_FILTER]=5 0x5 5.0.0.0
2019.07.03-10:25:41.17@3: u32 [SYS_TYPE]=TYPE_REQUEST
2019.07.03-10:25:41.17@3: u32 [STD_GETALLID]=6162984 0x5e0a28 40.10.94.0
2019.07.03-10:25:41.17@3: u32 [SYS_REQID]=556 0x22c 44.2.0.0
2019.07.03-10:25:41.17@3: u32 [SYS_CMD]=CMD_GETALL
2019.07.03-10:25:41.17@3: message [STD_GETALL_COOKIE]...
2019.07.03-10:25:41.17@3: true --- nv::message --------
2019.07.03-10:25:41.17@3: u32 [3]=-1407578107 0xac1a1005 5.16.26.172
2019.07.03-10:25:41.17@3: u32 [STD_ID]=1 0x1 1.0.0.0
2019.07.03-10:25:41.17@3: u32 [1]=1 0x1 1.0.0.0
2019.07.03-10:25:41.17@3: u32 [2]=-1407578107 0xac1a1005 5.16.26.172
2019.07.03-10:25:41.17@3: u32 [14]=2824504 0x2b1938 56.25.43.0
2019.07.03-10:25:41.17@3: u32[0x00000000] [SYS_TO]=
2019.07.03-10:25:41.17@3: u32[0x00000002] [SYS_FROM]=0x00000030, 0x000000
 
seregaelcin
just joined
Posts: 3
Joined: Wed Jul 03, 2019 3:23 pm

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 5:05 pm

After update 6.44.3->6.45.1 pptp-client doesn't work - connecting.... disconnecting....connecting.... disconnecting....
After downgrade 6.45.1->6.44.3 it works
i created gre input firewall rule and replaced over fasstrack. pptp-client connected. Solved
 
User avatar
Panbambaryla
just joined
Posts: 7
Joined: Sat Jun 08, 2019 12:12 pm

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 5:20 pm

After update 6.44.3->6.45.1 pptp-client doesn't work - connecting.... disconnecting....connecting.... disconnecting....
After downgrade 6.45.1->6.44.3 it works
i created gre input firewall rule and replaced over fasstrack. pptp-client connected. Solved
No need to...
Just enable ip firewall service ports pptp NAT helper... It's been mentioned so many timees in here...
Best, Bam
 
maxsaf
Frequent Visitor
Frequent Visitor
Posts: 57
Joined: Tue Mar 06, 2018 8:47 pm

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 5:33 pm

The Dude - RouterOS checkmark doesn't work anymore. Error "invalid user name or password (6), next attempt at Jul/04 14:25:10"
 
User avatar
gepelbaum
just joined
Posts: 6
Joined: Sat Mar 18, 2017 8:58 am
Location: AR
Contact:

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 6:04 pm

My update report:
Dear, after updating the 6.44.3 version 6.45.1 experience that the name field of the ipsec tunnels was removed, this occurred in all devices where I had ipsec configured and in some had several tunnels configured.
For the rest, I did not see any problem although this if I present productivity problems in the clients.
regards
 
nmt1900
newbie
Posts: 27
Joined: Wed Feb 01, 2017 12:36 am

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 6:30 pm

It looks like SNMP access from Dude works OK with SNMPv1 or SNMPv2c. Maybe something with SNMPv3 authentication or encryption is wrong in Dude?
It looks like Dude has problems with SNMP access.

snmpwalk to other Mikrotik device causes this to appear in log of target device
10:22:24 snmp,debug unsupported v3 security level 
10:22:24 snmp,debug v3 err: 0 unsupported security
10:22:24 snmp,debug bad packet

and snmpwalk times out. We have LibreNMS set up for monitoring and it works fine as it did before.SNMP is set up as v3 private access.

Dude is updated to 6.45.1. It is hard to say whether Dude is the problem or RouterOS on the device itself...
I have that same problem
 
mserge
just joined
Posts: 9
Joined: Tue May 28, 2019 8:51 pm

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 6:40 pm

Winbox 3.19 has been released:

viewtopic.php?f=21&p=737780#p737780
I tried it but i still get same error "Wrong user or password", any ideas?
 
theplanet
just joined
Posts: 4
Joined: Sun Jul 06, 2014 8:27 pm

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 6:41 pm

There is a major problem with Hotspot + Radius + Mac Authentication... i have dmasoftlab radius and after the upgrade no client connected automatically... before the upgrade all working... and now no mac auth... I've found the problem, is is http pap , has to be disabled.
 
nostromog
Member Candidate
Member Candidate
Posts: 159
Joined: Wed Jul 18, 2018 3:39 pm

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 7:43 pm

I upgraded 2 mAP Lite without a single issue, and another old 750GL. Same

On the other side, the hAP ac that could not be upgraded/downgraded to 6.44.* or 6.45beta* because it had the 100% looping CPU on ipsec is stil behaving the same.

It hangs in some initial script that tries to modify ipsec policies depending on dynamic local ip, it hangs on "/ export" or "/ip ipsec <whatever>". I can't generate a supout because it hangs :(

Again, downgrading to long-term works, and it recovers a very simple and working, ipsec configuration:
/ip ipsec export hide-sensitive 
# jul/03/2019 18:35:52 by RouterOS 6.43.16
# software id = <edited>
#
# model = RouterBOARD 962UiGS-5HacT2HnT
# serial number = <edited>
/ip ipsec mode-config
add address-pool=vpn2 name=RW-cfg split-include=192.168.87.0/24,192.168.90.0/24,192.168.91.0/24
/ip ipsec policy group
add name=RoadWarrior
/ip ipsec peer
add auth-method=pre-shared-key-xauth generate-policy=port-strict mode-config=RW-cfg passive=yes policy-template-group=RoadWarrior
/ip ipsec policy
add dst-address=192.168.91.0/24 group=RoadWarrior src-address=192.168.87.0/24 template=yes
add dst-address=192.168.91.0/24 group=RoadWarrior src-address=192.168.90.0/24 template=yes
add dst-address=192.168.91.0/24 group=RoadWarrior src-address=192.168.91.0/24 template=yes
add disabled=yes dst-address=192.168.91.0/24 group=RoadWarrior src-address=0.0.0.0/0 template=yes
/ip ipsec user
add name=user2
add name=user
add name=user3
Deleting the ipsec configuration and upgrading loops the same. I'll keep it in long-term until either a stable version works or a long-term version works "past" the problem, or I can make netinstall work, which I have not been able for the moment...

There is another, remote office machine, that I'm scared to upgrade because I'm afraid that the issue will happen again and I can't easily recover the machine. It is quite critical and far away.

Is any of the other people that was experiencing with me this 100% CPU loop in ipsec in 6.44-6.45 been able to recover? How?
 
sindy
Forum Guru
Forum Guru
Posts: 3814
Joined: Mon Dec 04, 2017 9:19 pm

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 8:43 pm

It hangs in some initial script that tries to modify ipsec policies depending on dynamic local ip, it hangs on "/ export" or "/ip ipsec <whatever>". I can't generate a supout because it hangs :(
Have you tried to reset the machine to defaults before or better after upgrade to 6.45.1 and then manually create the IPsec configuration from the export rather than letting the upgrade script do that? This clearly cannot be used on the production machine but it should at least confirm that the IPsec part is the trigger, so you could be able to remove the IPsec configuration on the production machine before the upgrade if you can provide some other means to access it remotely (ssh, https) and recreate the IPsec part after the upgrade.

Other than that, a support.rif of the state before upgrade should be enough for support to simulate the same process at their end.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
owsugde
just joined
Posts: 20
Joined: Thu Oct 06, 2016 5:01 pm

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 9:52 pm

All I can say is be very careful with this update. I have rolled it out on some remote devices, and now, one isn't having ethernet connectivity at all (at the least) and the other isn't coming back up over OVPN.

Can't say more about what has caused this in particular, yet. Probably will have to be on premises tomorrow because of this, more on it then...
 
DotTest37
Frequent Visitor
Frequent Visitor
Posts: 52
Joined: Sun Oct 06, 2013 10:01 pm

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 10:33 pm

What does exactly mean:
!) user - removed insecure password storage;
?
 
pe1chl
Forum Guru
Forum Guru
Posts: 5833
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 10:37 pm

What does exactly mean:
!) user - removed insecure password storage;
?
It is already written in the head of the release notes!
In older RouterOS versions before 6.43 the passwords were stored in plaintext.
In the 6.43 version they were changed to hashes but the plaintext version remained so you could downgrade and still have your passwords.
Now the plaintext versions are deleted, so when you downgrade from 6.45.1 to a 6.42 or older version you lose all your passwords.
 
dlausch
just joined
Posts: 11
Joined: Thu Jan 05, 2017 1:43 pm
Location: Uelzen, Germany

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 10:54 pm

i have found the failure.
connecting with the android app over vpn (i am not at home) is fine.
connecting with winbox from my windows laptop over vpn is fone too.

only winbox running with wine on my macbook shows this failure
and after deleting the cache in winbox it connects again on my macbook
I've got a similar issue...

I'm unable to connect my Router / APs etc by IOS app, no matter if VPN or WLAN.
The logs say: "system,error,critical login failure for user david from 10.200.5.13 via tikapp"

Via Winbox, SSH or Web no problems.
So I had to turn of the network for my Kids by ssh, not by app...

Greetz
David
Security is just a appearance....
 
CharlyBrown
just joined
Posts: 6
Joined: Tue Jul 17, 2018 7:12 pm

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 11:08 pm

Hi Guys, I recently updated 2 of my routers, one of them has Dude installed, and when I try to login through API, I receive the same error.
The las version installed on my routers are 6.44, and the API login style is the one indicated on the wiki.
Other strange thing, when I try to use AUTO UPGRADE option from other routers I receive the same error. (wrong password). The configured server with update packages are the router with DUDE, with 6.51 version.-
I try to reset de admin password, api password and nothing happened.
When I try to connect through API and AUTO UPGRADE option between routers with 6.44 version, everything works fine.
If need more information about those tests please tell me.
me to, but i have problem on api, i can connect with winbox, but i can't login with API ( wrong password ). why?
Do you use new login style in API?
https://wiki.mikrotik.com/wiki/Manual:API#Initial_login
 
DotTest37
Frequent Visitor
Frequent Visitor
Posts: 52
Joined: Sun Oct 06, 2013 10:01 pm

Re: v6.45.1 [stable] is released!

Wed Jul 03, 2019 11:12 pm

What does exactly mean:
!) user - removed insecure password storage;
?
It is already written in the head of the release notes!
In older RouterOS versions before 6.43 the passwords were stored in plaintext.
In the 6.43 version they were changed to hashes but the plaintext version remained so you could downgrade and still have your passwords.
Now the plaintext versions are deleted, so when you downgrade from 6.45.1 to a 6.42 or older version you lose all your passwords.
Which passwords?
The one used to log in on Router OS?
The ones for PPP accounts?
Anything else?
Which ones?
Are we talking also the password visibility when you do EXPORT on the CLI? (you see all passwords there)
 
salah
just joined
Posts: 7
Joined: Sun Jan 10, 2016 12:09 am

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 1:51 am

can anyone help me to enable this future (dot1x) on my LAN network

I have a tp-link access point with WPA/WPA2 enterprise authentication.
 
faraujo88
just joined
Posts: 13
Joined: Fri Feb 15, 2019 2:28 am

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 2:31 am

Hi Guys

I am having problem to update my device,

it complete and reboot , but when i go to check the currentversion, is still 6.42 and not 6.45

Please Help
Can U send log? did u check correct architecture?
 
faraujo88
just joined
Posts: 13
Joined: Fri Feb 15, 2019 2:28 am

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 2:32 am

What does exactly mean:
!) user - removed insecure password storage;
?
It is already written in the head of the release notes!
In older RouterOS versions before 6.43 the passwords were stored in plaintext.
In the 6.43 version they were changed to hashes but the plaintext version remained so you could downgrade and still have your passwords.
Now the plaintext versions are deleted, so when you downgrade from 6.45.1 to a 6.42 or older version you lose all your passwords.
Which passwords?
The one used to log in on Router OS?
The ones for PPP accounts?
Anything else?
Which ones?
Are we talking also the password visibility when you do EXPORT on the CLI? (you see all passwords there)
I guess it refears to Management users.
 
User avatar
winet
Member Candidate
Member Candidate
Posts: 272
Joined: Fri Mar 16, 2007 4:49 pm
Location: Indonesia

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 5:59 am

i think, v6.45.1 still have security hole. this happened last night. it's v6.45.1, and had already created new user credential on it, removed the old one. and somehow, the router made a vpn interface with the old deleted user login.
You do not have the required permissions to view the files attached to this post.
Last edited by winet on Thu Jul 04, 2019 6:21 am, edited 1 time in total.
 
xtrans
just joined
Posts: 9
Joined: Fri Feb 15, 2019 3:44 pm

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 6:19 am

This version is not automatically show captive portal on hotspot
I downgrade to 6.44.3 and fix.
 
User avatar
winet
Member Candidate
Member Candidate
Posts: 272
Joined: Fri Mar 16, 2007 4:49 pm
Location: Indonesia

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 6:35 am

ah got it, there is something on the system scheduler
You do not have the required permissions to view the files attached to this post.
 
User avatar
strods
MikroTik Support
MikroTik Support
Posts: 1407
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 7:05 am

joserudi - Please send supout file to support@mikrotik.com. Generate file while the problem is present and name at least single user which does not get rate-limit;
LeftyTs, Ulypka, gepelbaum, nostromog, CharlyBrown, xtrans - Please send supout file to support@mikrotik.com. Generate file while the problem is present;
mserge - Make sure that you use Winbox 3.19. If the problem persists, then generate a new supout file on your router after failed Winbox login attempt and send it to support@mikrotik.com;
owsugde - Is it possible that you are using a certificate verification feature which was introduced in this release? "ovpn - added "verify-server-certificate" parameter for OVPN client (CVE-2018-10066)"
dlausch - Sound like you have the same problem as we did with Winbox. Also new iOS MikroTik mobile application update will be released very soon;

Everyone - Everyone who is experiencing RADIUS related problems with authentication since v6.45, we will soon release 6.46beta version with potential fix for the problem;
Everyone - Long-term version will be released as soon as possible. There is no ETA since everyone will want version as stable as possible. We can not simply name date and time when the version will be released. It depends on test results.
 
xtrans
just joined
Posts: 9
Joined: Fri Feb 15, 2019 3:44 pm

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 7:32 am

Requesting for /ip hotspot active Session time left to be editable.
 
bubniakz
just joined
Posts: 1
Joined: Thu Jul 04, 2019 7:47 am

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 7:49 am

we use CRM, ISPadmin, which communicates with MKT by API, but when updating to 6.45.1
API doesnt work, because new API authentification is not implement in our CRM. It says
"killing PID 25009, API number exceeds the limit", but when downgrade to 6.44.3, which
worked with CRM prior and should have compatibility with old API authentification, it
doesnt work anymore and still have API error.

Log in MKT: "login failure via API"

thanks for help
 
buset1974
Frequent Visitor
Frequent Visitor
Posts: 50
Joined: Wed Sep 13, 2006 12:12 pm
Location: Jakarta

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 8:30 am

joserudi - Please send supout file to support@mikrotik.com. Generate file while the problem is present and name at least single user which does not get rate-limit;
LeftyTs, Ulypka, gepelbaum, nostromog, CharlyBrown, xtrans - Please send supout file to support@mikrotik.com. Generate file while the problem is present;
mserge - Make sure that you use Winbox 3.19. If the problem persists, then generate a new supout file on your router after failed Winbox login attempt and send it to support@mikrotik.com;
owsugde - Is it possible that you are using a certificate verification feature which was introduced in this release? "ovpn - added "verify-server-certificate" parameter for OVPN client (CVE-2018-10066)"
dlausch - Sound like you have the same problem as we did with Winbox. Also new iOS MikroTik mobile application update will be released very soon;

Everyone - Everyone who is experiencing RADIUS related problems with authentication since v6.45, we will soon release 6.46beta version with potential fix for the problem;
Everyone - Long-term version will be released as soon as possible. There is no ETA since everyone will want version as stable as possible. We can not simply name date and time when the version will be released. It depends on test results.
CCR1036-8G-2S+ , having random reboot by watchdog after upgrade to 6.45.1.
I have sent the supout file

thx
 
tesme33
newbie
Posts: 48
Joined: Mon May 26, 2014 10:25 pm

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 8:42 am

Hi
im attaching the config. There is nothing fancy in. But once the package is downloaded only 60KiB are left on the flash.
And this is just not enough. Now i need to figure out how to upgrade ind. packages step by step. Never did this before.

In between i was upgrading a CCR1009. Works. But also no fancy config. Just routing,dhcp and firewall.


Hi
upgraded crs326 and one hap lite without issues : 6.43.3 --> 6.45.1
one hap lite wont upgrade. I suspect space problem, but there are no files on the system.

It's the oroblem with free memory. Devices with small flash (less than 64MB) download upgrade packages to RAM ... and for that some 12MB RAM should be free. Free RAM on your hAP lite is quite low ... do you have some large address list?
You do not have the required permissions to view the files attached to this post.
 
User avatar
arsalansiddiqui
just joined
Posts: 16
Joined: Mon Aug 14, 2017 1:03 pm
Location: Karachi, Pakistan
Contact:

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 8:56 am

Hi, i have upgraded my two RB750 to v6.45.1 and they are not let me access through api, and my 6.43.8, 6.44.3 is connecting to api normally, i'm using default port and i'm accessing in php.
Before upgrading i can connect both tiks with api.
Thanks
 
User avatar
kanitelka
just joined
Posts: 2
Joined: Wed Oct 03, 2018 11:21 am
Location: Moscow, Russia

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 9:14 am

After update 6.44.3->6.45.1 pptp-client doesn't work - connecting.... disconnecting....connecting.... disconnecting....
After downgrade 6.45.1->6.44.3 it works
i created gre input firewall rule and replaced over fasstrack. pptp-client connected. Solved
The problem is only with PPTP?
 
Reinis
MikroTik Support
MikroTik Support
Posts: 57
Joined: Wed Jan 02, 2019 12:14 pm
Location: Latvia
Contact:

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 9:15 am

Hi, i have upgraded my two RB750 to v6.45.1 and they are not let me access through api, and my 6.43.8, 6.44.3 is connecting to api normally, i'm using default port and i'm accessing in php.
Before upgrading i can connect both tiks with api.
Thanks
https://wiki.mikrotik.com/wiki/Manual:API#Initial_login
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8310
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 10:35 am

but when downgrade to 6.44.3, which
worked with CRM prior and should have compatibility with old API authentification, it
doesnt work anymore and still have API error.

Log in MKT: "login failure via API"

thanks for help
When you upgraded to 6.45, plaintext passwords were removed. That's why you cannot use old login method on that router. You may try to recreate/reset password for API user on 6.44
Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

For every complex problem, there is a solution that is simple, neat, and wrong.

MikroTik. Your life. Your routing.
 
mangust479
just joined
Posts: 4
Joined: Sun Jan 28, 2018 11:44 pm

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 11:08 am

I updated 37 routers of different models, at all the error is observed: one core of CPU is loaded for 100% by process of routing, OSPF falls off when you come into the OSPF settings that there in general there is nothing. There is information when it is able to be corrected? I wrote to support already.
 
User avatar
le1
just joined
Posts: 9
Joined: Sat Sep 15, 2018 8:56 pm
Location: Georgia, Tbilisi
Contact:

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 11:32 am

Hello, I have problem with radius server authentication :(
hotspot,info,debug {MAC Address} (192.168.88.18): login failed: RADIUS server is not responding
hotspot,info,debug {MAC Address} (192.168.88.18): trying to log in by http-pap
 
User avatar
arsalansiddiqui
just joined
Posts: 16
Joined: Mon Aug 14, 2017 1:03 pm
Location: Karachi, Pakistan
Contact:

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 12:34 pm

Hi, i have upgraded my two RB750 to v6.45.1 and they are not let me access through api, and my 6.43.8, 6.44.3 is connecting to api normally, i'm using default port and i'm accessing in php.
Before upgrading i can connect both tiks with api.
Thanks
https://wiki.mikrotik.com/wiki/Manual:API#Initial_login
i did not understand it, what changes should i do to login ?
$API->connect($ip_address, $api_username, $api_password, $port );
 
User avatar
arsalansiddiqui
just joined
Posts: 16
Joined: Mon Aug 14, 2017 1:03 pm
Location: Karachi, Pakistan
Contact:

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 12:44 pm

me to, but i have problem on api, i can connect with winbox, but i can't login with API ( wrong password ). why?
Do you use new login style in API?
https://wiki.mikrotik.com/wiki/Manual:API#Initial_login
I use CHR
Have you figure it out ?
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 5934
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 1:02 pm

@arsalansiddiqui you need to fix your API wrapper so that login parameters are sent as described in the wiki.
Here is another topic
viewtopic.php?f=9&t=136475
 
User avatar
arsalansiddiqui
just joined
Posts: 16
Joined: Mon Aug 14, 2017 1:03 pm
Location: Karachi, Pakistan
Contact:

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 1:22 pm

@arsalansiddiqui you need to fix your API wrapper so that login parameters are sent as described in the wiki.
Here is another topic
viewtopic.php?f=9&t=136475
I got it :)
 
tdw
Member Candidate
Member Candidate
Posts: 194
Joined: Sat May 05, 2018 11:55 am

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 1:35 pm

we use CRM, ISPadmin, which communicates with MKT by API, but when updating to 6.45.1
API doesnt work, because new API authentification is not implement in our CRM. It says
"killing PID 25009, API number exceeds the limit", but when downgrade to 6.44.3, which
worked with CRM prior and should have compatibility with old API authentification, it
doesnt work anymore and still have API error.

Log in MKT: "login failure via API"

thanks for help

@bubniakz As stated in the release notes, and as noted here https://ispadmin.eu/en/mikrotik-api-in- ... t-working/

As 6.45.x erases passwords stored with the 'old' method of reversible encryption, after downgrading you will also have to recreate the password or restore from backup.

When upgrading firmware:
6.42.12 and prior: old method only -> 6.43.x & 6.44.x: old & new methods -> 6.45.x and later: new method only
When downgrading firmware:
6.45.x and later: new method only -> 6.43.x & 6.44.x: new method -> 6.42.12 and prior: no passwords
 
TDodger
just joined
Posts: 1
Joined: Wed Jul 03, 2019 4:55 pm

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 1:57 pm

I've read the thread, I seem to be the only one having problems with WebFig...
Upgraded from 6.44.3 to 6.45.1
WinBox worked/works fine, both 3.18 and 3.19
But when I use WebFig, it works only over http Port 80, not via https Port 443 which I normally use.
It says: ERROR: Not Found
But same user/password works via WinBox and http.
So I guess maybe a problem with my (self created) certificate? I didn't change anything in the config after upgrading to 6.45.1
 
User avatar
nichky
Long time Member
Long time Member
Posts: 526
Joined: Tue Jun 23, 2015 2:35 pm

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 1:57 pm

*) dhcpv4-server - added "client-mac-limit" parameter;

which number over here goes?
Last edited by nichky on Thu Jul 04, 2019 2:28 pm, edited 1 time in total.
Nikola Suminoski
MikroTik Consultan
MTCRE l MTCWE

!) Safe Mode is your friend;
 
owsugde
just joined
Posts: 20
Joined: Thu Oct 06, 2016 5:01 pm

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 2:06 pm

owsugde - Is it possible that you are using a certificate verification feature which was introduced in this release? "ovpn - added "verify-server-certificate" parameter for OVPN client (CVE-2018-10066)"
I don't think this is it, because a cold reboot done by the customer "fixed" it. At this time I don't know what it could have been really. For now, I went to longterm anyway, because RADIUS hotspot login by http-pap was disabled on stable somehow and we're using this.
 
Elans
MikroTik Support
MikroTik Support
Posts: 55
Joined: Wed Apr 18, 2018 12:41 pm

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 2:52 pm

It looks like Dude has problems with SNMP access.

snmpwalk to other Mikrotik device causes this to appear in log of target device
10:22:24 snmp,debug unsupported v3 security level 
10:22:24 snmp,debug v3 err: 0 unsupported security
10:22:24 snmp,debug bad packet

and snmpwalk times out. We have LibreNMS set up for monitoring and it works fine as it did before.SNMP is set up as v3 private access.

Dude is updated to 6.45.1. It is hard to say whether Dude is the problem or RouterOS on the device itself...
spacex
nmt1900
Make sure that your monitored device "IP-SNMP communities" and The Dude "server settings" SNMP custom profile does not have any mismatch.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5833
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 3:01 pm

we use CRM, ISPadmin, which communicates with MKT by API, but when updating to 6.45.1
API doesnt work, because new API authentification is not implement in our CRM.
You should ask the creator of that software for an update, or investigate how it works and update it yourself.
(e.g. when it uses the wellknown PHP API you can update just that file)
 
nmt1900
newbie
Posts: 27
Joined: Wed Feb 01, 2017 12:36 am

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 3:25 pm

spacex
nmt1900
Make sure that your monitored device "IP-SNMP communities" and The Dude "server settings" SNMP custom profile does not have any mismatch.
There is no mismatch and these community settings have been used for long time. Only Dude fails and it worked fine with 6.44.3. After testing it looks like only way to get it work with Dude is to use SNMPv2c or SNMPv1.
 
Ulypka
Frequent Visitor
Frequent Visitor
Posts: 52
Joined: Wed Jan 09, 2013 8:26 am

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 3:38 pm

joserudi - Please send supout file to support@mikrotik.com. Generate file while the problem is present and name at least single user which does not get rate-limit;
LeftyTs, Ulypka, gepelbaum, nostromog, CharlyBrown, xtrans - Please send supout file to support@mikrotik.com. Generate file while the problem is present;
mserge - Make sure that you use Winbox 3.19. If the problem persists, then generate a new supout file on your router after failed Winbox login attempt and send it to support@mikrotik.com;
owsugde - Is it possible that you are using a certificate verification feature which was introduced in this release? "ovpn - added "verify-server-certificate" parameter for OVPN client (CVE-2018-10066)"
dlausch - Sound like you have the same problem as we did with Winbox. Also new iOS MikroTik mobile application update will be released very soon;

Everyone - Everyone who is experiencing RADIUS related problems with authentication since v6.45, we will soon release 6.46beta version with potential fix for the problem;
Everyone - Long-term version will be released as soon as possible. There is no ETA since everyone will want version as stable as possible. We can not simply name date and time when the version will be released. It depends on test results.
It is exist Ticket:
[Ticket#2018101022007579]
 
fdk
just joined
Posts: 1
Joined: Thu Jul 04, 2019 5:15 pm

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 5:25 pm

Hi,

After upgrading to stable version, I lost access via my users' users even by reconfiguring the passwords. the pppoe server also stopped interpreting the maximum time set by the uptime AAA for the connections. I was forced to go back to version 4.43.16 which normalized.
 
llag
newbie
Posts: 31
Joined: Sat Aug 04, 2018 12:12 am

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 5:51 pm

yesterday I upgrade the CRS317 and the CRS328 POE. Since the upgrade I have seen 70 flaps of the link between the 2. See also viewtopic.php?f=2&t=141633&p=738127&hil ... 3d#p738127
I used to see the link flap once a day or every few days on 6.44
Mikrotik, what is happening here?
 
User avatar
machack
newbie
Posts: 47
Joined: Fri Jun 01, 2007 9:35 pm
Location: San Luis Argentina
Contact:

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 6:41 pm

RouterOS version 6.45.1 has been released in public "stable" channel!

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 new in 6.45.1 (2019-Jun-27 10:23):

Important note!!!
Due to removal of compatibility with old version passwords in this version, downgrading to any version prior to v6.43 (v6.42.12 and older) will clear all user passwords and allow password-less authentication. Please secure your router after downgrading.
Old API authentication method will also no longer work, see documentation for new login procedure:
https://wiki.mikrotik.com/wiki/Manual:API#Initial_login


MAJOR CHANGES IN v6.45.1:
----------------------
!) dot1x - added support for IEEE 802.1X Port-Based Network Access Control;
!) ike2 - added support for EAP authentication methods (eap-tls, eap-ttls, eap-peap, eap-mschapv2) as initiator;
!) security - fixed vulnerabilities CVE-2018-1157, CVE-2018-1158;
!) security - fixed vulnerabilities CVE-2019-11477, CVE-2019-11478, CVE-2019-11479;
!) security - fixed vulnerability CVE-2019-13074;
!) user - removed insecure password storage;
----------------------

Changes in this release:

*) bridge - correctly display bridge FastPath status when vlan-filtering or dhcp-snooping is used;
*) bridge - correctly handle bridge host table;
*) bridge - fixed log message when hardware offloading is being enabled;
*) bridge - improved stability when receiving traffic over USB modem with bridge firewall enabled;
*) capsman - fixed CAP system upgrading process for MMIPS;
*) capsman - fixed interface-list usage in access list;
*) ccr - improved packet processing after overloading interface;
*) certificate - added "key-type" field;
*) certificate - added support for ECDSA certificates (prime256v1, secp384r1, secp521r1);
*) certificate - fixed self signed CA certificate handling by SCEP client;
*) certificate - made RAM the default CRL storage location;
*) certificate - removed DSA (D) flag;
*) certificate - removed "set-ca-passphrase" parameter;
*) chr - legacy adapters require "disable-running-check=yes" to be set;
*) cloud - added "replace" parameter for backup "upload-file" command;
*) conntrack - fixed GRE protocol packet connection-state matching (CVE-2014-8160);
*) conntrack - significant stability and performance improvements;
*) crs317 - fixed known multicast flooding to the CPU;
*) crs3xx - added ethernet tx-drop counter;
*) crs3xx - correctly display auto-negotiation information for SFP/SFP+ interfaces in 1Gbps rate;
*) crs3xx - fixed auto negotiation when 2-pair twisted cable is used (downshift feature);
*) crs3xx - fixed "tx-drop" counter;
*) crs3xx - improved switch-chip resource allocation on CRS326, CRS328, CRS305;
*) defconf - added "custom-script" field that prints custom configuration installed by Netinstall;
*) defconf - automatically set "installation" parameter for outdoor devices;
*) defconf - changed default configuration type to AP for cAP series devices;
*) defconf - fixed channel width selection for RU locked devices;
*) dhcp - create dual stack queue based on limitations specified on DHCPv4 server lease configuration;
*) dhcp - do not require lease and binding to have the same configuration for dual-stack queues;
*) dhcp - show warning in log if lease and binding dual-stack related parameters do not match and create separate queues;
*) dhcpv4-server - added "client-mac-limit" parameter;
*) dhcpv4-server - added IP conflict logging;
*) dhcpv4-server - added RADIUS accounting support with queue based statistics;
*) dhcpv4-server - added "vendor-class-id" matcher (CLI only);
*) dhcpv4-server - improved stability when performing "check-status" command;
*) dhcpv4-server - replaced "busy" lease status with "conflict" and "declined";
*) dhcpv6-client - added option to disable rapid-commit;
*) dhcpv6-client - fixed status update when leaving "bound" state;
*) dhcpv6-server - added additional RADIUS parameters for Prefix delegation, "rate-limit" and "life-time";
*) dhcpv6-server - added "address-list" support for bindings;
*) dhcpv6-server - added "insert-queue-before" and "parent-queue" parameters;
*) dhcpv6-server - added RADIUS accounting support with queue based statistics;
*) dhcpv6-server - added "route-distance" parameter;
*) dhcpv6-server - fixed dynamic IPv6 binding without proper reference to the server;
*) dhcpv6-server - override prefix pool and/or DNS server settings by values received from RADIUS;
*) discovery - correctly create neighbors from VLAN tagged discovery messages;
*) discovery - fixed CDP packets not including address on slave ports (introduced in v6.44);
*) discovery - improved neighbour's MAC address detection;
*) discovery - limit max neighbour count per interface based on total RAM memory;
*) discovery - show neighbors on actual mesh ports;
*) e-mail - include "message-id" identification field in e-mail header;
*) e-mail - properly release e-mail sending session if the server's domain name can not be resolved;
*) ethernet - added support for 25Gbps and 40Gbps rates;
*) ethernet - fixed running (R) flag not present on x86 interfaces and CHR legacy adapters;
*) ethernet - increased loop warning threshold to 5 packets per second;
*) fetch - added SFTP support;
*) fetch - improved user policy lookup;
*) firewall - fixed fragmented packet processing when only RAW firewall is configured;
*) firewall - process packets by firewall when accepted by RAW with disabled connection tracking;
*) gps - fixed missing minus close to zero coordinates in dd format;
*) gps - make sure "direction" parameter is upper case;
*) gps - strip unnecessary trailing characters from "longtitude" and "latitude" values;
*) gps - use "serial0" as default port on LtAP mini;
*) hotspot - added "interface-mac" variable to HTML pages;
*) hotspot - moved "title" HTML tag after "meta" tags;
*) ike1 - adjusted debug packet logging topics;
*) ike2 - added support for ECDSA certificate authentication (rfc4754);
*) ike2 - added support for IKE SA rekeying for initiator;
*) ike2 - do not send "User-Name" attribute to RADIUS server if not provided;
*) ike2 - improved certificate verification when multiple CA certificates received from responder;
*) ike2 - improved child SA rekeying process;
*) ike2 - improved XAuth identity conversion on upgrade;
*) ike2 - prefer SAN instead of DN from certificate for ID payload;
*) ippool - improved logging for IPv6 Pool when prefix is already in use;
*) ipsec - added dynamic comment field for "active-peers" menu inherited from identity;
*) ipsec - added "ph2-total" counter to "active-peers" menu;
*) ipsec - added support for RADIUS accounting for "eap-radius" and "pre-shared-key-xauth" authentication methods;
*) ipsec - added traffic statistics to "active-peers" menu;
*) ipsec - disallow setting "src-address" and "dst-address" for transport mode policies;
*) ipsec - do not allow adding identity to a dynamic peer;
*) ipsec - fixed policies becoming invalid after changing priority;
*) ipsec - general improvements in policy handling;
*) ipsec - properly drop already established tunnel when address change detected;
*) ipsec - renamed "remote-peers" to "active-peers";
*) ipsec - renamed "rsa-signature" authentication method to "digital-signature";
*) ipsec - replaced policy SA address parameters with peer setting;
*) ipsec - use tunnel name for dynamic IPsec peer name;
*) ipv6 - improved system stability when receiving bogus packets;
*) ltap - renamed SIM slots "up" and "down" to "2" and "3";
*) lte - added initial support for Vodafone R216-Z;
*) lte - added passthrough interface subnet selection;
*) lte - added support for manual operator selection;
*) lte - allow setting empty APN;
*) lte - allow to specify URL for firmware upgrade "firmware-file" parameter;
*) lte - do not show error message for info commands that are not supported;
*) lte - fixed session reactivation on R11e-LTE in UMTS mode;
*) lte - improved firmware upgrade process;
*) lte - improved "info" command query;
*) lte - improved R11e-4G modem operation;
*) lte - renamed firmware upgrade "path" command to "firmware-file" (CLI only);
*) lte - show alphanumeric value for operator info;
*) lte - show correct firmware revision after firmware upgrade;
*) lte - use default APN name "internet" when not provided;
*) lte - use secondary DNS for DNS server configuration;
*) m33g - added support for additional Serial Console port on GPIO headers;
*) ospf - added support for link scope opaque LSAs (Type 9) for OSPFv2;
*) ospf - fixed opaque LSA type checking in OSPFv2;
*) ospf - improved "unknown" LSA handling in OSPFv3;
*) ovpn - added "verify-server-certificate" parameter for OVPN client (CVE-2018-10066);
*) ppp - added initial support for Quectel BG96;
*) proxy - increased minimal free RAM that can not be used for proxy services;
*) rb3011 - improved system stability when receiving bogus packets;
*) rb4011 - fixed MAC address duplication between sfp-sfpplus1 and wlan1 interfaces (wlan1 configuration reset required);
*) rb921 - improved system stability ("/system routerboard upgrade" required);
*) routerboard - renamed 'sim' menu to 'modem';
*) sfp - fixed S-35LC20D transceiver DDMI readouts after reboot;
*) sms - added USSD message functionality under "/tool sms" (CLI only);
*) sms - allow specifying multiple "allowed-number" values;
*) sms - improved delivery report logging;
*) snmp - added "dot1dStpPortTable" OID;
*) snmp - added OID for neighbor "interface";
*) snmp - added "write-access" column to community print;
*) snmp - allow setting interface "adminStatus";
*) snmp - fixed "send-trap" not working when "trap-generators" does not contain "temp-exception";
*) snmp - fixed "send-trap" with multiple "trap-targets";
*) snmp - improved reliability on SNMP service packet validation;
*) snmp - properly return multicast and broadcast packet counters for IF-MIB OIDs;
*) ssh - accept remote forwarding requests with empty hostnames;
*) ssh - added new "ssh-exec" command for non-interactive command execution;
*) ssh - fixed non-interactive multiple command execution;
*) ssh - improved remote forwarding handling (introduced in v6.44.3);
*) ssh - improved session rekeying process on exchanged data size threshold;
*) ssh - keep host keys when resetting configuration with "keep-users=yes";
*) ssh - use correct user when "output-to-file" parameter is used;
*) sstp - improved stability when received traffic hits tarpit firewall;
*) supout - added IPv6 ND section to supout file;
*) supout - added "kid-control devices" section to supout file;
*) supout - added "pwr-line" section to supout file;
*) supout - changed IPv6 pool section to output detailed print;
*) switch - properly reapply settings after switch chip reset;
*) tftp - added "max-block-size" parameter under TFTP "settings" menu (CLI only);
*) tile - improved link fault detection on SFP+ ports;
*) tr069-client - added LTE CQI and IMSI parameter support;
*) tr069-client - fixed potential memory corruption;
*) tr069-client - improved error reporting with incorrect firware upgrade XML file;
*) traceroute - improved stability when sending large ping amounts;
*) traffic-generator - improved stability when stopping traffic generator;
*) tunnel - removed "local-address" requirement when "ipsec-secret" is used;
*) userman - added support for "Delegated-IPv6-Pool" and "DNS-Server-IPv6-Address" (CLI only);
*) w60g - do not show unused "dmg" parameter;
*) w60g - prefer AP with strongest signal when multiple APs with same SSID present;
*) w60g - show running frequency under "monitor" command;
*) winbox - added "System/SwOS" menu for all dual-boot devices;
*) winbox - do not allow setting "dns-lookup-interval" to "0";
*) winbox - show "LCD" menu only on boards that have LCD screen;
*) wireless - fixed frequency duplication in the frequency selection menu;
*) wireless - fixed incorrect IP header for RADIUS accounting packet;
*) wireless - improved 160MHz channel width stability on rb4011;
*) wireless - improved DFS radar detection when using non-ETSI regulated country;
*) wireless - improved installation mode selection for wireless outdoor equipment;
*) wireless - set default SSID and supplicant-identity the same as router's identity;
*) wireless - updated "china" regulatory domain information;
*) wireless - updated "new zealand" regulatory domain information;
*) www - improved client-initiated renegotiation within the SSL and TLS protocols (CVE-2011-1473);

What's new in 6.45 (2019-Jun-21 09:00):

(factory only release)

What's new in 6.44.4 (2019-May-09 12:14):

(factory only release)

To upgrade, click "Check for updates" at /system package in your RouterOS configuration interface, or head to our download page: http://www.mikrotik.com/download

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 some problem has appeared on device

Please keep this forum topic strictly related to this particular RouterOS release.
After Upgrade 6.45.1.... My DHCP server dosent work anymore.. use radius to validate.... roolback...
Cesar Javier Robles
www.WindNet.com.ar
MTCNA - MTCTCE - MTCRE - MTCWE
 
maxsaf
Frequent Visitor
Frequent Visitor
Posts: 57
Joined: Tue Mar 06, 2018 8:47 pm

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 7:10 pm

On my CRS317-1G-16S+ i see in log "timeout while waiting for program 16" and "timeout while waiting for program 20".
Also errors "login failure for user admin from (Dude IP) via dude"
 
seregaelcin
just joined
Posts: 3
Joined: Wed Jul 03, 2019 3:23 pm

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 8:49 pm

No need to...
Just enable ip firewall service ports pptp NAT helper... It's been mentioned so many timees in here...


Thank, i didn't know
 
User avatar
petrb
Frequent Visitor
Frequent Visitor
Posts: 96
Joined: Thu Jan 26, 2017 4:17 pm

Re: v6.45.1 [stable] is released!

Thu Jul 04, 2019 9:34 pm

After Upgrade 6.45.1.... My DHCP server dosent work anymore.. use radius to validate.... roolback...
Fix in 6.46beta
Did you read manual? .... What? .... Read the manual.
 
chubbs596
Frequent Visitor
Frequent Visitor
Posts: 51
Joined: Fri Dec 06, 2013 6:07 pm

Re: v6.45.1 [stable] is released!

Fri Jul 05, 2019 7:49 am

Hi Mikrotik support

I have also send a support email for this.

We make use of the Auto upgrade feature we have the necesary upgrade files hosted on a central router with a user upgrade added for the Auto upgrade purpose
We add the below on all client routers, and with scripts and schedulers we daily check for upgrades,

This way we can choose when to upgrade our routers by just uploading new files to the central router and the next shcheduled run all routers shecduled will upgrade

/system upgrade upgrade-package-source
add address=x.x.x.x user=upgrade

Now since 6.45.1 we get authentication issues. we get below in the logs

06:05:36 system,error,critical login failure for user upgrade from x.x.x.x via winbox
06:05:36 system,error,critical login failure for user upgrade from x.x.x.x via winbox

Before we were running 6.44.3 with no issues we got below in the logs

02:00:00 system,info,account user upgrade logged in from x.x.x.x via winbox
02:00:00 system,info,account user upgrade logged in from x.x.x.x via winbox
 
User avatar
le1
just joined
Posts: 9
Joined: Sat Sep 15, 2018 8:56 pm
Location: Georgia, Tbilisi
Contact:

Re: v6.45.1 [stable] is released!

Fri Jul 05, 2019 7:57 am

Hello, I have problem with radius server authentication :(
hotspot,info,debug {MAC Address} (192.168.88.18): login failed: RADIUS server is not responding
hotspot,info,debug {MAC Address} (192.168.88.18): trying to log in by http-pap
When will you fix this problem?
 
User avatar
emils
MikroTik Support
MikroTik Support
Topic Author
Posts: 495
Joined: Thu Dec 11, 2014 8:53 am

Re: v6.45.1 [stable] is released!

Fri Jul 05, 2019 8:27 am

RADIUS authentication issue is already fixed in the latest beta. We will try to release a new stable version next week with a few fixes.
 
Elans
MikroTik Support
MikroTik Support
Posts: 55
Joined: Wed Apr 18, 2018 12:41 pm

Re: v6.45.1 [stable] is released!

Fri Jul 05, 2019 8:42 am

spacex
nmt1900
Make sure that your monitored device "IP-SNMP communities" and The Dude "server settings" SNMP custom profile does not have any mismatch.
There is no mismatch and these community settings have been used for long time. Only Dude fails and it worked fine with 6.44.3. After testing it looks like only way to get it work with Dude is to use SNMPv2c or SNMPv1.
Can not reproduce your described problem, only with mismatched configuration. Have you tried to create new SNMP profile in The Dude and/or IP-SNMP communities? There must be something specific, if problem persist, you may try to send your supout.rif file to support@mikrotik.com.
 
User avatar
skylark
MikroTik Support
MikroTik Support
Posts: 106
Joined: Wed Feb 10, 2016 3:55 pm

Re: v6.45.1 [stable] is released!

Fri Jul 05, 2019 8:43 am

The issue with login via auto-upgrade feature is reproduced and will be fixed in upcoming RouterOS versions.
 
nostromog
Member Candidate
Member Candidate
Posts: 159
Joined: Wed Jul 18, 2018 3:39 pm

Re: v6.45.1 [stable] is released!

Fri Jul 05, 2019 9:31 am

It hangs in some initial script that tries to modify ipsec policies depending on dynamic local ip, it hangs on "/ export" or "/ip ipsec <whatever>". I can't generate a supout because it hangs :(
Have you tried to reset the machine to defaults before or better after upgrade to 6.45.1 and then manually create the IPsec configuration from the export rather than letting the upgrade script do that? This clearly cannot be used on the production machine but it should at least confirm that the IPsec part is the trigger, so you could be able to remove the IPsec configuration on the production machine before the upgrade if you can provide some other means to access it remotely (ssh, https) and recreate the IPsec part after the upgrade.
Thanks!!! It had not occurred to me that this might work, because when it first happened I downgraded, disabled the security package and upgraded again in the hope that this would allow me to re-enable and proceed. This worked, but re-enabling brought back the problem.

This machine is production but not really remote, no concern about loosing access. The only concern was downtime, but I did the whole operation yesterday during the night.

I did what you suggested: upgraded, went back to default configuration, re-executed the relevant parts of the export and I'm now in 6.45.1 I tried to restore a backup before but the problem reproduced, so re-executing from a export script was the winner.

The suggestion from support to netinstall would have amounted to much more work: first netinstall itself, then re-creating the configuration in exactly the same way, so basically I would have done to do the same.
Other than that, a support.rif of the state before upgrade should be enough for support to simulate the same process at their end.
Support did not asked me that, but they could find the problem (some corruption of the configuration created by some previous version, maybe a test with a beta) just by looking into a backup.
 
chubbs596
Frequent Visitor
Frequent Visitor
Posts: 51
Joined: Fri Dec 06, 2013 6:07 pm

Re: v6.45.1 [stable] is released!

Fri Jul 05, 2019 9:57 am

The issue with login via auto-upgrade feature is reproduced and will be fixed in upcoming RouterOS versions.
Thanks Guys
 
User avatar
NetVicious
Member Candidate
Member Candidate
Posts: 109
Joined: Fri Nov 13, 2009 3:30 pm
Location: Spain

Re: v6.45.1 [stable] is released!

Fri Jul 05, 2019 11:26 am

As I posted before I had (as others) problems with GRE with this new version of RouterOS. In my case I'm using pptp VPN tunnels.
I have a master router acting as pptp Server and some other devices acting as pptp client.
2 of that clients had problems trying to connect to the pptp server after the 6.45.1 upgrade. After a downgrade all was OK another time. 3 other clients with the same configuration and hardware had no problems after the upgrade. So something strange was somewhere.

I discovered the problem was on the helper service for the pptp service on
IP / Firewall / Service Ports
On the routers with problems I had on the pptp item the 1723 port. That item was in red. That show me the tip to try removing the port on that item. I don't remember to add that port so it should be there from a lot of years ago when it was a default setting.

After that change pptp worked perfectly another time after the 6.45.1 upgrade.

Obviously this fix should work only for pptp VPN tunnels. For other setups that use GRE you should add ONE of the fixes posted on this thread:
/ip firewall filter add chain=input action=accept protocol=gre src-address=
/ip firewall raw add action=notrack chain=prerouting protocol=gre
. . //\/ e t . \/ i c i o u s ..
 
GambarottoM
just joined
Posts: 3
Joined: Fri Jun 21, 2019 3:18 pm

Re: v6.45.1 [stable] is released!

Fri Jul 05, 2019 12:35 pm

Hi everyone,

I have a problem with queue and idle timeout in my default profile with radius authaticated users.

When a user try to login with the radius authetication (this one works for me), he will use my default user profile.
BUT he won't get my custom IDLE-TIMEOUT and won't create a NEW QUEUE in queues list, that are both in my user default profile.

If I use a local user with the same user profile, I don't have this problem.
If I use different parameters, I tried for example "keepalive-timeout", they will work as usual.

I don't know why, but these two paramethers are skipped in the authetication process with radius.
In addition to that my radius doesn't provide these two paramethers...

Problem only in v.6.45.1, in v6.44.3 (my previous version) all ok.

Thanks
 
nmt1900
newbie
Posts: 27
Joined: Wed Feb 01, 2017 12:36 am

Re: v6.45.1 [stable] is released!

Fri Jul 05, 2019 12:51 pm

spacex
nmt1900
Make sure that your monitored device "IP-SNMP communities" and The Dude "server settings" SNMP custom profile does not have any mismatch.
There is no mismatch and these community settings have been used for long time. Only Dude fails and it worked fine with 6.44.3. After testing it looks like only way to get it work with Dude is to use SNMPv2c or SNMPv1.
Can not reproduce your described problem, only with mismatched configuration. Have you tried to create new SNMP profile in The Dude and/or IP-SNMP communities? There must be something specific, if problem persist, you may try to send your supout.rif file to support@mikrotik.com.
Problem persists even after SNMP settings are reconfigured on both sides - this has been tested on RB450Gx4, RB750Gr3 and CHR as Dude servers (3 different architectures). I sent supout files.
 
buset1974
Frequent Visitor
Frequent Visitor
Posts: 50
Joined: Wed Sep 13, 2006 12:12 pm
Location: Jakarta

Re: v6.45.1 [stable] is released!

Fri Jul 05, 2019 1:39 pm

having problem upgrading hAP lite to 6.45.1 from 6.44.2

"system, error not enough space for upgrade."


thx
 
mkx
Forum Guru
Forum Guru
Posts: 2985
Joined: Thu Mar 03, 2016 10:23 pm

Re: v6.45.1 [stable] is released!

Fri Jul 05, 2019 2:00 pm

having problem upgrading hAP lite to 6.45.1 from 6.44.2

"system, error not enough space for upgrade."

In order to upgrade ROS, your hAP lite needs at least some 14MB RAM free (possibly even more) and around 1MB hdd free. Both are displayed using command /system resource print (fields free-memory and free-hdd-space respectively).

If your RAM is low, try to reboot device (in case there are some processes which incrementally consume RAM, such as connection tracking or dynamic address lists). If hdd is low, try to remove some files which might occupy space - check output of /file print).
BR,
Metod
 
User avatar
le1
just joined
Posts: 9
Joined: Sat Sep 15, 2018 8:56 pm
Location: Georgia, Tbilisi
Contact:

Re: v6.45.1 [stable] is released!

Fri Jul 05, 2019 3:08 pm

RADIUS authentication issue is already fixed in the latest beta. We will try to release a new stable version next week with a few fixes.
Thnx a lot :)
 
dk5980
just joined
Posts: 3
Joined: Thu Jan 11, 2018 5:48 pm

Re: v6.45.1 [stable] is released!

Fri Jul 05, 2019 3:30 pm

I am having 350 plus hotspot locations as my clients and hAP lite is being used almost @ 50 locations, and they got updated automatic. Now from every of those location I am getting complaints that hotspot login page is not coming automatically. user need to put the hotspot gateway ip or hotspot dns address in address bar of browser.

please resolve it ASAP, or suggest some work around.

I am having no such problem in rb850gx2, or rb450 or even hAP AC lite, all other routers are seems ok with this upgrade with as hotspot gateway.
 
freemannnn
Long time Member
Long time Member
Posts: 669
Joined: Sun Oct 13, 2013 7:29 pm

Re: v6.45.1 [stable] is released!

Fri Jul 05, 2019 3:43 pm

I am having 350 plus hotspot locations as my clients and hAP lite is being used almost @ 50 locations, and they got updated automatic. Now from every of those location I am getting complaints that hotspot login page is not coming automatically. user need to put the hotspot gateway ip or hotspot dns address in address bar of browser.

please resolve it ASAP, or suggest some work around.

I am having no such problem in rb850gx2, or rb450 or even hAP AC lite, all other routers are seems ok with this upgrade with as hotspot gateway.

updated automatic????? there is not such option in ros. maybe you have a script that does that. disable it.
why you update all business customers at once at the first day of ROS release? update one check-wait everything is ok and after do the others.
when something works dont touch it!
 
STEPHANVS
just joined
Posts: 8
Joined: Wed Mar 29, 2017 12:16 pm

Re: v6.45.1 [stable] is released!

Fri Jul 05, 2019 3:48 pm

Download/Upload counters showed way off values in interface window, zero activity on my transmission server, higher CPU usage. All on an RB951G-2HnD. Rolled back to 6.44.3 for now.
 
dk5980
just joined
Posts: 3
Joined: Thu Jan 11, 2018 5:48 pm

Re: v6.45.1 [stable] is released!

Fri Jul 05, 2019 4:49 pm

I am having 350 plus hotspot locations as my clients and hAP lite is being used almost @ 50 locations, and they got updated automatic. Now from every of those location I am getting complaints that hotspot login page is not coming automatically. user need to put the hotspot gateway ip or hotspot dns address in address bar of browser.

please resolve it ASAP, or suggest some work around.

I am having no such problem in rb850gx2, or rb450 or even hAP AC lite, all other routers are seems ok with this upgrade with as hotspot gateway.

updated automatic????? there is not such option in ros. maybe you have a script that does that. disable it.
why you update all business customers at once at the first day of ROS release? update one check-wait everything is ok and after do the others.
when something works dont touch it!
Yes, because of script.
I did not run the script on first day, it was yesterday, and till then nobody complained the issue. Yesterday evening when i got to know the issue from several clients one by one etc then I took the notice. because other than hAP lite router, no one else complained till now and everything is working fine in them.

Please suggest me something . I cant make downgrade them.
 
bnw
just joined
Posts: 10
Joined: Thu Jun 13, 2019 5:56 pm

Re: v6.45.1 [stable] is released!

Fri Jul 05, 2019 5:23 pm

*) fetch - added SFTP support;
Good news !
Any way to use SSH key instead of password for login phase ?
Thank you !
 
User avatar
osc86
Frequent Visitor
Frequent Visitor
Posts: 50
Joined: Wed Aug 09, 2017 1:15 pm

Re: v6.45.1 [stable] is released!

Fri Jul 05, 2019 5:39 pm

Any updates regarding the SNMPv3 PrivAuth <-> Dude Issue?
For sure there's something wrong, I set up a new dude server and this "bad packet" error happens on all my devices running 6.45.1, LibreNMS works fine, though.
CCR1009-7G-1C-1S+ ROS6.45.2
 
User avatar
NetVicious
Member Candidate
Member Candidate
Posts: 109
Joined: Fri Nov 13, 2009 3:30 pm
Location: Spain

Re: v6.45.1 [stable] is released!

Fri Jul 05, 2019 7:28 pm

Yes, because of script.
I did not run the script on first day, it was yesterday, and till then nobody complained the issue. Yesterday evening when i got to know the issue from several clients one by one etc then I took the notice. because other than hAP lite router, no one else complained till now and everything is working fine in them.

Please suggest me something . I cant make downgrade them.
You have remote access from your office to each device?
You can launch within the RouterOS api a downgrade command for each device at the same time.
I don't have the downgrade option on my mtkManager but it can be easily added.
. . //\/ e t . \/ i c i o u s ..
 
nostromog
Member Candidate
Member Candidate
Posts: 159
Joined: Wed Jul 18, 2018 3:39 pm

Re: v6.45.1 [stable] is released!

Fri Jul 05, 2019 8:25 pm

In order to upgrade ROS, your hAP lite needs at least some 14MB RAM free (possibly even more) and around 1MB hdd free. Both are displayed using command /system resource print (fields free-memory and free-hdd-space respectively).

If your RAM is low, try to reboot device (in case there are some processes which incrementally consume RAM, such as connection tracking or dynamic address lists). If hdd is low, try to remove some files which might occupy space - check output of /file print).
I wonder if those two short paragraphs by mkx should be present as a footnote in every new release announcement, subtituting hAP lite -> device :) It would save some bad experience for users, and some work for support.
Last edited by nostromog on Sat Jul 06, 2019 1:31 pm, edited 1 time in total.
 
vb99
just joined
Posts: 1
Joined: Tue Mar 06, 2018 11:45 am

Re: v6.45.1 [stable] is released!

Fri Jul 05, 2019 9:20 pm

my web proxy not work on this version. may somebody give me help?
 
waeel
just joined
Posts: 2
Joined: Tue Dec 26, 2017 8:25 am

Re: v6.45.1 [stable] is released!

Sat Jul 06, 2019 12:40 am

Hi support
When update 6.45.1 dont log in via api user or password erro
can you help me pls
 
sindy
Forum Guru
Forum Guru
Posts: 3814
Joined: Mon Dec 04, 2017 9:19 pm

Re: v6.45.1 [stable] is released!

Sat Jul 06, 2019 12:55 am

read previous posts in this topic, search for "api".
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
eworm
Member
Member
Posts: 395
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

Re: v6.45.1 [stable] is released!

Sat Jul 06, 2019 1:00 am

I have serve issues with all my IPSec responders. As far as I can tell about half of my IPSec initiator devices do not get addresses from mode-config.
Not sure about the details. Anybody else seen this?
One after another the IPSec links came up without any configuration change. Finally today (after four days) every single link is up.
I can no longer reproduce - this looks as reliable as before the update. My guess is that any state data was corrupted on update and replaced successively later on.
Manage RouterOS scripts and extend your devices' functionality: RouterOS Scripts
 
Grant
just joined
Posts: 3
Joined: Sat Oct 26, 2013 10:55 am

Re: v6.45.1 [stable] is released!

Sat Jul 06, 2019 9:10 am

Hello!
after upgrading to version 6.45.1, power wi-fi lowered, permanent disconnects appeared, especially in the next room
device hAP ac lite
 
tesme33
newbie
Posts: 48
Joined: Mon May 26, 2014 10:25 pm

Re: v6.45.1 [stable] is released!

Sat Jul 06, 2019 2:10 pm

In order to upgrade ROS, your hAP lite needs at least some 14MB RAM free (possibly even more) and around 1MB hdd free. Both are displayed using command /system resource print (fields free-memory and free-hdd-space respectively).

If your RAM is low, try to reboot device (in case there are some processes which incrementally consume RAM, such as connection tracking or dynamic address lists). If hdd is low, try to remove some files which might occupy space - check output of /file print).
I wonder if those two short paragraphs by mkx should be present as a footnote in every new release announcement, subtituting hAP lite -> device :) It would save some bad experience for users, and some work for support.
Hi @nostromog
i would say even with the paragraphs you are not able to make the upgrade.
I have no files at all on my haplite (2 pcs) and only a minimal config. One worked and one not.
So what now ?
 
salah
just joined
Posts: 7
Joined: Sun Jan 10, 2016 12:09 am

Re: v6.45.1 [stable] is released!

Sat Jul 06, 2019 3:02 pm

hi,
I upgrade my router from 6.43 to 6.45.1

i get a problem when I connect my laptop (win10) with 802.1x authentication to the router with dot1x server and user-manager enabled.

authentication method: Microsoft PEAP
secured pass: (EAP-MSCHAP V2)

I get this error (unknown authentication algorithm )

log:
Image
 
salah
just joined
Posts: 7
Joined: Sun Jan 10, 2016 12:09 am

Re: v6.45.1 [stable] is released!

Sat Jul 06, 2019 3:09 pm

having problem upgrading hAP lite to 6.45.1 from 6.44.2

"system, error not enough space for upgrade."


thx
copy everything from file to your computer, upgrade your router and get your file back to the router after upgrade .
 
pe1chl
Forum Guru
Forum Guru
Posts: 5833
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.45.1 [stable] is released!

Sat Jul 06, 2019 4:29 pm

having problem upgrading hAP lite to 6.45.1 from 6.44.2
copy everything from file to your computer, upgrade your router and get your file back to the router after upgrade .
When you have files on your hAP lite, you are doing something wrong! This is a low-end router that is not supposed to have files on it. There is no space.
I booted my hAP lite (which is not in active use) and upgraded it from 6.44.3 to 6.45.1 without any problem.
Before the upgrade it had 8mb RAM free and apparently that is enough.
 
dk5980
just joined
Posts: 3
Joined: Thu Jan 11, 2018 5:48 pm

Re: v6.45.1 [stable] is released!

Sat Jul 06, 2019 5:17 pm

Yes, because of script.
I did not run the script on first day, it was yesterday, and till then nobody complained the issue. Yesterday evening when i got to know the issue from several clients one by one etc then I took the notice. because other than hAP lite router, no one else complained till now and everything is working fine in them.

Please suggest me something . I cant make downgrade them.
You have remote access from your office to each device?
You can launch within the RouterOS api a downgrade command for each device at the same time.
I don't have the downgrade option on my mtkManager but it can be easily added.
Where I may get this mtkManager ?
 
Iwanche
just joined
Posts: 3
Joined: Thu Mar 29, 2018 2:26 pm

Re: v6.45.1 [stable] is released!

Sat Jul 06, 2019 8:49 pm

Does someone have a problem with mac telnet login via neighbours?

Won't login with any user and pass or without pass, nor admin..
 
mahadiapps
just joined
Posts: 1
Joined: Sat Jul 06, 2019 10:00 pm

Re: v6.45.1 [stable] is released!

Sat Jul 06, 2019 10:07 pm

Dear Sir,

I have CCR 1036 8G-2S+ Router. When Router os update V6.45.1 ( stable) this code doesn't working, or login mikrotik router how to change please help.


<?php
/*****************************
 *
 * RouterOS PHP API class v1.5
 * Author: Denis Basta
 * Contributors:
 *    Nick Barnes
 *    Ben Menking (ben [at] infotechsc [dot] com)
 *    Jeremy Jefferson (http://jeremyj.com)
 *    Cristian Deluxe (djcristiandeluxe [at] gmail [dot] com)
 *
 * http://www.mikrotik.com
 * http://wiki.mikrotik.com/wiki/API_PHP_class
 *
 ******************************/

class routeros_api
{
    var $debug = false;      // Show debug information
    var $error_no;           // Variable for storing connection error number, if any
    var $error_str;          // Variable for storing connection error text, if any
    var $attempts = 5;       // Connection attempt count
    var $connected = true;  // Connection state
    var $delay = 3;          // Delay between connection attempts in seconds
    var $port = 8728;        // Port to connect to
    var $timeout = 3;        // Connection attempt timeout and data read timeout
    var $socket;             // Variable for storing socket resource
    
    /**
     * Print text for debug purposes
     *
     * @param string      $text       Text to print
     *
     * @return void
     */
    function debug($text)
    {
        if ($this->debug)
            echo $text . "\n";
    }
	
	
    /**
     * 
     *
     * @param string        $length
     *
     * @return void
     */
    function encode_length($length)
    {
        if ($length < 0x80) {
            $length = chr($length);
        } else if ($length < 0x4000) {
            $length |= 0x8000;
            $length = chr(($length >> 8) & 0xFF) . chr($length & 0xFF);
        } else if ($length < 0x200000) {
            $length |= 0xC00000;
            $length = chr(($length >> 16) & 0xFF) . chr(($length >> 8) & 0xFF) . chr($length & 0xFF);
        } else if ($length < 0x10000000) {
            $length |= 0xE0000000;
            $length = chr(($length >> 24) & 0xFF) . chr(($length >> 16) & 0xFF) . chr(($length >> 8) & 0xFF) . chr($length & 0xFF);
        } else if ($length >= 0x10000000)
            $length = chr(0xF0) . chr(($length >> 24) & 0xFF) . chr(($length >> 16) & 0xFF) . chr(($length >> 8) & 0xFF) . chr($length & 0xFF);
        return $length;
    }
	
	
    /**
     * Login to RouterOS
     *
     * @param string      $ip         Hostname (IP or domain) of the RouterOS server
     * @param string      $login      The RouterOS username
     * @param string      $password   The RouterOS password
     *
     * @return boolean                If we are connected or not
     */
    function connect($ip, $login, $password)
    {
        for ($ATTEMPT = 1; $ATTEMPT <= $this->attempts; $ATTEMPT++) {
            $this->connected = false;
            $this->debug('Connection attempt #' . $ATTEMPT . ' to ' . $ip . ':' . $this->port . '...');
            $this->socket = @fsockopen($ip, $this->port, $this->error_no, $this->error_str, $this->timeout);
            if ($this->socket) {
                socket_set_timeout($this->socket, $this->timeout);
                $this->write('/login');
                $RESPONSE = $this->read(false);
                if ($RESPONSE[0] == '!done') {
                    $MATCHES = array();
                    if (preg_match_all('/[^=]+/i', $RESPONSE[1], $MATCHES)) {
                        if ($MATCHES[0][0] == 'ret' && strlen($MATCHES[0][1]) == 32) {
                            $this->write('/login', false);
                            $this->write('=name=' . $login, false);
                            $this->write('=response=00' . md5(chr(0) . $password . pack('H*', $MATCHES[0][1])));
                            $RESPONSE = $this->read(false);
                            if ($RESPONSE[0] == '!done') {
                                $this->connected = true;
                                break;
                            }
                        }
                    }
                }
                fclose($this->socket);
            }
            sleep($this->delay);
        }
        if ($this->connected)
            $this->debug('Connected...');
        else
            $this->debug('Error...');
        return $this->connected;
    }
	
	
    /**
     * Disconnect from RouterOS
     *
     * @return void
     */
    function disconnect()
    {
        fclose($this->socket);
        $this->connected = false;
        $this->debug('Disconnected...');
    }
	
	
    /**
     * Parse response from Router OS
     *
     * @param array       $response   Response data
     *
     * @return array                  Array with parsed data
     */
    function parse_response($response)
    {
        if (is_array($response)) {
            $PARSED      = array();
            $CURRENT     = null;
            $singlevalue = null;
            foreach ($response as $x) {
                if (in_array($x, array(
                    '!fatal',
                    '!re',
                    '!trap'
                ))) {
                    if ($x == '!re') {
                        $CURRENT =& $PARSED[];
                    } else
                        $CURRENT =& $PARSED[$x][];
                } else if ($x != '!done') {
                    $MATCHES = array();
                    if (preg_match_all('/[^=]+/i', $x, $MATCHES)) {
                        if ($MATCHES[0][0] == 'ret') {
                            $singlevalue = $MATCHES[0][1];
                        }
						$CURRENT[$MATCHES[0][0]] = (isset($MATCHES[0][1]) ? $MATCHES[0][1] : '');
					}
                }
            }
            if (empty($PARSED) && !is_null($singlevalue)) {
                $PARSED = $singlevalue;
            }
            return $PARSED;
        } else
            return array();
    }
	
	
    /**
     * Parse response from Router OS
     *
     * @param array       $response   Response data
     *
     * @return array                  Array with parsed data
     */
    function parse_response4smarty($response)
    {
        if (is_array($response)) {
            $PARSED  = array();
            $CURRENT = null;
            $singlevalue = null;
            foreach ($response as $x) {
                if (in_array($x, array(
                    '!fatal',
                    '!re',
                    '!trap'
                ))) {
                    if ($x == '!re')
                        $CURRENT =& $PARSED[];
                    else
                        $CURRENT =& $PARSED[$x][];
                } else if ($x != '!done') {
                    $MATCHES = array();
                    if (preg_match_all('/[^=]+/i', $x, $MATCHES)) {
                        if ($MATCHES[0][0] == 'ret') {
                            $singlevalue = $MATCHES[0][1];
                        }
                        $CURRENT[$MATCHES[0][0]] = (isset($MATCHES[0][1]) ? $MATCHES[0][1] : '');
					}
                }
            }
            foreach ($PARSED as $key => $value) {
                $PARSED[$key] = $this->array_change_key_name($value);
            }
            return $PARSED;
            if (empty($PARSED) && !is_null($singlevalue)) {
                $PARSED = $singlevalue;
            }
        } else {
            return array();
        }
    }
	
	
    /**
     * Change "-" and "/" from array key to "_"
     *
     * @param array       $array      Input array
     *
     * @return array                  Array with changed key names
     */
    function array_change_key_name(&$array)
    {
        if (is_array($array)) {
            foreach ($array as $k => $v) {
                $tmp = str_replace("-", "_", $k);
                $tmp = str_replace("/", "_", $tmp);
                if ($tmp) {
                    $array_new[$tmp] = $v;
                } else {
                    $array_new[$k] = $v;
                }
            }
            return $array_new;
        } else {
            return $array;
        }
    }
	
	
    /**
     * Read data from Router OS
     *
     * @param boolean     $parse      Parse the data? default: true
     *
     * @return array                  Array with parsed or unparsed data
     */
    function read($parse = true)
    {
        $RESPONSE = array();
        $receiveddone = false;
        while (true) {
            // Read the first byte of input which gives us some or all of the length
            // of the remaining reply.
            $BYTE   = ord(fread($this->socket, 1));
            $LENGTH = 0;
            // If the first bit is set then we need to remove the first four bits, shift left 8
            // and then read another byte in.
            // We repeat this for the second and third bits.
            // If the fourth bit is set, we need to remove anything left in the first byte
            // and then read in yet another byte.
            if ($BYTE & 128) {
                if (($BYTE & 192) == 128) {
                    $LENGTH = (($BYTE & 63) << 8) + ord(fread($this->socket, 1));
                } else {
                    if (($BYTE & 224) == 192) {
                        $LENGTH = (($BYTE & 31) << 8) + ord(fread($this->socket, 1));
                        $LENGTH = ($LENGTH << 8) + ord(fread($this->socket, 1));
                    } else {
                        if (($BYTE & 240) == 224) {
                            $LENGTH = (($BYTE & 15) << 8) + ord(fread($this->socket, 1));
                            $LENGTH = ($LENGTH << 8) + ord(fread($this->socket, 1));
                            $LENGTH = ($LENGTH << 8) + ord(fread($this->socket, 1));
                        } else {
                            $LENGTH = ord(fread($this->socket, 1));
                            $LENGTH = ($LENGTH << 8) + ord(fread($this->socket, 1));
                            $LENGTH = ($LENGTH << 8) + ord(fread($this->socket, 1));
                            $LENGTH = ($LENGTH << 8) + ord(fread($this->socket, 1));
                        }
                    }
                }
            } else {
                $LENGTH = $BYTE;
            }
            // If we have got more characters to read, read them in.
            if ($LENGTH > 0) {
                $_      = "";
                $retlen = 0;
                while ($retlen < $LENGTH) {
                    $toread = $LENGTH - $retlen;
                    $_ .= fread($this->socket, $toread);
                    $retlen = strlen($_);
                }
                $RESPONSE[] = $_;
                $this->debug('>>> [' . $retlen . '/' . $LENGTH . '] bytes read.');
            }
            // If we get a !done, make a note of it.
            if ($_ == "!done")
                $receiveddone = true;
            $STATUS = socket_get_status($this->socket);
            if ($LENGTH > 0)
                $this->debug('>>> [' . $LENGTH . ', ' . $STATUS['unread_bytes'] . ']' . $_);
            if ((!$this->connected && !$STATUS['unread_bytes']) || ($this->connected && !$STATUS['unread_bytes'] && $receiveddone))
                break;
        }
        if ($parse)
            $RESPONSE = $this->parse_response($RESPONSE);
        return $RESPONSE;
    }
	
	
    /**
     * Write (send) data to Router OS
     *
     * @param string      $command    A string with the command to send
     * @param mixed       $param2     If we set an integer, the command will send this data as a "tag"
     *                                If we set it to boolean true, the funcion will send the comand and finish
     *                                If we set it to boolean false, the funcion will send the comand and wait for next command
     *                                Default: true
     *
     * @return boolean                Return false if no command especified
     */
    function write($command, $param2 = true)
    {
        if ($command) {
            $data = explode("\n", $command);
            foreach ($data as $com) {
                $com = trim($com);
                fwrite($this->socket, $this->encode_length(strlen($com)) . $com);
                $this->debug('<<< [' . strlen($com) . '] ' . $com);
            }
            if (gettype($param2) == 'integer') {
                fwrite($this->socket, $this->encode_length(strlen('.tag=' . $param2)) . '.tag=' . $param2 . chr(0));
                $this->debug('<<< [' . strlen('.tag=' . $param2) . '] .tag=' . $param2);
            } else if (gettype($param2) == 'boolean')
                fwrite($this->socket, ($param2 ? chr(0) : ''));
            return true;
        } else
            return false;
    }
	
	
    /**
     * Write (send) data to Router OS
     *
     * @param string      $com        A string with the command to send
     * @param array       $arr        An array with arguments or queries
     *
     * @return array                  Array with parsed
     */
    function comm($com, $arr = array())
    {
        $count = count($arr);
        $this->write($com, !$arr);
        $i = 0;
        foreach ($arr as $k => $v) {
            switch ($k[0]) {
                case "?":
                    $el = "$k=$v";
                    break;
                case "~":
                    $el = "$k~$v";
                    break;
                default:
                    $el = "=$k=$v";
                    break;
            }
            $last = ($i++ == $count - 1);
            $this->write($el, $last);
        }
        return $this->read();
    }
}
?>
 
ludvik
Frequent Visitor
Frequent Visitor
Posts: 59
Joined: Mon May 26, 2008 4:36 pm

Re: v6.45.1 [stable] is released!

Sat Jul 06, 2019 11:50 pm

Read before write. And then for example: https://wiki.mikrotik.com/wiki/Manual:API#Initial_login
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8310
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

Re: v6.45.1 [stable] is released!

Sun Jul 07, 2019 12:12 am

Dear Sir,

I have CCR 1036 8G-2S+ Router. When Router os update V6.45.1 ( stable) this code doesn't working, or login mikrotik router how to change please help.
You're using outdated API client, it was updated for v6.45 a year ago!
https://github.com/BenMenking/routeros-api
Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

For every complex problem, there is a solution that is simple, neat, and wrong.

MikroTik. Your life. Your routing.
 
bellotaman
just joined
Posts: 2
Joined: Thu Aug 04, 2016 3:51 pm

Re: v6.45.1 [stable] is released!

Sun Jul 07, 2019 2:02 am

Hi all!

I've noticed (suffered) that ALL my SXT G-5HPnD r2 in my network hang randomly. Had to power down them to recover access, and they work for 1 or 2 hours before recrash. Had to downgrade all them to 6.44.4 to take stability again.

So, the 921 system stability announced on changelog works fine with my problematic ones with had 6.44.3, and now on 6.45.1 they are fine; but my rock-solid SXT SA5 with 6.44.3 are now a headache on 6.45.1, so they are downgraded.

Too many SA5 on my net to be a casual failure.

PD. Sorry for my english.
 
bbs2web
Member Candidate
Member Candidate
Posts: 198
Joined: Sun Apr 22, 2012 6:25 pm
Location: Johannesburg, South Africa
Contact:

Re: v6.45.1 [stable] is released!

Sun Jul 07, 2019 2:21 am

Does someone have a problem with mac telnet login via neighbours?

Won't login with any user and pass or without pass, nor admin..
Unfortunately yes, not all devices though and resetting credentials does not help...
 
Iwanche
just joined
Posts: 3
Joined: Thu Mar 29, 2018 2:26 pm

Re: v6.45.1 [stable] is released!

Sun Jul 07, 2019 10:55 pm

Does someone have a problem with mac telnet login via neighbours?

Won't login with any user and pass or without pass, nor admin..
Unfortunately yes, not all devices though and resetting credentials does not help...
Yes, resetting credentials doesn't help.
I noticed that it happens to device that are in bridge mode.
Any help or solution?
 
User avatar
Jotne
Forum Guru
Forum Guru
Posts: 1303
Joined: Sat Dec 24, 2016 11:17 am
Location: jo.overland at gmail.com

Re: v6.45.1 [stable] is released!

Sun Jul 07, 2019 11:35 pm

Mine upgraded hAP lite, files login using Winbox the first time I try. Second try ok.
Seems to be every time.
 
How to use Splunk to monitor your MikroTik Router

MikroTik->Splunk
 
 
GambarottoM
just joined
Posts: 3
Joined: Fri Jun 21, 2019 3:18 pm

Re: v6.45.1 [stable] is released!

Mon Jul 08, 2019 10:35 am

Hi everyone,

I have a problem with queue and idle timeout in my default profile with radius authaticated users.

When a user try to login with the radius authetication (this one works for me), he will use my default user profile.
BUT he won't get my custom IDLE-TIMEOUT and won't create a NEW QUEUE in queues list, that are both in my user default profile.

If I use a local user with the same user profile, I don't have this problem.
If I use different parameters, I tried for example "keepalive-timeout", they will work as usual.

I don't know why, but these two paramethers are skipped in the authetication process with radius.
In addition to that my radius doesn't provide these two paramethers...

Problem only in v.6.45.1, in v6.44.3 (my previous version) all ok.

Thanks

Someone has a solution for these problems?
 
User avatar
skylark
MikroTik Support
MikroTik Support
Posts: 106
Joined: Wed Feb 10, 2016 3:55 pm

Re: v6.45.1 [stable] is released!

Mon Jul 08, 2019 12:23 pm

Someone has a solution for these problems?
Please enable RADIUS debug logs and send us the supout.rif file to support@mikrotik.com:
/system logging add topics=radius
 
jarda
Forum Guru
Forum Guru
Posts: 7603
Joined: Mon Oct 22, 2012 4:46 pm

Re: v6.45.1 [stable] is released!

Mon Jul 08, 2019 1:32 pm

Just to let you all know:
SNMP v.3 problem with "unsupported v3 security level" error was already reported to Mikrotik with ticket number [Ticket#2019070422003642].
I have been asked for some additional information, I provided response, but after that no news. Hope Mikrotik is working on correction.
 
dadaniel
Member Candidate
Member Candidate
Posts: 157
Joined: Fri May 14, 2010 11:51 pm

Re: v6.45.1 [stable] is released!

Mon Jul 08, 2019 1:32 pm

Does someone have a problem with mac telnet login via neighbours?

Won't login with any user and pass or without pass, nor admin..
I have the same problem.
 
GambarottoM
just joined
Posts: 3
Joined: Fri Jun 21, 2019 3:18 pm

Re: v6.45.1 [stable] is released!

Mon Jul 08, 2019 1:43 pm

Someone has a solution for these problems?
Please enable RADIUS debug logs and send us the supout.rif file to support@mikrotik.com:
/system logging add topics=radius
Hi Skylark, it's the first log that I checked.

Jul/08/2019 12:30:32 radius,debug new request 3f:138 code=Access-Request service=hotspot called-id=ServerWiFi
Jul/08/2019 12:30:32 radius,debug sending 3f:138 to 10.97.0.254:1812
Jul/08/2019 12:30:32 radius,debug,packet sending Access-Request with id 64 to 10.97.0.254:1812
Jul/08/2019 12:30:32 radius,debug,packet Signature = 0x189a769b54e49eb471f324542ca88611
Jul/08/2019 12:30:32 radius,debug,packet NAS-Port-Type = 19
Jul/08/2019 12:30:32 radius,debug,packet Calling-Station-Id = "C0:3F:D5:5B:00:EC"
Jul/08/2019 12:30:32 radius,debug,packet Called-Station-Id = "ServerWiFi"
Jul/08/2019 12:30:32 radius,debug,packet NAS-Port-Id = "ether5"
Jul/08/2019 12:30:32 radius,debug,packet User-Name = "username"
Jul/08/2019 12:30:32 radius,debug,packet NAS-Port = 2147483668
Jul/08/2019 12:30:32 radius,debug,packet Acct-Session-Id = "80000014"
Jul/08/2019 12:30:32 radius,debug,packet Framed-IP-Address = 10.10.250.250
Jul/08/2019 12:30:32 radius,debug,packet MT-Host-IP = 10.10.250.250
Jul/08/2019 12:30:32 radius,debug,packet User-Password = 0x4d34746963
Jul/08/2019 12:30:32 radius,debug,packet Service-Type = 1
Jul/08/2019 12:30:32 radius,debug,packet WISPr-Logoff-URL = "http://10.10.250.1/logout"
Jul/08/2019 12:30:32 radius,debug,packet NAS-Identifier = "Test"
Jul/08/2019 12:30:32 radius,debug,packet NAS-IP-Address = 10.97.0.103
Jul/08/2019 12:30:34 radius,debug,packet received Access-Accept with id 64 from 10.97.0.254:1812
Jul/08/2019 12:30:34 radius,debug,packet Signature = 0x65367fa61743ee7525aa52a67d3b8f7e
Jul/08/2019 12:30:34 radius,debug,packet Session-Timeout = 79503
Jul/08/2019 12:30:34 radius,debug,packet WISPr-Redirection-URL = "welcome.html"
Jul/08/2019 12:30:34 radius,debug received reply for 3f:138

There are only two variables in my radius reply:
- Session-Timeout = 79503
- WISPr-Redirection-URL = "welcome.html"

No idle timeout variable.


Anyway, I manage to get an idle-timeout with this change
/ip hotspot set ServerWiFi idle-timeout=1h
/ip hotspot user profile unset default idle-timeout
It seems that the idle-timeout for user profile doesn't count anymore in radius authentication.

I still have the problem with queue... I can't create them with radius authentication.
 
Wintermute
just joined
Posts: 21
Joined: Fri Jan 15, 2010 1:22 pm

Re: v6.45.1 [stable] is released!

Mon Jul 08, 2019 1:59 pm

Last Link Up/Down Time botched. It started happening to me (951G-2HnD, 941-2nD) on the latest stable ROS 6.45.1 / WinBox 3.19. Ethernet and ppp links.

WinBox Terminal - correct:
last-link-down-time=jul/08/2019 12:31:21

WinBox Interface List - wrong:
Last Link Down Time: Jul/14/2019 09:44:52

Today is Jul/08.

Mikrotik seriously, are you drunk? Search on this forum reveals, this or very similar similar issue was reported years or months ago.
 
User avatar
Cha0s
Forum Veteran
Forum Veteran
Posts: 903
Joined: Tue Oct 11, 2005 4:53 pm

Re: v6.45.1 [stable] is released!

Mon Jul 08, 2019 2:15 pm

Last Link Up/Down Time botched. It started happening to me (951G-2HnD, 941-2nD) on the latest stable ROS 6.45.1 / WinBox 3.19. Ethernet and ppp links.

WinBox Terminal - correct:
last-link-down-time=jul/08/2019 12:31:21

WinBox Interface List - wrong:
Last Link Down Time: Jul/14/2019 09:44:52

Today is Jul/08.

Mikrotik seriously, are you drunk? Search on this forum reveals, this or very similar similar issue was reported years or months ago.
This is a Winbox bug, not a RouterOS bug. And it didn't appear on 6.45.1, but long before that.
It has been reported numerous times but MikroTik says it's just a cosmetic bug, so no fix yet.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5833
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.45.1 [stable] is released!

Mon Jul 08, 2019 3:40 pm

Last Link Up/Down Time botched. It started happening to me (951G-2HnD, 941-2nD) on the latest stable ROS 6.45.1 / WinBox 3.19. Ethernet and ppp links.
This is a Winbox bug, not a RouterOS bug. And it didn't appear on 6.45.1, but long before that.
It has been reported numerous times but MikroTik says it's just a cosmetic bug, so no fix yet.
I don't expect a winbox release for this, but it surprised me a little that the 3.19 release did not include the fix for this long-known issue...
 
User avatar
gabrielpike
Frequent Visitor
Frequent Visitor
Posts: 84
Joined: Thu Apr 17, 2014 4:17 pm

Re: v6.45.1 [stable] is released!

Mon Jul 08, 2019 5:13 pm

I tried upgrading 2 routers that had minimal clients. OSPF has routers running at 100% CPU after upgrade and routes are not forwarding. After downgrade all works as expected. Not sure what is causing this.
Gabriel Pike
MTCNA
 
vorona
just joined
Posts: 1
Joined: Mon Jul 08, 2019 5:07 pm

Re: v6.45.1 [stable] is released!

Mon Jul 08, 2019 5:22 pm

my web proxy not work on this version. may somebody give me help?
the same issue
 
tonymobile
newbie
Posts: 37
Joined: Mon Jul 07, 2008 2:10 am

Re: v6.45.1 [stable] is released!

Mon Jul 08, 2019 6:45 pm

After upgrade some BSU for test, i have problem with mac authentication on my centralized radius.

I'm come back to 6.44.3

Mikrotik team, please fix bug.
 
tesme33
newbie
Posts: 48
Joined: Mon May 26, 2014 10:25 pm

Re: v6.45.1 [stable] is released!

Mon Jul 08, 2019 6:46 pm

hi
just to let you know if you are also not able to upgrade your hap lite.

Solution from mikrotik:
Hello,

Based on your provided information:
system,error not enough space for upgrade 

Please use the Netinstall utility to reinstall the device:
https://wiki.mikrotik.com/wiki/Manual:Netinstall
How this can be done remote ? I dont know.

And does this mean we have now to do this everytime, as the sw is now to large for 16M Flash ?
 
User avatar
Xymox
Member
Member
Posts: 387
Joined: Thu Jan 21, 2010 5:04 pm
Location: Phoenix, Arizona US
Contact:

Re: v6.45.1 [stable] is released!

Mon Jul 08, 2019 7:47 pm

I was running the 45RC betas and I did not notice these issues. but maybe I was not using the features that now have issues.

So all the issues in this thread were in the RC ?

Or were these issues introduced after the RC ?

Were the 5 CVEs patched in the RCs or did those patches only get included in the stable ?

Im just wondering how these issues got all the way into a stable release and how to prevent this in the future.
 
tesme33
newbie
Posts: 48
Joined: Mon May 26, 2014 10:25 pm

Re: v6.45.1 [stable] is released!

Mon Jul 08, 2019 10:05 pm

Hi
now i have upgraded 3 of my 4 hAP lite and i noticed that the one having the issue is only showing 7.4 MB free-hdd-space. The others are all showing more or equal to 7.5 MB.
What is consuming the space ? The config is "just" 98 lines other configs in the other haPlite were 154 lines or more.

How can i see what is stored on the flash ?

Anybody an idea ?
 
sid5632
Member
Member
Posts: 352
Joined: Fri Feb 17, 2017 6:05 pm

Re: v6.45.1 [stable] is released!

Mon Jul 08, 2019 10:20 pm

You can't see what's taking the space.
Netinstall it and use the unbundled packages (just the ones you need, not all of them).
 
DanchoDimitrov
just joined
Posts: 7
Joined: Wed Jul 03, 2019 10:10 pm
Location: Bulgaria

Re: v6.45.1 [stable] is released!

Mon Jul 08, 2019 11:04 pm

Anyone having poor/worse wifi performance after the update?
Edit:
Tried reverting (downgrading) RouterOS to 6.44.3 (firmware too) and wifi is fixed. This update basically returned the issues mentioned in viewtopic.php?t=131960
worse performance over 2ghz and terrible performance over 5ghz on the hAP AC^2.I was getting ~500ms ping over AC wifi, but with the older routeros and firmware its ~3ms under the same conditions. Clearly something broke with this update for this particular device. The other end of the wireless connection is Intel AC 3160 (the version with bluetooth). Tell me if you need more info on this in order to fix it.
hAP AC^2
 
turnip
Frequent Visitor
Frequent Visitor
Posts: 66
Joined: Wed Sep 11, 2013 7:01 pm

Re: v6.45.1 [stable] is released!

Tue Jul 09, 2019 11:08 am

I installed a new switch and access points at a client site yesterday running 6.45.1. The existing equipment onsite is all running 6.42.7. I wasn't able to upgrade it at the time (would have caused an interruption).
While onsite, I didn't have any problems, but now that I'm back in my office and trying to connect to these devices via RoMON, I'm finding the same authentication issue others have reported (ERROR: wrong username or password).
I've upgraded to Winbox 3.19 and this hasn't solved the problem.
I'm still able to access the devices via SSH from the router.
 
rekeds
just joined
Posts: 10
Joined: Fri Mar 14, 2014 10:45 pm

Re: v6.45.1 [stable] is released!

Tue Jul 09, 2019 11:50 am

11:36:27 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:36:37 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:37:07 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:37:18 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:37:47 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:37:58 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:38:27 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:38:39 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:39:08 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:39:20 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:39:48 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:40:01 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:40:28 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:40:42 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:41:08 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:41:22 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:41:48 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:42:02 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:42:28 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:42:43 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:43:08 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:43:23 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:43:48 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:44:04 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:44:28 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:44:45 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:45:08 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:45:26 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:45:48 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:46:07 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:46:29 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:46:48 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:47:09 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:47:29 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
downgrade 6.44, ospf works :[

about 20 routers, half was updated, all updated did this. downgrade fixes ;[

ospf with backbone and 23 nssa areas.
two links from bbone to nssa. 🤷‍♂️
vrf.

edit.
added a nokia to the mix:

"LCL_RTR_ID 10.9.0.1: Neighbor 0.0.0.6 on TEST-NBR router state changed to exchangeStart (event SEQ_MISM)" :D
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8310
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

Re: v6.45.1 [stable] is released!

Tue Jul 09, 2019 12:12 pm

new switch and access points running 6.45.1
The existing equipment onsite is all running 6.42.7
Looks like that is the answer. You cannot connect to >= 6.45 from <= 6.42.
Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

For every complex problem, there is a solution that is simple, neat, and wrong.

MikroTik. Your life. Your routing.
 
seb13
just joined
Posts: 3
Joined: Mon Sep 12, 2016 10:11 pm

Re: v6.45.1 [stable] is released!

Tue Jul 09, 2019 1:28 pm

How do I exclude an IP Range from an IPsec Policy in 6.45.1. Previously I did the following, like mentioned here viewtopic.php?t=118224
/ip ipsec policy
add action=none comment="do not tunnel local network" dst-address=10.11.1.0/24 src-address=0.0.0.0/0
add dst-address=10.0.0.0/8 proposal=phase2 sa-dst-address=1.2.3.4 sa-src-address=4.3.2.1 src-address=10.11.1.0/24 tunnel=yes
With 6.45.1 I cannot set the first policy. When I assign an existing peer, I get "Couldn't change IPsec Policy. Addresses in transport mode are updated automatic (6)". When I create a new peer having the address 10.11.1.0/24 and assign the policy, it's not excluding anything and stays red.
/ip ipsec peer
add address=10.11.1.0/24 exchange-mode=ike2 name=local passive=yes profile=phase1
/ip ipsec policy
add action=none dst-address=10.11.1.0/24 peer=local src-address=0.0.0.0/0
What's actually the correct way to exclude an overlapping IP Range when using IPsec?
 
nescafe2002
Long time Member
Long time Member
Posts: 623
Joined: Tue Aug 11, 2015 12:46 pm
Location: Netherlands

Re: v6.45.1 [stable] is released!

Tue Jul 09, 2019 1:36 pm

Add the policy with action=none and no peer:

/ip ipsec policy
add action=none dst-address=10.11.1.0/24 src-address=0.0.0.0/0

Peer is displayed as "unknown" in Winbox, but that's a cosmetic issue.
 
User avatar
emils
MikroTik Support
MikroTik Support
Topic Author
Posts: 495
Joined: Thu Dec 11, 2014 8:53 am

Re: v6.45.1 [stable] is released!

Tue Jul 09, 2019 1:41 pm

Or set tunnel=yes for action=none policies. We will fix action=none policies in next release.

EDIT: actually this is not correct and addresses will change after the phase 1 recreation.
 
seb13
just joined
Posts: 3
Joined: Mon Sep 12, 2016 10:11 pm

Re: v6.45.1 [stable] is released!

Tue Jul 09, 2019 2:54 pm

Add the policy with action=none and no peer:
/ip ipsec policy
add action=none dst-address=10.11.1.0/24 src-address=0.0.0.0/0
Peer is displayed as "unknown" in Winbox, but that's a cosmetic issue.
Perfect! That works! I forgot to try via Terminal... Thank you!

Or set tunnel=yes for action=none policies. We will fix action=none policies in next release.
That's also working, if I use a "dummy" local peer. Otherwise it keeps changing the dst-address. Still, I'll prefer the first, more simple, solution! Thank you both!
 
powerek
just joined
Posts: 4
Joined: Sat Jun 21, 2014 12:49 pm

Re: v6.45.1 [stable] is released!

Tue Jul 09, 2019 11:52 pm

Does someone have a problem with mac telnet login via neighbours?

Won't login with any user and pass or without pass, nor admin..
I have the same problem.
I have too

Wysłane z mojego SM-G975F przy użyciu Tapatalka

 
micaelhenriques
just joined
Posts: 5
Joined: Thu Feb 28, 2019 2:10 pm

Re: v6.45.1 [stable] is released!

Wed Jul 10, 2019 1:48 pm

Same problem, after upgrade i was unable to login again on router via IP in winbox 3.19 :shock: :shock: :shock:
I need a solution for that...
 
User avatar
skylark
MikroTik Support
MikroTik Support
Posts: 106
Joined: Wed Feb 10, 2016 3:55 pm

Re: v6.45.1 [stable] is released!

Wed Jul 10, 2019 2:13 pm

Same problem, after upgrade i was unable to login again on router via IP in winbox 3.19 :shock: :shock: :shock:
I need a solution for that...
Try Tools > Clear Cache
 
micaelhenriques
just joined
Posts: 5
Joined: Thu Feb 28, 2019 2:10 pm

Re: v6.45.1 [stable] is released!

Wed Jul 10, 2019 2:23 pm

Same problem, after upgrade i was unable to login again on router via IP in winbox 3.19 :shock: :shock: :shock:
I need a solution for that...
Try Tools > Clear Cache
already have done that and the problem persistes.. its a Mini LTE Router .. and i m trying to connect via IP remotelly... and keep telling me wrong username or password
 
User avatar
baks
just joined
Posts: 14
Joined: Fri Jul 19, 2013 9:05 pm
Location: Ukraine

Re: v6.45.1 [stable] is released!

Wed Jul 10, 2019 3:44 pm

Hi Colleagues,

After reading the whole topic and testing using my own prod ;) ("CRS326-24G-2S+" < GRE over IKEv2 tunnel > "HAPac") site it is still unclear for Me which firewall configuration expected to be 'proper' since fixing CVE-2014-8160 in RoS 6.45.1

My observations after update from RoS 6.44.3 to RoS 6.45.1 are the following:
- IKEv2 based tunnel works as expected, nothing changes
- HAPac can up GRE tunnel to CRS326-24G-2S+ without any issues
- CRS326-24G-2S+ can't up GRE tunnel to HAPac
- Adding of only ONE of the suggested in this topic rule "/ip firewall filter add chain=input action=accept protocol=gre ipsec-policy=in,ipsec" or "/ip firewall raw add chain=prerouting action=notrack protocol=gre" for both ends doesn't help to bring up GRE tunnel from CRS326-24G-2S+ to HAPac
- Adding of BOTH of the mentioned rules in 'filter->input' and 'raw->prerouting' respectively helps to bring up GRE tunnel from CRS326-24G-2S+ to HAPac

According to viewtopic.php?f=21&t=149786&start=150#p737612 'filter->input' rule is obvious "MUST to HAVE" for allowing new incoming GRE connections since RoS 6.45.1.
What about 'raw->prerouting' rule suggested in viewtopic.php?f=21&t=149786&start=50#p737382 which also seems influences behavior of GRE in my setup?

Mikrotik guys and forum Gurus could you please provide neat answer on this matter?

Thank you!
I will try the temporal fix later when users are not working.
Temporary? Please read the topic once again, carefully. This version fixes a bug that allowed GRE to work even when your device was configured improperly. So you do not need to apply a temporary fix, but rather permanently fix your configuration.
RB435G+R52Hn+PSU24V2A+CustomIndoorCase
CRS125-24G-1S-RM
CRS326-24G-2S+
RB962UiGS-5HacT2HnT (HAPac)
 
sindy
Forum Guru
Forum Guru
Posts: 3814
Joined: Mon Dec 04, 2017 9:19 pm

Re: v6.45.1 [stable] is released!

Wed Jul 10, 2019 5:14 pm

Mikrotik guys and forum Gurus could you please provide neat answer on this matter?
It is not possible to say which is the "correct" way because the firewall rules form up an inter-dependent system:
  • if you have no firewall rules at all (which is by no means recommended, just to illustrate the case), any packet from anywhere, including the GRE ones, will be accepted, because the default handling in all filter chains is "accept";
  • if you have the default firewall rules for SOHO devices (hEX, hAP, RB2011, ...), there are two important rules in input chain:
    • action=accept connection-state=established,related,untracked
    • action=drop in-interface-list=!LAN
    The output chain in this default firewall setup is empty which means the Mikrotik itself can send anything anywhere.
    The default firewall setup follows the concept of a stateful firewall, which depends on existence of a connection tracking module in the firewall. When using a stateful firewall, you only have to deal in detail with the initial packet of each connection; if you accept it, a record describing the properties of the resulting connection is created in the connection tracking, so subsequent packets belonging to either direction of that connection are attributed with "connection-state=established", whereas packets related to that connection in some way (like upstream icmp packets informing about packet being dropped due to size) are attributed with "connection-state=related", so in both cases the first rule above accepts them without inspecting their other properties.
    Now if you use a rule in /ip firewall raw table, saying "action=untrack protocol=gre [in-interface[-list]=... src-address-[list]=...]", you tell the connection tracking to ignore packets matching the criteria, so in filter, they are attributed with "connection-state=untracked" and thus the first rule mentioned above accepts them. If you don't do this, the initial GRE packet coming from outside matches none of the three connection-states for which the first rule checks, so unless you place some action=accept rule for protocol=gre into /ip firewall filter table before the last one mentioned above (which is the other possibility suggested earlier in this topic), the first GRE packet coming from outside will be dropped by that last rule in input chain of filter and the GRE tunnel will not come up (and as no tracked connection will be created, all subsequent received GRE packets will be treated as first ones again). But if the local Mikrotik sends some payload packet to the GRE tunnel (it doesn't matter whether a locally-originated or a transit one), or if keepaliving is activated on the tunnel's configuration, the outgoing GRE packet encapsulating that payload one will create a tracked connection (because it is handled by the empty chain output of /ip firewall filter which accepts it), so a GRE packet in the opposite direction (with swapped src and dst IP addresses) should be accepted even without any of the two suggested rules in place. However, there used to be an issue in connection tracking, where instead of a single bi-directional connection, each direction of a GRE connection was treated as a separate tracked connection; I don't know whether this issue has been fixed in 6.45.1 or not. If not, you need one of the rules above even if the local side sends first.
  • yet another case is where a GRE "session" is established under control of come control protocol, like PPTP (where a TCP session is used for control communication and GRE is used for the actual transport of data). In this case, the GRE packets with corresponding source and destination address match the "connection-state=related" in the first rule above so it accepts them; but for this to happen, a process (usually called "helper") in the firewall, which analyses the control communication of the PPTP, has to be enabled so that it would tell the connection tracker what GRE connection to expect. To enable that process, you need to enable the pptp item in /ip firewall service-port
So if your firewall is different from the default SOHO one (e.g. because it has been kept unchanged from older versions of ROS where connection-state=untracked was not supported), you have to choose the right rule and put it to the right place in the chain. Same applies if GRE connections only transit through your Mikrotik between other devices - the filter rule suggested in this topic only help GRE tunnels running on the Mikrotik itself, you need a similar rule in chain=filter for transit GRE connections. On the other hand, the PPTP helper works also for transit connections.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
LeftyTs
Frequent Visitor
Frequent Visitor
Posts: 71
Joined: Thu Nov 03, 2016 2:39 am
Location: Athens, Greece
Contact:

Re: v6.45.1 [stable] is released!

Wed Jul 10, 2019 5:43 pm

Does someone have a problem with mac telnet login via neighbours?
Won't login with any user and pass or without pass, nor admin..
I have the same problem.
MAC telnet works perfect here
 
Iwanche
just joined
Posts: 3
Joined: Thu Mar 29, 2018 2:26 pm

Re: v6.45.1 [stable] is released!

Wed Jul 10, 2019 8:12 pm

Does someone have a problem with mac telnet login via neighbours?
Won't login with any user and pass or without pass, nor admin..
I have the same problem.
MAC telnet works perfect here
Good for you..

On device in bridge or station mode?
 
LeftyTs
Frequent Visitor
Frequent Visitor
Posts: 71
Joined: Thu Nov 03, 2016 2:39 am
Location: Athens, Greece
Contact:

Re: v6.45.1 [stable] is released!

Wed Jul 10, 2019 8:38 pm

On device in bridge or station mode?
I have used it in a unit with bridged ports (Ether/WiFi) and worked without issues.
 
danieltecnet
just joined
Posts: 9
Joined: Tue Jan 31, 2017 10:35 pm
Location: https://www.google.com.br/maps/@-4.9872 ... 128006,16z

Re: v6.45.1 [stable] is released!

Wed Jul 10, 2019 10:38 pm

good afternoon! here after update all my ipv6 has stopped! ospf v3 works by the mikrotik terminal I ping out via ip v6 but even with the local v6 pool and prefix ipv6 delegation on pppoe server my clients do not get prefixes anyone else with this problem after updating? I did this in 8 ccr and all stopped ipv6
 
ckleea
newbie
Posts: 47
Joined: Sun Apr 21, 2013 12:19 pm

Re: v6.45.1 [stable] is released!

Thu Jul 11, 2019 6:51 am

Upgraded RB4011 from 6.44.3 to 6.45.1 - no issues
Well, actually there is one - the bridge MAC address has changed so the network discovery on Windows must be done again. In my case the bridge MAC addr is the same as for eth7 interface. Interesting what it depends on...
Best
Bam

Here same issue on 3 Devices upgraded from 6.44.3 to 6.45.1.

In my case this cause two major problems :
1. Static DHCP offer of DHCP Server didn't work because of changed MAC -> Login to know IP Address didn't work anymore because get no or a dynamic address from DHCP server
2. The Bridge get the MAC from the WLAN Interface which cause major porblem's in CAPSMAN configuration. There was a lot of 'receive packet from same interface, may loop' messages in the CPASMAN log. The cap client interface's repeatedly connect / disconnect from the CAPSMAN -> WLAN dead

I fix this issue by set the Admin MAC of each bridge manualy.
In my case, it is due to CAPsMAN certificate issue and after I revoke the certificate, CAPsMAN works again in all AP devices.
 
Abdock
Member Candidate
Member Candidate
Posts: 251
Joined: Sun Sep 25, 2005 10:50 pm

Re: v6.45.1 [stable] is released!

Thu Jul 11, 2019 9:46 am

Issues we have noticed:
1. cannot create support file, router goes offline, and come back but needs to be rebooted.
2. ospf, crashes, reboot is only resort.

Thanks.
 
UMarcus
Frequent Visitor
Frequent Visitor
Posts: 91
Joined: Wed Jan 21, 2015 10:11 am
Location: Europe

Re: v6.45.1 [stable] is released!

Thu Jul 11, 2019 9:56 am

Upgraded RB4011 from 6.44.3 to 6.45.1 - no issues
Well, actually there is one - the bridge MAC address has changed so the network discovery on Windows must be done again. In my case the bridge MAC addr is the same as for eth7 interface. Interesting what it depends on...
Best
Bam

Good to know. At the moment i do not use certificates.

Here same issue on 3 Devices upgraded from 6.44.3 to 6.45.1.

In my case this cause two major problems :
1. Static DHCP offer of DHCP Server didn't work because of changed MAC -> Login to know IP Address didn't work anymore because get no or a dynamic address from DHCP server
2. The Bridge get the MAC from the WLAN Interface which cause major porblem's in CAPSMAN configuration. There was a lot of 'receive packet from same interface, may loop' messages in the CPASMAN log. The cap client interface's repeatedly connect / disconnect from the CAPSMAN -> WLAN dead

I fix this issue by set the Admin MAC of each bridge manualy.
In my case, it is due to CAPsMAN certificate issue and after I revoke the certificate, CAPsMAN works again in all AP devices.
Good to know. At the moment I do not use certificates.
 
buset1974
Frequent Visitor
Frequent Visitor
Posts: 50
Joined: Wed Sep 13, 2006 12:12 pm
Location: Jakarta

Re: v6.45.1 [stable] is released!

Thu Jul 11, 2019 10:04 am

joserudi - Please send supout file to support@mikrotik.com. Generate file while the problem is present and name at least single user which does not get rate-limit;
LeftyTs, Ulypka, gepelbaum, nostromog, CharlyBrown, xtrans - Please send supout file to support@mikrotik.com. Generate file while the problem is present;
mserge - Make sure that you use Winbox 3.19. If the problem persists, then generate a new supout file on your router after failed Winbox login attempt and send it to support@mikrotik.com;
owsugde - Is it possible that you are using a certificate verification feature which was introduced in this release? "ovpn - added "verify-server-certificate" parameter for OVPN client (CVE-2018-10066)"
dlausch - Sound like you have the same problem as we did with Winbox. Also new iOS MikroTik mobile application update will be released very soon;

Everyone - Everyone who is experiencing RADIUS related problems with authentication since v6.45, we will soon release 6.46beta version with potential fix for the problem;
Everyone - Long-term version will be released as soon as possible. There is no ETA since everyone will want version as stable as possible. We can not simply name date and time when the version will be released. It depends on test results.
CCR1036-8G-2S+ , having random reboot by watchdog after upgrade to 6.45.1.
I have sent the supout file

thx
dear mikrotik,

router still stable after downgraded to 6.44.3, routerboard firmware still using 6.45.1
please fix this issue.

thx
 
Ansy
Frequent Visitor
Frequent Visitor
Posts: 72
Joined: Mon Oct 17, 2011 1:32 pm
Location: Russia
Contact:

Re: v6.45.1 [stable] is released!

Thu Jul 11, 2019 11:43 am

I wonder why Mikrotik guys don't pin this instruction to every hAP lite (may be other cheap, low memory, smips) device:
  1. Don't expect too many features of it, especially memory hangry ones!
  2. Don't use bundled "Main package" RouterOS at all -- that files are too heavy for lite devices. Download only full "Extra packages" *.zip to your computer.
  3. Setup, configure and tune the device with only needed functions and DISABLE all unneeded packages (grey them off in System->Packages)
  4. Backup and download to computer your current config (binary and /export file=config.rsc too)!!!
  5. When upgrade first time, unpack and upload into Files ONLY enabled new *.npk from *.zip "Extra packages" (all used -- or you can loose some config, for example, wireless -- then you'll need to replay some parts from saved config.rsc in terminal)
  6. REBOOT (cross your fingers and pray ;)
After that your will have only neccessary packages set on your device, plenty (I hope) space for updates and the ability to do it automatically later.
Last edited by Ansy on Thu Jul 11, 2019 6:33 pm, edited 1 time in total.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5833
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.45.1 [stable] is released!

Thu Jul 11, 2019 11:57 am

Well that is mostly standard for every MikroTik device deployment and upgrade... except point #1 for the more powerful devices.
 
TimurA
Member Candidate
Member Candidate
Posts: 186
Joined: Sat Dec 15, 2018 6:13 am
Location: Tashkent
Contact:

Re: v6.45.1 [stable] is released!

Thu Jul 11, 2019 12:23 pm

6.45.1 works fine on hAP AC, hAP AC lite, RB932, RB952, wAP AC. RB4011 - everything works except 5ghz, Colleagues! fix 5ghz on RB4011 and i will be happy
Image
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 5934
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: v6.45.1 [stable] is released!

Thu Jul 11, 2019 1:20 pm

Anyone who had problems with OSPF (/routing ospf lsa print triggers busy loop) in this version please try 6.46beta9 if possible.
 
User avatar
baks
just joined
Posts: 14
Joined: Fri Jul 19, 2013 9:05 pm
Location: Ukraine

Re: v6.45.1 [stable] is released!

Thu Jul 11, 2019 3:34 pm

It is not possible to say which is the "correct" way because the firewall rules form up an inter-dependent system:
  • if you have no firewall rules at all (which is by no means recommended, just to illustrate the case), any packet from anywhere, including the GRE ones, will be accepted, because the default handling in all filter chains is "accept";
  • if you have the default firewall rules for SOHO devices (hEX, hAP, RB2011, ...), there are two important rules in input chain:
    • action=accept connection-state=established,related,untracked
    • action=drop in-interface-list=!LAN
    The output chain in this default firewall setup is empty which means the Mikrotik itself can send anything anywhere.
    The default firewall setup follows the concept of a stateful firewall, which depends on existence of a connection tracking module in the firewall. When using a stateful firewall, you only have to deal in detail with the initial packet of each connection; if you accept it, a record describing the properties of the resulting connection is created in the connection tracking, so subsequent packets belonging to either direction of that connection are attributed with "connection-state=established", whereas packets related to that connection in some way (like upstream icmp packets informing about packet being dropped due to size) are attributed with "connection-state=related", so in both cases the first rule above accepts them without inspecting their other properties.
    Now if you use a rule in /ip firewall raw table, saying "action=untrack protocol=gre [in-interface[-list]=... src-address-[list]=...]", you tell the connection tracking to ignore packets matching the criteria, so in filter, they are attributed with "connection-state=untracked" and thus the first rule mentioned above accepts them. If you don't do this, the initial GRE packet coming from outside matches none of the three connection-states for which the first rule checks, so unless you place some action=accept rule for protocol=gre into /ip firewall filter table before the last one mentioned above (which is the other possibility suggested earlier in this topic), the first GRE packet coming from outside will be dropped by that last rule in input chain of filter and the GRE tunnel will not come up (and as no tracked connection will be created, all subsequent received GRE packets will be treated as first ones again). But if the local Mikrotik sends some payload packet to the GRE tunnel (it doesn't matter whether a locally-originated or a transit one), or if keepaliving is activated on the tunnel's configuration, the outgoing GRE packet encapsulating that payload one will create a tracked connection (because it is handled by the empty chain output of /ip firewall filter which accepts it), so a GRE packet in the opposite direction (with swapped src and dst IP addresses) should be accepted even without any of the two suggested rules in place. However, there used to be an issue in connection tracking, where instead of a single bi-directional connection, each direction of a GRE connection was treated as a separate tracked connection; I don't know whether this issue has been fixed in 6.45.1 or not. If not, you need one of the rules above even if the local side sends first.
sindy,

Thank you for detailed explanation.

You was right about absence of 'untracked' connection type in state-full allow rule, now I have got why BOTH of rules in 'filter->input' and 'raw->prerouting' was fixing my setup ;)

But one unclear fact still present: If I left only "/ip firewall filter add chain=input action=accept protocol=gre ipsec-policy=in,ipsec" rule, GRE tunnel still not start UP until I disable ''/ip firewall filter add chain=input action=drop connection-state=invalid" which is placed as the FIRST rule of 'filter->input' chain.
So it seems in my setup RoS marked the very first incoming GRE packet with "connection-state=invalid", and seems this happens before packet reach "...action=accept protocol=gre..." rule.(That is why "...action=untrack protocol=gre.." helped packet to reach "...action=accept protocol=gre..." rule) o_0
RB435G+R52Hn+PSU24V2A+CustomIndoorCase
CRS125-24G-1S-RM
CRS326-24G-2S+
RB962UiGS-5HacT2HnT (HAPac)
 
User avatar
osc86
Frequent Visitor
Frequent Visitor
Posts: 50
Joined: Wed Aug 09, 2017 1:15 pm

Re: v6.45.1 [stable] is released!

Thu Jul 11, 2019 3:49 pm

@baks this is why the drop invalid rule is placed AFTER the accept established,related,untracked rule.
1    ;;; defconf: accept established,related,untracked
      chain=input action=accept connection-state=established,related,untracked log=no log-prefix="" 

 2    ;;; defconf: drop invalid
      chain=input action=drop connection-state=invalid log=no log-prefix=""
CCR1009-7G-1C-1S+ ROS6.45.2
 
DanchoDimitrov
just joined
Posts: 7
Joined: Wed Jul 03, 2019 10:10 pm
Location: Bulgaria

Re: v6.45.1 [stable] is released!

Thu Jul 11, 2019 4:02 pm

6.45.1 works fine on hAP AC, hAP AC lite, RB932, RB952, wAP AC. RB4011 - everything works except 5ghz, Colleagues! fix 5ghz on RB4011 and i will be happy
Hey, a few quick questions.
Is that the hAP AC2 version?
What exactly is the issue you have with wifi? Mine is huge ping, low throughput, like 10mbit in just the one direction.
Im trying to get more info. So far ive noticed that the previous stable is fine, the current long term is fine too.
Can I have your wifi settings and compare? Thanks.
hAP AC^2
 
TimurA
Member Candidate
Member Candidate
Posts: 186
Joined: Sat Dec 15, 2018 6:13 am
Location: Tashkent
Contact:

Re: v6.45.1 [stable] is released!

Thu Jul 11, 2019 4:11 pm

6.45.1 works fine on hAP AC, hAP AC lite, RB932, RB952, wAP AC. RB4011 - everything works except 5ghz, Colleagues! fix 5ghz on RB4011 and i will be happy
Hey, a few quick questions.
Is that the hAP AC2 version?
What exactly is the issue you have with wifi? Mine is huge ping, low throughput, like 10mbit in just the one direction.
Im trying to get more info. So far ive noticed that the previous stable is fine, the current long term is fine too.
Can I have your wifi settings and compare? Thanks.
Hi, I have a hAP AC (RB962), the device just fine. There were no problems with him.

Problems with RB4011, read the thread: viewtopic.php?f=3&t=142298&start=100
Image
 
sindy
Forum Guru
Forum Guru
Posts: 3814
Joined: Mon Dec 04, 2017 9:19 pm

Re: v6.45.1 [stable] is released!

Thu Jul 11, 2019 5:01 pm

@baks this is why the drop invalid rule is placed AFTER the accept established,related,untracked rule.
1    ;;; defconf: accept established,related,untracked
      chain=input action=accept connection-state=established,related,untracked log=no log-prefix="" 

 2    ;;; defconf: drop invalid
      chain=input action=drop connection-state=invalid log=no log-prefix=""
Well... it does explain the behaviour, but I can see no reason why the first ever incoming GRE packet from a given IP address to another given IP address should be attributed with "connection-state=invalid", it should bear a normal "connection-state=new" attribute. For me, connection-state=invalid is for plain TCP packets coming after a packet with FIN flag has already been seen and stuff alike, so to me it looks like another bug.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
mszru
just joined
Posts: 18
Joined: Wed Aug 10, 2016 10:42 am

Re: v6.45.1 [stable] is released!

Thu Jul 11, 2019 5:12 pm

As per my observation 6.45.1 is more resource hungry than the long-term 6.44.5 on hAP ac2. The router has a default configuration and not connected to WAN link. I would say that 5-10% of CPU utilization for a device in idle state is quite high. When running at 6.44.5, the CPU utilization is 1-4%. Another interesting fact is at 6.44.3 CPU utilization of a similar device (another hAP ac2 unit) in idle state rarely jumps over 2%.

6.45.1
2019-07-11_hAPac2_6.45.1.png

6.44.5
2019-07-11_hAPac2_6.44.5.png
You do not have the required permissions to view the files attached to this post.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5833
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.45.1 [stable] is released!

Thu Jul 11, 2019 5:41 pm

I can see no reason why the first ever incoming GRE packet from a given IP address to another given IP address should be attributed with "connection-state=invalid", it should bear a normal "connection-state=new" attribute. For me, connection-state=invalid is for plain TCP packets coming after a packet with FIN flag has already been seen and stuff alike, so to me it looks like another bug.
This change is a bit of a mystery. You would think that there usually is some background traffic on networks, and when a GRE tunnel is setup there will usually be some outgoing packet that creates a connection and then the incoming packets are accepted as "established" on that connection. It would probably be tough to setup a test setup where there is really no outgoing traffic and all incoming is dropped.

However, I think that this change (likely the result of some misunderstanding) has now introduced the situation where a registered GRE "connection" does not accept incoming traffic until that has been accepted at least once. I.e. the outgoing GRE traffic does not setup a fully valid connection, there first has to be incoming accepted traffic as well. Incoming traffic on a "half open" GRE "connection" (that has only seen outgoing traffic) is apparently now labeled as "invalid".

Like you, I do not see why this would be done. I expect someone has come up with a test case where traffic was unexpectedly allowed (maybe under the threat of a CVE) and changes were made to close that "leak" without fully researching what was happening and if that indeed is a leak. Usually cases where connectionless traffic "meets in the middle" (both sides sending traffic to eachother, e.g. ISAKMP) are accepted as "established" without further matching.
 
User avatar
osc86
Frequent Visitor
Frequent Visitor
Posts: 50
Joined: Wed Aug 09, 2017 1:15 pm

Re: v6.45.1 [stable] is released!

Thu Jul 11, 2019 6:00 pm

Unlike TCP, GRE is completely stateless, there's no way the router knows if an incoming GRE packet is new, related, established or something else. On both endpoints of the tunnel you need to have these firewall rules set up.
Output chain's default action is accept, so you only have to do it for input chain.
CCR1009-7G-1C-1S+ ROS6.45.2
 
pe1chl
Forum Guru
Forum Guru
Posts: 5833
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.45.1 [stable] is released!

Thu Jul 11, 2019 6:45 pm

Unlike TCP, GRE is completely stateless, there's no way the router knows if an incoming GRE packet is new, related, established or something else.
This is of course incorrect. Yes, it is stateless, but no, the router can know if an incoming GRE packet is "established" when it has previously sent a GRE packet to the same address.
This is similar to the handling of UDP. While UDP is stateless, replies on outgoing UDP requests (like DNS) are still accepted as "established".

This is how GRE was handled in versions before 6.45. I have several routers with input rules that first accept established/related and then e.g. GRE with IPsec policy in:ipsec, and
that rule has only a few matches. The bulk is accepted by the established/related rule.
I have not yet tested what happens on a router running 6.45.1 in this regard. I expect my config will still work, as it already had the accept rule for GRE/IPsec. Configs without
that rule (i.e. default settings for the firewall) would now fail.
 
tonymobile
newbie
Posts: 37
Joined: Mon Jul 07, 2008 2:10 am

Re: v6.45.1 [stable] is released!

Thu Jul 11, 2019 7:52 pm

After upgrade some BSU for test, i have problem with mac authentication on my centralized radius.

I'm come back to 6.44.3

Mikrotik team, please fix bug.
 
User avatar
baks
just joined
Posts: 14
Joined: Fri Jul 19, 2013 9:05 pm
Location: Ukraine

Re: v6.45.1 [stable] is released!

Thu Jul 11, 2019 8:01 pm

I agree with sindy and pe1chl. To my mind "IP/Firewall/Connection tracking" in RoS is equivalent of RHEL 'conntrack-tool' which operate with raw network packets that get into firewall processing and try to bind each packet to 'new/established/related/untracked' connection state in terms of 'Connection tracking' logic even if the protocol itself not support any 'connections' or similar states.

For now situation with 6.45.1 looks like the following( based on '/system default-configuration print' from HAPac):
- Default ACCEPT rues configured in Filter->Input' chain
                     
...
                     /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"
...
- As suggested by strods (MikroTik Support) in viewtopic.php?f=21&t=149786&start=100#p737462 add ADDITIONAL ACCEPT rule AFTER default rules mentioned above
 
filter add chain=input action=accept protocol=gre ipsec-policy=in,ipsec


- Very first incoming GRE packet will be dropped by "chain=input action=drop connection-state=invalid" and will never reach ADDITIONAL ACCEPT rule, GRE tunnel is DOWN
- As workaround it is possible to skip 'Connection tracking' processing by adding 'raw add chain=prerouting action=notrack protocol=gre'. In such a case very first incoming GRE packet will be accepted by default rule 'chain=input action=accept connection-state=established,related,untracked' however it will not reach ADDITIONAL ACCEPT rule either, GRE tunnel is UP

In my initial setup I have no rule matching 'untracked', so packet finally was accepted by ADDITIONAL ACCEPT rule but this fact not changes situation much.

The main question now why very first GRE packet is marked as 'invalid' by 'Connection tracking' mechanism? ( I suppose that this issue occurred since RoS 6.45.1, however hasn't managed to perform tests with downgrade so far)
RB435G+R52Hn+PSU24V2A+CustomIndoorCase
CRS125-24G-1S-RM
CRS326-24G-2S+
RB962UiGS-5HacT2HnT (HAPac)
 
itmethod
newbie
Posts: 28
Joined: Tue Feb 18, 2014 8:44 pm

Re: v6.45.1 [stable] is released!

Thu Jul 11, 2019 8:58 pm

Has anyone solved these password issues as yet to access the routers ?

We have one remote router which is in a different country. We have a STTP VPN direct to the router which is showing as connected but the username and password are not working - It was working fine before it was upgraded.

It has or at least had a 16 digit random password on it with a custom username.

Tried using the username without a password
Tried the admin account with no password
Tried asking a staff member to reboot it

Still no access and we're not really sure what to try next - Any help much appreciated
I have the same problem, see post #55. I have not found a workaround.

Sent from my Pixel 3 using Tapatalk
Thanks for the response.

Good to know it works on the same network at least - we can get access to a local machine to get on it and downgrade again so we have access, giving us some time to do some testing in the office.

If you do manage to work this out please do let me know - i will of course do the same if we can find a solution.
Downgrading it doesn't work for me. but I'm able to login with winbox on local network. not from remote network. even when no vpn is setup on the router in question. this is on x86. it's like there is a timeout and and it's coming back with the wrong username or password.


Here's current config.

 
  MMM      MMM       KKK                          TTTTTTTTTTT      KKK
  MMMM    MMMM       KKK                          TTTTTTTTTTT      KKK
  MMM MMMM MMM  III  KKK  KKK  RRRRRR     OOOOOO      TTT     III  KKK  KKK
  MMM  MM  MMM  III  KKKKK     RRR  RRR  OOO  OOO     TTT     III  KKKKK
  MMM      MMM  III  KKK KKK   RRRRRR    OOO  OOO     TTT     III  KKK KKK
  MMM      MMM  III  KKK  KKK  RRR  RRR   OOOOOO      TTT     III  KKK  KKK

  MikroTik RouterOS 6.44.3 (c) 1999-2019       http://www.mikrotik.com/

[?]             Gives the list of available commands
command [?]     Gives help on the command and list of arguments

[Tab]           Completes the command/word. If the input is ambiguous,
                a second [Tab] gives possible options

/               Move up to base level
..              Move up one level
/command        Use command at the base level
jul/11/2019 17:40:16 system,error,critical login failure for user blindrain from 1
0.8.0.3 via winbox
[blindrain@vSEP] > /export compact     
# jul/11/2019 17:49:42 by RouterOS 6.44.3
# software id = 5HM8-QX9C
#
#
#
/interface bridge
add name=lo
/interface ethernet
set [ find default-name=ether1 ] advertise=\
    10M-half,10M-full,100M-half,100M-full,1000M-half,1000M-full
set [ find default-name=ether2 ] advertise=\
    10M-half,10M-full,100M-half,100M-full,1000M-half,1000M-full
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/tool user-manager customer
set admin access=\
    own-routers,own-users,own-profiles,own-limits,config-payment-gw
/user group
add name=api policy="local,ssh,read,write,test,sensitive,api,!telnet,!ftp,!reboo\
    t,!policy,!winbox,!password,!web,!sniff,!romon,!dude,!tikapp"
add name=ssh policy="ssh,!local,!telnet,!ftp,!reboot,!read,!write,!policy,!test,\
    !winbox,!password,!web,!sniff,!sensitive,!api,!romon,!dude,!tikapp"
/ip address
add address=192.168.253.74 interface=lo network=192.168.253.74
/ip cloud
set update-time=no
/ip dhcp-client
add dhcp-options=hostname,clientid disabled=no interface=ether1
add dhcp-options=hostname,clientid disabled=no interface=ether2
/system identity
set name=vSEP
/system lcd
set contrast=0 enabled=no port=parallel type=24x4
/system lcd page
set time disabled=yes display-time=5s
set resources disabled=yes display-time=5s
set uptime disabled=yes display-time=5s
set packets disabled=yes display-time=5s
set bits disabled=yes display-time=5s
set version disabled=yes display-time=5s
set identity disabled=yes display-time=5s

set lo disabled=yes display-time=5s
set ether1 disabled=yes display-time=5s
set ether2 disabled=yes display-time=5s
/system package update
set channel=long-term
/system scheduler
add interval=1d name=Upgrade on-event=":if ([/system clock get date]~\"/25/\") d\
    o={\r\
    \n#place instructions here\r\
    \n /system package update install\r\
    \n};" policy=\
    ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon \
    start-date=jul/11/2019 start-time=06:12:16
/tool user-manager database
set db-path=user-manager
[blindrain@vSEP] > 
 
TimurA
Member Candidate
Member Candidate
Posts: 186
Joined: Sat Dec 15, 2018 6:13 am
Location: Tashkent
Contact:

Re: v6.45.1 [stable] is released!

Thu Jul 11, 2019 9:18 pm

- Very first incoming GRE packet will be dropped by "chain=input action=drop connection-state=invalid" and will never reach ADDITIONAL ACCEPT rule, GRE tunnel is DOWN
- As workaround it is possible to skip 'Connection tracking' processing by adding 'raw add chain=prerouting action=notrack protocol=gre'. In such a case very first incoming GRE packet will be accepted by default rule 'chain=input action=accept connection-state=established,related,untracked' however it will not reach ADDITIONAL ACCEPT rule either, GRE tunnel is UP

In my initial setup I have no rule matching 'untracked', so packet finally was accepted by ADDITIONAL ACCEPT rule but this fact not changes situation much.

The main question now why very first GRE packet is marked as 'invalid' by 'Connection tracking' mechanism? ( I suppose that this issue occurred since RoS 6.45.1, however hasn't managed to perform tests with downgrade so far)
/ip firewall raw add action=notrack chain=prerouting in-interface-list=internet protocol=gre
/ip firewall filter add action=accept chain=input connection-state=established,related,new,untracked in-interface-list=internet protocol=gre

if you have deny rules in raw table in end, than put after notrack action:

/ip firewall raw add action=accept chain=prerouting in-interface-list=internet protocol=gre
Image
 
kraken
Trainer
Trainer
Posts: 2
Joined: Wed Dec 05, 2007 8:03 pm

Re: v6.45.1 [stable] is released!

Fri Jul 12, 2019 2:27 am

Just upgraded my Dude server and a few devices to 6.45.1, all of the 6.45.1 devices don't get any information of SNMP V3 service and security private, MD5 DES settings. After, I upgrade only devices to beta 6.46beta9, but problem persists.
I downgrade only devices to 6.44.3 and works fine SNMP again.

Is there an issue with SNMP V3 Security private MD5 DES in 6.45.1 and newest ?
You do not have the required permissions to view the files attached to this post.
 
User avatar
Xymox
Member
Member
Posts: 387
Joined: Thu Jan 21, 2010 5:04 pm
Location: Phoenix, Arizona US
Contact:

Re: v6.45.1 [stable] is released!

Fri Jul 12, 2019 4:34 am

Just a FYI...

Going to 6.45.1 on a RB4011iGS+5HacQ2HnD-IN and then dropping 6.44.3 on and downgrading because a list iist of issues caused the WLAN interfaces to be scrambled. Lost all settings and even lost WLAN 1 replaced with a greyed out WLAN 3 with the WLAN 1 chip.

The newly created WLAN 3 and the still present WLAN 2, lost bridge entires leaving "unknown" behind.

So even going back to 6.44.3 did not fix everything and 6.45.1 scrambled settings.

Clearly, IMHO, 6.45.1 is a RC level, and has a list of serious issues. It should clearly not be a "stable" release..
 
User avatar
Xymox
Member
Member
Posts: 387
Joined: Thu Jan 21, 2010 5:04 pm
Location: Phoenix, Arizona US
Contact:

Re: v6.45.1 [stable] is released!

Fri Jul 12, 2019 7:55 pm

( s i g h )

So I had a CCR1036-8G-2S+ that I am using as a beta as my clients all have these in high end homes. I had it on 6.45.1 and it *SEEMED* fine. I decided to move it to 6.46rc6 because 6.45.1 seemed unstable and I was hoping some issues were addressed in the RC.. Again, everything *seemed* fine..

Today I decided to remove a port from a bridge. The router lost all connectivity immd. No port worked.

I rebooted. It would not boot, it hung for a long time.

I rebooted again and was hooked up RS232 and used the boot menu to switch back to my 6.44.3 partition. Everything came right back up. I copied the 44.3 to the bad partition and booted back into that.

So. FYI. 6.46RC6&9 also seem unstable with maybe the same issues from 6.45.1

ALWAYS work with partitions as backup. ALWAYS do a backup and a export compact and drag both files off the router before you upgrade stables or RCs.
 
RhoAius
just joined
Posts: 1
Joined: Fri Jul 12, 2019 10:47 pm

Re: v6.45.1 [stable] is released!

Fri Jul 12, 2019 10:59 pm

Regarding protocol 47.
Tested on CHR 6.45.1 (stable) with no default configuration.
Added the folowing 3 filters:

Code: Select all

/ip firewall filter
add action=passthrough chain=input connection-state=invalid protocol=gre
add action=passthrough chain=input connection-state=new protocol=gre
add action=passthrough chain=input connection-state=\
established,related,untracked protocol=gre
Sending gre packets to this chr instance behaved as expected. There were hits on the connection-state=new (2nd filter rule)
Disabling pptp helper with /ip firewall service-port set pptp disabled=yes
Will cause the first filter rule to get all the hits (connection-state=invalid)
Packets were generated by a eoIP tunnel from another chr instance, so there seems to be a bug in witch all protocol 47 packets are treated as invalid if pptp helper is disabled.
Counter-intuitive if you actually want to use gre tunnel or eoip and no pptp.
 
aliashell
just joined
Posts: 2
Joined: Fri Feb 15, 2019 6:41 pm

Re: v6.45.1 [stable] is released!

Fri Jul 12, 2019 11:18 pm

Hi, could someone help me for a big issue
after updating my hap lite to 6.45.1
when i use winbox (even mobile app) the cpu prosses is 100% some times kick me out and some times i should wait for mins
the prosses is like this
CPU0 100%
spi 30 to 40%
management 40 t0 50%
is there any way to resolve it without downgrading.


for attention i used netinstall for two times and still nothing happened.
Image
 
mhugo
newbie
Posts: 49
Joined: Mon Sep 19, 2005 11:48 am

Re: v6.45.1 [stable] is released!

Sat Jul 13, 2019 12:33 am

Lots of wierdness in this release on 317s.

Working OSPF stops working - neighbour is not seen from 317 but adjacent 1016 sees ospf neighbor.

Romon stops working.

Downgrade to 6.44.5 works but that breaks some of the SFPs with autoneg that was broken until 6.45 in 317s and early 6.42.x with old autoneg where all works has security bugs.

Ive been using Mikrotik for a long time and these last releases has been devastating quality wise.

Dont change things in the middle of a long-term branch. Right now we have a production network caught between bad releases.

This has been discussed with mikrotik for weeks - they have access to sample switches and no response and still they keep pushing bad releases.

I just halted my order of 30 317s. Not that I think Mikrotik will notice, but this is unacceptable.
 
radionerd
just joined
Posts: 3
Joined: Sun Feb 24, 2019 2:46 am

Re: v6.45.1 [stable] is released!

Sat Jul 13, 2019 7:35 am

I have a possible bug v6.45.1
Consentrator with L2TP/IPSEC clients
On IPSEC Installed SAs tab, I flush SAs and they don't repopulate until reboot.

The IPSEC Policies tab all clients show PH2 State is "no phase2"

Reboot Consentrator and clients connect normally
LOG
 echo: ipsec,error phase1 negotiation failed due to send error
I have updated about 20 remote clients and several Consentrators without any other unreported problems.
 
User avatar
Xymox
Member
Member
Posts: 387
Joined: Thu Jan 21, 2010 5:04 pm
Location: Phoenix, Arizona US
Contact:

Re: v6.45.1 [stable] is released!

Sat Jul 13, 2019 8:30 am

I have posted some pretty negative posts in this thread about 6.45.1.. So.. I have run across something good and I thought I would pass it along..

Well.. Sorta good..

I netinstalled a CCR1036 on 6.44.3 which was the last stable I knew worked for sure in all the things I do. I then restored a backup I made from before this 6.45.1 mess.

I then pkg updated from WInbox to 6.46beta9... This has gone flawlessly. So far I have no issues, but, I am limited in what I am doing with it.

Still this was good news and I wanted to post it.

Im not sure what the official recommendation is from Mikrotik on 6.45.1, is it best to just skip it and go direct to 6.46beta9 ? Or is a 6.45.2 almost here ?
 
bbs2web
Member Candidate
Member Candidate
Posts: 198
Joined: Sun Apr 22, 2012 6:25 pm
Location: Johannesburg, South Africa
Contact:

Re: v6.45.1 [stable] is released!

Sat Jul 13, 2019 3:28 pm

Could someone else please check if routing crashes when viewing OSPF LSAs via Winbox or running '/routing ospf lsa print' via CLI?
 
chiwou7698
just joined
Posts: 1
Joined: Sat Jul 13, 2019 9:38 pm

Re: v6.45.1 [stable] is released!

Sat Jul 13, 2019 9:43 pm

for me, this release completely bricked my hex
even netinstall didn't work

had to install the long term release, now it works again
 
lrossouw
just joined
Posts: 6
Joined: Fri Feb 08, 2013 4:44 pm
Location: Cape Town, South Africa

Re: v6.45.1 [stable] is released!

Sun Jul 14, 2019 10:23 pm

Could someone else please check if routing crashes when viewing OSPF LSAs via Winbox or running '/routing ospf lsa print' via CLI?
It seems this command is broken on 6.45.1
>/routing ospf lsa print 
AREA                                                                                                                                    TYPE         ID             ORIGINATOR     SEQUENCE-NUMBER        AGE
action timed out - try again, if error continues contact MikroTik support and send a supout file (13)
Seen this issue on multiple devices. Also LSA table on Winbox shows only a subset of the true list.
 
lrossouw
just joined
Posts: 6
Joined: Fri Feb 08, 2013 4:44 pm
Location: Cape Town, South Africa

Re: v6.45.1 [stable] is released!

Sun Jul 14, 2019 10:45 pm

Anyone who had problems with OSPF (/routing ospf lsa print triggers busy loop) in this version please try 6.46beta9 if possible.
Will try and report back.
 
stefki
newbie
Posts: 32
Joined: Mon Aug 29, 2016 2:13 pm

Re: v6.45.1 [stable] is released!

Mon Jul 15, 2019 11:40 am

I have problem with 6.45.1 version. I can't login via api anymore.

It says "login failure"

This is the code which I am using from php
<?php
use PEAR2\Net\RouterOS;

require_once 'PEAR2/Autoload.php';

try {
    $client = new RouterOS\Client('1.1.9.3', 'admin', 'xxx');
} catch (Exception $e) {
    die('Unable to connect to the router.');
    //Inspect $e if you want to know details about the failure.
}
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 5934
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: v6.45.1 [stable] is released!

Mon Jul 15, 2019 3:05 pm

 
stefki
newbie
Posts: 32
Joined: Mon Aug 29, 2016 2:13 pm

Re: v6.45.1 [stable] is released!

Mon Jul 15, 2019 3:57 pm

I am not very experienced in php , could someone show me example how to modify the code ?
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 24217
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

Re: v6.45.1 [stable] is released!

Mon Jul 15, 2019 3:58 pm

If you are not good in PHP, I suggest to find somebody who is. API programming is not a simple thing to do.
No answer to your question? How to write posts
 
stefki
newbie
Posts: 32
Joined: Mon Aug 29, 2016 2:13 pm

Re: v6.45.1 [stable] is released!

Mon Jul 15, 2019 4:04 pm

Yes, I am using this library PEAR2\Net\RouterOS, I have to contact the author , and tell him to update the api.
 
fouinix
just joined
Posts: 4
Joined: Wed Feb 10, 2016 10:13 am

Re: v6.45.1 [stable] is released!

Mon Jul 15, 2019 4:09 pm

Hi,
I confirm there is something weird with 5Ghz on HAP ac2. My transfers seems limited to ~20Mb/s with http, and only http. Even 2.4Ghz where faster.
I done several tests, like speedtest, nperf, I was able to reach ~200Mbits/s. I tried iperf and I was able to go up to 100Mb/s, same with SCP transfer. And when I go back to http transfer I always be limited at ~20Mb/s.
I downgrade to 6.44.5 and everything go fine, I can reach ~200Mb/s with http.
I hope you will solve this issue :)
 
vohr56
just joined
Posts: 3
Joined: Mon Jul 15, 2019 4:51 pm

Re: v6.45.1 [stable] is released!

Mon Jul 15, 2019 4:59 pm

Same problem with mac-telnet login from RouterBoard here.

Tested:
RB2011 with v6.45.1 stable - login via Winbox mac address -> OK;
RB2011 with v6.45.1 stable - login via another RB2011 v6.43.14 stable via mac-telnet - ERROR: "Login failed, incorrect username or password";
RB2011 with v6.45.1 stable - login via another RB2011 v6.45.1 stable via mac-telnet - ERROR: "Login failed, incorrect username or password".

Both RBs was reseted after upgrade and with no default configuration.
 
nubip
just joined
Posts: 4
Joined: Fri Jul 01, 2016 2:29 pm

Re: v6.45.1 [stable] is released!

Mon Jul 15, 2019 5:26 pm

Another user affected by de issue with RADIUS (User Manager Package). It´s works normally (client authorizations) some time 5-6 days until it stop working, and pppoe clients receive "radius not responding, time out". If the RB is restarted, the RADIUS works again. Coming back to 6.44.3 as soon as possible.
 
powerek
just joined
Posts: 4
Joined: Sat Jun 21, 2014 12:49 pm

Re: v6.45.1 [stable] is released!

Mon Jul 15, 2019 11:20 pm

Another user affected by de issue with RADIUS (User Manager Package). It´s works normally (client authorizations) some time 5-6 days until it stop working, and pppoe clients receive "radius not responding, time out". If the RB is restarted, the RADIUS works again. Coming back to 6.44.3 as soon as possible.
I have this problem too

Wysłane z mojego SM-G975F przy użyciu Tapatalka

 
asghar
just joined
Posts: 2
Joined: Sun Aug 26, 2018 9:25 am
Location: Herat

Re: v6.45.1 [stable] is released!

Tue Jul 16, 2019 7:04 am

Same problem with mac-telnet login from RouterBoard here.

Tested:
RB2011 with v6.45.1 stable - login via Winbox mac address -> OK;
RB2011 with v6.45.1 stable - login via another RB2011 v6.43.14 stable via mac-telnet - ERROR: "Login failed, incorrect username or password";
RB2011 with v6.45.1 stable - login via another RB2011 v6.45.1 stable via mac-telnet - ERROR: "Login failed, incorrect username or password".

Both RBs was reseted after upgrade and with no default configuration.
I have the same problem. did you find a solution??
 
spacemind
Member Candidate
Member Candidate
Posts: 111
Joined: Mon Jul 07, 2008 8:33 pm

Re: v6.45.1 [stable] is released!

Tue Jul 16, 2019 7:30 am

Upgrade to 6.45.1 OK, but after install UPS package (same version) winbox became unresponsive. Files box is empty, menus not opening, unable to do nothing. SSH very very slow and unresponsive too.

Hex S device
 
nubip
just joined
Posts: 4
Joined: Fri Jul 01, 2016 2:29 pm

Re: v6.45.1 [stable] is released!

Tue Jul 16, 2019 10:35 am

How about downgrade only the user manager package to 6.44.3 and mantain the main package in 6.45.1, it will work ¿? (only by the circunstances, and supposing that the issue is in this module).
 
mkx
Forum Guru
Forum Guru
Posts: 2985
Joined: Thu Mar 03, 2016 10:23 pm

Re: v6.45.1 [stable] is released!

Tue Jul 16, 2019 10:43 am

All packages have to be the same version (and system package leads the game).
BR,
Metod
 
User avatar
baks
just joined
Posts: 14
Joined: Fri Jul 19, 2013 9:05 pm
Location: Ukraine

Re: v6.45.1 [stable] is released!

Tue Jul 16, 2019 10:50 am

Regarding protocol 47.
Tested on CHR 6.45.1 (stable) with no default configuration.
Added the folowing 3 filters:

Code: Select all

/ip firewall filter
add action=passthrough chain=input connection-state=invalid protocol=gre
add action=passthrough chain=input connection-state=new protocol=gre
add action=passthrough chain=input connection-state=\
established,related,untracked protocol=gre
Sending gre packets to this chr instance behaved as expected. There were hits on the connection-state=new (2nd filter rule)
Disabling pptp helper with /ip firewall service-port set pptp disabled=yes
Will cause the first filter rule to get all the hits (connection-state=invalid)
Packets were generated by a eoIP tunnel from another chr instance, so there seems to be a bug in witch all protocol 47 packets are treated as invalid if pptp helper is disabled.
Counter-intuitive if you actually want to use gre tunnel or eoip and no pptp.
Hi All,

Mikrotik has confirmed this behaviour of 'Connection tracking' tool against GRE traffic as bug in support ticket 2019071222004555

> Re: [Ticket#2019071222004555] GRE configuration inconsistency in RoS 6.45.1
> On Mon, 15 Jul 2019 at 12:32, Arturs C. [MikroTik Support] <support@mikrotik.com> wrote:
> Hello,
> Thank you for reporting this. Yes, there is an issue in RouterOS v6.45.1. We will look forward to fixing it in upcoming RouterOS versions.
> Best regards,
> Arturs C.
RB435G+R52Hn+PSU24V2A+CustomIndoorCase
CRS125-24G-1S-RM
CRS326-24G-2S+
RB962UiGS-5HacT2HnT (HAPac)
 
bda
Member Candidate
Member Candidate
Posts: 126
Joined: Fri Sep 03, 2010 11:07 am
Location: Russia,Moscow

Re: v6.45.1 [stable] is released!

Tue Jul 16, 2019 11:34 am

Regarding protocol 47.
Tested on CHR 6.45.1 (stable) with no default configuration.
Added the folowing 3 filters:

Code: Select all

/ip firewall filter
add action=passthrough chain=input connection-state=invalid protocol=gre
add action=passthrough chain=input connection-state=new protocol=gre
add action=passthrough chain=input connection-state=\
established,related,untracked protocol=gre
Sending gre packets to this chr instance behaved as expected. There were hits on the connection-state=new (2nd filter rule)
Disabling pptp helper with /ip firewall service-port set pptp disabled=yes
Will cause the first filter rule to get all the hits (connection-state=invalid)
Packets were generated by a eoIP tunnel from another chr instance, so there seems to be a bug in witch all protocol 47 packets are treated as invalid if pptp helper is disabled.
Counter-intuitive if you actually want to use gre tunnel or eoip and no pptp.
Hi All,

Mikrotik has confirmed this behaviour of 'Connection tracking' tool against GRE traffic as bug in support ticket 2019071222004555

> Re: [Ticket#2019071222004555] GRE configuration inconsistency in RoS 6.45.1
> On Mon, 15 Jul 2019 at 12:32, Arturs C. [MikroTik Support] <support@mikrotik.com> wrote:
> Hello,
> Thank you for reporting this. Yes, there is an issue in RouterOS v6.45.1. We will look forward to fixing it in upcoming RouterOS versions.
> Best regards,
> Arturs C.
Great! Very good news!!! Waiting for a bugfix
God bless UNIX!
 
tom65
just joined
Posts: 3
Joined: Mon Mar 18, 2019 8:24 pm
Location: South Africa

Re: v6.45.1 [stable] is released!

Tue Jul 16, 2019 3:29 pm

Upgraded to 6.45.1 on LHG LTE Kit.
Email send fails with Auth Fail.
Used to work on 6.44.3
Would you believe V4 is still around!!
 
User avatar
iperezandres
newbie
Posts: 42
Joined: Mon Feb 13, 2017 1:17 pm
Location: Madrid
Contact:

Re: v6.45.1 [stable] is released!

Tue Jul 16, 2019 5:41 pm

The first time I updated a RB951 to 6.45.1, I started receiving the error of invalid user and password. I somehow managed to access it via web access, downgraded to 6.44.3, and everything started working again.

Then I tried again, updated the RB951 to 6.45.1 and winbox to 3.19. Everything seamed ok, but after 24 hours, I started receiving the same error of invalid user and password, but this time both from winbox and web access.

I cannot access the device, although it seams to be working fine (except for the remote access detail).

Any solution?
 
User avatar
CyB3RMX
Member Candidate
Member Candidate
Posts: 135
Joined: Thu May 26, 2011 7:08 am

Re: v6.45.1 [stable] is released!

Tue Jul 16, 2019 7:31 pm

I found a bug in this version. I have a Basebox 5 and it has a radius enabled PPPoE Server, evertyhing there works fine, but when the user connects, it does not assing a queue to limit traffic.
I had to Downgrade to 6.44.3 to have this working.
Thanks
Have a great day!
Certified: MTCNA - MTCWE - MTCRE
 
danieltecnet
just joined
Posts: 9
Joined: Tue Jan 31, 2017 10:35 pm
Location: https://www.google.com.br/maps/@-4.9872 ... 128006,16z

Re: v6.45.1 [stable] is released!

Tue Jul 16, 2019 9:48 pm

I just want to understand why when updating to this version 6.45.1 my ipv6 has broken through the network? and just go back to another version that works!
 
User avatar
firerain
just joined
Posts: 14
Joined: Fri Nov 04, 2016 10:49 pm
Location: Poland

Re: v6.45.1 [stable] is released!

Wed Jul 17, 2019 1:16 am

Quite nice mess. I'll add my two cents...
Old, good RB450G. Just upgraded to 6.45.1 from something like 6.40 and now can't connect through any port. 4 ports switched and one with DHCP client.
Winbox says nothing (even after updating it and clearing cache).
The only solution seems to be a rs232 (not tried yet).
Any thoughts on that?
 
sindy
Forum Guru
Forum Guru
Posts: 3814
Joined: Mon Dec 04, 2017 9:19 pm

Re: v6.45.1 [stable] is released!

Wed Jul 17, 2019 7:43 am

6.40.x still had the "Ethernet master port" instead of current "hardware accelerated bridge", so I would be afraid to jump that deep into future from there directly.

Other than that, I usually export the configuration so that if the upgrade failed (so far only RC/beta versions did in my case), I could reset the configuration to defaults and then recreate it from the export. Files on device survive reset to defaults so it makes sense even where you have to instruct someone at remote location how to do the recovery.

Right now yes, serial is your last chance to see what went wrong and not lose the configuration completely.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
iperezandres
newbie
Posts: 42
Joined: Mon Feb 13, 2017 1:17 pm
Location: Madrid
Contact:

Re: v6.45.1 [stable] is released!

Wed Jul 17, 2019 8:10 am

Is it me or 6.45.1 is giving everyone a different type of headache? I don't remember an update with soooo many problems, right?

Any fix coming soon?

Thanks.
 
mkx
Forum Guru
Forum Guru
Posts: 2985
Joined: Thu Mar 03, 2016 10:23 pm

Re: v6.45.1 [stable] is released!

Wed Jul 17, 2019 8:27 am

Is it me or 6.45.1 is giving everyone a different type of headache?

Judging from posts in this tread it does seem that 6.45.1 is a troublesome child of MT.

This is not my personal experience though, have updated 6 pieces (2x hAP ac lite, 1x hAP, 2x RB951G and 1xhAP ac2) from 6.44.x and I didn't have a single problem ... neither during upgrade nor afterwards (after 15 days of uptime running 6.45.1). Disclaimer: I did upgrade all devices quite regularly, so not many entries from the changelog were there to bite.
BR,
Metod
 
faxxe
just joined
Posts: 5
Joined: Wed Dec 12, 2018 1:46 pm

Re: v6.45.1 [stable] is released!

Wed Jul 17, 2019 8:52 am

Since a long time i use a script to get my public ip and a log entry if it has changed. I found it here in the forum.
It creates also an entry in the adress lists with my public ip named "external-ip"
Since the upgrade to 6.45.1 this script doesnt work anymore.
No error message but also no adress list will be created. It was flawless until 6.45.1

Any ideas? Thanx
# Set needed variables
:global ExtIpListName "external-ip"
:global ExtIp ""
:global ExtIpOld ""

# Get IP and save it to "mypublicip.txt"
/tool fetch url="http://myip.dnsomatic.com/" mode=http dst-path=mypublicip.txt
# Save IP from "mypublicip.txt" to variable
:global ExtIp [file get mypublicip.txt contents]

:if ([:len [/ip firewall address-list find list="$ExtIpListName"]] > 0) do={
 :set ExtIpOld [/ip firewall address-list get [/ip firewall address-list find list="$ExtIpListName"] address];
 :if ($ExtIpOld != $ExtIp) do={
 /ip firewall address-list set [/ip firewall address-list find list="$ExtIpListName" address="$ExtIpOld"] address="$ExtIp"
 :log info "External IP relpaced from $ExtIpOld to $ExtIp."
 } else={
 :log info "External IP $ExtIp not changed."
 };
} else={
 /ip firewall address-list add list="$ExtIpListName" address="$ExtIp" comment="script generated"
 :log info "New external IP $ExtIp added."
};
 
User avatar
NetVicious
Member Candidate
Member Candidate
Posts: 109
Joined: Fri Nov 13, 2009 3:30 pm
Location: Spain

Re: v6.45.1 [stable] is released!

Wed Jul 17, 2019 10:03 am

Old, good RB450G. Just upgraded to 6.45.1 from something like 6.40 and now can't connect through any port. 4 ports switched and one with DHCP client.
Winbox says nothing (even after updating it and clearing cache).
The only solution seems to be a rs232 (not tried yet).
Any thoughts on that?
Try connecting within Mac Address. If doesn't works, and RS232 neither you should do a reset of the config.
Jumping from 6.40 to 6.45.1 it's a very very big jump and there was a lot of changes between that two versions. One of those changes was the elimination of master and slave ports. Now all needs to be done within bridges.
. . //\/ e t . \/ i c i o u s ..
 
dnordenberg
just joined
Posts: 23
Joined: Wed Feb 24, 2016 8:00 pm

Re: v6.45.1 [stable] is released!

Wed Jul 17, 2019 10:25 am

Upgraded a RB960PGS-PB from 6.42 something (factory) and lost administration connectivity. Almost empty config, no firewall, only a bridge1 with all ports and IP was set on bridge1. Reboot did nothing. I used reset button and it worked again at 192.168.88.1 but as soon as I removed config and added bridge1 and my IP back on bridge1 it stopped working again. Downgraded to 6.44.3 and winbox connected directly without touching anything else. 6.45.1 certainly has connectivity issues :(
 
dnordenberg
just joined
Posts: 23
Joined: Wed Feb 24, 2016 8:00 pm

Re: v6.45.1 [stable] is released!

Wed Jul 17, 2019 12:59 pm

Upgraded a RB960PGS-PB from 6.42 something (factory) and lost administration connectivity.
And with lost conectivity I mean I could not discover the device in winbox, not even see any of it's ports MAC addresses and connect to that while I was directly on one of it's ports. So not really an IP address issue only, even lower layer... :(
However the device continued to function as a switch, that traffic still worked so device was alive.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5833
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.45.1 [stable] is released!

Wed Jul 17, 2019 2:52 pm

It is a "known issue" (I don't know if MikroTik is aware of it but it has been mentioned on the forum before) that configuring the device in bridge mode from the quickset menu results in a bad configuration where you are locked out. When you configure it as a router and then remove the ether1-specific configuration (DHCP client etc) and the firewall forward rules, you can add ether1 to the bridge and the result should be the same.
 
dnordenberg
just joined
Posts: 23
Joined: Wed Feb 24, 2016 8:00 pm

Re: v6.45.1 [stable] is released!

Wed Jul 17, 2019 3:15 pm

configuring the device in bridge mode from the quickset menu results in a bad configuration where you are locked out.
I did not do it exactly this way, I removed config completely after first startup (after factory reset). Then connected by MAC address, did the bridge config by hand and not trough quickset and boom, device disappeared from network...

But when I think about it again, it is not completely reproducible, sometimes only IP connectivity was gone, MAC access still worked. It was that way I could do a downgrade so at least once MAC access still worked and only IP was blocked. Damn hard to remember all the steps you make when you are just trying to get a device to work again hehe....
 
pe1chl
Forum Guru
Forum Guru
Posts: 5833
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.45.1 [stable] is released!

Wed Jul 17, 2019 4:40 pm

Does it work OK when you configure it as a router in quickset? It should.
Then you can investigate what is going on.
 
dnordenberg
just joined
Posts: 23
Joined: Wed Feb 24, 2016 8:00 pm

Re: v6.45.1 [stable] is released!

Wed Jul 17, 2019 4:51 pm

Yes the factory default nat router config works so I can reset it back to that. It's when I apply the bridge config that things gets weird...
 
mkx
Forum Guru
Forum Guru
Posts: 2985
Joined: Thu Mar 03, 2016 10:23 pm

Re: v6.45.1 [stable] is released!

Wed Jul 17, 2019 5:13 pm

It's when I apply the bridge config that things gets weird...
As @pe1chl wrote: you have to remove router functionality by hand (either via GUI or CLI, just don't use quickset).
BR,
Metod
 
pe1chl
Forum Guru
Forum Guru
Posts: 5833
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.45.1 [stable] is released!

Wed Jul 17, 2019 5:50 pm

Yes as I wrote before, just keep the bridge settings made by the router config but remove the ether1 address config (dhcp client) and join it to the bridge (and change interface list membership, remove it from WAN).
Not by using the quickset but as separate steps in the configuration. Then it could be you also want to change the firewall.
 
mstead
Member Candidate
Member Candidate
Posts: 113
Joined: Sat Mar 04, 2006 2:41 am

Re: v6.45.1 [stable] is released!

Wed Jul 17, 2019 6:14 pm

Is this the new API that sends the password in plain text?? I cannot figure WHY you guys would revert to that way of operation.
 
bbs2web
Member Candidate
Member Candidate
Posts: 198
Joined: Sun Apr 22, 2012 6:25 pm
Location: Johannesburg, South Africa
Contact:

Re: v6.45.1 [stable] is released!

Wed Jul 17, 2019 7:07 pm

The old API login method used CHAP (challenge authentication protocol), which requires the router to store the password in plain text. Passwords are now stored as a hash so you need to send the original password, which the router then hashes to compare to the stored password.

Use API-SSL if you are transmitting API over an untrusted network...
 
User avatar
iperezandres
newbie
Posts: 42
Joined: Mon Feb 13, 2017 1:17 pm
Location: Madrid
Contact:

Re: v6.45.1 [stable] is released!

Wed Jul 17, 2019 7:26 pm

The process for the API, is the same one that follows winbox for the user authentication? May that be related to the issue with incorrect user and password error?
 
dnordenberg
just joined
Posts: 23
Joined: Wed Feb 24, 2016 8:00 pm

Re: v6.45.1 [stable] is released!

Wed Jul 17, 2019 9:16 pm

Yes as I wrote before, just keep the bridge settings made by the router config but remove the ether1 address config (dhcp client) and join it to the bridge (and change interface list membership, remove it from WAN).
Not by using the quickset but as separate steps in the configuration. Then it could be you also want to change the firewall.

I think you are talking about another problem, this was strictly related to 6.45.1 as downgrading made the problem disappear. And I did not use quickset, I directly answered no to the question if I want to keep the config. Then the router reboots without a config. Everything still works fine as expected. The problem starts when creating a bridge.
 
User avatar
firerain
just joined
Posts: 14
Joined: Fri Nov 04, 2016 10:49 pm
Location: Poland

Re: v6.45.1 [stable] is released!

Thu Jul 18, 2019 12:40 am

Try connecting within Mac Address. If doesn't works, and RS232 neither you should do a reset of the config.
Jumping from 6.40 to 6.45.1 it's a very very big jump and there was a lot of changes between that two versions. One of those changes was the elimination of master and slave ports. Now all needs to be done within bridges.

Of course, I tried with MAC. That's actually the only method I use on a daily basis. I treat that box as a regular (well, almost) switch, hence only one port (ether1) has dhcp client (just in case) and is not connected most of the time.

Right now yes, serial is your last chance to see what went wrong and not lose the configuration completely.

Thanks for advises both of you. I've tried serial and guess what... Winbox connection (via MAC) suddenly started to work. No idea what happened. It's a quite basic config.
My switching configuration is untouched - besides lack of slave/master ports settings.
Anyway, I'm not planning to make a network bridge of native switching device. Sounds ridiculous.
It's enough that I've lost switching possibility for ether1 after some prior upgrade (from 6.3x.x to 6.4x).
 
tdw
Member Candidate
Member Candidate
Posts: 194
Joined: Sat May 05, 2018 11:55 am

Re: v6.45.1 [stable] is released!

Thu Jul 18, 2019 2:35 am

It's enough that I've lost switching possibility for ether1 after some prior upgrade (from 6.3x.x to 6.4x).

What does /interface ethernet switch print detail show?
 
User avatar
bajodel
Long time Member
Long time Member
Posts: 545
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

Re: v6.45.1 [stable] is released!

Thu Jul 18, 2019 5:39 pm

I don't know if these things are strictly related to 6.45.x but..

Yesterday I've added a secondary ethernet link from my main switch (CRS326) and my firewall (RB3011) in the knowledge my CRS326 would handle the backup link correctly (STP was already active on my CRS326); previously there was only the SFP-cable connecting them:

1) if I use the ether1 on my RB3011 (witch is the PoE-in capable port) the RB3011 switches off immediately (no matter what port I use on the CRS326 side). If I try to connect the ether1 port of the RB3011 to a spare CRS125 all is fine instead.
2) (using a different port on RB3011 than ether1) switching on STP on RB3011 (beside of the up and running STP process on the CRS326) the STP process select the root port correctly but I've noticed a lot of packet losses; the packet loss is reproducibile easily pushing repeatedly the button "Refresh" on Winbox to force a quick discovery in LAN!! Switching off the STP process on RB3011 and relying only on the STP process of the CRS326 is fine and there is no evident packet loss any more.
3) With STP active only on CRS326, the dual link (active/backup) to the firewall seems to behave correctly but I've noticed the main switch (CRS326) has some issues with ARP( e.g. my ip phone snom-370 is unable to get a DHCP response, connecting to the switch via Winbox needs 2-3 tries, ..).
4) removing the secondary/backup ethernet link from CRS326 and RB3011 solves all the problems: no ARP issues (slow/weird), my ip phone get his address normally. All is back to normal.

P.S. Every firmwares are updated along with the ros versions (so 6.45.1) and I've also tried with a fresh netinstall for both of them (CRS326/RB3011) and I reimported the configurations line by line from a previous export. Setups on CRS326 and RB3011 are quite well tried and I'm sure I've already tried in the past to put a redundant link between them without noticing any similar issues.

The weirdest thing, however, is the fact that the RB3011 will immediately switch off if I connect the ether1 (PoE-in capable port) to any port of the CRS326 !!

Has anyone any insights ?
 
User avatar
iperezandres
newbie
Posts: 42
Joined: Mon Feb 13, 2017 1:17 pm
Location: Madrid
Contact:

Re: v6.45.1 [stable] is released!

Thu Jul 18, 2019 5:47 pm

No idea. As far as I am reading, everyone seams to be experiencing different issues, but for me they look completely unrelated. Maybe v6.45.1 is not that stable?
 
mkx
Forum Guru
Forum Guru
Posts: 2985
Joined: Thu Mar 03, 2016 10:23 pm

Re: v6.45.1 [stable] is released!

Thu Jul 18, 2019 5:49 pm

My thinking is that using STP to create redundant links between two directly attached devices is (slight) abuse.

In this case it would be better to use bonding. There are many varieties, if you only want to have backup line, you can use active-backup mode.
BR,
Metod
 
pe1chl
Forum Guru
Forum Guru
Posts: 5833
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.45.1 [stable] is released!

Thu Jul 18, 2019 5:54 pm

Is there any ETA for...
Wrong question! At MikroTik, there never is an ETA!
"it is ready when it's ready".
Typical time for things to be ready is late friday afternoon.
 
User avatar
eworm
Member
Member
Posts: 395
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

Re: v6.45.1 [stable] is released!

Thu Jul 18, 2019 5:56 pm

Is there any ETA for...
Wrong question! At MikroTik, there never is an ETA!
"it is ready when it's ready".
This is just spam to advertise Bitcoin/Cryptocurrency Trading Exchange Platform. (See signature.)
Manage RouterOS scripts and extend your devices' functionality: RouterOS Scripts
 
User avatar
bajodel
Long time Member
Long time Member
Posts: 545
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

Re: v6.45.1 [stable] is released!

Thu Jul 18, 2019 7:27 pm

My thinking is that using STP to create redundant links between two directly attached devices is (slight) abuse.
In this case it would be better .. bonding..
I can agree on this, but consider that just phisically plugging ether1 of rb3011 to one port of the crs326 immediately kills the rb3011 (switched off, dead untill I unplug the cable and it reboots) ..no matter what configuration you have. Furthermore a backup link should be a standby/blocked link with no activity, beside stp messaging, and so pretty stable! ARP issues with this simple scenario is clearly a nonsense.
Bonding (active/backup) might be my best choice here, but it sounds like something to avoid now if I haven't got the chance to figure out what the hell it's happening in the first place :-)

Who is online

Users browsing this forum: No registered users and 4 guests