[Toybox] toybox host command

Thu Dec 27 10:46:29 PST 2018

Thank you for looking into it. I am as perplexed as you.
Happy New Year!

Jeff

________________________________
From: Rob Landley <rob at landley.net>
Sent: Friday, December 21, 2018 9:26 PM
To: J Martin; toybox at lists.landley.net
Subject: Re: [Toybox] toybox host command

On 12/20/18 5:11 PM, J Martin wrote:
> Hello,
> I was wondering if the host command is functional?

It's in pending, so it's not fully reviewed and cleaned up, but it seems to work
when I tried it?

  $ ./host landley.net
  landley.net has address 208.113.171.142

> I have had no success in
> getting it to run on Windows 10 under Mobaxterm 11.
>
> It just returns with no output.

Window Subsystem for Linux is basically an inverted version of Wine:

  https://en.wikipedia.org/wiki/Wine_(software)

As with QEMU's application emulation, it intercepts and translates system calls,
and doesn't necessarily implement all of them.

(Or are you using cygwin? Or mingw? Or midipix?)

> /etc/resolv.conf is valid and has correct info.
> Thanks for any input!
> Jeff

Toybox isn't reading /etc/resolv.conf, it's #including <resolv.h> and having
libc do stuff for it.

> this is from strace:
> <snip>
>    49  132541 [main] toybox 12836 fcntl64: 0 = fcntl(3, 2, 0x1)
>    67  132608 [main] toybox 12836 fhandler_socket::bind: 0 =
> setsockopt(SO_EXCLUSIVEADDRUSE), Win32 error 0
>   143  132751 [main] toybox 12836 cygwin_bind: 0 = bind(3, 0x64BF4C, 16)

You're using cygwin.

I don't have a windows machine. I've never written a windows program. (I went
from a Atari 800 to C64 to Amiga to Dos to Desqview to OS/2 to Linux, wih
divergences into Solaris and AIX and a little bit of ancient MacOS, 6 months on
JavaOS, a couple horrible mainframe things, bare metal embedded things...)

I'm mostly familiar with Cygwin because EMX had a similar translation layer for
OS/2 (and years later I worked with somebody at TimeSys who maintained a chunk
of a cygwin fork), but lemme see if I can figure anything out here...

>    52  132803 [main] toybox 12836 getpid: 12836 = getpid()
>    72  132875 [main] toybox 12836 __set_errno: void __set_winsock_errno(const
> char*, int):224 setting errno 11
>    51  132926 [main] toybox 12836 __set_winsock_errno: recv_internal:1613 -
> winsock error 10035 -> errno 11
>    52  132978 [main] toybox 12836 cygwin_recvfrom: -1 = recvfrom(3, 0x64C6C0,
> 512, 0x0, 0x0, 0x0), errno 11

Hmmm... 11 is EAGAIN, which is just weird. (Is errno-base.h stable across
architectures?)

>   294  133272 [main] toybox 12836 cygwin_sendto: 27 = sendto(3, 0x64C5A8, 27,
> 0x0, 0x612A4F00, 16)
>    55  133327 [main] toybox 12836 pselect: pselect (4, 0x64BF3C, 0x0, 0x0,
> 0x64BED8, 0x0)
>    51  133378 [main] toybox 12836 pselect: to->tv_sec 5, to->tv_nsec 0, us 5000000
>    92  133470 [main] toybox 12836 dtable::select_read:  fd 3
>    45  133515 [main] toybox 12836 select: sel.always_ready 0
>   172  133687 [main] toybox 12836 start_thread_socket: stuff_start 0x64BCC4
> --- Process 12836 thread 9800 created
> --- Process 12836, exception 406d1388 at 76A34172

Toybox isn't threaded, I have no _clue_ what's going on here.

>  2102  135789 [socksel] toybox 12836 cygthread::stub: thread 'socksel', id
> 0x2648, stack_ptr 0x4FFCD60
>    56  135845 [socksel] toybox 12836 thread_socket: stuff_start 0x64BCC4,
> timeout 4294967295
>    56  135901 [main] toybox 12836 select_stuff::wait: m 4, us 5000000,
> wmfo_timeout -1
>    93  135994 [socksel] toybox 12836 peek_socket: read_ready: 1, write_ready: 0,
> except_ready: 0
>    51  136045 [socksel] toybox 12836 thread_socket: leaving thread_socket
>    99  136144 [main] toybox 12836 select_stuff::wait: wait_ret 2, m = 4.  verifying
>    52  136196 [main] toybox 12836 select_stuff::wait: res after verify 0
>    89  136285 [main] toybox 12836 select_stuff::wait: returning 0

select_stuff?

>    45  136330 [main] toybox 12836 select: sel.wait returns 0
>    54  136384 [main] toybox 12836 peek_socket: read_ready: 1, write_ready: 0,
> except_ready: 0
>    53  136437 [main] toybox 12836 set_bits: me 0x20061AE0, testing fd 3 ()
>    52  136489 [main] toybox 12836 set_bits: ready 1
>    88  136577 [main] toybox 12836 select_stuff::cleanup: calling cleanup routines
>    44  136621 [main] toybox 12836 socket_cleanup: si 0x20061B10 si->thread
> 0x611CE950
>   181  136802 [main] toybox 12836 socket_cleanup: returning
>    48  136850 [main] toybox 12836 select_stuff::destroy: deleting select records
>    90  136940 [main] toybox 12836 select_stuff::cleanup: calling cleanup routines
>    46  136986 [main] toybox 12836 select_stuff::destroy: deleting select records
>    47  137033 [main] toybox 12836 pselect: 1 = select (4, 0x64BF3C, 0x0, 0x0,
> 0x64BED8)
>   111  137144 [main] toybox 12836 cygwin_recvfrom: 27 = recvfrom(3, 0x64C6C0,
> 512, 0x0, 0x64BF5C, 0x64BF38)
>   401  137545 [main] toybox 12836 fhandler_pty_slave::write: pty0,
> write(0x432E3C, 4)
>    49  137594 [main] toybox 12836 fhandler_pty_common::process_opost_output:
> (1902): pty output_mutex (0x1CC): waiting -1 ms
>    51  137645 [main] toybox 12836 fhandler_pty_common::process_opost_output:
> (1902): pty output_mutex: acquired
>    53  137698 [main] toybox 12836 fhandler_pty_common::process_opost_output:
> (1941): pty output_mutex(0x1CC) released

Locking for a pseudo-terminal handler? How is a PTY involved here?

> host   55  137753 [main] toybox 12836 write: 4 = write(2, 0x432E3C, 4)
>   111  137864 [main] toybox 12836 fhandler_pty_slave::write: pty0,
> write(0x43260F, 2)
>    74  137938 [main] toybox 12836 fhandler_pty_common::process_opost_output:
> (1902): pty output_mutex (0x1CC): waiting -1 ms
>    46  137984 [main] toybox 12836 fhandler_pty_common::process_opost_output:
> (1902): pty output_mutex: acquired
>    69  138053 [main] toybox 12836 fhandler_pty_common::process_opost_output:
> (1941): pty output_mutex(0x1CC) released
> :    49  138102 [main] toybox 12836 write: 2 = write(2, 0x43260F, 2)
>   218  138320 [main] toybox 12836 fhandler_pty_slave::write: pty0,
> write(0x4342DE, 15)
>    42  138362 [main] toybox 12836 fhandler_pty_common::process_opost_output:
> (1902): pty output_mutex (0x1CC): waiting -1 ms
>    49  138411 [main] toybox 12836 fhandler_pty_common::process_opost_output:
> (1902): pty output_mutex: acquired
>    52  138463 [main] toybox 12836 fhandler_pty_common::process_opost_output:
> (1941): pty output_mutex(0x1CC) released
> Host not found.   45  138508 [main] toybox 12836 write: 15 = write(2, 0x4342DE, 15)
>   307  138815 [main] toybox 12836 fhandler_pty_slave::write: pty0,
> write(0x611CBDF7, 1)
>    45  138860 [main] toybox 12836 fhandler_pty_common::process_opost_output:
> (1902): pty output_mutex (0x1CC): waiting -1 ms
>    48  138908 [main] toybox 12836 fhandler_pty_common::process_opost_output:
> (1902): pty output_mutex: acquired
>    54  138962 [main] toybox 12836 fhandler_pty_common::process_opost_output:
> (1941): pty output_mutex(0x1CC) released
>
>    47  139009 [main] toybox 12836 write: 1 = write(2, 0x611CBDF7, 1)
>  1041  140050 [main] toybox 12836 do_exit: do_exit (256), exit_state 1

What just exited?

>    46  140096 [main] toybox 12836 void: 0x0 = signal (20, 0x1)
>    51  140147 [main] toybox 12836 void: 0x0 = signal (1, 0x1)
>    47  140194 [main] toybox 12836 void: 0x0 = signal (2, 0x1)
>    46  140240 [main] toybox 12836 void: 0x0 = signal (3, 0x1)

It's setting signal handlers?

  $ strace ./host landley.net 2>&1 | grep signal
  $

Nothing...

Sorry, I have no idea what's going on here. I kind of doubt toybox is
responsible for any of this.

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