Can you give more details about this?*) traffic-flow - do not count single extra packet per each flow;
*) firewall - fixed "tls-host" firewall matcher;
Cha0s - Before the fix Traffic Flow, for example, instead of reporting 5 packets per flow reported 6 packets. Simply reported one packet more than flow has actually processed;
irghost - Can you provide an example of rule which you have tried out and seen that it is not working?
/ip firewall filter add action=drop chain=forward protocol=tcp tls-host=*.youtube.com
i never figure out how to setup that, so i will be cool to have some exemple form MT supportCha0s - Before the fix Traffic Flow, for example, instead of reporting 5 packets per flow reported 6 packets. Simply reported one packet more than flow has actually processed;
irghost - Can you provide an example of rule which you have tried out and seen that it is not working?Code: Select all/ip firewall filter add action=drop chain=forward protocol=tcp tls-host=*.youtube.com
I don't think you can use wildcards. Or to put it more correctly, I think you should use the domains defined in the certificate.i never figure out how to setup that, so i will be cool to have some exemple form MT supportCha0s - Before the fix Traffic Flow, for example, instead of reporting 5 packets per flow reported 6 packets. Simply reported one packet more than flow has actually processed;
irghost - Can you provide an example of rule which you have tried out and seen that it is not working?Code: Select all/ip firewall filter add action=drop chain=forward protocol=tcp tls-host=*.youtube.com
i never figure out how to setup that, so i will be cool to have some exemple form MT supportCha0s - Before the fix Traffic Flow, for example, instead of reporting 5 packets per flow reported 6 packets. Simply reported one packet more than flow has actually processed;
irghost - Can you provide an example of rule which you have tried out and seen that it is not working?Code: Select all/ip firewall filter add action=drop chain=forward protocol=tcp tls-host=*.youtube.com
add some documents
irghost, raffav, Cha0s - Seems that we have found an issue with new TLS matcher. We will try to fix it as soon as possible;
+1 .. We know documentation takes time, but the rc features cannot be really well tested w/o at least basic suggestionsadd some documents
What configuration you had on the hap ac lite?I have a bootloop after upgrading my hap ac lite from rc2 to rc5...
capsman with local wifi and map lite on ether5 (poe), bridge (ether3,5 + caps interfaces), ripe atlas in ether4, uplink in ether1.What configuration you had on the hap ac lite?
Yes, all changes affecting commands and parameters should be documented on the Wiki.+1 .. We know documentation takes time, but the rc features cannot be really well tested w/o at least basic suggestionsadd some documents
+1!!!!Yes, all changes affecting commands and parameters should be documented on the Wiki.+1 .. We know documentation takes time, but the rc features cannot be really well tested w/o at least basic suggestionsadd some documents
It is not acceptable to have to manually check all change lists when trying to figure out how to use commands.
(especially the details of parameters)
Maybe the Wiki should be split in current and release candidate branches so new features can be added in the release candidate
branch and moved over to the current branch once it has been released.
When each new feature in the release candidates is not immediately documented in the Wiki, a backlog will develop and "making the
documentation uptodate" will become an every higher mountain.
where to find this feature ?!) wireless - new driver with initial support for 160 and 80+80 MHz channel width;
This new driver is needed to take advantage of 802.11ac Wave 2 wireless devices which MikroTik does not have currently (if I am not mistaken). Please follow the link viewtopic.php?f=21&t=123936&p=626003&hilit=160#p626003 with a brief discussion.where to find this feature ?!) wireless - new driver with initial support for 160 and 80+80 MHz channel width;
what hardware is supported to test 160mhz channel width?
Wave 2, a superset of Wave 1, requires new hardware in both access points and client devices to support the additional 802.11ac capabilities such as MU-MIMO, channel widths up to 160 MHz, and the potential for a fourth spatial stream.
The SXTsq AC is 802.11ac Wave2. As is the un-announced cAP AC which has passed FCC testing.This new driver is needed to take advantage of 802.11ac Wave 2 wireless devices which MikroTik does not have currently (if I am not mistaken).
Thanks for the info. I haven´t noticed the IPQ4018 on the product pageThe SXTsq AC is 802.11ac Wave2.
12:32:29 caps,info XX:XX:XX:XX:XX:XX@cap6 connected
12:32:32 caps,info XX:XX:XX:XX:XX:XX@cap6 disconnected, too strong signal
12:32:37 caps,info XX:XX:XX:XX:XX:XX@cap6 connected
12:32:41 caps,info XX:XX:XX:XX:XX:XX@cap6 reassociating
12:32:41 caps,info XX:XX:XX:XX:XX:XX@cap6 connected
12:32:53 caps,info XX:XX:XX:XX:XX:XX@cap6 disconnected, too strong signal
12:32:56 caps,info XX:XX:XX:XX:XX:XX@cap6 connected
12:32:59 caps,info XX:XX:XX:XX:XX:XX@cap6 disconnected, too weak signal
No Omnitik is QCA9557I've found that QCA9888 is 80+80mhz capable
https://www.qualcomm.com/products/qca9888
seems that Omnitik AC has one, or am I mistaken?
Yes - I agree totally your experience with IGMP snooping on bridges at least downstream. Main router is ccr1016, feeding 3 x downstream crs125 switches, 1 x 8 port switch, a dell centos7 server using two more CCR ethernets with VMs, DNS, FTP, etc on it as well. All off different ethers on the CCR for our LAN. A simple single bridge on the CCR with ether 1 (WAN) routed not a part of the bridge. Rest of ethers 2 to 7 are on a single bridge.IGMP Snooping problems experienced with 6.41 and still present in 6.42rc:
- Very high traffic volume (~90Mbps) without apparent reason (VMs were not moving much data) on interfaces connecting Proxmox cluster nodes (hypervisors). During this time of high traffic, some node heartbeats were missed and nodes sporadically appeared as down, even though they were up. Just a straight bridge, no vlans. Fast forward and IGMP snooping enabled. Turning off IGMP snooping on the bridge fixed this.
- Inability of clients of vlan-tagging access points to get IP address from DHCP running on the Mikrotik, even though the VLAN and DHCP were set up correctly. The VLAN is set up in pre-6.41 style, on the bridge interface, with no vlan filtering on the bridge. Access Points are connected to the bridge ethernet ports and are tagging the traffic from clients. The DHCP server runs on the VLAN inteface. Fast forward enabled on bridge. Everything was working fine until IGMP Snooping was also enabled on the bridge. Then and after a while (not immediately), the new DHCP leases would stick in an "offered" state and logs were filled with "lease unsuccessful" messsages. Again, disabling IGMP Snooping on the bridge fixed the problem immediately.
Interesting, how does this feature work at all?The new "/interface wireless access-list allow-signal-out-of-range" feature in 6.41 dramatically improved roaming wireless clients' connectivity. Thanks!
Here is a lengthy discussion:Interesting, how does this feature work at all?The new "/interface wireless access-list allow-signal-out-of-range" feature in 6.41 dramatically improved roaming wireless clients' connectivity. Thanks!
If my present rule allows -80..120 and rejects -120..-81 ; what are the precise rules i want for the new option? mind pasting the lines? I suppose the involved lines should go above my present rules right?Here is a lengthy discussion:Interesting, how does this feature work at all?The new "/interface wireless access-list allow-signal-out-of-range" feature in 6.41 dramatically improved roaming wireless clients' connectivity. Thanks!
viewtopic.php?t=124884
Basically, in a wireless access-list you can specify a signal range required to establish/maintain a connection. Bugs in the client radio, bugs in the AP radio, or actual signal changes will cause a client to be disconnected from the AP when the calculated signal strength goes out of that range. This sounds good in theory, but in practice this happens for certain clients regardless of their distance to the AP (likely a bug in radio firmware.) Because the offending clients only exceed this signal range for a small number of frames at a time, the new access-list default in 6.41 is to allow a client to be out of signal range for 10 seconds before the rule is triggered.
In my experience, using a signal range of -120..120 (or not specifying a signal range at all) in the access list still results in both "too strong" and "too weak" events that disconnect clients. The "allow-signal-out-of-range" keeps these clients connected to the AP while still preventing low-signal clients from initially connecting. Unfortunately, this change didn't get implemented in caps-man when it was put into /interface wireless access-list.
Please explain.Version 6.42rc5 has been released.
*) bridge - properly update "actual-mtu" after MTU value changes (introduced v6.41);
If my present rule allows -80..120 and rejects -120..-81 ; what are the precise rules i want for the new option? mind pasting the lines? I suppose the involved lines should go above my present rules right?
allow-signal-out-of-range (always | time [0s..1d]; Default: 10s)
Ignore signal-range in this rule for the specified time period.
/interface wireless access-list
print
# For the "allow connections" rule allow 10 seconds of out-of-range signal:
set 1 allow-signal-out-of-range=10s
https://wiki.mikrotik.com/wiki/Manual:I ... encryption*) tile - added "aes-ctr" hardware acceleration support;
Can someone explain to me?
interface wireless frequency-monitor wlan1
FREQ USE NF
frequency-monitor not running
/interface wireless snooper> snoop wlan1
CHANNEL USE BW NET-COUNT NOISE-FLOOR STA-COUNT
not running
UPDATE: Nstreme work fine... i add the "Management Protection Key" of the Sextant AP to the SXT station and connect OK with Nstreme... NV2 is not working!BAD WIRELESS!!!
Tested in a SXT in "station-bridge" in production connected to a Sextant in "ap-bridge" mode and was lost tomorrow need to go physically to the tower to downgrade by ethernet... the SXT client is in Wireless-Protocol=nv2-nstreme, changed the Sextant AP to NV2 or Nstreme and no connect... In rc5 was the same and by the changelog this solve wireless problems and i take the risk... NOT SOLVED!
That's as expected since hw-offloaded STP/RSTP is not supported on Realtek, Mediatek and ICPlus175D switches: https://wiki.mikrotik.com/wiki/Manual:S ... Offloading. As I understand when you enable STP/RSTP on one of these switches the hw-offload should automatically be turned off, but that didn't happen before, and now they fixed that.Updated: "*) bridge - fixed hw-offload disabling for Mediatek and Realtek switches when STP/RSTP configured;"
upload speed through router is still 500 Mbit/s slower when STP/RSTP is activated on the Bridge
While it is a worthy mention and any improvement in DHCPv6 support is welcome I feel it is important to remind you that your team is sorely lacking in this area from even a residential router perspective. Look at how OpenWRT / LEDE implements DNSMASQ in LUCI for a valuable interface. We need to be allow per server instance to set the network bits used, aka VLAN11 should always be provider::/56 ending in 11 like provider11::/64, this implies nesting or parent/child functionality that is currently not allowed with your pool system. Additionally, the DHCPv6 server needs to support client address allocation before it is useful. In parallel the SLAAC implementation should not parrot the upstream DNS servers, instead the administrator should be able to set their own. If I use your SLAAC implementation it results in all of my IPv6 DNS queries, which could be a single stack area of my network, not being cached.*) dhcpv6-client - added info exchange support;
*) dhcpv6-client - added support for options 15 and 16;
*) dhcpv6-server - added DHCPv4 style user options;
I tested and have the same problem. Test done with veritas.hr 185.58.74.135. IPv4 only.No feedback what's wrong with pppoe.?
It's not a problem for a RC release, but a current. Especially at this point, Downgrade is not simply because of the implementation bridge.
This is the main thing about roter, website review. it is not a special possibility. Some hosting does not open, they which have about 100 websites.
My production is at 6.39.3, so it's not terrible. At work and at home in newer versions.
Tnx liviu2004 on the topic, I thought something was wrong with me.
Best regards.
Sorry for bad English
It's OK now with rc11. Tried veritas.hr, pupilla.hr and boletus.hr. All loading ok.The list opens normally, the web pages on that list do not open. For example, the web Page pupilla.hr, boletus.hr ...
Just through the Mikrotik pppoe connection is a problem. "Status do not get off of "syn sent"
I have print logs, but the liviu2004 explained everything in his topic.
( I have a backup connection, pppoe on the router ISP, a Mikrotik connected via Lan to that router. . so the company that has to have access to one page has redirected it.)
Please give a bit more detail and/or workaround for this issue. Can it be fixed by removing change-mss in PPP and adding a change-mss firewall mangle rule?*) ppp - fixed change-mss funcionality in some specific traffic (introduced in v6.41);
Yes. You can add change mss mangle rules manually to fix the problem, you don't need to turn off setting in ppp profile.Please give a bit more detail and/or workaround for this issue. Can it be fixed by removing change-mss in PPP and adding a change-mss firewall mangle rule?*) ppp - fixed change-mss funcionality in some specific traffic (introduced in v6.41);
When will 6.41.1 be released to fix it?
Yes, I saw that fix, everything is okay now.It's OK now with rc11. Tried veritas.hr, pupilla.hr and boletus.hr. All loading ok.The list opens normally, the web pages on that list do not open. For example, the web Page pupilla.hr, boletus.hr ...
Just through the Mikrotik pppoe connection is a problem. "Status do not get off of "syn sent"
I have print logs, but the liviu2004 explained everything in his topic.
( I have a backup connection, pppoe on the router ISP, a Mikrotik connected via Lan to that router. . so the company that has to have access to one page has redirected it.)
I guess this fixed it:
*) ppp - fixed change-mss funcionality in some specific traffic (introduced in v6.41);
dst-address-type=local should not catch addresses from local network. it should work just as described in docs: "local - if dst-address is assigned to one of router's interfaces"Did anyone else noticed a change (6.42.RC11) in behaviour of the Address Type: "local" as described in posting: viewtopic.php?f=21&t=129034&start=50#p637725?
How many CAP interfaces are we talking about?Version 6.42rc5 has been released.
:
*) capsman - improved CAPsMAN responsiveness on systems with large amount of CAP interfaces;
:
Why are you working on a new features that are not very important for Mikrotik users (there is firewall which can do much more for experienced users) and you are not fixing existing important issues? When you will solve a problem with with wireless compatibility for low-end client devices? viewtopic.php?f=7&t=102908#p618041*) kidcontrol - added initial support for "/ip kid-control" feature (CLI only);
Yah I was wondering about that too. I'm sure Amazon are very much looking forward to flashing the latest RC so they can have kid control.Why are you working on a new features that are not very important for Mikrotik users (there is firewall which can do much more for experienced users) and you are not fixing existing important issues? When you will solve a problem with with wireless compatibility for low-end client devices? viewtopic.php?f=7&t=102908#p618041*) kidcontrol - added initial support for "/ip kid-control" feature (CLI only);
It was not mentioned in the RC11 release notes and it good that Mikrotik fixed this because this discrepancy between the docs and reality has been present in at least 6.40 and 6.41 and up to 6.42RC9.dst-address-type=local should not catch addresses from local network. it should work just as described in docs: "local - if dst-address is assigned to one of router's interfaces"Did anyone else noticed a change (6.42.RC11) in behaviour of the Address Type: "local" as described in posting: viewtopic.php?f=21&t=129034&start=50#p637725?
https://wiki.mikrotik.com/wiki/Manual:I ... all/Filter
Can't confirm on 6.41:It was not mentioned in the RC11 release notes and it good that Mikrotik fixed this because this discrepancy between the docs and reality has been present in at least 6.40 and 6.41 and up to 6.42RC9.
Router pings itself (192.168.88.1/24) - packets are in log./ip firewall filter
add action=accept chain=output dst-address-type=local log=yes
Can't confirm on 6.41:It was not mentioned in the RC11 release notes and it good that Mikrotik fixed this because this discrepancy between the docs and reality has been present in at least 6.40 and 6.41 and up to 6.42RC9.
Router pings itself (192.168.88.1/24) - packets are in log./ip firewall filter
add action=accept chain=output dst-address-type=local log=yes
Router pings its neighbour (192.168.88. - no logging. So, in 6.41 dst-address-type=local also works as expected.
/ip firewall mangle
add action=mark-connection chain=prerouting comment="VPN connection mark" connection-mark=no-mark \
dst-address-type=!local dst-port=80,443 new-connection-mark=VPN1 passthrough=yes \
per-connection-classifier=src-port:2/0 protocol=tcp src-address-list=PrivateVPN
add action=mark-connection chain=prerouting comment="VPN connection mark" connection-mark=no-mark \
dst-address-type=!local dst-port=80,443 new-connection-mark=VPN2 passthrough=yes \
per-connection-classifier=src-port:2/1 protocol=tcp src-address-list=PrivateVPN
I always hope (or try to fool myself?) that silly things like kid-control or "detect internet" are assignments for a trainee or graduate, and the normal staff is working on the important stuff (or maybe even on version 7!).Why are you working on a new features that are not very important for Mikrotik users (there is firewall which can do much more for experienced users) and you are not fixing existing important issues?*) kidcontrol - added initial support for "/ip kid-control" feature (CLI only);
What you see is product focus on home router, cheap home router, not at wisp wireless anymore....I always hope (or try to fool myself?) that silly things like kid-control or "detect internet" are assignments for a trainee or graduate, and the normal staff is working on the important stuff (or maybe even on version 7!).Why are you working on a new features that are not very important for Mikrotik users (there is firewall which can do much more for experienced users) and you are not fixing existing important issues?*) kidcontrol - added initial support for "/ip kid-control" feature (CLI only);
Indeed it would be a shame when time that would otherwise be spent on important stuff is instead wasted on these things...
Yeah been waiting for it too, but they could be busy working on other extremely important enterprise features like kid control.Please inform about your plans,
when will work LACP with hardware offload in RouterOS (on crs 317)?
Depends on your answer, we will buy your equipment or not.
Thank you.
[Ticket#2018012222005306] RE: LACP HW CRS317-1G-16 [...]HW LACP is must.
More than 100 CAPs.How many CAP interfaces are we talking about?Version 6.42rc5 has been released.
:
*) capsman - improved CAPsMAN responsiveness on systems with large amount of CAP interfaces;
:
[Ticket#2018012222005306] RE: LACP HW CRS317-1G-16 [...]HW LACP is must.
Got reply from support that they are working on and trying to release soon... That feels like a message all would like to hear.....Hello,
We are currently working on this feature. We hope to see it soon.
Best regards,
Arturs C.
--
MikroTik.com
Come to the MUM conferences, registration open in Cameroon, Kenya, Russia (Ekaterinburg), Russia (St. Petersburg), Europe (Berlin), Australia, New Zealand! https://mum.mikrotik.com/
I setup a new controller (coming from the CHR release) with an RB1100AHX4 and put new CAPs (wAP AC, HAP AC, HAP AC lite) on the controller, step by step. After nearly 3 days without any problem,More than 100 CAPs.How many CAP interfaces are we talking about?Version 6.42rc5 has been released.
:
*) capsman - improved CAPsMAN responsiveness on systems with large amount of CAP interfaces;
:
HOORAY!!! finally!*) chr - added "open-vm-tools" on VMware installations;
What's the point if we have to do an extra reboot?*) routerboard - added RouterBOOT "auto-upgrade" after RouterOS upgrade (extra reboot required) (CLI only);
*) chr - make virtio disks visible under "/disk" on KVM installations;
The fix should be applied on the CAPsMAN.I setup a new controller (coming from the CHR release) with an RB1100AHX4 and put new CAPs (wAP AC, HAP AC, HAP AC lite) on the controller, step by step. After nearly 3 days without any problem,More than 100 CAPs.How many CAP interfaces are we talking about?Version 6.42rc5 has been released.
:
*) capsman - improved CAPsMAN responsiveness on systems with large amount of CAP interfaces;
:
I experienced my first problems again today, i.e. the controller lost the connection to all of the CAPs concurrently.
- The RB1100AHX4 is monitored from two different probes (10s ping) within my network. There was no single loss to it. My monitoring was able pull all information with SNMP. No connection loss here.
- RouterOS version on RB1100AHX4: 6.41
- RouterOS version on CAPs: 6.42rc11
- sessions displayed on RB1100AHX4 when right before the loss: ~23000
- amount of clients connected on all CAP right before the loss: 723
- CPU load on RB1100AHX4 right before the loss: CPU1: 25%, CPU2: 38%, CPU3: 19%, CPU4: 19%
- Amount of CAPS: 46
- Amount of CAP interfaces displayed within CAPSMAN => CP Interfaces: 268 (we have multiple SSIDs on 2.4Ghz and 5Ghz)
----> That´s the critical 100 "CAP interface barrier" I assume?
All CAPs tell me within their logs: "CAP connect to MikroTik (::ffff:....) failed: timeout
The CAPSMAN controller tells me for each CAP: "caps,debug [::ffff:.....,Run,[6C:3B:6B:B7:01:95]] lost connection, keepalive timeout"
So will 6.42rc11 running on the RB1100AHX4 help?
(I had those issues as well on a the CHR version before with ~80 CAPs and it didn´t matter what CPU cores I used, going from 2 core up to 16, the controller lost its connection to the CAPs)
v6.42rc14, and still not workingirghost, raffav, Cha0s - Seems that we have found an issue with new TLS matcher. We will try to fix it as soon as possible;
Does the basic "request a certificate" option in CAPsMAN use SCEP? Or does that use something else?Note: if SCEP and CAPsMAN is used, make sure to upgrade clients first, only then upgrade server side. Otherwise after server upgrade old clients will not be able to get certificates.
i emailed support and they said they don't plan on adding this feature for capsman. so they find this important for wireless but not capsman. very 'logical' right?The new "/interface wireless access-list allow-signal-out-of-range" feature in 6.41 dramatically improved roaming wireless clients' connectivity. Thanks! Is it possible to add this functionality to "/caps-man access-list" as well? I am getting quite a few too-strong and too-weak disconnects on CAP managed APs:
Code: Select all12:32:29 caps,info XX:XX:XX:XX:XX:XX@cap6 connected 12:32:32 caps,info XX:XX:XX:XX:XX:XX@cap6 disconnected, too strong signal 12:32:37 caps,info XX:XX:XX:XX:XX:XX@cap6 connected 12:32:41 caps,info XX:XX:XX:XX:XX:XX@cap6 reassociating 12:32:41 caps,info XX:XX:XX:XX:XX:XX@cap6 connected 12:32:53 caps,info XX:XX:XX:XX:XX:XX@cap6 disconnected, too strong signal 12:32:56 caps,info XX:XX:XX:XX:XX:XX@cap6 connected 12:32:59 caps,info XX:XX:XX:XX:XX:XX@cap6 disconnected, too weak signal
/system certificates add type=LE hostname=remote.mikrotik.com challenge=DNS-manual services=SSL hotspot=profile1 ipsec-peer="name of the peer"
what a news...*) userman - added support for ARM and MMIPS platforms;
a miracle after 3 years
i emailed support and they said they don't plan on adding this feature for capsman. so they find this important for wireless but not capsman. very 'logical' right?The new "/interface wireless access-list allow-signal-out-of-range" feature in 6.41 dramatically improved roaming wireless clients' connectivity.
in our email conversation, they mentioned they want logs. maybe you could provide that. although i have a huge complaint about logs. it doesnt mention signal strength. i wish they'd consider linux type logs instead of windows type logs. logs should have useful detailed information and not just "signal too strong/weak"i emailed support and they said they don't plan on adding this feature for capsman. so they find this important for wireless but not capsman. very 'logical' right?The new "/interface wireless access-list allow-signal-out-of-range" feature in 6.41 dramatically improved roaming wireless clients' connectivity.
Hopefully, there was a misunderstanding. I suppose they could fix the bugs related to signal strength calculations instead of adding allow-signal-out-of-range. Obviously, I don't have clients connecting at above 120dBm (1,000 Mega Watt) even though we regularly see disconnects for "too strong signal."
These bugs make caps-man virtually useless for 802.11 clients. Modern OS wireless drivers often auto-reconnect, but older ones stay disconnected when the AP sends a de-auth frame. This is fine when the clients go out of range, but my customers have multiple devices less than 6 meters from an access point disconnecting and reconnecting because of "too strong/weak signal." In the logs I copied it was the same non-moving device for all the log entries.
I assume that Mikrotik is working on something to mitigate the signal issue in access-list. I'm not picky about how it gets fixed. If there is anything I can do to speed this along, please let me know.
/caps-man access-list
# Main rule to allow strong clients to have a high-speed connection
add action=accept ap-tx-limit=40000000 client-tx-limit=10000000 interface=all signal-range=-80..120
# Rule to prevent clients on the fringe from using 100% of the radio bandwidth
add action=accept ap-tx-limit=500000 client-tx-limit=500000 interface=all signal-range=-87..-80
add action=accept ap-tx-limit=200000 client-tx-limit=200000 interface=all signal-range=-120..-88
# Catch-all rule to test if there is a bug in signal-range matching code
add action=accept ap-tx-limit=100000 client-tx-limit=100000 interface=all signal-range=-120..120
# Catch-all rule to see if a rule without signal-range still checks the signal... it does
add action=accept ap-tx-limit=100000 client-tx-limit=100000 interface=all
jan/24 17:49:06 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal
jan/24 17:49:14 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal
jan/24 17:49:25 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal
jan/24 17:50:02 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal
jan/24 17:51:53 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal
jan/24 17:53:58 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal
jan/24 17:58:45 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal
jan/24 17:59:52 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal
jan/24 18:00:09 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal
jan/24 18:11:29 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal
jan/24 18:12:31 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal
jan/24 18:28:02 caps,info EC:88:92:XX:XX:F1@cap20 disconnected, too strong signal
jan/24 18:28:10 caps,info EC:88:92:XX:XX:F1@cap21 disconnected, too strong signal
jan/24 18:33:27 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal
jan/24 18:43:38 caps,info D0:22:BE:XX:XX:30@cap21 disconnected, too strong signal
jan/24 18:43:54 caps,info D0:22:BE:XX:XX:30@cap21 disconnected, too strong signal
jan/24 18:43:57 caps,info 90:68:C3:XX:XX:4A@cap12 disconnected, too strong signal
jan/24 18:55:41 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal
jan/24 18:57:32 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal
jan/24 19:06:20 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal
jan/24 19:06:24 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal
jan/24 19:38:43 caps,info F8:62:14:XX:XX:60@cap20 disconnected, too strong signal
jan/24 19:46:13 caps,info E4:58:E7:XX:XX:D0@cap10 disconnected, too strong signal
jan/24 19:47:10 caps,info 30:10:B3:XX:XX:60@cap12 disconnected, too strong signal
jan/24 19:55:38 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal
jan/24 20:01:54 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal
jan/24 20:13:45 caps,info F8:62:14:XX:XX:60@cap20 disconnected, too strong signal
jan/24 20:19:08 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal
jan/24 20:23:30 caps,info B8:E8:56:XX:XX:72@cap20 disconnected, too strong signal
jan/24 20:23:34 caps,info B8:E8:56:XX:XX:72@cap20 disconnected, too strong signal
jan/24 20:39:54 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal
jan/24 20:48:49 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal
jan/24 20:59:44 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal
jan/24 21:01:40 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal
jan/24 21:15:12 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal
Version 6.42rc14 has been released.
OK. Thank you..djtechwork - You installed latest rc version and User Manager package, can access "/tool user-manager" from CLI, but can not open it on WEB browser (x.x.x.x/userman)? If this is correct, then please generate supout file on your router and send it to support@mikrotik.com.
Hello Strods, i'll open a ticket right now, thank you.evince - Have you opened support ticket regarding this issue? We have not received any more complaints that this option would not work and have not experienced any more issues with it in our lab.
Well, from https://mikrotik.com/support:Good example why you should write to support not only report it in forum
This does not exactly encourage people to send anything to support@mikrotik.com unless they fulfil the formal requirement or are audacious or desperate enough to tryIf you have bought a RouterOS license or a RouterBOARD product, limited support service might be provided by e-mail for 30 days after the purchase by support@mikrotik.com. Contact your distributor for help and support, if device is not purchased from MikroTik directly.
If only the PM was working so that I could have sent my previous post to you directly rather than spamming the topic... I perfectly understand that the support team cannot deal with elementary questions of every end user, but to tell a misconfiguration from a bug or even a deliberate limitation (see userman and support of Radius fields required to support EAP) is sometimes not easy even for experienced specialists, so don't be surprised that not everyone dares to send what he believes to be a bug to support unless encouraged to do so by someone at the forum.If there is an actual issue with software and/or hardware, then such problems can be resolved only through support@mikrotik.com. None of users in forum, consultants or distributors will not be able to fix issues in RouterOS.
That's why PMs are disabled support@mikrotik.com is his PMIf only the PM was working so that I could have sent my previous post to you directly rather than spamming the topic...
That looks to me a bit selfish because all others have also no private messaging abilities.That's why PMs are disabled support@mikrotik.com is his PMIf only the PM was working so that I could have sent my previous post to you directly rather than spamming the topic...
well... in our email conversation, they finally said they would add this to their list..... didn't sound as if they were gonna add it immediately.Here is the config from one controller:
Code: Select all/caps-man access-list # Main rule to allow strong clients to have a high-speed connection add action=accept ap-tx-limit=40000000 client-tx-limit=10000000 interface=all signal-range=-80..120 # Rule to prevent clients on the fringe from using 100% of the radio bandwidth add action=accept ap-tx-limit=500000 client-tx-limit=500000 interface=all signal-range=-87..-80 add action=accept ap-tx-limit=200000 client-tx-limit=200000 interface=all signal-range=-120..-88 # Catch-all rule to test if there is a bug in signal-range matching code add action=accept ap-tx-limit=100000 client-tx-limit=100000 interface=all signal-range=-120..120 # Catch-all rule to see if a rule without signal-range still checks the signal... it does add action=accept ap-tx-limit=100000 client-tx-limit=100000 interface=all
Recent logs... I am pretty sure there aren't any client devices capable of 1 GigaWatt.Code: Select alljan/24 17:49:06 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal jan/24 17:49:14 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal jan/24 17:49:25 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal jan/24 17:50:02 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal jan/24 17:51:53 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal jan/24 17:53:58 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal jan/24 17:58:45 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal jan/24 17:59:52 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal jan/24 18:00:09 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal jan/24 18:11:29 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal jan/24 18:12:31 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal jan/24 18:28:02 caps,info EC:88:92:XX:XX:F1@cap20 disconnected, too strong signal jan/24 18:28:10 caps,info EC:88:92:XX:XX:F1@cap21 disconnected, too strong signal jan/24 18:33:27 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal jan/24 18:43:38 caps,info D0:22:BE:XX:XX:30@cap21 disconnected, too strong signal jan/24 18:43:54 caps,info D0:22:BE:XX:XX:30@cap21 disconnected, too strong signal jan/24 18:43:57 caps,info 90:68:C3:XX:XX:4A@cap12 disconnected, too strong signal jan/24 18:55:41 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal jan/24 18:57:32 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal jan/24 19:06:20 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal jan/24 19:06:24 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal jan/24 19:38:43 caps,info F8:62:14:XX:XX:60@cap20 disconnected, too strong signal jan/24 19:46:13 caps,info E4:58:E7:XX:XX:D0@cap10 disconnected, too strong signal jan/24 19:47:10 caps,info 30:10:B3:XX:XX:60@cap12 disconnected, too strong signal jan/24 19:55:38 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal jan/24 20:01:54 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal jan/24 20:13:45 caps,info F8:62:14:XX:XX:60@cap20 disconnected, too strong signal jan/24 20:19:08 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal jan/24 20:23:30 caps,info B8:E8:56:XX:XX:72@cap20 disconnected, too strong signal jan/24 20:23:34 caps,info B8:E8:56:XX:XX:72@cap20 disconnected, too strong signal jan/24 20:39:54 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal jan/24 20:48:49 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal jan/24 20:59:44 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal jan/24 21:01:40 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal jan/24 21:15:12 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal
Hello Strods, can you exlain this feature please?Version 6.42rc15 has been released.
Changes since previous release:
*) routerboard - added RouterBOOT "auto-upgrade" after RouterOS upgrade (extra reboot required);
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 expected or after crash.
Hello Strods, can you exlain this feature please?Version 6.42rc15 has been released.
Changes since previous release:
*) routerboard - added RouterBOOT "auto-upgrade" after RouterOS upgrade (extra reboot required);
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 expected or after crash.
That this means thaht the following SFP modules are working:*) sfp - improved SFP module compatibility;
Version 6.42rc15 has been released.
Changes since previous release:
*) dhcpv4-server - added "dns-none" option to "/ip dhcp-server network dns";
*) dhcpv6 - make sure that time is set before restoring bindings;
*) dhcpv6-client - added possibility to specify options;
*) dhcpv6-server - added DHCPv4 style user options;
*) fetch - added "output" option for all modes in order to return result to file, variable or ignore it;
*) ippool - added ability to specify comment;
*) radius - added warning if PPP authentication over RADIUS is enabled;
*) routerboard - added RouterBOOT "auto-upgrade" after RouterOS upgrade (extra reboot required);
*) sfp - improved SFP module compatibility;
*) userman - added support for ARM and MMIPS platform;
*) webfig - do not show "hw" option on non-ethernet interfaces;
*) winbox - added "crl-store" setting to certficate settings;
*) winbox - fixed typo from "UPtime" to "Uptime";
*) winbox - fixed Winbox closing when viewing graph which does not contain any data;
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 expected or after crash.
/ip dhcp-client add dhcp-options=hostname,clientid disabled=no interface=ether1
From the Codel Wiki:implementing a new type of queue such cake or fq_codel would be a great addition, what do you think?
Metarouter for arm?
From the Codel Wiki:
CoDel - in order to run well at line rate - requires the Linux 3.3 Byte Queue Limits . It has proven too hard to backport BQL to Linux 3.2 or earlier (an attempt for 3.2 exists, but no driver support), so you will need to upgrade to Linux 3.5 or later, and have a driver that supports BQL (only about 24 as of the present writing).
There you have your answer. You will have to wait for RouterOS V7 at least.
I think the same. For the last few years
- ROS7 will be ready in a year I think.
Is it like saying that there is no hope?I think the same. For the last few years
- ROS7 will be ready in a year I think.
Ok it is working, it was a problem of configuration.v6.42rc14, and still not workingirghost, raffav, Cha0s - Seems that we have found an issue with new TLS matcher. We will try to fix it as soon as possible;
5 years and counting for meI think the same. For the last few years
- ROS7 will be ready in a year I think.
I have been trying to test the ability to store downloaded data in a variable, though I haven't had any luck yet.Version 6.42rc15 has been released.
*) fetch - added "output" option for all modes in order to return result to file, variable or ignore it;
[admin@Mikrotik] > /tool fetch https://api.ipify.org/ output=user
status: finished
downloaded: 0KiBC-z pause]
total: 0KiB
duration: 0s
data: [My IP Address was here]
Confirmed, I see the same thing on rc12Hi.
I noted that PVID field has the value 65 as default when add a port to a bridge under the Winbox.
Under terminal is ok, set the value 1 to that field.
Great!*) winbox - allow to comment new object without committing it;
Please report exact cases. They fix it(in some cases the configured object goes down-up when you change the comment!)
I think it is easier for them to find all cases where this is handled incorrectly than for me trying to hunt them down and potentially miss some.Please report exact cases. They fix it(in some cases the configured object goes down-up when you change the comment!)
I understand that and I think it is great, because in the past I have sometimes gone wrong with that, e.g. because it stored something that was not configured correctly yet after doing a COPY, and I wanted to reset the comment as one of the first steps. In fact, it would be better when the comment is just a separate TAB on the object, like in Webfig.pe1chl - Seems that you misunderstood the fix. Assume that you add firewall rule, specify different parameters and do not press "Ok" button yet. Now you press "Comment" button and specify comment. When you press "Ok" on comment form, then in the past whole rule was added to firewall. Now "Ok" button on comment accepts only comment - it does not create a new rule right away.
OK, that was too annoying and I've installed 6.41.1 stable now. Fan stays off with cpu at 42C.I've updated a crs317 from rc6 to rc18 and now the fan is kicking in regularly. It seems it's trying to keep the cpu temperature below 40C as this is the point when it stops again.
There's nothing in the changelog about it and before that I've even seen cpu temperatures of almost 50C without the fan starting. Has this been changed?
At living room temperatures and idling the fan now iterates between running 30 seconds and being 1-2 minutes off. A little bit annoying and I guess also not the best running conditions for the fans on log term. Especially as it was totally quiet before and not remarkably hotter with like around 44C.
Please see viewtopic.php?f=3&t=129649#p638204Just missing BGP routing in multicore cpu....need this please !!!!
can someone give me a example how to use TLS-host i tryed to use facebook youtube, allot of site no one worked
/ip firewall filter
add action=passthrough chain=forward dst-port=443 protocol=tcp tls-host=*.facebook.com
What problems exist with macOS clients? Which OS X versions are affected? ( I'm running 6.41 on all CAPs and have no issues being reported by OS X clients...)*) wireless - fixed incompatibility with macOS clients;
If you were setting priorities for the WMM then sometimes the macOS clients didn't accept packets with some priorities.What problems exist with macOS clients? Which OS X versions are affected? ( I'm running 6.41 on all CAPs and have no issues being reported by OS X clients...)*) wireless - fixed incompatibility with macOS clients;
I meant to say that, instead of entering the max limit value you could assume a fixed value in percentage or at choice.Percentage of what?
Again, percentage of what? Interface speed? Some queues are not related to any particular interface.I meant to say that, instead of entering the max limit value you could assume a fixed value in percentage (e. g. 10%) or at choice.Percentage of what?
Of course, ROS should read the bandwidth instantly or after a set time.
Hi all,Version 6.42rc23 has been released.
Changes since previous release:
*) console - fixed "idpr-cmtp" protocol by changing its value from 39 to 38 (CLI only);
*) crs3xx - added initial hw-offload support for 802.3ad and balance-xor bonding
*) disk - fixed disk related processes becoming unresponsive after unplugging used disk;
*) kidcontrol - added initial support for "/ip kid-control" feature;
*) ppp - do not lose "/ppp profile" script configuration after other profile parameters are edited;
*) routerboard - properly report warnings under "/system routerboard" menu;
*) sniffer - fixed situation when "/tool sniffer packet" returned packets in incorrect order;
*) snmp - added w60g support;
*) upgrade - improved RouterOS upgrade process and restrict upgrade from RouterOS older than v5.16;
*) w60g - fixed "/interface w60g reset-configuration";
*) winbox - changed default bridge port PVID value to 1;
*) wireless - added initial support for "nstreme-plus";
*) wireless - improved compatibility with specific wireless AC standard clients;
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 expected or after crash.
Again, percentage of what? Interface speed? Some queues are not related to any particular interface.I meant to say that, instead of entering the max limit value you could assume a fixed value in percentage (e. g. 10%) or at choice.Percentage of what?
Of course, ROS should read the bandwidth instantly or after a set time.
Oh! Do we finally get 802.3ad link aggregation in HW on routeros - I've been waiting for that for a long time Any documentation on how to set that up?Version 6.42rc23 has been released.
Changes since previous release:
*) crs3xx - added initial hw-offload support for 802.3ad and balance-xor bonding
thats my question toonstreme-plus ? What is it ?
+thats my question toonstreme-plus ? What is it ?
+ 32984920nstreme-plus ? What is it ?
What does 'improve compatibility' mean ? Also speed related ?*) wireless - improved compatibility with specific wireless AC standard clients;
Same here, except by the message about free space.This broke my CHR installation, though I am not sure if 6.42rc23 is involved at all. The system was running 6.42rc20. I booted it and tried to update, the system told me there is not enough free space. After reboot it hangs at "Loading system with initrd".
Sure. But with "not enough free space available" the system should cancel upgrade and stay with old version, no?Main part of upgrade process happens on old version.
For example, rc21 -> rc23. If upgrade fails, then it is caused by rc21 version. As you can see in changelog we are still working on upgrade improvements. At the moment latest fixes are included in rc23. You can test upgrade improvements only when upgrade from rc23 to, for example, rc24 will be available.
Well...For example, rc21 -> rc23. If upgrade fails, then it is caused by rc21 version. As you can see in changelog we are still working on upgrade improvements. At the moment latest fixes are included in rc23. You can test upgrade improvements only when upgrade from rc23 to, for example, rc24 will be available.
Access the router over physical console, or netinstall it!this AM I Installed 6.42rc24 on my CCR1009 and now no connectivity --- Winbox cannot discover the Router
How do I recover from this please?
Strods,Version 6.42rc24 has been released.
Changes since previous release:
*) crs3xx - added initial hw-offload support for 802.3ad and balance-xor bonding
*) export - fixed "/system routerboard mode-button" compact export;
*) firewall - fixed "tls-host" firewall feature (introduced v6.41);
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 expected or after crash.t
I upgrade old rb711-5Hnd to 6.42rc24. There is no possibility set nstreme-plusNstreme-plus?
It would be nice to finally get LACP on the CRS125. the fact that we haven't got it by now and the changelog only mentions the CRS3XX series doesn't fill me with much hope though.@Strods
Since this new crs Poe series is out, so this version belongs to the same of crs1xx having the same features or it have new features available on crs3xx series?
Enviado do meu iPad usando Tapatalk
What does "initial" mean here?
*) crs3xx - added initial hw-offload support for 802.3ad and balance-xor bonding
Are you serious about this?At the moment we are not aware about any problems with upgrade starting from 6.42rc23 version.
On the first link, the rc24 hadn't out yet.Upgrade from 6.42rc20 (not from rc23):
viewtopic.php?f=21&t=129034&start=150#p641249
If I did understand post correctly, then this is about fresh installation, not an upgrade:
viewtopic.php?f=21&t=129034&start=150#p641262
Version from which upgrade was made is not mentioned:
viewtopic.php?f=21&t=129034&p=641436#p641289
[kaze@hueragem3 Downloads]$ sha256sum -c chr-6.42rc24.vdi.sha256
chr-6.42rc24.vdi: OK
Jiiiha!.... Will test prompty. Offcourse 4 tuble ip hash srcip srcport dstip dstport will come later right!?*) crs3xx - added initial hw-offload support for 802.3ad and balance-xor bonding
Well, I made some tests with CHR only.Did someone tried to do a downgrade to rc18 or more old and then upgrade to rc24?
I saw that 6.42rc20 is a bomb as origin of upgrade to rc23/rc24.
Ok So I tested on a CRS326-24G-2S+ but neither winbox nor cli shows anything anywhere. Initial maybe initial not ready for test yet or do I need to do something other then define bond and add the bond to the bridge?Jiiiha!.... Will test prompty. Offcourse 4 tuble ip hash srcip srcport dstip dstport will come later right!?*) crs3xx - added initial hw-offload support for 802.3ad and balance-xor bonding
/routing bgp peer
add default-originate=if-installed in-filter=X-in name=Y out-filter=X-out remote-address=1.1.1.2 tcp-md5-key=secret123 ttl=default remote-as=64512
[admin@router] > /routing bgp peer export
/routing bgp peer
add default-originate=if-installed in-filter=X-in name=Y out-filter=X-out remote-address=1.1.1.2 tcp-md5-key=secret123 ttl=default
Are we going to get any kind of response onto what nstreme-plus is? Please?
Are we going to get any kind of response onto what nstreme-plus is? Please?
too secret to tell everyone!
(found using google)nstream is a wireless protocol mikrotik proprietary.
Googling nstreme is not the answer, protocols can vary vastly. nstreme and NV2 (nstreme version 2) are entirely different. I want details on what is actually different in nstreme plus and would like to know if it was developed specifically for any type of hardware (there have been many complaints with nstreme and nv2 on AC). We have abandoned mikrotik for wireless on 2.4 and 5ghz but still rely on them for some remaining 900mhz customers. I want to know if this will be applicable for us.Are we going to get any kind of response onto what nstreme-plus is? Please?
too secret to tell everyone!
If this is correct:(found using google)nstream is a wireless protocol mikrotik proprietary.
Then I guess that nstreme-plus is the same as nstreme with some more funtion.
+1Nstreme plus, any hints?
I'm about to update a couple of test units...
This XML file does not appear to have any style information associated with it. The document tree is shown below.
<Error>
<Code>AccessDenied</Code>
<Message>Access Denied</Message>
<RequestId>C8CAC51C5479E518</RequestId>
<HostId>
3aRnHLgJqfV4AKF81siOXhSgng8kYK1qYiDci7AL7PPOYkAmt0jMpV6AGcyVhvyLNrws/PYiJqQ=
</HostId>
</Error>
That's exactly what we fearedNstreme-plus is almost the same Nstreme protocol but with some additional tweaks to get better compatibility with latest ARM based wireless chipset hardware that we started to release recently.
So no sync options or anything like that?Nstreme-plus is almost the same Nstreme protocol but with some additional tweaks to get better compatibility with latest ARM based wireless chipset hardware that we started to release recently.
That's exactly what we fearedNstreme-plus is almost the same Nstreme protocol but with some additional tweaks to get better compatibility with latest ARM based wireless chipset hardware that we started to release recently.
again only patchwork and no innovation
*) radius - increase allowed RADIUS server timeout to 60s;
nstreme Connection with this RC ist not working on LHG acNstreme-plus is almost the same Nstreme protocol but with some additional tweaks to get better compatibility with latest ARM based wireless chipset hardware that we started to release recently.
Hm, this is probably the reason why the wireless product line contains much more items than the wireless-less one.Mate, Mikrotik is mainly routing. Wireless is a peripheral offering, not core business for them. They do not have the horsepower to pursue both of them equally. If you want wireless, go to one of the guys that do that as their main business and then combine the best of both worlds.
*) radius - increase allowed RADIUS server timeout to 60s;
To add an important reason to the too short limit problem of timeout in radius:
Successful authentications are answered immediately (in order of milliseconds if possible), but to protect the server from brute-force attacks and DOS-type attacks, radius is usually configured in order that in case of failed authentication, the response is delayed for a longer time (usually 4 or 5 seconds). In that way the attack slows down and is not effective.
For that it is important to be able to configure a "large" timeout time.
Nstreme-plus is almost the same Nstreme protocol but with some additional tweaks to get better compatibility with latest ARM based wireless chipset hardware started to release recently.+ 32984920nstreme-plus ? What is it ?
And you all miss upon proxied multifactor stuff where upstream servers is waiting on user action on other device. The timeout need to be high so that user have time to respond and router not destroying auth process by resending same request again and being denied due to replay attack.*) radius - increase allowed RADIUS server timeout to 60s;
To add an important reason to the too short limit problem of timeout in radius:
Successful authentications are answered immediately (in order of milliseconds if possible), but to protect the server from brute-force attacks and DOS-type attacks, radius is usually configured in order that in case of failed authentication, the response is delayed for a longer time (usually 4 or 5 seconds). In that way the attack slows down and is not effective.
For that it is important to be able to configure a "large" timeout time.
This isn't actually true as the radius server will return either an accept or deny (if bad password) immediately. This timeout only affects no response from the radius server before it tries to send the exact same packet again. Its still very helpful when your radius server is at a remote site across a high latency link.
http://networkradius.com/doc/3.0.10/raddb/security.htmlThis isn't actually true as the radius server will return either an accept or deny (if bad password) immediately. This timeout only affects no response from the radius server before it tries to send the exact same packet again. Its still very helpful when your radius server is at a remote site across a high latency link.*) radius - increase allowed RADIUS server timeout to 60s;
To add an important reason to the too short limit problem of timeout in radius:
Successful authentications are answered immediately (in order of milliseconds if possible), but to protect the server from brute-force attacks and DOS-type attacks, radius is usually configured in order that in case of failed authentication, the response is delayed for a longer time (usually 4 or 5 seconds). In that way the attack slows down and is not effective.
For that it is important to be able to configure a "large" timeout time.
Strods?What does "initial" mean here?
*) crs3xx - added initial hw-offload support for 802.3ad and balance-xor bonding
Response to my ticket to support@ is that they plan on addressing it in 6.42 eventually, but it doesn't look like it's been touched yetIs IGMP snooping fixed in rc24 or in 6.41.2?
Got yelled at last time so I've left it off for now
6.42rc24 ....................................... 6.42rc27 how long will this last?
As it was mentioned several times before in this topic. Upgrade happens on old version
6.42rc17 - 6.42rc24 are bad versions, so if you want to upgrade from these versions, use netinstall from the beginning.
As it was mentioned several times before in this topic. Upgrade happens on old version
6.42rc17 - 6.42rc24 are bad versions, so if you want to upgrade from these versions, use netinstall from the beginning.
Then why when upgrading from version 6.42rc20 to version 6.42rc27 the router again ceased to give signs of life?No, only if older version was 6.42rc17 - 6.42rc24
No, only if older version was 6.42rc17 - 6.42rc24
Then why when upgrading from version 6.42rc20 to version 6.42rc27 the router again ceased to give signs of life?No, only if older version was 6.42rc17 - 6.42rc24
Because you are upgrading from bad version. upgrade from any of my previously mentioned rc versions most likely will fail.
You don't have to believe me,but upgrade from rc26 to rc27 works, so there is very big chance that upgrade from rc27 will also work It is still an RC version anyway so anything can happen.And we should just believe you when you say it all works perfectly again starting from the untested ( by users ) 6.42.rc27 version?
Just a heads up, Mikrotik usually has some issue with Intel cards, they generally get them fixed, but Intel's drivers are garbage.
You don't have to believe me,but upgrade from rc26 to rc27 works, so there is very big chance that upgrade from rc27 will also work It is still an RC version anyway so anything can happen.And we should just believe you when you say it all works perfectly again starting from the untested ( by users ) 6.42.rc27 version?
I do not see the reason for complains, RC was always test version for those who are willing to test it on routers in test environment where netinstalling router is not a problem.
If you put test version on production router or only remotely reachable routers then that is on you.
@edinorog Yes, if you upgrade from bad version upgrade may fail even if you upgrade to final 6.42.
Developer doing a debug? Well, they know how to don't the wrong things passively.Why isn't there a test that you can run as developers to see wether you can use a version to upgrade to a version with a higher number? Should be a basic test that prevents us from heaving these issues.
thanks for adding that... but i hope the spelling within winbox is allow-signal-out-of-range*) capsman - added "allow-signal-out-off-range" option for Access List entries (CLI only);
Where is the Dude client? Again?What's new in 6.42rc27 (2018-Feb-14 11:53):
Okay this is indeed perfectly true, but why do support insist on a 6.41.1 and 6.41.2 tickets running RC on production routers or else the fix will have to wait until 6.42 final?Please remember what we have been telling from the first public rc release - rc versions are provided for MikroTik enthusiasts who are ready to Netinstall router if necessary. Versions are tested on few routers and released right away. If you are experiencing issues with an upgrade and do not want to Netinstall devices any more, then you should wait for a final 6.42 release.
As it was mentioned several times before in this topic. Upgrade happens on old version
6.42rc17 - 6.42rc24 are bad versions, so if you want to upgrade from these versions, use netinstall from the beginning.
Answered many times before! The old version is the one that performs upgrade. We can't fix a released and installed version.As it was mentioned several times before in this topic. Upgrade happens on old version
6.42rc17 - 6.42rc24 are bad versions, so if you want to upgrade from these versions, use netinstall from the beginning.
Will there be no fix that is ist possible to upgrade from one of this versions?
Or what a bout a downgrade e.g. from 6.42.rc20 to 6.41.2 ?
Thank you very, very much!!What's new in 6.42rc28 (2018-Feb-16 07:02):
*) chr - added "virtio-scsi" driver on KVM installations;
*) chr - added support for Hyper-V ballooning;
*) chr - added support for Hyper-V guest quiescing;
*) chr - added support for Hyper-V host-guest file transfer;
*) chr - added support for Hyper-V integration services;
*) chr - added support for Hyper-V static IP injection;
*) chr - added support for NIC hot-plug on VMware and Xen installations;
Well, you definitely cannot, but I assume it would be technically possible to provide a dedicated application (as an npk file) which would both perform the configuration upgrade and then install the software upgrade instead of the running version. I understand that this would be way too much effort to spend on every single RC version just to save the adrenaline addicts who use RC for machines they cannot easily reach for netinstall, but I had a case of losing conifguration when upgrading from 6.41 stable to 6.42rc9. Netinstall wasn't necessary in this case, but I would have been very disappointed if that would have happened to me when upgrading the 6.41 to 6.41.2 1500 km crow line away on the same model (which luckily didn't happen).We can't fix a released and installed version.As it was mentioned several times before in this topic. Upgrade happens on old version
Will there be no fix that it is possible to upgrade from one of this versions?
Apologies, this is probably because my imagination was not wild enough to admit that the task of downloading a binary and applying it could go so much wrong So I've assumed that the configuration conversion must be the culprit.I think you are mixing two different things. Upgrade failure had nothing to do with configuration. Software installation process was redesigned, which led to "bricked" (unable to boot) routers in those RC versions.
Oh no... I also had a CHR running same RC in qemu/kvm and bang wouldn't even boot. Quickest fix was I had backup image of the CHR and always download current backups. Copied over current image and then uploaded the backup and restored, since its the same CHR.6.42rc28 wrecked my CHR on libvirtd / Qemu KVM setup. Virtio network interfaces aren't recognized anymore.
Do not install 6.42rc28 on KVM CHR!
Still trying to salvage this thing, will write more later...