Share via

Troubleshooting BTARN Web Pages and more on BTARN x64

  • Article

 

Support for BTARN often involves issues connecting with the partner. Unfortunately the web pages deployed for this purpose are not the best when it comes to troubleshooting. It can be problematic to tell a customer they need to deploy new pages with increased tracking capabilities into their production environment. This is especially true if it is 3 AM. This was generally the situation prior to BTARN 3.3.

With .Net 2.0 some cut and paste changes to the web.config file often provide the same information without the need to redeploy pages to the production environment. The configuration changes provided here should be pasted in after the closing </system.web> tag. Then make sure the logging location exists and is available for output.

<system.diagnostics>

<trace autoflush="true" />

<sources>

<source name="System.Net">

<listeners>

<add name="System.Net"/>

</listeners>

</source>

<source name="System.Net.HttpListener">

<listeners>

<add name="System.Net"/>

</listeners>

</source>

<source name="System.Net.Sockets">

<listeners>

<add name="System.Net"/>

</listeners>

</source>

<source name="System.Net.Cache">

<listeners>

<add name="System.Net"/>

</listeners>

</source>

</sources>

<sharedListeners>

<add

name="System.Net"

type="System.Diagnostics.TextWriterTraceListener"

initializeData="c:\\trace\\System.Net.trace.log"

/>

</sharedListeners>

<switches>

<add name="System.Net" value="Verbose" />

<add name="System.Net.Sockets" value="Verbose" />

<add name="System.Net.Cache" value="Verbose" />

<add name="System.Net.HttpListener" value="Verbose" />

</switches>

</system.diagnostics>

A log will be created with great deal of detail. This includes the messages being passed. The log eliminates the previous issues with same-box transfers, SSL encryption, and sometimes limited access to network resources. Armed with this information it should be straight forward to understand the problem. The same information from BTARN 3.0 would require many lines of code added to the web pages to get the same information and as mentioned before redeployment of the enhanced pages.

BTARN and Windows 08 x64

In my previous blog I published help when using x64 with BTARN. This is particularly bothersome for Windows 03 x64 because BTARN is only available as a 32 bit application. Another little discovery has been detected with Windows 08 x64.

It turns out Windows 08 uses TLS protocol 1.0 as the default when attempting connections for BTARN (any HTTP). This was not the case with Windows 03. In some cases this turns out to be a problem. Close examination of the conversation shows the "Client Hello" being responded to with an "Encryption Error" or some other server drop. When things work properly the first attempt to use the TLS protocol should be followed with a second attempt to revert back to SSL 3.0 if the server cannot use TLS 1.0. Some servers don't allow the second attempt.

The fix for this situation is to change the code in the BTARN web pages. The following line of code should be added.

//this line for compatibility with Win08

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

//rest of the code

HttpWebRequest outerRequest = null;

ErrorLevel level = ErrorLevel.ProxyToOuterFailure;

This code sets a property. Location is not critical except I would keep it close to the HttpWebRequest object so it is easy to follow like listed above. This will prevent the use of the TLS protocol for this communication.