trier@diku.dk (Jens Trier Rasmussen) (03/22/89)
Reply-to: trier@diku.dk (Jens Trier Rasmussen) Hello in Netland !! Has anyone out there tried to run SLIP (Serial Line IP) over a LAT connection to an asyncron line sitting on a DECserver ? All this under ULTRIX. Cheers Jens trier
grr@cbmvax.UUCP (George Robbins) (03/29/89)
In article <88360@felix.UUCP> trier@diku.dk (Jens Trier Rasmussen) writes: > Reply-to: trier@diku.dk (Jens Trier Rasmussen) > > Has anyone out there tried to run SLIP (Serial Line IP) over a LAT > connection to an asyncron line sitting on a DECserver ? All this under > ULTRIX. It will probably work, though there seems to be some question about just what happens to the server when an Unix program issues a IOCTL to put the line in RAW mode. Some people here are claiming that this does not disable control q/s flow control at the server. This would be a pain, since flow control/8 bit mode (passall) on the Decserver is a session, rather than port parameter and would have to be set everytime you log into the server. On the other hand, these people may be confused. I haven't resolved this yet, and it may be a non-issue or further perusal of the Decserver manual may yield the correct setup. The details of the LAT / terminal emulation are almost completely undocumented, not to mention the intentional secrecy surrounding how to initiate reverse LAT connections. DEC could do a lot better in this respect. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
mtsu@blake.acs.washington.edu (Montana State) (03/31/89)
In article <6425@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >In article <88360@felix.UUCP> trier@diku.dk (Jens Trier Rasmussen) writes: >> Reply-to: trier@diku.dk (Jens Trier Rasmussen) >> Has anyone out there tried to run SLIP (Serial Line IP) over a LAT >> connection to an asyncron line sitting on a DECserver ? All this under >> ULTRIX. >It will probably work, though there seems to be some question about just >what happens to the server when an Unix program issues a IOCTL to put >the line in RAW mode. Some people here are claiming that this does not >disable control q/s flow control at the server. This would be a pain, >since flow control/8 bit mode (passall) on the Decserver is a session, >rather than port parameter and would have to be set everytime you log into >the server. Couldn't you just set priv's on the DECServer, and then do a DEFINE PORT FLOW DISABLED?? Followed with a SET PORT FLOW DISABLED?? Of course maybe I'm misunderstanding what you're trying to do. Which leads me to another question... Are the IOCTL()'s that allow you to make a connection to a remote LAT port documented anywhere?? Obviously lpd uses them, but I don't see any how-to's anywhere. Jaye Mathisen icsu6000@caesar.cs.montana.edu
grr@cbmvax.UUCP (George Robbins) (03/31/89)
In article <1400@blake.acs.washington.edu> mtsu@blake.acs.washington.edu (Montana State) writes: > > Are the IOCTL()'s that allow you to make a connection to a remote LAT port > documented anywhere?? Obviously lpd uses them, but I don't see any > how-to's anywhere. NO! This is the big gripe, that DEC has chosen not to document or provide access to the same facilities that sytem programs like lcp and lpd use, limiting your ability to upgrade/replace these programs with ones that you feel to be better in some way. As of 3.0, there is at least a new feature in lcp that allows you to attach a server/port specification to a LAT pseudo terminal so that when you open the terminal in the "normal" fashion, LAT will initiate the reverse-LAT link. While still not providing the interface apparently used by lpd, this does seem to proivde the support needed for most reverse-LAT connections, i.e. printers, slave terminals or (hopefully) uucp connections. I haven't gotten around to installing 3.0 yet, so I don't know how well this works. I'm also hot to try the LAT/telnet gateway program, since since this will reduce the pain of being stuck with DECServers in an environment where we keep adding more and more non-DEC, TCP only network hosts. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
treese@crltrx.crl.dec.com (Win Treese) (04/01/89)
Keywords: ultrix,slip,decserver,lat In article <6467@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >In article <1400@blake.acs.washington.edu> mtsu@blake.acs.washington.edu (Montana State) writes: >> >> Are the IOCTL()'s that allow you to make a connection to a remote LAT port >> documented anywhere?? Obviously lpd uses them, but I don't see any >> how-to's anywhere. > >NO! This is the big gripe, that DEC has chosen not to document or provide >access to the same facilities that sytem programs like lcp and lpd use, >limiting your ability to upgrade/replace these programs with ones that >you feel to be better in some way. Actually, 3.0 contains the information. I don't think there's much in the documentation, but there is code in /usr/examples/lat that show you how to do it. As George Robbins noted later in his message, 3.0 also provides the facility for lcp to associate a tty with a LAT line automatically, without an application having to worry about LAT at all. This works fine for printers, at least -- I haven't tried it for SLIP yet. /usr/examples also contains other code that might be of interest to you systems hackers out there... Win Treese Cambridge Research Lab treese@crl.dec.com Digital Equipment Corp.
grr@cbmvax.UUCP (George Robbins) (04/03/89)
In article <122@crltrx.crl.dec.com> treese@crltrx.crl.dec.com.UUCP (Win Treese) writes: > In article <6467@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: > >In article <1400@blake.acs.washington.edu> mtsu@blake.acs.washington.edu (Montana State) writes: > >> Are the IOCTL()'s... > >NO! This is the big gripe... > > Actually, 3.0 contains the information. I don't think there's much in > the documentation, but there is code in /usr/examples/lat that show you > how to do it. Beg to differ, but: The programs in /usr/exampes/lat don't use or document the core ioctl's used for lat operation. One of the programs does show a single new "readonly" ioctl that returns the servicename, server and port of an incoming lat call. > /usr/examples also contains other code that might be of interest to > you systems hackers out there... Does your /usr/examples contains something mine doesn't? I sucked in the entire supported and unsupported tapes, and found nothing other than the 3 programs in /usr/expamples/lat... Anyway, here are the ioctl's and data structures that need to be fully documneted and have their data structures appear in the distributed .h files. LIOCTTYI is addmittedly halfway there, but doen't appear in any manual page... ioctl structure function ========= ========= ======== LIOCSOL solicit_1 send solicit msg LIOCRES response_1 get response msg LIOCCMD lat_ucom send command msg LIOCINI lat_ini lat tty init LIOCTTYI ltattyi lat tty info The following .h files were also present in the Ultrix 1.2 release, but they seem to have dissapeared... csh> ls -l sys/lat total 15 -r--r--r-- 1 root 2816 Feb 19 1986 lat.h -r--r--r-- 1 root 5343 Feb 19 1986 lat_protocol.h -r--r--r-- 1 root 6031 Feb 19 1986 lat_var.h Oh well, I guess I'll just have to start invoking the ioctl's with random arguments and then try to get help from DEC if something just happens to go wrong.... 8-) -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
avolio@decuac.dec.com (Frederick M. Avolio) (04/04/89)
Check that you have edited /etc/svcorder. This is set up automatically if you di a bindsetup which is the preferred way to set this stuff up. Fred