Traffic Generation

[KumarS]

It does seem like a bug though because the original design intent was to start Ixia session using environment variables defined by the user and only if the session cannot be started, look at standard places where the user may have installed Ixia software. We will try to repeat this here and see if something can be done about this behaviour.

[DougC]

ixTclHal.dll:

Directories defined in your PATH environment variable are searched for this DLL. If it's not found, then the DLL from the latest installed version of IxOS (highest version number) is used. iTest determines what versions you have installed by consulting the Windows registry.

ixTclHal.tcl

This was found because you specified "C:/Program Files/Ixia/IxOS/5.20-GA-Patch1/TclScripts/lib/ixTcl1.0" in "Path to Tcl library".

ScriptGen:

Your session loaded the ScriptGen lib found under the latest installed version of IxOS (5.30). The session will find the desired version (5.20) if you add an additional entry, on a new line, in the "Path to Tcl library", e.g.:

C:/Program Files/Ixia/IxOS/5.20-GA-Patch1/TclScripts/lib

[bgessaro]

Excellent - this explains a lot.  The question now:  I can explicitly override the Environment Variables for ixTclHal.tcl and ScriptGen within the session profile (or step properties), can I explicitly override the PATH environment variable in the session profile (or step properties) for ixTclHal.dll?  Or is this the only IxOS value that iTest needs that must be defined only in the Environment Variable PATH?  In the scenario listed in previous posts to this thread, this behavior would prevent me from specifying an older version of IxOS at iTest runtime, overriding the PATH Environment Variable.

[KumarS]

iTest only checks if ixTclHal.dll is in the PATH. Actually, it does not care at all about this file. Only Ixia Tcl libraries care about this dll being in path. iTest will call:

package require IxTclHal

and the tcl code written by ixia will try to load ixTclHal.dll based on the PATH. I do not know if Ixia's code is intelligent enough to load ixTclHal.dll from the location where the corresponding tcl package is being sourced. My guess is probably "no". But you can give that a try. If the answer is "no", then you will need to run two different instances of iTest started from two different shells with PATH appropriately set. The same will be true for iTestRT.

We can add a feature to iTest where one can also specify the PATH variable to be set for the Tcl shell which iTest launches. That will solve the problem of using a single instance of iTest to target different Ixia versions.

[bgessaro]

Adding a feature to iTest to explicitly define where icTclHal.dll lives would be very helpful in our implementation of iTest (maybe iTest 4.1?  :)  In the mean time, we will continue with our process of ensuring all IXIAs in the automated test environment are at the same revision and not try to override the Environment Variables during test case execution.

Thanks!

[jianguo72]

If itest just care about the filename of ixhal.dll not the location. Can we rename it before call itest session? after calling, and then move it back?

In our script, just add two more steps.

Just a idea, I did not try it yet.