There is some software package that allow run plug a tmux console into a null modem device (/dev/nmdm)?

Is there a terminal emulator program/command that when run from a shell, inside a Terminal Emulator, giving it some null modem device, e.g.
Code:
/dev/nmdm-probeA
it takes over your terminal, like tmux or screen, giving you a terminal over that null modem device?
 
Start with learning how to connect to a null modem device in command-line.

Google around for that.

It's basically same idea as SSH - use a command-line client to SSH into another host.

When you get that down in practice, then it's time to move on to start getting used to the idea of shells and terminal emulators (A shell runs inside a terminal emulator. An SSH command-line client runs in a shell.)

Keep things simple, and in order. SSH is not a terminal emulator, btw...

For more info on null modems in FreeBSD, consult the Handbook, Ch. 29: https://docs.freebsd.org/en/books/handbook/serialcomms/
 
For more info on null modems in FreeBSD, consult the Handbook, Ch. 29: https://docs.freebsd.org/en/books/handbook/serialcomms/
Have been there not help
Google around for that.
That is not even English.
Start with learning how to connect to a null modem device in command-line.
Found with socat one can connect to a null modem https://unix.stackexchange.com/questions/63116/create-null-modem-pair-linux, but have to use Yandex.
But how can it be done in base?
 
$ tmux attach

Will connect to an existing session of the user. It won't even disconnect the other session, so you can both type into the same terminal. Quite useful for remote support.
I thougth it was another thing. The point is that I have a virtual machine, using bhyve, that whose serial console is connected to a null modem device of nmdm(), and I need a way to attach some tmux terminal or something to the other end of the null modem device.
 
I thougth it was another thing. The point is that I have a virtual machine, using bhyve, that whose serial console is connected to a null modem device of [ma]nmdm[/man], and I need a way to attach some tmux terminal or something to the other end of the null modem device.
Hmm, not too familiar with nmdm. Perhaps someone else here can give more useful advice.

However, something like PPP would basically allow you to use your serial device like a (slow) network adapter and then you can use SSH and tmux ontop of that stack.
 
I thougth it was another thing. The point is that I have a virtual machine, using bhyve, that whose serial console is connected to a null modem device of nmdm(1), and I need a way to attach some tmux terminal or something to the other end of the null modem device.
If your VM has an IP address, even a private one, you can just SSH in (provided the VM has access to a NIC on your metal, which it should, otherwise just having a VM is kind of pointless )...
 
If your VM has an IP address, even a private one, you can just SSH in (provided the VM has access to a NIC on your metal, which it should, otherwise just having a VM is kind of pointless )...
Well, the machine definitely has network, but has not been installed ssh, not want to do such thing, as is just attack surface to worry about.
 
The point is that I have a virtual machine, using bhyve, that whose serial console is connected to a null modem device of nmdm(), and I need a way to attach some tmux terminal or something to the other end of the null modem device.
If you use sysutils/vm-bhyve this is just a setting.

Code:
     console            Set the type of console to use, which defaults to
                        nmdm.  If you have the tmux port installed and would
                        prefer to use that for guest console access, you can
                        set this option to tmux.
vm(8)

As much as I love tmux(1) this setting is fairly annoying. Alternatively you could run cu(1) in tmux and connect that to the serial console of the VM. Or simply fire off vm console <myvm> in a tmux window.
 
Well, the machine definitely has network, but has not been installed ssh, not want to do such thing, as is just attack surface to worry about.
Now that's just paranoia. If you have sensible settings for SSH, you'll be fine. Not to mention that realistically speaking, your VM is most likely not even visible to port scanners on the Internet, and you don't present an attractive target for anyone capable of launching an attack that does any real damage. I have a few devices with SSH access sitting behind a 192.168.1.1/24 network, tell me if you can see them. ?

It's fine if you just wanna learn just for the heck of it, these Forums are full of people like that. :)
 
If you use sysutils/vm-bhyve this is just a setting.

Code:
     console            Set the type of console to use, which defaults to
                        nmdm.  If you have the tmux port installed and would
                        prefer to use that for guest console access, you can
                        set this option to tmux.
vm(8)

As much as I love tmux(1) this setting is fairly annoying. Alternatively you could run cu(1) in tmux and connect that to the serial console of the VM. Or simply fire off vm console <myvm> in a tmux window.
I already tried this and ended in this disaster: https://forums.freebsd.org/threads/...rectory-should-i-make-a-problem-report.95017/

I still have to try cu(1)
 
Now that's just paranoia. If you have sensible settings for SSH, you'll be fine. Not to mention that realistically speaking, your VM is most likely not even visible to port scanners on the Internet, and you don't present an attractive target for anyone capable of launching an attack that does any real damage. I have a few devices with SSH access sitting behind a 192.168.1.1/24 network, tell me if you can see them. ?

It's fine if you just wanna learn just for the heck of it, these Forums are full of people like that. :)
Sometimes you cannot have a ssh console, like when developing an new kernel, or a failing VM.
 
looks like the same:
I believe on FreeBSD they share the same binary but have different operation based on argv[0] (similar to i.e busybox). One might even be a symlink.

However, if you look at the manpages, you can see that their usage is a little different from one another. Historically, different UNIX platforms preferred one or the other so FreeBSD kind of inherited both.
 
Back
Top