Apologies in advance for a somewhat vague question, but is anyone having any issues with DHCP on 7.11.2 ?

Edit: False alarm. the problem was on our network!

We had DHCP issues from the 7.x series somewhere around 7.8 until 7.11.2, which has fixed it for all of our devices.

Could this be related to 'ARP entries building up' here: viewtopic.php?t=195759
and hence causing issues not handing out IP's anymore?

Are you aware of this?

(see pic, on an RB981-2nd-TC)

Regards

hrool

That's a model that exists just for you...

However, if it were the RB941-2nd-TC, as written everywhere, and as common sense dictates, RouterOS 7, even if they compiled it, is not for SMIPS.

Could this be related to 'ARP entries building up' here: viewtopic.php?t=195759
and hence causing issues not handing out IP's anymore?

No. ARP entries are not DHCP entries. When DHCP assigns an existing address to a new device (while the old address is no longer assigned), the ARP entry will be updated as well.
When you do not like the ARP table to be full of unused entries, schedule this script (e.g. once a day):

/ip arp remove [ find where !complete ]

@rextended:

(Apologies, I have an RB941 indeed)

You mean, Winbox downloaded a wrong firmware so far? (some weeks ago, it upgraded from v6 to v7 and then to 7.10.2 without any complaints)

Somewhere when moving from 6 to 7, someone must have done something special because ROS/Winbox does not upgrade automatically from 6 to 7.
You have to select to do that.

Apart from that, even though it is possible, it is not recommended to use ROS7 on a device with less then 64Mb RAM.
You can always downgrade.

You can always downgrade.

Well, that probably requires a netinstall by now... even within v6, upgrading such devices often was problematic.

To downgrade my RB941 to v6, I followed the advices at
https://help.mikrotik.com/docs/display/ ... g+RouterOS

- downloading routeros-smips-6.49.10.npk (latest v6 Firmware)
- uploading it via winbox to the router
- issuing /system/package/downgrade at console

It didn't come to /system/reboot, because the downgrade command announced and seemingly performed it on it's own.

The session closed, but then no more reconnection was possible. The device appears bricked now.

I am tired of the crappy information provided. Is anybody here able to articulate some helpful cue?

I said it was possible to downgrade.
I did not say how.
Pe1chl told you how.

Netinstall.

*) wifiwave2 - added "steering" parameters and menu to set up and monitor AP neighbor groups (CLI only);

Is it possible to define custom lists of bssids to annouce via 802.11k with this? If yes, how does it work?
I can see automatically created dynamic neighbor-groups, but cannot see how to add custom static neighbor-groups.

I am tired of the crappy information provided. Is anybody here able to articulate some helpful cue?

you know mikrotik has a wiki, help pages and a youtube channel where exactly NETINSTALL is mentioned.
and also - routeros is not a "shiny clicky pointy" system - you need to have at least some basic networking knowledge

I am seeing a lot of jitter in the connection now, my ping in games used to be less than 80ms but right now it is 3x the amount with this version. I think the only change was that I updated all mikrotik devices to 7.11 and it sure started happening after this update.

I have a "complicated" network path. Router -> AP ->VPLS/MLPS bridge -> Station -> Router -> modem. But that was there with 7.10 without jitter.

Even speed test shows the same throughtput but now the ping during upload and download spikes up and before it didn't do that. Just a heads up and something to look out for in case your setup shows this behaviour.

Ok, after more testing it turns out the configuration I have in this router (AX2) is too much for the device. It does not really goes above 70% CPU usage but it does jitter a lot. I Replaced it with a RB5009 and left the AX2 as a simple AP/VPLS bridge and now I am back at a stable 7ms Ping idle/21ms Ping on download/10ms ping on upload.

The only weird thing is that I was getting values close to this on 7.10 but when I jumped to 7.11 AX2 started having performance issues.

I do not know if this is enough but that is as much asI could find out.

In previous days, Apple released iOS 17, after which I got lots of reports from IKEv2 EAP clients on Apple devices running this version that they were disconnected after 8 minutes when utilizing a previously created connection to the update. However, they couldn't connect at all when they tried with a new VPN connection.
*)FPS groupe=none
I will attach the connections log as soon as I can. In the meantime, is anyone can confirm this issue?

Bricked on 750gr3 on upgrade and one WAPac RBwAPG-5HacT2HnD. Had to recover both with netinstall, not what I expected on "stable" tree.

not what I expected on "stable" tree.

First inform you about what "stable" means before you base your expectations on it. That prevents disappointment.

First inform you about what "stable" means before you base your expectations on it. That prevents disappointment.

To be fair, regardless of what "stable" means I'd expect firmware updates _not_ to brick my devices.

First inform you about what "stable" means before you base your expectations on it. That prevents disappointment.

To be fair, regardless of what "stable" means I'd expect firmware updates _not_ to brick my devices.

Yes, but so do we expect for "testing" or "development" updates. However, it is for a reason that the release topic always starts with:

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.

I.e. you must always be prepared. Sometimes the upgrade goes wrong for some unusual reason, and when it happens it usually is not related to the particular version of the update, but to some pre-existing condition on the device.
"bricked" MikroTik devices are normally not permanent bricks, they can be recovered using the "netinstall" procedure.

To be fair, regardless of what "stable" means I'd expect firmware updates _not_ to brick my devices.

Yes, but so do we expect for "testing" or "development" updates. However, it is for a reason that the release topic always starts with:

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.

I.e. you must always be prepared. Sometimes the upgrade goes wrong for some unusual reason, and when it happens it usually is not related to the particular version of the update, but to some pre-existing condition on the device.
"bricked" MikroTik devices are normally not permanent bricks, they can be recovered using the "netinstall" procedure.

They didn't lose power. They had enough storage space. Guess what. I also have a backup, but it isn't like it isn't a PITA to recover a bricked device...

Having to uninstall ceiling mounted devices so you can hold the reset button to force netinstall is a PITA, for something that should have "worked". I am sorry you can't see that this is in fact a defect. 1 out of 2 RB750GR3 failed, 1 out of 3 WAP AC failed.

Apologies in advance for a somewhat vague question, but is anyone having any issues with DHCP on 7.11.2 ?

I do. DHCP client can't add a simple default route:
>dhcp-client on ether1 failed to add 0.0.0.0/0 route to 192.168.1.1: std failure: timeout (13)

What a nonsense, didn't expect this bullshit from mikrotik.

What a nonsense, didn't expect this bullshit from mikrotik.

Mikrotik can't handle users and their sometimes exotic configs. Not saying this is the case with you...just saying that this is not caused by RouterOS v7.11.2.

What a nonsense, didn't expect this bullshit from mikrotik.

Mikrotik can't handle users and their sometimes exotic configs. Not saying this is the case with you...just saying that this is not caused by RouterOS v7.11.2.

It's the default config, which comes with AX³, you know. Mikrotik must handle it with no excuses.

To downgrade my RB941 to v6, I followed the advices at
https://help.mikrotik.com/docs/display/ ... g+RouterOS

- downloading routeros-smips-6.49.10.npk (latest v6 Firmware)
- uploading it via winbox to the router
- issuing /system/package/downgrade at console

It didn't come to /system/reboot, because the downgrade command announced and seemingly performed it on it's own.

The session closed, but then no more reconnection was possible. The device appears bricked now.

I am tired of the crappy information provided. Is anybody here able to articulate some helpful cue?

RAM shortage (where firmware is stored during the upgrade) is common problem on those smaller smips devices, you must make sure you have at least 7.7MB free RAM available (winbox/system/resources) before upgrade, unfortunately this doesn't help you now I guess...
It is common opinion that you should not use RouterOS 7 on these devices at all, although that isn't official Mikrotik stance, on a contrary the download link on hAP lite TC page points to 7.11.2 version...
You cannot use steps you are referring to to downgrade between major version, 7 to 6 for example, just between same major version like 6.x.x to 6.x.x, this unfortunately isn't mentioned on that help page and it should be really.
Considering all the above you are probably justified to be angered.
The only way to downgrade to lower major version, as long it is not lower than factory installed one, is to use netinstall, and that is what you should now to unbrick your device...
https://help.mikrotik.com/docs/display/ROS/Netinstall

RAM shortage (where firmware is stored during the upgrade) is common problem on those smaller smips devices, you must make sure you have at least 7.7MB free RAM available (winbox/system/resources) before upgrade, unfortunately this doesn't help you now I guess...

No, those small smips devices do NOT use RAM to store the downloaded firmware, that is stored in flash.
Using RAM for that is only in the other devices with 16MB flash. (MMIPS, MIPSBE etc)

It's the default config, which comes with AX³, you know. Mikrotik must handle it with no excuses.

>dhcp-client on ether1 failed to add 0.0.0.0/0 route to 192.168.1.1: std failure: timeout (13)

Default is 192.168.88.1

Hello,

I recently installed version 7.11.2 on an RBM33G, along with the R11e-LoRa8/R11e-LoRa9 LoRa card. We updated to this version because the release notes indicated that filtering option using NetID or JoinEUI is now supported on uplink messages. We made several attempts to activate filtering using JoinEUI, but unfortunately, it did not function as expected. I've outlined our approach to filtering data below; however, the gateway continued to transmit data to the server. We tried stopping and restarting the LoRa module and even rebooting the device, but none of these actions resolved the issue.
When we attempted to filter data using NetIDs, it worked as intended, but this method does not align with our specific requirements.

Could you please verify whether this is a known bug or if there are specific settings we need to adjust?

Thank you

Anyone having issues with fasttrack stopping working after some time?

My RB5009 loses the ability of fasttrack, what limits its routing performance.

On hAP ax^2 (with wifiwave2) if you turn on Hardware Offload on ethernet ports (and it actually works meaning you have H flag) in a Bridge where wifi interfaces are connected (say LAN) the packets from wifi interfaces are not forwarded, it just doesn't work...
I am not sure if this is the case in previous versions but in 7.11.2 it is definitely the case.

After upgrading from 6.49.10 only 9 of 50 openVPNs (over 443 TCP) are coming up. I don't know why, after every restart other 9 connections are active. The only fixed thing is the counter 9...

Niels

I'm seeing what appears to be a memory leak on v7.11.2, likely related to the DNS resolver once again. Have already reported, with supout files, as SUP-128622 on September 20th, but absolutely no answer there, almost one month after the report with detailed data

Posting here to let people aware that some memory leak is still present on v7.11.2 and, by my own analyses of the supout files, it's once again DNS resolver related (no confirmation from Mikrotik at this one). While I have other that are not presenting the behavior, the faulty behavior (and screenshot) was taken from a RB2011 box.

While I have other that are not presenting the behavior, the faulty behavior (and screenshot) was taken from a RB2011 box.

In fairness to the poor DNS server... maybe it's related to the architecture. Is there something that point at DNS, other than DNS has had memory leaks before? It seems if DNS is leaking, it be more widespread.

In fairness to the poor DNS server... maybe it's related to the architecture. Is there something that point at DNS, other than DNS has had memory leaks before? It seems if DNS is leaking, it be more widespread.

For sure it might be arch related, I also considered that. Thing is that even other RB2011s i have running the same RoS version, the leaky behavior can't be seen. After decoding supout files before and after a reboot (attached to my bug report), I can clearly see the /nova/bin/resolver process is the one using much more memory than likely needed, so I'm pretty sure (to my best knowledge) that it's DNS resolver related. Might have other variables as well, but I couldn't find any. Was expecting Mikrotik Support to pay some attention to my bug report, but it's almost 1 month old and no interaction at all from Mikrotik there :(

Hi,
one of my CRS328-24P-4S+ don't know about PoE on interfaces 9-24, however PoE on theese ports still works...

Same model, with same RoS version, but different device this problem haven't.

Any idea?

I had to netinstall a couple of RB4011 because they had a weird partition scheme with two "part1" (instead of "part0" and "part1") that prevented them to work properly. The two RB4011 were used for labbing so they passed through multiple install of beta/rc ..so I'm not too concerned about the weird partitions, but I need cleaning them before putting them into production.
Well .. I tryied to netinstall with the [netinstall-7.11.2] utility -> both the two RB4011 went into a sort of "boot loop" (ether boot-loop).
Then I switched to [netinstall-6.49.10] utility -> READY !there you go! ..here I flashed the 7.11.2 ok, then created the 2 partitions which were ok (part0/part1). Nice!

It seems that the the old 6.x netinstall utility is more robust than the new one (at least of the 7.11.2).

Had anyone come across similar issues (weird partitions / netinstal) ?

Have a nice week-end guys.

Hi, one of my CRS328-24P-4S+ don't know about PoE on interfaces 9-24, however PoE on theese ports still works...
Same model, with same RoS version, but different device this problem haven't.
Any idea?

No idea, but I would recommend:
1) check if firmware version is up to date, otherwise upgrade (/system/routerboard/print -> current-firmware: 7.11.2)
2) supout to Mikrotik so they can see why and fix it
3) netinstall (if not already done)

Hi,
one of my CRS328-24P-4S+ don't know about PoE on interfaces 9-24, however PoE on theese ports still works...

Same model, with same RoS version, but different device this problem haven't.

Did you restore a "backup" file from another device on that one?

pe1chl is absolutely right! That is the typical unpredictable outcome you get into if you do that ;-)
It's definitely a possibility.

Hint: it's a boring task importing from export and validating line by line, but it's the only reliable one.

Is it just me or is the wireguard bug back? I cannot get more than one peer to work. If I disable and then re-enable the peer it works fine but breaks all other peers. Just to be clear, all peers still connect but only one can route traffic at a time.

edit: nevermind

Usually that's an indication of error in peer config allowed address.
Wireguard works just fine for me with multiple peers.

Usually that's an indication of error in peer config allowed address.
Wireguard works just fine for me with multiple peers.

You are correct! Had to set allowed address to a /32 for all peers and now it works.

Is it normal for Device -> RouterOS -> Route tab to have empty lines?

I see this in all of my RouterOS devices


They all seem to be working correctly and connected with no issues. All other tabs show values correctly except for that one.

Is it normal for Device -> RouterOS -> Route tab to have empty lines?

The Dude has not been properly updated to work with RouterOS v7. The routing table has changed design and probably it is no longer able to parse the new table correctly.

Likely you can still view the routing table in the Snmp tab, if that is an option.

Likely you can still view the routing table in the Snmp tab, if that is an option.

Except when you have multiple routing tables, then SNMP retrieval of routes will fail in v7.

Has anyone had issues after updating to 7.11.2 Stable? If so, what kind?
I am using CCR2116-12G-4S+ (ARM64)

I still see some strange behaviour in the SNMP-BGP Peer Table;

`bgp` as defined at https://oidref.com/1.3.6.1.2.1.15
Is missing the following properties;

• `bgpLocalAs` (https://oidref.com/1.3.6.1.2.1.15.2)
• `bgpIdentifier` (https://oidref.com/1.3.6.1.2.1.15.4)
• `bgpPeerInUpdateElapsedTime` (https://oidref.com/1.3.6.1.2.1.15.3.1.24)

Also incorrect values are presented, and not updated over time;

• `bgpPeerFsmEstablishedTime` (https://oidref.com/1.3.6.1.2.1.15.3.1.16); this one should indicate how long (in seconds) this peer has been in the Established state or how long since this peer was last in the Established state.

These values aren't updated over time, nor after a reboot (and therefore a new Established) and completely inaccurate!

After a reboot, all the BGP-sessions are established at almost the same timestamp (+/- 10 minutes ago), side-by-side the output of snmpwalk '.1.3.6.1.2.1.15.3.1.16' is shown. 10 minutes should result in 600 seconds, these values are far off and quite random;

About two weeks ago I've upgraded RB3011UiAS from 6.49.8 to 7.11.2, CPU usage went up to 100%, there were significant packet loss. Going back to RoS v6 (exactly 6.49.10) solved the problem. Upgrade was made on 2023-10-24 early morning, and downgrade on 2023-10-26 same quite early. Is this normal behaviour on that platform?
CPU usage:
http://pasteboard.co/TtG4lE43OHEw.png
Total traffic:
http://pasteboard.co/c52g5tGU60aE.png

RB3011 is a particular device, was the First Routerboard on ARM Arch, so is somewhat old, also is the Only Routerboard Based on Qualcomm IPQ-8064 SoC so is possible to encounter a problem only happening to that device

RouterOS v7.12 has been released
viewtopic.php?t=201345