My php api has stopped working after going to v6.0

I need to try and get the following working using an alternative method...

--
$ARRAY = $API->comm("/system/resource/print");
$first = $ARRAY['0'];
$wan_ip = $row['wan_ip'];
$uptime = $first['uptime'];
$cpu_load = $first['cpu-load'];

--

$ARRAY = $API->comm("/system/reboot");

--

$ARRAY = $API->comm("/ip/hotspot/host/print", array('bytes'=>''));

for ($i=0; $i<250; $i++)
{
$load = $ARRAY[$i];
$mac = $load['mac-address'];
$newin = $load['bytes-in'];
$newout = $load['bytes-out'];
}

--

Any help would be hugely appreciated.

What error message(s) are you getting?

As one possible problem: Are you sure there's NO certificate in place at "/ip services" with the API? In 6.0, API now supports TLS encryption, but no API client supports this yet, so if you make the connection encrypted, they all choke (no exceptions; not yet). AFAIK, having no certificate turns the connection back to an unencrypted one.

Here's a rewrite with PEAR2_Net_RouterOS, as per your request in the title: But if the issue is in configuration (whether that's encryption, or merely firewall rules), you'll likely get similar errors here too.

api-ssl is on port 8729, api service is still on 8728 (of course these are the default ports). All clients connecting to old service should work without issues.

And to make client for api-ssl all you have to do is - when creating socket (a connection) you should use TLS. When secure connection is up and running - it is old API again.

api-ssl is on port 8729, api service is still on 8728 (of course these are the default ports). All clients connecting to old service should work without issues.

And to make client for api-ssl all you have to do is - when creating socket (a connection) you should use TLS. When secure connection is up and running - it is old API again.

Oh. OK... I was merely guessing, due to the currently absent documentation on the question (combined with the fact patrickclover never described the actual error message(s)).

I have a related question about that though - doesn't TLS require a certificate on the router (akin to "www-ssl")? Also, I recently upgraded my router to 6.0, and I don't see "api-ssl" (nor "api-tls" or anything similar) in "/ip service". I only see the old services. Is this a known issue?

API-ssl is available starting RouterOS 6.1

Since we make the client side we can determine what requirements we want to enforce.

Without the certificate api-ssl will use ADH cipher. If a certificate is set - ADH will not be used anymore and certificate will be sent instead, then you on your client can check if you "like" this certificate and upon your decision. For example, most of the web browsers (being SSL clients) reject connection if there is no certificate or origin of certificate cannot be established (that is certificate is untrusted).

If you have ssl capable libraries, like openssl, you can follow instructions on how to establish a secure connection

how to display the connection error, if a router is not available?

how to display the connection error, if a router is not available?

With Denis' class, I don't know if you can at all.

With PEAR2_Net_RouterOS, you surround the code with a "try {} catch () {}" block, and inspect the previous exception to SocketException (the last one just tells you that it's the connection that failed, as opposed to it being a failure of sending/receiving data). For example:

how to display the connection error, if a router is not available?

With Denis' class, I don't know if you can at all.

With PEAR2_Net_RouterOS, you surround the code with a "try {} catch () {}" block, and inspect the previous exception to SocketException (the last one just tells you that it's the connection that failed, as opposed to it being a failure of sending/receiving data). For example:

Code: Select all

try {
    $client = new RouterOS\Client('192.168.0.1', 'admin', 'password');
} catch (RouterOS\DataFlowException $e) {//In this try block's case, invalid credentials is the only possibility
    echo $e->getMessage();
} catch (RouterOS\SocketException $e) {
    //In this try block's case, connection failure is one of two possibilities,
    //the other being that you're connecting to a different kind of service (e.g. if you have an HTTP server at that port)

    $previous = $e->getPrevious();
    if ($previous instanceof \Exception) {
        echo "{$previous->getSocketErrorNumber()}: {$previous->getSocketErrorMessage()}";
    } else {
        echo $e->getMessage();
    }
} 

Thank you very much!

@boen_robot:
I'm finally switched to your PEAR API can you tell me one thing:
I'm connecting to my router like this: Is my connection secure, even if I'm not using any certificate?
Is the connection between php server and routerboard encrypted? Is it any different than regular connection without NetworkStream::CRYPTO_TLS?

With that, yes.
If you're not using a certificate, you have no guarantee that the device you connect to is the one you intended, but you DO have guarantee that no 3rd device would be able to listen in or manipulate data exchanged with that device.

So if, for example, there was a router between your web server and router, and I was an attacker who had control over that middle router, I could dst-nat you to MY own "spy device" with a pseudo router with ADH running, and your PHP app wouldn't know the difference - it would communicate with my spy device, which could in turn perhaps relay this over a new connection to your actual router. Since I could log the info from both ends, this renders the whole encryption thing pointless. If my router was set such that your web server is behind its NAT, it's even better - my spy device could safely use the middle router's public IP, and your router wouldn't know about my spy device.

But this is still one step better than an unencrypted connection, where an attacker doesn't even need control of a router in order to listen in, but just be in your router or web server's LAN.
It's only different in that the connection is encrypted... Or rather, it SHOULD be. Sadly, it's not currently the same. Due to internal PHP issues, encrypted connections are currently very unstable. They can disconnect (seemingly) randomly.

Keep in mind that even with an unencrypted connection, your router's password is never transmitted in plain text. It uses a CHAP challenge (you know, like in hotspot), which is not trivial to crack - If an attacker gets ahold of the successful CHAP exchange, they can then do unlimited amount of tries on their machine, but they must still actually brute force the password, which can take a long time, depending on how complex your password is and how powerful their machine is.

The more troublesome part is if you're using the API to modify user passwords - those are transmitted in plain text.