permission error 13 messages

[Instamess]

I'm not happy with getting these messages.

First, the message seems to be a catchall error number ...which is not helpful. Nobody seems to ever get an error 12 or an error 14.

Second, there doesn't seem to be a list anywhere of all the possible causes of this error. and the solutions.

The last time I started a thread about it I was told to send an email with the log and trace files - just like is asked in all the other error 13 support threads - and I got a long reply to perform certain tasks in Windows so NT could connect again. And it worked. But what I would rather have is an explanation about why these faults are caused in the first place and how they can be avoided/rectified without having to contact support. (I accept support is usually quick to reply in the forum, but my email complaint about an error 13 message from a week ago still doesn't have a reply).

Can somebody from support shed some light on this error 13 problem and point to a comprehensive document explaining what causes it and how to avoid the problem or rectify it? I have been unable to connect this evening and don't want to be subject to waiting on support's reply every time I have an error 13. I'd rather not get the error in the first place.

[NinjaTrader_Matthew]

Hi,

The error 13 indicates that you were unable to be authenticated by the system, which can fail at various points.

This can be related to local certificates (i.e., not installed, time and date incorrect) however is usually related to isolate incidents related to traffic shaping by the ISP.

In terms of your email that was not responded to, we generally respond within 15-minutes of our regular support hours. Your email sent on Oct 18 2013, 03:28 AM US Eastern was responded to at Oct 18 2013, 03:34 AM US Eastern time.

I've recently resent that response to you, please let us know if you did not receive it.

[Instamess]

Matthew, thank you for your reply.

I did get your latest email but not the one sent in response to my support request last week. I've been through my spam folder and it isn't there either which is strange as I've always found your responses prompt.

Anyway, I hear what you're saying about the possible causes. I can exclude the time and date as mine are configured to automatically synch with Microsoft's clock. With respect the local certificates - well, the last time you suggested this, it worked. However, sometimes when I log off and immediately try logging back on again I get the error. It would seem to me that if I didn't have the appropriate certs then I wouldn't have been able to connect the first time. Further, when I do get the error if I leave the PC for an hour or two and attempt a connect again (without a reboot), I am able to connect which again suggests it's not a missing certificate.

That would leave your last suggestion of ISP routing . You say this could happen rarely. But as it's happening frequently for me do you have any suggestions for how I can pin this down (i.e. pin down the fault to the ISP rather than NT or NT's servers)? I did once try a tracert to your IP and that worked fine, but I was still getting the permission error. In fact, doesn't NT have to actually reach your server and attempt a connection before that error 13 is generated? Or is the error generated when NT can't reach your server?

[NinjaTrader_Matthew]

Hi,

Thanks for the reply.

In my opinion it sounds like all the required certs are installed and there is no reason it's failing on the client end. It's good to check that they are installed, but there is no reason they should fail beyond that.

We usually use tools like tracert to isolate this behavior - when you tried this test, were you doing it to a NinjaTrader server or your broker server? It's authentication to the broker which is failing so be sure you're running the diagnostics to those servers. From the files you sent in last week, here is the server you would be connecting to:

ritpz02502.02.rithmic.com

The error can be presented while the server does not authenticate the request in time. So you may be able to resolve a ping/tracert to these servers, but it will still give an error if it is taking too long to do so.

Additionally, have you tried isolating this behavior to a single computer/network component? To completely isolate it to the ISP, please check for connection errors from another and eliminate any network hardware by plugging the computer directly into the modem. If you see the same error from the two computers on the same modem, you can work closer with the ISP.

[Instamess]

Hi Matthew,

Ah, so the tracert to your server showing up as fine doesn't matter in this case as my connection is likely failing on connecting to the broker ( that's the remaining option which I hadn't tested i.e. tracert to the broker)?

If so it would really help if the error message was better!!

The error 13 indicates that you were unable to be authenticated by the system, which can fail at various points.

A single error message for such a wide range of problems - from a missing certificate on the PC ... to the broker's server going down - is very frustrating wouldn't you agree?

[NinjaTrader_Matthew]

The errors come from the adapter as they're spec'd by the API. The error is enough to tell us that the user account cannot be authenticated to the broker system, but there is no way to know where it has failed in particular.

Please let me know if you have any questions.

[Instamess]

Whose API, Matthew? The broker's or the routing platform's?

But wouldn't a missing certificate on the user's PC have nothing to do with any external party's API and could be detected by NT itself and notified to the user as a certificate error rather than the catchall error 13?

[NinjaTrader_Matthew]

The error does not come from NinjaTrader source code, it is a native error that comes from the broker API.

We appreciate you for providing feedback in this area. Our support staff is more than happy to offer help to isolate and resolve these types of errors. If you're still facing this error, please let us know and we can help via remote support to help troubleshoot.

[Instamess]

Thanks, Matthew.

You're welcome for the feedback. I come from an IT background and improving usability of software is something I know all good companies take seriously. My suggestion is to make the error message less cryptic. Where possible it pays to tell the user what the fault is as that could reduce support calls - users can often then just resolve the problem themselves.

If a third party's API is throwing this permission error 13 without any clue as to what's causing it, it's not beyond the realms of possibility for NT to intercept that message and convey it in user friendly terms, e.g. "the broker's server is rejecting the connection" (which does help the user as he knows it's not his PC or router or ISP).

In this case I'm still a bit confused as the broker has nothing to do with it as far as I can see. Zen-fire's data feed is what I was trying to connect to so even if there's a problem with the broker why can't I connect to Zen-fire and get data? And if the connection problem was with Zen-fire, why don't I as the user know that it's Zen-fire that's the problem, not the broker?

PS: When I did a tracert it was to the IP that I pulled out of the router log - the IP that NT connects to. I appreciate that it's not NT's server, my earlier wording was sloppy.

[NinjaTrader_Matthew]

In this case I'm still a bit confused as the broker has nothing to do with it as far as I can see. Zen-fire's data feed is what I was trying to connect to so even if there's a problem with the broker why can't I connect to Zen-fire and get data? And if the connection problem was with Zen-fire, why don't I as the user know that it's Zen-fire that's the problem, not the broker?

Zen-Fire is the brokerage technology which is used to connect for data. I'm not sure I understand your question.

[Instamess]

Then Zen-Fire is broken!

I am updating this thread to help others who get this error. And maybe this thread will rise to the top of search engine results for the permission error 13 problem.

NT support staff have been very kind and we are still talking via email trying to resolve the problem of frequent permission error 13 login problems. They would now like to remote access my PC when the problem is happening. I've agreed for this despite knowing in my own mind that my PC isn't the problem, it's Zen-Fire.

The following are the list of main possible reasons I've been given:

- SSL certificates on my PC missing or damaged
- A DNS or routing problem trying to get to the Zen-fire server
- A firewall or other security on my PC causing a block
- The fact that I don't use Internet Explorer (!!!) as my browser (or a proxy setting related to that)

SSL certificates aren't the issue. The certificates won't exist one minute and be gone the next.

DNS / Routing: I've excluded this as the cause. When I have problems logging in I try a tracert from different locations like Australia, US etc., and they too fail at Bigwells (Zen-fire's IP) or the Zen-Fire backbone IP - nLayer. This suggests a problem at Zen-Fire and nothing to do with my PC (which nobody seems willing to accept). Their server doesn't have IMCP echo turned off so tracert should work and if it times out then the problem is at the server end.

I've excluded the firewall as the cause. The permission error 13 occurs independently of whether the firewall is on or off. I don't have any anti-virus running.

The last one needs some explanation. I do not have IE on my PC. Apparently NT needs some components of IE and depending on how you uninstalled IE it could cause a fault. But I uninstalled IE a long time ago and before I ever installed NT. And the NT login works fine some of the time, so it can't be the missing IE causing the fault.

Folk, my conclusion is that it's Zen-Fire that's screwing me up. When I need to login, I need to login and with Zen-Fire, it appears, this is somewhat flaky. Bear that in mind if you're getting the permission error (13) message - it may not be your PC that's the problem. I have found the highest level of unreliability is after 11 PM UK time perhaps it's because of all those traders in the US logging in on their return from work... or something else altogether.

Your mileage may vary.

A simple change in error message could separate an IP unreachable from all the other causes of permission error 13. It's my suggestion that Ninjatrader implement that in their next upgrade to the software.

[NinjaTrader_Matthew]

Please allow me to offer some clarification from our perspective:

In our experience, users can receive the permission 13 error from one location, however they are also able to log into from another location or ISP (switching from cable to DSL for example). This to us points to ISP issues. We have a large user base who have never experienced this error. With all due respect, a problem of this magnitude with a broker technology would be experienced by all users, not just a subset of users. I've checked with one of my contacts and he has confirmed for me there are no issue with Zen-Fire at the times you've reported.

I was under the impression we determined a long time ago that your PC wasn't the issue, but it was something outside of your PC. We only want to log into your PC so we can enable some verbose logging which will pinpoint the exact moment the certificate fails. Again, I do not think there is anything wrong with your PC, but rather ISP issues.

Furthermore, the destination server is not pingable. Can you clarify exactly how you determined they are? Are you sure you're trying to ping the true destination server?

Below is a tracert to a Zen-Fire server. It begins to fails after nlayer which is the backbone used by this technology, which is then passed to the destination server which is not pingable and hence does not resolve. This is expected behavior and would be seen from any location. What we're looking for in a tracert is the amount of time it takes to be handed from one ISP to another. In our experience, the tracert will complete to the nyayer backbone, but it is what is happening before that which clues us into what is going wrong.

tracert 199.30.196.169

Tracing route to ritpz02502.rithmic.com [199.30.196.169]
over a maximum of 30 hops:

  1     1 ms     1 ms     1 ms  173-14-19-14-Colorado.hfc.comcastbusiness.net [1
73.14.19.14]
  2    33 ms    15 ms    17 ms  23.70.62.1
  3    11 ms     9 ms    10 ms  te-7-1-ur09.denver.co.denver.comcast.net [68.85.
221.81]
  4    14 ms    14 ms    15 ms  te-0-11-0-8-ar02.denver.co.denver.comcast.net [6
8.86.179.121]
  5    13 ms    18 ms    15 ms  pos-0-7-0-0-ar02.aurora.co.denver.comcast.net [6
8.86.128.246]
  6    12 ms    15 ms    15 ms  he-3-10-0-0-cr01.denver.co.ibone.comcast.net [68
.86.92.25]
  7    34 ms    35 ms    35 ms  he-5-11-0-0-cr01.350ecermak.il.ibone.comcast.net
[68.86.86.185]
  8    36 ms    37 ms    34 ms  be-17-pe03.350ecermak.il.ibone.comcast.net [68.8
6.82.222]
  9    36 ms    38 ms    41 ms  as4436.350ecermak.il.ibone.comcast.net [173.167.
57.126]
10    34 ms    34 ms    39 ms  as22957.ge-0-0-32.ar1.ord1.us.nlayer.net [69.31.
105.54]
11     *        *        *     Request timed out.
12     *        *        *     Request timed out.
13     *        *        *     Request timed out.
14     *        *        *     Request timed out.
15     *        *        *     Request timed out.
16     *        *        *     Request timed out.
17     *        *        *     Request timed out.
18     *        *        *     Request timed out.
19     *        *        *     Request timed out.
20     *        *        *     Request timed out.
21     *        *        *     Request timed out.
22     *        *        *     Request timed out.
23     *        *        *     Request timed out.
24     *        *        *     Request timed out.
25     *        *        *     Request timed out.
26     *        *        *     Request timed out.
27     *        *        *     Request timed out.
28     *        *        *     Request timed out.
29     *        *        *     Request timed out.
30     *        *        *     Request timed out.

Trace complete.

Please allow us to log in the next time you receive this error and we can enable the verbose logging which was offered. I understand that this last occurred during a time our IT manager was out of the office and we're looking into other ways we can assist at that time.

We appreciate your efforts in helping clarify this error and I do hope this helps users in the future, however all of the reasons given have been known to cause this error and there is not a catch-all fix for this API error. We can pass your feedback to Zen-Fire regarding the generic error to help offer clarification in a future API release.

Thanks for your understanding and we look forward to helping you remotely the next time you experience this error.

[Instamess]

Thanks, Matthew. I have numerous copies of the tracerts I've done and I've emailed a few of them over in the email conversations. Rest assured I'm doing tracerts to the correct IPs for the two rithmic.com subdomains which resolve to 199.20.196.169 and 199.20.196.170. Also, I do have two different ADSL connections at home from different ISPs and can probably get permission from my neighbour to use his wi-fi. It all seems an exercise in futility if the fault is elsewhere but I'm willing to jump the hoops to prove to you it's not the ISP.

You make a valid point in that an error like this is likely to affect more than the occasional user. I've seen numerous threads here on the permission error 13 issue, but it's not to the extent of the massive problem it seems to be to me. And some of those users' faults could in fact be due to security certificate or other causes.

But, if my PC is clear and the route to the IP is clear then I'm struggling to see where else the fault could be.

You aren't convinced of the latter - i.e. the ISP, DNS, tracert - so we'll run the verbose logging when it next happens. The problem is that it tends to happen most consistently for me after 11 PM when I login to check charts before going to bed. And that's a bit late to start a support call but I'll try again.

I do have two screenshots of tracerts from last night, one from the UK and one from Australia, both to 199.20.196.169. I could attach them here. If I understand correctly you are saying that (among other things) a slow node somewhere could cause NT to throw a permission error 13 message?

Furthermore, the destination server is not pingable.

There's some logic to turning Ping responses off but if they have turned them off we've no way of telling if the fault lies at that end, do we?

Thanks again to you and other staff at NT for their patience with me. Maybe there's nothing wrong with Zen-fire and it's just me that Zen-fire is targeting!

[NinjaTrader_Matthew]

Cyber security outweighs the limited benefit we'd have by having these IP open to the public. It's completely understandable that a system such as a broker server would want to protect themselves from DDoS, etc.

A good reason that it happens after a specific time if traffic shaping policies that may be in play by your ISP:

http://en.wikipedia.org/wiki/Traffic_shaping

http://en.wikipedia.org/wiki/Bandwidth_throttling

I do have two screenshots of tracerts from last night, one from the UK and one from Australia, both to 199.20.196.169. I could attach them here. If I understand correctly you are saying that (among other things) a slow node somewhere could cause NT to throw a permission error 13 message?

If the client does not hear back from the system in enough time this can cause the validation procedure to return with this error.

I reviewed these with our IT Manager and we did notice a very high ping time from some of the nodes between you and Zen-Fire. One of which timed out completely. The tracert has a timeout switch where if it doesn't get a response in X amount of time it'll just move on. This is what we were seeing in one of your results which tells us there was quite a bit of traffic on that node and is where I'd start looking. This could be completely out of your ISP hands but you may want to check to see if they have any other routes they could take.

[Instamess]

Thanks, Matthew. I don't argue that people shouldn't protect against potential DDoS attacks. I do the same on servers I manage. I have no complaint about the lack of ping response. My main issue is being able to connect whenever I want and not trusting it to luck. Clear error messages would help so I know where the fault is when there's a fault.

If there's a slow node then the client should be warned about the routing problem rather than getting the same message that he gets when certificates are missing.

In one of the emails, support got back to say that at the given time there was no known problem at Zen-fire. But what happens when there IS a problem at Zen-fire? I'd still get the generic error 13 rather than a message saying that Zen-Fire is aware of problems and is working to resolve them?

Anyway, I got the error again this morning and, given that we're trying to eliminate route, I tried a different ISP. I still got the error message (I could even try a DNS independent of the ISP but I'd still get the same message which suggests it's not the route). On one of them there was a slow node, yes, but not on the other. Yet I couldn't login with either ISP. I've emailed copies of those tracerts.. Some time later and without even a reboot I was able to connect.