tcpdump + IFS = no sense?

tcpdump + IFS = no sense?

Post by tony.andre.. » Thu, 31 Aug 2006 00:49:46



Ok, perhaps one of the experts here can help.  I'm just trying to write
a small script that will start a tcpdump.  The dump will be started
with a variable for tcpdump's parameters.  This works fine:

cmd="-i eth0"
tcpdump $cmd

BUT, if I then add an IFS command before it (to eventually allow me to
read the parameters from a config file) it doesn't work.  This fails:

IFS="
"
cmd="-i eth0"
tcpdump $cmd

with a "tcpdump: ioctl: No such device"

I've tried it with Redhat EL3 and FC5 with the same results.  Can
someone explain what the heck's going on?

Thanks!
Tony

 
 
 

tcpdump + IFS = no sense?

Post by Dale Dellutr » Thu, 31 Aug 2006 01:00:41



Quote:> Ok, perhaps one of the experts here can help.  I'm just trying to write
> a small script that will start a tcpdump.  The dump will be started
> with a variable for tcpdump's parameters.  This works fine:
> cmd="-i eth0"
> tcpdump $cmd
> BUT, if I then add an IFS command before it (to eventually allow me to
> read the parameters from a config file) it doesn't work.  This fails:
> IFS="
> "
> cmd="-i eth0"
> tcpdump $cmd
> with a "tcpdump: ioctl: No such device"
> I've tried it with Redhat EL3 and FC5 with the same results.  Can
> someone explain what the heck's going on?

bash can't parse the command string properly because you changed the
field separator.  What are you setting IFS to?

$IFS
    internal field separator
    This variable determines how Bash recognizes fields, or word
boundaries when it interprets character strings.
    $IFS defaults to whitespace (space, tab, and newline), but may be
changed, for example, to parse a comma-separated data file. Note that
$* uses the first character held in $IFS. See Example 5-1.

--


 
 
 

tcpdump + IFS = no sense?

Post by tony.andre.. » Thu, 31 Aug 2006 02:09:10


I'm setting it to a carriage return:

IFS="
"

As I've done a million times before.  The result is the ability to read
a text file one line at a time rather than one word at a time.  That
functionality still works fine, it's just that tcpdump is *.



> > Ok, perhaps one of the experts here can help.  I'm just trying to write
> > a small script that will start a tcpdump.  The dump will be started
> > with a variable for tcpdump's parameters.  This works fine:

> > cmd="-i eth0"
> > tcpdump $cmd

> > BUT, if I then add an IFS command before it (to eventually allow me to
> > read the parameters from a config file) it doesn't work.  This fails:

> > IFS="
> > "
> > cmd="-i eth0"
> > tcpdump $cmd

> > with a "tcpdump: ioctl: No such device"
> > I've tried it with Redhat EL3 and FC5 with the same results.  Can
> > someone explain what the heck's going on?

> bash can't parse the command string properly because you changed the
> field separator.  What are you setting IFS to?

> $IFS
>     internal field separator
>     This variable determines how Bash recognizes fields, or word
> boundaries when it interprets character strings.
>     $IFS defaults to whitespace (space, tab, and newline), but may be
> changed, for example, to parse a comma-separated data file. Note that
> $* uses the first character held in $IFS. See Example 5-1.

> --


 
 
 

tcpdump + IFS = no sense?

Post by David Schwart » Thu, 31 Aug 2006 12:55:35



> I'm setting it to a carriage return:

> IFS="
> "

> As I've done a million times before.  The result is the ability to read
> a text file one line at a time rather than one word at a time.  That
> functionality still works fine, it's just that tcpdump is *.

With IFS set to just a newline, bash interprets "tcpdump -i eth0" as
"tcpdump" "-i eth0" instead of "tcpdump" "-i" "eth0", which is what it
expects and requires.

DS

 
 
 

tcpdump + IFS = no sense?

Post by tony.andre.. » Thu, 31 Aug 2006 23:27:55


Wierd, I've never experienced this, but putting "eval" in front solved
it.

Thanks!



> > I'm setting it to a carriage return:

> > IFS="
> > "

> > As I've done a million times before.  The result is the ability to read
> > a text file one line at a time rather than one word at a time.  That
> > functionality still works fine, it's just that tcpdump is *.

> With IFS set to just a newline, bash interprets "tcpdump -i eth0" as
> "tcpdump" "-i eth0" instead of "tcpdump" "-i" "eth0", which is what it
> expects and requires.

> DS

 
 
 

tcpdump + IFS = no sense?

Post by tony.andre.. » Thu, 31 Aug 2006 23:28:09


Wierd, I've never experienced this, but putting "eval" in front solved
it.

Thanks.



> > I'm setting it to a carriage return:

> > IFS="
> > "

> > As I've done a million times before.  The result is the ability to read
> > a text file one line at a time rather than one word at a time.  That
> > functionality still works fine, it's just that tcpdump is *.

> With IFS set to just a newline, bash interprets "tcpdump -i eth0" as
> "tcpdump" "-i eth0" instead of "tcpdump" "-i" "eth0", which is what it
> expects and requires.

> DS

 
 
 

1. Deciphering IBM/AIX SCSI Sense data to ANSI SCSI Sense data

[ Article crossposted from comp.periphs.scsi ]
[ Author was Jeff Johnson ]
[ Posted on Tue, 22 Dec 1992 00:06:22 GMT ]

Hello,

        Has anyone been able to decipher a correlation between ANSI Spec SCSI
Extended Sense Data and the Sense Data that is returned by IBM's AIX SCSI
Disk drive Diagnostics Routine?

        The data returned by the AIX diagnostics looks like HEX data but
its in a four digit format instead of typical two digit HEX data that
correlates to the Extended Sense Data Format.

        Below is the data from the AIX SCSI Diagnostics utility. If anyone can
find a key to deciphering it or how the data is grouped I'd appreciate it.
The subject drive is a Seagate Elite 1 ST41600N which conforms to ANSI SCSI-2
and Sense Data Format:

Detail Data
SENSE DATA
0603 0000 0801 F770 2000 0000 0800 0000 0102 0000 F000 0100 01F7 800A 0000 0000
1700 0080 0007 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 075E 0001 1080

If anyone has any ideas on how to read the above data into anything close to
SCSI Request Sense Data I'd really like to hear it.


I'll post the results.

-Jeff Johnson
 Western Scientific

2. XF86_S3V and 2.0.28

3. log sense parameter code does not make sense

4. SLIP for Solaris 2.4

5. "Request sense couldn't get sense data" -- huh?

6. Compilation with floating exceptions

7. Problem with TCPDUMP ( it says : "tcpdump: socket: Invalid argument" ??!!

8. ppp & linuxconf

9. TCPDUMP how to configure bpf0 for tcpdump?

10. Not Available these Signal nos on Linux

11. CD-RW: CDFS? Unstable dev nos?

12. NOS shootout