7.24.1 [stable] is released!

[2MEV2]

hEX S (RB760iGS)

7.23.3 -> 7.24.1
On ROS 7.24.1 with DHCP snooping on bridge ENABLED in log I see:

vlan_10_customers: received DHCP message with MAC address [ff:ff:ff:ff:ff:ff] not present in FDB

7.23.3 - NO ISSUE
7.24 - HAVE ISSUE (hosts can't get IP)
7.24.1 - HAVE ISSUE (hosts can't get IP)

Same issue from others users:

7.24 [stable] is released!

Subject: DHCP Snooping regression in RouterOS 7.24 with Wi-Fi repeater Hello, After upgrading RB5009UG+S+ from RouterOS 7.23.x to 7.24 stable, DHCP Snooping causes a TP-Link Archer C5 v4 working in Repeater Mode to fail DHCP lease acquisition/renewal. With dhcp-snooping=yes, the DHCP server receives the request and assigns 192.168.31.5, but the repeater does not receive/process the DHCP ACK and retries every ~20 seconds: assigned → deassigned → assigned → deassigned The client has differen…

[bbs2web]

Scheduled tasks automatically have !daysset on them when upgrading to 7.24.1 (came from 7.23.2). The following schedulers subsequently don't ever run:

/system scheduler
add !days interval=1d name=Update_RADIUS_Servers on-event=\
    "/system script run \"update_radius_servers\"" policy=read,write,policy,test start-date=\
    1970-01-01 start-time=00:00:00
add !days interval=1m name=CAP_-_Restart_due_to_missing__wifi3_ on-event=":if ([/system resour\
    ce get uptime] > 00:10:00) do={\r\
    \n  /interface bridge port  {\r\
    \n    :local varif [find interface=wifi3]\r\
    \n    :if ([:len \$varif] = 0) do={\r\
    \n      /sys reboot\r\
    \n    }\r\
    \n  }\r\
    \n}" policy=reboot,read start-date=1970-01-01 start-time=00:00:00
add !days interval=1m name=CAP_-_Restart_due_to_missing__wifi5_ on-event=":if ([/system resour\
    ce get uptime] > 00:10:00) do={\r\
    \n  /interface bridge port  {\r\
    \n    :local varif [find interface=wifi5]\r\
    \n    :if ([:len \$varif] = 0) do={\r\
    \n      /sys reboot\r\
    \n    }\r\
    \n  }\r\
    \n}" policy=reboot,read start-date=1970-01-01 start-time=00:00:00

This required two changes, the first was to set days to always on all 3 scripts:

/system scheduler set 0,1,2 days=always

Having days=alwaysand interval=1dis however apparently not compatible, so I had to set interval="00:00:00"on the script that I want to execute daily.

PS: Logged as SUP-222820

[bbs2web]

Change of days for /sys scheduler tasks has not received documentation updates at:

Scheduler - RouterOS - MikroTik Documentation

[infabo]

This is the manual: https://manual.mikrotik.com/docs/system-information-and-utilities/scheduler

@bbs2web

Scheduled tasks automatically have !daysset on them when upgrading to 7.24.1 (came from 7.23.2)

Thats right. I also noticed that in oxidized diff. But it had no impact on my schedules.

[rextended]

(deleted after @infabo kind clarification)

[infabo]

Not good idea. days conflicts with interval.......

# multi-day intervals are not supported with active day scheduling
add days=always interval=1d ....

But I am not 100% sure what the comment above means. 1d is a multi-day interval?

[rextended]

Thanks...

[bbs2web]

Bug with MAC VLAN interfaces, where DHCP client doesn't work. There are numerous uses, these are three of our use cases:

• We run DHCP Server on an interface (eg vlan100) and also want to relay DHCP traffic to a NAC (Network Access Controller) such as PacketFence or ClearPass
• We want multiple PPPoE sessions on a given interface
• Some ISPs create a sticky DHCP association with the first MAC to obtain an IP. This then requires subscribers to contact the ISP to reset the MAC address when changing the router. We can use a MAC VLAN interface to set a custom MAC on that interface.

Validation:

/interface macvlan
  add interface=vlan100 mac-address=55:C4:56:95:B0:1B mode=private name=vlan100-mac
/ip dhcp-client
  add default-route-tables=main interface=vlan100-mac name=vlan100-mac

The interface remains in 'searching' mode, although sniffing traffic of the parent interface shows that the packet should be leaving:

[admin@router] > /tool/sniffer/quick interface=vlan100
Columns: INTERFACE, TIME, NUM, DIR, SRC-MAC, DST-MAC, SRC-ADDRESS, DST-ADDRESS, PROTOCOL, SIZE, CPU
INTERFACE  TIME    NUM  DIR  SRC-MAC            DST-MAC            SRC-ADDRESS          DST-ADDRESS                  PROTOCOL  SIZE  CPU
vlan100    4.335     1  ->   55:C4:56:95:B0:1B  FF:FF:FF:FF:FF:FF  0.0.0.0:68 (bootpc)  255.255.255.255:67 (bootps)  ip:udp     342    2
vlan100    7.141     2  ->   55:C4:56:95:B0:1B  FF:FF:FF:FF:FF:FF  0.0.0.0:68 (bootpc)  255.255.255.255:67 (bootps)  ip:udp     342    2
vlan100    8.143     3  ->   55:C4:56:95:B0:1B  FF:FF:FF:FF:FF:FF  0.0.0.0:68 (bootpc)  255.255.255.255:67 (bootps)  ip:udp     342    2
vlan100    9.886     4  ->   55:C4:56:95:B0:1B  FF:FF:FF:FF:FF:FF  0.0.0.0:68 (bootpc)  255.255.255.255:67 (bootps)  ip:udp     342    2
vlan100    11.757    5  ->   55:C4:56:95:B0:1B  FF:FF:FF:FF:FF:FF  0.0.0.0:68 (bootpc)  255.255.255.255:67 (bootps)  ip:udp     342    3
vlan100    15.281    6  ->   55:C4:56:95:B0:1B  FF:FF:FF:FF:FF:FF  0.0.0.0:68 (bootpc)  255.255.255.255:67 (bootps)  ip:udp     342    3

These packets don't actually leave the interface though. This worked perfectly on prior version of RouterOS v7.

Other related configurations, relevant to the above (DHCP client works perfectly when I set it to run on interface vlan100):

/interface bridge
  add admin-mac=44:BB:68:6A:B7:52 auto-mac=no dhcp-snooping=yes dhcpv6-snooping=yes igmp-snooping=yes \
    name=bridge priority=0x5000 ra-guard=yes vlan-filtering=yes
/interface bridge port
  add bridge=bridge edge=yes interface=ether1 pvid=100 trusted=yes
/interface vlan
  add comment=Internet: interface=bridge name=vlan100 vlan-id=100

PS: Logged as SUP-222821

[pe1chl]

@bbs2web

Scheduled tasks automatically have !daysset on them when upgrading to 7.24.1 (came from 7.23.2). The following schedulers subsequently don't ever run:

I have seen that change (I always diff the /export before and after upgrade) but I have not experienced any difficulty with daily scheduled tasks... I presume this change is to allow easier scheduling of tasks to run on specific weekdays only.

[mantouboji]

It is very wonderful for add wireguard client-mtu option in 7.25beta3

[nmt1900]

OK now Mikrotik is releasing betas as "important security updates". What's next?

[rextended]

They don't understand that what you wrote is true... there's no beta Topic yet...
People are too lazy to go and look for the download and read the changelog...

[nmt1900]

We'll see if it appears - or not (maybe somebody thought that adding obscurity improves security - while it actually just drives conversation to other places).

[rextended]

Also because if there is a (real) security issue,
all versions (6 long-term, 7 long-term, 7 stable) must be updated, not just the beta...

[nmt1900]

I am not sure if we'll ever actually know - it is almost 2 months from previous panic-release and we still don't know the details.

[normis]

Beta topic: V7.25beta [development] is released! - #3 by woland

All other versions coming soon

[CGGXANNX]

This bug is tied with the DHCP Snooping feature. I did some tests and:

• Last properly working version with DHCP Snooping & RA Guard enabled is longterm 7.21.5
• Starting with 7.22 it doesn't work if you enable both DHCP Snooping & RA Guard
• In 7.23 / 7.24 / 7.25 you don't even need to turn on RA Guard, just DHCP Snooping enabled is enough to stop the DHCP client from receiving responses.

Turning on trusted on the ethernet port does not help. But if you disable DHCP Snooping on the bridge, then the DHCP client on MACVLAN interfaces works normally in 7.22-7.25.

[normis]

Stable 7.24.2 with important fixes is out: 7.24.2 [stable] is released!