Community discussions

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 9
 
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: 27
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: 7
Joined: Wed Aug 03, 2016 3:46 pm

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: 11
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: 5891
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: 11
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: 875
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: 3496
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: 5891
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: 20
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 Veteran
Forum Veteran
Posts: 970
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: 3496
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
just joined
Posts: 24
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
newbie
Posts: 47
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: 3496
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: 3496
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: 95
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: 8
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: 3496
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: 45
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: 16
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: 3496
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: 3
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: 1405
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: 95
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
Frequent Visitor
Frequent Visitor
Posts: 96
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: 5357
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: 5357
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
Frequent Visitor
Frequent Visitor
Posts: 96
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 Veteran
Forum Veteran
Posts: 970
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: 1079
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
Frequent Visitor
Frequent Visitor
Posts: 96
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 ..
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 9

Who is online

Users browsing this forum: No registered users and 11 guests