Community discussions

 
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: 190
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: 54
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: 5816
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: 494
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: 54
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: 2943
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: 666
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: 3811
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: 392
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: 5816
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: 8308
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: 1302
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: 7602
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: 899
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: 5816
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: 8308
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: 622
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: 494
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: 3811
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: 247
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: 5816
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: 3811
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: 5816
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: 5816
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: 24205
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: 2943
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: 3811
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: 2943
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: 5816
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: 5816
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: 2943
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: 5816
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: 190
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: 2943
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: 5816
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: 392
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 14 guests