Re: netcat missing example (is this even possible?)

[David Burrows <snadge () gmail com>]

On Thu, Jun 3, 2010 at 2:38 AM, David Fifield <david () bamsoftware com> wrote:

> On Wed, Jun 02, 2010 at 03:44:43PM +1000, David Burrows wrote:
> > Hi (response below),
> >
> > On Wed, Jun 2, 2010 at 9:43 AM, David Fifield <david () bamsoftware com>
> wrote:
> > > On Wed, Jun 02, 2010 at 03:42:53AM +1000, David Burrows wrote:
> > > > Hello again!
> > > >
> > > > Sorry to reply to my own post so soon, but it appears that I have
> found a
> > > > solution that could save someone the trouble of what I just went
> though.
> > > > (on server)
> > > > socat /dev/urandom TCP4-LISTEN:9999
> > > > (on client - substitute localhost for the servers ip if not
> localhost)
> > > > socat TCP4:localhost:9999 PTY,link=/dev/newrandom,raw,echo=0
> > > >
> > > > The server socat command can be substituted with: ncat -l -k 9999 -c
> 'cat
> > > > /dev/urandom'
> > > > I'm not sure if there would be a netcat equivalent of the client
> > > connection.
> > > > Now you can "dd bs=nnn count=1 /dev/newrandom of=/dev/null" and cat,
> etc
> > > all
> > > > works as expected with the newly cloned device.
> > >
> > > Ncat doesn't have code to create a pty. You could probably do it with a
> > > fifo:
> > >
> > > $ ncat -l -k 9999 --sh-exec "cat /dev/urandom"
> > > $ mkfifo /dev/newrandom
> > > $ ncat localhost 9999 > /dev/newrandom
> >
> > Ok this works as expected, except when a test dd process closes the
> > /dev/newrandom fifo, the second ncat exits with the error "Broken pipe".
>
> I see that too. I don't have a good solution for you, but as a dumb
> workaround you can use a SIGPIPE-ignoring Perl buffer like this.
>
> $ ncat localhost 9999 | perl -e 'use
> bytes;$SIG{PIPE}="IGNORE";while(sysread(STDIN,$_,1024)){syswrite(STDOUT,$_);}'
> > /dev/newrandom

I tried this, and it kind of works, except that perl continuously reads from
tcp and writes into the fifo, even when nothing is reading from the fifo as
was evidenced by my cpu usage and network activity meter.  So this results
in heavy system utilisation which is not desirable.

My next thoughts were to try and make ncat ignore the SIGPIPE when its
running in connect mode (as well as it already does in listen mode).  This
would lead to a better performing solution than the above.  However I'm
unsure as to where the best place to put the Signal call is?

Regards,

David B.


> You might want to double-check that two processes reading from
> /dev/newrandom simultaneously will get different random bytes; I'm not
> sure that's the case.
>
> David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/