Long lists returning via API issue

RouterOS Scripting
1

I’ve noticed an issue with a new Cloud Core router we installed running 6.10. When you query the device for data via the API for a command that returns a long list of information like “ip firewall filters” or in our case “queue tree” and “ip firewall mangle” the request eventually just times out. If I remove entries from the list then eventually it will return the list. This is a huge issue for us since we use the API to manage all our customer bandwidth settings on our core routers.

Here an example of the issue. You can see that the authentication works then the devices returns nothing and eventually the connection times out. This is using the routers.class.php available from https://svn.osk-net.pl/rosapi/trunk

!done
=ret=fb757ce8ca8d225c1c417e57e0a746ae

!done

getall: undefined type=


Other devices with large data sets running 5.26 and even 6.10 work fine. We also tried to upgrade to 6.12 and the issues persists.

Here I removed all accept 5 entries (out of the original 71 entries) and now it returns the data:

!done
=ret=cda5b1698a05cc48ac21e8af66bceba2

!done

!re
=.id=*97
=chain=forward
=action=jump
=jump-target=dedicated-conn
=connection-mark=no-mark
=bytes=49064364
=packets=172707
=invalid=false
=dynamic=false
=disabled=false
=comment=Jump to dedicated connection chain

!re
=.id=*98
=chain=forward
=action=jump
=jump-target=dedicated-mark
=connection-mark=!no-mark
=bytes=2420700950
=packets=4520595
=invalid=false
=dynamic=false
=disabled=false
=comment=Jump to dedicated packet mark chain

!re
=.id=*99
=chain=dedicated-conn
=action=mark-connection
=new-connection-mark=T5/IEC-PETRO1-CPE-A
=passthrough=false
=src-address-list=T5/IEC-PETRO1-CPE-A
=bytes=3254
=packets=52
=invalid=false
=dynamic=false
=disabled=false
=comment=T5/IEC-PETRO1-CPE-A Connection

!re
=.id=*9A
=chain=dedicated-mark
=action=mark-packet
=new-packet-mark=T5/IEC-PETRO1-CPE-A
=passthrough=false
=connection-mark=T5/IEC-PETRO1-CPE-A
=bytes=3100
=packets=57
=invalid=false
=dynamic=false
=disabled=false
=comment=T5/IEC-PETRONOR1-CPE-A Mark

!re
=.id=*51
=chain=forward
=action=change-mss
=new-mss=1440
=passthrough=true
=tcp-flags=syn
=protocol=tcp
=in-interface=all-ppp
=tcp-mss=1441-65535
=bytes=70864
=packets=1465
=invalid=false
=dynamic=true
=disabled=false

!re
=.id=*52
=chain=forward
=action=change-mss
=new-mss=1448
=passthrough=true
=tcp-flags=syn
=protocol=tcp
=out-interface=all-ppp
=tcp-mss=1449-65535
=bytes=6493144
=packets=121645
=invalid=false
=dynamic=true
=disabled=false

!done

2

The link doesn’t seem to work.

Regardless, I believe I know the reason… Many clients erroneously do a single fread($socket, $length), as opposed to gathering the data into a buffer, and re-fetching the remaining data as needed, until it’s all there. A few of them have already been fixed, but many others - perhaps including the one you’re using - remain unfixed.

Try to use the client from my signature, and see if it has the problem. I strongly believe it wouldn’t.