GRIPS 2: Government Rast…rocessing Software & Data/GRIPS_2.cdr/dos/ncsa_tel/digests/v2.07

Text File | 1990-12-29 | 12KB | 265 lines

NCSA Telnet Digest    Wednesday, 27 April 1988    Volume 2 : Issue 7
-------------------------------------------------------------------
        Re:  NCSA Telnet Digest Vol II - Issue 6
    what C compiler was NCSA Telnet for the Macintosh written for?
        comment to an article in telnet v2 #06
            A couple of things
        Re: NCSA Telnet Digest Vol II - Issue 6
            Re: Telnet 2.1e with 1/88 KIP
    Help with Netware compatible (hardware independent) pc-tcp/ip
     Re: Help with Netware compatible (hardware independent) pc-tcp/ip
-------------------------------------------------------------------

Date: Fri, 15 Apr 88 13:27:17 EDT
From: Rob Logan <[e-mail]>
Subject: Re:  NCSA Telnet Digest Vol II - Issue 6


I am running telnet 2.1 under windows386 with a 5210.  With ms-windows I
can make a window much larger than 80x25.  Is it possable tell telnet
how mant lines I have without recompiling it? (I hear the mc-c compiled
version is buggy.)

                Rob

[e-mail]

----------------------------------------
Date: Fri, 15 Apr 88 14:32:36 EDT
From: [e-mail] (James Ganong )
Subject: what C compiler was NCSA Telnet for the Macintosh written for?


does anyone know if it is possible to compile it using Lightspeed C?

(by the way, when I tried to grab the archives of this digest from
ftp.ncsa.uiuc.edu i got permission denied)

thanks
[ Ed Note -
[    The current version compiles in Aztec C68k 3.4b, and should
[    take few changes to compile under Lightspeed (assuming the Header
[    files are the same as MPW.  BTW, MPW is much more difficult because
[    of the sizeof(int)==sizeof(long) instead of sizeof(int) ==sizeof(short)
[    problem.
[  - Gaige ]

--------------------------------------------

Date: Fri, 15 Apr 88 13:58:15 EDT
From: [e-mail] (Les Wu)
Subject: comment to an article in telnet v2 #06

Tim,
   I recently attempted to send an entry to the relavent news group
concerning port addresses for the 3com driver.  I didn't manage to get
my msg out because our news system is a bit messed up.  I have included
it below.

   As far as I can tell, a change to the base IO address is trivial
straight forward at the source level (assembly) provided that one also
has the appropriate compilers (I don't have lattice) and the dos.mac
file.  A hand patch would be more difficult as about 40 changes would
be required.

My attempted message:

Newsgroups: comp.protocols.tcp-ip.ibmpc
Summary: How do I change the port addresses for a 3com card?

I am presently using NCSA Telnet v2.1 on my IBM-PC with a
3-Com EtherLink card.  All in all I am very happy with this
package.  The problem that I run into is that the 3Com card
resides at port address 0x300-0x310 which collides with another
card that I am using.

It is possible to change the IO address of the 3Com card but not
of the other card that I wish to use.  Does anybody have any
experience with hacking Telnet to use different IO addresses?

I have looked at the driver sources.  Unfortunately the source
distribution is missing one of the include files (DOS.MAC).
It appears that about 40 out instructions have to be patched.
Has anyone else out there in netland done this?


                                        Les J. Wu
                                        NRL Code 5153w
                                        Washington, DC 20375
                                        Tel: [phone]
                                        arpa: [e-mail]


------------------------------------------------

Date: Fri, 15 Apr 88 12:48:10 PDT
From: [e-mail] (David Vangerov)
Subject: A couple of things

First off I'd like to say that Telnet is a great product and
I'm really satisfied with its performance so far, but I have
a few comments to make about it and to suggest a couple of
things to be included in the future.

We use Telnet 2.1 on a Mac AppleTalk network that is connected
to the campus Ethernet via a Kinetics-Box. After struggling
for a while with the docs and the config file, I got everything
working right so that we could connect to the hosts, use a name
server and all that fun stuff. However, I've noticed a problem,
and I'm told that it is a problem with the code in the K-Box.
The K-Box has an address of 128.114.130.80. The hosts that I want
to connect to sit on the 129 net (128.114.129.*). I have no problem
connecting to hosts that sit on the 130 net or above, and I can
even reach outside hosts like ucbvax, sri-nic, etc, but for some
reason I can't get to the 129 net which is where most of the hosts
are that we want to get to. I'm told that this because the K-Box
isn't using the ARP code correctly. Does the new version of
Telnet take care of this slight problem? And if not, does anyone
know if Kinetics is going to fix the code so that it will use ARP
correctly? We have a kludge running that allows us to get to one
of the 129 hosts, but I don't know for how long it will last
(probably not long at all).

It would be really neat if Telnet could do anonymous FTP
transfers. In other words not have to login into a host and then
FTP back to the Mac or IBM. It would be really neat to just be
able to directly connect to the host, give it the anonymous
password (or even a user login and a password) and just be able
to get a list of files and copy 'em. Stanford's Mac IP seems to
do this really well, but there is some stuff about the program
that I don't like all that well, like the font used, size of
windows, and the setup procedures used for it. Other than that,
it's great.

It sounds like the new version of Telnet may correct some of
these problems and I'm looking forward to beta testing the new
version and seeing what new stuff you've got for it...



                -david

It's time out for a fortune:

            *** NEWSFLASH ***
Russian tanks steamrolling through New Jersey!!!!  Details at eleven!

---------------------------------------------

Date:     Fri, 15 Apr 88 15:00:18 CDT
From: Scott Comer <[e-mail]>
Subject:  Re: NCSA Telnet Digest Vol II - Issue 6

I would like to add another bug to NCSA Telnet 2.1 for the mac. When running
under MultiFinder, with telnet running also, I cannot type option-blech
characters to MPW. Without telnet running, they work fine. Please be sure
to fix that in version 2.2.

scott out

[ - Ed Note
[    I believe that late last year this problem was first discussed, but
[    in the interest of those who weren't on the list then, this bug has
[    been found, acknowledged and removed for the next version (as well
[    as a couple of others).  For more information, there was an extensive
[    note in V2.03.
[ - Gaige]

-----------------------------------------------

Date: Fri, 15 Apr 88 17:22:32 EDT
From: [e-mail] (Dan Lanciani)
Subject: Re: Telnet 2.1e with 1/88 KIP

    The problem is worse than you may think.  Even if the ip numbers
do not overlap 2.1e will fail if KIP is routing to the ethernet.  It
seems that if 2.1e sees a KIP box ("=:IPGATEWAY@*") if will use ip in
DDP (that's DDP on the ethernet) rather than sending ip directly.  Now,
this might even work (with sever performance loss) except that the KIP
code believes that incoming ip packets that are to be encapsulated in
DDP should be written to the LocalTalk port rather than routed as
DDP packets.  Of course, it also believes that the node numbers of
machines that request dynamic ip addresses are on LocalTalk...
    In any case, a quick fix is to turn EtherTalk off on the
Mac before using telnet.  Another approach (that I use here) is
to patch the telnet binary to not look for IPGATEWAY.  A simple
way to do this is to clobber the string IPGATEWAY with a few x's.

                Dan Lanciani
                ddl@harvard.*

-----------------------------------------------
Date:         Fri, 22 Apr 88 14:16:56 EST
From: Bob Alston <[e-mail]>
Subject:      Help with Netware compatible (hardware independent) pc-tcp/ip
To: pcip lists <pcip-l@byuadmin>, pcip list <[e-mail]>,
        Telnet list <[e-mail]>, tcp-ip list <[e-mail]>

We at ODU Computing Services are looking for a hardware topologically
independent tcp/ip solution for our Novell Networks.  We have an
ethernet based TCP/IP backbone that we would like to be able to take
advantage of from several existing and proposed Novell pc networks using
IBM Token Ring, 3COM 501 Ethernet, SMS Arcnet, and other asstd. hardware
topologies.  I have seen the Micom-Interlan (Netware) TCP/IP gateway, but
have concerns about its performance.  Also, I have seen several workstation
based solutions (ie Excelan, Ungermann-Bass, etc.), but we already have a
substantial hardware investment in other pc network interface cards
(token ring, ethernet, etc. as mentioned above) and also have heard that
the aformentioned workstation based solutions are prohibitively expensive.
I have heard rumors of a netbios based solution and I would be very interested
in learning more.  Please send me any and all info you can share.  I will
be glad to post the responses to the lists.

                 Thanks in Advance
                 Bob Alston
                 Old Dominion University
                 Norfolk, VA
                 BITNET: RWA100S@ODUVM

-----------------------------------------------------

Date: Sat, 23 Apr 88 10:58:13 EDT
From: [e-mail] (James Van Bokkelen)
Subject: Re: Help with Netware compatible (hardware independent) pc-tcp/ip

None of them use NETBIOS to encapsulate IP datagrams, but there are several
Novell-compatible, hardware- (but not media-) independent versions of TCP/IP
for the IBM PC that are either commercially supported, or widely available
in the public domain.

Our product for the IBM 802.5 Token Ring calls the IBM-supplied software
driver (the ASI interface), and can share it with other programs (Banyan
Vines, Novell Netware).  IBM's PC product might be able to manage the same
trick, but I don't know of anyone who has tried it.

A number of Novell's OEMs have modified their versions of Netware so that
they support our Packet Driver spec.  This allows our Generic Ethernet
version to share the interface with Netware. (Or you can ask Karl Auerbach
for the CMU version he posted about on pc-ip a week or two ago.  It also
uses the spec.)

Regrettably, none of the versions of Netware that support the Packet Driver
spec run on the 3C501, but there may be a workaround:  The 3C501 is so simple
(I'm being nice) that it is possible for two pieces of software using it
to co-exist:  You can run a TCP/IP package that is careful about restoring
the interrupt vector, as long as you don't try to use the LAN program while
the TCP/IP has the card.  I know this works with our PC/TCP or the CMU freeware
and 3Com's 3+, it would be worth trying with Netware.

For Arcnet, you could try Philip Prindeville's version of the CMU code, which
has also been mentioned on pc-ip.  I don't know if you could manage the
"co-existence" trick with Netware, or not.

Of course, this approach requires IP routers to forward normal IP packets
back and forth across the various networks.  Keep in mind that encapsulating
IP in NETBIOS datagrams requires at least one IP router, too.  Somebody has
to get the packets onto and off of your normal-IP backbone (?) Ethernet,
and the NETBIOS-space, however it is mapped to the various LANs, is at
least one subnet on its own.  If you aren't totally committed to Netware,
you might try looking up Banyan and asking them how they'd solve your problem.

James VanBokkelen
FTP Software Inc.