i am about to use nc + xxd to debug a network process. the process
under test, say process P1, will send/receive binary data
( datagrams ) to/from another process, say process P2, via tcp socket.

so, i have nc act as the P2 as below,
nc -s 127.0.0.1 -l -p 9000 | xxd -g1
by this way i can see what sent from P1. thanks xxd ! but the
problem is, how can i have P1 send some datagrams back to P2? i need
to both directly inject the binary data stream and input some
datagrams in hexadecimal text format ( just as the form in which xxd
outputs ).

i once came out with a solution,
nc -s 127.0.0.1 -l -p 9000 < my.input | xxd -g1\
but it never work since after nc opened the my.input, what i did on
the file will not get know by the nc.

On 7 17 , 4 35 , Steven Woody <narkewo...@gmail.com> wrote:
> i am about to use nc + xxd to debug a network process. the process
> under test, say process P1, will send/receive binary data
> ( datagrams ) to/from another process, say process P2, via tcp socket.
>
> so, i have nc act as the P2 as below,
> nc -s 127.0.0.1 -l -p 9000 | xxd -g1
> by this way i can see what sent from P1. thanks xxd ! but the
> problem is, how can i have P1 send some datagrams back to P2? i need
> to both directly inject the binary data stream and input some
> datagrams in hexadecimal text format ( just as the form in which xxd
> outputs ).
>
> i once came out with a solution,
> nc -s 127.0.0.1 -l -p 9000 < my.input | xxd -g1\
> but it never work since after nc opened the my.input, what i did on
> the file will not get know by the nc.

does anyone understand my problem? thanks.

2007-07-17, 07:48(-07), Steven Woody:
> On 7 17 , 4 35 , Steven Woody <narkewo...@gmail.com> wrote:
>> i am about to use nc + xxd to debug a network process. the process
>> under test, say process P1, will send/receive binary data
>> ( datagrams ) to/from another process, say process P2, via tcp socket.
>>
>> so, i have nc act as the P2 as below,
>> nc -s 127.0.0.1 -l -p 9000 | xxd -g1
>> by this way i can see what sent from P1. thanks xxd ! but the
>> problem is, how can i have P1 send some datagrams back to P2? i need
>> to both directly inject the binary data stream and input some
>> datagrams in hexadecimal text format ( just as the form in which xxd
>> outputs ).
>>
>> i once came out with a solution,
>> nc -s 127.0.0.1 -l -p 9000 < my.input | xxd -g1\
>> but it never work since after nc opened the my.input, what i did on
>> the file will not get know by the nc.
>
> does anyone understand my problem? thanks.

Not really, no.

Didn't you mean above "P2 send some datagrams back to P1" instead?

I'd use perl's Socket module or zsh's ztcp.

You may also consider using expect with TCL's socket(n).

--
Stéphane

On Jul 17, 11:04 pm, Stephane CHAZELAS <this.addr...@is.invalid>
wrote:
> 2007-07-17, 07:48(-07), Steven Woody:
>
>
>
> > On 7 17 , 4 35 , Steven Woody <narkewo...@gmail.com> wrote:
> >> i am about to use nc + xxd to debug a network process. the process
> >> under test, say process P1, will send/receive binary data
> >> ( datagrams ) to/from another process, say process P2, via tcp socket.
>
> >> so, i have nc act as the P2 as below,
> >> nc -s 127.0.0.1 -l -p 9000 | xxd -g1
> >> by this way i can see what sent from P1. thanks xxd ! but the
> >> problem is, how can i have P1 send some datagrams back to P2? i need
> >> to both directly inject the binary data stream and input some
> >> datagrams in hexadecimal text format ( just as the form in which xxd
> >> outputs ).
>
> >> i once came out with a solution,
> >> nc -s 127.0.0.1 -l -p 9000 < my.input | xxd -g1\
> >> but it never work since after nc opened the my.input, what i did on
> >> the file will not get know by the nc.
>
> > does anyone understand my problem? thanks.
>
> Not really, no.
>
> Didn't you mean above "P2 send some datagrams back to P1" instead?

yes. i am sorry for the typo. i actually want to find a way to let
NC send some datagrams back to P1. i guess i should let NC read from a
pipe and i, on the another virtual terminal, can inject some ( via
xxd, maybe ) binary data into the piple. but i dont know how to do
it.

>
> I'd use perl's Socket module or zsh's ztcp.
>
> You may also consider using expect with TCL's socket(n).

i don't know syntax about perl and TCL and it is not prefered to write
a program. thanks.

2007-07-18, 16:56(-07), Steven Woody:
[...]
> yes. i am sorry for the typo. i actually want to find a way to let
> NC send some datagrams back to P1. i guess i should let NC read from a
> pipe and i, on the another virtual terminal, can inject some ( via
> xxd, maybe ) binary data into the piple. but i dont know how to do
> it.

I'm still not sure what exactly you want to do, but if you don't
want to use perl nor tcl, and want to use nc, you'll probably
have to use named pipe.

mkfifo to_nc from_nc
nc ... < to_nc > from_nc &
exec 3> to_nc 4< from_nc

Write anything you want to send to the remote end to fd 3:

printf >&3 ...
xxd -r < hex-input >&3

read what comes from the remote end from fd 4.

reading_cmd <&4

for instance:
dd count=1 <&4 | xxd
to read up to 512 bytes of the output of nc (that will read
however many bytes, up to 512 there are in the pipes at the time
that command is run, and if there aren't, it will wait until nc
does its first write to the pipe, in which case, you'll get the
bytes written by that one write(2) system call (up to 512
bytes).

When you're done, close both fds so nc can close the socket.

exec 3>&-
exec 4<&-

--
Stéphane

On Jul 20, 11:30 pm, Stephane CHAZELAS <this.addr...@is.invalid>
wrote:
> 2007-07-18, 16:56(-07), Steven Woody:
> [...]
>
> > yes. i am sorry for the typo. i actually want to find a way to let
> > NC send some datagrams back to P1. i guess i should let NC read from a
> > pipe and i, on the another virtual terminal, can inject some ( via
> > xxd, maybe ) binary data into the piple. but i dont know how to do
> > it.
>
> I'm still not sure what exactly you want to do, but if you don't
> want to use perl nor tcl, and want to use nc, you'll probably
> have to use named pipe.
>
> mkfifo to_nc from_nc
> nc ... < to_nc > from_nc &
> exec 3> to_nc 4< from_nc
>
> Write anything you want to send to the remote end to fd 3:
>
> printf >&3 ...
> xxd -r < hex-input >&3
>
> read what comes from the remote end from fd 4.
>
> reading_cmd <&4
>
> for instance:
> dd count=1 <&4 | xxd
> to read up to 512 bytes of the output of nc (that will read
> however many bytes, up to 512 there are in the pipes at the time
> that command is run, and if there aren't, it will wait until nc
> does its first write to the pipe, in which case, you'll get the
> bytes written by that one write(2) system call (up to 512
> bytes).
>
> When you're done, close both fds so nc can close the socket.
>
> exec 3>&-
> exec 4<&-
>
> --
> Stéphane

thank you Stephane, i think what you told about named pipes is exactly
what i needed. but i get some problem in trying your examples

1, ' nc -s localhost -p 9000 -l < to_nc > from_nc' seems not work.
there is no error reported but just no client can connected to the
9000 port and 'netstat -na' proved it did not listen.

2, 'exec 3> to_nc 4< from_nc' never return :-(

i am on 2.6 linux.

-
woody

On Jul 21, 12:40 pm, Steven Woody <narkewo...@gmail.com> wrote:
> On Jul 20, 11:30 pm, Stephane CHAZELAS <this.addr...@is.invalid>
> wrote:
>
>
>
> > 2007-07-18, 16:56(-07), Steven Woody:
> > [...]
>
> > > yes. i am sorry for the typo. i actually want to find a way to let
> > > NC send some datagrams back to P1. i guess i should let NC read from a
> > > pipe and i, on the another virtual terminal, can inject some ( via
> > > xxd, maybe ) binary data into the piple. but i dont know how to do
> > > it.
>
> > I'm still not sure what exactly you want to do, but if you don't
> > want to use perl nor tcl, and want to use nc, you'll probably
> > have to use named pipe.
>
> > mkfifo to_nc from_nc
> > nc ... < to_nc > from_nc &
> > exec 3> to_nc 4< from_nc
>
> > Write anything you want to send to the remote end to fd 3:
>
> > printf >&3 ...
> > xxd -r < hex-input >&3
>
> > read what comes from the remote end from fd 4.
>
> > reading_cmd <&4
>
> > for instance:
> > dd count=1 <&4 | xxd
> > to read up to 512 bytes of the output of nc (that will read
> > however many bytes, up to 512 there are in the pipes at the time
> > that command is run, and if there aren't, it will wait until nc
> > does its first write to the pipe, in which case, you'll get the
> > bytes written by that one write(2) system call (up to 512
> > bytes).
>
> > When you're done, close both fds so nc can close the socket.
>
> > exec 3>&-
> > exec 4<&-
>
> > --
> > Stéphane
>
> thank you Stephane, i think what you told about named pipes is exactly
> what i needed. but i get some problem in trying your examples
>
> 1, ' nc -s localhost -p 9000 -l < to_nc > from_nc' seems not work.
> there is no error reported but just no client can connected to the
> 9000 port and 'netstat -na' proved it did not listen.
>
> 2, 'exec 3> to_nc 4< from_nc' never return :-(
>
> i am on 2.6 linux.
>
> -
> woody

at least, does anyone please tell me why 'exec' can not work on named
pipes on Linux? actually, using redirectors on normal files for exec
are okay.

2007-07-22, 16:46(-07), Steven Woody:
[...]
> at least, does anyone please tell me why 'exec' can not work on named
> pipes on Linux? actually, using redirectors on normal files for exec
> are okay.

An open(2) for writing on a named pipe returns when the named
pipe is being open for reading (typically by another process or
thread). Same thing in reverse for reading.

You may have noticed that in my example, I had.

cmd < fifo1 > fifo2 &

Before executing cmd (but after forking), the shell will do a
open(fifo1, read-only). That one will block until something else
opens fifo1 for writing.

I've not doubled check, but I might have had it backwoard in the
example I gave.

Then, you need

exec 3> fifo1 4< fifo2

in that order or else you'll have a deadlock.

--
Stéphane