[Toybox] netcat -f bug

[Yi-Yo Chiang]

On Thu, May 16, 2024 at 1:12 AM enh <enh at google.com> wrote:

> On Sat, May 11, 2024 at 3:12 AM Yi-Yo Chiang via Toybox
> <toybox at lists.landley.net> wrote:
> >
> >
> >
> > 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.
>
> you know there's a _microcom_ though, right? (there's even a symlink
> in /system/bin.)
>

Regretfully no... not until now. Just tried it and I think it perfectly
suits my need =)


>
> > 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
> >
> > _______________________________________________
> > Toybox mailing list
> > Toybox at lists.landley.net
> > http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20240516/d904acde/attachment.htm>