Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nicer Serial-over-LAN client #138

Open
bluecmd opened this issue Mar 12, 2019 · 3 comments
Open

Nicer Serial-over-LAN client #138

bluecmd opened this issue Mar 12, 2019 · 3 comments

Comments

@bluecmd
Copy link
Contributor

bluecmd commented Mar 12, 2019

Right now using SoL requires reading and writing protobufs. Not ideal, but works.

We should find a way to use some of the existing clients. Maybe ubmcctl can create a Telnet socket and launch something like telnet/minicom/screen towards it?

@bluecmd
Copy link
Contributor Author

bluecmd commented Apr 8, 2019

There is now a UNIX socket in the build root named host.uart that is attached to the host serial port of an emulated u-bmc. This can be used to feed recorded serial data from servers to develop a nice client. One could also envision having a UART simulator program that interactively drives a fake terminal to make sure that input/output and special keys work as they should.

@bluecmd
Copy link
Contributor Author

bluecmd commented Apr 8, 2019

OVMF setup program uses Code page 437 (or possibly 850) instead of UTF-8 which hilights an important point: the system will be using various code pages at various times (Linux will be using UTF-8 for example). In addition to this the UEFI shell is more or less impossible to use if you haven't restricted your terminal to 80x24. These options should be easily available to switch between, but we might want to follow up with them later.

To illustrate what the implications are for a client, see https://imgur.com/a/2GeC3ER.

@bluecmd
Copy link
Contributor Author

bluecmd commented Apr 8, 2019

One possibility is that when the machine boots up, the client is "locked" into a 80x24 mode, and when the Xterm control sequence to read out the terminal size is invoked we know that the software running is size aware, and the size lock can be released. Obviously there will be cases where this breaks and then manual control will also be needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant