still hoping to have a small wifi2 package for device that have small space

Hello.

After upgrading to 7.3 sending emails through google fails. Any advice?

BR.

Hello.

After upgrading to 7.3 sending emails through google fails. Any advice?

BR.

Might be a Google thing.
I seem too recall an announcement from Google you can not use simple authentication anymore as of end of May.
Needs to be an app password (or something like that, can't verify right now)

Hello.

After upgrading to 7.3 sending emails through google fails. Any advice?

BR.

Might be a Google thing.
I seem too recall an announcement from Google you can not use simple authentication anymore as of end of May.
Needs to be an app password (or something like that, can't verify right now)

But this morning it worked perfectly, it was when updating all my computers from 7.2.1 to 7.3, sending emails (through google) from different accounts and different routers stopped working.

BR.

Might be a Google thing.
I seem too recall an announcement from Google you can not use simple authentication anymore as of end of May.
Needs to be an app password (or something like that, can't verify right now)

But this morning it worked perfectly, it was when updating all my computers from 7.2.1 to 7.3, sending emails (through google) from different accounts and different routers stopped working.

BR.

Works fine for me, gmail in a web browser, Apple Mail on OSX workstations, and Mail on an iPhone. I use Google Workspace, fwiw. CCR2004 on the edge, 7.3 with 7.3 firmware.

But this morning it worked perfectly, it was when updating all my computers from 7.2.1 to 7.3, sending emails (through google) from different accounts and different routers stopped working.

BR.

Works fine for me, gmail in a web browser, Apple Mail on OSX workstations, and Mail on an iPhone. I use Google Workspace, fwiw. CCR2004 on the edge, 7.3 with 7.3 firmware.

I am referring to sending emails through the routeros application /tool->emails

BR.

I am referring to sending emails through the routeros application /tool->emails

That is a feature that has been hanging by a thread for quite some time. Basically it could stop working at any moment.
It would be better to send the mails through the ISP's smarthost (which trusts the IP addresses within its own allocation) rather than directly to a Google server...

You are right, the problem is with Google.

Since May 30 they have reinforced the security of the accounts and now it is necessary to activate the two-step verification and then create "application passwords" on the Google website with 16 characters.

I have tried it and it has worked.

BR.

You are right, the problem is with Google.

Since May 30 they have reinforced the security of the accounts and now it is necessary to activate the two-step verification and then create "application passwords" on the Google website with 16 characters.

I have tried it and it has worked.

BR.

Thanks for confirming my memory is still ok ;)

You are right, the problem is with Google.

Since May 30 they have reinforced the security of the accounts and now it is necessary to activate the two-step verification and then create "application passwords" on the Google website with 16 characters.

But still you are not safe. Microsoft has done that before, and now they plan (in october, I think) to end support of those "application passwords" as well.
So, only 2-factor remains. Which of course sucks for applications like this.

Probably Google is going to do that as well... don't know if it has already been planned and announced.

In both routers

Code: Select all

/system routerboard settings set auto-upgrade=yes

was configured and routerboard firmware version was v7.2.3

You have remote routers on auto-upgrade and get them updated at the same day of a new 7.x release?
You seem to be more the YOLO type of admin ¯\_(ツ)_/¯

You have remote routers on auto-upgrade and get them updated at the same day of a new 7.x release?
You seem to be more the YOLO type of admin ¯\_(ツ)_/¯

That setting does not actually auto-upgrade RouterOS...
But indeed I have removed it on all my routers some time ago, after reading about mishaps with firmware upgrade. Now I only upgrade it when there are indications that it is required.

In both routers

Code: Select all

/system routerboard settings set auto-upgrade=yes

was configured and routerboard firmware version was v7.2.3

You have remote routers on auto-upgrade and get them updated at the same day of a new 7.x release?
You seem to be more the YOLO type of admin ¯\_(ツ)_/¯

Firmware version should always match RouterOS version, too many “admins” run on firmware version 3.1 and ROS v7 and complain about problems.

RB3011 is resolved by disconnecting the fibre from the SFP module and downgrading back to 7.2.1 along with firmware.

For the RB450Gx4 I have a feeling, disconnect some Ethernet cables might help

That setting does not actually auto-upgrade RouterOS...
But indeed I have removed it on all my routers some time ago, after reading about mishaps with firmware upgrade. Now I only upgrade it when there are indications that it is required.

Yeah, everything related to ”auto-upgrade” and similar scripts should be abandoned immediately until Mikrotik sorts out the release management.

It's actually pretty hard to understand why MT even try to promote this functionallity due to the current sitation (I was thinking about the YT stuff)

Firmware version should always match RouterOS version, too many “admins” run on firmware version 3.1 and ROS v7 and complain about problems.

Why? Do you have a change list for all the firmware version so you know what has been updated, and you can see that its needed?


PS to any auto upgrade or upgrade to a new release the first day it comes out on a production router, have not read this forum...
Wait a week or two, read forum, upgrade on a test router, equal to the production router. If all OK, you can upgrade if there are some new function that you need or an important fix that need to be added.

Firmware version should always match RouterOS version, too many “admins” run on firmware version 3.1 and ROS v7 and complain about problems.

Why? Do you have a change list for all the firmware version so you know what has been updated, and you can see that its needed?

Ask MT, they encourage the version should match as best practice. Either way, does it make sense to have firmware version 3.1 but ROS 7.3?

I do agree in that, but it would be better that firmware and RouterOS was just one thing, if it was to always upgrade both.

@DarkeNate
The 2 parts that make up the solution for Tik gear is:
1… The functional software that drives the capability
2… The Firmware [drivers] that enables the functional software to exploit the capability

So When upgrading it’s MANDATORY to always do both parts sequentially otherwise the capability will fail.

I do agree in that, but it would be better that firmware and RouterOS was just one thing, if it was to always upgrade both.

I'm just another customer of MikroTik. This flaw of RouterOS + firmware separation is for MikroTik to fix their xxx. The advice is set auto-upgrade=yes when upgrading ROS and then reboot twice, go figure.

@DarkeNate
The 2 parts that make up the solution for Tik gear is:
1… The functional software that drives the capability
2… The Firmware [drivers] that enables the functional software to exploit the capability

So When upgrading it’s MANDATORY to always do both parts sequentially otherwise the capability will fail.

Are you not aware of how auto-upgrade=yes works? It IS sequential by design from Tik. First you update ROS, then it injects the firmware into memory, then you reboot and then only the firmware gets flashed.

It is NEVER not sequential.

(@DarkNate don't use that rude language)

RouterBOOT / BIOS and RouterOS / the System is like a BIOS on motherboard and Windows (Linux, UNIX, etc.)
This difference has always existed and it is perfectly normal.

When I update an RB, I first extract the .fwf of the appropriate chipset from the .npk file inside the "etc" folder.
Next I put both the .fwf file and the .npk file in the root folder of the RouterBOARD, then I update with "/system routerboard", then reboot.
Done, just one step.
The point is: why doesn't RouterOS do it directly when auto update is yes, instead of waiting for reboot, to reboot later?...

(@DarkNate don't use that rude language)

RouterBOOT / BIOS and RouterOS / the System is like a BIOS on motherboard and Windows (Linux, UNIX, etc.)
This difference has always existed and it is perfectly normal.

Not sure what rude language – But the difference isn't clear with Tik as others pointed out. I've never bricked motherboards when flashing UEFI in 15+ years, but come to Tik land and all hell breaks loose.

Note: BIOS is dead since 2013, all modern mobos do not have it, it is only UEFI with some legacy support for BIOS in some models.

When I upgrade one RB, first I extract the .fwf of the appropriate chipset from .npk file inside etc folder.
Next I put both .fwf and .npk inside root folder, upgrade with system routerbard, then reboot.
Done, only one single passage.
The point is: why RouterOS do not do it directly when auto-upgrade is yes, instead wait the reboot, for reboot again later...

The point is simple: Poor Q/A from Tik as always… Arrogant too.

Oooooohhhh call it BIOS, call it RouterBOOT, call it EFI or UEFI, still a Basic Input/Output System than load, after some initializations, the Operative System...
Also SSD and other devices have inside own "BIOS" / firmware, etc.

Oooooohhhh call it BIOS, call it RouterBOOT, call it EFI or UEFI, still a Basic Input/Output System than load, after some initializations, the Operative System...
Also SSD and other devices have inside own "BIOS" / firmware, etc.

BIOS / UEFI are not the same underlying code/logic on motherboards. It's not just a marketing term brought up by Microsoft.

Though “firmware” applies to SSDs/GPUs etc, some calls them "BIOS" and makes perfect sense, UEFI is motherboard specific.

Either way love or hate it, Tik isn't fixing the real problems.

Is why some punctualizations are perfectly useless.

Since May 30 they have reinforced the security of the accounts and now it is necessary to activate the two-step verification and then create "application passwords" on the Google website with 16 characters.

The irony is that Google forces a somewhat low security password - it is 16 characters, but all lower case - no upper case, no numbers, no punctuation.

Google forces a somewhat low security password - it is 16 characters, but all lower case - no upper case, no numbers, no punctuation.

That’s plenty even for a massively parallel offline attack scenario.

Ask MT, they encourage the version should match as best practice. Either way, does it make sense to have firmware version 3.1 but ROS 7.3?

It very very rarely contains fixes for already released products and that is why we do not believe that it is worth forcing this upgrade and making a ROS upgrade much, much slower (if the bootloader would be upgraded at the same time).

MT telles that there are no (rarely any) changes, so no need to upgrade to save time while upgrading.

Google forces a somewhat low security password - it is 16 characters, but all lower case - no upper case, no numbers, no punctuation.

That’s plenty even for a massively parallel offline attack scenario.

The problem is that it does not work at all in scenarios where the stored password is leaked. E.g. someone puts it in their RouterOS config and posts a /export show-sensitive somewhere by mistake, or there is some bug in some device (can be anything, not just a MikroTik router) that allows reading this stored password.
That is what 2nd factor authentication solves, however it is not usable for such things as a router sending alerts by mail.
The question is, how to solve that. One way would be not to use mail for such things. Or at least do not use your main account, use a throwaway account only for this purpose.

That setting does not actually auto-upgrade RouterOS...
But indeed I have removed it on all my routers some time ago, after reading about mishaps with firmware upgrade. Now I only upgrade it when there are indications that it is required.

Yeah, everything related to ”auto-upgrade” and similar scripts should be abandoned immediately until Mikrotik sorts out the release management.

It's actually pretty hard to understand why MT even try to promote this functionallity due to the current sitation (I was thinking about the YT stuff)

Indeed one should never have some scripted daily auto-upgrade tied to the "stable" channel! it was again demonstrated that a new version that had 2 release candidates in "testing" is suddenly promoted to "stable" with known issues and even some last-minute changes. That is just not a good thing to do, a "stable" version should have been a release candidate at least for some time to get reports like this, and then it should just be promoted with no changes whatsoever. When there are changes, first make a new release candidate.

Now MikroTik argues that for this auto-upgrade one could use "long-term". However, the release policy of long-term is exactly the same: there are long-term versions that are not copies of the last stable, but have some additional quick fixes that could result in the same situation.

So ideally when you run an auto-upgrade script is should only trigger after the posted version is at least some days old (like 14 days or so), but that is probably difficult to do.

Why? Do you have a change list for all the firmware version so you know what has been updated, and you can see that its needed?

Ask MT, they encourage the version should match as best practice. Either way, does it make sense to have firmware version 3.1 but ROS 7.3?

In the days when firwmare had version numbers like 3.1 the firmware had separate version numbers that were incremented when a change was made. After updating RouterOS and going to the System Routerboard menu you would SEE if there was a firmware newer than the one on the routerboard and you updated it.
But at some point, the firmware version was made the same as the RouterOS version and now you get an update every time, even when nothing was changed (other than the firmware version number).
That has not made the situation clearer. Now you need to do an extra upgrade and reboot every time, and the system does not support automation of that.
E.g.:
- when you set the automatic upgrade in /system routerboard, and it has performed the update, reboot immediately
- or: perform the firmware upgrade as part of the routeros upgrade, which is in fact done by the running versionjust before the reboot, so the firmware upgrade could be part of that and the reboot required as part of the routeros upgrade also activates the new firmware

Okay, so here's what I did to fix the bootloop created by our amazing crap Quality Assurance experts and good ol' arrogant Tik inc.

For RB3011, you don't need to remove SFP module:
Remove fibre, it will boot, login, downgrade to 7.2.3 and do the same for firmware, reboot again.

For those using PPPoE:
Disconnect Ethernet cable from WAN ports on which PPPoE client is running, it will boot, login, downgrade to 7.2.3 and do the same for firmware, reboot again.

Once I have the budget, I'm leaving Tik for good and encouraging all my peers to dump CrapTik on both L3 and L2 – Hearing good things about Huawei, Arista and even DANOS.

Ask MT, they encourage the version should match as best practice. Either way, does it make sense to have firmware version 3.1 but ROS 7.3?

In the days when firwmare had version numbers like 3.1 the firmware had separate version numbers that were incremented when a change was made. After updating RouterOS and going to the System Routerboard menu you would SEE if there was a firmware newer than the one on the routerboard and you updated it.
But at some point, the firmware version was made the same as the RouterOS version and now you get an update every time, even when nothing was changed (other than the firmware version number).
That has not made the situation clearer. Now you need to do an extra upgrade and reboot every time, and the system does not support automation of that.
E.g.:
- when you set the automatic upgrade in /system routerboard, and it has performed the update, reboot immediately
- or: perform the firmware upgrade as part of the routeros upgrade, which is in fact done by the running versionjust before the reboot, so the firmware upgrade could be part of that and the reboot required as part of the routeros upgrade also activates the new firmware

You're expecting too much from CrapTik experts. They can't even ensure long-term is “long-term” as others pointed out in this thread and other discussions for the last 5 years.

It's 2022 and we don't even have dynamic ARP inspection on Tiks.

Solution: Migrate to a different vendor once your budget permits.

The question is, how to solve that. One way would be not to use mail for such things. Or at least do not use your main account, use a throwaway account only for this purpose.

Exactly why I have several gmail accounts for only that purpose (or for one-time registrations) next to my regular one ... already for a decade (at least).
You could also use Telegram, Twitter, whatever ... it will all become the same problem.

With O365 there is an option of trusted subnet to skip 2FA. If you got a fixed IP that's also a workaround if you want to use that service.
But for mobile setups or dynamic IP allocation, that will not work either.

There will always be a situation where 2FA is simply not possible.

The problem is that it does not work at all in scenarios where the stored password is leaked. E.g. someone puts it in their RouterOS config and posts a /export show-sensitive somewhere by mistake, or there is some bug in some device (can be anything, not just a MikroTik router) that allows reading this stored password.

As far as I have tested, this authentication using APP password has limited use. You can not logg inn to an gmail account with it (using web), so you can not change anything.

But to be safe, create a new gmail account, its free. Then forward stuff you send to that email to your normal email.

As far as I have tested, this authentication using APP password has limited use. You can not logg inn to an gmail account with it (using web), so you can not change anything.

There are (IMHO perfect legitimate) reasons for APP passwords:

• If it leaks, you just can revoke the APP password using your main login without having to change your main or any of the other APP passwords.

• A leaked APP password can only be used for what you allowed when creating it (accessing eMails and/or Calendar and/or gDrive and/or etc.). It never can be used to login to your main Account and most important not to change things or change any PWs or creating additional APP PWs or access CCs for the Appstore etc.

So it might be a bit inconvenient in some cases, but it's for sure much safer than using your main Google PW in routers and similar exposed devices.

Yes, it makes some sense. Of course it is better to have such a limited password than your full account password in the router.
I only wanted to indicate that Microsoft is ending the support for APP passwords in O365 soon and allow only "modern authentication" (meaning 2FA), and so it would not be unexpected when Google eventually does the same thing.
I don't know how they think that unattended devices should continue operating under that regime. It affects IMAP as well, e.g. we are polling some O365 mailboxes using "fetchmail" and it will not be possible anymore.

Jotne, app password is "app password". Not for web. The "limited use" is a feature, like jbl42 explained.

That’s plenty even for a massively parallel offline attack scenario.

The problem is that it does not work at all in scenarios where the stored password is leaked.

A password may be leaked no matter how many characters it has, or how wide the range of characters it uses. The post I was responding to implied that the all-lowercase 16-character limit was a problem, but raising those limits don't alter your objection. My only point is that these passwords' resistance to offline massively-parallel attacks is likely to suffice, since the device in question is likely to be retired before the ~14 years the page I linked to predicts.

Realize also that massively-parallel offline attacks aren't the norm. In this case, it would mean that Google's hashed password store was compromised, which doesn't seem likely. For online connection rate limited attacks, even 8 characters may be enough.

It's important to consider that these GMail application-specific passwords are machine-generated random ones. Much of the advice recommending long passwords carries the implication that humans will be making them up. With a random password, the entropy in each character is as close to ideal as the PRNG permits. (Roughly 5 bits of entropy for all-lowercase.) With a human-generated password, effective entropy can drop into the 1-2 bits per character range.

That is what 2nd factor authentication solves

Certainly, but that's also precisely why Google has this feature: they know not all applications of email are from humans, who can complete the MFA challenges. Automated senders require fixed passwords. Thus Google's solution: make them long (enough), random, and per-application to reduce the risks associated with fixed passwords.

not to use mail for such things

That is indeed becoming a common option. It's why I prefer off-router syslog to the cutesy "email the logs every night" stuff you see around RouterOS occasionally.

Guys,
stop this Gmail-thing conversation on the topic of specific ROS version. It's completely out of scope and interest of many.

The problem is that it does not work at all in scenarios where the stored password is leaked.

A password may be leaked no matter how many characters it has, or how wide the range of characters it uses. The post I was responding to implied that the all-lowercase 16-character limit was a problem, but raising those limits don't alter your objection.

True. I only wanted to mention it because it apparently motivates other serviceproviders to drop this form of authentication as well. It still works for gmail and it serves a purpose, but don't be surprised when you receive the announcement that its days are numbered.

There are no changes since rc2.

How can you not test the RB3011 SFP bug before releasing this into "stable"?

Very fun downgrading routers at remote sites today!


How can I go from 6.x to 7.2.x? If I set channel=upgrade it will chose 7.3 as of now.
Should I just manually upload 7.2.x NPK and reboot to get to 7.2.x?

Has anyone tested RB3011 and SFP with 7.4 beta?

There are no changes since rc2.

How can you not test the RB3011 SFP bug before releasing this into "stable"?

Very fun downgrading routers at remote sites today!


How can I go from 6.x to 7.2.x? If I set channel=upgrade it will chose 7.3 as of now.
Should I just manually upload 7.2.x NPK and reboot to get to 7.2.x?

Has anyone tested RB3011 and SFP with 7.4 beta?

Is there something you need in v7 that means you have to upgrade? If no rush I would wait for a real long-term build in v7 that support good upgrading from 6 to 7.

OlofL, 7.3 in general is much better than 7.2.x except this one issue with SFP on RB3011. We will have a hotfix later today. Don't install 7.2 just for this

OlofL, 7.3 in general is much better than 7.2.x except this one issue with SFP on RB3011.

This sounds so stupid. Its not "much better" for me. It broke everything.


So basically you make 7.3 release candidate.
Wait a few days and see how much forum is spammed.
If less than 5 new angry topics - move that exact release into "stable" channel.

So basically you make 7.3 release candidate.
Wait a few days and see how much forum is spammed.
If less than 5 new angry topics - move that exact release into "stable" channel.

Yes, that seems to be how it works. But usually between the last rc and the final release there are a couple of "last minute fixes" as well... at least it seems.
Also the time the last rc spent in testing was very short. If the 3011 SFP issue was there as well in that version, it would probably have come up when waiting a little longer before stable release.

Fortunately in another topic Normis now said they were looking at these schemes. It really has to be done more carefully.
Ideally what we want to see is a release of a version 7.3 [stable] that has the same date/time stamp of the last rc (in this case 7.3rc2). But there are 4 days between them, who knows what happened in those 4 days that makes the 7.3 different from 7.3rc2.

Trying to upgrade a cAPac from 6.49.6 to 7.3.1 and getting a "not enough space for upgrade" error (as well as warnings that 7.3.1 dhcp and wireless packages are broken). Try to upgrade to 7,3 and I still get the "not enough space for upgrade" error, but at least there are no complaints about broken packages.

I've tried resetting it and uninstalling unwanted packages, but to no avail. Is the only way to upgrade this to netinstall it?

Trying to upgrade a cAPac from 6.49.6 to 7.3.1 and getting a "not enough space for upgrade" error (as well as warnings that 7.3.1 dhcp and wireless packages are broken).

You probably at one time have switched to separate packages instead of the combined package. That causes this problem. It is best to netinstall.

Trying to upgrade a cAPac from 6.49.6 to 7.3.1 and getting a "not enough space for upgrade" error (as well as warnings that 7.3.1 dhcp and wireless packages are broken). Try to upgrade to 7,3 and I still get the "not enough space for upgrade" error, but at least there are no complaints about broken packages.

I've tried resetting it and uninstalling unwanted packages, but to no avail. Is the only way to upgrade this to netinstall it?

Make a backup of anything on .backup and .rsc format
save routeros-...-7.3.1.npk on your system, not on routerboard
extract from 6.48.6 extra packages only system-...-6.48.6.npk and copy it on routerboard
on System / Packages select uninstall to all except system, do not reboot, then click on downgrade,
now reboot
after downgrade put back 7.3.1, reboot, upgrade bios on System / Routerboard and import back the text .rsc file, section by section.

OR

backup all on external disk and
netinstall 7.3.1 selecting on netinstall 7.3.1 "Keep old configuration"

Make a backup of anything on .backup and .rsc format
<SNIP>

That worked perfectly. Thank you.