Community discussions

  • 1
  • 5
  • 6
  • 7
  • 8
  • 9
 
TimurA
Member Candidate
Member Candidate
Posts: 141
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: 3760
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: 15
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: 5555
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
newbie
Posts: 46
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: 5555
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: 141
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: 48
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: 197
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: 5913
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: 24074
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: 110
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: 2590
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: 124
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: 1
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: 134
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: 8
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: 3760
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: 2590
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
Frequent Visitor
Frequent Visitor
Posts: 97
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: 5555
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.
  • 1
  • 5
  • 6
  • 7
  • 8
  • 9

Who is online

Users browsing this forum: No registered users and 7 guests