[Leon Tieleman]

Maybe your issue has something to do with the migration issue explained on page 68 of the release notes:

Issue: hcihrlconvert

Description: hcihrlconvert is used to add the {ACTIVENULLWHENNOCONTENT 1} key into any VRL/FRL segment in an HRL file.

Usage

hcihrlconvert [hrl …]

Where: hrl is the HRL file to convert. Specifying no argument converts all HRL files under the site.

The ACTIVENULLWHENNOCONTENT key is used to change the parsing and encoding behavior on a empty VRL/FRL segment in an HRL file.

In versions earlier than 6.1, the behavior was to set the empty VRL/FRL segment as ActiveNull.

In versions 6.1 and later, the default behavior is to fill padding characters for empty VRL/FRL segments.

For example, if you have an xlate file which uses Repeat While on an empty VRL/FRL segment in a HRL, set ACTIVENULLWHENNOCONTENT to 1 for the VRL/FRL segment in the HRL. This is set through the GUI (by selecting Active Null) or by using hcihrlconvert on the command line.

If you have no requirement to use HRL in this way, then do not select Active Null on the GUI. This makes the engine use the new behavior.

[Leon Tieleman]

This is one of the most annoying problems we have at our customers at the moment.

We reported it to support several times. R&D fixed something in 5.7 rev2 and 5.8.0.0 but it look like it was a specific fix for only one specific PDL error and not for all the errors. It is still occurring in 5.7 Rev2 and higher. I still hope there is a chance this will be fixed for all the different types of errors soon.

Release notes 5.7 Rev2

Quote:

9.1.3         PDL error fills up the disk space in the VPN environment (6248)

Errors occur when using TCP-MLP through VPN. The same error echo in the process log until the process panic because the logs filled up the disk.

For example:

[pdl :PDL :ERR /0: bno31bb_out:01/27/2009 17:04:44] read returned error 0 (Success)

When this error occurs, the thread stays in an UP status because there was not a graceful shutdown from the VPN.

This error no longer occurs. A sleep interval has been added for retrying the connection, and the engine will now detect if there is an error and put the thread in error state.

Release notes 5.8.0.0

Quote:

6.4         PDL error fills up the disk space in VPN environment (5742)

An issue has been reported with using TCP-MLP thru VPN and getting errors. The same error echoes in the process log until the process panics because the logs fill up the disk.

When this error occurs, the thread stays in an UP status because there is not a graceful shutdown from the VPN.

This error no longer occurs. Now, a sleep interval retries the connection. The engine will now detect there is an error and put the thread in an error state.

Some examples of errors:

Code:

[pdl :PDL :ERR /0:alert_acc_ADT_out:05/11/2011 11:13:32] write of 636 bytes failed: Unknown error
[pdl :PDL :ERR /0:alert_acc_ADT_out:05/11/2011 11:13:32] PDL signaled exception: code 1, msg write failure
…..
[pdl :PDL :ERR /0: star:02/09/2009 11:18:02] read returned error 110 (Connection timed out)
…..
[pdl :PDL :ERR /0:  PatTerm_ADT:09/03/2009 05:33:16] read failed: Connection timed out
[pdl :PDL :ERR /0:  PatTerm_ADT:09/03/2009 05:33:16] read returned error 34 (Numerical result out of

[Leon Tieleman]

We also had this problem in 5.8 in every situation with a firewall / VPN involved.

I found out the Cloverleaf 5.8 Host Server tries to connect to a port on the Client when opening a Network Monitor or Network Configurator. Our problem was that the firewall blocked the traffic from the Host Server to the port opened on the Client. In the example below the problem was caused by port 2513.

Host Server

Code:

-bash-3.2$ netstat -an | grep 10.13.113.180
tcp   0   52 ::ffff:10.125.0.2:32     ::ffff:10.13.113.180:2494   ESTABLISHED
tcp   0   0 ::ffff:10.125.0.2:13019   ::ffff:10.13.113.180:2510   ESTABLISHED
tcp   0   0 ::ffff:10.125.0.2:14019   ::ffff:10.13.113.180:2511   ESTABLISHED
tcp   0   0 ::ffff:10.125.0.2:14019   ::ffff:10.13.113.180:2512   ESTABLISHED
tcp   0   1 ::ffff:10.125.0.2:41537   ::ffff:10.13.113.180:2513   SYN_SENT

Client

Code:

C:Documents and Settingsleont>netstat -an | grep 10.125.0.2
TCP    10.13.113.180:2494     10.125.0.2:32          ESTABLISHED
TCP    10.13.113.180:2510     10.125.0.2:13019       ESTABLISHED
TCP    10.13.113.180:2511     10.125.0.2:14019       ESTABLISHED
TCP    10.13.113.180:2512     10.125.0.2:14019       ESTABLISHED

C:Documents and Settingsleont>netstat -an | grep 2513
TCP    0.0.0.0:2513         0.0.0.0:0           LISTENING

[Author]

Replies