V7.23rc [testing] is released!

  • system - improved handling of HTTP/2 connection closure;

This for us is not true.

We still get the rest/api session not closed!!!

I downgraded to 7.22, both, CAP and CAPsMAN; it didn’t help.I discovered the reason why there is the “no available channels” issue. Interfaces swapped. It means 2 GHz channels are now assigned to interface wifi1 which is 5 GHz radio and 5 GHz channels are assigned to wifi2 which is 2 GHz radio.

Partial export taken before the issue:

/interface wifi
set [ find default-name=wifi2 ] channel=2G configuration=piot \
configuration.mode=ap name=2g_iot
set [ find default-name=wifi1 ] configuration=spcam configuration.mode=ap \
name=5g_spcam

And partial export after this issue happened

/interface wifi
# failed to prepare interface
set [ find default-name=wifi1 ] channel=2G configuration=piot \
configuration.mode=ap disabled=no mac-address=48:A9:8A:0D:D9:BE name=\
2g_iot
# failed to prepare interface
set [ find default-name=wifi2 ] configuration=spcam configuration.mode=ap \
disabled=no mac-address=48:A9:8A:0D:D9:BD name=5g_spcam

In the "before issue" part is not MAC, in the "after issue part" are MACs

Playing with it, tried to assign correct channels, still no success.

What about MACs? Can I assign any MAC to wifi interface?

Am I right, wifi1 is 5 GHz and wifi2 2 GHz, right? (on hAP AX3)

One way to find out is: /interface/wifi/radio/print detail

Thanks, based on this print/detail, it’s the oposite. Wifi1 is 2GHz and Wifi2 is 5GHz. I’m pretty sure in the past wifi1 was 5GHz and wifi2 2GHz. I checked few past exports. It means - upgrading CAP from 7.22 ro 7.23rc1 changed wifi interface order on CAPsMAN.

Reconfigured again, rebooting

After reboot, it changed again. wifi1 is now 5 GHz, wifi2 is 2 GHz. On wifi1, 5GHz for now, MAC has changed completelly

Reconfigured again, copy/paste MACs from the radio /interface/wifi/radio/print detail and now it works. I’m afraid of it will work till reboot. Maybe better to move CAPsMAN to device without wifi and control CAPs from here.

In a capsman setup this is completely normal. You'd need to use action=create-enabled in provisioning.

Really? Even the issue was not on CAP, but on local wifi interfaces on CAPsMAN (not controlled by CAPsMAN, but share the same configuration, which was intacted.

On local interfaces, not controlled by capsman, this should not happen.

confirmed
SIMCOM_SIM7600CE-T up&running

On a router where the /app feature has never been used (and will never be used), after an upgrade from 7.22.1 to 7.23rc1, the following appears in the /export

Which pollutes the export output and introduces irrelevant changes to my configurations under source control.

i was happy too early :frowning:

modem is up, registered, IPv4 DHCP -> OK

but ...

after modem getting IP, nothing is forwarded to LTE interface
only traffic is exactly 666 byte, when LTE get DHCP response, and that is it
tried with two SIM card, different operators
same, dhcp OK and then nothing else work

tried reseting with "AT&F" "AT&W" "ATZ" ...
still nothing

Please implement HTTP/2 for DoH on ARM32.

It's already better than it was before.

Is the WebFig firewall filter rule number now being below the rule handle some new feature designed to make the list even less compact???

It appears that that div is now marked as “flex” when it wasn’t in 7.22.1.

This persists since the first 7.23 beta on my CCR2004. Setting check-certificate=no fixes it, but it is a workaround, not a proper fix.

I understand I could use this rc1 to add letsencrypt certificate really easy in mikrotik devices.

Can mikrotik make available cloud support for x86/chr?

Any reason winbox taking like 5 to 10 seconds to open up? Been like this since 7.22.