I am getting intermittent failures with connecting to our RB1100 using the API code provided on the wiki. The connect code is returning with success. The first login write/read pair returns as expected but sometimes the second read after the second /login write returns a trap. This is not happening all the time. Does anyone have a ny idea to make the interface function the same way every time?
Note I am using the C API.
what is delay between these messages, there is time-out, that you have to fit in. Or try 5.8 RouterOS
I put a delay of 2 seconds between the write of the second login command and its read, but between the read of the initial login write and reading its response there is no delay. Between the first read and the second write there is also no delay except the time it takes to generate the response using MD5. Are the delays documented anywhere?
Also what in 5.8 who help with timing problems like this?
use 5.8 just to be sure we are on same version so other differences would interfere. Also, what router is that?
Time-out value for challenge sent on first request is around 10 seconds. Should be enough for software client to log in.
So this is the sequence:
write /login
(Is there a delay between these two?)
read response
(Is there a delay between these two?)
write /login
(Is there a delay between these two?)
read response
Is the timeout of 10 seconds from the first write to the second read?
Our router is an RB1100.
Also once logged in is there some timeout before the connection is not longer valid? That is do we need to send and receive some from the router so the connection stays alive.
The weird thing is that I have a small program which all it does is login and either enables or disables one of the ethernet ports and it always works. In my live application I use the same C code and it always fails. I assume the value coming from the initial login is some sort of session key.
Is there anyway to turn off the md5 handshake? My router will be on a isolated network and there is no need for the extra security.