[Toybox] netcat -f bug

[Yi-Yo Chiang]

On Sat, May 11, 2024 at 1:30 AM Rob Landley <rob at landley.net> wrote:

> What's your use case triggering this patch? Because without that, I go off
> on
> various design tangents, as seen below:
>

I just wanted some tool to communicate with a pty or socket node on android.
Wanted a program to be able to send/recv towards a duplex data stream.
(more precisely I want a command that does exactly what pollinate() does)
Since socat nor minicom is available on Android, I'm just using `stty raw
-echo && nc -f` to "talk" to my pty.

Why didn't I use <> redirector? Because I wasn't aware of that feature
before reading this mail...
Let me fiddle with it a bit:

cat <>/dev/pts/0
> Shows the pts output, but my input doesn't get passed back
cat <>/dev/pts/0 >&0 2>&0
> Shows nothing on my terminal. All the output of the pts node got uno
reversed back to it. The ptm side just sees all their data got echoed back.

Seems <> doesn't sate my need, or I'm still using it wrong?
Anyway actually what I need could just be as simple as starting 2 cat
processes as bidirection data stream. Though this wouldn't be a true
duplex...

cat /dev/pts/0 & stty raw isig -echo && cat >/dev/pts/0
> This actually works and behave similarly enough to `stty raw -echo && nc
-f` for me.

(but it's still much more convenient if I can do all that (double `cat` and
background process handling) with a single shorter `nc -f` command)


>
> On 5/10/24 06:09, Yi-Yo Chiang via Toybox wrote:
> > Hi,
> > The -f option for netcat doesn't seem to be doing anything right now.
>
> I should have a test for that, but to be honest I came up with netcat -f
> back in
> busybox (commit 1cca9484db69 says 2006) before I knew about bash's <>
> redirector
> to open a file for both reading _and_ writing (or had bash not added it
> yet?),
> meaning the example in that commit probably _should_ have been stty 115200
> -F
> /dev/ttyS0 && stty raw -echo -ctlecho && cat <>/dev/ttyS0 >&0 2>&0
>
> (I should NOT ask Chet for "{0-2}<>/dev/ttyS0" syntax operating on a
> filehandle
> range. I should not do it. That would be... I dunno, rude? I mean in
> theory I'd
> just want him to fix the existing {1..2} syntax to do one open() and then
> dup()
> redirects instead of opening the device multiple times, which was the
> initial
> problem because reopening the /dev node instead of dup() an existing
> filehandle
> to it either gave -EBUSY or hardware reset the UART depending on the
> underlying
> driver, and the reason chet would give me a LOOK if I asked is
> {brace,expansion}
> is resolved _before_ variable expansion and redirection, so it literally
> turns
> INTO 3 arguments with different numbers and thus three separate open()
> calls to
> the char device, and making it do something else is basically a layering
> violation...)
>
> Ahem. Sorry. Tangent.
>
> It's possible netcat -ft makes it still useful, but A) that implies there
> should
> be some sort of tty wrapper in the nice/taskset/time/chroot/nohup mold, B)
> I
> think -t is currently broken because I needed to rewrite it to add nommu
> support
> (decompose forkpty() into the underlying openpty() and login_tty() calls
> around
> the vfork() instead of fork()) and just commented it out and put it on the
> todo
> list...
>
> The original theory was -f should fall through to the "else" case on line
> 191,
> and thus naturally inherit any other applicable options. Which is hard to
> see in
> my current tree because with a bunch of half-finished work in it:
>
> $ git diff toys/*/netcat.c | diffstat
>  netcat.c |   62
> +++++++++++++++++++++++++++++++++++++++++++++++++-------------
>  1 file changed, 49 insertions(+), 13 deletions(-)
>
> Sorry for falling behind...
>
> > It is
> > missing a call to pollinate() after opening the specified device file.
> > The patch adds back that line of pollinate().
>
> Which makes it not work with running commands (ala -f should work like -l).
>

yeah like you said it should had fall through and be like -l.
However digging the git history the fall through line got removed here
https://github.com/landley/toybox/commit/67bf48c1cb3ed55249c27e6f02f5c938b20e027d
which is unintentional I think?


>
> > Also make sure that the timeout handler is not armed for -f mode as -f
> shouldn't
> > timeout. File open() should just succeed or fail immediately.
>
> Why shouldn't -f timeout? Various /dev nodes take a while to open,
> automount
> behind the scenes... Is there a downside to leaving that part as is?
> (Other than
> the new case you added not alarm(0) disarming it?)
>

I was wrong. What you pointed out is correct. Reading `man open` again it
also clearly says that opening a fifo could block until the other end is
open-ed also.
Please ignore my claim about moving the signal handler lines. Yes I think
after open() succeeded then alarm(0) to disarm is good.



>
> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20240511/a56701ea/attachment-0001.htm>