Permalink: www.outsystems.com/goto/tcpsniff
 

Overview

Sometimes you may encounter some problems where you find it useful to know what is being passed between the server and the client of a HTTP communications. A frequent situation is that you have a web service that is not producing the desired result, you have already got it all sorted out on the applications (correctly imported, correct data types, ...) but when calling it you either get an error, or no results at all. Other scenarios where this may become useful are when you suspect of connectivity issues between servers, or simply when you are curious to know what is being transfered between your browser and your server when you access a given page.

For this, there is a procedure called TCP sniffing, which is literally to sneak peek at the communications between the two parties involved. Many tools exist for that, and this post explains how to do it with one given tool, for the sake of simplicity, although the explanation is transversal so any other tool can be used. 

The procedure above is generic enough to be used with any of the OutSystems AgilePlatform tools, when troubleshooting 3rd party integrations, or even for non-OutSystems related communications

How it is done - high level

There are two typical ways to sniff TCP communications:

  - Placing the sniffer in the middle of the communication, and altering one or both ends of the communications to explicitly send traffic to it. This procedure demands changing involved URLs in the application logic, but is typically less intrusive since you don't need access to the server and/or sniff all communications;

  - Sniffing the communications between both parties without explicit man-in-the-middle. This option is more faithful to the desired setup, but is more intrusive.

This post focus on the first perspective - explicit sniffer in the middle. The tool chosen for this procedure is TCPTrace, which is a free and simple tool that needs not be installed - simply unzip the program and run it. The sniffer itself runs only in Windows machines, but can be used to sniff communications between any servers. Other programs exist with the same set of functionality, so you might opt for your favorite one.

Just for information, a program that is used for the second perspective is Wireshark, but its use is outside the scope of this post.

TCPTrace

TCPTrace can be obtained at https://www.pocketsoap.com/tcptrace/ . After downloading it, simply run it and configure its options:

  - local port where TCPTrace will be listening;

  - IP of the destination computer

  - port in the destination computer

Local port should be a port that is not being used in the computer where TCPTrace is run. 8080 is usually a good choice.

Make sure to configure the correct ports for destination. For HTTP port, it is typically port 80; SMTP is typically port 25. Other port listings can be used, depending on the context.

To test sniffing, simply open a web browser and access https://computer:8080/ (where computer is the machine where TCPTrace is running). You will see some lines in the window indicating communication with the destination server. If you do, congratulations, you have TCPTrace running.

Some usage scenarios

I. Sniff communication between Service Studio and Service Center

To do this, simply start TCPTrace, and use computer:8080 instead of servername in the dialog in Service Studio.

II. Capture communications (get/post) between browser and server

To do this, rewrite application URLs to use computer:8080 instead of servername in the server part. If using AgilePlatform 4.2, remember to turn off IIS compression and back on when you are done (https://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/d52ff289-94d3-4085-bc4e-24eb4f312e0e.mspx?mfr=true)

III. Capture Web Service Communications

This one is a little trickier, as it involves importing a changed version of the WSDL. Steps are as follows, and assume web reference created in Service Studio:

  1. Get the WSDL from your web service (put the URL in a web browser and save the text file you obtained);

  2. Open it with a text editor, and locate (typically at the bottom) a tag in the form:

      <wsdl:service>

        <wsdl:port>

          <soap:address location="https://servername/some/path/to/a/service.asmx" />

        </wsdl:port>

      </wsdl:service>

     Here you need to replace servername with computer:8080. Note that you might have several port/address elements - make sure to change them all. Also note that, in this case, computer must be a machine visible by the OutSystems server - if you can, simply run TCPTrace in the OutSystems server for simplicity.

  3. Refresh the web reference with the altered WSDL (replace the URL you originally inputted with the path to the file, e.g. c:\test.wsdl);

  4. Publish the eSpace

  5. Run the logic that calls the web service. You will be able to see the contents of the communication in TCPTrace.

IV. Capture communications with SMTP server during email send

For this, you will need to configure TCPTrace to listen on port 25 and redirect the traffic to the SMTP server, to the same port. After that, use the name of the computer as the SMTP server in the eSpace logic.

Finally

There are several variants you can create to this, for diverse troubleshooting purposes. You can also associate TCPTrace with STunnel to sniff on HTTPS traffic, in case you are having problems troubleshooting communcations that can only be made in a secure channel. More on the subject later on.

Before using any of these procedures, note that you might be able to capture confidential information (usernames / password, ...) and that you must be authorized to do so.

Feel free to comment or correct whatever is said above!