Community discussions

MikroTik App
 
User avatar
Deantwo
Member
Member
Topic Author
Posts: 332
Joined: Tue Sep 30, 2014 4:07 pm

SSTP Interface Queue Type is invalid after upgrade

Mon May 09, 2016 10:37 am

I have a recently just upgraded a number of routers running 5.18 to 6.35 and noticed a couple a scripts failing.
Doing a little testing I found out that it is because the Queue Type of a SSTP interface is not changed to the correct default during the upgrade.

In version 5.x the default interface queue type of a SSTP interface is "default".
In version 6.33.3 there seems to be no interface queue for a SSTP interface at all.
In version 6.35 the default interface queue type of a SSTP interface is "no-queue".

But the queue type is not changed during the upgrade, so the queue type is left as "default" which is an invalid queue type for a SSTP interface. This then results in script failures when trying to manipulate the SSTP interface.
Terminal example:
[admin@router 6.35] :put [/queue interface get [/queue interface find interface="sstp-out1"] queue]
default
[admin@router 6.35] /interface set [/interface find name="sstp-out1"] disabled=no
failure: non rate limit queues are useless on this interface
[admin@router 6.35]
To fix the issue I simple ran this little code on all my routers:
# Fixes SSTP interface queue not using the default.
/queue interface {
    :local a [find]
    :foreach o in=$a do={                
        :if ([get $o queue] != [get $o default-queue]) do={
            set $o queue=[get $o default-queue]
        }
    }
}
Steps to reproduce:
  1. Have router with RouterOS version 5.18
  2. Create SSTP Client interface
  3. Notice that interface queue type is "default"
  4. Upgrade router to RouterOS version 6.35
  5. Notice that interface queue type is still "default"
  6. Attempt to enable/disable the SSTP interface
  7. Receive error message "non rate limit queues are useless on this interface"
  8. Change interface queue type to "no-queue"
  9. Attempt to enable/disable the SSTP interface
  10. Everything works fine
Last edited by Deantwo on Thu Jan 18, 2018 4:44 pm, edited 3 times in total.
 
User avatar
Deantwo
Member
Member
Topic Author
Posts: 332
Joined: Tue Sep 30, 2014 4:07 pm

Re: SSTP Interface Queue Type is invalid after upgrade

Mon May 09, 2016 11:06 am

Tested upgrades:
  • 5.18 to 6.35: Invalid queue type
  • 5.26 to 6.35: Invalid queue type
  • 5.18 to 6.33: No interface queue and no errors
  • 6.33 to 6.35: Correct queue type
  • 5.18 to 6.33 to 6.35: Invalid queue type
  • 5.18 to 6.35.1: Invalid queue type
  • 5.18 to 6.35.2: Invalid queue type
 
xtornado
newbie
Posts: 31
Joined: Sun Mar 07, 2010 8:02 pm

Re: SSTP Interface Queue Type is invalid after upgrade

Tue May 21, 2019 10:00 am

Hello

Did you get this work on 6.44?

default queue type is default-small on 6.44 , i need to put all new dynamic interfaces on startup to ethernet-default or custom pfifo queue type

Can you help me?

Workaround for now:

1. empty queue tree rule
/queue tree
add comment=test name=queue3_test priority=5 queue=ethernet-default
2. Netwatch on remote host ip :
add comment=test disabled=yes host=172.16.1.5 interval=15s up-script="/queue tree set 3 parent=<sstp-sstp_hapmini> queue=ethernet-default
 
User avatar
Deantwo
Member
Member
Topic Author
Posts: 332
Joined: Tue Sep 30, 2014 4:07 pm

Re: SSTP Interface Queue Type is invalid after upgrade

Tue May 21, 2019 10:24 am

Hello

Did you get this work on 6.44?

default queue type is default-small on 6.44 , i need to put all new dynamic interfaces on startup to ethernet-default or custom pfifo queue type

Can you help me?

Workaround for now:

1. empty queue tree rule
/queue tree
add comment=test name=queue3_test priority=5 queue=ethernet-default
2. Netwatch on remote host ip :
add comment=test disabled=yes host=172.16.1.5 interval=15s up-script="/queue tree set 3 parent=<sstp-sstp_hapmini> queue=ethernet-default
This issue had nothing to do with "Queue Tree".

This was only an issue when "Queue Interface" was changed at some point between v6.33 and v6.35 and only when upgrading from v5.x, which was only an issue 3 years ago when I still had routers that needed upgrading from that old RouterOS version.

You might want to make a new thread about your issue, since it is likely not related to this.

Who is online

Users browsing this forum: No registered users and 26 guests