The project OpenWRT, an open source router OS, needs a web console terminal, is xterm.js a good fit ?

[shodanx2]

Hi,

So, OpenWRT is a linux version for your wifi internet router.
It currently has a web interface to do most things but since that's linux, a lot of the time you need to type in console commands.

Figuring out how to do that for regular people is of course very difficult and most just give up and buy another router that does the thing they need out of the box.

So, I think what OpenWRT really needs is a tty console terminal that you can run bash into and type commands that will execute on the router itself.

It needs to be -extremely- small, the entire operating system is less than 8 megabytes.

So, I'm curious to ask, is xterm.js a good fit for this purpose ?
Do people use xterm to type console commands into their linux computer from a browser ? Is that what it is for ?

[jerch]

Yes, it can give you a TTY console via a PTY bridge in the browser. Whether it is a good idea to use it for openWRT depends on a few constraints:

• needed tech stack vs. 8MB distro size:

  • PTY bridge, capable to move IO chunks into HTTP realms
  • HTTP server
  • xterm.js bundles (with several addons)

  Maybe ttyd is a good starting point, which bundles all the needed things into a quite small binary (~1.3MB). If you already serve your current webinterface via a small C HTTP server, you can prolly hook the PTY lifecycling directly into that to get it even smaller. If you are not interested in fast IO and small latency, you can also dump the websocket in favor of good old long polling, which makes state handling somewhat easier and gives you some more security features on browser side (you'd have to implement auth mechs yourself with websockets).
  Note that most server side integrations use high level frameworks in NodeJS, Python or Java, which is prolly not a viable goal for you due to the size constraint of staying below 8MB. So beside cheating with ttyd sources you are on your own here get things into a very small C binding (or C++ or rust, whatever you prefer).

• exposed env:
  Giving full shell access to the system, which delivers the HTTP terminal with xterm.js has a big drawback - ppl can easily kill the terminal connection by accident locking themselves out. Most server side integrations therefore use some sort of virtualization or chroot tricks to avoid access to components a user should not mess with.

• network topology:
  Changing router settings might screw up HTTP terminal connection, since it needs a working network transport in the first place (again lock out by accident). You already might have dealt with that issue for your current web interface (some sort of service ports?), the issue applies here as well.

• security aspects:
  Thats abit challenging to get right with xterm.js (also see https://xtermjs.org/docs/guides/security/). You def. gonna need proper TLS capabilities on the HTTP connection, ideally with some strong AUTH and strong origin policy (or explicit CORS). If you use websockets for IO transport, the websocket connection needs further care at the AUTH and origin part.