tessel / t2-cli

Tessel 2 Command Line Interface
MIT License
114 stars 56 forks source link

Proposal: `t2 root --serial` or `t2 serial` #988

Open tcr opened 8 years ago

tcr commented 8 years ago

I wrote this module: https://github.com/tcr/t2-serial It lets you jump into the serial port shell on Tessel 2 + also see boot logs from Linux.

This was necessary because we currently don't show up as a COM port on Windows, so the serial port is unusable from minicom, etc. But we can do it through libusb quite easily in spite of that limitation.

This is a good addition for when t2 root requires a network connection to work. However: it is also worthwhile to get t2 root to support SSH'ing over the USB connection itself. If that were supported, then the utility of having the serial support in t2-cli directly is diminished.

Wanted to open this up to feature discussion.

rwaldron commented 8 years ago

We'd want to branch here: https://github.com/tessel/t2-cli/blob/master/lib/controller.js#L818-L819 my guess is by checking for the absense of a LAN connection

tcr commented 8 years ago

This is different than an SSH connection (i.e. exit doesn't work, it doesn't require provisioning, it dumps the Linux logs in your stream). I mentioned to @johnnyman727 I did not think this was strictly the --usb implementation, since --usb would be SSH over domain socket. Should we go about adding a third connection, t2 root --serial (in addition to usb and lan), or should this be a separate command entirely (t2 serial)?

rwaldron commented 8 years ago

Yes, I know—that's why I said you'd need to branch at that point. One path is the serial connection, the other is the ssh connection.

I mentioned to @johnnyman727 I did not think this was strictly the --usb implementation, since --usb would be SSH over domain socket.

I'm not sure I understand what you're saying here, but I think my spitball about the LAN connection was just the wrong thing to key on and that might've caused confusion...? I guess you'd just branch on:

  // Fetch a Tessel
  return controller.standardTesselCommand(opts, tessel => {
    if (opts.serial) {
      log.info('Starting Serial Session on Tessel.');

      return new Promise((resolve, reject) => {
        // The new code goes here. 
      });
    } else {
      log.info('Starting SSH Session on Tessel. Type "exit" at the prompt to end.');
      return new Promise((resolve, reject) => {
        // Spawn a new SSH process
        var child = cp.spawn('ssh', ['-i',
          // Use the provided key path
          Tessel.LOCAL_AUTH_KEY,
          // Connect to the Tessel's IP Address
          'root@' + tessel.lanConnection.ip
        ], {
          // Pipe our standard streams to the console
          stdio: 'inherit'
        });

        log.spinner.stop();

        // Report any errors on connection
        child.once('error', err => {
          return reject('Failed to start SSH session: ' + err.toString());
        });

        // Close the process when we no longer can communicate with the process
        child.once('close', resolve);
        child.once('disconnect', resolve);
      });
    }
  });
tcr commented 8 years ago

@rwaldron Yup, I misread. On the same page now. Hopefully my exposition is helpful anyway for anyone wondering what makes this different from t2 root.

dbuentello commented 8 years ago

FWIW, The serial set up logic also helps t2 logs --boot proposal. After reading your code, Im thinking that node-serialport might be overkill.

tcr commented 8 years ago

@dbuentello Not only that, but it's possible that on Windows you wouldn't even recognize it as a serial port. Using libusb directly will work cross-platform in either case :)

rwaldron commented 8 years ago

I'm going to investigate moving this forward