mfryba@phoenix.Princeton.EDU (Martin Francis Ryba) (12/01/88)
I have a problem, and am getting a little exasperated by now.... I want to remotely control a AT via the modem port. I don't want the graphics (just tty), so I can do this from any machine. I've looked at various communications programs (mskermit,BitCom, etc..) and have yet to find one that will do. "Answering capability" is a joke with most of them, since they all require someone at the keyboard still. I mean REMOTE control: this thing is going to be operating a telescope 500 miles from the lab. I don't relish the idea of writing a device driver from scratch. What do people who run BBS's do? I have MKS Toolkit and all languages of import, so a variety of methods are open once I figure out how to address the COM port to control the modem (Hayes-compatible). I currently get a write error if I simply write stuff to COM. Thanks in advance for help on this. Marty Ryba (slave physics grad student) They don't care if I exist, let alone care about my opinions!
gpmenos@phoenix.Princeton.EDU (G. Philippe Menos) (12/01/88)
In article <4652@phoenix.Princeton.EDU> mfryba@phoenix.Princeton.EDU () writes: >I have a problem, and am getting a little exasperated by now.... > >I want to remotely control a AT via the modem port. I don't want the >graphics (just tty), so I can do this from any machine. I've looked at >various communications programs (mskermit,BitCom, etc..) and have yet to Have you looked at a product called "PCanywhere" or "CarbonCopy"; maybe even Procomm will fit the bill. -Phil
starr@shuxd.UUCP (Michael L. Starr) (12/01/88)
In article <4652@phoenix.Princeton.EDU> mfryba@phoenix.Princeton.EDU () writes: >I have a problem, and am getting a little exasperated by now.... > >I want to remotely control a AT via the modem port. I don't want the >graphics (just tty), so I can do this from any machine. ... I mean >REMOTE control: this thing is going to be operating a telescope 500 >miles from the lab. I have had great success with Carbon Copy. I use it to access every board on my machine, including IRMA and LAN. Carbon Copy turns your local keyboard into your remote keyboard, and your local screen into your remote screen. (i.e. if a character, including graphics, appears on your remote screen, it is duplicated on your local screen). The keyboard mapping is so good, that if you have any "hot" keys for TSR programs, it will active the TSR remotely. I've been using Carbon Copy for about two years, and have just ordered an upgrade to 5.0. -- __/\__ ******************** __/\__ | starr@shuxd.att.com \ / * Michael L. Starr * \ / | att!shuxd!starr |/\| ******************** |/\| | starr%shuxd@att.arpa
williamo@hpcupt1.HP.COM (William O'Shaughnessy) (12/02/88)
The primary thing you want to do is switch your console to com1.
This is done with the ">ctty com1" command. This should be imbeded
in your autoexec.bat file along with some other important steps.
This guarantees that it will be redone if there is a power outage
at the remote site.
Your autoexec.bat file should contain the following:
1.) a "mode " command to set baud rate and parity on the com port;
2.) copy a file that contains the modem configuration strings from
the disc to the com port.
3.) a password program that reads a password from the comport. There
are a few nasties out there that dial phone numbers looking for
auto answer modems. Wouldn't you like to have one of them
controlling your telescope!
4.) the ctty com1 or ccty com2 command to move the console to the
com port.
The last thing you should do in each of your connected sessions is to
run the password program so that the next access is protected by the
password also. You'll feel kind of sick if you dial your telescope some
day and the number is busy.
Good Luck,
Bill O'Shaughnessy
No warrantees or guarantees are implied or given
for any of the above. The above opinions are
my personal opinions and may not reflect those
of my employer.sic@ritcsh.UUCP (Eric A. Neulight) (12/03/88)
In article <4652@phoenix.Princeton.EDU> mfryba@phoenix.Princeton.EDU () writes: >I have a problem, and am getting a little exasperated by now.... > >I want to remotely control a AT via the modem port. I don't want the >graphics (just tty), so I can do this from any machine. I've looked at >various communications programs (mskermit,BitCom, etc..) and have yet to >find one that will do. "Answering capability" is a joke with most of >them, since they all require someone at the keyboard still. I mean >REMOTE control: this thing is going to be operating a telescope 500 >miles from the lab. I don't relish the idea of writing a device driver >from scratch. What do people who run BBS's do? I have MKS Toolkit and >all languages of import, so a variety of methods are open once I figure >out how to address the COM port to control the modem (Hayes-compatible). The best (and most user transparent and simple to use) package I have seen is written and sold by a company called "Robec" based in Horsham, PA. The name of the package is "SoloCom" and allows you to do just about anything but change floppies from the remote location. A few for-intances ... file transfers in the background (while you are doing something else) auto call/answer. chat mode. printer redirection from remote. enable/disable remote display and keyboard. remote reboot. do DOS things locally while still connected to remote. very fast (works at any baud rate your PCs can mannage.) fully configurable. password and license protection (if you wish). It sounds to me like you want to get at the actual guts of the package. Not just control a program which is running on the remote end, but actually interfacing to the packages low level communications protocol. SoloCom uses some sort of fully packetized protocol with full error detection and retry. Supposedly, in a future release, they intend to allow user programs to send/receive their own packets via some user interface calls. Sorry if all this seems disjoint, but I am banging this out in a hurry and going from memory. Check it out. ============================================================================== CLAIMER: Well -- I wrote it! Eric Alan Neulight "Nothing is Impossible -- Just Impractical." Electrical Engineering "For every Lock, there is a Key." Computer Science House "INSANITY is just a state of mine." Rochester Institute of Technology BITNET: EAN4762@RITVAX UUCP: ...!rutgers!rochester!rit!ritcsh!sic ==============================================================================
waters@dover.uucp (Mike Waters) (12/04/88)
In article <12630002@hpcupt1.HP.COM> williamo@hpcupt1.HP.COM (William O'Shaughnessy) writes: >The primary thing you want to do is switch your console to com1. >3.) a password program that reads a password from the comport. There > are a few nasties out there that dial phone numbers looking for > auto answer modems. Wouldn't you like to have one of them > controlling your telescope! I agree on the hacker problem, but please don't get the idea that a password alone fixes the problem! Password "crackers" are almost an art form these days and could likely get your password with a simple system such as described in a few hours. The solution really depends on how much damage can be done and how much you have to spend (see my earlier post for one idea). Whatever you do though DONT ignore the possibility that someone you don't want will be calling! -- Mike Waters (for your EDIFication) * Motorola CAD Group * Witty remark goes *HERE* Mesa, AZ ...!sun!sunburn!dover!waters * OR moto@cad.Berkley.EDU *
keith@meph.UUCP (Keith McQueen) (12/05/88)
In the article: " From: mfryba@phoenix.Princeton.EDU (Martin Francis Ryba) Subject: Remote control of PC via modem " >I have a problem, and am getting a little exasperated by now.... >I want to remotely control a AT via the modem port. I don't want the >graphics (just tty), so I can do this from any machine. I've looked at >various communications programs (mskermit,BitCom, etc..) and have yet to >find one that will do. "Answering capability" is a joke with most of >them, since they all require someone at the keyboard still. I mean >REMOTE control: this thing is going to be operating a telescope 500 >miles from the lab. I don't relish the idea of writing a device driver >from scratch. What do people who run BBS's do? I have MKS Toolkit and >all languages of import, so a variety of methods are open once I figure >out how to address the COM port to control the modem (Hayes-compatible). >I currently get a write error if I simply write stuff to COM. It sound like you might be able to get by just using the "CTTY" command of DOS. This assigns another device to be the console device for DOS ie. COM1 or COM2 etc. It is rather crude, but may just do the job for you. Keith (not Steve) McQueen.
jcb@loral.UUCP (Jay C. Bowden) (12/07/88)
In article <229@ritcsh.UUCP> sic@ritcsh.UUCP (Eric A. Neulight) writes: >In article <4652@phoenix.Princeton.EDU> mfryba@phoenix.Princeton.EDU () writes: >>I have a problem, and am getting a little exasperated by now.... >> >>I want to remotely control a AT via the modem port. I don't want the >>graphics (just tty), so I can do this from any machine. I didn't see the original posting, but I have some info re the topic: Call this number for fun: (619) 481-1753 (1200-n-8-1, wait 60 seconds after you get a carrier then hit RETURN) to find out about: o A gadget that turns on the PC's power when the modem answers (you may not want this if the PC is left on all the time) o Some .BAT files that let you CHOOSE, over the COM1: port, which of several remote control progs you want to run (like PROCOMM, PC-Anywhere, or just dumb CTTY mode). If you can't replicate the same results with the .BAT files, call me by voice at (619) 436-7608. I'll be happy to try and help. You may have to do some mode-like things to your modem (I did). - Jay ------------------------------------------------------------------ Jay Bowden, EE/Consultant; see also Bowden Engineering Currently contracted at Loral Instrumentation, San Diego {ucbvax, ittvax!dcdwest, akgua, decvax, ihnp4}!ucsd!loral!jcb
sme@computing-maths.cardiff.ac.uk (Simon Elliott) (12/07/88)
In article <12630002@hpcupt1.HP.COM>, williamo@hpcupt1.HP.COM (William O'Shaughnessy) writes: > The primary thing you want to do is switch your console to com1. > This is done with the ">ctty com1" command. This should be imbeded > in your autoexec.bat file along with some other important steps. > This guarantees that it will be redone if there is a power outage > at the remote site. > [stuff deleted about setting baud rate using MODE, etc] The ctty command will work for well-behaved programs only, but you all knew that, didn't you? The important thing, though, is that the default COM1 device does no buffering, and polls the serial port for i/o. This makes CTTY COM1 pretty frustrating and unusable, 'coz you lose characters. If you really want to use CTTY, it's advisable to replace the COM1 device driver with something that uses interrupt-driven, buffered i/o. Actually, you wouldn't need to have a complete device driver; you could capture interrupts 0Bh & 0Ch (for hardware interrupts) and interrupt 14h (the serial port BIOS s/w interrupt). You'd have to enable interrupts 0B and 0C at the 8259 interrupt controller and at the 8250 UART also. The interrupt handlers would co-operate to manage buffered i/o, and setting the baud rate etc could be done by chaining to the original BIOS handler. Anyone seen/got any code to do this? I dimly recall an article in an old Dr Dobbs (c. 1986). -- -------------------------------------------------------------------------- Simon Elliott Internet: sme%v1.cm.cf.ac.uk@cunyvm.cuny.edu UWCC Computer Centre JANET: sme@uk.ac.cf.cm.v1 40/41 Park Place UUCP: {backbones}!mcvax!ukc!reading!cf-cm!sme Cardiff, Wales PHONE: +44 222 874300
kjohn@CTIX.uucp (John K. Counsulatant) (12/09/88)
I too have an AT and would like to run it remotely. What I need is
the ability to see the text output (don't need or have graphics :-) at the
remote end. My reason for this is that our company runs it's day-to-day
operations on this AT, but the environment it is in is *extremely* dusty
(wood is being sawed, etc in the next room). I don't know how long our AT
can survive this. Please help us.....
KJohn
I can be reached at:
RealTime: 1(312)418-1236 (6pm to 10:30pm central time)
USmail: John Kjellman
17302 Park Ave.
Lansing IL 60438
E-Mail: kjohn@richp1.UUCP
or
[ purdue | cs.ubc | mcdcchg ] ! richp1 ! kjohn
or
uunet ! richsun ! kjohn
| Amiga ///.5K| Disclaimer: This is only a dream, it's only a dream ........ |
| Manic/// 1K| KJohn, the man without an Amiga :-( |
| \\\/// 2K| (how much is an A2500/3000 anyways? :-) |
| \XX/ 2.5K| kjohn@richp1 or [ purdue | cs.ubc | mcdcchg ] ! richp1 ! kjohn|rbono@necis.UUCP (Rich Bono) (12/12/88)
In article <579@cf-cm.UUCP>, sme@computing-maths.cardiff.ac.uk (Simon Elliott) writes: ... deleted stuff... > > If you really want to use CTTY, it's advisable to replace the COM1 device > driver with something that uses interrupt-driven, buffered i/o. ... deleted stuff... > > Anyone seen/got any code to do this? I dimly recall an article in an old > Dr Dobbs (c. 1986). > I have posted DOSGATE to comp.binaries.ibm.pc and rec.ham-radio.packet that accomplishes all the above. I hope *someone* finds it useful. Rich Bono, NM1D -- /**************************************************************************\ * Rich Bono (NM1D) If I could only 'C' forever!! rbono@necis.nec.com * * (508) 635-6303 NEC Information Systems NM1D @ WB1DSW-1 * \**************************************************************************/