Interactive mode is unuseable

[melonlm]

Issuing commands in interactive mode results in error loop of

"send error: Socket operation on non-socket"

I tracked it down in the code to the fact that even in interactive mode the program wants to send the responses back using socket_send( ) function, but using file descriptor "1" (STDOUT stream), which causes the socket lib to error out.

OS is Debian, from Stable to Sid, kernels : 6.1 and 6.7, arch amd64 and arm64.

[worikgh]

I came here to report the same issue.

I have mine working now

    // Protocol OK
    if (index >= 0)
      {
        if (g_commands[index].callback)
      {
            g_commands[index].callback(&proto);
            if (proto.response)
          {
        if(msg->sender_id > 3){
          SEND_TO_SENDER(msg->sender_id, proto.response, proto.response_size);
        }else{
          fprintf(stdout, "%s\n", proto.response);
        }
        if (g_verbose) printf("PROTOCOL: response '%s'\n", proto.response);

                FREE(proto.response);
          }
      }
      }
    // Protocol error
    else
      {
    if(msg->sender_id > 3){
      SEND_TO_SENDER(msg->sender_id, g_error_messages[-index-1], strlen(g_error_messages[-index-1]));
    }else{
      fprintf(stdout, "%s\n", g_error_messages[-index-1]);
    }
    if (g_verbose) printf("PROTOCOL: error '%s'\n", g_error_messages[-index-1]);
      }

That is a bit hairy. But I do not think a socket file number can be less than 3, I just cannot find documentation for that.

[melonlm]

Looks like it is a POSIX thing. FDs 0, 1 and 2 are supposed to be standard streams: https://en.wikipedia.org/wiki/File_descriptor So the patch is ok I suppose?

[worikgh]

My workaround is just a workaround

The problem of getting into an infinite loop I have not looked at, yet.

[melonlm]

The infinite loop issue is due to missing return (or break) statement after perror() is called in SEND_TO_SENDER function.

See comments here: https://github.com/moddevices/mod-host/commit/c69480efbc0ecd5a0273a56ba0a42d40dcc723cd

[riban-bw]

Looks like it is a POSIX thing. FDs 0, 1 and 2 are supposed to be standard streams: https://en.wikipedia.org/wiki/File_descriptor

By convention, a shell based / launched application will use file descriptors 0, 1 & 2 for std in, out & err but this does not need to be the case and this behaviour can be changed. One should never assume that the first three file descriptors are used by in/out/err.

I found this issue wieht continual send error messages which seems to be in the code base for a while. I wonder when the last person to use / test interactive mode was?

This is a significant issue. Do we need to submit a PR to fix it?