Community discussions

 
mkx
Forum Guru
Forum Guru
Posts: 2464
Joined: Thu Mar 03, 2016 10:23 pm

Re: v6.44.5 [long-term] is released!

Sat Jul 13, 2019 12:02 pm

Can't you connect via ssh but using administrative user name?
BR,
Metod
 
sanitycheck
newbie
Posts: 47
Joined: Wed Nov 16, 2011 6:03 am
Location: USA

Re: v6.44.5 [long-term] is released!

Sat Jul 13, 2019 7:32 pm

Can't you connect via ssh but using administrative user name?

Not in the standard configuration I use.

As a security measure the only user on the router with ssh rights is a special user for just that purpose, and it only has the ssh permission. I remove the ssh rights from admin. Admin user can only connect by remote through a second local login (Winbox, telnet) through ssh port redirect.

I can issue commands in the terminal window as the limited ssh user, but of course they are rejected because of no rights. From what I've found it is not possible to change users from within that window.

I have a server behind that router I connect to through ssh port redirect, in this case also with ssh. I can't connect to it either without the error and disconnection. So the problem isn't just trying to connect back to the router, it happens with any attempt to connect using an ssh port redirect.
 
tdw
Member Candidate
Member Candidate
Posts: 135
Joined: Sat May 05, 2018 11:55 am

Re: v6.44.5 [long-term] is released!

Sun Jul 14, 2019 12:04 am

I connect to manage routers with ssh using an rsa ssh key. SSH stong-crypto is set to yes. I upgraded a remote test router from 6.43.16 long-term to 6.44.5 long-term.

It allows me to make a connection using Putty as usual, the connection terminal window displays correctly. But when I try to manage the router through ssh port tunnel (redirect) to winbox or telnet it disconnects the ssh session with this error:

Strange packet received: type 82

The firmware was not upgraded to 6.44.5 because I could never reconnect to do it (user with ssh permissions is limited to just ssh, so management has to be through a redirected winbox or telnet unless there is a way to change users inside the ssh console window).

My Winbox is 3.19. If there is a change in the changelog that explains this problem I don't see it.

Upgrading to 6.44.5 (and possibly prior 6.44.x releases) does bonkers things to the SSH settings, in particular:
If strong-crypto=yes then allow-none-crypto=no is added - AFAIK this is fixed in the latest beta.
Pertinent to your situation forwarding-enabled=remote is added - IIRC this has been mentioned in previous threads that forwarding-enabled=both, or at least forwarding-enabled=local, would be a better choice on upgrade.

Message ID (packet type) 82 is SSH_MSG_REQUEST_FAILURE

Unless you have a port allowed through the firewall through which you can fangle a remote SSH tunnel I see a long drive in your future.
 
oxy1
just joined
Posts: 8
Joined: Tue Mar 07, 2017 2:19 am

Re: v6.44.5 [long-term] is released!

Mon Jul 15, 2019 8:27 am

How do you guys propose we make such a changelog? This is the long term branch, where releases are very rare, and the jumps are very big.
Imagine there could be 15 fixes, new bugs, fixes again, then the feature could be already removed, then a new one added, removed again, and then a new feature made and fixed.

Listing fixes for non existing feature would be useless.
Realistically though, the introduction then removal of a feature in "stable" prior to moving to "long-term" is unlikely to occur often. It's supposed to be "stable". :-)

The problem with reading the list of changes for "stable" is that often quite a few of the changes have already made it into the previous "long-term" branch. E.g. some fixes in 6.44.1 "stable" were also applied to 6.43.13 "long-term". So there's often quite a lot of duplicate information to wade through that may not be relevant at all. If I'm going from 6.43.16 to 6.44.5, I don't want to have to read a list of the changes that are already incorporated in the release I'm already running.

The way it is now means everyone who wants to upgrade would need to lay out both "stable" and "long-term" changelogs, side-by-side in chronological order, with all the possible changes, and then cross-reference between the two lists to see if there any (probable) matches. It really does make sense for this to be done once (by the team that actually develop the software?), rather than everyone having to do it each time the minor version number is bumped (or possibly multiple times, if you don't actually keep a copy of what you worked out). Do it once properly, and everyone (else) benefits enormously. It really will save a lot of effort overall (and probably grief).
 
Matrix64
just joined
Posts: 3
Joined: Thu Apr 18, 2019 11:37 am

Re: v6.44.5 [long-term] is released!

Mon Jul 15, 2019 2:44 pm

I wish the "long-term" channel would only have releases with bugfixes and security fixes, not a bunch of new features and underlying changes that need to be tested before I can apply the update to fix a security vulnerability. IMO, "long-term" channel should stay in 6.43.x branch and just receive fixes for at least 1 year, preferably more.
 
User avatar
Anumrak
Forum Veteran
Forum Veteran
Posts: 970
Joined: Fri Jul 28, 2017 2:53 pm

Re: v6.44.5 [long-term] is released!

Mon Jul 15, 2019 4:18 pm

I wish the "long-term" channel would only have releases with bugfixes and security fixes, not a bunch of new features and underlying changes that need to be tested before I can apply the update to fix a security vulnerability. IMO, "long-term" channel should stay in 6.43.x branch and just receive fixes for at least 1 year, preferably more.
This exactly what long-term branch is:

https://wiki.mikrotik.com/wiki/Manual:U ... _numbering
 
Matrix64
just joined
Posts: 3
Joined: Thu Apr 18, 2019 11:37 am

Re: v6.44.5 [long-term] is released!

Mon Jul 15, 2019 5:42 pm

I wish the "long-term" channel would only have releases with bugfixes and security fixes, not a bunch of new features and underlying changes that need to be tested before I can apply the update to fix a security vulnerability. IMO, "long-term" channel should stay in 6.43.x branch and just receive fixes for at least 1 year, preferably more.
This exactly what long-term branch is:

https://wiki.mikrotik.com/wiki/Manual:U ... _numbering
So why was 6.44 pushed to long-term if all we needed were a few Linux kernel fixes? I remember "long-term" channel going from 6.42 to 6.43 not long ago.
 
User avatar
chebedewel
just joined
Posts: 5
Joined: Tue Feb 02, 2016 6:41 am
Location: Noumea
Contact:

Re: v6.44.5 [long-term] is released!

Tue Jul 16, 2019 1:28 am

An upgrade on a hAP ac lite from 6.43.16 to 6.44.5 had an issue, only one wireless interface came back => one wireless interface was missing hence no connexion to CAP'sMAN.
It was fixed with a routerboard upgrade an a reboot.
Hopefully it was just a glitch on this device, as I have 1500 more in the wild with autoupgrade ...
Bertrand Cherrier
MTCNA - MTCTCE
_______________________________________________________
MikroTik Consultant & Distributor for New Caledonia
 
User avatar
Anumrak
Forum Veteran
Forum Veteran
Posts: 970
Joined: Fri Jul 28, 2017 2:53 pm

Re: v6.44.5 [long-term] is released!

Tue Jul 16, 2019 11:01 am

I wish the "long-term" channel would only have releases with bugfixes and security fixes, not a bunch of new features and underlying changes that need to be tested before I can apply the update to fix a security vulnerability. IMO, "long-term" channel should stay in 6.43.x branch and just receive fixes for at least 1 year, preferably more.
This exactly what long-term branch is:

https://wiki.mikrotik.com/wiki/Manual:U ... _numbering
So why was 6.44 pushed to long-term if all we needed were a few Linux kernel fixes? I remember "long-term" channel going from 6.42 to 6.43 not long ago.
Cause previous version became stable enough?
 
sanitycheck
newbie
Posts: 47
Joined: Wed Nov 16, 2011 6:03 am
Location: USA

Re: v6.44.5 [long-term] is released!

Tue Jul 16, 2019 7:15 pm

Upgrading to 6.44.5 (and possibly prior 6.44.x releases) does bonkers things to the SSH settings, in particular:
If strong-crypto=yes then allow-none-crypto=no is added - AFAIK this is fixed in the latest beta.
Pertinent to your situation forwarding-enabled=remote is added - IIRC this has been mentioned in previous threads that forwarding-enabled=both, or at least forwarding-enabled=local, would be a better choice on upgrade.

Thanks for that. Confirmed SSH changes you mention above were the problem. To upgrade any other routers with my SSH configuration to 6.44.x I will first have to create a temporary remote access method to prevent being locked out. Another riskier option would be to add a script in scheduler that sets the correct SSH options at next startup, since they can't be set in advance.

I agree that SSH forwarding-enabled might be better set to 'both' as a default, at least during upgrades, to prevent this type of problem.
 
ttaiw
just joined
Posts: 13
Joined: Mon Jun 29, 2009 5:48 pm

Re: v6.44.5 [long-term] is released!

Wed Jul 17, 2019 4:11 pm

I got problem with dhcp-relay , after upgrade my client cannot get address.
Now I downgrade to version 6.43.16 it work fine.

Who is online

Users browsing this forum: No registered users and 7 guests