RouterOS version 6.48.1 has been released in public "stable" 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.48.1 (2021-Feb-03 10:54):

*) crs312 - fixed missing SwOS firmware on revision 2 devices;
*) crs3xx - fixed packet duplication when multiple bonding interfaces are created for CRS317, CRS309, CRS312, CRS326-24S+2Q+ and CRS354 devices;
*) crs3xx - fixed port-isolation on ether37-ether48 ports for CRS354 device;
*) crs3xx - improved load balancing on bonding interfaces for CRS317, CRS309, CRS312, CRS326-24S+2Q+ and CRS354 devices;
*) crs3xx - improved system stability when bonding and IGMP snooping is used (introduced in v6.48);
*) hotspot - fixed "idle-timeout" usage with RADIUS authentication;
*) hotspot - fixed special character parsing in "target" variable (CVE-2021-3014);
*) ike2 - fixed phase 2 rekeying with enabled PFS (introduced in v6.48);
*) ike2 - improved stability when invalid certificate is configured (introduced in v6.48);
*) ike2 - properly register packet time after expensive CPU operations;
*) interface - fixed pwr-line interface linking (introduced in v6.48);
*) ipsec - improved stability when processing IPv6 packets larger than interface MTU;
*) led - fixed default LED configuration for RB911-5HnD;
*) package - do not include multiple The Dude packages in HDD installer;
*) snmp - fixed "send-trap" functionality (introduced in v6.48);
*) switch - fixed interface toggling for devices with multiple QCA8337, Atheros8327 or RTL8367 switch chips (introduced in v6.48);
*) winbox - fixed enable/disable button presence for "Bridge/Hosts" menu;
*) wireless - renamed "macedonia" regulatory domain information to "north macedonia";

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 some problem has appeared on device

Please keep this forum topic strictly related to this particular RouterOS release.

does this release include the fix for the sip issue with discovery?

viewtopic.php?f=21&t=171035&p=840901&hi ... et#p840552

What about RB3011 port flapping re-introduced in 6.48?

Is DoH memory leakage fix?

A fix for SIP related issue is not included in this release, but it is available in the 6.49beta11.

If an upgrade to the testing version is not available, try disabling MNDP in neighbor discovery settings, see command below:
/ip neighbor discovery-settings set protocol=cdp,lldp

A fix for SIP related issue is not included in this release, but it is available in the 6.49beta11.

If an upgrade to the testing version is not available, try disabling MNDP in neighbor discovery settings, see command below:
/ip neighbor discovery-settings set protocol=cdp,lldp

i just disabled the neighbor completely, as i couldn't understand what use it had other then showing other mikrotik routers/switches
and a few of our cisco spa voip phones

What about RB3011 port flapping re-introduced in 6.48?

It's this one

) switch - fixed interface toggling for devices with multiple QCA8337, Atheros8327 or RTL8367 switch chips (introduced in v6.48);

What about RB3011 port flapping re-introduced in 6.48?

It's this one

) switch - fixed interface toggling for devices with multiple QCA8337, Atheros8327 or RTL8367 switch chips (introduced in v6.48);

Ou, I missed that. Thanks!

A fix for SIP related issue is not included in this release, but it is available in the 6.49beta11.

If an upgrade to the testing version is not available, try disabling MNDP in neighbor discovery settings, see command below:
/ip neighbor discovery-settings set protocol=cdp,lldp

i just disabled the neighbor completely, as i couldn't understand what use it had other then showing other mikrotik routers/switches
and a few of our cisco spa voip phones

I use it to be enable to connect with Winbox to a router that is not in the same network segment when only MAC initiated traffic is possible.

More info here in the Wiki: https://wiki.mikrotik.com/wiki/Manual:I ... _discovery

Try it with only MNDP disabled to ignore Cisco devices.

Problem with DoH was not fixed ?! omg

Use a separate device. I use a Pi, with dnscrypt-proxy running for DoH and Pi-Hole as the DNS Sinkhole. Uptime more than 8 months excluding updates/firmware patches/reboots.

could not upgrade from 48 to 48.1

kernel failure in previous boot
rb3011

Installed 6.48.1 to test device and first thing I noticed is that this Web UI bug introduced in 6.48 is still present in 6.48.1:

- By default /webfig/ URL (default after fresh login) always forwards to "QuickSet / Port Mapping" configuration options.

This happens even if Quick Set has been disabled and menu entries hidden in the UI.
Bug does not seem to affect functionality but is very annoying.

Upgraded the following units from 6.47.8
Two 3011
One RB750Gr3
One cAP AC

No issues and full production has been moved to these units. Will see during the weekend how all looks.

could not upgrade from 48 to 48.1

kernel failure in previous boot
rb3011

And, after all, the 48 -> 49b11 -> 48.1 was worked

So i am SICK !!! from stable branch
Please, rename it to Beta

No issues and full production has been moved to these units. Will see during the weekend how all looks.

Upgrading production systems 3.5 hours after new release at Friday afternoon.. what can go wrong and who would be guilty.

Problem also remains in this version.

Edit by moderator:
Please DO stop posting and quoting same set of quotes of quotes.
You have been already warned.
It is users' forum, not Mikrotik's staff one. Send e-mails directly to support.

A bunch of haP ac2, SXT, wAP, etc. updated.
So far so good.
IKEv2 is stable.

Problem also remains in this version.

Edit by moderator:
Please DO stop posting and quoting same set of quotes of quotes.
You have been already warned.
It is users' forum, not Mikrotik's stuff one. Send e-mails directly to support.

I'm sorry, but I've no idea which moderator made this edit so I can't ask directly, so: Could you please tell me when and how was I being warned? I think I wasn't informed at all so I was thinking I forgot to post it! So I reposted it! That's it! I've made this set of quotes to not leave any information behind.
Of course you can delete this message here after reading but please message me the way you've warned me so I'll catch it next time ..

Problem also remains in this version.

Edit by moderator:
Please DO stop posting and quoting same set of quotes of quotes.
You have been already warned.
It is users' forum, not Mikrotik's stuff one. Send e-mails directly to support.

I'm sorry, but I've no idea which moderator made this edit so I can't ask directly, so: Could you please tell me when and how was I being warned? I think I wasn't informed at all so I was thinking I forgot to post it! So I reposted it! That's it! I've made this set of quotes to not leave any information behind.
Of course you can delete this message here after reading but please message me the way you've warned me so I'll catch it next time ..

MikroTik support isn't any better, factually. Proof here: viewtopic.php?f=2&t=171390#p838707

Again, the DoH memory leak isn't fixed. Sigh.

Webfig seems to have some issues - "Add New" buttons do nothing on the following tabs:

• "Wireless": "WiFi Interfaces", "W60G Station" and "Nstreme Dual"
• "Interface": "EoIP Tunnel", "IP Tunnel", "GRE Tunnel", "VLAN", "VRRP", "Bonding"

The only thing that changes is the element id in the browser's URL box.

In example, I've opened the VLAN tab in the Interface section:

http://ap-test/webfig/#Interfaces.VLAN

After clicking the "Add New" button, the URL changes to:

http://ap-test/webfig/#Interfaces.VLAN.new

But nothing happens on the page itself.
Web Console in the browser spits out this error (Firefox 85.0):

Uncaught TypeError: map.setDefaultConf is not a function
createPane http://ap-test/webfig/master-min-d4f93cc8bdee.js:1190
updateContent http://ap-test/webfig/master-min-d4f93cc8bdee.js:1200
generateContent http://ap-test/webfig/master-min-d4f93cc8bdee.js:1204
openContent http://ap-test/webfig/master-min-d4f93cc8bdee.js:1205
onclick http://ap-test/webfig/master-min-d4f93cc8bdee.js:1137
create http://ap-test/webfig/master-min-d4f93cc8bdee.js:1137
open http://ap-test/webfig/master-min-d4f93cc8bdee.js:1125
updateContent http://ap-test/webfig/master-min-d4f93cc8bdee.js:1200
generateContent http://ap-test/webfig/master-min-d4f93cc8bdee.js:1204
onload http://ap-test/webfig/:1
master-min-d4f93cc8bdee.js:1190:323
createPane http://ap-test/webfig/master-min-d4f93cc8bdee.js:1190
updateContent http://ap-test/webfig/master-min-d4f93cc8bdee.js:1200
generateContent http://ap-test/webfig/master-min-d4f93cc8bdee.js:1204
openContent http://ap-test/webfig/master-min-d4f93cc8bdee.js:1205
onclick http://ap-test/webfig/master-min-d4f93cc8bdee.js:1137
(Async: EventHandlerNonNull)
create http://ap-test/webfig/master-min-d4f93cc8bdee.js:1137
open http://ap-test/webfig/master-min-d4f93cc8bdee.js:1125
updateContent http://ap-test/webfig/master-min-d4f93cc8bdee.js:1200
generateContent http://ap-test/webfig/master-min-d4f93cc8bdee.js:1204
onload http://ap-test/webfig/:1

...and on Chrome 88

Uncaught TypeError: map.setDefaultConf is not a function
at Object.container.map.createPane (master-min-d4f93cc8bdee.js:1190)
at updateContent (master-min-d4f93cc8bdee.js:1200)
at generateContent (master-min-d4f93cc8bdee.js:1204)
at openContent (master-min-d4f93cc8bdee.js:1205)
at HTMLAnchorElement.b.onclick (master-min-d4f93cc8bdee.js:1137)

Curiously, all of the above work fine when selected from the "Add New..." dropdown on the "Interfaces/Interface" tab - in this case "VLAN" opens:

http://ap-test/webfig/#Interfaces.Interface.new.VLAN

Issue seems to be introduced on v6.48 - on v6.47.8 this works fine.
Reproduced on hAP ac and CRS326-24G-2S+

could not upgrade from 48 to 48.1

kernel failure in previous boot
rb3011

Did you do any reboots with 6.48 before this upgrade?

The reboot failures with various models (RB3011 and CRS9x) is issue related to the first 6.48 release.

I have not yet tested if fresh install of 6.48.1 reboot bricks these devices - and if so - what percentage of them. 6.48 reboot bricked ~50% of the devices I tested.

could not upgrade from 48 to 48.1

kernel failure in previous boot
rb3011

Did you do any reboots with 6.48 before this upgrade?

The reboot failures with various models (RB3011 and CRS9x) is issue related to the first 6.48 release.

I have not yet tested if fresh install of 6.48.1 reboot bricks these devices - and if so - what percentage of them. 6.48 reboot bricked ~50% of the devices I tested.

Hi @Cray
no, i don't dare to make reboots. It is in production, and that was my mistake to rush on 6.48
i wanted PPP->Remote IPv6 prefix/IPv6 Routes features to finaly replace old scripts and without thinking pushed Upgrade button
what an idiot
From this point, my rock solid 3011 started to flap ports, and instead of rebooting i played with enable/disable to make them back to life
but now, 6.48.1 seem to solve this problem, only strange thing was upgrade path :D
48 -> 49b11 -> 48.1 was worked
could not go straight from 48 to 48.1

so i hope my nightmare is over

i will not push the Upgrade button until next year.

after upgrade winbox system health show temp and voltage but after i upgrade system >>routerboard>>upgrade and reboot the system health blank again like previous version

Two RB3011 units severely effected by 6.48 and updating to 6.48.1 did not fix, had to roll back to 6.47.8.

One RB3011 became unstable with port flapping but was kind of working long enough to be useful.

Another RB3011 rebooting with the kernel message, port flapping, and ports 6-10 were non operational. Impossible to downgrade - in the end I had to hook up to the console and Netinstall

This is first time i've had such a bad upgrade experience and I updated looking to get a fix for the issue with wireless clients not getting DHCP replies. It seems that MT never tested this release on RB3011, or did not test it properly. This is a very worrying development especially as this branch is supposed to be "stable". Today this cost me the whole day sorting one unit out as it ran the network for a very busy office.

Why is the DoH leak still not fixed? We asked for a fix a month ago.

Installed 6.48.1 to test device and first thing I noticed is that this Web UI bug introduced in 6.48 is still present in 6.48.1:

- By default /webfig/ URL (default after fresh login) always forwards to "QuickSet / Port Mapping" configuration options.

This happens even if Quick Set has been disabled and menu entries hidden in the UI.
Bug does not seem to affect functionality but is very annoying.

I raised a support ticket for this and ended up getting told to do a Netinstall. I closed the ticket.

Adding to the info I posted on the 6.48 thread and posting here again, as there's no fix related to that on 6.48.1 and also 6.49rc. Queue packets are really overflowing on the 32 bit signed integer limit, screenshot was taken with 6.48 on a RB1100AHx2. Not easy to reproduce, for sure, by the amount of packets required. On this RB, it took about 40 days to reach that 2,14 billion packet mark on the queue trees.
.

Upgrading all my devices from 6.47.8 to 6.48.1 went smooth, no problems.

Running 6.48.1 (stable) on :
CCR1009-8G-1S (2x ipsec/l2tp site-to-site, ipsec/l2tp roadwarrior, dhcpd, dns), CRS125-24G-1S, RB1100, RB962UiGS-5HacT2HnT (10pc), RB931-2nD, RB951, RB750GL ,RB2011UAS-RM, PWR-LINE-AP, RB750Gr3 running dude

no, i don't dare to make reboots. It is in production, and that was my mistake to rush on 6.48
i wanted PPP->Remote IPv6 prefix/IPv6 Routes features to finaly replace old scripts and without thinking pushed Upgrade button
what an idiot
From this point, my rock solid 3011 started to flap ports, and instead of rebooting i played with enable/disable to make them back to life
but now, 6.48.1 seem to solve this problem, only strange thing was upgrade path :D
48 -> 49b11 -> 48.1 was worked
could not go straight from 48 to 48.1

When you have a router like that in production, you should partition it so you can always go back to a stable situation without problem.
Of course enabling partitioning in a device in production is a risk as well, it will require at least one reboot and it may further disturb the device, so it is best done BEFORE you put it in production.
But at least, when you have clicked upgrade and it was a mistake, you can go back (when you have done a partition 0->1 copy before you clicked upgrade).

IP Service List > Available From no longer do it's function.
Since I update to 6.48.1[stable] on my Hex S, all IPs can now connect to Winbox.

Reverted back to 6.46.8[long term] and is working again. No other IPs can connect to Winbox other than listed on "Available From".

you should not use that as only defense,
you should use firewall rules to protect your management interfaces

CCR1009-8G-1S FW 6.48.1 PPPoE server drops connection with client every minute

you should not use that as only defense,
you should use firewall rules to protect your management interfaces

What do you mean shouldn't ???
What is this option for then ???

What is this option for then ???

You should not trust it, alt least not from public internet.
Some time ago thousands of router was hacked trough bug in software using WinBox port!!!!
From internet, you should use VPN.
I VPN is not an option at all, then follow this:

1. Use another port than default. Do NOT use 8291.
2. Use port knocking. This prevents someone from seeing open ports.
3. Use a long and good password.
4. Use access list to prevent any random internet from accessing your router.
5. Log everything. (See my signature for example.)
6. Upgrade firmware to latest stable release
7. ++++

----------------------------------

 
Why do not use Splunk to monitor your MikroTik Router(s)? Look at this page in how to set it up.

MikroTik->Splunk

BTW, the copyright needs to be updated for 2021... It still reads:
(And when you are at it... How about changing the url to https?)

When you have a router like that in production, you should partition it so you can always go back to a stable situation without problem.
Of course enabling partitioning in a device in production is a risk as well, it will require at least one reboot and it may further disturb the device, so it is best done BEFORE you put it in production.
But at least, when you have clicked upgrade and it was a mistake, you can go back (when you have done a partition 0->1 copy before you clicked upgrade).

Well, here we go again ...

it is my ? fault to not partition RB in advance ?
or it is MKT fault that release "stable" release with missing features, port flapping, kernel failure etc etc ...

no, it is not !!! my fault

if i install from "beta" branch, then it is my fault
if i install from "stable" branch ...

but, as in past, we never could agreed that MKT is doing wrong things
so, this time will be the same
according to your writing it is user fault to not thinkink in advance: what if MKT release faulty SW? do i have 3 pcs of RB3011 for backup sitting in closet for any case ? it is full moon today ?

no, no, always blame the user

Well, here we go again ...

it is my ? fault to not partition RB in advance ?

Completely irrelevant! It is your own responsibility to ensure that you can operate your equipment at sufficient availability for your network.
That includes being responsible for backups, rollback possibilities, spare hardware in case it breaks, and also if software is suitable for your purpose.
You cannot shift that responsibility to someone else, and certainly not to a supplier.

[/quote]
Completely irrelevant! It is your own responsibility to ensure that you can operate your equipment at sufficient availability for your network.
That includes being responsible for backups, rollback possibilities, spare hardware in case it breaks, and also if software is suitable for your purpose.
You cannot shift that responsibility to someone else, and certainly not to a supplier.
[/quote]

look @pe1chl
lets try to make things clear

my native language is not English, but i know well what word "stable" mean
but maybe i am wrong, who know
now, would you be so kind to explain what "stable" mean in your world ? port flapping ? kernel faults ?

and, no, i don't want any other answer
straight one, meaning of word stable is ...

BTW, the copyright needs to be updated for 2021... It still reads:

Code: Select all

MikroTik RouterOS 6.48.1 (c) 1999-2020       http://www.mikrotik.com/

(And when you are at it... How about changing the url to https?)

Very observant worm!! +30 points for House of Invertebrate! ;-)

Completely irrelevant! It is your own responsibility to ensure that you can operate your equipment at sufficient availability for your network.
That includes being responsible for backups, rollback possibilities, spare hardware in case it breaks, and also if software is suitable for your purpose.
You cannot shift that responsibility to someone else, and certainly not to a supplier.

...

look @pe1chl
lets try to make things clear

my native language is not English, but i know well what word "stable" mean
but maybe i am wrong, who know
now, would you be so kind to explain what "stable" mean in your world ? port flapping ? kernel faults ?

and, no, i don't want any other answer
straight one, meaning of word stable is ...

All the points pelchi made are quite valid for any business setup. For a homeowner, however I have tons of sympathy and can only recommend use the LONGTERM firmware as your best option.

and, no, i don't want any other answer
straight one, meaning of word stable is ...

Stable is don't be a pussy man! Stop complaining, you'll better send a bug report.

"Stable" . What's in a name? Pure convention, even vendor specific. This one might be inspired by Linux distributions.

https://en.wikipedia.org/wiki/Software_ ... le_release

https://wiki.mikrotik.com/wiki/Manual:U ... ase_chains

BTW, the copyright needs to be updated for 2021... It still reads:

Code: Select all

MikroTik RouterOS 6.48.1 (c) 1999-2020       http://www.mikrotik.com/

(And when you are at it... How about changing the url to https?)

They have enabled HTTPS overwrite on their domain, technically it wouldn't matter. But you'd expect a "networking" company to know their shit and the difference between HTTP and HTTPS.

and, no, i don't want any other answer
straight one, meaning of word stable is ...

Stable is don't be a pussy man! Stop complaining, you'll better send a bug report.

Send a bug report? Are you new to MikroTik, users both home and professionals have been reporting various bugs for decades and MikroTik refuses to fix them.

Here's one: viewtopic.php?f=21&t=172321#p842490

BTW, the copyright needs to be updated for 2021... It still reads:

Code: Select all

MikroTik RouterOS 6.48.1 (c) 1999-2020       http://www.mikrotik.com/

(And when you are at it... How about changing the url to https?)

They have enabled HTTPS overwrite on their domain, technically it wouldn't matter. But you'd expect a "networking" company to know their shit and the difference between HTTP and HTTPS.

That's not quite right, it does matter!
An attacker will make use of the fact that the first request is unencrypted. He/she can redirect you to his/her site, you will never receive the redirect from Mikrotik's http server and thus you will never see the encrypted version of Mikrotik's site.

When ever possible links should contain https instead of just http. Do not trust that the first unencrypted request will redirect you where you expect it.

BTW, the copyright needs to be updated for 2021... It still reads:

Code: Select all

MikroTik RouterOS 6.48.1 (c) 1999-2020       http://www.mikrotik.com/

(And when you are at it... How about changing the url to https?)

They have enabled HTTPS overwrite on their domain, technically it wouldn't matter. But you'd expect a "networking" company to know their shit and the difference between HTTP and HTTPS.

That's not quite right, it does matter!
An attacker will make use of the fact that the first request is unencrypted. He/she can redirect you to his/her site, you will never receive the redirect from Mikrotik's http server and thus you will never see the encrypted version of Mikrotik's site.

When ever possible links should contain https instead of just http. Do not trust that the first unencrypted request will redirect you where you expect it.

Wouldn't matter if MikroTik configured their domain host/CDN correctly like this:

Wouldn't matter if MikroTik configured their domain host/CDN correctly like this:

No. There's nothing Mikrotik can do on their servers. If the attacker is successful no request will ever reach Mikrotik's servers.

I tested the release on a CCR1036-12G-4S with Traffic of aprox 200mbit on 2 SFP ports -> still Port Flapping but not as often as in 6.48. About every 6h now.
Is there hope for an actual fix in the near future ?

Resize this window.

Upgrading RBM33G + R11-LTE6 devices from 6.47.9 to 6.48.1 no problems.
As a reminder, the upgrade from 6.48 to 7.1b4 is becoming a brick from the router. On default settings. Only netinstall helps.

it's better?

I do see the same on my RB 750G v3
Why do not not see Temperature/Voltage? I do see it on 6.48.0
Have you also upgraded routerboard firmware to 6.48.1 and rebootet?

on my RB750GR3 running 6.48.1 ...
no problems, there is just noting to configure so settings is empty ...

Upgraded several devices with no issues so far:
CRS326-24G-2S+
CRS112-8P-4S
CCR1009-7G-1C-1S+
hEX S
RB750GL
mAP2nD

Tried new stable 6.48.1 on my hAP ac2 after long-term 6.46.8.
The same situation with new long-term 6.47.9.
I don't like this difference in sector write quantity with the same config.
That's why had to downgraded to the 6.46.8.

Tried new stable 6.48.1 on my hAP ac2 after long-term 6.46.8.
The same situation with new long-term 6.47.9.
I don't like this difference in sector write quantity with the same config.
That's why had to downgraded to the 6.46.8.
6.48.1_cr.png6.46.8_cr.png

I'm running into the same thing with my hAP_AC2 . I don't understand why i'm getting some many sector re-writes. I was using 6.48.1 as the previous message but i'm still seeing them with the latest long term version.

Why do not not see Temperature/Voltage?

I had the same issue. It works again after I clicked "OK" on the empty settings page. (I use the web interface.)

#SUP-41913

A huge amount of sector writes. More than 7 000 000.
It seems that events such as changing the port state are being recorded.

These writes are real? How bad is it?

I have an Android TV device with USB ethernet adapter attached. The port status ever-changing.

Screenshots:

Screenshot 2021-02-15 223811.png

Screenshot 2021-02-15 223710.png

#Added later

I think this is for port flapping issue debugging. But at what cost?
As an experienced user, I want to have settings for disabling such wasting features.

Needs a dark mode

webproxy on hAP lite still doesn't work. Since versions 6.45.x

First try, its showed on "Web Proxy Connections" the server and client connection, but Browser never loaded the requested web. The next web requests ends with "connection timeout".

Is there plans to correct that issue?

Come on! Web proxy on a hAP lite???
Maybe it is better when MikroTik release a "RouterOS lite" version for use on smips which does not include such applications...
That would also ease the upgrading for those users, as they now often run out of memory during the upgrade and end up with a device that bricks or cannot upgrade.

webproxy on hAP lite still doesn't work. Since versions 6.45.x

Please welcome RZD Russia on Mikrotik forum!

As far as I understand, webproxy does not work on https site, so there are no use for it any more since nearly all site are https.

It can be used with https, but only when configured in the client as a proxy server. Not when configured in the router as a transparent proxy.

So if you have no control of the client, webproxy is useless.

So if you have no control of the client, webproxy is useless.

That is correct. You can do "auto proxy config" e.g. on Windows machines but it requires a webserver to store a file with the proxy config (the URL of that file is sent as a DHCP option).
In such cases it is a bit inconvenient that RouterOS does not provide a small webserver (unless you trick hotspot into doing that).

Hello everyone. I tell you that I have the v8.1 version installed on a 1036 router and I have problems with my interfaces that are connected.

inexplicably appears in the log link down and then link up for few seconds.

Please can you help me..?

After upgrade, the dude client takes too long to get connected to the dude server, some times hours. Any ideas?

RBmAP2nD with 6.48.1 connected to CAPsMAN ap's....MASSIVE packet loss (about 85%)

rushlife If the issue is version-related, please report it to support@mikrotik.com or in our support portal. Together with problem description and a supout.rif file made while the issue is present.

Hello! I upgraded about 5,000 CPEs (SXT 5 LHG 5 and SXTsq lite5) to version 6.48 (stable). After the update, everything was fine, but time passed (+ -3 weeks) and already on updated and working devices, the cases when the firmware takes off became more frequent, and you can only restore it with netinstall. Has anyone encountered this, do you have any thoughts?

as reported on 6.48, queue tree packets counter seems to be a 32 unsigned integer and is overflowing at 2 million and something packets. On that point, number becames negative and starts decreasing. The screenshot is from a RB1100AHx2 unit.

as reported on 6.48, queue tree packets counter seems to be a 32 unsigned integer and is overflowing at 2 million and something packets.

That is not the only "32-bit counter" issue in RouterOS v6. I have previously reported such issues and it seems the fix for that is planned only in v7.

That is not the only "32-bit counter" issue in RouterOS v6. I have previously reported such issues and it seems the fix for that is planned only in v7.

.
Great to know that. This is the first time/place in which I really stumbled upon this 32-bit overflow. I wasn't aware it's already known and planned for v7. Thanks for the info.

I'd replace cable connecting RB and UBNT ... marginal cable can cause lowering the negotiated speed.

mskoric; yes, sniffer disables fast path. The issue is fixed in 6.49beta11.

viewtopic.php?f=21&t=172259&p=842156#p844958

The reported SIP phone issue is fixed with this change:
*) fastpath - fixed IP packet receive on bridge and bonding interfaces when destination MAC address match with slave port MAC;

The suggestion to disable MNDP is because in the 6.48 version MNDP had some changes and it now uses an individual slave port MAC address instead of bridge/bond MAC. The same thing is done with other neighbor protocols, but MNDP is the only one that uses IP packets. It turns out, this can affect the ARP table on certain devices and they might start to use this other MAC from MNDP as a destination. On the RouterOS side with an active bridge/bond fast-path, these packets were dropped.

You might not notice the issue because MNDP is sent only once in a minute, the bridge did not use a fast-path or your phone simply ignored the MNDP.

I have 1 report with SIP problems on 6.48.1 on a 4011
Gigaset N300A basestation is unable to connect to the sip provider with MNDP on...

disabling it in IP->Neighhour->Discovery Settings solves the problem and all works fine

The Dude problem. My device's custom images disappeared from unknown reason. I was trying to recover my Dude database, but i'v got this:

/dude import-db file-dude.db
status: import failed

And all my job was go to the hell.

Database is creating daily by scheduler and it was always working in older versions.

Tried to get LLDP-MED working with Cisco and Grandstream IP phones, but the behavior of ROS renders this function unusable. During the first contact, ROS responds to LLDP-MED probe from the phone by burst of LLDP frames that include MED TLVs - this behavior is correct, the phone catches information about voice VLAN and connects in tagged mode. But when you reboot the phone, until ROS loses neighbor information (the phone is still present in neighbor cache), ROS does not respond to LLDP-MED probe immediately, instead it is sending LLDP frame every minute. As the phone does not see immediate reponse (in a few seconds) to the LLDP-MED probe, it abandons VLAN assignment via LLDP-MED and tries to connect untagged (in native VLAN).

The fix should be quite straightforward - after reception of LLDP-MED probe from the phone, ROS should respond by burst of LLDP-MED frames (including MED network policy TLV) always, regardless of the neighbor cache. This behavior is common amongst switches from many vendors.

Ondrej

But when you reboot the phone, until ROS loses neighbor information (the phone is still present in neighbor cache), ROS does not respond to LLDP-MED probe immediately, instead it is sending LLDP frame every minute. As the phone does not see immediate reponse (in a few seconds) to the LLDP-MED probe, it abandons VLAN assignment via LLDP-MED and tries to connect untagged (in native VLAN).

Interesting. I wonder if this is related to the issue I had found? viewtopic.php?f=21&t=171035&p=836796#p836789

Interesting. I wonder if this is related to the issue I had found? viewtopic.php?f=21&t=171035&p=836796#p836789

When looking at the behavior it seems there are three different problems with LLDP:

• bridge forwards LLDP frames
• LLDP frames are sent VLAN-tagged and without VLAN in LLDP-MED network policy TLV (this one may eventually be related to the previous one, but who knows)
• LLDP-MED probes are ignored in active neighbor state

Of course, no one can judge how these are related without investigation in the code.

In the current state, we decided to not use LLDP on boxes running ROS - there are no configuration options to control LLDP tx/rx and individual TLVs sent/accepted (security policy requires us to minimize attack surface and information available anonymously) and we cannot run even LLDP-MED at least for IP phones as it is unusable.

Ondrej

[*]bridge forwards LLDP frames

Just to be clear - is this true also when protocol-mode differs from none on that bridge?

[*]bridge forwards LLDP frames

Just to be clear - is this true also when protocol-mode differs from none on that bridge?

I haven't tried it yet, we do not use bridges in any of the xSTP modes (at the edge APs, where we use bridges, there's really no need to include them in the spanning tree topology). However, both protocols (xSTP and LLDP) are independent and thus the protocol setting (none/stp/rstp/mstp) at the bridge level should not change whether LLDP BPDUs are forwarded or not (yes, I know that in Linux kernel forwarding of both these protocols is controlled by the same bitmap setting group_fwd_mask, so there may be common point of both). Also, the behavior can be different in different modes of bridge operation (full software bridging, fast path, switchchip aka hardware acceleration), so there are many scenarios to check the behavior in all possible situations.

To be precise, the reasons why a when (not) forward STP and LLDP are also different:

• LLDP - intended to exist only between physical ports, so the bridge/switch should not forward LLDP BPDUs in any case
• STP - if the bridge/switch does not perform spanning tree operations, it should forward (=flood) STP BPDUs so it does not break function of spanning tree in the surrounding network (from spanning tree perspective such passive switch acts like a cable); otherwise, if the bridge/switch is active part of spanning tree topology, STP BPDUs need to be processed on reception and not forwarded

Ondrej

...the behavior can be different in different modes of bridge operation (full software bridging, fast path, switchchip aka hardware acceleration)...

And indeed it is. I did a quick test on RB750GL (switchip Atheros 8327) and the results are:

• bridge in full software and fast path modes with protocol-mode=none forwards LLDP frames
• bridge in full software and fast path modes with protocol-mode=rstp does not forward LLDP frames
• bridge in hardware accelerated mode always forwards LLDP frames

Also, in hardware accelerated mode, when the switch ports have configured VLANs, LLDP frame forwarded from access port to trunk port gets appropriate 802.1Q encapsulation, that is completely wrong, but this is expectable generic behavior of switch chip that doesn't know anything about LLDP.

Ondrej

After upgrading to FW 6.48.1, my 3 CCR1009-8G-1S routers (PPPoE servers) disconnect from PPPoE client every minute. What could be wrong? Upgrading to FW 6.46.8 fixes this issue.

upgraded hAP ac routeos and routerboard firmware (routerboot) as well from 6.47.4 directly to 6.48.1. - ethernet port started flopping, pretty much 'stock' config. dunno why :( downgrading to 6.47.8 solved the issue.

RB450Gx4, been running on this version since release. No flapping, no errors, no crashes or any noticeable issue.

aronw95, did you check the log after the first attempt?

Please help after upgrade to v6.48.1. MT is not booting.
hex rb750

Seams like my HEX (RouterBOARD 750G r3) crashes after about 30-40 Uptime days and what I just noticed now, winboard dosn't find it anymore, is that because i turned lldp off? I mean that winboard dosn't find the board?

When it crashes it dosn't reboot, i just notice that all my AP are down...then I have to poweroff the Hex..this happended now twice since version 6.48

I just noticed now, winboard dosn't find it anymore, is that because i turned lldp off? I mean that winboard dosn't find the board?

It seems that MNDP (neighbour discovery) runs on top of LLDP. However, you should still be able to connect to your router using winbox if entering its IP address (or MAC address), you just have to do it manually. If router is alive enough that is.

It seems that MNDP (neighbour discovery) runs on top of LLDP.

I may have misunderstood what you mean by "on top". If it means "in addition to", then that's correct - three protocols in total are used in parallel unless you disable some of them - MNDP (which is a UDP broadcast one), LLDP (which uses a range of multicast MAC addresses intended not to be forwarded by bridges) and CDP (which uses another range of multicast MAC addresses not forwarded by Cisco switches but forwarded by other vendors' ones).

If you had in mind that MNDP uses LLDP as its transport protocol, then this is incorrect.

Plus I know that RouterOS itself understands received PDUs of any of the three protocols, but I'm not sure whether Winbox understands CDP and/or LLDP; as a minimum, Winbox does understand MNDP, so disabling of LLDP alone on the hEX should not prevent Winbox from detecting the hEX.

MNDP is a UDP broadcast and will not work when IP is not configured. But Winbox can still detect devices in that state, it will list them without IP address.
So apparently Winbox does not use or does not rely on MNDP, but uses at least one of the LLDP or CDP protocols.

MNDP is a UDP broadcast and will not work when IP is not configured. But Winbox can still detect devices in that state, it will list them without IP address.
So apparently Winbox does not use or does not rely on MNDP, but uses at least one of the LLDP or CDP protocols.

Nope. MNDP is sent even if no IPv4 is configured on the interface, from 0.0.0.0 to 255.255.255.255.

As for LLDP, it seems the bridge on Hyper-V doesn't pass it from the CHR to the Windows, so I can't say whether Winbox would use it for neighor discovery, but it seems unlikely to me as it would have to bind very low to the network stack to ever see an LLDP frame even if the Windows would get it. If I disable MNDP and allow LLDP and CDP in the /ip neighbor discovery-settings, Winbox stops showing the 6.48.1 CHR among neighbors.

i have error and when startup 4 minutes for boot

error while running customized default configuration script: std failure: timeout (13)

That and a few other reports here sound suspiciously similar to what may have caused what I just described in detail at:

--> How to view or retrieve 'autosupout.rif' file without networking?

I don't know if it was introduced by this version or not, but I have a hEX S router and if I open "System ---> Health" from left menu it shows nothing at all, if I click at "Configure" there are no options to do.
But if I open a new terminal, and ask by manual command for this ( /system health print ) I have Voltage and Temperature as reply, with both values.

As I say I have latest stable version, Winbox is v3.27 (MKPS)

Tks!

Gerardo

Makes one wonder if these releases are tested... I've just updated a hEX PoE to this 'stable' release and so far:

In Webfig and Winbox: No /system/heath output at all
In Webfig: /Interfaces/VLAN/Add-New does not work at all - nothing happens when the button is pressed (in three browsers on 2 boxes)

In Webfig and Winbox: No /system/heath output at all

You upgraded the routerboard as well to 6.48.1 as well and rebooted?
System->Routerboard->Upgrade

In Webfig and Winbox: No /system/heath output at all

You upgraded the routerboard as well to 6.48.1 as well and rebooted?
System->Routerboard->Upgrade

I can confirm. I have an hEX Gr3, with 6.48.1. Upgraded firmware as well.
Webfig doesn't show health.
Winbox doesn't show health.
SSH works.

Yes, firmware and ROS updated. I did spot other errors in Webfig yesterday (things that just don't work, but do in Winbox) but can't remember what now. I just needed to get it working so cracked on in a console session.

#SUP-41913
I think this is for port flapping issue debugging. But at what cost?
As an experienced user, I want to have settings for disabling such wasting features.

You can turn off this logging under /system logging. Just create a rule (or disable one).

queue simple set [find max-limit=10M/10M] max-limit=15M/15M

This command is not working in this version. Is it bug or just command is changed.

I have had trouble with that with earlier versions as well. My workaround has always been to use another match to select the queue items to change.
(never persisted to find what is really going wrong there, but selecting on a match with the current limit values never seems to work)

New version 6.48.2 has been released in stable RouterOS channel:

viewtopic.php?f=21&t=174403