Pseudo-TTYs & Reverse Telnet

I am looking for a utility that will allow me to bind a reverse-telnet connection via a psuedo-TTY. The goal is to be able to emulate a modem attached to a terminal server as a local device.

To clarify, I am looking for a utility that will run in daemon mode, that will create a direct connection to the modem (telnet ip.of.termsrv 2001), and emulate that connection via a psuedo-TTY (/dev/pts/#).

The reason I am doing this is because I have no physical serial or USB ports on the FreeBSD host, and need to attach a modem to it for dial-out purposes.

I've found some old documents indicating that something like this is possible, but I've been unable to duplicate the functionality thus far.

Here's an example of an AIX utility called cnsconnect: http://blake.ism.u-bordeaux1.fr/doc_link/C/a_doc_lib/7318s20/s20gdref/dialoutMod.htm

Does such a program exist within FreeBSD, or something that could be compiled within FreeBSD?
 
After posting I found conservd in the ports tree, which appears to do what I need. I have configured conservd.conf to point to my terminal server host, and reference the appropriate TCP port for initiating the connection.

All appears to work when I connect via cu or tip:
Code:
$ sudo cu -l /usr/local/comserv/dev/modem
Password:
Connected
AT
OK

Great, right? Well unfortunately I cannot get Minicom to connect to the same device.

Code:
$ sudo minicom
minicom: cannot open /usr/local/comserv/dev/modem: Permission denied

Code:
$ ls -l /usr/local/comserv/dev/modem
lrwxr-xr-x  1 root  wheel  10 Dec 14 14:01 /usr/local/comserv/dev/modem -> /dev/ttySu

Any ideas?
 
Sorry, I meant "comserv" in the ports tree.

Code:
ls -l /usr/ports/comms/comserv/
total 10
-rw-r--r--  1 root  wheel  509 Aug 31  2008 Makefile
-rw-r--r--  1 root  wheel  195 Jan 22  2006 distinfo
-rw-r--r--  1 root  wheel  469 Aug 31  2008 pkg-descr
-rw-r--r--  1 root  wheel   67 Feb 17  2001 pkg-plist
drwxr-xr-x  3 root  wheel  512 Dec 14 12:45 work
 
Ah, is that what you had in mind. Well, looks like you got it working.

Have you checked the minicom man page? Looks like you're telling it that the serial line is its configuration file.
 
It appears to be reading the global configuration file to get the '/usr/local/comserv/dev/modem' reference. I'm not exactly sure why it would say it doesn't have permissions when cu is able to access it.

Code:
# more /usr/local/etc/minicom/minirc.dfl
# Machine-generated file - use "minicom -s" to change parameters.
pu port             /usr/local/comserv/dev/modem
pu baudrate         9600

Are there any diagnostics I can run while initiating minicom to identify the reason for the failure?
 
Okay, so here's the latest. It appears that if I 'chmod 666 /dev/ttySu' minicom is then able to access the device.

Code:
Welcome to minicom 2.3

OPTIONS: I18n 
Compiled on Dec 10 2009, 21:08:15.
Port /usr/local/comserv/dev/modem

Press CTRL-A Z for help on special keys
                                                      
AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0                      
OK

Unfortunately, as soon as I exit Minicom, the device is removed/re-created, and the default permissions restored.

Code:
crw--w----  1 root  tty    0,  97 Dec 14 14:51 ttySu

Is there an expalanation for the root user not being able to access ttySu unless it is world writeable?

... very confused.
 
I guess my current situation boils down to two questions.

1 - Why can't /dev/ttySu (which is linked from /usr/local/comserv/dev/modem) be opened by Minicom (as root) unless it is world read/writeable?

2 - Assuming I have to make /dev/ttySu world read/writeable in order for this to work, what do I need to do to modify the default behavior when that device is created? Once I exit Minicom /dev/ttySu is removed/re-created, requiring it to be chmod'd again. I've looked at devfs.conf, but that appears to only relate to devices during bootup, is there a similar file to control devices upon dynamic creation?

Thanks..
 
Thanks for the quick reply. Does the system need to be reloaded after /etc/devfs.rules has been modified? /etc/devfs.rules didn't exist prior to this, although /etc/default/devfs.rules did exist.

Anyways, I've added the following to /etc/devfs.rules:
Code:
[localrules=10]
add path 'ttyS*' mode 0666 group tty

Additionally, I've added this to /etc/rc.conf:
Code:
devfs_system_ruleset="localrules"

Unfortunately /dev/ttyS* related devices aren't created with the expected results, and I'm wondering if a relaod, or restart of some service, is required before devfs.rules take effect.
 
Back
Top