View Full Version : [Solved] Pseudo-TTYs & Reverse Telnet
December 14th, 2009, 21:15
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?
December 14th, 2009, 22:32
Perhaps you could use inetd to spawn cu which in turn connects to the modem line.
December 14th, 2009, 23:02
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:
$ sudo cu -l /usr/local/comserv/dev/modem
Great, right? Well unfortunately I cannot get Minicom to connect to the same device.
$ sudo minicom
minicom: cannot open /usr/local/comserv/dev/modem: Permission denied
$ 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
December 14th, 2009, 23:03
Sorry, I meant "comserv" in the ports tree.
ls -l /usr/ports/comms/comserv/
-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
December 14th, 2009, 23:09
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.
December 14th, 2009, 23:19
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.
# 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?
December 14th, 2009, 23:52
Okay, so here's the latest. It appears that if I 'chmod 666 /dev/ttySu' minicom is then able to access the device.
Welcome to minicom 2.3
Compiled on Dec 10 2009, 21:08:15.
Press CTRL-A Z for help on special keys
AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0
Unfortunately, as soon as I exit Minicom, the device is removed/re-created, and the default permissions restored.
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.
December 15th, 2009, 00:16
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?
December 15th, 2009, 00:22
1. Don't know. Checked for any suid bits? Do a ps while minicom is running to see what uid it is... it might be dropping privileges.
December 15th, 2009, 00:34
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:
add path 'ttyS*' mode 0666 group tty
Additionally, I've added this to /etc/rc.conf:
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.
December 15th, 2009, 00:36
December 15th, 2009, 01:13
Beautiful, that worked as expected. Thanks so much for your help.
December 15th, 2009, 01:24
ecables, please stop using [QUOTE] tags where you should use [CODE] tags!
vBulletin® v3.8.7, Copyright ©2000-2013, vBulletin Solutions, Inc.