tcpreplay has a facility to remap IP address in a capfile.
The format for that arg is so:
-N 192.168.0.1/32:1.0.0.1/32,192.168.0.100/32:2.0.0.1/32

When I try to pass that via exec:
       my @args =
         ("$tcpreplay", "-p", "$pps",
          "-i",  "$eth",
          "-N", "$src_ip/32:$src,$dest_ip/32:$dst",
          "$capfile,
          "2>&1");

       exec (@args) or die "cannot exec tcpreplay: $!\n";

It ends up that the colon and comma are treated, I believe, as shell
escapes, and so are turned into whitespace separating the arg for the
-N flag. A ps shows this:

/usr/sbin/tcpreplay -p 1 -i eth2 -N 192.168.0.6/32 1.0.0.1/32
192.168.0.2/32 2.0.0.1/32 data.cap 2>&1

I am unable to get around the issue of the colon and comma being
rendered to spaces.

I get the same result wether using backticks, system or exec. I've
tried using the indirect object approach

exec { $args[0] } @args;

- same result.

Any suggestions very much appreciated.
- bill

Bill Babcock wrote:

> tcpreplay has a facility to remap IP address in a capfile.
> The format for that arg is so:
> -N 192.168.0.1/32:1.0.0.1/32,192.168.0.100/32:2.0.0.1/32
> 
> When I try to pass that via exec:
>        my @args =
>          ("$tcpreplay", "-p", "$pps",
>           "-i",  "$eth",
>           "-N", "$src_ip/32:$src,$dest_ip/32:$dst",
>           "$capfile,
>           "2>&1");
> 
>        exec (@args) or die "cannot exec tcpreplay: $!\n";
>

That code will not compile.  What does your code actually look like?

> It ends up that the colon and comma are treated, I believe, as shell
> escapes, and so are turned into whitespace separating the arg for the
> -N flag.

This should not be the case.  Using the LIST form of exec there is no 
shell involvement thus : and , should not be treated as shell 
metacharacters.  Nor for that matter would the "2>&1" be treated as a 
shell redirection.

> A ps shows this:
> 
> /usr/sbin/tcpreplay -p 1 -i eth2 -N 192.168.0.6/32 1.0.0.1/32
> 192.168.0.2/32 2.0.0.1/32 data.cap 2>&1
> 
> I am unable to get around the issue of the colon and comma being
> rendered to spaces.

Any if you issue the command from the command line by hand, does the 
same happen?  It is possible the program tcpreplay is altering its 
paramters.

Bill Babcock wrote:

> When I try to pass that via exec:
>        my @args =
>          ("$tcpreplay", "-p", "$pps",
>           "-i",  "$eth",
>           "-N", "$src_ip/32:$src,$dest_ip/32:$dst",
>           "$capfile,
>           "2>&1");
> 
>        exec (@args) or die "cannot exec tcpreplay: $!\n";

Whenever you're planing to use "2>&1" or other /bin/sh syntax,
you need to pass a single string, not a list of strings.

What happens when you do it as one string?

   $cmd = "$tcpreplay -p $pps -i $eth -N $src_ip/32:$src,$dest_ip/32:$dst 
$capfile 2>&1";
   print "About to execute '$cmd'\n";	# Verify argument string
   system "echo $cmd";			# Verify what /bin/sh sees
   exec $cmd;

	-Joe