Hi Don,
Tnx for the reply...
I have a cable modem connection here at the house... if it was a standard
telephone modem connection, what you suggest would indeed work (and i have
used it before), but you have a "standard" login sequence to a "shell" like
what can be presented from logging into a linux/unix box. If you are
connecting to your ISP with PPP (a binary connection stream) u cant readily
play this little trick... as you suggest, sometimes being "dumb enough" is
good!! i will post to the group just in case others are interested in ur
response...
the k1ttt widget will work well too, but again requires another box to
collaborate with. It lets you pump the output of a telnet connection to the
COM port, then all u have 2 do is connect the machine with TR running to
that COM port and 'viola!.... OTOH, for my puny little pistol contesting,
employing a second machine for this seems like an Atomic Powered Swiss Army
Knife solution.... but it would certainly be appropriate for a big gunner.
Unfortunately, now its getting to look better and better since RF blew out
the analog switch in the key line of the radio i used to use for packet ( i
have the replacement parts, but what a job to get at it! ). So its !really!
hard to stay connected to the local cluster!
i will try another experiment tonite which i dont expect to work, but it
may by accident.... it depends on how "dumb" tr and Windoze is (does TR use
the BIOS calls, or go directly to the hardware?).... I just thought of this
driving into work this morning, but it's a big punt...
1. Jumper pins 2,3 (TxD,RxD) together on the COMx port. Jump the
appropriate signalling bits together (null modem style).
2. Open up the k1ttt session, route telnet cluster output to COMx.
3. Startup TR in a DOS penalty box, using COMx as the Packet port...
4. Pray things are stupid enough to work!... If you reverse the sequence,
the k1ttt bridge stuff may not be able to open the port if TR has glomped
onto it already...
I guess i should have clarified my post a bit...
< SNIP 4 context >
At 05:22 PM 6/7/99 -0600, you wrote:
>We did this in wpx ssb, as our local cluster failed. It was simple - just
>told TRlog that I had a packet port on what really was the com port for
>the modem. Issued the ATDT # to dial from the packet window in tr to one
>of our ops home machine (on Linux, I think) that is on the internet full
>time. Logged on, telnetted and had spots all weekend! I'm no computer
>expert, but I sure was impressed that Trlog was just smart enough to be
>"dumb enough" in the right places not to care about difference between a
>modem or tnc.
>
>Hope this helps.
>
>73 Don
>VE6JY
>
>
>On Mon, 7 Jun 1999 rpb@ec.rockwell.com wrote:
>
>>
>>
>> i cant reliably stay connected to my local packetcluster when it's a busy
>> contest weekend... well, let me re-phrase that, i should say that im not
>> willing to run high power to do so!!
>>
>> but...
>> i do have a reliable connection to an internet telnet cluster site.....
>> so.... does anyone know how to fool the dos penalty box into thinking there
>> is incoming data on a com port (to satisfy TRlog) from a windows telnet
>> packetcluster session??
>>
>> k1ttt's bridge software would work, but requires a separate machine (or at
>> least add'l serial ports on the same machine, which i dont have) to do
>> it.... if i write the software myself, any clues on how to "bridge" between
>> the virtual dos machine and the windoze environment? what api's/interfaces
>> could be used?
>>
>> is there a simpler way?
>>
>> i can flawlessly run tr from within a dos box under win98, so no apparent
>> problems there...
>>
>> any suggestions?
--
FAQ on WWW: http://www.contesting.com/trlogfaq.html
Submissions: trlog@contesting.com
Administrative requests: trlog-REQUEST@contesting.com
Problems: owner-trlog@contesting.com
Feature Wishlist: http://web.jzap.com/n6tr/trwish.html
|