thanks a lot for the clarification. always appreciate such insights
It wasn’t the whole post, @bartoz, only the relevant part. Before cutting out something, do pay attention.
any chance to have dhcp snooping option 82 remote id and circuit id customization? we are using option 82 for client authorization on switch ports
we need remoteid=bridge/systemmac and circuitid=port number in hex
please check
SUP-104088, dns AAAA issue
I am waiting for SUP-99383. The fix supposedly is in v7.7 and I am not questioning that. However I can’t test that as I am not putting an ‘RC’ on a production router.
No need to hurry Mikrotik, I will wait patiently. Although my device maybe wont and the issue will reappear 
However I am curious, v7.7 has been in testing for ~3 months now, Yet some other releases have whizzed trough testing in 3 weeks. And those longer development cycles happen every so often. Is that something Mikrotik does intentionally to stabilize routeros, or are some releases just that troubled?
I agree with taking time and releasing really stable versions.
It use to be crazy…no matter what kind issue was included in stable version or how many HW will be bricked but every month new “stable” version…
I don’t think they changed anything. As far as I remember working with Mikrotik, some versions just had slower development. Something like every 4th 6.x/7.x was slow to release. Or sometimes it even took them months to release a 6.x.y hotfix.
What’s new in 7.7rc5 (2023-Jan-11 13:20):
*) dns - fixed CNAME reading from the cache (introduced in v7.7rc3);
*) dns - fixed incorrect TTL=0 reporting for cached entries;
*) ike2 - added support for ChaChaPoly1305 encryption;
*) port - fixed R11e-LTE6 port mapping;
Please keep this forum topic strictly related to this particular RouterOS release.
hap ac3 updated ok
Hello everyone, with that new rc’s on RB4011iGS+5HacQ2HnD, CPU Frequecy is not reported, also CPU Frequency settings is missing again. ( but its present in 7.7beta6 ).
I have tried RC5 on hAP ac^2 256MB and works fine. Regarding DNS definitely better performance, but very rarely (really very rarely) there is strange high cache DNS latency on directly connected (wire or wireless) device. Checked by DNS Check. I have curious question, is DNS process priority and run really securerd and reliable? Or can be interrupted by any other load or other processes? On the other hand, router was under low load (up to 10%).
Attempting to load an ED25519 public key into my CHR per the following change announcement:
*) ssh - added support for Ed25519 key exchange;
I’m importing the key with the usual command, but still getting the same error I always used to get.
/user/ssh-keys/import public-key-file=id_ed25519.pub user=admin
unable to load key file (wrong format or bad passphrase)!
The key type in the public key file is “ssh-ed25519” so I’m wondering if RouterOS is expecting something different.
Thoughts?
RouterOS added ed25519 support for key exchange. This can be set using KexAlgorithms option in OpenSSH.
The key you can generate using ssh-keygen and you use to log in is a different thing.
Got it. That makes sense. Thanks. If they’ve added it to key exchange, it may not be unreasonable to be optimistic about it being added to key authentication soon.
when we will get stable v. of 7.7?
I got a missing 5GHz A/N/AC wireless available under CAPSMan after updating to V7.7rc5.
It restored when I reverted back to rc4.
All APs (ac2) do not install wave2 nor I install wave2 into the CAPSMan router.
Still with RouterOS 7.7rc5, given that one connects serial console cable directly to switch (have tested only with several CRS354) some kind of strange named error is always being shown:
insmod: /lib/modules/5.6.3/drivers/char/music_dog.ko failed: 22 Invalid argument
Can anyone else repeat it?
/routing/route/print count-only
working only without any where clause, otherwise returning always 0
@Winbox Routing/BGP/Sessions - “Prefix Count” always 0 /no release till now that work…/
it is a known bug, fixed but the fix not yet added to 7.7branch
on 7.7rc4 and 7.7rc5 we still have issue about pppoeservers:
- in rare condition the simple queue about pppoe-client inteface became unknow and not canceled on client disconnection (seems related to a massive clients disconnection);
- more frequentòy the pppoe-client dynamic interface of just authenticated customer it is not running, so the clients is authenticated but not able to usethe connection
both issues are present on several x86 platform and documentated with a lot of supouts through [SUP-97493].
this is a critical fix needed to have a stable pppoe concetrator based on v7.
regards
Ros