MikroTik

Posted: **Fri Feb 02, 2018 7:22 am**

RouterOS version 6.41.1 has been released in public "current" 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.41.1 (2018-Jan-30 10:26):

*) bridge - fixed "mst-override" export;
*) bridge - fixed allowed MSTI priority values;
*) bridge - fixed ARP option changing on bridge (introduced v6.41);
*) bridge - fixed hw-offload disabling for Mediatek and Realtek switches when STP/RSTP configured;
*) bridge - fixed hw-offload disabling when adding a port with "horizon" set;
*) bridge - fixed IGMP Snooping after disabling/enabling bridge;
*) bridge - fixed interface list moving in "/interface bridge port" menu;
*) bridge - fixed repetitive port "priority" set;
*) bridge - fixed situation when packet could be sent with local MAC as dst-mac;
*) bridge - fixed VLAN filtering when "use-ip-firewall" is enabled (introduced in v6.41);
*) bridge - properly update "actual-mtu" after MTU value changes (introduced v6.41);
*) btest - fixed TCP test accuracy when low TX/RX rates are used;
*) certificate - do not use utf8 for SCEP challenge password;
*) certificate - fixed PKCS#10 version;
*) crs317 - improved transmit performance between 10G and 1G ports;
*) crs326 - fixed possible packet leaking from CPU to switch ports;
*) crs3xx - hide deprecated VLAN related settings in "/interface ethernet switch port" menu;
*) detnet - additional work on "detect-internet" implementation;
*) dhcpv4-server - fixed framed and classless route received from RADIUS server;
*) discovery - fixed discovery related settings conversation during upgrade from pre-v6.41 discovery implementation (introduced v6.41);
*) dude - fixed e-mail notifications when default port is not used;
*) firewall - fixed "tls-host" firewall feature (introduced v6.41);
*) firewall - limited maximum "address-list-timeout" value to 35w3d13h13m56s;
*) ike1 - fixed "aes-ctr" and "aes-gcm" encryption algorithms (introduced v6.41);
*) ike2 - delay rekeyed peer outbound SA installation;
*) ike2 - improve half-open connection handling;
*) ipsec - properly update IPsec secret for IPIP/EoIP/GRE dynamic peer;
*) log - properly report bridge interface MAC address changes;
*) netinstall - improved LTE package description;
*) netinstall - properly generate skins folder when branding package is installed;
*) ovpn - fixed resource leak on systems with high CPU usage;
*) ppp - changed default value of "route-distance" to 1;
*) ppp - fixed change-mss functionality in some specific traffic (introduced in v6.41);
*) radius - added warning if PPP authentication over RADIUS is enabled;
*) radius - increase allowed RADIUS server timeout to 60s;
*) rb1100ahx4 - fixed reset button responsiveness when regular firmware is used;
*) rb433/rb450 - fixed port flapping on bridged Ethernet interfaces if hw-offload is enabled (introduced in v6.41);
*) routerboot - fixed missing upgrade firmware for "ar7240" devices;
*) sfp - improved SFP module compatibility;
*) snmp - allow also IPv6 on default public community;
*) tile - fixed USB device speed detection after reboot;
*) traffic-flow - do not count single extra packet per each flow;
*) webfig - added support for proper default policies when adding script or scheduler job;
*) webfig - fixed bridge port sorting order by name;
*) webfig - fixed MAC address ordering;
*) webfig - fixed wireless snooper address, SSID and other column ordering;
*) winbox - added "dhcp-option-set" to DHCP server;
*) winbox - allow to specify "to-ports" for "action=masquerade";
*) winbox - do not show "hw" option on non-Ethernet interfaces;
*) winbox - do not show VLAN related settings in switch port menu on CRS3xx boards;
*) wireless - updated "Czech Republic" country 5.8 GHz frequency range;

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 crash.

Posted: **Fri Feb 02, 2018 7:33 am**

If you use Winbox as a management tool, to ensure the very best customer experience, we have also released new Winbox version v3.12. Please upgrade your Winbox!
viewtopic.php?f=21&t=130319

Posted: **Fri Feb 02, 2018 8:01 am**

I was upgrading some routers from previous versions to 6.41, when all of a sudden I notice the most recent version is now 6.41.1.

I noticed that on 6.41.1 I am unable to change the neighbor discover-setting. Shown below are console output from a 6.41 router and a 6.41.1 router. They are the same router. I performed the first neighbor discovery setting change from !dynamic to all, then upgraded the router from 6.41 to 6.41.1. When the router came back online, the neighbor discovery setting was reset from all to !dynamic, and I am unable to get it to change at all now, even after multiple reboots. This occurs from the console and winbox. Interesting...

# running v6.41 - can make changes to neighbor discovery-settings
[user@router] > /ip neighbor discovery-settings 
[user@router] /ip neighbor discovery-settings> print 
  discover-interface-list: !dynamic
[user@router] /ip neighbor discovery-settings> set discover-interface-list=all 
[user@router] /ip neighbor discovery-settings> print 
  discover-interface-list: all
[user@router] /ip neighbor discovery-settings> /system package update install 

# now running v6.41.1 - after reboot - can NOT make changes to neighbor discovery-settings from cli or winbox
[user@router] /ip neighbor discovery-settings> /ip neighbor discovery-settings 
[user@router] /ip neighbor discovery-settings> print 
  discover-interface-list: !dynamic
[user@router] /ip neighbor discovery-settings> set discover-interface-list=all 
[user@router] /ip neighbor discovery-settings> print 
  discover-interface-list: !dynamic
[user@router] /ip neighbor discovery-settings>

Posted: **Fri Feb 02, 2018 8:29 am**

bluecrow76 - We can confirm that there is this issue in this particular release. We will include fix for this problem in next public RouterOS release. However, this is cosmetic issue. If you, change value, then it will be used, but print and export will show incorrect value.

Posted: **Fri Feb 02, 2018 9:30 am**

I just noticed that a number of my devices lost their system note.

Posted: **Fri Feb 02, 2018 11:08 am**

bluecrow76 - We can confirm that there is this issue in this particular release.

While you are at fixing this, please also fix the problem that it is no longer possible to run neighbor discovery
for a fixed set (not all) of static interfaces plus on the dynamic interfaces. This was possible before 6.41 by
enabling it on specific interfaces and setting default-for-dynamic=yes
As it is now only possible to select a single interface list, one can not run it on the configured interface list
AND on "dynamic". And "dynamic" cannot be a member of the interface list (it can be included, but that does not work).

Posted: **Fri Feb 02, 2018 11:10 am**

You can use include/exclude configuration under interface list settings.

For example:
/interface list
add name=test exclude=dynamic

Posted: **Fri Feb 02, 2018 11:27 am**

tls-host now seems to work very nice!
However, is there any way to block a list of hosts, or I have to create separate rule for everysite I want to block?

Posted: **Fri Feb 02, 2018 12:05 pm**

You can use include/exclude configuration under interface list settings.

For example:
/interface list
add name=test exclude=dynamic

I tried that with "add name=discover include=dynamic" but it does not work.
I did not see the dynamic interfaces listed under the interface list menu (I would expected entries to show up with a D in column 1, as in other parts of RouterOS),
and also I did not get working neighbor discovery on those interfaces. I even tried to reboot after configuring it that way. Doesn't help.
But when I select "all" in the discovery interface list, it works OK on dynamic interfaces. However, it is now also enabled on all static interfaces.

Posted: **Fri Feb 02, 2018 12:25 pm**

matiaszon - Depends on situation. You can add domain names to address list and then drop access to specific dst-address-list.
pe1chl - All, none and dynamic are built-in interface lists. Interfaces belonging to these interface lists will not show up as list members.

Posted: **Fri Feb 02, 2018 2:03 pm**

pe1chl - All, none and dynamic are built-in interface lists. Interfaces belonging to these interface lists will not show up as list members.

Ok, that is fine by itself, but they are not *becoming* list members either, when dynamic is specified for include!
So, when the neighbor discovery is configured with interface-list=discover, and in that list there are a couple of static interfaces plus include=dynamic,
you won't get neighbor discovery on these dynamic interfaces. That is the problem I encountered when migrating from 6.40.5 to 6.41, see also
the report in the 6.41 topic.

Posted: **Fri Feb 02, 2018 2:13 pm**

After this update, static routes on Ipv6 stopped working. I had to return to the dynamic receipt of the address from the provider. Static pool stopped giving normally addresses and routes

Posted: **Fri Feb 02, 2018 3:24 pm**

Reset configuration on RB750Gr3 is removing current configuration but not restore default one.
Tested on 6.41 and 6.41.1.

Posted: **Fri Feb 02, 2018 3:44 pm**

IPSec tunnel is not established any longer in 6.41.1. Is this a known problem?

Posted: **Fri Feb 02, 2018 4:05 pm**

Enable ipsec logs, generate supout file right after tunnel fails and send the file to support.

Posted: **Fri Feb 02, 2018 6:07 pm**

Noticed today after upgrading to 6.41.1 that proxy-arp and local-proxy-arp seem to be broken both on 6.41 and 6.41.1 (FW upgraded to match) when set on a bridge. Device: hAP AC.

Reverting back to 6.39.3 (FW 6.41.1), restores proxy-arp amd local-proxy-arp, but only on a full software bridge.

Setting an hybrid bridge, i.e. setting all ethernets as slaves of another ether (ether2 in my case as ether1 is the WAN), doesn't work either, guess this being firmware related.

Posted: **Fri Feb 02, 2018 6:41 pm**

CCR1016-12G Kernel fails on 6.41.1 every few hours.

It did it once, so after another reboot, its failed again about a hour or so later.

Sent sipout after second reboot and failure - [Ticket#2018020222004914] RE: Kernel failure 6.41. [...]

Posted: **Fri Feb 02, 2018 7:42 pm**

Re: v6.41.1 [current] (DNS problem)

CHR running v6.41.1
-with-
Winbox v3.12

I can no longer use tools traceroute and perform a traceroute to www.yahoo.com
It appears that the CHR ROS does not do a DNS lookup

However - I can traceroute using an IP address for www.yahoo.com ( 206.190.39.43 )

North Idaho Tom Jones

Posted: **Fri Feb 02, 2018 8:32 pm**

pe1chl - We will look into this issue;
SirPrikol - Did you downgrade to 6.41 routes where working and upgrade to 6.41.1 and they are not working again? Can you provide supout file to support@mikrotik.com which would be generated while there are such routes on router;
feris - Do you experience such issue on one particular device? What does "/system default-configuration print" show;
pukkita - Please send supout file to support@mikrotik.com. Generate it while you are running on this version but ARP settings are not working as suspected. Did you try to set settings and then reboot device;
TomjNorthIdaho - If you downgrade to 6.41 then it start to work again? If it does, then upgrade back to this version once more and test if proble is still there;

Posted: **Fri Feb 02, 2018 9:20 pm**

Re: v6.41.1 [current] (DNS problem)

CHR running v6.41.1
-with-
Winbox v3.12

I can no longer use tools traceroute and perform a traceroute to www.yahoo.com
It appears that the CHR ROS does not do a DNS lookup

However - I can traceroute using an IP address for www.yahoo.com ( 206.190.39.43 )

North Idaho Tom Jones

Hey Tom,

Its working fine on my CHR 6.41.1 just did a traceroute to www.yahoo.com

Cheers
David

Posted: **Fri Feb 02, 2018 9:25 pm**

CCR1016-12G Kernel fails on 6.41.1 every few hours.

It did it once, so after another reboot, its failed again about a hour or so later.

Sent sipout after second reboot and failure - [Ticket#2018020222004914] RE: Kernel failure 6.41. [...]

Okay there is a pattern here. Its been up perfectly after it kernel failed and I left it running, now 4 hours. Log shows that upon rebooting the CCR on the front display panel right upon reboot these are the first two logs:

Router was rebooted without proper shutdown, probably kernel failure
Kernel failure in previous boot

Posted: **Fri Feb 02, 2018 10:22 pm**

matiaszon - Depends on situation. You can add domain names to address list and then drop access to specific dst-address-list.

But thi won't work on https sites. I am talking about tls-host functionality. How can you block more than 1 site using this feature?

Posted: **Fri Feb 02, 2018 10:58 pm**

With tls-host you have to have new rule for each host.

I do not understand what do you man. Why do you assume that you can not block HTTPS traffic with address list?

/ip firewall address-list
add list=block address=www.example1.com
add list=block address=www.example2.com
/ip firewall filter
add chain=forward action=drop dst-address-list=block

Posted: **Fri Feb 02, 2018 11:32 pm**

With tls-host you have to have new rule for each host.

I do not understand what do you man. Why do you assume that you can not block HTTPS traffic with address list?

/ip firewall address-list
add list=block address=www.example1.com
add list=block address=www.example2.com
/ip firewall filter
add chain=forward action=drop dst-address-list=block

I think this is about something like this:

/ip firewall address-list
add list=block tls-host=*.example1.com
add list=block tls-host=*.example2.com
/ip firewall filter
add chain=forward action=drop dst-address-list=block

He wants to reuse lists with tls-host matcher.

Posted: **Sat Feb 03, 2018 12:57 am**

Issue of flooding all bridge ports with IGMP Snooping on stream change (ie channel surfing, flood lasts about 1-2 sec) or interface removal (ie dynamic interface leaves bridge, flood lasts 60+ sec) still exists on this version.

How to easily replicate:

Method a) Put multiple interfaces on the IGMP-Snooped bridge, start streaming with one (ie an IPTV channel), leave one stream and join another (ie change channels) all interfaces on the bridge start to get flooded with the stream for a few seconds. Rapidly change streams (ie channel surf), you can easily flood all interfaces with 80-100mbit of traffic for a ~8mbit per stream scenario.

Method b) Put multiple interfaces on the IGMP-Snooped bridge, start streaming with one, remove it from the bridge, all interfaces on the bridge start to get flooded with the stream for 60+ seconds.

Makes IGMP Snooping kinda useless, when a group's doesn't have any members but is still getting to the router, it needs to get blackhole'd, not broadcasted.

Posted: **Sat Feb 03, 2018 5:16 am**

Minor issue that maybe not a lot of people will see:

My bridge interface MAC address changed after upgrade from 6.40 to 6.40.1, or possibly due to the reboot.

This is a wAP-ac. I set it up as a regular access point by adding the ethernet interface to the bridge, then setting dhcp-client to listen on the bridge interface.

I use a static DHCP setup using the ISC dhcp server on another machine.

Layer 2 services were working (Wifi allowed clients to connect to the internet and get a DHCP address), but the wAP-ac itself was not able to get an IP address after the reboot after upgrade.

I was able to log into the wAP-ac with mac-telnet and understand the problem, then I put the new MAC address into my dhcp server and everything was fine.

So the bridge MAC definitely changed at some point.

Posted: **Sat Feb 03, 2018 9:54 am**

After upgrade to 6.41.1 from 6.41 I have the problem, with /tool fetch, gives timeout for larger downloads.

Original fetch from www.squidblacklist.org, filesize around 3.7 mb fails.

Also fetch from internal:
/tool fetch address=10.1.0.30 host=10.1.0.30 mode=http src-path=/resources/drop.malicious.rsc dst-path=disk1/drop.malicious.rsc
timed out and failed.

Normal download via curl from the origin site works without any issue.

Runs on a CCR1009-8G-1S-1S+..

Other does see this also?

Posted: **Sat Feb 03, 2018 12:31 pm**

acruhl, was the mac address of the bridge originally set as administrative mac address? Or it was just dynamic before the upgrade?

Posted: **Sat Feb 03, 2018 1:24 pm**

feris - Do you experience such issue on one particular device? What does "/system default-configuration print" show;

I have at the moment only RB750Gr3 for test purposes, 6.39.3 was creating default configuration without problem.
Command shows default configuration script. I can post it on Monday.

Posted: **Sat Feb 03, 2018 2:08 pm**

All my RBmAP2n devices that were running a hotspot with a customised set of files have been reset to the default hotspot setup. The customisations were all stored in a directory under /flash but since the upgrade, the subdirectory has disappeared (though /flash is still there) and I now have a new root entry called disk that has the default hotspot files under it.

Is that to be expected????

Posted: **Sat Feb 03, 2018 2:58 pm**

acruhl, was the mac address of the bridge originally set as administrative mac address? Or it was just dynamic before the upgrade?

Sorry, I meant 6.41 to 6.41.1...

I didn't statically set the MAC address. I just added the wired interface to the bridge is all.

Looking at my notes on DHCP server config, the bridge MAC changed from being the same as one of the WLAN MACs to the same as the wired ethernet interface.

Again. I'm not 100% sure if it was just a reboot that caused this or the upgrade, but I suspect it was the upgrade.

Posted: **Sat Feb 03, 2018 3:21 pm**

All my RBmAP2n devices that were running a hotspot with a customised set of files have been reset to the default hotspot setup. The customisations were all stored in a directory under /flash but since the upgrade, the subdirectory has disappeared (though /flash is still there) and I now have a new root entry called disk that has the default hotspot files under it.

Is that to be expected????

Possibly the same issue that dropped the system note for me? I guess it is not expected.

Posted: **Sat Feb 03, 2018 3:30 pm**

... in a directory under /flash but since the upgrade, the subdirectory has disappeared (though /flash is still there) and I now have a new root entry called disk that has the default hotspot files under it.

Is that to be expected????
Possibly the same issue that dropped the system note for me? I guess it is not expected.

I'd say it is a known bug of 6.41.1. From change list of 6.42rc20:

*) filesystem - fixed situations when "/flash" directory lost files after upgrade;

Posted: **Sat Feb 03, 2018 3:48 pm**

All my RBmAP2n devices that were running a hotspot with a customised set of files have been reset to the default hotspot setup. The customisations were all stored in a directory under /flash but since the upgrade, the subdirectory has disappeared (though /flash is still there) and I now have a new root entry called disk that has the default hotspot files under it.

Is that to be expected????

Hap AC upgraded from 6.41 - same thing happened to disk... and besides that it cleared my bridge ports config with all VLANs

Posted: **Sat Feb 03, 2018 5:04 pm**

With tls-host you have to have new rule for each host.

I do not understand what do you man. Why do you assume that you can not block HTTPS traffic with address list?

/ip firewall address-list
add list=block address=www.example1.com
add list=block address=www.example2.com
/ip firewall filter
add chain=forward action=drop dst-address-list=block

For example, I want to block facebook ad youtube sites which are https. I can do it with address list, but need to find all domains (i.e.xxx.facebook.com, yyy.facebook.com, etc.) and put them on the list. With tls-host functionality, I can put *facebook.com and it's done. I need to create the similar rule for youtube and all other sites I want to block. My qustion is, if there is (will be) any possibility to create a list containing all hosts I want to block? Or maybe there is any other way to block whole domains, like it is mentioned few posts below

/ip firewall address-list
add list=block address=*.example1.com
add list=block address=*.example2.com
/ip firewall filter
add chain=forward action=drop dst-address-list=block

Posted: **Sat Feb 03, 2018 5:06 pm**

Can you please give more details about this:
*) sfp - improved SFP module compatibility;

thank you

Posted: **Sat Feb 03, 2018 10:08 pm**

What about 6.40.6? Could we expect it?

Posted: **Sat Feb 03, 2018 10:27 pm**

hello,

noticed after upgrading to 6.41 and 6.41.1 dhcp server lease script is not executed any longer.
last-started timestamps / run-count properties below were set / incremented from manual executions only...
My lease_debug script is not executed when client (dis)connects.

Can anybody confirm?

/ip dhcp-server
add address-pool=dhcp disabled=no interface=bridge lease-script="/system script lease_debug" lease-time=5m name=dhcp


/system script> print
1   name="debug_lease" owner="quirin" policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon last-started=feb/03/2018 21:03:18 run-count=16 
     source=:log info "leaseBound: $leaseBound - leaseServerName: $leaseServerName - leaseActMAC: $leaseActMAC - leaseActIP: $leaseActIP"

Posted: **Sun Feb 04, 2018 4:08 am**

Hi, as I can see there are some issues with dhcp server on all ethernet/wlan interfaces. After creating a new dhcp server, disabling it makes it permanent 'red' after re-enabling again.
Supot sended to support.

Posted: **Sun Feb 04, 2018 6:24 pm**

at hotspot with user manager (profile with 2 shared users) when i reboot the router after devices can not automatic login with mac-cookie. at log it says "login failed simultaneous session limit reached" and hotspot login page appears.

ps why i cannot attach a picture? where is the option?

Posted: **Sun Feb 04, 2018 8:54 pm**

Re: v6.41.1 [current] (DNS problem)

CHR running v6.41.1
-with-
Winbox v3.12

I can no longer use tools traceroute and perform a traceroute to www.yahoo.com
It appears that the CHR ROS does not do a DNS lookup

However - I can traceroute using an IP address for www.yahoo.com ( 206.190.39.43 )

North Idaho Tom Jones

IIRC, traceroute in tools uses the clients DNS, so maybe check your pc dns settings. Terminal uses RouterOS DNS settings. Or vica versa, can't remember anymore ;-(

Posted: **Sun Feb 04, 2018 9:37 pm**

works good so far!

Posted: **Sun Feb 04, 2018 10:35 pm**

viewtopic.php?f=21&t=128915&start=250#p638556

Seems to be fixed in this version. Great

Posted: **Sun Feb 04, 2018 11:16 pm**

CCR1016-12G Kernel fails on 6.41.1 every few hours.
It did it once, so after another reboot, its failed again about a hour or so later.
Sent sipout after second reboot and failure - [Ticket#2018020222004914] RE: Kernel failure 6.41. [...]
Okay there is a pattern here. Its been up perfectly after it kernel failed and I left it running, now 4 hours. Log shows that upon rebooting the CCR on the front display panel right upon reboot these are the first two logs:
Router was rebooted without proper shutdown, probably kernel failure
Kernel failure in previous boot

Hi!
The similar situation was with ccr1009-7G on 6.41 after update to 6.41.1 nothing changed.
What’s happened:
On 6.41 ccr1009 suddenly made several reboots with “kernel failure“ plus made 2 supout files in / “root” directory.
For next days - no reboots.
Sent files to mikrotik support to check out problems.

But, after first “kernel error” reboots - connected USB flash disk disappeared. On USB it was “disk1” with configs, backups, etc.
I tried to change USB flash disk to another, tried to change Mikrotik USB cables, tried to “reset USB power” on port (in console and Winbox) - everything was with no luck

Once I connected it, but 3 or 4 hours later USB disappeared again with supout file, but without “kernel error” reboots.
Update to 6.41.1 nothing changed with this situation - logs in memory, cannot connect USB flash.
DiM

Posted: **Mon Feb 05, 2018 12:50 am**

I just noticed that a number of my devices lost their system note.

Weird, since /system note doesn't actually do anything but create or edit a physical file named sys-note.txt ... so you must have lost the file.

Posted: **Mon Feb 05, 2018 6:16 am**

any documentation or tutorial for new feature, internet detect?

Posted: **Mon Feb 05, 2018 8:21 am**

eworm, mobdoc,
sindy - We are sorry for any inconvenience caused. We will fix this problem in 6.41.2 RouterOS release;
matiaszon - You can not use multiple “tls-host” entries within the same firewall rule. If you need to use “tls-host” functionality, then you have to add multiple rules. If all you need is to block domain, then you can use address list instead;
NetflashTechnical, ithierack, theq, Clauu, freemannnn, nuffrespect - Please generate supout file on your router while you see such behavior and send this file to support@mikrotik.com
feris - Do you see such behavior on single unit? Are you sure that default configuration on this device is not replaced with another one by using Netinstall;
acruhl - Please generate supout file on your router while you see such behavior and send this file to support@mikrotik.com
miha99 - Please provide configuration that you had on your unit to support@mikrotik.com and supout file from router which would be generated after an upgrade showing that old configuration is lost;
diablonet - This fix has introduced improvements related to auto negotiation with different SFP modules;
BartoszP - Most likely - yes;
blackhiden - https://wiki.mikrotik.com/wiki/Manual:Detect_internet

Posted: **Mon Feb 05, 2018 9:21 am**

acruhl, was the mac address of the bridge originally set as administrative mac address? Or it was just dynamic before the upgrade?
Sorry, I meant 6.41 to 6.41.1...

I didn't statically set the MAC address. I just added the wired interface to the bridge is all.

Looking at my notes on DHCP server config, the bridge MAC changed from being the same as one of the WLAN MACs to the same as the wired ethernet interface.

Again. I'm not 100% sure if it was just a reboot that caused this or the upgrade, but I suspect it was the upgrade.

This just happened to me on a hAP lite RB941-2nD configured a similar way, but on 6.39.3. So problem appears to be older than 6.41.1.

It is configured as a wireless client (station pseudobridge) with all Ethernet ports configured as a switch, a bridge with wlan1, with dhcp-client configured on the bridge. DHCP server would see mac of wlan1 or sometimes mac of bridge/ether1. No admin mac set on the bridge. I recall a reboot would often make it change but not always. It would get a different IP from the DHCP server. I set a static IP on ether1 and disabled the dhcp-client to get around it.

Posted: **Mon Feb 05, 2018 10:13 am**

it will be great if I don't have to reboot twice for ROS & firmware upgrading

Posted: **Mon Feb 05, 2018 1:53 pm**

Issue of flooding all bridge ports with IGMP Snooping on stream change (ie channel surfing, flood lasts about 1-2 sec) or interface removal (ie dynamic interface leaves bridge, flood lasts 60+ sec) still exists on this version.

How to easily replicate:

Method a) Put multiple interfaces on the IGMP-Snooped bridge, start streaming with one (ie an IPTV channel), leave one stream and join another (ie change channels) all interfaces on the bridge start to get flooded with the stream for a few seconds. Rapidly change streams (ie channel surf), you can easily flood all interfaces with 80-100mbit of traffic for a ~8mbit per stream scenario.

Method b) Put multiple interfaces on the IGMP-Snooped bridge, start streaming with one, remove it from the bridge, all interfaces on the bridge start to get flooded with the stream for 60+ seconds.

Makes IGMP Snooping kinda useless, when a group's doesn't have any members but is still getting to the router, it needs to get blackhole'd, not broadcasted.

I have similar problem, see details:

viewtopic.php?f=1&t=127960

Posted: **Mon Feb 05, 2018 3:25 pm**

nuffrespect - Please generate supout file on your router while you see such behavior and send this file to support@mikrotik.com

@strods, for your attention

Ticket#2018020522000654, Ticket#2018013122002471

DiM

Posted: **Mon Feb 05, 2018 3:42 pm**

It's possible to use bridge port with horizon=1 with hardware offload activated? I think i misunderstood this question about the horizon.

Using CRS326 when i add a port with horizon=1 hardware offload is deactivated.

Thanks.

Posted: **Mon Feb 05, 2018 4:40 pm**

feris - Do you see such behavior on single unit? Are you sure that default configuration on this device is not replaced with another one by using Netinstall;

There is no Netinstall service available. Im making reset from CLI.
Reset configuration on wAP ac with 6.41.1 works as expected.

Configuration of RB750Gr3 with 6.41.1 after reset to default:

/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/system routerboard mode-button
set enabled=no on-event=""

After downgrade to 6.40.5 configuration reset on RB750Gr3 works fine.
Upgrade to 6.41.1 and problem is coming back.

Posted: **Mon Feb 05, 2018 6:43 pm**

NetflashTechnical - Please generate supout file on your router while you see such behavior and send this file to support@mikrotik.com

Done! In fact, several supouts attached to it even

Ticket#2018020522004918

Posted: **Mon Feb 05, 2018 9:34 pm**

CRS125-24G-1S - after upgrade from 6.40.5 to 6.41.1 -> power cycle required

Posted: **Tue Feb 06, 2018 10:43 am**

sanitycheck - This is why admin-mac is available. Please select one of interfaces which is configured within bridge, copy its MAC address and specify as bridge MAC address. Now it will not change any more. This is not a bug - it is intended behavior;
tkgit - At the moment there is no other solution to upgrade firmware after RouterOS upgrade. We will consider implementing automated firmware upgrade in future;
Misi, Nando_lavras, honzam - If you have not contacted support yet, then please do so and send supout file from router. If you have, then please wait for a response from us;
nuffrespect - Thank you for providing files. We are looking into this problem. Please, if possible, in future do not create multiple support tickets for the same problem. In such way usually there is miscommunication which slows down debugging process drastically;
feris - What do you mean by Netinstall service is not available? I have tested this on hEX units with 6.41.1 RouterOS version and default configuration works properly. Please try to Netinstall unit and reset after that. If problem persist, then send supout file to support@mikrotik.com. if configuration is not there after reset, then run "/log print" command (after reset) and send it to support@mikrotik.com

Posted: **Tue Feb 06, 2018 2:14 pm**

This just happened to me on a hAP lite RB941-2nD configured a similar way, but on 6.39.3. So problem appears to be older than 6.41.1.

It is configured as a wireless client (station pseudobridge) with all Ethernet ports configured as a switch, a bridge with wlan1, with dhcp-client configured on the bridge. DHCP server would see mac of wlan1 or sometimes mac of bridge/ether1. No admin mac set on the bridge. I recall a reboot would often make it change but not always. It would get a different IP from the DHCP server. I set a static IP on ether1 and disabled the dhcp-client to get around it.

Yeah that's probably a good idea. My last AP was a hAP ac lite, and it had a static IP. Might as well set a static on this one.

The wAP ac has so much better wireless coverage than the hAP ac lite. I'm happy with it.

Posted: **Tue Feb 06, 2018 3:17 pm**

The update resets the hotspot files! I have the login customized and it's now gone!

I just updated an old 951 and it seems the problem is only on the new hap ac's (not the brand new hap ac 2)

Posted: **Tue Feb 06, 2018 3:35 pm**

The update resets the hotspot files! I have the login customized and it's now gone!

We are sorry for any inconvenience caused. We will fix this problem in 6.41.2 RouterOS release;

Posted: **Tue Feb 06, 2018 4:35 pm**

What is ETA for v6.41.2?

Posted: **Tue Feb 06, 2018 6:12 pm**

Has anyone had an issue with DHCP packets not being passed through a bridge using 6.41.1?

I have bridged 2 ports together, with 1 port being the network where a DHCP server resides and the second port where a DHCP client device is connected.

DHCP packets do not pass through the bridge.

Posted: **Tue Feb 06, 2018 6:46 pm**

*) ovpn - fixed resource leak on systems with high CPU usage;

Does this fix this problem I reported here?
viewtopic.php?f=2&t=129459

Posted: **Tue Feb 06, 2018 9:35 pm**

While updating to 6.41.1 from 6.41 my HAP did not make it, it was powered on port 1 with PoE.

When powering up, the PWR and USR lights up, but nothing else.
There is no response on webfig or winbox. Winbox does not recognize the device.
Neighbors with another Mikrotik device also does not detect the HAP.

Reset to factory defaults does not have any usable effect.

Any other suggestions what to do next?

Posted: **Tue Feb 06, 2018 10:03 pm**

While updating to 6.41.1 from 6.41 my HAP did not make it, it was powered on port 1 with PoE.
...
Any other suggestions what to do next?

Use Wireshark or tcpdump to see whether the machine sends bootp packets after restart. If it does, use netinstall to reinstall the software.

Posted: **Tue Feb 06, 2018 10:06 pm**

NetflashTechnical, ithierack, theq, Clauu, freemannnn, nuffrespect - Please generate supout file on your router while you see such behavior and send this file to support@mikrotik.com

Done: Ticket#2018020622006647

Posted: **Wed Feb 07, 2018 12:52 pm**

SirPrikol - Did you downgrade to 6.41 routes where working and upgrade to 6.41.1 and they are not working again? Can you provide supout file to support@mikrotik.com which would be generated while there are such routes on router;

Send
Ticket#2018020722003201

Posted: **Wed Feb 07, 2018 4:06 pm**

Sorry for an off-topic small question - I am a newbie with MT and not an IT-professional and just update to 6.41.1

Terminal seems to be the most powerful toll ...
In case of WinBox vs. Browser as interface to ROS ..., what is next to Terminal ( I would like to avoid to install WinBox on my MacBook) ?
I appreciate your opinion very much

Sorry to be a bit off-topic but I see here a lot of professionals where a short answer takes some seconds

Have a nice day !

Posted: **Wed Feb 07, 2018 4:53 pm**

In case of WinBox vs. Browser as interface to ROS ..., what is next to Terminal ( I would like to avoid to install WinBox on my MacBook) ?

You may use any - they have similar interface and functionality.

Posted: **Wed Feb 07, 2018 5:01 pm**

Thank you !

Posted: **Wed Feb 07, 2018 6:49 pm**

Changing settings through the Quick Set drop-down menu renders the device unresponsive and requires push-button hardware reset to defaults.
Changing IP address through the Quick Set web page renders the device unresponsive (at both old and new IP address) and requires push-button hardware reset to defaults.
RouterBOARD 941-2nD does not have Gigabit Ethernet ports but auto-negotiation of 1000M half / 1000M full is enabled by default.

Model RouterBOARD 941-2nD
Current Firmware 6.41.1
Packages version 6.41.1

Posted: **Wed Feb 07, 2018 7:18 pm**

I think I found a bug

The problem is on every reboot, the Mikrotik CHR auto injects a dhcp-client option.

Removing the dhcp-client and rebooting the CHR will again show a dhcp-client in the configuration.
Disabeling the dhcp-client in the config , then rebooting will result in two dhcp-client configs - One is disabled and the other is enabled.

I have verified this problem on several different CHR routers.

The problem appears to start at v6.4.anything.
When I downgrade to 6.39 or older on the CHR , it works correctly and does not auto inject a dhcp-client setting in the configuration after reboots.
When I upgrade any CHR (CHR-64) to 6.4anything or even the 6.42rc20 , the problem appears again.

With any version of 6.4 , a reboot will auto inject a dhcp-client into the configuration.
In testing , I disabled the dhcp package then rebooted and because there is no dhcp package at this time , there are no dhcp-client configs in the configuration.
The moment I re-enable the dhcp package on the CHR and reboot , the dhcp-client configuration shows up again.

I have tested/verified this condition on several different CHR (chr-64) systems.

Is this a bug ?
Anybody else seeing this ?

North Idaho Tom Jones

Posted: **Wed Feb 07, 2018 8:03 pm**

podrian ayudarme con la password de este mikrotic

Posted: **Wed Feb 07, 2018 8:24 pm**

Is this a bug ?
Anybody else seeing this ?

Yes and yes. I've already had it confirmed by support as a bug - [Ticket#2018012422000218] [MT Support] CHR keeps recreating unwanted ether1 dhcp-client.
After initially telling me it was correct, I argued my case and then they said:
"This client indeed is created by mistake. We will try to fix this in upcoming RouterOS versions."

I found that creating a bridge and adding ether1 as a bridge port stopped it from doing this, because you can't have a DHCP client on a slave interface.

Posted: **Wed Feb 07, 2018 8:35 pm**

Is this a bug ?
Anybody else seeing this ?
Yes and yes. I've already had it confirmed by support as a bug - [Ticket#2018012422000218] [MT Support] CHR keeps recreating unwanted ether1 dhcp-client.
After initially telling me it was correct, I argued my case and then they said:
"This client indeed is created by mistake. We will try to fix this in upcoming RouterOS versions."

I found that creating a bridge and adding ether1 as a bridge port stopped it from doing this, because you can't have a DHCP client on a slave interface.

sid5632 - thanks for your prompt input/reply.
So far, I have only seen this on CHRs. Have you (or anybody else) seen the dhcp-client issues auto-showing up on x86-ROS-32-Bit or other physical Mikrotik platforms ?

North Idaho Tom Jones

Posted: **Wed Feb 07, 2018 8:39 pm**

podrian ayudarme con la password de este mikrotic

junior18 , I think this translated is: "password could help me with this mikrotik"
Not sure I understand your question/statement
North Idaho Tom Jones

Posted: **Wed Feb 07, 2018 8:39 pm**

I think I found a bug

The problem is on every reboot, the Mikrotik CHR auto injects a dhcp-client option.

There must be a little more to it, as on my CHR (which has ether1 and ether2 both with static address and no DHCP) I cannot reproduce it.

Posted: **Wed Feb 07, 2018 9:08 pm**

I'm running 6.41.1 on a CCR-1016-12S-1S+RM router that I'm testing SFP compatibility/behavior in. The non-mikrotik modules worked on gigabit only when manually set to 1Gbps (no auto negotiation) they would not work on 100Mbps when manually set even though the modules support it (UBNT and Fiberstore SFPs). After upgrading the board firmware/BIOS, whatever you want to call it, from 3.39 to 6.41.1 the non-mikrotik modules will not work under any settings configured. Is this a bug or are you guys removing the minimal level of compatibility we did have?

Posted: **Wed Feb 07, 2018 9:15 pm**

I think I found a bug

The problem is on every reboot, the Mikrotik CHR auto injects a dhcp-client option.
There must be a little more to it, as on my CHR (which has ether1 and ether2 both with static address and no DHCP) I cannot reproduce it.

Can not reproduce it either. It does however create a DHCP client on ether1 when deploying the CHR with the use of the ova template even when you use 'static IP' in the wizard without actually entering an IP-address.

Posted: **Wed Feb 07, 2018 10:24 pm**

DHCP client on CHR reappears on purpose. You can not delete it. It is intended behavior.

Posted: **Wed Feb 07, 2018 10:42 pm**

DHCP client on CHR reappears on purpose. You can not delete it. It is intended behavior.

But why?

Posted: **Wed Feb 07, 2018 10:45 pm**

podrian ayudarme con la password de este mikrotic
junior18 , I think this translated is: "password could help me with this mikrotik"
Not sure I understand your question/statement
North Idaho Tom Jones

Not quite. It's more like "could you help me with this mikrotik password?"

Posted: **Wed Feb 07, 2018 11:06 pm**

Dear all,

with 6.40.3 I had on my wAP-ac for each vAP a VLAN (on ether1 = Trunk) and a separate bridge, connected together - e.g.: bridge-vlan10 + vlan10 + vAP10 ... it worked fine.

With 6.41.1 there is some "spezial" bridge solution ... is there any need to change my old vAP configuration, please ?
If yes or if better ... is there any kind of red-line/best-prctice or some configuration file available to avoid to get in troubles, please ?

Thanks a lot in advance !

Posted: **Wed Feb 07, 2018 11:21 pm**

The "special" bridge solution brings some advantages (namely, hardware switching where possible and a possibility to run MSTP protocol and better operation of other flavours of STP).

However, in your setup where you just need to bridge several VLANs from a single Ethernet port to virtual APs running on the very same box, you can safely stay with your existing configuration. It continues to work and none of the advantages of the new method is applicable for your setup.

Posted: **Wed Feb 07, 2018 11:31 pm**

I was upgrading some routers from previous versions to 6.41, when all of a sudden I notice the most recent version is now 6.41.1.

I noticed that on 6.41.1 I am unable to change the neighbor discover-setting. Shown below are console output from a 6.41 router and a 6.41.1 router. They are the same router. I performed the first neighbor discovery setting change from !dynamic to all, then upgraded the router from 6.41 to 6.41.1. When the router came back online, the neighbor discovery setting was reset from all to !dynamic, and I am unable to get it to change at all now, even after multiple reboots. This occurs from the console and winbox. Interesting...
Code: Select all
# running v6.41 - can make changes to neighbor discovery-settings
[user@router] > /ip neighbor discovery-settings 
[user@router] /ip neighbor discovery-settings> print 
  discover-interface-list: !dynamic
[user@router] /ip neighbor discovery-settings> set discover-interface-list=all 
[user@router] /ip neighbor discovery-settings> print 
  discover-interface-list: all
[user@router] /ip neighbor discovery-settings> /system package update install 

# now running v6.41.1 - after reboot - can NOT make changes to neighbor discovery-settings from cli or winbox
[user@router] /ip neighbor discovery-settings> /ip neighbor discovery-settings 
[user@router] /ip neighbor discovery-settings> print 
  discover-interface-list: !dynamic
[user@router] /ip neighbor discovery-settings> set discover-interface-list=all 
[user@router] /ip neighbor discovery-settings> print 
  discover-interface-list: !dynamic
[user@router] /ip neighbor discovery-settings> 

I have noticed that you can change discovery interfaces. It seems viewing the setting always reports !dynamic. As a test I have set to none. The setting appears to be !dynamic. No neighbors appear in the neighbor list. It works like none. It seems to work with whatever it is set to, however it always displays !dynamic.

Posted: **Wed Feb 07, 2018 11:49 pm**

DHCP client on CHR reappears on purpose. You can not delete it. It is intended behavior.

ditto on the why question ?

There are some/many reasons an admin would not want a dhcp-client configuation on their CHR.
- If dhcp-client is not needed , why does it auto add the dhcp-client on reboot
- Why is not needed prior to v6.39x and earlier and now needed after v6.4x ?
- What happens if a CHR has a static IP address on a network that also has a DHCP server and the CHR also injects a dhcp-client configuration on the same network - now you have two IP addresses and possibly two different gateways ?
- Is there a way to remove the dhcp-client auto inject into the configuration without disabeling the dhcp package ? ( A CHR may need to be a dhcp-server and and not be also a dhcp-client )

Will this dhcp-client auto inject feature stay in all future versions/updates of CHR ROS or can/will the auto inject of dhcp-client be disabled or removed.
Am I correct in thinking the auto inject of dhcp-client was a planned function on CHR reboots if the dhcp package is enabled ?

confused - North Idaho Tom Jones

Posted: **Thu Feb 08, 2018 1:03 am**

The "special" bridge solution brings some advantages (namely, hardware switching where possible and a possibility to run MSTP protocol and better operation of other flavours of STP).

Hello Sindy,

thank you !
In this case, maybe I should to got the way of future und to adapt my configuration on both wAP-ac to the new bridge ... any recommendation how to start, what to read, etc. ?

Thanks !

Posted: **Thu Feb 08, 2018 2:47 am**

Hello Sindy,

thank you !
In this case, maybe I should to got the way of future und to adapt my configuration on both wAP-ac to the new bridge ... any recommendation how to start, what to read, etc. ?

Thanks !

The change in bridging is to do with hardware switching I thought, and since the wAP-ac doesn't use a switch chip you shouldn't be having any problems
Can you share your config?

Posted: **Thu Feb 08, 2018 7:40 am**

After update 6.41.1 my RB951Ui 2HnD has alway reboot, and i cant winbox to interface address. How can I fix this?

Posted: **Thu Feb 08, 2018 9:36 am**

Splash - We are not aware about such problem. Usually such issues appear due to some configuration issue. Please send supout file to support@mikrotik.com
onlineuser - It might affect your situation, however, we can not give you precise yes or no answer. If the problem that you have is caused by delayed/slow responses to/from OVPN server, then this might help and your problem might go away;
mla, minhcoi - Have you tried to Netinstall your device;
jackx - Did you have such problem also in 6.41 release;
TomjNorthIdaho, sid5632, pe1chl, SPKA16, XaTTa6bl4 - This is intended behavior, because it is required in order to access CHR (when used on cloud services not hosted by yourself and you do not have access to the console). Also this was the behavior also before 6.41.1 RouterOS release. Please in future for such cases either contact support or create a new forum topic. Such posts might make other users to think that this release has some bug which affects CHR installations, however, it has nothing to do with concrete RouterOS release;
russman - Please send supout file from your router generated while SFP is not working properly to support@mikrotik.com;
myke1124 - Please before posting look through previous posts in the same topic. This problem is already resolved in 6.42rc version and fix will be included in 6.41.2 RouterOS release;

Posted: **Thu Feb 08, 2018 9:52 am**

The DHCP on CHR thing is annoying, I guess we can all add drop rules to the output chain to block the requests :/

Posted: **Thu Feb 08, 2018 10:14 am**

Hello Sindy,

thank you !
In this case, maybe I should to got the way of future und to adapt my configuration on both wAP-ac to the new bridge ... any recommendation how to start, what to read, etc. ?

Thanks !
The change in bridging is to do with hardware switching I thought, and since the wAP-ac doesn't use a switch chip you shouldn't be having any problems
Can you share your config?

@coliflower, @LIV2 has put in another words what I've already written: the new way of bridging won't bring anything useful to you until you decide to deploy more than one Ethernet port, as it unites "bridge" and "switch" configuration into one and lets the RouterOS itself decide which functionality to execute in hardware and which in software. But you can change the settings if you want, so if the documentation is not clear enough, try to read the same in another wording in this post.

Posted: **Thu Feb 08, 2018 11:24 am**

Splash
mla, minhcoi - Have you tried to Netinstall your device;

Because device canot stable so I tried to Netinstall but doesnt work.

Posted: **Thu Feb 08, 2018 12:19 pm**

Hello Sindy,

thank you !
In this case, maybe I should to got the way of future und to adapt my configuration on both wAP-ac to the new bridge ... any recommendation how to start, what to read, etc. ?

Thanks !
The change in bridging is to do with hardware switching I thought, and since the wAP-ac doesn't use a switch chip you shouldn't be having any problems
Can you share your config?

Yes, can do it if I am back from my business-trip.

Posted: **Thu Feb 08, 2018 12:41 pm**

Hello Sindy,

thank you !
In this case, maybe I should to got the way of future und to adapt my configuration on both wAP-ac to the new bridge ... any recommendation how to start, what to read, etc. ?

Thanks !
The change in bridging is to do with hardware switching I thought, and since the wAP-ac doesn't use a switch chip you shouldn't be having any problems
Can you share your config?
@coliflower, @LIV2 has put in another words what I've already written: the new way of bridging won't bring anything useful to you until you decide to deploy more than one Ethernet port, as it unites "bridge" and "switch" configuration into one and lets the RouterOS itself decide which functionality to execute in hardware and which in software. But you can change the settings if you want, so if the documentation is not clear enough, try to read the same in another wording in this post.

Thank you Sindy,
I will read and check ... Who knows when I need some additional Switch or to replace the current one

Posted: **Thu Feb 08, 2018 2:29 pm**

TomjNorthIdaho, sid5632, pe1chl, SPKA16, XaTTa6bl4 - This is intended behavior, because it is required in order to access CHR (when used on cloud services not hosted by yourself and you do not have access to the console).

Please look at my comments on [Ticket#2018012422000218] [MT Support] CHR keeps recreating unwanted ether1 dhcp-client

Creating it initially makes sense, but recreating it automatically after the user has deliberately chosen to remove it and do something else is just plain STUPIDITY.
Your support person did seem to agree with me eventually.

Posted: **Thu Feb 08, 2018 3:41 pm**

I have downgraded all RouterBOARD 941-2nD to version 6.39.3 (bugfix) firmware 3.41 because version 6.41.1 causes slowdown that renders the devices too slow to even use their web interface.

Posted: **Thu Feb 08, 2018 4:03 pm**

strods,sid5632, pe1chl, SPKA16, XaTTa6bl4

strods - please go ahead and create a new thread on this topic and we can follow this topic there.

Re: ... This is intended behavior...
Who decided to make all CHRs only operate as DHCP-CLIENTS , and deny you the ability to disable dhcp-client?
There is no other operating system or router or any type of network device I can think of that forces you to only be a DHCP-Client.
You can't disable it - You can't remove it - You can't turn it off - You can't even factory default reset it without it comming back.
Just think about the world-wide impact if every network device, every router, every switch, every PC was suddenly forced to be a DHCP-CLIENT after a software upgrade , and there was no option to change/disable it ?

Re: Also this was the behavior also before 6.41.1 RouterOS release.
No, it was not.
The problem was not there prior to v6.4 (v6.39x and older work correctly)
The problem is there at v6.4 and later

Re: Please in future for such cases either contact support or create a new forum topic.
please go ahead and create a new thread on this topic and we can follow this topic there.

Re: ... think that this release has some bug ...
Lets just call it a new un-documented feature

North Idaho Tom Jones

Posted: **Thu Feb 08, 2018 4:32 pm**

@strods

It didn't generate a support file automatically. It didn't crash the router, this is all regarding link negotiation via 10/100/1000M RJ45 SFP modules. Before the aforementioned update, the non-mikrotik modules would link up if the port was manually set to 1Gbps but wouldn't let anything connect under any speed but 1Gbps even though the module supported it. The mikrotik one just did some odd things with auto-negotiation below 1Gbps and the speed reported that was fixed with the firmware update. After the update however, now only the mikrotik SFP will work regardless of link negotiation settings applied (auto and manual).

Testing was performed with:

Mikrotik S-RJ01
UBNT UF-RJ45-1G
FiberStore SFP-GB-GE-T (#34976)

Posted: **Thu Feb 08, 2018 4:40 pm**

The supout.rif contains telemetry which is needed to analyze the issue. It is not mandatory that it is created "spontaneously" after a crash. So insert the previously-supported SFP and manually create the supout.rif for support.

Posted: **Thu Feb 08, 2018 7:48 pm**

onlineuser - It might affect your situation, however, we can not give you precise yes or no answer. If the problem that you have is caused by delayed/slow responses to/from OVPN server, then this might help and your problem might go away;

It looks good. At the first connection establishment the connection will be established.

Another feature would be that when there are more than one outgoing ovpn client only one by one connection will be established - this would be better for the CPU when 4k keys will be used on slower devices.

Posted: **Thu Feb 08, 2018 8:48 pm**

I can confirm the DHCP behavior described by Splash.
Having a DHCP server on a (SW only - CCR1009) bridge interface stops the DHCP server from handing out leases, with all just in the waiting state.
Adding accept firewall rules for UDP port 67 on the input chain for the needed interfaces gets it up and running.

Posted: **Fri Feb 09, 2018 1:35 am**

After update 6.41.1 my RB951Ui 2HnD has alway reboot, and i cant winbox to interface address. How can I fix this?

Can you winbox to MAC address?

Posted: **Fri Feb 09, 2018 12:08 pm**

Notice for those, how are using hotspot with custom pages.

After update from 6.41 to 6.41.1 path to hotspot files has changed. It was 'flash' before, now it's 'disk'.
Did not find this in changelog.
Got hotspot misfunction, because I use custom redirect pages.

Just bear it in mind.

Posted: **Fri Feb 09, 2018 1:37 pm**

I have to downgrade firmware on cAP and Hex POE wireless routers to 6.41.
In IP Hotspot settings I select correct path from dropdown menu, i.e. 'disk/custom-hotspot'. But it save path as 'flash/disk/custom-spotspot' and display default auth page to connected wireless stations. This behavior is either using WinBox or CLI.

This look like a bug.

On cAP Lite 6.41.1 path saves correctly.

Posted: **Fri Feb 09, 2018 3:29 pm**

Version 6.41.2 has been released:
viewtopic.php?f=21&t=130626

MikroTik

v6.41.1 [current]

v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current] (DNS problem)

Re: v6.41.1 [current]

Re: v6.41.1 [current] (DNS problem)

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current] (DNS problem)

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

Re: v6.41.1 [current]

v6.41.1 [current] bug report

Re: v6.41.1 [current] (BUG in dhcp package - I think)

Re: v6.41.1 [current]

Re: v6.41.1 [current] (BUG in dhcp package - I think)

Re: v6.41.1 [current] (BUG in dhcp package - I think)

Re: v6.41.1 [current]

Re: v6.41.1 [current] (BUG in dhcp package - I think)

Re: v6.41.1 [current]

Re: v6.41.1 [current] (BUG in dhcp package - I think)