[Toybox] netcat -f bug

[enh]

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.)

> 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