|
|
ARCHIVE: TCP-IP Distribution List - Archives (1991)
DOCUMENT: TCP-IP Distribution List for August 1991 (341 messages, 190041 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1991/08.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: 1 Aug 91 00:16:07 GMT From: km@mathcs.emory.edu (Ken Mandelberg) To: alt.sys.sun,comp.protocols.tcp-ip Subject: Midget thin ethernet tranceiver rec wanted.
We are about to buy about 15 midget thin ethernet trasnsceivers for use
with various compact suns. The last time we did this we stumbled
accross a batch with a very high failure rate. Maybe 25% failed within
a few weeks, and another 25% within a year. The vendor (who I would
prefer not to mention) did make good on the failures, but I don't think
this should happen.
Can anyone recommend one in the <$100 range which has shown to be
reliable.
--
Ken Mandelberg | km@mathcs.emory.edu PREFERRED
Emory University | {rutgers,gatech}!emory!km UUCP
Dept of Math and CS | km@emory.bitnet NON-DOMAIN BITNET
Atlanta, GA 30322 | Phone: Voice (404) 727-7963, FAX 727-5611
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: 1 Aug 91 00:21:01 GMT From: brunner@telebit.com (Eric Brunner) To: comp.protocols.tcp-ip Subject: Re: behavior when receiving >1 ARP REPLY
In article <1991Jul26.225607.26001@Think.COM> barmar@think.com writes:
>In article <569@zeuswtc.sbi.com> matt@zeuswtc.sbi.com (Matthew Gutherz ISG) writes:
>>I seem to recall that a host is supposed to keep the last ARP REPLY it
>>receives when it receives more than one reply to a request. I've looked
>>through a number of RFCs but can't find a reference to this. Could
>>someone out there provide me with a reference either for or against.
>
>This follows from the original ARP specification in RFC826. Whenever you
>receive an ARP packet you are supposed to update your ARP cache with the
>information it contains. This can happen even if you haven't sent an ARP
>request (some systems broadcast an ARP reply when they boot, and if a
>system has an interface that supports changing the hardware address it's
>probably a good idea to broadcast an ARP reply when doing this).
So far so good, however, in multi-path 802.5 rings (with source route
bridges), rfc1042 does not require the implementor(s) any specific
behavior.
From rfc1042 (not yet obsoleted by son-of-1042):
It is possible that when sending an ARP request via an all-routes
broadcast that multiple copies of the request will arrive at the
destination as a result of the request being forwarded by several
Postel & Reynolds [Page 11]
^L
RFC 1042 IP and ARP on IEEE 802 Networks February 1988
bridges. However, these "copies" will have taken different routes
so the contents of the RIF will differ. An implementation of ARP
in this context must determine which of these "copies" to use and
to ignore the others. There are three obvious and legal
strategies: (1) take the first and ignore the rest (that is, once
you have an entry in the ARP cache don't change it), (2) take the
last, (that is, always up date the ARP cache with the latest ARP
message), or (3) take the one with the shortest path, (that is,
replace the ARP cache information with the latest ARP message data
if it is a shorter route). Since there is no problem of
incompatibility for interworking of different implementations if
different strategies are chosen, the choice is up to each
implementor. The recipient of the ARP request must send an ARP
reply as a point to point message using the RIF information.
Note that choice #2 is what is actually implemented, since most media
(read ethernet) rarely presents arp requests with small inter-arrival
times except in pathological circumstances. In multi-path SRB 802.5
rings, choice #2 results in pessimal routing, the final ARP Reply recieved
results in the installed route (in the 802.5 SRB sense of link-level routes),
which is probably the longest traversal path in both the query and reply
paths (which are probably distinct).
While pessimal routes are a problem, the undocumented semantics of the 3rd
bit in the RIF cause more problems in the unicast reply, but that is another
subject.
--
Eric Brunner
Tule Network Services - 4bsd/rt project
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: 1 Aug 91 00:41:09 GMT From: mdyoung@AUSTIN.LOCKHEED.COM (Mark D. Young) To: comp.protocols.nfs,comp.protocols.tcp-ip,comp.windows.x,comp.windows.x.motif Subject: How do I get the file id. for TCP socket from RPC?
We are using the RPC package on the Suns to do network programming in conjunction with X windows and Motif. I've gotten stuck because XtAddInput needs a file id. Does anyone know how to get the file id. of a TCP socket from the RPC package? Or is there a different way to use the RPC package with X windows? Thanks. Mark Young mdyoung@austin.lockheed.com
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: 1 Aug 91 01:07:36 GMT From: rikitake@jrd.dec.com (Kenji Rikitake) To: comp.protocols.tcp-ip Subject: Internet Society: how to join?
I would like to join Internet Society, just established this June. I would appreciate any help. Please email to me. (No followup please) -- Kenji
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: 1 Aug 91 01:30:29 GMT From: rwmira01@ULKYVX.BITNET (Rob Miracle) To: comp.mail.misc,comp.protocols.tcp-ip Subject: Help with Sendmail and WIN/386 TCP-IP
I am having difficulty getting a AT&T 386 with AT&T System V R3.2.3 and Wollengong WIN/386 TCP/IP 3.2 to receive mail. I can send from the 386 (ncc02) to other smtp systems, but when they try to send to ncc02, it fails. I used to get a message in the /usr/spool/mqueue/syslog about a Directory not found or something. I created the /usr/lib/aliases file, /usr/lib/sendmail.hf and .st and that seemed to help. I even created a /usr/spool/mail directory (the default is /usr/mail) thinking that was the problem. I would appreciate any suggestions or help. Below are the contents of the /usr/spool/mqueue/syslog file and the mail that is returned to the sender. It has to be something simple. Thanks in advance. Rob -- /usr/spool/mqueue/syslog: Jul 31 20:50:08 [1360] 4 aliases, longest 20 bytes, 77 bytes total Jul 31 20:50:09 [1360] AA01360: message-id=<9108010051.AA27464@vlsi.louisville.edu> Jul 31 20:50:09 [1360] AA01360: from=<rwmira01@vlsi.louisville.edu>, size=392, class=0 Jul 31 20:50:11 [1362] AA01360: to=<rob@ncc02.ct.louisville.edu>, delay=00:00:03, stat=Service unavailable Jul 31 20:50:11 [1362] giveresponse: statmsg: 554 Service unavailable. Jul 31 20:50:11 [1362] AA01362: message-id=<9108010050.AA01362@ncc02.louisville.edu> Jul 31 20:50:11 [1362] AA01362: from=MAILER-DAEMON, size=0, class=0 Jul 31 20:50:20 [1365] AA01362: to=<rwmira01@vlsi.louisville.edu>, delay=00:00:09, stat=Sent After a bit, the following message is returned to to sender: From MAILER-DAEMON@ncc02.louisville.edu Wed Jul 31 20:53:04 1991 Received: from [136.165.2.13] by ncc02.louisville.edu (5.59/25-eef) id AA01362; Wed, 31 Jul 91 20:50:08 EDT Date: Wed, 31 Jul 91 20:50:08 EDT From: Mail Delivery Subsystem <MAILER-DAEMON@ncc02.louisville.edu> Message-Id: <9108010050.AA01362@ncc02.louisville.edu> Subject: Returned mail: Service unavailable To: <rwmira01@vlsi.louisville.edu> ----- Transcript of session follows ----- >>> HELO ncc02.louisville.edu <<< 553 ncc02.louisville.edu I refuse to talk to myself 554 <rob@ncc02.ct.louisville.edu>... Service unavailable: No such file or directory ----- Unsent message follows ----- Received: from [136.165.2.13] by ncc02.louisville.edu (5.59/25-eef) id AA01360; Wed, 31 Jul 91 20:50:08 EDT Received: from vlsi.louisville.edu by ulkyvx.bitnet with PMDF#10536; Wed, 31 Jul 1991 20:51 EDT Received: by vlsi.louisville.edu (5.57/Ultrix4.1) id AA27464; Wed, 31 Jul 91 20:51:16 -0400 Date: Wed, 31 Jul 91 20:51:16 -0400 From: rwmira01@vlsi.louisville.edu (Robert W. Miracle) To: rob@ncc02.ct.louisville.edu Message-Id: <9108010051.AA27464@vlsi.louisville.edu> Apparently-To: rob@ncc02 Testing Rob Miracle | Bitnet : RWMIRA01@ULKYVX CIS: 74216,3134 Programmer/Analyst-III | INTERNET : rwmira01%ulkyvx.bitnet@cunyvm.cuny.edu University of Louisville | UUCP : ...ukma!ulkyvx.bitnet!rwmira01
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: 1 Aug 91 03:23:00 GMT From: ingham@nodecg.ncc.telecomwa.oz.au (bruce ingham 4206700) To: comp.protocols.tcp-ip Subject: IP routing over ISDN.
We are currently evaluating methods of routing IP via ISDN. Do any products exist that provide IP routing directly onto ISDN ? While there are ISDN adapters that provide semi permanent circuits that could be used by conventional routers, I would hope a much neater solution exists. Bruce Ingham Phone: +61 9 4206700 Engineering Computer Centre Fax: +61 9 4207585 3rd Floor Telecom Centre ACSNET: ingham@telecomwa.oz 80 Stirling Street, Perth Inet: ingham%telecomwa.oz@uunet.uu.net Western Australia 6000
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: 1 Aug 91 07:24:05 GMT From: mouse@thunder.mcrcim.mcgill.edu (der Mouse) To: comp.mail.misc,comp.protocols.tcp-ip,comp.unix.misc,comp.unix.wizards Subject: Re: TALK (Unix-to-Unix, Unix-to-VMS)
In article <1991Jul26.184754.3298@bernina.ethz.ch>, volkoff@isi.ethz.ch (Serge Volkoff) writes: > When I type "talk user@host.domain.edu" it displays a split screen, > then says "No connection yet", then "Checking for invitation on > caller's machine", and stops there. No requests appear on the other > end. I have tried this with a number of machines, running both Unix > and VMS (I am using Unix here) and the result is always the same. I was not aware that VMS was capable of speaking talk protocol.... Part of this confusion is probably arising because there are two talk protocols, not one. They are, of course, incompatible, and if you try to talk from a machine that supports only one of them to a machine that supports only the other, the above is exactly what you'll get. The reason for having two protocols is not pure randomness. The original protocol was designed by someone who did not understand the concept of machine independence as applied to network protocols; as I recall it dumps C structs in raw binary to the network connection.... The new protocol is somewhat better, but still has problems. Some machines support both talk protocols, typically by having the new protocol in /usr/ucb/talk and the old one in /usr/old/talk. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: 1 Aug 91 08:34:59 GMT From: B.Kumar@CS.UCL.AC.UK To: comp.protocols.tcp-ip Subject: Re: Communication Failure Rates
>I am looking for information on the packet loss rates for wide area >networks, in particular, how these rates compare to local area >networks. Please mail any citations to (pds+@cs.cmu.edu). If others >are interested in the information, let me know and I will post a summary. I am also interested in these figures. Please do post summary on net if possible. Thanks, -- B Kumar Department of Computer Science University College London London WC1E 6BT(U.K ) PH: +44-71-387 7050 EXT 3697
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: 1 Aug 91 12:04:47 GMT From: iservice@gourock.sw.stratus.com (Ian Service) To: comp.protocols.tcp-ip Subject: EARP is it a reality?
I have heard some mention of the Extended ARP protocol, EARP, and have read a draft of an RFC(?) however lately I have heard nothing about the topic. Is EARP a viable protocol, is anybody going to use it. Or are there any alternatives agreed/proposed/under discussion for one to many IP to Link Layer mapping. -- ======================================================== All opinions are my own and do not represent anyone else. Ian Service iservice@gourock.sw.stratus.com Stratus Computer Inc. TEL (508) 460-2352 M/S M3-2-COM, 55 Fairbanks Boulevard FAX (508) 624-7488 Marlboro MA 01752-1298
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: 1 Aug 91 12:30:04 GMT From: richi@hpopd.pwd.hp.com (Richard Jennings) To: comp.protocols.tcp-ip Subject: Re: IP routing over ISDN.
bruce ingham 4206700 writes...
> We are currently evaluating methods of routing IP via ISDN.
I believe Hewlett-Packard make such a product. You could talk to your local
HP sales office.
Regards,
richi.
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -
Richard Jennings, Software Development Engineer
Pinewood Information Systems Division, the home of HP's Advanced
----------------------------------------- Image Management System (HP AIMS),
AdvanceLink, OpenMail and Multi-media communications
Hewlett-Packard --------------------------------------
Nine Mile Ride Voice: (+44)/(0) 344 763738 ADMD=GOLD 400 C=GB
Wokingham Fax: (+44)/(0) 344 763526 OU1=Pinewood ORG=hp
Berkshire RG11 3LL E-mail: richi@hpopd.pwd.hp.com GN=Richard PRMD=hp
England or: richi@hpopd.pwd.hp.co.uk SN=Jennings
--
>> Of course, I don't speak for Hewlett-Packard <<
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: 1 Aug 91 13:36:04 GMT From: NU021172@VM1.NODAK.EDU (Marty Hoag) To: comp.protocols.tcp-ip Subject: Connectivity among EMH ARMY.MIL Hosts and NSFNET
Bob Stringfield was kind enough to share a couple letters (from
Jeff Funk and Leland Steinke) speculating on causes for poor connectivity
among army.mil hosts (especially the Sperry 5000-80s) and other Internet
hosts (especially those on NSFNET).
I really think the problem is at a more fundamental layer than SMTP.
Frank Wancho has contributed some information (below) which indicates
that the IP packet TTL is set at 15 for these hosts. The minimum
recommended value in RFC 1060 is 32 but most sites are now using
at least 60! A value of 15 would allow the packet to travel only
15 "hops" before it is discarded.
Evidence that this is a "low level" problem is that the same problem
is seen with PING ICMP packets as with the SMTP packets. We have seen
hosts (eg. frankfurt-emh1.army.mil) where depending on the routing at
the moment the packets would arrive here with a residual TTL or 2 or
would hit our router with 0. If they were 0 they would be discarded
of course.
Below are a couple items on this. I REALLY wish someone could
declare a communications emergency for the Sperry TCP/IP software
and get this fixed! ;-) It is bad enough that your users can't
communicate but it wastes a lot of time for those of us whose
services they are trying to use.
Anything you can do to expedite a fix would be appreciated.
In particular, if you can trace your packets and find the TTL of
your outgoing and incoming IP packest (8 bytes offset from start
of the IP packet is the one byte TTL field) that would be a good
start.
Let me know if there is anything I can do to help! Thanks.
-----------
Marty Hoag
ND Higher Education Computer Network US Mail: NDSU Computer Center
Phone: (701)-237-8639 Fax: (701)-237-7464 PO Box 5164 / UCCS
Bitnet: nu021172@NDSUVM1 (NOTE 0 = ZERO) Fargo, ND 58105
Internet: nu021172@VM1.NoDak.EDU
UUCP: ...!uunet!plains!vm1.nodak.edu!nu021172
Date: Fri, 26 Jul 1991 11:29 MDT
Message-ID: <WANCHO.12704475680.BABYL@WSMR-SIMTEL20.ARMY.MIL>
Sender: <tcp-ip-relay@nisc.sri.com>
From: "Frank J. Wancho" <WANCHO@WSMR-SIMTEL20.ARMY.MIL>
To: Marty Hoag <NU021172@VM1.NODAK.EDU>
Cc: "Scott D. Martin" <ASQEXLA051A@FRANKFURT-EMH1.ARMY.MIL>,
...
Subject: Connectivity Problems
In-reply-to: Msg of 25 Jul 1991 07:50-MDT from Marty Hoag <NU021172 at
VM1.NODAK.EDU>
Marty,
There are several problems with the Sperry 5000/80 hosts. The most
severe is that the largest TTL value is 15. In a previous message Bob
listed some hosts in the EDU and COM domains he couldn't reach. Most
of them were well beyond 15 hops as measured from here. However, the
number of hops is not a constant in the policy-based routing of the
NSFnet world, and may be as few as 10 under some circumstances, such
as whether the route goes through FIX EAST or FIX WEST.
The other problem, even when the hop count is under 15, is that the
round trip time may be long enough to cause a timeout. Of course, when
the hop count is higher, the RTT is higher, too. In one case, the hop
count went over 30 (to sh.cs.net) before my trace quit.
--Frank
Resent-Date: Fri, 26 Jul 91 12:16:18 CDT
Resent-From: Marty Hoag <NU021172@NDSUVM1>
Resent-Organization: North Dakota Higher Education Computer Network
Resent-Subject: mainz-emh2.army.mil connectivity problems
Resent-To: funkb@zweibrucken-emh1.army.mil
Resent-Reply-To: Marty Hoag <nu021172@vm1.nodak.edu>
Received: from NDSUVM1 by NDSUVM1.BITNET (Mailer R2.07) with BSMTP id 9753;
Fri, 26 Jul 91 11:32:49 CDT
Received: from NDSUVM1.BITNET by VM1.NoDak.EDU (IBM VM SMTP R1.2.1MX) with BSMTP
id 6445; Fri, 26 Jul 91 11:32:43 CDT
Received: from NDSUVM1 (INFO) by NDSUVM1.BITNET (Mailer R2.07) with BSMTP id
9751; Fri, 26 Jul 91 11:32:41 CDT
X-Resent-Date: Fri, 26 Jul 91 11:32:25 CDT
X-Resent-From: ND HECN E-mail Postmaster <INFO@VM1.NoDak.EDU>
X-Resent-Organization: North Dakota Higher Education Computer Network
X-Resent-To: root%mainz-emh2.army.mil@moehringen-emh1.army.mil,
Marty Hoag <nu021172@vm1.nodak.edu>
X-Resent-Reply-To: ND HECN Postmaster <info@VM1.NoDak.EDU>
Date: Fri, 26 Jul 91 11:03:56 CDT
Sender: <tcp-ip-relay@nisc.sri.com>
From: ND HECN E-mail Postmaster <INFO@VM1.NoDak.EDU>
Organization: North Dakota Higher Education Computer Network
Subject: Re: [To: eurmmdf: Connect Problems]
To: Don Ross <mmdf@moehringen-emh1.army.mil>,
Network Mailer <MAILER@NDSUVM1>,
postmaster@APPLE.COM,
postmaster@VM1.NODAK.EDU,
postmaster@MERIT.EDU,
postmaster@SH.CS.NET,
root%MAINZ-EMH2.ARMY.MIL@zweibrucken-emh1.army.mil
cc: trouble@merit.edu,
danj@cac.washington.edu,
ASQEXLA051A@FRANKFURT-EMH1.ARMY.MIL,
"Billy O. Howard" <A455@HUACHUCA-EMH2.ARMY.MIL>
Reply-To: Marty Hoag <nu021172@VM1.NoDak.EDU>
In-Reply-To: Message of Thu, 25 Jul 91 09:04:39 CDT from
<mmdf@moehringen-emh1.army.mil>
Hi! Bob Stringfield sent me your note. I wanted to be sure you got
my reply earlier which explains some of the background. We are only a few
hops (ie. 3 ticks of the TTL) from the NSFNET backbone but many sites now
are 8-10 hops away (eg. nysernet sites).
I agree that this "acts" like a routing issue since sites tend to
fade in or out (of course some may never be able to connect). Again, I
can run LANWatch packet traces here and supply the printed packets if that
would help.
If there is anything we can do from here please let us know. Please note
that the frankfurt-emh1.army.mil site seems to be pretty well connectable
lately so I suspect someone did something... ;-)
Marty
----------------------------Original message----------------------------
The problem of connectivity between some MILnet sites (especially those
with XXXX-EMHn.ARMY.MIL names) was reported to NSFNET (our Internet backbone)
on 5/8/91. They opened trouble ticket 13032 at that time. The host
triggering the report was frankfurt-emh1.army.mil (26.4.0.116).
At the time of the reports frankfurt would "fade" in and out of connectivity
depending on the residual IP packet TTL. When connected it was 2. When we
could NOT connect it would reach 0 JUST before reaching our router.
At some point a change seemed to be made and the TTL reaching us now is 7
(as is zweibrucken's).
In simplistic terms it looks like the initial TTL value is just now large
enough for the Internet as it exists today. But I realize there could be
some other problem (a host using the incoming TTL for outgoing packets,
some gateway problem, etc).
The most frustrating problem for me in tracking this problem was NOT having
a contact for the MILNET gateway or for MILnet connectivity. I have included
the folks at Huachuca because I think they are involved with supporting some
of the mail software but this may be a problem at a deeper layer since it
involves IP TTLs (and they are the same for ICMP such as PING as for TCP SMTP
packets in general).
If you can forward the info to the appropriate people I'd sure appreciate
it. I have a LANWatch that I can check packet TTLs on quite easily. I have
used that to find sites which are potential problems (TTLs of 3 or less).
Let me know if I can help! We would like to clear up this problem. Thanks!
Marty
----------
Marty Hoag ND HECN E-mail Postmaster
ND Higher Education Computer Network US Mail: NDSU Computer Center
Work Phone: (701)-237-8639 PO Box 5164 / UCCS
Fax: (701)-237-7464 Fargo, ND 58105
Bitnet: INFO@NDSUVM1 (Including EARN, NetNorth)
Internet: INFO@VM1.NoDak.EDU
UUCP: ...!uunet!plains.nodak.edu!vm1.nodak.edu!INFO
Personal address: nu021172@vm1.NoDak.EDU (nu021172@ndsuvm1.bitnet)
On Thu, 25 Jul 91 09:04:39 CDT you said:
>Attempted as requested.....
>
>
>----- Forwarded message # 1:
>
>Received: from zweibrucken-emh1.army.mil by moehringen-emh1.army.mil id
>aa23936;
> 25 Jul 91 1:34 MDT
>Received: from zweibrucken-emh1 by mini01.zweibrucken-emh1.army.mil id aa17706;
> 25 Jul 91 1:09 MDT
>Received: from mainz-emh2.army.mil by mini01.zweibrucken-emh1.army.mil
> id aa17593; 25 Jul 91 0:59 MDT
>Date: Thu, 25 Jul 91 7:45:39 MST
>From: System Administrator <root@MAINZ-EMH2.ARMY.MIL>
>To: eurmmdf@zweibrucken-emh1.army.mil
>Subject: Connect Problems
>
>We're having problems connecting to EDU & COM destinations.
>
>Results are:
>
> ...can't
> destination not available, queuing for retry
>
>Contacted MILNET Support. They are able to connect. Our forced delivery
>could not be detected by them. I've rebuilt the tables, even went to
>a prior hosts.txt with no results.
>
>Any ideas.
>
>Would appreciate if some people would attempt delivery
>to some of the following and forward me the results:
>
>130.43.2.2
>134.129.111.1
>35.1.1.42
>128.89.0.92
>
>Thank you,
>Neal Warren
>
>
>----- End of forwarded messages
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: 1 Aug 91 15:21:51 GMT From: swt@bwdls25.bnr.ca (Steven W. Truelove) To: comp.protocols.tcp-ip Subject: TFTP block counter
I cannot find any reference that state whether or not the block counter in the tftp application is a signed or unsigned integer. Could anyone tell me which it is? SWT@BNR.CA These are my own thoughts, even though Bell Northern Research they are simple ones. Ottawa, Ontario, Canada
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: 1 Aug 91 15:36:46 GMT From: pcg@aber.ac.uk (Piercarlo Grandi) To: comp.protocols.tcp-ip Subject: Re: TCP Urgent data
On 30 Jul 91 16:31:29 GMT, mike@gordian.com (Michael Thomas) said: [ ... the Urgent indicator is just a "water mark" that gives the offset of the first byte of urgent data ... ] mike> I agree that, normally, not all of the data in between the current mike> stream head and the urgent pointer are likely to be Urgent, mike> however, I don't see where your're argument spares *any* mike> application from the nessesity of having buffer the data in mike> between RCV.NXT and RCV.NXT+Urgent *if* it doesn't desire to lose mike> bytes. Correct, but try to read URGENT (a misnomer!) as BREAK/RESYNC instead; the URGENT indicator simply means, as it is defined, that there is a pending interrupt, flush the queue, the first valid byte after the interrupt has this offset. The facility is designed for the case where the application _wants_ to lose the data before the BREAK/RESYNC (the classic example is aborting the current file transfer or remote command, where buffered typeahed has to be flushed, nothing more). mike> In the case of urgent data, the maximum amount "out of band" extra mike> buffering you would need is (64k - open-queue-size) Per occurrence mike> of urgent data, glech. Sadly this just seems to be a deficiency mike> in TCP -- trying to get out-of-band from a mechanism that just mike> ain't up to the job... Precisely, because it is not its job. The URGENT pointer is not meant to encode an OOB subchannel inside the main channel, it is meant to provide sort of asynchronous record boundaries. In TCP/IP, OOB must be _really_ OOB, another connection. If one wants a control channel and a data channel one does not use BREAK/RESYNC aka URGENT to multiplex the two channels onto one TCP/IP connection, one uses *two* TCP/IP connections, maybe making use of the quality of service options to five one higher "priority" than the other. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: 1 Aug 91 16:04:54 GMT From: jrb@jove.cs.pdx.edu (James Binkley) To: comp.protocols.tcp-ip,comp.unix.internals Subject: question about BSD checksum routine error? message
In the BSD p.d. tcp/ip code, in the portable checksum routine,
in_cksum()
there is a line of code near the end as follows:
if (len)
printf("cksum: out of data\n");
I seem to be getting this. This means logically that the mbuf
chain is shorter than the length passed in. Is this a bug?
What underlying circumstances might cause this to happen?
It crops up during heavy tcp traffic, presumably on the input side.
It seems possible to me that the length is derived from header info
and the actual received data might be short due to traffic accidents;
i.e., this might be a natural occurance??? Or no? On the other hand,
maybe this indicates a driver bug of some sort. Why is there
a printf?
Any info appreciated. Thanks
Jim Binkley
jrb@cs.pdx.edu
From: jrb@intel.com (James Binkley)
Newsgroups: comp.protocols.tcp-ip,comp.unix.internals
Subject: question about BSD checksum routine error(?) message
Summary:
Followup-To:
Distribution: world
Organization: Embedded Processor Focus Group, Intel Corp.
Keywords:
--------------------------------------------------------------
In the BSD p.d. tcp/ip code, in the portable checksum routine,
in_cksum()
there is a line of code near the end as follows:
if (len)
printf("cksum: out of data\n");
I seem to be getting this. This means logically that the mbuf
chain is shorter than the length passed in. Is this a bug?
What underlying circumstances might cause this to happen?
It crops up during heavy tcp traffic, presumably on the input side.
It seems possible to me that since the length is derived from header info,
and the actual received data might be short due to traffic accidents;
this might be a natural occurance??? Or no? On the other hand,
maybe this indicates a driver bug of some sort. Why is there
a printf? To me, that implies that this is a bug.
Any info appreciated. Thanks
Jim Binkley
jrb@ichips.intel.com
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: 1 Aug 91 16:36:27 GMT From: NU021172@VM1.NODAK.EDU (Marty Hoag) To: comp.protocols.tcp-ip Subject: Re: Connectivity Problems
Thanks for the note Bruce.
Could you ping these hosts and let me know the results? I think you
can reach us (the first one) and when we "PING" you the reply comes back
with a "good" TTL value of 7 left (which, in a normal case, would mean it
is 8 "hops" to here). I'm only about 3 hops from the NSFNET backbone
while CUNYVM.CUNY.EDU (the Internet-Bitnet gateway) is a bit deeper as I
remember. I'm curious if you can reach all the sites equally well just
with the gateway change. In other words - is it the gateway itself or
just because of the number of hops needed to get to the unusual gateway
that caused the problem. If it is the number of hops then there still
could be a problem.
VM1.NODAK.EDU 134.129.111.1
CUNYVM.CUNY.EDU 128.228.1.2
ORST-NWNET-GW.UCS.ORST.EDU 128.193.16.2
NIC.DDN.MIL 192.67.67.20
I'd be especially interested in what traceroutes look like from the
various sites or at least whether or not they could each ping each
of these sites.
Marty
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: 1 Aug 91 18:37:42 GMT From: NU021172@VM1.NODAK.EDU (Marty Hoag) To: comp.protocols.tcp-ip Subject: Re: Connectivity among EMH ARMY.MIL Hosts and NSFNET Reply To:, dmritter@cbg-99sima.army.mil
On Thu, 1 Aug 91 14:21:59 EDT you said:
>Marty,
>
>If I read you correctly, your saying that the Sperry TCP/IP
>software needs to be modified. Is that correct? Having just a
>binary release of this software, is there anything we can do to up
>our TTL?
>
>Thanks,
>dave
Dave:
This discussion has been forwarded to so many folks I no longer remember
who has seen what... ;-) But Frank Wancho said the Sperry software is using
a TTL value of 15 in the IP packets. It is probably something that would
have to be changed and redistributed or for which maybe some sort of field
change could be issued (ie. a zap in IBM MVS terms. ;-).
Apparently at least one site may have had the problem made worse by
using a rather obscure gateway. But even if that were the particular
problem, I just think 15 is too low to reach many of the Internet hosts
these days.
If a case could be made that the Sperry binary code is faulty is there
a maintenance contract on it? Or is what you have what you get? It would
be nice for the problem to be fixed at all the sites (but I imagine there
are other more urgent problems too...).
Marty
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: 1 Aug 91 20:12:09 GMT From: aras@falcon.no (Arne Asplem) To: comp.protocols.tcp-ip Subject: Routing question (between TCP/IP and dedicated SLIP links)
I've set up a network of 3 UNIX SVR3 systems connected over Ethernet,
running TCP/IP. My Sun 3/50 has a 38kbit/s SLIP link to a Stride 740
UNIX system runnning UniStride 2.x (SVR2 with BSD networking). How
do I set up routing on the SVR3 systems so they directly can telnet/ftp
over the SLIP link ?
I've set up routed with an entry like this in /etc/gateways
host falc2 gateway walrus metric 2 passive
but it still doesn't work !
Any other files I have to modify ?
-- Arne
--
Arne Asplem Address: Falcon Information Services A/S
Stranden 1, N-0250 Oslo 2, Norway
Research and Development Phone: +47 2 831310 Fax: +47 2 831290
of UNIX based trading systems E-mail: aras@falcon.no
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: 1 Aug 91 21:50:48 GMT From: rikitake@jrd.dec.com (Kenji Rikitake) To: comp.protocols.tcp-ip Subject: Re: IP routing over ISDN.
In article <1991Aug1.032300.8756@nodecg.ncc.telecomwa.oz.au>, ingham@nodecg.ncc.telecomwa.oz.au (bruce ingham 4206700) writes: ] Do any products exist that provide IP routing directly onto ] ISDN ? You can attach ISDN boards for Sony NEWS workstations. I've heard several people doing IP networking on it. The board is intelligent so you need not to have TA. -- Kenji
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: 1 Aug 91 23:10:40 GMT From: NAM@EVAX2.ENGR.ARIZONA.EDU To: comp.protocols.tcp-ip Subject: Need help on kerberos
Hi, I need a help on kerberos setup on VAX. I purchase a 4.3BSD-reno about 3 month ago and still having trouble on passwd setup using kerberos. If anyone has experience or referance material, please give me some help. Thanks in advance!!! --- Nam
-----------[000019][next][prev][last][first]----------------------------------------------------
Date: 2 Aug 91 00:20:12 GMT
From: RAF@CU.NIH.GOV ("Roger Fajman")
To: comp.protocols.tcp-ip
Subject: Re: TCP Urgent data> I haven't used a TCP without urgent data, but my (pre-1123) TELNET > implementations don't use it. When you hit INTR, they send IP, then (by > default) flush all data until the server responds up to DM. There are no > surprises, because as far as the user can tell, the server shuts up > instantly. (I was happy to see that RFC 1123 recommended this practice. > The user can turn off the flushing, of course, but what sane user would > want to do so? In fact, what sane TELNET client implementation would do > anything other than flush data as soon as it sent IP?) That's usually a reasonable thing to do, but there can be applications in which it is more important to know at what point the IP was received and acted upon by the host than to have the output stop immediately. This may not be true in Unix, but everything is not Unix. Roger Fajman Telephone: +1 301 402 1246 National Institutes of Health BITNET: RAF@NIHCU Bethesda, Maryland, USA Internet: RAF@CU.NIH.GOV
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: 2 Aug 91 02:41:56 GMT From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein) To: comp.mail.misc,comp.protocols.tcp-ip,comp.unix.misc,comp.unix.wizards Subject: Re: TALK (Unix-to-Unix, Unix-to-VMS)
In article <1991Aug1.072405.13249@thunder.mcrcim.mcgill.edu> mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes: > Part of this confusion is probably arising because there are two talk > protocols, not one. It's more accurate to say that there are three in wide use: 4.3, 4.2 with big-endian, 4.2 with little-endian. None of the three is compatible with any other. Of course, if someone has 4.2 talk running on a PDP, that's a fourth protocol. The 4.2 protocol can also be affected by compiler padding, but in practice all compilers do the same thing with the relevant structures... > The reason for having two protocols is not pure randomness. The > original protocol was designed by someone who did not understand the > concept of machine independence as applied to network protocols; I believe the original protocol was designed by someone who was working solely on VAXen. That's close, but not quite, the same thing as someone who doesn't understand machine independence. :-) ---Dan
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: 2 Aug 91 05:08:39 GMT From: jel@xerver.data.nokia.fi (Jerry Lahti) To: comp.protocols.tcp-ip Subject: Re: TFTP block counter
swt@bwdls25.bnr.ca (Steven W. Truelove) writes: >I cannot find any reference that state whether or not the block >counter in the tftp application is a signed or unsigned integer. TFTP spec (RFC 783) says in the description of the DATA packet (section 5) that "The block numbers on data packets begin with one and increase by one for each new block of data." So presumably they are unsigned integers. However, you probably should not be even trying to transfer several megabytes of data in 512 byte blocks using a stop and wait protocol, i.e. there should be no need to worry about integer overflow. Regards, Jerry Lahti Nokia Data Systems Oy
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: 2 Aug 91 05:15:37 GMT From: dave@ips.oz.au (Dave Horsfall) To: comp.protocols.tcp-ip Subject: GATED and SLIP
We have a small network of three SUNs on an Ethernet and two more connected by SLIP links to one of the hosts. I want to make the SLIP hosts visible to the rest of the network (and vice-versa), and I know I have to use GATED, not ROUTED. Try as I might, I cannot get GATED to do the right thing. The documentation is somewhat less than lucid when talking about pointopoint links. How should the /etc/gated.conf (and /etc/gateways etc) be set up? On a related note, I want to make the SLIP hosts visible to an Annex-IIe on the network as well. Since GATED is not working, neither will the Annex, so I can't localise the problem if the Annex is misconfigured. I know the Annex will support SLIP, but for various reasons the SLIP hosts have to hang off one of the other hosts. If it matters, the SUNs are running 4.0.3 & 4.1, and the Annex 6.0.2. -- Dave Horsfall (VK2KFU) VK2KFU @ VK2RWI.NSW.AUS.OC dave@ips.OZ.AU ...munnari!ips.OZ.AU!dave
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: 2 Aug 91 06:24:12 GMT From: craig@sics.se (Craig Partridge) To: comp.protocols.tcp-ip,comp.unix.internals Subject: Re: question about BSD checksum routine error? message
In <3133@pdxgate.UUCP> jrb@jove.cs.pdx.edu (James Binkley) writes:
>In the BSD p.d. tcp/ip code, in the portable checksum routine,
>in_cksum()
>there is a line of code near the end as follows:
> if (len)
> printf("cksum: out of data\n");
>I seem to be getting this. This means logically that the mbuf
>chain is shorter than the length passed in. Is this a bug?
My recollection is yes, this means a bug somewhere. The input
code for both IP and ARP checks to make sure that the amount of data
passed to them is consistent with the protocol lengths (there are cases
where interface hardware can fail and provide partial packets -- that's
why the code checks the lengths). So one shouldn't hit the IP checksum
routine without some assurance that there's enough data to feed the
checksummer.
Craig Partridge
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: 2 Aug 91 12:55:38 GMT From: PIRARD@VM1.ULG.AC.BE (Andr'e PIRARD) To: comp.protocols.tcp-ip Subject: Re: Ftp, Tcp/Ip
On Mon, 8 Jul 91 09:14:46 -0400 you said: >Ours isn't available as shareware. At the moment, our Windows support is >only for 386 Extended mode: a VxD/DLL which allows use of our applications >in multiple DOS boxes, and developement of WinApps. And what about the same for DESQview (and DV/X)? (Like Novell told us :-) Andr'e PIRARD SEGI, Univ. de Li`ege 139.165 IP coordinator B26 - Sart Tilman B-4000 Li`ege 1 (Belgium) +32 (41) 564932 pirard@vm1.ulg.ac.be alias PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: 2 Aug 91 14:12:03 GMT From: SSJACK%ECUVM1@NCSUVM.CC.NCSU.EDU To: comp.protocols.tcp-ip Subject: VAX TCP/IP Recommendations
We are seeking software recommendations for a TCP/IP package to run on a VAX 4000 running VMS 5.4. Please send your comments or suggestions regarding your experience with CMU-TCP, Multinet, or another solid package. Thanks in advance for your help. ====================================================================== Jack E. McCoy SSJACK@ECUVM1.BITNET Systems Programmer (919) 757 - 6401 East Carolina University Greenville, NC 27858 ======================================================================
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: 2 Aug 91 15:37:02 GMT From: henry@zoo.toronto.edu (Henry Spencer) To: comp.protocols.tcp-ip Subject: Re: TFTP block counter
In article <jel.681109719@xerver.data.nokia.fi> jel@xerver.data.nokia.fi (Jerry Lahti) writes: >So presumably they are unsigned integers. However, you probably should >not be even trying to transfer several megabytes of data in 512 byte blocks >using a stop and wait protocol... Unfortunately, one of the main uses for TFTP is bootstrapping, and multi- megabyte kernels are getting all too common... -- Arthritic bureaucracies don't tame new | Henry Spencer @ U of Toronto Zoology frontiers. -Paul A. Gigot, WSJ, on NASA | henry@zoo.toronto.edu utzoo!henry
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: 2 Aug 91 16:21:23 GMT From: ddl@husc6.harvard.edu (Dan Lanciani) To: comp.mail.misc,comp.protocols.tcp-ip,comp.unix.misc,comp.unix.wizards Subject: Re: TALK (Unix-to-Unix, Unix-to-VMS)
In article <8926.Aug202.41.5691@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: | In article <1991Aug1.072405.13249@thunder.mcrcim.mcgill.edu> mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes: | > Part of this confusion is probably arising because there are two talk | > protocols, not one. | | It's more accurate to say that there are three in wide use: 4.3, 4.2 | with big-endian, 4.2 with little-endian. None of the three is compatible | with any other. This isn't quite true. For some time, the 4.2 versions for the Sun 2/3 and the Vax have had code that attempts to handle messages from a foreign machine. Generally, they look at the sin_family field of a socket address and try to decide from that whether the structure should be "fixed up." There are several problems with this. One is simply that not everyone got the code "right." Sun's later versions have it "right" but Ultrix seems to get confused. Another problem is that the examined sin_family field overlays the id number field thus it can happen to have the "wrong" value and spoof the check. This can cause great confusion: "The first time I talk it works but the second time it doesn't." | Of course, if someone has 4.2 talk running on a PDP, | that's a fourth protocol. I did but I made it look like a Vax... | The 4.2 protocol can also be affected by | compiler padding, but in practice all compilers do the same thing with | the relevant structures... No, in fact, the Sun 2/3 and Vax compilers generate different structure sizes for the 4.2 talk response message. This happens because the Vax's compiler aligns a long/int "id_num" on a 32-bit boundary while the Sun's does not. [Sun 4 is another story.] Dan Lanciani ddl@harvard.*
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: 2 Aug 91 17:19:32 GMT From: dmicka@MAINZ-EMH2.ARMY.MIL (David A Micka) To: comp.protocols.tcp-ip Subject: Re: DDN error message
Bob, Following are the host addresses for backed up mail and fragments from the ddn error logs. The logs are kept in /usr/net and are - errlog.cur and errlog.pre. David 128.112.129.99 PUCC.PRINCETON.EDU 134.129.111.1 VM1.NODAK.EDU 129.29.199.2 WESTPOINT-EMH2.ARMY.MIL 35.1.1.42 MERIT.EDU 143.78.1.2 ODS-HOST11.ARMY.MIL ++++++++++++++++++++++++++++ errlog.cur ++++++++++++++++++++++++++++++++++++++++ Fri Aug 2 09:42:47 1991: intermed: PK_REJECT chan 12 Fri Aug 2 09:42:50 1991: intermed: PK_REJECT chan 12 Fri Aug 2 09:42:52 1991: session: ERROR: Remote no response after rtxed 15 times in (CLOSING) on tyx:0 Fri Aug 2 09:42:52 1991: session: forced close tyx:0 and tcp chan 0. Fri Aug 2 09:42:52 1991: session: ERROR 29 (CLOSED) Fri Aug 2 09:43:08 1991: intermed: PK_REJECT chan 14 Fri Aug 2 09:43:13 1991: session:tcpeval Opening state receive event 29 Fri Aug 2 09:43:13 1991: intermed: PK_REJECT chan 14 Fri Aug 2 09:43:13 1991: intermed: PK_REJECT chan 14 Fri Aug 2 09:43:23 1991: session:tcpeval Opening state receive event 29 Fri Aug 2 09:43:46 1991: intermed: PK_REJECT chan 14 Fri Aug 2 09:43:53 1991: session: ERROR: Remote no response after rtxed 15 times in (CLOSING) on tyx:0 Fri Aug 2 09:43:53 1991: session: forced close tyx:0 and tcp chan 0. Fri Aug 2 09:43:53 1991: session: ERROR 29 (CLOSED) Fri Aug 2 09:44:24 1991: session:tcpeval Opening state receive event 29 Fri Aug 2 09:44:54 1991: session: ERROR: Remote no response after rtxed 15 times in (CLOSING) on tyx:0 Fri Aug 2 09:44:54 1991: session: forced close tyx:0 and tcp chan 0. Fri Aug 2 09:44:54 1991: session: ERROR 29 (CLOSED) Fri Aug 2 09:45:20 1991: intermediate: time out. index = 10, real ch# = 3. send msg Fri Aug 2 09:45:25 1991: session:tcpeval Opening state receive event 29 Fri Aug 2 09:42:41 1991: intermed: PK_REJECT chan 12 Fri Aug 2 09:42:43 1991: intermed: PK_REJECT chan 12 Fri Aug 2 09:42:43 1991: session:tcpeval Opening state receive event 29 Fri Aug 2 09:42:44 1991: intermed: PK_REJECT chan 12 Fri Aug 2 09:42:45 1991: intermed: PK_REJECT chan 12 +++++++++++++++++++++ End of errlog.cur +++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++ errlog.pre ++++++++++++++++++++++++++++++++++++ Fri Aug 2 06:11:08 1991: intermed: PK_REJECT chan 5 Fri Aug 2 06:11:10 1991: intermed: PK_REJECT chan 5 Fri Aug 2 06:11:10 1991: intermed: PK_REJECT chan 5 Fri Aug 2 06:11:10 1991: intermed: PK_REJECT: channel not S_OPENING! Fri Aug 2 06:11:12 1991: intermed: PK_REJECT chan 5 Fri Aug 2 06:11:12 1991: intermed: PK_REJECT chan 5 Fri Aug 2 06:11:12 1991: intermed: PK_REJECT: channel not S_OPENING! Fri Aug 2 06:11:12 1991: session: ERROR: Remote no response after rtxed 15 times in (CLOSING) on tyx:0 Fri Aug 2 06:11:12 1991: session: forced close tyx:0 and tcp chan 0. Fri Aug 2 06:11:12 1991: session: ERROR 29 (CLOSED) Fri Aug 2 06:11:12 1991: session:tcpeval Opening state receive event 29 Fri Aug 2 06:11:13 1991: intermed: PK_REJECT chan 5 Fri Aug 2 06:11:14 1991: intermed: PK_REJECT chan 5 Fri Aug 2 06:11:14 1991: intermed: PK_REJECT chan 5 Fri Aug 2 06:11:15 1991: intermed: PK_REJECT chan 5 Fri Aug 2 06:11:16 1991: intermed: PK_REJECT chan 5 Fri Aug 2 06:11:16 1991: intermed: PK_REJECT chan 5 Fri Aug 2 06:11:17 1991: intermediate: time out. index = 2, real ch# = 1. send msg Fri Aug 2 06:11:17 1991: intermed: PK_REJECT chan 5 Fri Aug 2 06:11:19 1991: intermed: PK_REJECT chan 5 Fri Aug 2 06:11:21 1991: intermed: PK_REJECT chan 5 Fri Aug 2 06:11:22 1991: intermed: PK_REJECT chan 5 Fri Aug 2 06:11:31 1991: intermed: PK_REJECT chan 7 Fri Aug 2 06:11:42 1991: session:tcpeval Opening state receive event 29 Fri Aug 2 06:11:42 1991: intermed: PK_REJECT chan 7 Fri Aug 2 06:11:43 1991: intermed: PK_REJECT chan 2 Fri Aug 2 06:11:43 1991: intermed: PK_REJECT: channel not S_OPENING! Fri Aug 2 06:11:43 1991: session:tcpeval Opening state receive event 29 Fri Aug 2 04:57:17 1991: session: ERROR: Remote no response after rtxed 15 times in (CLOSING) on tyx:0 +++++++++++++++++++++++++++++ End of errlog.pre+++++++++++++++++++++++++++++++++
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: 2 Aug 91 17:43:02 GMT From: jbvb@FTP.COM (James B. Van Bokkelen) To: comp.protocols.tcp-ip Subject: Re: TCP Urgent data
My personal taste in this matter is not to provide notification of things I can't be sure of delivering to the application, which means that I wouldn't notify of Urgent until data up to the pointer is in hand. I realize this offers less functionality than notification when the URG bit is first received, but I think the world will be better off overall if the application doesn't have to cope with an EOF or reset connection error while it's in Urgent mode. Perhaps I'm not giving the application developers enough credit here, but I've seen an awful lot of people assume malloc() can never fail... James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: 2 Aug 91 18:07:46 GMT From: mta@toro.MTS.ML.COM (Michael Askew) To: comp.protocols.tcp-ip Subject: Reliable Datagram Service
Can anybody tell me anything about the following: ISIS V3.x Camelot VMTP Answers by e-mail please, thanks .............Mike :) Mike Askew | Merrill Lynch & Co., Inc. (212) 236-3181 | Municipal Analytics & Systems., 15th Floor., mta@toro.mts.ml.com | World Financial Center, South Tower, uunet!toro!mta | New York., New York., 10080-6115., USA
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: 2 Aug 91 21:43:15 GMT From: l1ngo@copper.denver.colorado.edu (l1ngo) To: comp.protocols.tcp-ip,rec.games.mud Subject: FIN_WAIT_1 and Copper Diku
I run a DikuMud and I'm having some problems. After I shutdown the mud, most connections TIME_WAIT and die. Now and then, I get a FIN_WAIT_1 which will not die. The mud needs to bind tcp/ip port 4000 and cannot do so with FIN_WAIT_1 hanging around. Anyone know how I can kill the connection? Last time it happened, it prevented the mud from going up on port 4000 for over 24 hours. Copper Diku is running off port 4001 temporarily, by the way. Thanks for any help, Lin ----------------------------------------------------------------------------- Copper.Denver.Colorado.Edu 4000 // Mud till you drop... -----------------------------------------------------------------------------
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: 2 Aug 91 23:50:56 GMT From: rleeson@relay.nswc.navy.mil (Robert Leeson) To: comp.protocols.tcp-ip Subject: Remote Sensing of Conditions at Network Distribution Sites
Before I go out and "re-invent a wheel" (which might be "fun" in this case), does anyone know of a device that would permit the temperature, humidity, and the like at remote distribution points (wiring closets, comm. shacks, etc) be monitored and then reported to a central location using the network cabling. If there is an off-the-shelf device it would probably be cheaper than a "roll your own" solution. Our network is distributed through several buildings, some seperated by miles of fiber. And many of the distrution points are seldom visited except when there is a failure. (In many cases the failure of a cooling system is reported by the failure of the equipment it was intended to protect.) Thanks for your help --- Rob Leeson Internet: rleeson@relay.nswc.navy.mil Phone: 703-663-7745 Autovon: 249-7745 FAX: 703-663-1952 Mail: Robert Leeson, Naval Surface Warfare Center, Code E41 Dahlgren, Virginia 22448-5000
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: 3 Aug 91 12:08:13 GMT From: merdian@rus.uni-stuttgart.dbp.DE (Peter Merdian) To: comp.protocols.tcp-ip Subject: NFS and UID mapping
We have in Baden-Wuerrtemberg (a federal state of Germany) a science network (called BelWue) that connects the universities and colleges. The problem is, that the UIDs used in the different organisations are not coordinated and we will experience conflicts if we mount hosts via NFS over BelWue. One solution would be a UID mapping facility for NFS mounts. Another solution would be reassigning all the UIDs of the BelWue organisations (which is hardly possible). Is there another solution? Do I miss something obvious? I have heard that Cray will provide a UID mapping in the near future. Are there plans for UID mapping of other workstation companies? Peter Merdian, BelWue-coordination, university of stuttgart merdian@rus.uni-stuttgart.dbp.de, merdian@belwue.de
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: 3 Aug 91 12:53:16 GMT From: sfrazier@mcinix.vlink.COM (Steven E. Frazier) To: comp.unix.questions,comp.protocols.tcp-ip Subject: ppp vs slip
What is the difference between PPP and SLIP. I understand that PPP is suppose to be much better, in what ways? If you are calling a site using SLIP, can you change to PPP without the other end changing? I understand Morningstar makes a PPP package which I received some information on, but I still am not clear on the differences, advantages, and useage, could someone help me out? Thanks. Steve -- Steven E. Frazier DID: (614) 761-6612 VNET: 424-6612 FAX: (614) 761-6679
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: 3 Aug 91 17:39:26 GMT From: jcurran@SH.CS.NET (John Curran) To: comp.protocols.tcp-ip Subject: Re: ARP
> From: Stephen B Kutzer <COTRCSBK@sea04vm.navsea.navy.mil> > > My reading of Comer's book and RFC826 make me believe that ARP will > work independently of Internet addresses. A friend of mine tells me > I am wrong. I am waiting for maintenance time to play with it and thought > I'd ask this question in the meantime. > > If I have the following network: > ... > It looks like you could, and ARP would bind the Ethernet address to the > Internet address. My friend says no, that ARP will only occur for Internet > address within a given host's network. Therefore to go from one to the other > you need a gateway that has addresses in both networks. ARP would handle this case, *but* ARP nevers sees this packet. IP processing first uses the destination address to determine the correct interface to use for delivery. Since the destination address is on a network not connected to our host, there must exist a route in the routing table to that network or the packet is dropped (network unreachable). IP processing in most hosts does not yet support the concept of multiple logical networks on a physical network, but it is common in routers and many people are working on a standard way of handling it. >It seems wasteful to add the router hop and processing. Is it an >implementation issue or am I just missing something inherent to ARP? IP knows better, and won't even try delivery. ARP can't help when it's not called. A good explanation of the combined IP routing algorithm can also be found in Comer. /John
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: 3 Aug 91 18:53:40 GMT From: jdavis@noao.edu (Jim Davis) To: comp.protocols.tcp-ip Subject: Re: OSPF Information
In article <9107121837.AA00840@bart.> eli@bart.UUCP (Eli Blumenthal) writes: > >uunet!mcsun!news.funet.fi!kannel!saruman.it.lut.fi!larry (Lauri >Toropainen) writes: > >> Another silly question: how to change directory during a ftp session at >> NIC.DDN.MIL? The CD command only results to an error message. DDN NIC >> seems to be a VMS host, so this may be the reason. > >Directories in VMS are specified as follows: [... nice VMS ftp tutorial omitted ...] Actually it's a DEC-20. Here's a transcript of fetching the RFC index from a UNIX box. Note the "cd rfc:", with a colon; also note that the scary-sounding "Default name accepted. Send password to connect to it." message can be ignored. $ ftp nic.ddn.mil Connected to nic.ddn.mil. 220 NIC.DDN.MIL FTP Server Process 5Z(47)-6 at Sat 3-Aug-91 11:40-PDT Name (nic.ddn.mil:jdavis): anonymous 331 ANONYMOUS user ok, send real ident as password. Password: 230 User ANONYMOUS logged in at Sat 3-Aug-91 11:40-PDT, job 21. ftp> cd rfc: 331 Default name accepted. Send password to connect to it. ftp> dir rfc-index.txt 200 Port 18.24 at host 140.252.1.54 accepted. 150 List started. RFC-INDEX.TXT.1243;P777752;AREF,61,10-Jul-91 10:01:56,10-Jul-91 10:01:57, 3-Aug-91 06:36:22 226 Transfer completed. remote: rfc-index.txt 93 bytes received in 0.01 seconds (9.1 Kbytes/s) ftp> get rfc-index.txt 200 Port 18.25 at host 140.252.1.54 accepted. 150 ASCII retrieve of TS:<RFC>RFC-INDEX.TXT.1243 (61 pages) started. 226 Transfer completed. 155304 (8) bytes transferred. local: rfc-index.txt remote: rfc-index.txt 155304 bytes received in 8.9 seconds (17 Kbytes/s) ftp> quit 221 QUIT command received. Goodbye. $ ls rfc-index.txt rfc-index.txt
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: 4 Aug 91 19:59:28 GMT From: bob@MorningStar.Com (Bob Sutterfield) To: comp.unix.questions,comp.protocols.tcp-ip Subject: Re: ppp vs slip
In article <23@mcinix.vlink.COM> sfrazier@mcinix.vlink.COM (Steven E. Frazier) writes: What is the difference between PPP and SLIP. The first thing you'll notice is that their RFCs are numbered differently - 1055 vs 1171 :-) Also, while SLIP describes itself as a "non-standard", PPP is the product of the Internet Engineering Task Force PPP Working Group and is on track to being a "blessed" Internet Standard. Read the RFCs for a description of their respective protocols. SLIP is a starkly minimalist approach, only suggesting what byte to prepend and perhaps append to each frame sent across the wire. PPP addresses a lot of other issues too. I understand that PPP is suppose to be much better, in what ways? Read the Deficiencies section of RFC-1055 and the Introduction of RFC-1171 for a definitive discussion. SLIP was a "first cut", from which the IETF PPP Working Group learned plenty. PPP is a more general solution to the problem. The most obvious differences that I can think of off the top of my head: PPP incorporates FCS error checking. SLIP expects higher levels of the protocol stack to worry about that sort of stuff. PPP allows different implementations to agree on a set of mutually-acceptable features (what protocol family to carry, various compression techniques, frame size (MTU/MRU), addresses of both ends, etc.) at connection time. SLIP only carries IP, needs to know in advance whether to use TCP header compression and what frame size to use, and needs to know in advance what addresses are at each end of the link. PPP can negotiate a truly huge frame size, though a MTU of 1500 seems to be a common compromise between batch throughput and interactive responsiveness. SLIP can send any size that both implementations can support, and while the RFC suggests 1006, many (most?) use 256. PPP can be used in either asynchronous or synchronous environments. It has become the standard protocol for high-speed routers to talk over leased lines, at speeds up to T1. This allows people to build networks using routers from different vendors, and expect them to all work together. If you are calling a site using SLIP, can you change to PPP without the other end changing? No, the two use different framing techniques. PPP is not upward compatible from SLIP, though some hosts or routers may contain implementations of both.
-----------[000038][next][prev][last][first]----------------------------------------------------
Date: 4 Aug 91 20:09:11 GMT
From: DUCKY@ACADVM1.UOTTAWA.CA ("Richard V. Janke")
To: comp.protocols.tcp-ip
Subject: Internet SocietyI would like to learn more about the Internet Society. Please e-mail me re. this. Thanks.
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: 4 Aug 91 22:04:23 GMT From: CCMARK@UMCVMB.MISSOURI.EDU (Mark Moody) To: comp.protocols.tcp-ip Subject: 3270 to vt100
Greetings, I am looking for ways to allow our IBM mainframes on MOREnet to emulate vt100 terminals from 3270 devices. Most of our machines run VM/CMS but there are MVS systems as well. We are familiar with the products offered by A-Net, however they are cost prohibitive at this time. Does anyone else know of any other solutions? any help would be appreciated, and I will post a summary if warranted. Mark Moody MOREnet - MissOuri Research and Educational network University of Missouri - Columbia CCMARK@umcvmb.missouri.edu (preferred) mark@noc.missouri.edu (alternate)
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 91 10:46:53 GMT From: koerber.sin@sni.de (Mathias Koerber) To: comp.protocols.tcp-ip Subject: Network Traffic Analyzer?
I'm looking for a PD (or freeware) network traffic anayzer program, which runs on either SysV or BSD, and recognizes TCP/IP as well non-TCP/IP packets (OSI, whatever). It should deliver a breakdown of traffic generated by host (user) and maybe time... Is there any such thing ? Oh yeah, something on PC would also work... Thx, Mathias Mathias Koerber | S iemens | EUnet: koerber.sin@sni.de 2 Kallang Sector | N ixdorf | USA: koerber.sin@sni-usa.com S'pore 1344 | I nformation Systems | Tel: +65/7402852 | Fax: +65/7402834 "Don't be humble, you're not that great" - Golda Meir | #include <disclaimer.h>
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 91 11:35:59 GMT From: mni@CRAYAMID.CRAY.COM (Michael Nittmann) To: comp.protocols.tcp-ip Subject: Re: Sub standard FTP implementation
on my opinion an implementation must always be complete. give back an error if there is a request to write into a read only object (card reader would then be like a read only file). michael
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 91 15:08:07 GMT From: solensky@ANIMAL.CLEARPOINT.COM (Frank T. Solensky) To: comp.protocols.tcp-ip Subject: Re: ARP
Steve -- >If I have the following network: > >144.11.100.1 140.195.203.1 >(mask FFFFFF00) (mask FFFFFF00) > | | >--------------------------------------------------- > Common Ethernet >--------------------------------------------------- > >can I configure each host so that the other is a local delivery? I imagine that you might be able to, but it wouldn't be advisable. The example you include uses two IP addresses that are, by definition, on different nets or subnets. The normal case would be to assign IP addresses out of the same network or subnet number on the common ethernet, then to use a router in the same net to talk to "everything else". -- Frank Solensky / Clearpoint Research Red Sox magic number -- 67
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 91 15:37:45 GMT From: jbvb@FTP.COM (James B. Van Bokkelen) To: comp.protocols.tcp-ip Subject: Re: TCP Urgent data
>The TCP ...
> ... isn't supposed to pass data up until it has been ACKed,
There is no such requirement. Delayed ACKs exist in many implementations,
for good reasons and with good results.
I should have said 'can be ACKed'. I've voiced other opinions about TCP APIs
in a reply to Chrlie Lynn.
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 91 16:16:45 GMT From: pozar@kumr.lns.com (Tim Pozar) To: comp.protocols.tcp-ip Subject: Re: IP routing over ISDN.
In article <1991Aug1.215048.12396@jrd.dec.com> rikitake@jrd.dec.com writes:
>] Do any products exist that provide IP routing directly onto
>] ISDN ?
>
>You can attach ISDN boards for Sony NEWS workstations. I've heard several
>people doing IP networking on it. The board is intelligent so you need not to
>have TA.
Hayes makes a modem that will plug into ISDN. I have been itching
to plug one in and run slip through it. Unfortunatly, where I want
to pass IP from and to, do not have switches that support ISDN. Pac
Bell sez "At least two years off". :-(
Tim
--
pozar@lns.com Fido: 1:125/555 PaBell: 415-788-3904
USNail: KKSF-FM / 77 Maiden Lane / San Francisco CA 94108
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 91 16:50:44 GMT From: NIC@NIC.DDN.MIL (DDN Reference) To: comp.protocols.tcp-ip Subject: Vendors Beware: Hop count and IP Internet "diameter"
The IP Internet has continued to grow at an amazing rate. This has uncovered problems with vendor software that does not follow the guidelines in RFC 1122 for the time to live (TTL) field. The problem manifests as failure of email due to a TTL of only 15. Now, TTL is defined as a unit of time in seconds, but handled in gateways as a hop count. The assigned numbers RFC currently recommends the value 32. It is also required to be configurable. The IP Internet user community depends upon software vendors to provide enough flexibility to allow for continued growth of the networks we are attached to, and to allow for this growth in the software we as users are applying in our day to day jobs. Thank you for taking a moment to review your current software parameters, and insuring that they provide the maximum in flexibility at the users site. Steven ...for the DDN NIC -------
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 91 17:22:46 GMT From: gmc@PREMISES1.QUOTRON.COM (Greg Christy) To: comp.protocols.tcp-ip Subject: Routing question (between TCP/IP and dedicated SLIP links)
In this situation I would recommend using static routes as there is only one way to get to the Stride. On each of your SVR3 machines add host routes to the rc file which starts the net: route add host stride_name 3/50_name 1 where stride_name and 3/50_name are the hostnames you have assigned to these machines. Likewise add routes to the SVR3 machines on the Stride using the 3/50 as a gateway. Make sure that you use the address of the 3/50 side of the slip link. You can use 'netstat -in' and look at the net/dest column to find the address. Greg
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 91 17:50:26 GMT From: rmurthi@cpqhou.uucp (@Strat Mkt) To: comp.unix.questions,comp.protocols.tcp-ip Subject: FTP sites for RFP's
in article <BOB.91Aug4155922@remora.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) says: > > In article <23@mcinix.vlink.COM> sfrazier@mcinix.vlink.COM (Steven E. Frazier) writes: > What is the difference between PPP and SLIP. > > The first thing you'll notice is that their RFCs are numbered > differently - 1055 vs 1171 :-) Also, while SLIP describes itself as a > "non-standard", PPP is the product of the Internet Engineering Task Is there any sites where these RFC's are stored? Anonymous FTP sites of course. Thanks in advance for the Info..... Raghu rmurthi@cpqhou.se.compaq.com -------------------------------------------------------------- Standard Disclaimer
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 91 18:52:25 GMT From: PADLIPSKY@A.ISI.EDU (Michael Padlipsky) To: comp.protocols.tcp-ip Subject: Re: Sub standard FTP implementation
Alex-- It's actually been closer to 20 years than to 15, but still and all I'm quite confident that my EarlyMiddleAged Memory is in better (well, make that less bad) shape than yours on this one. Even though I don't believe it ever saw the dark of print in any of the RFCs, I'm certain that the "from a keypunch, to a lineprinter" (or even "from a cardreader, to a cardpunch (and interpreter)") metaphor was not from FTP, it was from Telnet, and was my own catchphrase for how a Network Virtual Terminal COULD be instantiated, for all the protocol "cared". Of course, there's no particular reason in the abstract for you to believe that my EMAM actually is functioning better than your EMAM even on this one, but in practice I believe I can prove you're wrong, which at least lends a bit of credence to the conviction I'm right. For, you see, as far back as the August, 1973 version of the FTP spec, there HAS been a "minimum implementation" listed (RFC 542, p.27, and still findable in the original issue (NCP-based) ARPANET Protocol Handbook, which I never had the heart to throw out; unfortuantely, the version of Telnet in it doesn't offer direct confirmation of my theory, at least to my EMA eyesight). Actually, that should be "at least as far back" as RFC 542, since I didn't bother to try to find any of the earlier versions. Now, maybe the minimum implementation got left out of one iteration or another of the spec, since I find them a lot harder to lay my hands on than the '73 one, but I don't think it did, especially since at least one other respondent kindly pointed out which page in the latest RFC the original poster on this thread had overlooked. So it does seem you're trying to account for a non-phenomenon--unless, of course, I unsuccessfully tried to apply my pet NVT principle to FTP at one of the meetings and that's what you're remembering.... antiquarian (but not, one hopes, antiquated) cheers, map P.S. Protocol archaeologists might be amused to learn that one interesting widget that did inadvertantly get left out from one version of a spec to the next was the "Logger" concept of Telnet. Myself, I'm more amused that even without the explanation of what was supposed to be on the other end of the Telnet Well-Known Socket in the spec, almost everybody did something quite like the right thing anyway: seems that all those intervening years of practice reading unixtm manuals must have trained people to furnish and/or invent needed context, after all (though maybe it was just that they were only iterating preceding implementations, which were already in the right place). -------
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 91 19:28:02 GMT From: postel@ISI.EDU To: comp.protocols.tcp-ip Subject: Re: Sub standard FTP implementation
Hi. The "minimum implementation" command set is listed on page 43 of RFC-959. --jon.
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 91 19:52:54 GMT From: finnegan@viewlogic.com (David Finnegan) To: comp.protocols.tcp-ip Subject: Connected Udp socket question
I am having some trouble with 'connected' Udp sockets using the
local interface on a DEC Station 3100.
If the server end of a connected Udp socket is unreachable
(closed, for example) then a 'connection refused' error is
generated on the next system call to the client socket after a
write is performed.
This behavior is what I expect.
What I don't expect is that other processes, on the same machine,
with local Udp connected sockets also get the connection refused
error.
An example:
I've created three processes: snd, srv and rcv.
snd reads stdin and writes a connected socket to a srv
process.
srv reads a connected socket, writes the data to its stdout
and then writes the data to another connected socket.
rcv reads a connected socket and writes the data to its
stdout.
Each process checks for and displays any error detected when
writing their respective sockets.
If I chain a snd, multiple srv's and a receive together as
follows:
__ snd_sock
| __ srv1_sock1
| | __ srv1_sock2
| | | __ srv2_sock1
| | | | __ srv2_sock2
| | | | | __ srv3_sock1
| | | | | | __ srv3_sock2
| | | | | | | __ rcv_sock
v v v v v v v v
snd --> srv1 --> srv2 --> srv3 --> rcv
such that snd_sock is a Udp 'connected' socket to srv1_sock1,
srv1_sock2 is a Udp 'connected' socket to srv2_sock1, ... and
srv3_sock2 is a Udp 'connected' socket to rcv_sock then I
observe the following behavior:
A character (1) typed in to snd is displayed on the stdout
of each srv? process and the rcv process.
After terminating the rcv process, a character (2) typed
in to snd is displayed on the stdout of each srv? process.
A character (3) typed in to snd results in a connection
refused error displayed on the stdout of the snd process
and no other process receives the character.
A character (4) typed in to snd is displayed on the stdout
of srv1 and a connection refused error is also displayed
on the stdout of srv1. No other process receives the
character.
A character (5) typed in to snd is displayed on the stdout
of srv1 and srv2, a connection refused error is displayed
on the stdout of srv2 and no other process receives the
character.
A character (6) typed in to snd is displayed on the stdout
of srv1, srv2 and srv3 and an connection refused error is
displayed on the stdout of srv3. No other process
receives the character (rcv has been killed!).
Finally, a character (7) typed in to snd is displayed on
the stdout of all srv? processes. No other output is
observed.
If more characters are entered to snd the above process is
repeated starting with character (4).
To summarize:
char snd srv1 srv2 srv3 rcv
1 1 1 1 1 1
kill the rcv process
2 2 2 2 2
3 3 CR
4 4 4 CR
5 5 5 5 CR
6 6 6 6 6 CR
7 7 7 7 7
8 8 CR
...
where CR denotes connection refused error
It appears, at least to me, that once the rcv process has been
killed an attempt to send a character to it generates a connection
refused error for each (and every) process with a locally
connected Udp socket. Each process 'trips' the error by trying to
send on their connected client socket. Once the final process in
the chain has 'tripped' their error the process starts over again
by generating another error with an attempted send to the
nonexistent rcv socket.
What I would expect to see is a single connection refused error
displayed by the last srv process in the chain on every other
character generated by snd. This, in fact, is what I see on a
Sparc Station running the same code.
Furthermore, the erroneous connection refused errors (at least in
my opinion) only appear to present themselves to locally,
connected sockets. That is, if I run srv2, srv3 and rcv on a remote
machine then the connection refused errors only propogate through
srv2 and srv3. Neither snd nor srv1 ever see a connection refused
error.
Even more suprisingly, if I start a second chain of snd, srv and
rcv processes as another user and then start up the orignal
example, processes in the second chain all receive the connection
refused errors along with the upstream processes on the test set.
I.e. the same chain of connection refused errors is generated in
the second chain after each attempt to write to the nonexistent
process in the first chain!
My question (albeit long winded) is this: is this really a bug in
the DS3100 Tcp/Ip code or am I misinterpreting the results?
If this is a bug, is there a patch or preferred workaround?
Or, at least, has anyone else observed this behavior?
[I've declined to post sources, but could provide some if
necessary]
Thanks in advance for any information.
David
Internet: dfinnegan@viewlogic.com
US Mail: David M Finnegan
Viewlogic Systems, Inc.
293 Boston Post Rd West
Marlboro, MA 01752-4615
508 480 0881
--
David M Finnegan
Internet: dfinnegan@viewlogic.com
US Mail: Viewlogic Systems, Inc.
293 Boston Post Rd West
Marlboro, MA 01752-4615
508 480 0881
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 91 21:12:22 GMT From: rah@sppy00.UUCP (MOORE ROBIN) To: comp.protocols.tcp-ip Subject: TN term type
Could someone answer a question for me about RFC 1091 (the Telnet
Terminal-Type Option)?
We have an IBM 3090 running version 1 of IBM's TCP/IP software for
that system. It understands two terminal types: 3270 and Drop Dead
Stupid.
When someone tries to come into our system from a Vax somewhere out
in the Internet, the Vax issues the command "WILL OPTION TERMINAL TYPE".
The IBM responds with "DO OPTION TERMINAL TYPE". Then it gets hairy.
The IBM transmits the "SEND" subnegotiation, and the Vax responds
that it "IS VT102". The IBM, naturally, was hoping for a 3270 and
transmits "SEND" again. The Vax is apparently set up to only support
one terminal type, so it responds "IS VT102" again. This concludes
the terminal type negotiation; things seem to work pretty well from
then on simply because the application on the IBM does not use
any glitzy terminal features at all.
From my reading of the RFC, the Vax has acted correctly by cycling
through its "list" of options until the server system selects the one
it likes best. The Vax believes it has been granted VT102 type access.
Also, it seems the IBM has no way to go back and say "I don't like
your list -- you should realize you're not getting a VT102." It just
has to do its best with the least unpleasant option presented to it.
Have I missed something here, or is this really as good as it gets?
Thanks in advance for any help you can provide.
Robin H-M
--
{ Robin A. Hermance-Moore % OCLC Inc. }
{ sppy00!rah@cis.ohio-state.edu <== 1st %%% %%% %% %%%%% 6565 Frantz Road }
{ OR: rah@rsch.oclc.org <== 2nd % % % % % % Dublin, OH 43017 }
{ OCLC => "Services for Libraries" % % % % % % (614) 764-6215 }
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 91 21:48:36 GMT From: mmm@well.UUCP (Michael Hidalgo) To: comp.protocols.tcp-ip Subject: unsubscribe
please remove my name from the mailing list. thank you, Michael Hidalgo
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 91 21:50:43 GMT From: mmm@well.UUCP (Michael Hidalgo) To: comp.protocols.tcp-ip Subject: unsubscribe
Please unsubscribe me from the mailing list. Thank you. Michael Hidalgo
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 91 23:47:05 GMT From: rwmira01@ulkyvx.bitnet (Rob Miracle) To: comp.mail.misc,comp.mail.sendmail,comp.protocols.tcp-ip Subject: Followup: WIN/386 Sendmail problems
I would like to thank those that responded to my query and those who followed
up to the news groups.
The consensus was that I did not have sendmail configured to know who it was.
This was in part true. I had it configured properly, however, I failed to
restart sendmail so that it would reparse the .cf file (slap slap punch
uppercut).
It's always something.
--
Rob Miracle | Bitnet : RWMIRA01@ULKYVX CIS: 74216,3134
Programmer/Analyst-III | INTERNET : rwmira01%ulkyvx.bitnet@cunyvm.cuny.edu
University of Louisville | UUCP : ...ukma!ulkyvx.bitnet!rwmira01
"Revenge is a dish best served cold. It is very cold in space"
-- Ancient Klingon Proverb
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: 6 Aug 91 07:00:55 GMT From: mni@CRAYAMID.CRAY.COM (Michael Nittmann) To: comp.protocols.tcp-ip Subject: Re: TFTP block counter
just a comment: the problem is probably not Mbytes, but the question of 32kB or (unsigned, one more bit) 64kB blocks buffered on a 16 bit machine. There is a problem then. I would be careful and be prepared to handle 64kB incoming buffered but send only out max 32kB. michael
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: 6 Aug 91 13:08:21 GMT From: tvf@cci632.cci.com (Tom Frauenhofer) To: comp.protocols.tcp-ip Subject: UUCP versus FTP
I'm interested in any performance comparisons that have been done between
UUCP and FTP file transfer rates over various network configurations
(especially over Ethernet-based systems). If anyone can send me papers or
point me to the literature I would be most appreciative.
Thanks in advance.
--
Thomas V. Frauenhofer, WA2YYW, tvf@cci.com | "The most depressing part
{uupsi,ccicpg}!cci632!tvf@uunet.uu.net | of USENET is that it's
tvf@frau.UUCP | mostly inhabited by people
tvf1477@ma.cs.rit.edu | who think negative." - me
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: 6 Aug 91 13:19:37 GMT From: utterbac@husc9.harvard.edu (Margot Utterback) To: comp.protocols.tcp-ip,comp.dcom.lans Subject: Protocol analyzers
We are evaluating protocol analyzers. So far we will be looking at the Network General Sniffer and the Digilog LanVista 100. What we are looking for is a portable unit that can diagnose as wide a range of problems as possible. Price is a consideration but not a show stopper. Has anyone had any experience with either of these units and can advise us about them? And are we missing any other candidates? Thanks in advance. utterbac@husc.harvard.edu
-----------[000058][next][prev][last][first]----------------------------------------------------
Date: 6 Aug 91 13:32:59 GMT
From: steinkel@CARLISLE-EMH2.ARMY.MIL ("L. Steinke")
To: comp.protocols.tcp-ip
Subject: [System Administrator: TTL]>the ddnstart.sh script. Successfully delivered to most of the EDU. >Now revised the TTL to 100 to see if we reach the IT net. I am not trying to be a spoilsport here, but what are we losing by upping the TTLs to ever-higher values? I am not pretending to know (in other words, I'm guessing), but isn't there a higher probability of increased network (DDN and Internet) congestion with all these longer-lived packets running around? Leland ps: Given that the highest TTL for an IP packet is 255 (or 0, depending on when TTL is decremented, relative to testing for death), and that it would appear that for the 3B2 600G, ICMP Echo Replies start out with TTLs of 255, we might already be on the verge of a problem pps: what is the IT net?
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: 6 Aug 91 15:15:57 GMT From: brendan@cs.widener.edu (Brendan Kehoe) To: comp.protocols.tcp-ip Subject: Divine Whois
---
% whois god
Davisson, Gordon O. (GOD) gordon@JUNE.CS.WASHINGTON.EDU (206) 527-0832
Tria, Brian (BT53) god@SBCS.SUNYSB.EDU (516) 632-8751
To single out one record, look it up with "!xxx", where xxx is the
handle, shown in parenthesis following the name, which comes first.
---
Gordon's secret is out. Now you know.
--
Brendan Kehoe - Widener Sun Network Manager - brendan@cs.widener.edu
Widener University in Chester, PA A Bloody Sun-Dec War Zone
"And clever rogues with far less valid cause, have trapped their victims
in a web of laws." --- Moliere
-----------[000060][next][prev][last][first]----------------------------------------------------
Date: 6 Aug 91 15:54:46 GMT
From: CMSEDORE@mh.syr.edu ("Christopher M Sedore")
To: comp.protocols.tcp-ip
Subject: RE: NET14 redirector
OK, here is the info on the net14 redirector:
host: 129.97.128.96
directory: /pub/wattcp
filename: apps.zip
The source code is also available somewhere near the apps.zip file for those
who are interested.
Good luck!
--Chris
Christopher M Sedore
Systems Programmer
Syracuse University
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: 6 Aug 91 16:40:39 GMT From: cwk@boomer.ssc.gov (Carl W. Kalbfleisch) To: comp.protocols.tcp-ip,comp.dcom.lans Subject: Re: Protocol analyzers
>>>>> On 6 Aug 91 13:19:37 GMT, utterbac@husc9.harvard.edu (Margot Utterback) said: In article <1991Aug6.091939.2340@husc3.harvard.edu> utterbac@husc9.harvard.edu (Margot Utterback) writes: Margot> We are evaluating protocol analyzers. So far we will be looking at Margot> the Network General Sniffer and the Digilog LanVista 100. What we are Margot> looking for is a portable unit that can diagnose as wide a range of Margot> problems as possible. Price is a consideration but not a show stopper. Margot> Has anyone had any experience with either of these units and can advise Margot> us about them? And are we missing any other candidates? Margot> Thanks in advance. I contacted a number of vendors on this area recently. Since you don't say what type of LAN you are looking at, it is difficult to know which of these companies have what you want. I have listed below the companies that I contacted, as well as the products they have of interest. I understand that Novell also has a protocol analysis product, but I don't have a contact there. In no particular order (and not a complete list I'm sure of protocol analysis units). Tekelec 818-880-5656 ChameLAN 100 Cabletron Systems 603-332-9400 LANVIEW Network Analyzer Network General 415-688-2700 Sniffer Distributed Sniffer Hewlett Packard (contact a local rep) 4972A Network Advisor LAN Probe Tektronix/LP COM 800-826-8675 TC1000 TC2000 Carl -- +--------------------------------------------------------------------------+ | Carl W. Kalbfleisch cwk@psychosis.ssc.gov | | Superconducting Super Collider Laboratory | | 2550 Beckleymeade Avenue, MS-4002 | | Dallas, Texas 75237 (214) 708-3428 | +--------------------------------------------------------------------------+
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: 6 Aug 91 16:49:08 GMT From: jik@cats.ucsc.edu (Jonathan I. Kamens) To: comp.unix.questions,comp.protocols.tcp-ip Subject: Re: FTP sites for RFC's
In article <1991Aug05.175026.24412@cpqhou.uucp>, rmurthi@cpqhou.uucp (@Strat Mkt) writes: |> Is there any sites where these RFC's are stored? Anonymous FTP sites of |> course. Thanks in advance for the Info..... They're on uunet.uu.net. Also, quoting from RFC-INDEX.TXT: Many RFCs are available online; if not, this is indicated by (Not online). Paper copies of all RFCs are available from the NIC, either individually or on a subscription basis (for more information contact NIC@NIC.DDN.MIL). Online copies are available via FTP or Kermit from NIC.DDN.MIL as RFC:RFC####.TXT or RFC:RFC####.PS (#### is the RFC number without leading zeroes). Additionally, RFCs may be requested through electronic mail from the automated NIC mail server by sending a message to SERVICE@NIC.DDN.MIL with a subject line of "RFC ####" for text versions or a subject line of "RFC ####.PS" for PostScript versions. To obtain the RFC index, the subject line of your message should read "RFC index". -- Jonathan Kamens jik@CATS.UCSC.EDU
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: 6 Aug 91 18:49:42 GMT From: barmar@think.com (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: TN term type
In article <1317@sppy00.UUCP> rah@sppy00.UUCP (MOORE ROBIN) writes:
> Could someone answer a question for me about RFC 1091 (the Telnet
>Terminal-Type Option)?
...
> From my reading of the RFC, the Vax has acted correctly by cycling
>through its "list" of options until the server system selects the one
>it likes best. The Vax believes it has been granted VT102 type access.
> Also, it seems the IBM has no way to go back and say "I don't like
>your list -- you should realize you're not getting a VT102." It just
>has to do its best with the least unpleasant option presented to it.
> Have I missed something here, or is this really as good as it gets?
What does it mean for the TELNET *client* to "get" a particular terminal
type? The client is simply informing the server of what type of terminal
is attached or is being emulated. This information is purely for use by
the server.
If the server doesn't know how to do anything useful with the particular
terminal type, the situation is the same as if the terminal type
information had never been transmitted. You'd still be using a VT102, and
the IBM system wouldn't send any terminal-dependent control operations or
recognize function keys.
--
Barry Margolin, Thinking Machines Corp.
barmar@think.com
{uunet,harvard}!think!barmar
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: 6 Aug 91 19:19:39 GMT From: peter@ficc.ferranti.com (Peter da Silva) To: comp.protocols.tcp-ip Subject: Re: Sub standard FTP implementation
In article <9107312114.AA25385@ftp.com> jbvb@ftp.com writes: > RFC 1123 remedies that lack - see the section on FTP. I myself haven't > seen software that didn't implement LIST or NLST since 1987, and it was > out of date at that time. DDN1100 on the Unisys 1100 mainframes. -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: 6 Aug 91 19:56:34 GMT From: fyang@nysnet.nys.GOV (Frank Yang) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.sys.ibm.pc.misc,comp.binaries.ibm.pc.wanted Subject: X-windows/terminal software for PC <-- info needed
We need infomation on PC X-windows/teminal software. Currently we use PC Xsight, but we are looking for some other product. Any suggestion/information will be very appreciated ! Thank, Frank fyang@nysnet.ny.gov uunet!nysnet!fyang
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: 6 Aug 91 19:59:46 GMT From: RXR300G@ODUVM.BITNET To: comp.protocols.tcp-ip Subject: explanation of ip-source code 4.3BSD
Can someone who knows e-mail me some explanation/documentation for the 4.3BSD source code of the internet protocol? thanks in advance, -Ramesh p.s: my email address is radha_s@cs.odu.edu
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: 6 Aug 91 21:02:32 GMT From: bvk@scharat.uucp (Dr. B.van Kruechten) To: comp.protocols.tcp-ip Subject: Re: Network printers
bmiller@CABELL.VCU.EDU (Bryan Miller) writes: >Can anyone give me any hints/suggestions on network printers. By that >I mean a printer that can attach directly to Ethernet, be assigned >an IP address, and then be able to receive printed output. We are >looking towards this as an alternative to purchasing terminal servers >each time we need to connect a remote printer. >Thanks, >Bryan Miller We have used a box from SPIDER: It's connected to ETHENET and has some twelve V24 lines on the other side. bvk
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: 6 Aug 91 21:04:57 GMT From: ado@BBN.COM To: comp.protocols.tcp-ip Subject: Re: ARP
You wrote: My reading of Comer's book and RFC826 make me believe that ARP will work independently of Internet addresses. A friend of mine tells me I am wrong. .... I didn't see a reply go by, so I'll give it a try. You are right about ARP. It is specified as being independent of the upper layer protocol, so if the ARP request ever got sent, and a reply came back, it should provide the desired answer. But your friend is right too. An ARP request won't get sent until the upper layer tries to send on the locally attached network. For the upper layer to so decide, it probably thinks it needs to have an address on that net. If your software is able to configure multiple address/mask pairs for a single interface, it probably doesn't have a way to configure a netaddress/mask pair, but no hostaddress. (I don't see that this would do any harm, but I expect good arguments can be constructed saying it is wrong for a host to be on a net without a host address on that net assigned to it.) So, to configure your host to be on a net, you would have to allocate a fake address on that net, and then even if you had the address to spare, the software might decide to send from that address instead of from the address you want it to use. Also, if you sent an ARP request, a reply might not come back -- I would guess that ARP software is often constructed to know (or only know) about TCP instead of being truly independent, so it might (although this is improbable,) do some checking and decide the sender's protocol address is offnet, and decline to reply -- unless you had configured the target host on both nets also.
-----------[000069][next][prev][last][first]---------------------------------------------------- Date: 6 Aug 91 23:29:17 GMT From: jtw@lcs.mit.edu (John Wroclawski) To: comp.protocols.tcp-ip Subject: Re: TCP Urgent data
In article <9108021743.AA13459@ftp.com> jbvb@FTP.COM (James B. Van Bokkelen) writes: My personal taste in this matter is not to provide notification of things I can't be sure of delivering to the application, which means that I wouldn't notify of Urgent until data up to the pointer is in hand. I realize this offers less functionality than notification when the URG bit is first received, but I think the world will be better off overall if the application doesn't have to cope with an EOF or reset connection error while it's in Urgent mode... But the whole point of urgent is to get the sleeping critter at the other end to wake up and do something different. Consider, for example, a remote invocation server, which is in the middle of crunching away at some 2-hour computation, and as a result isn't reading the data stream. If the client has sent any significant additional data, the TCP window will likely be closed. In this case, an Urgent indication delivered when the URG bit shows up can still be used to ^C the remote invocation server, but your way will leave the client helpless. There are a number of protocols other than TELNET which can benefit from TCP Urgent working right. Your approach makes it useless for many of them... -john
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: 7 Aug 91 00:25:15 GMT From: coates@UC780.UMD.EDU To: comp.protocols.tcp-ip,comp.dcom.lans Subject: Re: Protocol analyzers
In article <1991Aug6.091939.2340@husc3.harvard.edu>, utterbac@husc9.harvard.edu (Margot Utterback) writes: >We are evaluating protocol analyzers. So far we will be looking at >the Network General Sniffer and the Digilog LanVista 100. What we are >looking for is a portable unit that can diagnose as wide a range of >problems as possible. Price is a consideration but not a show stopper. >Has anyone had any experience with either of these units and can advise >us about them? And are we missing any other candidates? > >Thanks in advance. > >utterbac@husc.harvard.edu Go with the Sniffer, for a single unit it covers the most LAN nad WAN protocols.
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: 7 Aug 91 00:58:09 GMT From: dag@unisoft.UUCP (Darren Alex Griffiths) To: comp.protocols.tcp-ip Subject: Re: Remote Sensing of Conditions at Network Distribution Sites
In article <1991Aug2.235056.10184@relay.nswc.navy.mil> rleeson@relay.nswc.navy.mil (Robert Leeson) writes:
>
>Before I go out and "re-invent a wheel" (which might be "fun" in this
>case), does anyone know of a device that would permit the temperature,
>humidity, and the like at remote distribution points (wiring closets,
>comm. shacks, etc) be monitored and then reported to a central location
>using the network cabling. If there is an off-the-shelf device it would
>probably be cheaper than a "roll your own" solution.
>
There are a number of products to monitor environments in catalogs like
Computer Products and Inmac. All of the ones I've seen have consisted of
a phone line and water and temperature sensors. They are designed to call
you at a list of 5-10 numbers when there is a problem, you can also call
them and have them tell you information over the phone. It's not
exactly what you asked for, but if you can get fiber to the site you could
probably get a phone line there as well.
Cheers,
--darren
-----------[000072][next][prev][last][first]---------------------------------------------------- Date: 7 Aug 91 05:45:00 GMT From: tb@Materna.DE (Torsten Beyer) To: comp.protocols.tcp-ip Subject: RPC/XDR weirdness
Hi Netland,
I'm working on a piece of RPC-software part of which transfers lists between
two machines. While debugging the stuff I realized that my program would
slowly grow ( in terms of memory usage ;-). I first thought that I forgot to
put some xdr_free's in the right place but couldn't find a fault on my side.
Finally I decided to look into the xdr routines generated by rpcgen. I think
I have found a bug but correct me if I'm blind. Consider the dir.x demo
software that comes with rpc. Here's what rpcgen generates of dir.x:
bool_t
xdr_nametype(xdrs, objp)
XDR *xdrs;
nametype *objp;
{
if (!xdr_string(xdrs, objp, MAXNAMELEN)) {
return (FALSE);
}
return (TRUE);
}
bool_t
xdr_namelist(xdrs, objp)
XDR *xdrs;
namelist *objp;
{
if (!xdr_pointer(xdrs, (char **)objp, sizeof(struct namenode), xdr_namenode)) {
return (FALSE);
}
return (TRUE);
}
bool_t
xdr_namenode(xdrs, objp)
XDR *xdrs;
namenode *objp;
{
if (!xdr_nametype(xdrs, &objp->name)) {
return (FALSE);
}
if (!xdr_namelist(xdrs, &objp->next)) {
return (FALSE);
}
return (TRUE);
}
Consider a list of n entries. When calling xdr_free for namenode, it would
free it's nametype entry and - by calling xdr_namelist the next one. But not
further. I'm I right to suspect that in the above case only the second list
element would get free'd by xdr ? Or is there a trick somewhere in
xdr_pointer that enables it to free subsequent list elements ???
Is there any whay to convince rpcgen that a certain struct is part of a list
and that it should generate recursive xdr routines ?? Or do I have to code
all this by hand ???
Any clues greatly appreciated
thanx in advance
-Torsten
--
Torsten Beyer e-mail : tb@Materna.DE
Dr. Materna GmbH VOX : +49 231 5599 225
Vosskuhle 37, D-4600 Dortmund FAX : +49 231 5599 100
"Strahlentod und Mutation durch die schnelle Kernfusion..", Kraftwerk
-----------[000073][next][prev][last][first]---------------------------------------------------- Date: 7 Aug 91 06:22:20 GMT From: imp@solbourne.com (Warner Losh) To: comp.protocols.tcp-ip Subject: ntalk forwarding daemon
I'm looking for a forwarding talk daemon. By this I mean that I want a talk daemon (speaking ntalk) to accept talk requests by proxie for me and forward them to where ever I am at the time (or where ever I have registered being). It would then let me connect to it so I could talk with the remote person. Has anybody done anything like this, or am I going to have to spend a few hours hacking talkd from the tahoe tape? Warner P.S. If you have any good ideas on how to accomplish this, please let me know. I think that it can be done w/o extending the protocol (but extending the protocol would make it more generally useful). -- Warner Losh imp@Solbourne.COM uunet bang stan bang imp "Red hair is caused by sugar and lust," the woman, who was blond, confided. "Highly evolved beings do not indulge in sugar and lust."
-----------[000074][next][prev][last][first]---------------------------------------------------- Date: 7 Aug 91 08:10:49 GMT From: anne@spider.co.uk (Anne Ambler) To: comp.protocols.tcp-ip,comp.dcom.lans Subject: Re: Protocol analyzers
In article <1991Aug6.091939.2340@husc3.harvard.edu> utterbac@husc9.harvard.edu (Margot Utterback) writes: >We are evaluating protocol analyzers. So far we will be looking at >the Network General Sniffer and the Digilog LanVista 100. What we are >looking for is a portable unit that can diagnose as wide a range of >problems as possible. Price is a consideration but not a show stopper. >Has anyone had any experience with either of these units and can advise >us about them? And are we missing any other candidates? > >Thanks in advance. > >utterbac@husc.harvard.edu You should also consider the SpiderAnalyzer from Spider Systems. Their address is: Spider Systems, Inc. 12 New England Executive Park Burlington MA 01803 tel. (617) 270 3510
-----------[000075][next][prev][last][first]---------------------------------------------------- Date: 7 Aug 91 08:31:36 GMT From: hiroshi@semicon.sony.co.jp (Hiroshi Miyazawa) To: comp.protocols.tcp-ip Subject: Re: IP routing over ISDN.
In article <1991Aug1.215048.12396@jrd.dec.com>,
rikitake@jrd.dec.com (Kenji Rikitake) says:
> In article <1991Aug1.032300.8756@nodecg.ncc.telecomwa.oz.au>, ingham@nodecg.ncc.telecomwa.oz.au (bruce ingham 4206700) writes:
>
> ] Do any products exist that provide IP routing directly onto
> ] ISDN ?
>
> You can attach ISDN boards for Sony NEWS workstations. I've heard several
> people doing IP networking on it. The board is intelligent so you need not to
> have TA.
>
> -- Kenji
I'm using the NEWS-workstation with ISDN board as "IP router over ISDN".
This combination of equipments are used at many sites in Japan to build
cost-effective WANs over ISDN. The board make the workstation behave as a
gateway not only over ISDN but also X.25 . ISDN I/F is S-point and 8-pin
moduler jack.
When the workstation receive an IP packet which is derected to the remote
network, the board automatically (and quickly) establish the ISDN-connection
with the another ISDN-gateway of designated network. The relations between
network addresses and ISDN numbers are defined in a database file.
(Of course, the sub-address of ISDN number can be assigned to the board)
For the purpose of security, the board never accept the request of connection
if the callers ISDN number is not defined in the database.
Once the connection is established, both LANs become reachable as if they
are connected with leased 64kbps line. Futher, the users can talk over this
ISDN link with the analog voice I/F of the board wihle doing IP operation.
Also the board disconnect the ISDN link automatically when a certain time
(may be 1 minute or so) has passed since last packet was transfered.
However, I think those equipments are not suitable for the ISDN in U.S. As
Richard Jennings wrote, I've also heard HP provides same one. I hope that
is available in both countries and can be used for the international
internetworking over ISDN.
--------
Hiroshi Miyazawa Sony Semiconductor Grp. System Div.
hiroshi@semicon.sony.co.jp 4-14-1 Asahi-cho, Atsugi, Kanagawa
Tel: (81)462-30-5341
-----------[000076][next][prev][last][first]---------------------------------------------------- Date: 7 Aug 91 09:30:23 GMT From: daveg@prowler.clearpoint.com (Dave Goldblatt) To: comp.sys.mac.comm,comp.protocols.tcp-ip Subject: Re: "EtherScope" from Racal-Interlan
On 7 Aug 91 12:46:10 GMT, dag@fciva.FRANKCAP.COM (Daniel A. Graifer) said: dag> I have been using the ethernet protocol analyzer that was bundled free with dag> the Racal-Interlan NIA310 MacConnect II ethernet controller card in My Mac dag> IIcx: EtherScope version 1.0. I'm just an amateur, so I've learned a lot dag> about tcp/ip from trapping various types of traffic. There appears to be dag> a bug in the way it translates the source ethenet address to a station dag> name (from an internal table) in the header of the packet listing. Also the dag> initial sequence number and Ack Number of the tcp/ip packets appear to dag> be translated incorrectly. So my questions are: dag> 1) Am I just ignorant, or have others observed these problems? I seem to recall bugs along those lines in earlier versions. dag> 2) If these problems are real, are there other bugs people have dag> observed that I should watch out for? Nothing fatal. In fact, they should be pretty responsive if you find anything. dag> 3) Is there a more recent version of this with these bugs fixed dag> available somewhere? I think the latest (shipping) version is 1.1 -- at least it was when I left. You can either call customer service at 1-800-LAN-TALK, or send email to pulley@interlan.interlan.com (the director in charge of drivers & EtherScope) and ask him (probably a better bet). dag> I don't mean to complain. The card has been a great performer (I bought dag> it because it was rated #1 by MacUser in their Ethernet Special last dag> summer), and the price for the software was certainly right! You can't dag> beat free, and I can't justify big bucks for a commercial product. But dag> the bugs are annoying, and in at least one instance I had trouble dag> convincing another software vendor that there really was a bug in his dag> product, since my packet dumps proving it were "obviously suspect". You wouldn't believe the fight that occurred over giving it away. :-) But try sending email to the above address if you find bugs -- I think that group will be quite responsive. -dg- -- "We are young, wandering the face of | Dave Goldblatt [daveg@clearpoint.com] the Earth, wondering what our dreams | Subsystems Software Engineering might be worth, learning that we're | Clearpoint Research Corporation only immortal for a limited time.." -- Rush, "Dreamline"
-----------[000077][next][prev][last][first]---------------------------------------------------- Date: 7 Aug 91 11:28:57 GMT From: mark@labtam.labtam.oz.au (Mark Treacy) To: comp.protocols.tcp-ip Subject: Re: Connected Udp socket question
finnegan@viewlogic.com (David Finnegan) writes: > I am having some trouble with 'connected' Udp sockets using the > local interface on a DEC Station 3100. > > If the server end of a connected Udp socket is unreachable > (closed, for example) then a 'connection refused' error is > generated on the next system call to the client socket after a > write is performed. > > This behavior is what I expect. > > What I don't expect is that other processes, on the same machine, > with local Udp connected sockets also get the connection refused > error. > [detailed description deleted] > It appears, at least to me, that once the rcv process has been > killed an attempt to send a character to it generates a connection > refused error for each (and every) process with a locally > connected Udp socket. Each process 'trips' the error by trying to > send on their connected client socket. Once the final process in > the chain has 'tripped' their error the process starts over again > by generating another error with an attempted send to the > nonexistent rcv socket. Correct > My question (albeit long winded) is this: is this really a bug in > the DS3100 Tcp/Ip code or am I misinterpreting the results? It's a generic bug in pre 4.3bsd-reno sources, and hence some tcp/ip implementations derived from such. (SVR4 for example) Briefly: The write to the rcv process causes an ICMP port unreachable to be generated. icmp_input() calls the protocol ctlinput routine, udp_ctlinput(), with the destination address of the original packet which caused the icmp error. udp_ctlinput() calls in_pcbnotify() which calls udp_notify() for _all_ udp sockets connected to the destination address which caused the original icmp error. in_pcbnotify() needs more information to be a bit more specific about who it notifies, but the protocol ctlinput mechanism doesn't allow for it to be passed along. 4.3bsd-reno solves this problem by having icmp_error() pass along the errornous ip packet and in_pcbnotify() taking a few more arguments. - Mark. Mark Treacy Systems Programmer Labtam Australia net: mark@labtam.labtam.oz[.au] Melbourne, Australia phone: +61-3-587-1444
-----------[000078][next][prev][last][first]---------------------------------------------------- Date: 7 Aug 91 12:46:10 GMT From: dag@fciva.FRANKCAP.COM (Daniel A. Graifer) To: comp.sys.mac.comm,comp.protocols.tcp-ip Subject: "EtherScope" from Racal-Interlan
I have been using the ethernet protocol analyzer that was bundled free with
the Racal-Interlan NIA310 MacConnect II ethernet controller card in My Mac
IIcx: EtherScope version 1.0. I'm just an amateur, so I've learned a lot
about tcp/ip from trapping various types of traffic. There appears to be
a bug in the way it translates the source ethenet address to a station
name (from an internal table) in the header of the packet listing. Also the
initial sequence number and Ack Number of the tcp/ip packets appear to
be translated incorrectly. So my questions are:
1) Am I just ignorant, or have others observed these problems?
2) If these problems are real, are there other bugs people have
observed that I should watch out for?
3) Is there a more recent version of this with these bugs fixed
available somewhere?
I don't mean to complain. The card has been a great performer (I bought
it because it was rated #1 by MacUser in their Ethernet Special last
summer), and the price for the software was certainly right! You can't
beat free, and I can't justify big bucks for a commercial product. But
the bugs are annoying, and in at least one instance I had trouble
convincing another software vendor that there really was a bug in his
product, since my packet dumps proving it were "obviously suspect".
As usual, many thanks in advance to the net community...
Dan
--
Daniel A. Graifer Coastal Capital Funding Corp.
Sr. Vice President, Financial Systems 7900 Westpark Dr. Suite A-130
(703)821-3244 McLean, VA 22102
uunet!fciva!dag fciva.FRANKCAP.COM!dag@uunet.uu.net
-----------[000079][next][prev][last][first]---------------------------------------------------- Date: 7 Aug 91 13:58:32 GMT From: bmiller@VCU1.VCU.EDU (Bryan Miller) To: comp.protocols.tcp-ip Subject: (none)
Has anyone out there ported ATT ditroff for use with Ultrix? Bryan
-----------[000080][next][prev][last][first]---------------------------------------------------- Date: 7 Aug 91 13:58:38 GMT From: ckollars@deitrick.East.Sun.COM (Chuck Kollars - Sun BOS Software) To: comp.protocols.tcp-ip Subject: Re: TCP Urgent data
Some folks report that using TCP's Urgent Data feature improves their Telnet. (example from Steven Bellovin:) > You've never tried using a version of TCP without it, obviously. I have... > Yes, you need it. You'd be surprised at how much longer it takes to get > the remote end to shut up when you hit INTR if you don't have out-of-band. Other folks report that TCP's urgent data doesn't seem necessary. (example from Dan Bernstein:) > I regularly work over a cross-country connection which approximately 10% > of the time provides throughput under 3KB/sec. What most people don't > seem to understand is that it's the *client* queue length, *not* the > server queue length, which matters for TELNET IP and AO. Do you type > 3KB/sec? How can they both be right? What are we missing? It depends on the implementation details of the server side Telnet. o A server side Telnet daemon that does its own buffering will find the IP/AO/DM in the stream right away and do the appropriate thing with or without TCP's Urgent Data feature. o A server side Telnet daemon that relies on TCP do to its buffering won't see the IP/AO/DM/etc. until its user process reads the input stream. When the server side TCP sees Urgent Data it "wakes up" the server side Telnet, an exception to layering. (The Urgent Data notification "nudges" the server side Telnet, but doesn't tell it exactly what to do. The server side Telnet still has to read the data stream to find the IP or AO or whatever, then react appropriately. You can have Telnet without Urgent Data, but you can't have Telnet without IP/AO/DM/etc.) --- chuck kollars <ckollars@East.Sun.COM> (located in Boston) Systems and Network Administration Group (SNAG)
-----------[000081][next][prev][last][first]---------------------------------------------------- Date: 7 Aug 91 14:45:14 GMT From: iain@castle.ed.ac.uk (Iain Lindsay) To: comp.protocols.tcp-ip Subject: ICMP ECHO TTL (was Re: Connectivity Problems)
In article <9108021241.AA26833@NISC.SRI.COM> NU021172@VM1.NODAK.EDU (Marty Hoag) writes:
>
> .... when we "PING" you the reply comes back
>with a "good" TTL value of 7 left (which, in a normal case, would mean it
>is 8 "hops" to here).
The use of the phrase "in a normal case" above brings up something which has
been niggling me for quite a while. I've never found a definitive answer to
the question "what should the TTL be set to in an ICMP ECHO REPLY. Most (?)
software seems to set the value to something determined locally (I've seen 15,
30 and 255). However, given the wording of rfc792:
....... To form an echo reply
message, the source and destination addresses are simply reversed,
the type code changed to 0, and the checksum recomputed.
(and correcting it to ensure the correct outgoing source address) I have always
thought that the TTL should simply be decremented from its value on receipt.
The idea behind this is that the echo datagram is 'the same one' all the way
round. Changing the type code is done simply to ensure that the datagram is
caught when it gets back to its origin. I can find no reference to 'correct'
behaviour in rfc1122. However, rfc1122 does say:
If a Record Route and/or Time Stamp option is received in an
ICMP Echo Request, this option (these options) SHOULD be
updated to include the current host and included in the IP
header of the Echo Reply message, without "truncation".
Thus, the recorded route will be for the entire round trip.
Which confirms me in my opinion that the initial TTL should be taken from the
incoming datagram. This enables the originator to be sure of the round-trip
distance to another host, without requiring knowledge of the remote host's
TTL configuration. Can anyone point me to a definitive answer, or show why
my opinion is wrong?
-Iain Lindsay..
-----------[000082][next][prev][last][first]---------------------------------------------------- Date: 7 Aug 91 14:49:06 GMT From: dmritter@CBG-99SIMA.ARMY.MIL (Dave Ritter) To: comp.protocols.tcp-ip Subject: rejection of unregister host mail
Reply To: dmritter@cbg-99sima.army.mil Phone: DSN/AV: 570-9166 Comm: 717-267-9166 Resent-Date: Thu, 8 Aug 91 12:38:17 MST Resent-From: bstring@mainz-emh2.army.mil Resent-To: tcp-ip@NIC.DDN.MIL Hi, As you are aware, with the increased use of nameservers on the Internet, many many hosts are not registered in the hosts.txt file. Therefore, these "unregister" hosts do not get into the Sperry's /etc/hosts file. This leads to a problem with MMDF.S04. When an unregister host sends mail to a Sperry, it is rejected. When I watch the delivery attempt, I see "problem reading from net". And in the chan.log I see "Sys error 203 socket operation on a non socket, netread: ret=0, fd=3" and "smtpsrvr: wrong number of args!". In my smtpd.log, I see "p started", as opposed to an entry for a register hosts of say "cbg-99sima.army.mil started". Quoting from the "Installation and Operating MMDF II" document (which came out when MMDF II came out I _think_, the doc is undated) NODOMLIT Prevents Domain Literals (such as [10.0.0.59]) from appearing in addresses. Since MMDFII doesn't currently handle Domain Literals properly, use of this option is strongly advised. I compiled the smtpsrvr without defining NODOMLIT and experienced the same failure. It occures to me that the private/academic community (update 43) should have already tackled this problem as they're heavy into nameserver use. Also, an unregister host can't telnet to a Sperry's smtp port (port 25). Any ideas/suggestions? TIA, dave ~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~ % Dave Ritter % These opinions are % % Programmer/Analyst % My own and do not % % SIMA % Necessarily reflect % % AMXSI-TLB % Those of Management % % Chambersburg, PA 17201 % % ~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~
-----------[000083][next][prev][last][first]---------------------------------------------------- Date: 7 Aug 91 18:27:24 GMT From: morphy@nntp-server.caltech.edu (Jones Maxime Murphy) To: comp.protocols.tcp-ip Subject: Where is the FAQ for this group kept?
Please email me with a telnet site, thanks. Jones -- :)
-----------[000084][next][prev][last][first]---------------------------------------------------- Date: 7 Aug 91 19:21:23 GMT From: brian@natinst.com (Brian H. Powell) To: comp.protocols.tcp-ip Subject: ftp-data service ?
On SunOS, in /etc/services, there's an entry for:
ftp-data 20/tcp
I'm wondering what ftp-data is used for. Near as I can tell, FTP uses
port 21. What's the scoop?
Just curious. Please respond by mail.
Brian
-----------[000085][next][prev][last][first]---------------------------------------------------- Date: 7 Aug 91 21:16:54 GMT From: tleng@faline.bellcore.com (Tony L. Eng) To: comp.protocols.tcp-ip Subject: question about ftp
I have a question concerning ftp between host A and B, A being the client
to server at B:
at the start of an ftp session, I find that on doing an 'ls' on host A,
it sends a PORT command to the ftp server on B, then
a packet with data field:
..9..NLST
to host B, which replies with
500 '9': command not understood.
what can cause Host A to do such a thing? On examing packets on the
ethernet, it seems that host B proceeds to send the directory listing,
but host A doesn't display it onto the screen, nor does it process the
226 message that Host B sends (perhaps the 500 message triggers some
blocking mechanism on Host A).
Aborting the session and trying to ftp again results in some other character
besides '9'.
does anyone have any ideas?
thanks in advance,
cheers,
Tony
-----------[000086][next][prev][last][first]---------------------------------------------------- Date: 7 Aug 91 22:54:42 GMT From: dricejb@drilex.UUCP (Craig Jackson drilex1) To: comp.protocols.tcp-ip Subject: Re: Sub standard FTP implementation
In article <NU0DCI9@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:
>In article <9107312114.AA25385@ftp.com> jbvb@ftp.com writes:
>> RFC 1123 remedies that lack - see the section on FTP. I myself haven't
>> seen software that didn't implement LIST or NLST since 1987, and it was
>> out of date at that time.
>
>DDN1100 on the Unisys 1100 mainframes.
Unisys A-Series boxes aren't any better.
Their current implementation of TCP/IP doesn't do LIST or NLST, either.
They don't even do UDP, so they can't run DNS.
Supposedly, this is all fixed in the next release, whenever that comes out.
--
Craig Jackson
dricejb@drilex.dri.mgh.com
{bbn,alliant,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}
-----------[000087][next][prev][last][first]---------------------------------------------------- Date: 8 Aug 91 03:32:43 GMT From: keith@novell.com (Keith Brown) To: comp.protocols.tcp-ip,comp.dcom.lans Subject: Re: Protocol analyzers
>In article <1991Aug6.091939.2340@husc3.harvard.edu>, utterbac@husc9.harvard.edu (Margot Utterback) writes:
>
>Go with the Sniffer, for a single unit it covers the most LAN nad WAN
>protocols.
Hold up! As you might expect, I'm a LANalyzer user myself and I can vouch
for the fact that the thing decodes more protocols than you can shake a
stick at! Also, all these decodes are included for free (very free in
my case :-)). I believe Network General still charge extra for each protocol
family your interested in having broken out for you.
The guys in our lanz group just cranked out a new release (version 3.11)
which decodes a positively horrendous number of protocols. You can even
"feed" it SNMP Management Information Bases and it will start decoding
all your SNMP queeries and responses to and from "proprietary" (vendor
specific) MIBs. You feed it the ascii MIB files in either SMI format
or the newer concise format specified in RFCs 1212 and 1215 (and no I
didn't remember that, I had to look in the manual :-)). The lanz also
comes with over 120 canned experiments to both analyze and characterize
the piece of cable into which it is plugged (from the protocol perspective).
It's great fun to play with :-)
Oh... and in case your wondering.... yes it does decode LAN Manager and
Banyan Vines protocols too. The LANalyzer group can be hailed
on 1-800-243-8526.
Keith
Disclaimer: The Lanalyzer division of Novell is in a completely different
building to me and I have no affiliation to them whatsoever,
particularly since they creamed my group in a softball match
during a company outing last year! In fact, I spit on them :-)
-
Keith Brown Phone: (408) 473 8308
Novell San Jose Development Centre Fax: (408) 433 0775
2180 Fortune Dr, San Jose, California 95131 Net: keith@novell.COM
-----------[000088][next][prev][last][first]---------------------------------------------------- Date: 8 Aug 91 14:54:54 GMT From: PIRARD@VM1.ULG.AC.BE (Andr'e PIRARD) To: comp.protocols.tcp-ip Subject: EBCDIC ASCII and *much* more
In answer to the questions of an EBCDIC/ASCII translation and "Which EBCDIC?", I offer a paper containing in-depth analysis of the situation, extending into the field of [inter]national characters support in communication protocols. The concepts and methods hold for TCP/IP applications. The paper stems from discussion with programmers who wanted to enlarge usability of their software and takes the form of a how to understand and do it practically. Of translation tables data, you'll get your share... ftp vm1.ulg.ac.be anonymous cd anonymous get ISO8859.NOTES A broader aspect of the ASCII/EBCDIC or ISCII/EBCDIC is covered in Edwin Hart's White Paper of SHARE to IBM. Support of international characters with Kermit is described in watsun.cc.columbia.edu:kermit/e/isok5.txt Andr'e PIRARD SEGI, Univ. de Li`ege 139.165 IP coordinator B26 - Sart Tilman B-4000 Li`ege 1 (Belgium) +32 (41) 564932 pirard@vm1.ulg.ac.be alias PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU
-----------[000089][next][prev][last][first]---------------------------------------------------- Date: 8 Aug 91 15:53:40 GMT From: jesmith@gdfwc3 (Jesse Smith) To: comp.protocols.tcp-ip Subject: POSIX Interface to TCP/IP
Is there a POSIX draft document which describes the application interface to the transport layer (specifically, TCP/IP and UDP/IP)? If so, what is its number and how can I order a copy? Thanks, Jesse E. Smith General Dynamics Corp. Fort Worth, TX gdfwc3!jesmith@central.sun.com
-----------[000090][next][prev][last][first]---------------------------------------------------- Date: 8 Aug 91 17:10:39 GMT From: fmueller@telebit.com (Fritz Mueller) To: comp.protocols.tcp-ip,comp.dcom.lans Subject: Re: Authentication
Can anyone tell me how the various terminal server vendors do user authentication over a network. I understand that cisco terminal servers use TACACs and Xylogics uses a proprietary method based on TACACs. What do DEC, Xyplex, 3Com and all the others do? Unless they are keeping the user ID and password right on a disk on the terminal server they must be getting the information off a network server with some protocol. -- Fritz Mueller 408-745-3028 Product Manager
-----------[000091][next][prev][last][first]---------------------------------------------------- Date: 9 Aug 91 13:07:32 GMT From: mleech@bnr.ca (Marcus Leech) To: comp.protocols.tcp-ip Subject: Getting a class-C allocation (FAQ warning)
This is almost certainly an FAQ: I want to get a class-C network for my basement computing complex ;-) Do I still do such things via registrar@nic.ddn.mil? Does the NIC at SRI still exist? It's been a couple of years since I last had to do this, and things may have changed.
-----------[000092][next][prev][last][first]---------------------------------------------------- Date: 9 Aug 91 14:08:43 GMT From: bmiller@VCU1.VCU.EDU (Bryan Miller) To: comp.protocols.tcp-ip Subject: Broadcast address
Would someone like to share their thoughts on broadcast address for individual hosts? We have a class B address, we'll call 150.150.x.x. As the new network manager here, I was surprised to find all the broadcast addresses on our machines set to 150.150.1.255. Our network is split into 3 campuses. I would have thought that you would want a broadcast message sent to ALL hosts on 150.150, not just those on 150.150.1. Am I missing something here? Thanks for any tips. Bryan Miller Virginia Commonwealth University
-----------[000093][next][prev][last][first]---------------------------------------------------- Date: 9 Aug 91 16:04:45 GMT From: rae@s5000.rsvl.unisys.com (Rick Erickson x2132) To: comp.protocols.tcp-ip Subject: Gratuitous ARP
I've heard references to 'gratuitous ARP'. Can anybody explain this? My
understanding is that hosts and routers that receive an ARP Request will
refresh their ARP caches, but that is how ordinary ARP works, so what is
'gratuitous ARP'?
Another question is whether there are any ARP implementations that do not
refresh their ARP cache when a broadcasted ARP Request is seen?
Rick Erickson
-----------[000094][next][prev][last][first]---------------------------------------------------- Date: 9 Aug 91 16:13:27 GMT From: daveg@prowler.clearpoint.com (Dave Goldblatt) To: comp.sys.mac.comm,comp.protocols.tcp-ip Subject: Re: "EtherScope" from Racal-Interlan
By the way, I just found out that EtherScope is up to version 1.2.2, and has full support for System 7. Contact pulley@interlan.interlan.com with questions, etc. -dg- -- "We are young, wandering the face of | Dave Goldblatt [daveg@clearpoint.com] the Earth, wondering what our dreams | Subsystems Software Engineering might be worth, learning that we're | Clearpoint Research Corporation only immortal for a limited time.." -- Rush, "Dreamline"
-----------[000095][next][prev][last][first]---------------------------------------------------- Date: 9 Aug 91 16:58:39 GMT From: rgoldstone@OAVAX.CSUCHICO.EDU (Robin Goldstone) To: comp.protocols.tcp-ip Subject: Finger server as a requirement for all Internet hosts
I doubt this is the appropriate place to bring this up, so maybe someone can refer me to a newsgroup or mailing list where issues such as these are discussed. I would like to see a requirement for all Internet domains to operate a finger (or whois) server to serve the top-level domain at their site. I often have users come to me and say "I want to send e-mail to my colleague at the University of XYZ. Is there some way I can look up their address?" And I feel that the answer to this question should be YES, given that you know the person's last name and the domain name for the organization (which can be obtained from the NIC using WHOIS if you don't know it). This would parallel the function of the telephone directory assistance service. If you know the area code (which you can get from local directory assistance if you don't know it) then you can contact the desired directory assistance using (area code) 555-1212. Users should be able to finger: lastname@top-level-domain (e.g. goldstone@csuchico.edu) and get back a valid e-mail address. So I am wondering if there is any effort under way to standardize on some form of electronic "directory assistance" on the Internet. Like I said, I don't know if this is the place to discuss this. If not, tell me where to go (well, you know what I mean!). *********************************************************************** Robin Goldstone, Systems Software Specialist California State University, Chico Computing Services rgoldstone@oavax.csuchico.edu
-----------[000096][next][prev][last][first]---------------------------------------------------- Date: 9 Aug 91 17:27:36 GMT From: coates@UC780.UMD.EDU To: comp.protocols.tcp-ip Subject: Re: POSIX Interface to TCP/IP
In article <JESMITH.91Aug8165340@kuwait.gdfwc3>, jesmith@gdfwc3 (Jesse Smith) writes: >Is there a POSIX draft document which describes the application interface to >the transport layer (specifically, TCP/IP and UDP/IP)? If so, what is its >number and how can I order a copy? > >Thanks, >Jesse E. Smith >General Dynamics Corp. >Fort Worth, TX >gdfwc3!jesmith@central.sun.com I don't believe POSIX uses TCP-IP or UDP-IP. I understand its purpose to be to provide a uniform interface for applications to OSI transport and network protocols.
-----------[000097][next][prev][last][first]---------------------------------------------------- Date: 9 Aug 91 17:54:32 GMT From: raphael@dorsai.com (Raphael Laderman) To: comp.protocols.tcp-ip Subject: CompressNET
Has anyone any experience or thoughts on Process Software's CompressNET? It apparently compresses TCP/IP data before TCP gets it, thereby reducing the number of packets and amount of data transmitted between nodes using the software. They claim to be transparent to both the application programs and the TCP. I'm wondering how transparent they can be with any stability: how could they insert themselves in the datastream without disrupting something. They claim to work with anyone's applications and anyone's TCP with no relinking.
-----------[000098][next][prev][last][first]----------------------------------------------------
Date: 9 Aug 91 18:05:20 GMT
From: aets-kja-a-ao3@ANSBACH-EMH1.ARMY.MIL ("Thomas F. Pockberger")
To: comp.protocols.tcp-ip
Subject: A new dump questionSorry but I am REALLY new to TCP/IP. here is my question: If two Internet sites establish a connection it normally goes thru a couple of "hops". Each of them uses one TTL count on the packets. Is there something like a "return receipt" from the receiving machine which also has TTLs and uses them. Sample: I conect to a host, some of the packet goes thrue 13 hops but most thru 16 hops. TTL is set to 15 on our machine. So the packets with 13 hops get thru the 16 hops not. Can the result be something like "timed out".? If the receiving machine is sending acknowledgement on the 13 hops packet can this result in a kind of "loose" connection. (connect; permission denied) Sorry if this is a dump question. Can somebody shine a light on me. Pocky
-----------[000099][next][prev][last][first]---------------------------------------------------- Date: 9 Aug 91 18:34:06 GMT From: mckenzie@bbn.com (Alex McKenzie) To: comp.protocols.tcp-ip Subject: Re: Sub standard FTP implementation
This message is for history buffs only. Mike, I think my memory stands the test. Now that it has been challenged, I have gone back to the original RFC's. RFC's 171 and 172 were published in June 1971. I was a co-author of each. RFC 171 defined "The Data Transfer Protocol", and RFC 172 defined "The File Transfer Protocol." RFC 172: - contains the statement "FTP uses the data transfer protocol described in RFC 171 to achieve transfer of data." - contains the statement "Implementation of a workable* subset of opcodes is specifically permitted." " * A workable subset is any request, plus terminates." RFC 171 begins with the sentence: "A common protocol is desirable for data transfer in such diverse applications as remote job entry, file transfer, network mail system, graphics, remote program execution, and communication with block data terminals (such as printers, card, paper tape, and magnetic tape equipment, expecially [sic] in context of terminal IMPs)." The first RFC which combined the Data Transfer and File Transfer protocols is RFC 354, published in July 1972 under the author name Abhay Bhushan (MIT). It reports on the work of a committee, listed on the last page of the RFC. This RFC does not define a minimum FTP implementation. Cheers, Alex
-----------[000100][next][prev][last][first]---------------------------------------------------- Date: 10 Aug 91 00:01:04 GMT From: small@turing.seas.ucla.edu (James F. Small) To: comp.protocols.tcp-ip Subject: att 3b2 and slipinks)
I'm trying to set up a slip connection on an att 3b2 running unx sys v r3 with WIN tcpip. any hints , or anyone know where I can find hints?
-----------[000101][next][prev][last][first]---------------------------------------------------- Date: 10 Aug 91 01:05:08 GMT From: geertj@philica.ica.philips.nl (Geert Jan de Groot) To: comp.protocols.tcp-ip Subject: Re: Finger server as a requirement for all Internet hosts
In article <1991Aug09.165839.21578@ecst.csuchico.edu> rgoldstone@OAVAX.CSUCHICO.EDU writes: >I would like to see a requirement for all Internet domains to operate a >finger (or whois) server to serve the top-level domain at their site. >I often have users come to me and say "I want to send e-mail to my colleague >at the University of XYZ. Is there some way I can look up their address?" I don't think this is a good idea. First off, finger sometimes provide usable hacker info (this is why some sites don't allow finger). Second, the site might distribute mail internally via aliases, so there is no account for that user on the mailhost, and no finger info.. Third, not all sites have IP connectivity or are allowed to use part of the network (in Europe, access on the NSFnet backbone is something that has to be asked for and doesn't come automatically). Fourth, some sites are not connected via IP but use UUCP or BITNET or other means, which means finger doesn't work for them. In situations like these, I have successfully used sending mail to postmaster@XYZ.edu. Now, you're talking to a human (postmaster is defined to be a name that is looked at frequently), and (s)he should know or should be able to point you to someone who does. Good hunting, Geert Jan --8<--nip-nip--------------------------------------------------------------- "We trained hard - but it seemed that every time we were beginning to form up into teams, we would be reorganized. It was to learn later in life that we tend to meet any new situation by reorganizing, and a wonderful method it can be for creating the illusion of progress while producing confusion, inefficiency, and demoralisation." - possibly from Petronius, 100 BC Geert Jan de Groot, Philips ICA, Weisshausstrasse 1, 5100 Aachen, Germany Email: geertj@ica.philips.nl or ..!hp4nl!philica!geertj Phone: +49 241 6003 714 FAX: +49 241 6003 709 >And I feel that the answer to this question should be YES, given that you >know the person's last name and the domain name for the organization (which >can be obtained from the NIC using WHOIS if you don't know it). This >would parallel the function of the telephone directory assistance service. >If you know the area code (which you can get from local directory assistance >if you don't know it) then you can contact the desired directory assistance >using (area code) 555-1212. Users should be able to finger: >lastname@top-level-domain (e.g. goldstone@csuchico.edu) and get back a valid >e-mail address. > >So I am wondering if there is any effort under way to standardize on some >form of electronic "directory assistance" on the Internet. Like I said, >I don't know if this is the place to discuss this. If not, tell me where to >go (well, you know what I mean!). > >*********************************************************************** >Robin Goldstone, Systems Software Specialist >California State University, Chico Computing Services >rgoldstone@oavax.csuchico.edu
-----------[000102][next][prev][last][first]---------------------------------------------------- Date: 10 Aug 91 01:27:20 GMT From: coolidge@speaker.sgi.com (Don Coolidge) To: comp.protocols.tcp-ip Subject: Re: Gratuitous ARP
In article <236@s5000.rsvl.unisys.com> rae@s5000.rsvl.unisys.com (Rick Erickson x2132) writes: >I've heard references to 'gratuitous ARP'. Can anybody explain this? My >understanding is that hosts and routers that receive an ARP Request will >refresh their ARP caches, but that is how ordinary ARP works, so what is >'gratuitous ARP'? Probably when the act of configuring an interface with an IP address causes the host to send out an ARP request for that address over that interface. Nobody will answer, but everyone who refreshes his cache will get a guaranteed up-to-date IP address to match with the meduim address. (When I worked at a different company, we called ours "Unsolicited ARPs".) - Don Coolidge coolidge@sgi.com
-----------[000103][next][prev][last][first]----------------------------------------------------
Date: 10 Aug 91 04:26:08 GMT
From: ole@CSLI.STANFORD.EDU ("Ole J. Jacobsen")
To: comp.protocols.tcp-ip
Subject: TCP Urgent DataBy the way, a discussion of this topic appeared in an article by Mitch Tasman in the June 1990 issue of ConneXions. The article was entitled "Telnet Output Discard Processing". Ole Ole J Jacobsen, Editor & Publisher ConneXions--The Interoperability Report Interop, Inc., 480 San Antonio Road, Suite 100, Mountain View, CA 94040, Phone: (415) 962-2515 FAX: (415) 949-1779 Email: ole@csli.stanford.edu
-----------[000104][next][prev][last][first]---------------------------------------------------- Date: 10 Aug 91 05:48:13 GMT From: mikeb@polari.UUCP (Mike Branch) To: comp.os.vms,comp.protocols.tcp-ip Subject: TCP/IP printing on VMS
Can anyone tell me how to send data to a printer connected to VAX/VMS over TCP/IP? I'm interested in using either Wollongong, or getting really creative and using sockets. I'd also like to get data back from the printer, in case it happens to be a PostScript printer. Please make your responses readable by a 5-year-old, as I am a neophyte when it comes to TCP/IP. VMS and DECnet have spoiled me. Or, if you know of a lucid hardcopy discussion of the subject, I'd love to hear about it. Thanks in advance for your help. -- Mike Branch, Bellevue, Washington mikeb@polari.UUCP uw-beaver!sumax!polari!mikeb
-----------[000105][next][prev][last][first]---------------------------------------------------- Date: 10 Aug 91 07:06:24 GMT From: greg@gagme.chi.il.us (Gregory Gulik) To: comp.sys.att,comp.protocols.tcp-ip Subject: 3B2 Ethernet problems.
I'm running the following hardware/software:
3B2/400
NI card in slot 6 and other cards
Cabletron Systems ST-500 with LANVIEW transceiver
WIN/3B 1.1
The problem I'm having is that the diagnostics are failing
on the NI card. At first, I didn't have a transceiver so
I expected that, but it didn't go away once I hooked it up.
The problem with the transceiver is that I don't have
any documentation on it!! What does the SQE light mean?
Is it suppsed to always be on? What does the jumper
inside mean? The PWR light is on, so that's a pretty
good sign. There is a terminator connected before
anyone asks the obvious.
I looked in the NI card docs, and it doesn't
seem to help. All is tells you is how to plug
it in.
-greg
--
Gregory A. Gulik Call Gagme, a public
greg@gagme.chi.il.us || gulik@depaul.edu access UNIX system at
|| gulik@motcid.rtsg.mot.com (312) 714-8568
-----------[000106][next][prev][last][first]---------------------------------------------------- Date: 10 Aug 91 08:51:43 GMT From: dhuber@aut.autelca.ascom.ch (Daniel Huber) To: comp.protocols.tcp-ip,comp.protocols.ibm,comp.sys.hp Subject: tn3270 mapping for HP workstations
I send you this message below for a friend. If you decide to answer, could you
please send him your suggestions directly? (mzahn@autelca.ascom.ch) Thanks.
Daniel
######################################################################
Programm Documentation for tn3270 - full screen remote login to IBM AS/400
In our company we use HP and SUN workstations for the product development.
On the commercial side we have an IBM/AS400 for the product planning (PPS).
It is essential that our engineers have the possibility of a direct access
to the IBM-AS/400 system with the TELNET-emulation.
We have at our disposal a version of the public domain software tn3270
and we have examined this product.
Our intention is to map the HP/SUN Keyboards to the IBM 5250 Keyboards which
caused us a problem :
- The HP Keyboard has different keys which dont produce an esqcape sequence
so we must use the HIL-Interface to fetch this keys. For this we must write
an own C-programm which conforms to this functionality. For the keys which
delivers an escape sequence we can use the map file /etc/map3270, this keys
are not the problem. But we want to use also the other keys on the HP46021A
keyboard.
- Where do we have to build in our own code in the existing tn3270 code ?
- It takes a lot of time to find out which is the correct tn3270 module ?
Please send us detailled information (if possible) about the programm design
of tn3270 by E-Mail. Thanks a lot..
We would be very happy to here from you !
Martin
######################################################################
Additional notes:
- HP's are HP9000/3xx
- we have sligthly adapted code for HPUX 7.0. (from iris613.gsfc.nasa.gov)
- tn3270.hp runs fine with keys mapped on ctrl-shift-xy keys, but we want to
use the function keys f1-f8 and for f9-f12 (f21-f24) the keys, Martin
mentioned above.
- The question is, where to begin for implementing the solution for the HIL
keys. Any hint from you, to expand which module, function or file would be
the best way to do it, would be greatly appreciated.
- I guess this could be the first step for a patch to tn3270 ?
Thanks a lot..
Daniel
--
Daniel Huber AD-KT2.6 VOICE: +41 31 52 96 64 FAX: +41 31 52 97 51
Ascom Autelca AG Network Engineer ( Network, E-Mail, News )
CH-3073 Guemligen EMAIL: dhuber@autelca.ascom.ch
Switzerland UUCP: uunet!{chsun,chx400}!hslrswi!aut!dhuber
--
Daniel Huber AD-KT2.6 VOICE: +41 31 52 96 64 FAX: +41 31 52 97 51
Ascom Autelca AG Network Engineer ( Network, E-Mail, News )
CH-3073 Guemligen EMAIL: dhuber@autelca.ascom.ch
Switzerland UUCP: uunet!{chsun,chx400}!hslrswi!aut!dhuber
-----------[000107][next][prev][last][first]---------------------------------------------------- Date: 10 Aug 91 09:00:23 GMT From: skl@wimsey.bc.ca (Samuel Lam) To: comp.protocols.tcp-ip Subject: Re: ftp-data service ?
In article <26748@natinst.natinst.com>, brian@natinst.com (Brian H. Powell) wrote: >On SunOS, in /etc/services, there's an entry for: > ftp-data 20/tcp >I'm wondering what ftp-data is used for. Near as I can tell, FTP uses >port 21. What's the scoop? FTP uses port 21 for commands and responses, but uses port 20 to transfer the actual file data. ...Sam -- <skl@wimsey.bc.ca>
-----------[000108][next][prev][last][first]---------------------------------------------------- Date: 10 Aug 91 22:40:47 GMT From: marikar@digrev.UUCP (Mo) To: comp.protocols.tcp-ip Subject: Not on mailing list. Need benchmarking tool
Hi, I am in the process of reviewing terminal servers that have Telnet to LAT conversion capabilities. Is there any benchmarking tool in the public domain area that will allow me to quantify throughput and character response time for terminal servers ? Thanks. /Mo Marikar Digital Review Labs.
-----------[000109][next][prev][last][first]---------------------------------------------------- Date: 10 Aug 91 22:48:10 GMT From: barmar@think.com (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: Gratuitous ARP
In article <1991Aug10.012720.7148@odin.corp.sgi.com> coolidge@speaker.UUCP (Don Coolidge) writes:
>In article <236@s5000.rsvl.unisys.com> rae@s5000.rsvl.unisys.com (Rick Erickson x2132) writes:
>>I've heard references to 'gratuitous ARP'. Can anybody explain this?
>Probably when the act of configuring an interface with an IP address causes
>the host to send out an ARP request for that address over that interface.
>Nobody will answer, but everyone who refreshes his cache will get a guaranteed
>up-to-date IP address to match with the meduim address.
Sometimes someone *does* answer, in which case you know that there's a
configuration problem. When SunOS receives a reply to its unsolicited ARP,
it reports "Duplicate IP address". On the occasions where I've seen this,
the problem wasn't actually that two hosts had the same IP address (most of
our Suns get their IP addresses using RARP), but that the Sun was connected
to the wrong subnet for its IP address; we have a cisco router that does
proxy ARP, and it was responding to the unsolicited ARP.
--
Barry Margolin, Thinking Machines Corp.
barmar@think.com
{uunet,harvard}!think!barmar
-----------[000110][next][prev][last][first]---------------------------------------------------- Date: 10 Aug 91 23:18:00 GMT From: henry@zoo.toronto.edu (Henry Spencer) To: comp.protocols.tcp-ip Subject: Re: TFTP block counter
In article <9108060700.AA08124@crayamid.cray.com> mni@CRAYAMID.CRAY.COM (Michael Nittmann) writes: >just a comment: the problem is probably not Mbytes, but the question of 32kB >or (unsigned, one more bit) 64kB blocks buffered on a 16 bit machine. No, this is entirely a non-issue for TFTP, whose blocks are at most 512 bytes. The problem is that its sequence numbers for blocks are only 16 bits long. -- Arthritic bureaucracies don't tame new | Henry Spencer @ U of Toronto Zoology frontiers. -Paul A. Gigot, WSJ, on NASA | henry@zoo.toronto.edu utzoo!henry
-----------[000111][next][prev][last][first]---------------------------------------------------- Date: 10 Aug 91 23:25:16 GMT From: henry@zoo.toronto.edu (Henry Spencer) To: comp.protocols.tcp-ip Subject: Re: Finger server as a requirement for all Internet hosts
In article <1991Aug09.165839.21578@ecst.csuchico.edu> rgoldstone@OAVAX.CSUCHICO.EDU writes: >I would like to see a requirement for all Internet domains to operate a >finger (or whois) server to serve the top-level domain at their site. >I often have users come to me and say "I want to send e-mail to my colleague >at the University of XYZ. Is there some way I can look up their address?" The correct answer to such a question is: "Phone him up and ask. That way you can also ask whether he reads his mail regularly." Between people with multiple accounts, people with very similar names (there are two professors named "A. Zimmerman" in our department, for example), people on vacation, and people who have accounts but seldom or never read their mail, a directory lookup service simply is not an adequate solution. -- Arthritic bureaucracies don't tame new | Henry Spencer @ U of Toronto Zoology frontiers. -Paul A. Gigot, WSJ, on NASA | henry@zoo.toronto.edu utzoo!henry
-----------[000112][next][prev][last][first]---------------------------------------------------- Date: 11 Aug 91 17:40:47 GMT From: allyn@sleepy.UUCP (Mark Allyn) To: comp.unix.questions,comp.protocols.tcp-ip Subject: Using both /etc/hosts and domain name server to get host addrs
I have a situation here where I need to have some machines access both the /etc/hosts file and the domain name server for host name and address resolution. Our site has Suns running sunos 4.1.1. We use network file system and NIS extensively throughout the site therefore the machines need to access the /etc/hosts (which is NIS mapped) so they can know where to access NFS files at boot time. Currently, we are not using the name server that is being established for the company but we are thinking about connecting to it. I am concerned because once we connect to it (by establishing a resolv.conf file) we may no longer have access to the /etc/hosts file locally. We have requirement where we have to set up temporary machines in our network which we dont want to have listed in the domain name server but we want to put in the local NIS host map or the machine's local /etc/hosts file. I have tried the manuals and some experimenting and found: 1. The manuals were not clear on how to have the gethost functions access both the domain name server and the local host files. 2. A local site that I have an account on using a Vax running ULTRIX seems to have done the trick, but I poked around and could not see anything special with their resolv.conf file and they are running as a domain server (no named.boot files and nothing in rc files to start the named daemon). 3. Another site that I have access to which is running resolv but not a name server (a Sun running sunos 4.0.3) will not access both the name server and the /etc/hosts file at the same time. ( I tried to rlogin into itself using the name of the machine without the domain name and it could not find it) I would greatly appreciate any help you folks may have. Thanks! Mark Allyn 206-526-8852 206-865-4699
-----------[000113][next][prev][last][first]---------------------------------------------------- Date: 12 Aug 91 01:01:00 GMT From: small@turing.seas.ucla.edu (James F. Small) To: comp.protocols.tcp-ip Subject: subscribe
Please subscribe me to the mailing list
-----------[000114][next][prev][last][first]---------------------------------------------------- Date: 12 Aug 91 04:56:48 GMT From: jeff@onion.rain.com (Jeff Beadles) To: comp.unix.questions,comp.protocols.tcp-ip Subject: Re: Using both /etc/hosts and domain name server to get host addrs
allyn@sleepy.UUCP (Mark Allyn) writes: >I have a situation here where I need to have some machines access >both the /etc/hosts file and the domain name server for host name >and address resolution. Well, I had the same problem when we connected to the Internet. I didn't see an apparent solution, so I ended up modifying gethostbyxxx, in libc/libresolv. If you would like a copy of this, please let me know. Basically it understands DNS/bind, and /etc/hosts. I have no use for YP/NIC, so I didn't bother. The order of resolution is configurable. Drop me a note if you would like a copy. It's no harder to install than adding the resolver stuff to libc. -Jeff -- Jeff Beadles jeff@onion.rain.com
-----------[000115][next][prev][last][first]---------------------------------------------------- Date: 12 Aug 91 06:21:22 GMT From: skl@cs.sfu.ca (Sam Lam) To: comp.protocols.tcp-ip,alt.sys.sun Subject: BSD 4.3-Reno routed(8C) on SunOS 4.1.1
Has anyone got the BSD 4.3-Reno/4.4 routed/in.routed(8C) sources running on a SunOS 4.1.1 SPARC? Please reply via mail, I will summarize. Thanks. ...Sam -- <skl@cs.sfu.ca>
-----------[000116][next][prev][last][first]---------------------------------------------------- Date: 12 Aug 91 11:05:57 GMT From: ccrth@lut.ac.uk (Rob Thirlby) To: comp.protocols.tcp-ip Subject: pc-nfs
We are trying to set up a class room of IBM LEO ie PS2/55 machines packaged with a modified Western Digital Ethernet board. We wish to run concurrently pc-nfs and novell (the pc-nfs is necessary to support a proprietary X-windows product). We seem to have two problems 1) is there a packet driver for this IBM/wd ether board? 2) Is there any way of modifying/patching pc-nfs to make its printer capture mechanism use drives lower down the alphabet. Having to specify lastdrive=V clobbers novell's search path system which uses drive letters from Z upwards. Any help or experience on either fron would be appreciated. Rob Thirlby. .
-----------[000117][next][prev][last][first]---------------------------------------------------- Date: 12 Aug 91 11:06:01 GMT From: rbrickey@BBN.COM (Ron Brickey) To: comp.protocols.tcp-ip Subject: Removal
Please remove me from the subject mailinglist. --- ron
-----------[000118][next][prev][last][first]---------------------------------------------------- Date: 12 Aug 91 13:27:37 GMT From: bob@MorningStar.Com (Bob Sutterfield) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains Subject: Re: rejection of unregister host mail
In article <9108081056.AA07170@NISC.SRI.COM> dmritter@CBG-99SIMA.ARMY.MIL (Dave Ritter) writes: With the increased use of nameservers on the Internet, many many hosts are not registered in the hosts.txt file. Therefore, these "unregister" hosts do not get into the Sperry's /etc/hosts file. This leads to a problem with MMDF.S04. When an unregister host sends mail to a Sperry, it is rejected... See RFC-1031 of November 1987. Since October 1989, when the use of the host table was discontinued and the Milnet's mandatory conversion to the use of domain name service was expected to be completed, hosts represented in a nameserver are more "registered" than those in hosts.txt. Sperry has come catching up to do.
-----------[000119][next][prev][last][first]---------------------------------------------------- Date: 12 Aug 91 18:29:53 GMT From: jason@hpcndjdz.CND.HP.COM (Jason Zions) To: comp.protocols.tcp-ip Subject: Re: POSIX Interface to TCP/IP
The POSIX working group which is developing a set of standards for Protocol- Independent Interfaces is 1003.12, chaired by Les Wibberley (lhw25@cas.bitnet). To get current drafts, you really should join the mailing list; for one-time only sorts of things, contacting the chair should work. Wibberley, Les Chemical Abstracts Service P.O. Box 3912 Columbus, OH 43210 As was observed, the interfaces are not TCP or UDP specific, and are instead aimed at being more generic interfaces independent of protocol. -- This is not an official statement of the IEEE, POSIX, or HP. No warranty is expressed or implied. The information included herein is not to be construed as a committment on anyone's part. I'm not speaking on anyone's behalf. Jason Zions The Hewlett-Packard Company Chair, P1003.8, POSIX TFA 3404 E. Harmony Road Mail Stop 102 Ft. Collins, CO 80525 USA jason@cnd.hp.com (303) 229-3800
-----------[000120][next][prev][last][first]---------------------------------------------------- Date: 12 Aug 91 18:40:56 GMT From: simon@fuquad.westford.ccur.com (Simon Rosenthal) To: comp.protocols.tcp-ip Subject: Re: Gratuitous ARP
In article <1991Aug10.012720.7148@odin.corp.sgi.com> coolidge@speaker.UUCP (Don Coolidge) writes: >In article <236@s5000.rsvl.unisys.com> rae@s5000.rsvl.unisys.com (Rick Erickson x2132) writes: >>I've heard references to 'gratuitous ARP'. Can anybody explain this? >> ... >Probably when the act of configuring an interface with an IP address causes >the host to send out an ARP request for that address over that interface. >Nobody will answer, but everyone who refreshes his cache will get a guaranteed >!!!!!!!!!!!!!!!!!! >up-to-date IP address to match with the meduim address. > >- Don Coolidge Well, they do occasionally (even in the most carefully managed networks !). Concurrent has a "DUPLICATE IP ADDRESS !!!" message logged and printed out on the system console, along with the MAC address that generated the ARP reply, so that the system/network manager can resolve the conflict. - Simon _______________________________________________________________________________ Simon Rosenthal: ___________ Concurrent Computer Corporation / _________/_ Westford, MA 01886 /_/________/ / Internet: simon@westford.ccur.com /__________/
-----------[000121][next][prev][last][first]---------------------------------------------------- Date: 12 Aug 91 19:04:05 GMT From: ddl@husc6.harvard.edu (Dan Lanciani) To: comp.protocols.tcp-ip Subject: Re: behavior when receiving >1 ARP REPLY
In article <1991Aug1.002101.17581@telebit.com>, brunner@telebit.com (Eric Brunner) writes: | While pessimal routes are a problem, the undocumented semantics of the 3rd | bit in the RIF cause more problems in the unicast reply, but that is another | subject. What are these undocumented semantics? Dan Lanciani ddl@harvard.*
-----------[000122][next][prev][last][first]---------------------------------------------------- Date: 12 Aug 91 19:06:51 GMT From: jbvb@ftp.com (James B. Van Bokkelen) To: comp.protocols.tcp-ip Subject: Re: TN term type
Terminal Type as originally designed (RFC 930) was a simple way of letting
the client tell the server what kind of terminal it was. RFC 1091 added
support for clients (PCs or the like) which could be several different
kinds of terminal, so the server could pick the one which was the best
match. The specific problems I was trying to solve were: First, to eliminate
the need for human intervention when one Telnet client was used to talk to
several different hosts (e.g. mainframes and unix boxes), and second, to
allow the server to ask the client to change the type of emulation in mid-
session (e.g. so applications that work best with different terminals can
be used together).
I didn't try to deal with the more general issue of what happens when the
terminal type the host or application wants doesn't match any of those the
client can provide. The user loses, as usual, and the only items in
question are when and how he/she finds out. Since you can't know the
particular combination of applications and functions the user wants before
they try, I vote for the status quo, or maybe a mild "I can only handle
these terminal types {list} that your client supports as NVT Ascii"
warning message from the server at login time.
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000123][next][prev][last][first]---------------------------------------------------- Date: 12 Aug 91 19:06:53 GMT From: jbvb@ftp.com (James B. Van Bokkelen) To: comp.protocols.tcp-ip Subject: Re: Protocol analyzers
There are a number of software network monitors/protocol analyzers out there, including LANWatch from FTP Software, WIN/Watch (may have been renamed recently) from Wollongong and WatchTower from Intercon. These use an existing PC (or Mac in the case of WatchTower) and network interface, and tend to cost between 1/10th and 1/100th of the price of a similarly-equipped high-end product. There's also Netwatch, which is free as part of the MIT/CMU/Harvard PCIP software package. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000124][next][prev][last][first]---------------------------------------------------- Date: 12 Aug 91 19:22:00 GMT From: gmc@premises1.quotron.com (Greg Christy) To: comp.protocols.tcp-ip Subject: Subnet Practice?
While it is recommended practice to make subnet bits contiguous and
use the most significant bits of the local address (for sanity's
sake), it is not required. See the following RFC excerpts:
From RFC 950 (Internet Standard Subnetting Practice):
"Since the bits that identify the subnet are specified by a
bitmask, they need not be adjacent in the address. However, we
recommend that the subnet bits be contiguous and located as the
most significant bits of the local address."
From RFC 1122 (Requirements for Internet Hosts -- Communications Layers):
We now summarize the important special cases for Class A, B,
and C IP addresses, using the following notation for an IP
address:
{ <Network-number>, <Host-number> }
or
{ <Network-number>, <Subnet-number>, <Host-number> }
and the notation "-1" for a field that contains all 1 bits.
This notation is not intended to imply that the 1-bits in an
address mask need be contiguous.
-----------[000125][next][prev][last][first]---------------------------------------------------- Date: 12 Aug 91 19:41:13 GMT From: carroll@ssc-vax (Jeff Carroll) To: comp.protocols.tcp-ip Subject: Re: Finger server as a requirement for all Internet hosts
In article <868@philica.ica.philips.nl> geertj@ica00.ica.philips.nl (Geert Jan de Groot) writes: >In article <1991Aug09.165839.21578@ecst.csuchico.edu> rgoldstone@OAVAX.CSUCHICO.EDU writes: >>I would like to see a requirement for all Internet domains to operate a >>finger (or whois) server to serve the top-level domain at their site. > >Second, the site might distribute mail internally via aliases, so there is no >account for that user on the mailhost, and no finger info.. There are now several domains that are nationally if not internationally distributed (.boeing.com now has sites in at least five states across the country, and others, particularly large computer manufacturers, are even more widely distributed). In our case, the people who operate the gateway have no control over or information about users of other machines; and in any case, the company considers such information to be proprietary (one reason is to make unsolicited contacts from outside difficult, in order to dissuade persistent salesmen. Stockbrokers are particularly notorious.) Corporations that are cognizant of whois and finger generally disable them; and it's quite often wrong to assume that people who perform and publish research are connected to Internet, even in the USA, especially if they work in the corporate sector. -- Jeff Carroll carroll@ssc-vax.boeing.com
-----------[000126][next][prev][last][first]---------------------------------------------------- Date: 12 Aug 91 20:16:20 GMT From: map@isi.edu (Michael Padlipsky) To: comp.protocols.tcp-ip Subject: Re: Sub standard FTP implementation
Alex (and other protocol arachaeologists)-- Hmmmmm. You appear to have been having meetings behind my back -- or were RFCs 171/2 complete solos? (Or was I too busy in May and June of '71 getting Multics Telnet on the air by the July 1 deadline to attend?) No, on closer inspection you do say "CO-author"; eliminate solo option, anyway. Re-hmmm. At any rate, I must concede that your EMAM is NOT worse than mine on this one, given the RFC 354 evidence in particular, since that was based on meetings I did attend. Of course, RFC 354 was very flawed (containing, e.g., the infamous Mail should be free, I.E. not require a login solecism, where it SHOULD have said "e.g."), so maybe we had INTENDED a minimum implementation list be in it.... (Now I'll probably hear it from Abhay.) Well, that's a quibble, I guess. Still, I'll take partial credit, since I DID use the metaphor w/r/t Telnet (independently of your use w/r/t FTP, clearly) and the minimum implementation lists WERE in RFCs 542ff. Besides, 1971 is certainly MUCH closer to 20 years ago than to 15, even if that only speaks to our respective Early MiddleAged Arithmetic. Perhaps we should call it a draw. Whatever it was we were talking about.... Heh, heh. Rashomoniacal cheers, map
-----------[000127][next][prev][last][first]----------------------------------------------------
Date: 12 Aug 91 20:51:31 GMT
From: tundra@eskimo.chi.il.us ("Tundra" Tim Daneliuk)
To: comp.protocols.tcp-ip
Subject: ruptime and multiple networks
(Hope this is the right place to ask...)
I am responsible for a small IP-based network in my department. This network
is NOT connected to the Internet, but does have NIC-assigned IP addresses.
Some of the hosts are connected to a thin-Ethernet, the others are connected
to a 4 MB/sec Token Ring a' la IBM. The Ethernet and Token Ring each have
their own, unique Class C address space. We are using a CISCO MGS router to
establish logical ip connectivity between the two spaces.
I've got everything working (i.e. any host can see any other host on either
the Ethernet or Token-Ring via rlogin, telnet, etc.) except for one strange
thing: When I do an 'ruptime' I see only the hosts on the network where I
am currently logged-in.
Is this correct ruptime behaviour? I've tried fiddling with the MGS
configuration to try and make sure UDP broadcasts are making it through the
router, but so far I can't get 'ruptime' (and for that matter 'rwho') to
see anything on the "other side" of the router.
TOPOLOGY:
Sys V.3.2 / Intel 486 / -> Ethernet
BSD 4.3 - Mach / Intel 386/ -> Ethernet
AIX/ Intel 386 (PS/2) / -> Token Ring
PC Running Wollongong Pathway Software -> Token Ring
PCs Running NCSA Telnet -> Ethernet
Comments anyone? (Probably should be mailed to me.)
------------------------------------------------------------------------------
"Tundra" Tim Daneliuk
PREFERRED: tundra@eskimo.chi.il.us
OR (Yuk!): eskimo!tundra@clout.chi.il.us
ALSO: ...uunet!gargoyle.uchicago.edu!clout!eskimo!tundra
------------------------------------------------------------------------------
-----------[000128][next][prev][last][first]---------------------------------------------------- Date: 12 Aug 91 21:35:46 GMT From: young@alw.nih.gov (Jeff Young) To: comp.protocols.tcp-ip,comp.dcom.lans Subject: Re: Protocol analyzers
Look at the Wandel and Goltermann. Does two ethernets at a time - real-time. Also has slots for token-ring and a promised fddi card. 919 460-3312 -- ___________ jy young@heart.dcrt.nih.gov
-----------[000129][next][prev][last][first]---------------------------------------------------- Date: 12 Aug 91 22:05:05 GMT From: bstratton@hns.com (Bob Stratton) To: comp.protocols.tcp-ip Subject: What's your IP Time to Live?
Hello all, I've just had to bump my IP Time-To-Live to compensate for some of the recent routing changes on the Internet. Would any of you system administrators, especially those running Apollo or HP workstations, let me know what you currently have your IP Time-To-Live set to? I need to make a presentation to management-types, and could use all of the ammo I can get. If you're wondering where this value is set, on SR.10.3.4 of Domain/OS, it's in file /etc/rc.local, on the line where /etc/tcpd is started. If you see a "-t" switch, that's the value. (BTW, I jacked mine up to "3c" hexadecimal, which seemed to cure a lot of problems. Please respond directly to me, as I'm temporarily off of the list. All replies are welcome. Thanks in advance, Bob Stratton | Hughes Network Systems | SMTP: bstratton@hns.com Germantown, Maryland | PSTN: +1 301 409 2703 "Personally, I think the DNS administrative interface was designed by the IRS." --Mark Beyer
-----------[000130][next][prev][last][first]---------------------------------------------------- Date: 12 Aug 91 22:07:35 GMT From: sak@cdg.chalmers.se (Anders Karlsson) To: comp.protocols.tcp-ip Subject: Re: Finger server as a requirement for all Internet hosts
First rgoldstone@OAVAX.CSUCHICO.EDU writes: I often have users come to me and say "I want to send e-mail to my colleague at the University of XYZ. Is there some way I can look up their address?" And then Henry Spencer writes: The correct answer to such a question is: "Phone him up and ask. That way you can also ask whether he reads his mail regularly." Between people with multiple accounts, people with very similar names (there are two professors named "A. Zimmerman" in our department, for example), people on vacation, and people who have accounts but seldom or never read their mail, a directory lookup service simply is not an adequate solution. In favor for the world wide electronic directory I must argue against Henry, and make the folowing statement instead. In the near future the correct answer will hopefully be: Look him up in "the directory" (read X.500). This have the potential to work better. For example, if he is on vacation he will not answer his phone. Also, in the directory there could, possibly, be included information on how often he reads his mail. -- Anders Karlsson
-----------[000131][next][prev][last][first]---------------------------------------------------- Date: 12 Aug 91 22:13:37 GMT From: oldera@twg.com (Ed R. Alcoff) To: comp.protocols.tcp-ip,comp.dcom.lans Subject: Re: Protocol analyzers
Don't forget the Novell LANalyzer (originally from Excelan?). It's been around longer than most, I believe. Cheers, Ed Alcoff
-----------[000132][next][prev][last][first]---------------------------------------------------- Date: 12 Aug 91 22:22:21 GMT From: slimick@unix.cis.pitt.edu (John C Slimick) To: comp.sys.att,comp.protocols.tcp-ip Subject: Re: 3B2 Ethernet problems.
I had problems with the NIC and Cabletronics enet MAU on our 3b2/400 at bootup time. It seems that the NIC diagnostics failed every time. My solution was to isolate the 3b2 (put 2 50 ohm terminators on the MAU while putting a barrel connector to connect the two parts of the enet). Then I could boot up with no difficulty. Once up and running, I would reconnect the network and the MAU. I'm using a Black Box MAU now, and I don't recall having as many bootup problems. John Slimick slimick@unix.cis.pitt.edu
-----------[000133][next][prev][last][first]---------------------------------------------------- Date: 12 Aug 91 22:31:16 GMT From: stevo@elroy.jpl.nasa.gov (Steve Groom) To: comp.protocols.tcp-ip Subject: Re: Finger server as a requirement for all Internet hosts
In article <1991Aug09.165839.21578@ecst.csuchico.edu> rgoldstone@OAVAX.CSUCHICO.EDU writes:
>
>I would like to see a requirement for all Internet domains to operate a
>finger (or whois) server to serve the top-level domain at their site.
[...]
>This
>would parallel the function of the telephone directory assistance service.
Well, in a sense this form of service already exists. And just like
telephone directory assistance, folks can choose to be unlisted. It's
just that in the case of the Internet, not a whole lot of folks have
chosen to be listed! If organizations feel that this is a service
worth providing (and one that they want "outsiders" to have access to),
they will. Mandating such a service is probably not a workable idea,
for the same reason that many companies prohibit (or limit) external
distribution of their internal telephone directories.
-steve
--
Steve Groom, Jet Propulsion Laboratory, Pasadena, CA
stevo@elroy.jpl.nasa.gov {ames,usc}!elroy!stevo
"... and the babe, she needs a chaaaa--nging..." (apologies to Bob Dylan)
-----------[000134][next][prev][last][first]---------------------------------------------------- Date: 12 Aug 91 23:37:10 GMT From: coolidge@speaker.sgi.com (Don Coolidge) To: comp.protocols.tcp-ip Subject: Re: Gratuitous ARP
In article <1991Aug10.224810.6202@Think.COM> barmar@think.com writes: >In article <1991Aug10.012720.7148@odin.corp.sgi.com> coolidge@speaker.UUCP (Don Coolidge) writes: >>In article <236@s5000.rsvl.unisys.com> rae@s5000.rsvl.unisys.com (Rick Erickson x2132) writes: >>>I've heard references to 'gratuitous ARP'. Can anybody explain this? >>Probably when the act of configuring an interface with an IP address causes >>the host to send out an ARP request for that address over that interface. >>Nobody will answer, but everyone who refreshes his cache will get a guaranteed >>up-to-date IP address to match with the meduim address. > >Sometimes someone *does* answer, in which case you know that there's a >configuration problem. When SunOS receives a reply to its unsolicited ARP, >it reports "Duplicate IP address". On the occasions where I've seen this, >the problem wasn't actually that two hosts had the same IP address (most of >our Suns get their IP addresses using RARP), but that the Sun was connected >to the wrong subnet for its IP address; we have a cisco router that does >proxy ARP, and it was responding to the unsolicited ARP. Absolutely right about the duplicate IP address. That particular reply isn't all that rare, especially on nets with gobs of PCs. Everyone who implements unsolicited ARPs uses that, I'm sure. However, you've raised a religious question by bringing up Proxy ARP...shall I dive in?...sure! :^) Definitive Statement: It is Poor Design to use a Link Level protocol to do Network Level routing. You want to solve a Network Level problem, you Should Do It at the Network level. Amen. (Even if it is convenient...) Not to mention that anyone silly enough to use Proxy ARP in conjunction with default routes (as many older implementations still do, but hopefully fewer as static routes become thankfully a thing of the past) can doom his application to sending packets out into the Internet to die a long and painful TTL death, and never get a "host unreachable" reply. - Don Coolidge coolidge@sgi.com
-----------[000135][next][prev][last][first]---------------------------------------------------- Date: 13 Aug 91 01:24:27 GMT From: sfrazier@mcinix.vlink.COM (Steven E. Frazier) To: comp.protocols.tcp-ip Subject: ka9q
I have some questions after reading the docs with ka9q. Could someone email me if they have used the ka9q for use as a router? I am interested in setting up ka9q as a router and have a few questions. Thanks in advance Steve -- Steven E. Frazier DID: (614) 761-6612 VNET: 424-6612 FAX: (614) 761-6679
-----------[000136][next][prev][last][first]---------------------------------------------------- Date: 13 Aug 91 03:44:57 GMT From: barmar@think.com (Barry Margolin) To: comp.protocols.tcp-ip Subject: Proxy ARP (was Re: Gratuitous ARP)
In article <1991Aug12.233710.23310@odin.corp.sgi.com> coolidge@speaker.UUCP (Don Coolidge) writes:
>Definitive Statement: It is Poor Design to use a Link Level protocol to do
>Network Level routing. You want to solve a Network Level problem, you Should
>Do It at the Network level. Amen.
I agree. The first time I saw proxy ARP result in a workstation
complaining about a duplicate IP address, my immediate response was to turn
off proxy ARP on the cisco router. Unfortunately, this suddenly cut off
many of our Macintoshes, which were apparently running a flavor of TCP/IP
that didn't have subnet support (or maybe the subnet masks weren't
configured properly). Rather than run around manually reconfiguring a
hundred Macs, it was simpler to re-enable proxy ARP.
>Not to mention that anyone silly enough to use Proxy ARP in conjunction with
>default routes (as many older implementations still do, but hopefully fewer
>as static routes become thankfully a thing of the past) can doom his
>application to sending packets out into the Internet to die a long and painful
>TTL death, and never get a "host unreachable" reply.
This is just a problem with default routes, not proxy ARP. But it's really
only a problem if all the routers are using default routes. In real life,
you'll eventually encounter a router that doesn't have a default route, and
it will send a host unreachable back.
--
Barry Margolin, Thinking Machines Corp.
barmar@think.com
{uunet,harvard}!think!barmar
-----------[000137][next][prev][last][first]----------------------------------------------------
Date: 13 Aug 91 07:56:03 GMT
From: imo2@cann.stuttgart-emh1.army.mil ("William Dugger at Bad Cannstatt")
To: comp.protocols.tcp-ip
Subject: Registration of non-NIC host userI am not on a NIC registered host, but I am registered with the NIC. Please send me your listing at either my primary address which is in the NIC table imo2@bdcnnsdt-amedd.army.mil or my alternate imo2@stuttgart-emh1.army.mil Please subscribe me to your list: William Daniel Dugger, System Administrator 5th General Hospital, Information Management Office ATTN: AEMBC-IMO APO New York 09154-3345 DSN 4222-810 or 0711-5201-810 (Bad Cannstatt, Germany) Electronic Mail: imo2@bdcnnsdt-amedd.army.mil Alternative: imo2@stuttgart-emh1.army.mil Bill CANN
-----------[000138][next][prev][last][first]---------------------------------------------------- Date: 13 Aug 91 09:33:18 GMT From: clu@malihh.hanse.de (Carsten Lutz) To: comp.protocols.tcp-ip,comp.unix.xenix.sco,comp.unix.sysv386,comp.unix.questions Subject: DialUp-IP and SCO-Unix ???
Hello ! We would like to install DialUp-SLIP on our host running SCO-Unix. There are 5 serial ports thie T2500-Modems available over wich we want to run DialIn - SLIP-Connections and DialIn/DialOut UUCP & Terminalsessions. As I understand, the SLIP-implenentation delivered with SCO-Unix is only for hard-wired SLIP-Connections. This is not what we want. I would like to know if there is somewhere a package out there that allows SCO-Unix to managa real *DialUp* SLIP - Connections. DialIn would suffice. And it should also allow SLIP-Connection to multiple hosts on the same line. ( At different times of course, I don't want a wonder, just SLIP. ;-) If such a packet doesn't exist, wich one might be relatively easy to port to SCO ? please answer via email. greetings, Carsten -- * Carsten Lutz, Rellingen, FRG / clu@malihh.hanse.de ( NeXTmail accepted ) * * Voice : +49 4101 207871 Fax: +49 4101 27757 Traily : +49 4101 22306 * ---------------------------------------------------------------------------- * Why do birds sing ? *
-----------[000139][next][prev][last][first]---------------------------------------------------- Date: 13 Aug 91 14:27:58 GMT From: rgoldstone@OAVAX.CSUCHICO.EDU (Robin Goldstone) To: comp.protocols.tcp-ip Subject: Re: Finger server as a requirement for all Internet hosts
Well, I have seen enough followup postings and private e-mail replies to realize that finger is apparently not a popular service for most of you. I hadn't given much thought to the negative uses of finger: unwarranted solicitation, junk e-mail, privacy violations... I was just thinking in terms of providing a way for users with legitimate reasons for using e-mail to determine someone's address. I guess they'll just have to stick to calling them on the phone and asking them for their address. -Robin *********************************************************************** Robin Goldstone, Systems Software Specialist California State University, Chico Computing Services rgoldstone@oavax.csuchico.edu
-----------[000140][next][prev][last][first]---------------------------------------------------- Date: 13 Aug 91 14:33:47 GMT From: jonson@NISC.SRI.COM (1Lt Matthew W. Jonson) To: comp.protocols.tcp-ip Subject: LaTeX
I know that this isn't strictly a topic that belongs on this list, but I wonder if someone could give me some information. I have run across some documentation that is in LaTeX format. I was wondering where I could get the latex formatting program. Is it public domain? Any pointers appreciated. I would like to put it up on an AT&T 3B2 but there are other Unix machines available. Thanks in advance. Please e-mail me direct. /matt -- Lt Matthew W Jonson jonson@server.af.mil snail-mail: Network Systems Engineer 205-279-4075 SSC/SSMT USAF DDN Program Office AV: 596-4075 Gunter AFB, AL 36114
-----------[000141][next][prev][last][first]---------------------------------------------------- Date: 13 Aug 91 16:45:29 GMT From: lac@HPLB.HPL.HP.COM (Laurence Crutcher) To: comp.protocols.tcp-ip Subject: Network Status Information
I have a requirement to obtain status information from the Unix kernel, giving details of the network interface configuration together with relevant performance information. The type of information that I want is very similar to that given by the netstat command, with appropriate options. However, I want to get this information into a known form inside a C program. Can somebody tell me how netstat is implemented. Is it based on ioctl commands, and if so which ones? Pushing my luck further, is there a site where I can get the source code for this command? Thanks for any help Laurence ====================================================================== Laurence Crutcher Hewlett Packard Laboratories e-mail: lac@hplb.hpl.hp.com Filton Road lac@hplb.hpl.hp.co.uk Stoke Gifford Tel: (0272) 799910 Bristol BS12 6QZ Fax: (0272) 790554 UK. ======================================================================
-----------[000142][next][prev][last][first]---------------------------------------------------- Date: 13 Aug 91 16:53:19 GMT From: art@opal.acc.com (Art Berggreen) To: comp.protocols.tcp-ip Subject: Re: A new dump question
In article <9108060906.AA18619@NISC.SRI.COM> aets-kja-a-ao3@ANSBACH-EMH1.ARMY.MIL ("Thomas F. Pockberger") writes:
>Sorry but I am REALLY new to TCP/IP.
>
>here is my question:
>
>If two Internet sites establish a connection it normally goes thru a couple
>of "hops". Each of them uses one TTL count on the packets. Is there
>something like a "return receipt" from the receiving machine which also
>has TTLs and uses them.
If the connection uses TCP, the TCP data sent one way is acknowledged
by the ACK field of a packet going the opposite way.
>Sample:
>I conect to a host, some of the packet goes thrue 13 hops but most thru
>16 hops. TTL is set to 15 on our machine. So the packets with 13 hops get
>thru the 16 hops not. Can the result be something like "timed out".?
From a user perpective, this could definitly happen. There is an ICMP
error message that is supposed to be sent back when the IP TTL goes to 0,
but that event often is not conveyed to the application affected.
>If the receiving machine is sending acknowledgement on the 13 hops packet
>can this result in a kind of "loose" connection. (connect; permission denied)
Unlikely that a permission denied error would occur in this case.
>Sorry if this is a dump question. Can somebody shine a light on me.
>
>Pocky
Hope this helps,
Art
-----------[000143][next][prev][last][first]---------------------------------------------------- Date: 13 Aug 91 16:58:47 GMT From: art@opal.acc.com (Art Berggreen) To: comp.protocols.tcp-ip Subject: Re: Gratuitous ARP
In article <236@s5000.rsvl.unisys.com> rae@s5000.rsvl.unisys.com (Rick Erickson x2132) writes: >I've heard references to 'gratuitous ARP'. Can anybody explain this? My >understanding is that hosts and routers that receive an ARP Request will >refresh their ARP caches, but that is how ordinary ARP works, so what is >'gratuitous ARP'? This probably refers to the behavior of sending an ARP request to yourself when the interface first comes up. This has two effects. First it lets everyone cache your ARP information (the gratuitous effect) and lets you check for IP address conflicts. >Another question is whether there are any ARP implementations that do not >refresh their ARP cache when a broadcasted ARP Request is seen? I've seen some pretty limited ARP implementations out there, so I would imagine there are some like that. > Rick Erickson Art
-----------[000144][next][prev][last][first]---------------------------------------------------- Date: 13 Aug 91 18:39:53 GMT From: dls@mentor.cc.purdue.edu (David L Stevens) To: comp.protocols.tcp-ip Subject: Re: Gratuitous ARP
In article <1991Aug13.165847.3969@salt.acc.com>, art@opal.acc.com (Art Berggreen) writes: > when the interface first comes up. This has two effects. First it lets > everyone cache your ARP information (the gratuitous effect)... RFC 826 says you only add to the cache if the request is directed to you (and so you may be talking to that host soon) or it's a reply to a request you sent. You also update an existing entry, but in general, you don't just add every ARP reply that comes along to your translation cache, gratuitous or not. I think the two beneficial effects of gratuitous ARP are duplicate detection and making sure out-of-date translations are updated promptly (though this will happen with the timeout mechanism eventually, anyway). People adding this feature should consider the down side, as well. What happens when a power failure causes a hundred workstations to send extraneous ARP packets at the same time? I haven't read RFC 826 recently, so a conforming implementation may be able to add unsolicited translations to its cache, but you generally want the cache to be small, so whether it says you can or not, you probably wouldn't want to. Especially on large networks. -- +-DLS (dls@mentor.cc.purdue.edu)
-----------[000145][next][prev][last][first]---------------------------------------------------- Date: 13 Aug 91 21:33:32 GMT From: pa335371@longs.LANCE.ColoState.Edu (Paul E. Andrighetti) To: comp.protocols.appletalk,comp.protocols.tcp-ip,comp.protocols.ibm,comp.protocols.iso,comp.protocols.tcp-ip.ibmpc,comp.protocols.kerberos Subject: X.PC port to UNIX or VMS
Has anyone ever ported the protocol X.PC to UNIX or VMS? We will be using SCO System V for one implementation. X.PC is a asynchronous communication protocol that enables you to communicate errorfree and simultaneously with up to 15 separate destinations. This protocol came out in the early to mid 80's and was designed by TYMNET who is now BT North America. BT North America has not been any help in locating the right group(s). I know that it has already been ported, but can not find those resources. Any help that can point me in the right direction would be greatly appreciated. Please respond to the below EMAIL address as soon as possible. EMAIL: Paul_Andrighetti@stortek.com If not possible just reply to this news group. I apologize if this is the wrong group to post this message. Thank You, Paul E. Andrighetti StorageTek 2270 South 88th Street Louisville, CO 80028-2263 USA (303) 673-3063
-----------[000146][next][prev][last][first]---------------------------------------------------- Date: 14 Aug 91 06:19:04 GMT From: jos@bull.nl (Jos Vos) To: comp.protocols.tcp-ip Subject: Semantics of KEEPALIVE
Who can supply me the detailed semantics of the KEEPALIVE option in
4.3BSD-alike TCP/IP implementations.
What are the roles of the client and the server w.r.t. the so-called
keep-alive packets?
What I also want to know is what happens if the SO_KEEPALIVE option is set,
and what should happen if it is not set.
And what is "normal" for standard applications like telnet, rlogin etc.?
Do they have the option set or not?
Please E-MAIL responses to me. I'll summarize if that is wanted.
Thanks.
--
-- Jos Vos <jos@bull.nl> (UUCP: ...!{uunet,mcsun,hp4nl}!nlbull!jos)
-- Bull Nederland NV, Product Support Unix, Amsterdam, The Netherlands
-----------[000147][next][prev][last][first]---------------------------------------------------- Date: 14 Aug 91 12:22:21 GMT From: rickert@mp.cs.niu.edu (Neil Rickert) To: comp.protocols.tcp-ip Subject: Re: Finger server as a requirement for all Internet hosts
In article <3997@chalmers.se> sak@cdg.chalmers.se (Anders Karlsson) writes: >And then Henry Spencer writes: > The correct answer to such a question is: "Phone him up and ask. That > way you can also ask whether he reads his mail regularly." Between people >In favor for the world wide electronic directory I must argue against Henry, >and make the folowing statement instead. > > In the near future the correct answer will hopefully be: Look him up > in "the directory" (read X.500). > >This have the potential to work better. For example, if he is on >vacation he will not answer his phone. Also, in the directory there If he doesn't answer his phone, you are very likely to notice that when you call him. But if he doesn't read his email, you may never know. >could, possibly, be included information on how often he reads his >mail. Sure. Somebody who will not go to the trouble of occasionally logging in to read his mail is going to carefully maintain his X.500 directory info to inform people he doesn't read it. Not likely! -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
-----------[000148][next][prev][last][first]---------------------------------------------------- Date: 14 Aug 91 13:59:03 GMT From: ddj@zardoz.club.cc.cmu.edu (Doug DeJulio) To: comp.protocols.tcp-ip Subject: Re: Finger server as a requirement for all Internet hosts
In article <1991Aug14.122221.4214@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >>This have the potential to work better. For example, if he is on >>vacation he will not answer his phone. Also, in the directory there > > If he doesn't answer his phone, you are very likely to notice that when >you call him. But if he doesn't read his email, you may never know. This is untrue these days. That's one of the reasons I really, really hate answering machines and voice mail systems. -- Doug DeJulio ddj@zardoz.club.cc.cmu.edu (NeXT mail) dd26+@andrew.cmu.edu (AMS/ATK mail)
-----------[000149][next][prev][last][first]---------------------------------------------------- Date: 14 Aug 91 14:38:24 GMT From: chi@SPARTA.COM (Chi Chu) To: comp.protocols.tcp-ip Subject: (none)
Subject: NREN Hey folks, Can someone tell me what the NREN email address is? Thanks. Chi - SAIC
-----------[000150][next][prev][last][first]---------------------------------------------------- Date: 14 Aug 91 15:22:55 GMT From: jbev@iscden.jbsys.com ( J B Systems) To: comp.protocols.tcp-ip,comp.unix.sysv386,comp.sources.wanted Subject: Telnet daemon help
Net People,
I have been trying to get login to work on SCO UNIX 3.2. I am trying
to replace the telnet daemon with a custom version. I started with the
telnetd from the BSD source archives and am tring to get it to run on
SCO Unix before I start my hacking. I seem to be able to get connected
to the person attempting to log into the system, but from there, the
new daemon just hangs. If I do a ps, login is present. If the person
who is trying to login, types anything, I receive the data. I can
also send data back through the socket and see it displayed on his
system. I also recognize his quit command and can disconnect from
the network. I can not, however, seem to get the user logged in, or send
or receive any data from the assigned pty. Has anyone modified the BSD telnet
daemon to run on SYSV? I need to know the following:
1. How do you correctly allocate and provide the pseudo tty assignment
information to login so login can talk to the pty's? What is the
proper open, dup2, and close sequences for the ptys?
2. What is the proceedure to exec the login program and the proper
options. I am now using execl ("/bin/login", "login", -h, host, 0).
Where are the options documented? Where is the pty documented? I
have almost worn out the pages of the manuals looking.
If some kind person could send me some code samples of how to make
login connect to the pty and the telnet daemon, I would be greatful.
Also, if someone knows of a PD telnet daemon for SYSV that would be even
better. :-) I have ftp access. Any help would be welcome.
Thanks in advance.
Jim Bevier
jbev@jbsys.com
-----------[000151][next][prev][last][first]---------------------------------------------------- Date: 14 Aug 91 19:38:47 GMT From: dyer@motcid.UUCP (Bill Dyer) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: DOS - UNIX communcations.
Well, seeing as I am fairly ignorant when it comes to networking, I have several questions. What I want to do is write 2 applications, one for a UNIX box and one for a PC (running DOS, and no we can't run unix on the PC for various reasons). I would like the applications to be able to send messages (packets) back and forth over an ethernet link. I assume TCP/IP would be the way to do this, but I am clueless as to what software I need. I assume that most UNIX implementations have TCP/IP built in and I am aware of several TCP/IP packages for the PC. Now the questions: How hard is it to do the above? What software do I need to accomplish this? Any help would be greatly appreciated. -Bill -- _____________________________________________________________________________ | I wish I could sit on soft pillows, |Bill Dyer (708) 632-7081 | | and eat molten lava. | dyer@motcid.rtsg.mot.com | | -King Missle | or uunet!motcid!dyer |
-----------[000152][next][prev][last][first]---------------------------------------------------- Date: 14 Aug 91 20:24:34 GMT From: sak@cdg.chalmers.se (Anders Karlsson) To: comp.protocols.tcp-ip Subject: Re: Finger server as a requirement for all Internet hosts
Neil Rickert: > If he doesn't answer his phone, you are very likely to notice that when > you call him. But if he doesn't read his email, you may never know. Entierly true, but the usefullness of a directory service that let you look up someones e-mail address is not negligible. Further, letting the users maintain the information on whether they read their e-mail or not, is obviously not a good idea. But gathering that information could be done (and I have done it at our site) quite automaticly by sending everyone a letter and simply asking them. One other good effect of this is that it seems to be kind of an exercise to a lot of users, thus increasing the number of people who read their e-mail. Also if they do not answer their question that could be usefull information as well. -- Anders Karlsson
-----------[000153][next][prev][last][first]---------------------------------------------------- Date: 14 Aug 91 21:30:18 GMT From: tierney@george.lbl.gov (Brian Tierney) To: comp.protocols.tcp-ip,ba.internet Subject: High Performance Network Computing job at LBL
High Performance Network Computing and the NREN
Lawrence Berkeley Laboratory Job Posting
This position involves defining and exploring new directions for
effective use of the emerging high speed national network, as well as
participating in the National committees working on the design of the
NREN. Some of the work will entail investigation and use of a wide
range of distributed computing technology, and scientific applications
based on the national deployment of high speed networking technology.
See posting in: misc.jobs.offered,ba.jobs.offered for more information
(DO NOT respond to this email address)
-----------[000154][next][prev][last][first]---------------------------------------------------- Date: 14 Aug 91 21:59:34 GMT From: dgreen@sti.com (Dan R. Greening) To: comp.protocols.tcp-ip Subject: Dialin SLIP (or PPP or ?) for SunOS 4.1.1
We want to add a dial-in slip line, with these properties:
1. Initial contact with the modem results in the normal login
prompt. If you login normally, you login.
2. If you login as "slip", giving the proper password, the slip server
starts.
3. When carrier drops, the slip program terminates properly (and getty
starts again). (This may actually be the tricky part: the slip-4.1-beta
we use for our hard-wired slip implementation doesn't gracefully turn
itself off.)
Is there an existing program (hopefully PD), for SunOS 4.1.1, which
does this? It doesn't necessarily have to be slip: we have control of
both sides of the connection, and all participants are SunOS 4.1.1.
Many thanks for any information on this (we're desperate!). We'll
even help write/test/supply the code if there's a partial
implementation somewhere.
Regards,
--
____
\ /Dan Greening Software Transformation 1601 Saratoga-Sunnyvale Rd, #100
\/dgreen@sti.com (408) 973-8081 x313 Cupertino, CA 95014
-----------[000155][next][prev][last][first]---------------------------------------------------- Date: 15 Aug 91 01:45:15 GMT From: MAP@LCS.MIT.EDU (Michael A. Patton) To: comp.protocols.tcp-ip Subject: Finger server as a requirement for all Internet hosts
Date: 9 Aug 91 16:58:39 GMT
From: csusac!cindy!OAVAX.CSUCHICO.EDU!RGOLDSTONE@ucdavis.ucdavis.edu (Robin Goldstone)
I would like to see ... domains ... operate a finger server ... I
... have users come to me and say "I want to send e-mail to my
colleague at the University of XYZ. Is there some way I can look
up their address?"
What I do in this case is send mail to Postmaster at that site and ask
them. I usually include something along the lines, "Because your site
doesn't run a finger server, I am required to waste your time and mine
by sending this request for an address to you. You should consider
running such a server to cut down on the amount of time you spend
answering such queries."
__
/| /| /| \ Michael A. Patton, Network Manager
/ | / | /_|__/ MIT Laboratory for Computer Science
/ |/ |/ |atton and Postmaster@LCS.MIT.EDU
Disclaimer: The opinions expressed above are a figment of the phosphor
on your screen and do not represent the views of MIT, LCS, or MAP. :-)
P.S. On the other hand, even though MIT does run such a service, it's
amazing how many people don't think to try and just send to Postmaster
anyway. At least having the service makes it easy for me to reply.
-----------[000156][next][prev][last][first]---------------------------------------------------- Date: 15 Aug 91 02:02:42 GMT From: mcmillan@mizar.usc.edu (Delcina McMillan) To: comp.protocols.tcp-ip Subject: SLIP Info...
I have been seeing the word Dial-up IP and SLIP lately. I would like to know just what that means. I have a good guess as to what it might be, but I would rather have a real answer. Rather than tie up this group with answers, if anyone would send me mail on the subject, I would be greatly appreciative -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Kim C. Callis +
-----------[000157][next][prev][last][first]---------------------------------------------------- Date: 15 Aug 91 02:04:47 GMT From: pte900@jatz.aarnet.edu.au (Peter Elford) To: comp.unix.sysv386,comp.protocols.tcp-ip Subject: Making the DNS work on System V Release 4 System
I have been trying to help a site with Intel's (?) System V Release 4 running on a 386 to operate correctly with the DNS. The system identifies itself at login as follows: UNIX System V/386 Release 4.0 Version 2.0 Copyright (C) 1984, 1986, 1987, 1988, 1989, 1990 AT&T Copyright (C) 1987, 1988 Microsoft Corp. We had no problems running up the name server, but have been unable to make the IP applications (ftp, telnet, ping, etc) use the DNS rather than the /etc/hosts file. The /etc/netconfig file has had the resolver routines added to the name-to-address mapping field: tcp tpi_cots_ord v inet tcp /dev/tcp /usr/lib/tcpip.so,/usr/lib/resolv.so udp tpi_clts v inet udp /dev/udp /usr/lib/tcpip.so,/usr/lib/resolv.so rawip tpi_raw - inet - /dev/rawip /usr/lib/tcpip.so,/usr/lib/resolv.so icmp tpi_raw - inet icmp /dev/icmp /usr/lib/tcpip.so,/usr/lib/resolv.so but noone of the applications are querying the DNS (this can be checked by truning on named debugging). We rebooted the system after changing netconfig (is this necessary?) but this made no difference. We changed the /etc/resolv.conf file to point to the loopback address rather that the systems Ethernet address, and I tried running without a resolv.conf (but didn't reboot between these changes). Aagin, no joy. Is there some magic trick we are missing ? PLEASE pass copies of any answers to jd@buc.edu.au (they don't have a news feed yet) - thanks, Peter Elford, e-mail: P.Elford@aarnet.edu.au Network Co-ordinator, phone: +61 6 249 3542 Australian Academic Research Network, fax: +61 6 247 3425 c/o, Computer Services Centre, pager: +61 6 245 3035 Australian National University post: PO Box 4 Canberra, AUSTRALIA Canberra 2601 ps. mail (to remote Internet destinations) and nslookup work fine ...
-----------[000158][next][prev][last][first]---------------------------------------------------- Date: 15 Aug 91 09:03:10 GMT From: J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) To: comp.protocols.tcp-ip Subject: tcpdump port for snap encoded IP?
has anyone done the (small) addon to get tcpdump to pretty snap encoded IP? if so, can we ftp it/deltas? thanks...if not, we'll doit anyhow...setting timer event for monday for us to start it:-) jon
-----------[000159][next][prev][last][first]---------------------------------------------------- Date: 15 Aug 91 11:08:42 GMT From: rbrickey@BBN.COM (Ron Brickey) To: comp.protocols.tcp-ip Subject: Recoval
Please remove me from this mailing list.
-----------[000160][next][prev][last][first]---------------------------------------------------- Date: 15 Aug 91 14:34:16 GMT From: jas@proteon.com (John A. Shriver) To: comp.protocols.tcp-ip Subject: Gratuitous ARP
Gratuitous ARP is where a host sends an ARP reply as a broadcast when there was no ARP query. It is something polite that hosts having to change their MAC addresses do. (Some non-IP protocols sometimes require changing the MAC address.) If all of the other hosts on the LAN correctly implement ARP (not all do!), they will learn the new MAC address for the host that sent the gratuitous ARP reply. This is because they are always supposed to learn from the arp$sha and arp$spa filed on all incoming ARP packets. (See the pseudo-code in ARP.) If all hosts implemented ARP cache aging, Gratuitous ARP probably would not be as necessary. However, ARP cache aging was originally optional. (Now that there are things like proxy ARP, aging is more necessary.)
-----------[000161][next][prev][last][first]---------------------------------------------------- Date: 15 Aug 91 14:59:45 GMT From: bb16@prism.gatech.EDU (Scott Bostater) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Problems with PC <-> Unix on Multiport Ethernet Transceiver
We are having problems using NCSA Telnet to connect various IBM PC clones
to various unix machines. The problem is localized to PC's and a unix host
that are on the same Multiport transceiver. This has been a problem for a
Sun 386i, Sun Sparc Station, and Silicon Graphics IRIS workstations. All of
the PC clones are using WD 8003e ethernet cards. The multiport transceivers
are Cabletron MT-800's (thick ethernet).
The main sympton is either inability to connect at all, or connections where
the data transfer is measured in seconds/byte :-(
We have no network monitering capability here, so I can't get a reading of how
many dropped packets we have. I am assumming the problem is due to a massive
percentage of lost packets. Is there any easy way to fix this?
Any help would be greatly appreciated.
--
Scott Bostater Georgia Tech Research Institute - Radar Systems Analysis
"My soul finds rest in God alone; my salvation comes from Him" -Ps 62.1
uucp: ...!{allegra,amd,hplabs,ut-ngp}!gatech!prism!bb16
Internet: bb16@prism.gatech.edu
-----------[000162][next][prev][last][first]---------------------------------------------------- Date: 15 Aug 91 15:03:34 GMT From: kurt@s5000.rsvl.unisys.com (Kurt Matthys x5693) To: comp.protocols.tcp-ip Subject: TCP FIN and window
I have recently run into a TCP question that I would like some input on. It concerns whether a TCP can send a FIN when the window is closed. I have seen at least two implementations that do this, but RFC 793 would appear to say that it should not be done. The following is my interpretation of the issue: On page 25 of RFC 793 it states that the segment length is "the number of octets occupied by the data in the segment (including SYN and FIN)". On page 69 the table shows that if the segment length > 0 and the received window = 0, the received segment is not acceptable. A couple of lines later it says that "If the RCV.WND is zero, no segments will be acceptable, but special allowance should be made to accept valid ACKs, URGs and RSTs". Then it states that "if an incoming segment is unacceptable, an acknowledgment should be sent in reply ... After sending the acknowledgment, drop the unacceptable segment and return". On page 70 it talks about trimming an incoming segment so that it is completely inside the window by "trimming off any portions that lie outside the window (including SYN and FIN)". From the above the FIN is included in the segment length and a TCP that receives a FIN when the window is closed should discard it (at least this is how I interpret it). Any comments? Kurt Matthys Unisys Corp. Roseville MN kurt@s5000.rsvl.unisys.com
-----------[000163][next][prev][last][first]---------------------------------------------------- Date: 15 Aug 91 15:06:25 GMT From: dcm@gram.dell.com (Dave McCracken) To: comp.unix.sysv386,comp.protocols.tcp-ip Subject: Re: Making the DNS work on System V Release 4 System
pte900@jatz.aarnet.edu.au (Peter Elford) writes: >I have been trying to help a site with Intel's (?) System V Release 4 >running on a 386 to operate correctly with the DNS. The system >identifies itself at login as follows: >UNIX System V/386 Release 4.0 Version 2.0 >Copyright (C) 1984, 1986, 1987, 1988, 1989, 1990 AT&T >Copyright (C) 1987, 1988 Microsoft Corp. >We had no problems running up the name server, but have been unable to >make the IP applications (ftp, telnet, ping, etc) use the DNS rather >than the /etc/hosts file. The /etc/netconfig file has had the resolver >routines added to the name-to-address mapping field: >tcp tpi_cots_ord v inet tcp /dev/tcp /usr/lib/tcpip.so,/usr/lib/resolv.so >udp tpi_clts v inet udp /dev/udp /usr/lib/tcpip.so,/usr/lib/resolv.so >rawip tpi_raw - inet - /dev/rawip /usr/lib/tcpip.so,/usr/lib/resolv.so >icmp tpi_raw - inet icmp /dev/icmp /usr/lib/tcpip.so,/usr/lib/resolv.so >but noone of the applications are querying the DNS (this can be checked >by truning on named debugging). >We rebooted the system after changing netconfig (is this necessary?) but >this made no difference. >We changed the /etc/resolv.conf file to point to the loopback address >rather that the systems Ethernet address, and I tried running without >a resolv.conf (but didn't reboot between these changes). Aagin, no joy. >Is there some magic trick we are missing ? I suspect your problem is the buggy /usr/lib/resolv.so found in the SVR4.0.2 you have. As I recall, resolv.so refers to some symbols that are in libc.a only and not in libc.so, so can not be resolved at dynamic load time. You could try to pry a fixed version out of your vendor (or buy Dell SVR4 :-)). If you do get a working resolv.so, you might want to put resolv.so in front of tcpip.so, unless you really need to access /etc/hosts first. That's the way we run internally, and ship our SVR4. -- Dave McCracken dcm@dell.dell.com (512) 343-3720 Dell Computer 9505 Arboretum Blvd Austin, TX 78759-7299
-----------[000164][next][prev][last][first]---------------------------------------------------- Date: 15 Aug 91 16:13:23 GMT From: YXT108@psuvm.psu.edu To: comp.protocols.tcp-ip,comp.sys.mac.comm Subject: connection between mac and vax
Hi there, I tried to connect to VAX by using NCSA Telnet 2.3 MacTCP. "Sometimes" the cursor freezed during the connection and then, after a while, VAX kicked me out automatically. "Sometimes" my mac crushed right after above situation. (screen freezed and no error massage) But everytinging works well when I tried to connect to a unix machine. I also tried to use NCSA Telnet 2.4 and it didn't help. I have no idea how to fix the problem. It looks like something wrong with the VAX. I am running 6.0.7 on SE/30 with Dove FastNet SE/30. Does anyone have similar experiences? I'd appreciate any suggestions. Thanks in advance. Please reply by e-mail. Y. C. Tan Internet yxt108@psuvm.psu.edu BITNET yxt108 at psuvm
-----------[000165][next][prev][last][first]---------------------------------------------------- Date: 15 Aug 91 16:18:18 GMT From: lcz@sat.datapoint.com (Lee Ziegenhals) To: comp.unix.sysv386,comp.protocols.tcp-ip Subject: Re: Making the DNS work on System V Release 4 System
pte900@jatz.aarnet.edu.au (Peter Elford) writes: >I have been trying to help a site with Intel's (?) System V Release 4 >running on a 386 to operate correctly with the DNS... >We had no problems running up the name server, but have been unable to >make the IP applications (ftp, telnet, ping, etc) use the DNS rather >than the /etc/hosts file. The /etc/netconfig file has had the resolver >routines added to the name-to-address mapping field: Peter, you have to REBUILD those utilities with the resolv library to get them to use DNS :-(. AT&T took the BSD versions of these utilities and ported them almost verbatum. They call gethostbyname() to resolve host names, but the utilities as distrbuted are linked with the non-DNS library. For some reason, they did not provide a single compatibility library that uses the netconfig entries to resolve host names. To use the netconfig stuff, an application must call the new SVR4 name-to-address functions. I couldn't believe this when I found out the hard way, just like you. I have considered writing my own resolver library that uses the netconfig entries, and relinking the utilities. Unfortunately, if you don't have a source license you're stuck. I'd call your vendor and complain. If anyone has found a better solution to this problem, a post would be much appreciated! Lee Ziegenhals (lcz@sat.datapoint.com)
-----------[000166][next][prev][last][first]---------------------------------------------------- Date: 15 Aug 91 16:27:23 GMT From: u5434122@ucsvc.ucs.unimelb.edu.au To: comp.protocols.tcp-ip Subject: TALK getting stuck and not connecting.
Could anyone please explain why talk occasionally gets stuck at the "Checking for invitation on caller's machine." message? It only does this on attempting connection with specific hosts eg milton.u.washington.edu, and will not connect, regardless of whether an invitation has been issued by the other party. I found the source code for talk, and went through it, to find out what the "Checking.." message means, and it appears that it means that your talk is checking locally to see if the local talk-daemon has received an invitation from a remote talk. Why then should talk get stuck whether there is an invitation or not? Does the problem lie in the local talk-daemon, the remote talk-daemon, local talk, remote talk, or just some mutual antipathy somewhere? It was possible to talk between my host (xvax.ucs.unimelb.edu.au) and milton last week, but now it is impossible. I have tried both 4.3 and 4.2 talks to respond to talk-requests from milton, but neither works now, although 4.3 did last week. Thanks for any help, Danny
-----------[000167][next][prev][last][first]---------------------------------------------------- Date: 15 Aug 91 17:11:38 GMT From: watstar@sail.uwaterloo.ca (WATSTAR at UW) To: comp.protocols.tcp-ip,comp.dcom.lans Subject: Re: RARP vs. BOOTP
In article <paul.682258136@aucs> paul@aucs.acadiau.ca (Paul Steele) writes: >Which address resolution protocol is more typically used by the rest >of the world - RARP or BOOTP? We having been having trouble with Rarp is a less robust system. Bootp can often work with multiple subnets (some gateways forward BOOTP packets). Also BOOTP can supply much more information such as local gateways, name servers, etc. Of the two, BOOTP is preferred. Just for your information, BOOTP does not meet all the needs of the internet, it does not give all the required information, such as the domain name, its gateway information is not complete, and there are other deficiencies. A working group is preparing a proposal for a successor to it, but the current BOOTP is still far superior to RARP. Erick Engelke
-----------[000168][next][prev][last][first]---------------------------------------------------- Date: 15 Aug 91 17:20:14 GMT From: watstar@sail.uwaterloo.ca (WATSTAR at UW) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: DOS - UNIX communcations.
In article <7102@graphite8.UUCP> dyer@motcid.UUCP (Bill Dyer) writes: > >I have several questions. What I want to do is write 2 applications, >one for a UNIX box and one for a PC (running DOS, and no we can't run >unix on the PC for various reasons). I would like the applications to be >able to send messages (packets) back and forth over an ethernet link. For building pc based TCP/IP clients, take a look at the Waterloo TCP collection available via anonymous ftp to sunee.uwaterloo.ca in pub/wattcp/src.zip You can use functions roughly similar to BSD type sockets. There are some sample applications (Finger for tcp, cookie for udp) and a complete programmers guide and reference manual is available to simplify your task. Erick Engelke Network Systems Manager Faculty of Engineering University of Waterloo
-----------[000169][next][prev][last][first]---------------------------------------------------- Date: 15 Aug 91 18:22:31 GMT From: emv@msen.com (Ed Vielmetti) To: comp.protocols.tcp-ip,comp.protocols.ppp,alt.sys.sun Subject: Re: Dialin SLIP (or PPP or ?) for SunOS 4.1.1
First note: there's a PPP newsgroup (comp.protocols.ppp) worth reading
for questions like this.
I'd look at the BBN dialup-ip code as an example of a configuration
setup, I believe that it can be configured as you expect.
In article <1991Aug14.215934.603@sti.com> dgreen@sti.com (Dan R. Greening) writes:
We want to add a dial-in slip line, with these properties:
1. Initial contact with the modem results in the normal login
prompt. If you login normally, you login.
2. If you login as "slip", giving the proper password, the slip server
starts.
3. When carrier drops, the slip program terminates properly (and
getty starts again). (This may actually be the tricky part:
the slip-4.1-beta we use for our hard-wired slip implementation
doesn't gracefully turn itself off.)
____
\ /Dan Greening Software Transformation 1601 Saratoga-Sunnyvale Rd, #100
\/dgreen@sti.com (408) 973-8081 x313 Cupertino, CA 95014
--
Newsgroups: msen.archives.vrfy
Archive-name: dialupip
Archive-directory: bbn.com:/pub/dialup*
Subject: vrfy dialupip
Date: Thu, 15 Aug 1991 18:20:09 GMT
bbn.com
-rw-r--r-- 1 ftp ftp 197321 Jan 14 1991 /pub/dialup2.0.tar.Z
found dialupip ok
bbn.com:/pub/dialup*
--
Edward Vielmetti, vice president for research, MSEN Inc. emv@msen.com
MSEN, Inc. 628 Brooks Ann Arbor MI 48103 +1 313 741 1120
for information on MSEN products and services contact info@msen.com
-----------[000170][next][prev][last][first]---------------------------------------------------- Date: 15 Aug 91 19:19:44 GMT From: fsimmons@ub.d.umn.edu (Frank Simmons) To: comp.protocols.tcp-ip Subject: telnet
To whom it may concern: I am running Campus Wide Information System and I would like to provide telnet service to off-campus sources of information. As I understand it, telnet accepts commands from tty only. I would like to be able to have telnet accept its commands from a file until the file is exhausted and then return control back to tty for further action. Has anyone done this and if so, would you be willing to share it with me? Frank Simmons
-----------[000171][next][prev][last][first]---------------------------------------------------- Date: 15 Aug 91 19:30:12 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: Gratuitous ARP
In article <62274@fuquad.westford.ccur.com>, simon@fuquad.westford.ccur.com (Simon Rosenthal) writes: > > Well, they do occasionally (even in the most carefully managed networks !). > Concurrent has a "DUPLICATE IP ADDRESS !!!" message logged and printed out > on the system console, along with the MAC address that generated the ARP > reply, so that the system/network manager can resolve the conflict. Even better is for the system that thinks it's MAC address has been stolen also to broadcast its own IP address in a "gratuituous ARP" back at the perpetrator. With suitable timers (~15 sec) to avoid swamping the ether with the arguing, this allows the network connections of both hosts to stagger along well enough for you to get thru to fix remote host tables or whatever. Try it on a pair of IRIS's. (There is a bug in 3.3 which causes the victim to never stop complaining.) The code is obvious and trivial to (reverse-)engineer into arptimer() and in_arpinput() in netinet/if_ether.c in 4.3BSD style network code. IMinsufficientlyHO, it's a neat idea. Vernon Schryver, vjs@sgi.com
-----------[000172][next][prev][last][first]---------------------------------------------------- Date: 15 Aug 91 20:36:45 GMT From: stevea@i88.isc.com (Steve Alexander) To: comp.unix.sysv386,comp.protocols.tcp-ip Subject: Re: Making the DNS work on System V Release 4 System
I have seen two methods for this. In earlier versions of 5.4, there
were two socket libraries, libsocket.so and libsockdns.so, and if you
replaced libsocket with the DNS version, things worked OK.
In 5.4 Version 3.0, gethostby* use the netdir routines as you would expect,
and the order of /usr/lib/resolv.so and /usr/lib/tcpip.so control which
gets searched first. This is, of course, the preferred approach.
--
Steve Alexander, Software Technologies Group | stevea@i88.isc.com
INTERACTIVE Systems Corporation, Naperville, IL | ...!{sun,ico}!laidbak!stevea
-----------[000173][next][prev][last][first]---------------------------------------------------- Date: 15 Aug 91 21:12:49 GMT From: jim@lsuc.on.ca (Jim Mercer) To: bit.listserv.ibmtcp-l,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,bit.listserv.ibm-main,bit.listserv.ibm-nets Subject: telnet and AS400/NCSA/CUTCP/Packetdrivers/AT&T etc
[ forgive the wide posting, but i figured i'd hit what i thought was the
appropriate groups without too much overlap ]
we have:
IBM AS/400 Midrange with IBM TCP/IP 2.0 in the IBM Ethernet Adapter
AT&T 3b2/500 with Wollongong TCP/IP 3.2 and the AT&T 10base5 card
PC/AT's attached to Novell servers using packet drivers/NCSA/CUTCP to achieve
TCP/IP connectivity to the AS400 and 3b2's
this works:
smtp between 3b2, as400 and ka9q router
ftp between 3b2, as400, ka9q router and PC's with NCSA telnet/ftp server
telnet between NCSA and 3b2.
telnet from as400 to 3b2 (line mode only)
this don't work:
telnet from 3b2 to as400
telnet from PC's to as400 (NCSA telnet, CUTCP telnet, CUTCP TN3270)
does anyone out there have telnet working INTO an as400?
has anyone heard of a tn5250 for unix and/or PC's ?
thanx
--
[ Jim Mercer jim@lsuc.On.Ca || ...!uunet!attcan!lsuc!jim +1 416 947-5258 ]
[ Educational Systems Manager - Law Society of Upper Canada, Toronto, CANADA ]
[ Standards are great. They give non-conformists something to not conform to. ]
[ The opinions expressed here may or may not be those of my employer ]
-----------[000174][next][prev][last][first]---------------------------------------------------- Date: 15 Aug 91 22:37:52 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: Gratuitous ARP
In article <16086@mentor.cc.purdue.edu>, dls@mentor.cc.purdue.edu (David L Stevens) writes: > ... > People adding this feature should consider the down side, as well. > What happens when a power failure causes a hundred workstations to send > extraneous ARP packets at the same time? Is this still a problem? Given ethernet "deferals" (not collisions), what bad thing happens today should 100 stations each decide to transmit a 60byte packet in the same millisecond? Today, when "low end" engineering workstations can and do transmit or receive as fast as the ether will go? Also given that no one in their right mind puts more than a dozen machines on one ethernet segment? This is not 1983, when 100KByte/sec was a respectible number. Vernon Schryver, vjs@sgi.com
-----------[000175][next][prev][last][first]---------------------------------------------------- Date: 15 Aug 91 23:03:21 GMT From: mjhammel@Kepler.dell.com (Michael J. Hammel) To: comp.unix.sysv386,comp.protocols.tcp-ip Subject: Re: Making the DNS work on System V Release 4 System
In article <1991Aug15.020447.22138@newshost.anu.edu.au>,
pte900@jatz.aarnet.edu.au (Peter Elford) writes:
> I have been trying to help a site with Intel's (?) System V Release 4
> running on a 386 to operate correctly with the DNS. The system
> identifies itself at login as follows:
[stuff deleted]
> We had no problems running up the name server, but have been unable to
> make the IP applications (ftp, telnet, ping, etc) use the DNS rather
> than the /etc/hosts file. The /etc/netconfig file has had the resolver
> routines added to the name-to-address mapping field:
[stuff deleted]
> We changed the /etc/resolv.conf file to point to the loopback address
> rather that the systems Ethernet address, and I tried running without
> a resolv.conf (but didn't reboot between these changes). Aagin, no joy.
>
> Is there some magic trick we are missing ?
You might try making sure the /etc/resolv.conf is a link to
/etc/inet/resolv.conf. The actual file was moved under /etc/inet in V4,
but many applications still look for /etc/resolv.conf. Don't know why,
but that seemed to work for most of my needs.
I noticed at one point that these were independent files. So editing
one did not change the other and thus you got varied results with
different applications.
Hope this helps.
Michael J. Hammel | mjhammel@{Kepler|socrates|feynman}.dell.com
Dell Computer Corp. | {73377.3467|76424.3024}@compuserve.com
#include <disclaim/std> | zzham@ttuvm1.bitnet
"Jesus Saves! But Gretzky gets the rebound! He shoots! HE SCORES!"
-----------[000176][next][prev][last][first]---------------------------------------------------- Date: 15 Aug 91 23:08:14 GMT From: mcb@compaq.com (Michael Busby) To: comp.unix.sysv386,comp.protocols.tcp-ip Subject: Re: Making the DNS work on System V Release 4 System
lcz@sat.datapoint.com (Lee Ziegenhals) writes: >pte900@jatz.aarnet.edu.au (Peter Elford) writes: >>I have been trying to help a site with Intel's (?) System V Release 4 >>running on a 386 to operate correctly with the DNS... >>We had no problems running up the name server, but have been unable to >>make the IP applications (ftp, telnet, ping, etc) use the DNS rather >>than the /etc/hosts file. The /etc/netconfig file has had the resolver >>routines added to the name-to-address mapping field: >Peter, you have to REBUILD those utilities with the resolv library to get them >to use DNS :-(. AT&T took the BSD versions of these utilities and ported them >almost verbatum. They call gethostbyname() to resolve host names, but the >utilities as distrbuted are linked with the non-DNS library. For some reason, >they did not provide a single compatibility library that uses the netconfig >entries to resolve host names. To use the netconfig stuff, an application must >call the new SVR4 name-to-address functions. >I couldn't believe this when I found out the hard way, just like you. I have >considered writing my own resolver library that uses the netconfig entries, and >relinking the utilities. >Unfortunately, if you don't have a source license you're stuck. I'd call your >vendor and complain. >If anyone has found a better solution to this problem, a post would be much >appreciated! >Lee Ziegenhals (lcz@sat.datapoint.com) System V.4 release 3 does not have this problem. The internet commands are linked with libnsl. Yes, release 2 does seem to need the commands recompiled with libresolv. Michael C. Busby - Systems Engineer ---------------------------------------------------------------------- Compaq Computer Corporation | Internet: mcb@compaq.com P.O. Box 692000 m/s 050701 | Uunet: uunet!cpqhou!michaelb Houston, Texas 77269-2000 | Phone: 713-374-5638 ---------------------------------------------------------------------- All views and opinions expressed are my own and do not represent the views and opinions of Compaq Computer Corporation.
-----------[000177][next][prev][last][first]---------------------------------------------------- Date: 16 Aug 91 05:27:30 GMT From: pte900@jatz.aarnet.edu.au (Peter Elford) To: comp.unix.sysv386,comp.protocols.tcp-ip Subject: Re: Making the DNS work on System V Release 4 System
In article <1991Aug15.203645.23468@i88.isc.com>, stevea@i88.isc.com (Steve Alexander) writes: |> I have seen two methods for this. In earlier versions of 5.4, there |> were two socket libraries, libsocket.so and libsockdns.so, and if you |> replaced libsocket with the DNS version, things worked OK. Someone who had set up UTS (Fujitsu's System V release 4 for IBM 370 compatible mainframes) suggested this - but I could not find the dns socket library. |> In 5.4 Version 3.0, gethostby* use the netdir routines as you would expect, |> and the order of /usr/lib/resolv.so and /usr/lib/tcpip.so control which |> gets searched first. This is, of course, the preferred approach. Yep - this seem to be the way to go - version 3.0 it will have to be! Thanks to all the others that responded! Peter Elford, e-mail: P.Elford@aarnet.edu.au Network Co-ordinator, phone: +61 6 249 3542 Australian Academic Research Network, fax: +61 6 247 3425 c/o, Computer Services Centre, pager: +61 6 245 3035 Australian National University post: PO Box 4 Canberra, AUSTRALIA Canberra 2601
-----------[000178][next][prev][last][first]---------------------------------------------------- Date: 16 Aug 91 16:58:36 GMT From: thomson@hub.toronto.edu (Brian Thomson) To: comp.protocols.tcp-ip Subject: Re: TCP FIN and window
In article <240@s5000.rsvl.unisys.com> kurt@s5000.rsvl.unisys.com (Kurt Matthys x5693) writes:
>I have recently run into a TCP question that I would like some input on. It
>concerns whether a TCP can send a FIN when the window is closed. I have seen
>at least two implementations that do this, but RFC 793 would appear to say
>that it should not be done. The following is my interpretation of the issue:
As you have noted, the RFC does indicate that a lone FIN at the edge of a
zero window is thrown away. What this means is that you should be prepared
to interoperate with implementations that do follow the spec literally,
whether or not you decide to do so yourself.
As to the question of whether you should send these things, or act on them
when you receive them, hey, be a little brave. The RFC is not error-free.
Consider the test it describes for acceptability of a nonzero length
segment when the window is open:
RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND
which, if you believed it, would require that you throw away a segment
that overlaps the window on both ends:
SEG.SEQ SEG.SEQ+SEG.LEN
|--------------------------------------------|
| |
RCV.NXT RCV.NXT+RCV.WND
whereas the reasonable thing to do, is to trim both ends and accept the data.
Getting back to the FIN-at-edge-of-zero-window question, the RFC's
position is probably the result of its authors not recognizing that it
is a special case. The reasonable thing to do is to go ahead and send the
FINs, and to accept them. In fact, you could argue that it is necessary,
because it is entirely acceptable for a TCP to never advertise a nonzero
window if it does not expect to receive data (eg. the unused second half
of a half-duplex connection), and following the RFC too closely in this
case would make it impossible to cleanly close the connection.
--
Brian Thomson, CSRI Univ. of Toronto
utcsri!uthub!thomson, thomson@hub.toronto.edu
-----------[000179][next][prev][last][first]---------------------------------------------------- Date: 16 Aug 91 18:20:25 GMT From: clayh+@MUDLHEAD.NETWORK.COM (Clayton Haapala) To: comp.unix.sysv386,comp.protocols.tcp-ip Subject: Re: Making the DNS work on System V Release 4 System
This won't apply unless the TCP on the system is Wollongong-derived, such as I've seen on ATT 3B2s and NCR Towers (some of them, anyway), but in these cases, there is an environment variable called NONAMESERVER that gets set by default to "true" or "yes" or something to turn the DNS function off. I've spent some time getting all the config files right and got named running, but still couldn't get lookup to work right until that variable got changed. Again, I've never seen the V.4 TCP. -- Clayton Haapala (clayh@mudlhead.network.com) Network Systems Corp. MS10 "Ahead iWarp factor two, Ensign." 7625 Boone Ave N "Aye, Aye, Captain." Minneapolis, MN 55428-1099
-----------[000180][next][prev][last][first]---------------------------------------------------- Date: 16 Aug 91 18:30:50 GMT From: mike@atc.SP.Unisys.COM (Mike Grenier) To: comp.unix.sysv386,comp.protocols.tcp-ip Subject: Re: Making the DNS work on System V Release 4 System
From article <lcz.682273098@dptspd>, by lcz@sat.datapoint.com (Lee Ziegenhals):
> pte900@jatz.aarnet.edu.au (Peter Elford) writes:
>
>>I have been trying to help a site with Intel's (?) System V Release 4
>>We had no problems running up the name server, but have been unable to
>>make the IP applications (ftp, telnet, ping, etc) use the DNS rather
>>than the /etc/hosts file. The /etc/netconfig file has had the resolver
>>routines added to the name-to-address mapping field:
>
> Peter, you have to REBUILD those utilities with the resolv library to get them
> to use DNS :-(. AT&T took the BSD versions of these utilities and ported them
> almost verbatum. They call gethostbyname() to resolve host names, but the
> utilities as distrbuted are linked with the non-DNS library. For some reason,
> they did not provide a single compatibility library that uses the netconfig
> entries to resolve host names. To use the netconfig stuff, an application must
> call the new SVR4 name-to-address functions.
>
I don't believe thats true. Simply move /usr/lib/libsocket.so to
somewhere safe and then move /usr/lib/socketdns.so to
/usr/lib/socket.so. This will allow the already compiled utilities to
use the DNS routines.
The only problem with this is that you need to check the startup
script in /etc/inet/rc.inet. Note that the use of uname -n tells
ifconfig to look up the internet address of your box. Of course, if
ifconfig is not set up yet -- it can't ask the name server for that
information. I just hardcoded the internet address into
/etc/inet/rc.inet.
-Mike Grenier
mike@sp.unisys.com
*** rc.inet Thu Aug 8 12:15:59 1991
--- rc.inet.orig Thu Aug 8 12:10:57 1991
***************
*** 14,21 ****
# Default (single interface, not a gateway)
EMDMAJOR=0
! #/usr/sbin/ifconfig emd${EMDMAJOR} `uname -n` up -trailers
! /usr/sbin/ifconfig emd0 129.218.59.165 netmask 255.255.255.0 broadcast 129.218.59.255
if [ $? -ne 0 ]
then
exitcode=1
--- 14,20 ----
# Default (single interface, not a gateway)
EMDMAJOR=0
! /usr/sbin/ifconfig emd${EMDMAJOR} `uname -n` up -trailers
if [ $? -ne 0 ]
then
exitcode=1
-----------[000181][next][prev][last][first]---------------------------------------------------- Date: 16 Aug 91 19:05:41 GMT From: donp@novell.com (don provan) To: comp.protocols.tcp-ip Subject: Re: TCP FIN and window
In article <1991Aug16.125836.1187@jarvis.csri.toronto.edu> thomson@hub.toronto.edu (Brian Thomson) writes: >Consider the test it describes for acceptability of a nonzero length >segment when the window is open... >which, if you believed it, would require that you throw away a segment >that overlaps the window on both ends... >whereas the reasonable thing to do, is to trim both ends and accept the data. This is the reasonable thing to do under the "be liberal in what you accept" rule, but notice that the transmitting TCP has violated the "be conservative in what you send" rule by transmitting data which doesn't fit into the window. Given that the receiving TCP didn't shrink the window, one might actually consider this a protocol violation on the part of the transmitter. >Getting back to the FIN-at-edge-of-zero-window question, the RFC's >position is probably the result of its authors not recognizing that it >is a special case. But it *isn't* a special case. Typically, the window is closed because the data is tied up. In that case, the FIN *can't* be accepted for exactly the same reason more data can't be accepted: the previously accepted data has not been processed yet. >The reasonable thing to do is to go ahead and send the >FINs, and to accept them. It's perfectly reasonable to send the FIN if it's the next thing in the transmission buffer. In fact, it's required that closed windows be probed, and if the FIN's the only thing in the transmit queue, it's what has to be used to probe. I don't have any problem with a particular implementation accepting a FIN to a zero window, either, if it wants. After all, from the protocol's point of view that could be viewed as TCP suddenly finding an additional byte of buffer space. But i do not think it's a good idea for applications to be written to assume that a FIN sent to a closed window will be accepted, nor do i think a TCP which advertises a zero window should expect timely delivery of a FIN, since rfc793 recommends a two minute probe time for closed windows. >In fact, you could argue that it is necessary, >because it is entirely acceptable for a TCP to never advertise a nonzero >window if it does not expect to receive data (eg. the unused second half >of a half-duplex connection), and following the RFC too closely in this >case would make it impossible to cleanly close the connection. But it *is* expecting data: it's expecting the FIN. The FIN is *part* of the data stream. If the application requires a graceful close, i don't understand why the TCP wouldn't advertising window space for the FIN. don provan donp@novell.com
-----------[000182][next][prev][last][first]---------------------------------------------------- Date: 16 Aug 91 21:24:42 GMT From: geof@aurora.com (Geoffrey H. Cooper) To: comp.protocols.tcp-ip Subject: Re: Semantics of KEEPALIVE
In article <1122@nlbull.bull.nl> jos@bull.nl (Jos Vos) writes: >Who can supply me the detailed semantics of the KEEPALIVE option in >4.3BSD-alike TCP/IP implementations. >What are the roles of the client and the server w.r.t. the so-called >keep-alive packets? Consider the case of a TCP connection that is quiescent: all data transmitted by each side has been ACK'd by the other side. In this case the TCP spec does not mandate any reason to send a packet over the connection. If the underlying communications path is obstructed, or if one peer crashes, this fact can only be known when one of the two sides of the connection finally decides to send some data. Concept: If I use a telnet remote login to connect to a computer, and leave it idle overnight, the fact that some gateway has gone down for an hour during the night is of no consequence to me. Further, I would rather not use bandwidth when I'm not there, since this might cost someone money per packet (on some media). If I need to know if the other host is there, I can send some telnet data, such as the AYT (are you there) signal. Problem: This characteristic of TCP places a burden on higher level protocols. There are some HL protocols (e.g., SMTP) that have "crux" points where they are prohibited from sending any data. This makes them sensitive to a severed TCP connection during these times. These protocols might be considered buggy, but they are, nonetheless, pervasive. Berkeley Solution: If SO_KEEPALIVE is present, a quiescent TCP will periodically retransmit the last byte of data that was transmitted to the other side, and set a timer. This packet must be interpreted by the receiver as a retransmission due to a missing ACK, so the receiver can be expected to retransmit the ACK. If the sender's timer goes off before the ACK is received, the connection is reset (actually, the original packet is retransmitted several times before the connection is reset). The effect of this is to have TCP periodically probe an otherwise quiescent connection. If the connection becomes untenable, a deficient higher level protocol is rescued when TCP informs it that its underlying connection has gone away. Example: TCP PEER A TCP PEER B ------------ --------------- SN 100, ACK 300 SN 300, ACK 100 <idle> <idle> SEND(SN 100, ACK 299) ----------> <oh, he missed the ack for 300, so...> OK <----------------------------SEND(SN 300, ACK 100) [should that be ACK 301? Never remember these things...] I have seen some very strange packets transmitted as keepalives in the rare circumstance where a connection is opened but no data is sent. - Geof -- geof@aurora.com / aurora!geof@decwrl.dec.com / geof%aurora.com@decwrl.dec.com
-----------[000183][next][prev][last][first]---------------------------------------------------- Date: 17 Aug 91 15:55:59 GMT From: dls@mentor.cc.purdue.edu (David L Stevens) To: comp.protocols.tcp-ip Subject: Re: TCP FIN and window
Someone recently asked me a similar question, put this way: If there were one byte in the window and you had one byte of data and the FIN, do you send the packet with just the data, or with the data and the FIN. I don't have the mail laying around, but the question is so similar that I suspect it may be the same source, but the wording posted here makes it sound like you're sending an extra FIN-only bearing packet. You could say that question is included in this one, but I think there is a distinction in sending another packet and, somewhat artificially, stripping the FIN on a packet you're sending anyway. I think the reasonable thing to do is: Receiver side: 1) Process the FIN, if it's there. I.e., don't let window checks force a retransmission for something that doesn't take buffer space! Sender side: 1) Include the FIN if it'll fit in a packet you're already sending. 2) If you're not already sending it, put it in a probe for more window. The person that I was talking to suggested that my implementation was wrong because I do #1 on the sender side.. I think that's too dogmatic, myself. I think that's what thompson@hub.toronto.edu (Brian Thompson) was getting at. donp@novell.com (don provan) writes: >But it *isn't* a special case. Typically, the window is closed >because the data is tied up. In that case, the FIN *can't* be >accepted for exactly the same reason more data can't be accepted: the >previously accepted data has not been processed yet. and >But it *is* expecting data: it's expecting the FIN. The FIN is *part* >of the data stream. If the application requires a graceful close, i >don't understand why the TCP wouldn't advertising window space for the >FIN. But it is a special case, as illuminated above. If you have exactly 4K of buffer space, you can't advertise 4K+1, because it'll force you to drop the last byte of data (you can't tell a priori it'd be a FIN) during normal flow and force a retransmit for that 1 byte, but you *can* accepted 4K of data and the FIN. The FIN is special, because it doesn't require any extra space in either the packet or the receive buffers. Similarly for the SYN, if your TCP and its user interface allows you to send data along with the SYN. For that reason, if you treat it exactly like data in MSS checks or window checks, you'll force an extra packet that carries only the FIN-- a waste of network bandwidth and the application's time, if the receiver is overly dogmatic about windows. Also, I thought I'd point out, since it's a pet peeve [:-)], the probe time should be the same as the retransmission time, with exponential backoff, and not 2 minutes (!). Berkeley uses a minimum of 5 seconds (as much as a 1000 times too large on an Ethernet), which makes for pretty poor performance if you do drop a probe. Maybe they'll fix it in 4.4. :-) If you have an implementation that uses 2 minutes for a probe time, or anything more than the smoothed rtt, you should complain to the vendor, because dropped packets will give you unnecessary and noticeable delays. -- +-DLS (dls@mentor.cc.purdue.edu)
-----------[000184][next][prev][last][first]---------------------------------------------------- Date: 17 Aug 91 18:26:14 GMT From: kenny@dit.lth.se (Kenny Ranerup) To: alt.sys.sun,comp.protocols.ppp,comp.protocols.tcp-ip Subject: Diskless Sun 3/50 as X-terminal over SLIP/PPP. How to boot?
We have a number of diskless 3/50s that we would like to run as
X-terminals. The only connection to the 3/50 would be a modem
connected to the serial port. PPP or SLIP would be used to communicate
over this serial line.
Now the problem is how to boot the 3/50 over the serial line so that
it can run a X-server and SLIP/PPP software.
The boot-prom on the 3/50 only supports booting from SCSI-disk or from
ethernet using TFTP. (as far as I know)
The solutions that I can see are
1. Hack a new boot-prom with possibility to boot via serial port.
(Can you get source code for existing proms?).
2. Buy a cheap SCSI-disk large enough for Xkernel & SLIP/PPP.
So, is there anyone out there who has done something like this or have
some ideas how to approach this?
+------------------------------------+----------------------------+
| Kenny Ranerup, | Phone: +46 46 104940 |
| Dept. of Computer Engineering | Email: kenny@dit.lth.se |
| Lund University | |
| P.O. Box 118, S-221 00, Sweden | |
+------------------------------------+----------------------------+
-----------[000185][next][prev][last][first]---------------------------------------------------- Date: 17 Aug 91 19:43:25 GMT From: vern@zebra.UUCP (Vernon C. Hoxie) To: comp.sys.3b1,comp.protocols.tcp-ip Subject: Printing out 'ipctut' from osu archive
I recently downloaded a file from the AT&T-7300/3B1 archive at osu-cis
which is called 'ipctut'. It is a tutorial originally issued by the
Regents of the University of California. It contains no programming
code but does have a Makefile to be used in printing out the document.
In the Makefile, 'ditroff' is called using the 'me' macros and appears
to require a preprocessor filter called 'grn'.
Since all of these are foreign to my SYSV type machine, can anyone give
me suggestions about how to get a printout.
Is there an 'nroff' version available?
What is 'grn' and is it available for SYSV machines?
Does 'ditroff' differ appreciably from 'nroff'?
Will 'me' macros "borrowed" from a BSD machine
work with 'nroff'?
Thanks to all!!
vern
--
Vernon C. Hoxie {ncar,boulder}!scicom!zebra!vern
3975 W. 29th Ave. voice: 303-477-1780
Denver, Colo., 80212 TB+ uucp: 303-455-2670
-----------[000186][next][prev][last][first]---------------------------------------------------- Date: 17 Aug 91 21:54:50 GMT From: brendan@cs.widener.edu (Brendan Kehoe) To: comp.protocols.tcp-ip,comp.windows.x Subject: X11R5 Release -- Net Lag?
I was just thinking ... what kind of an effect do you think the
announced X11R5 release on September 5 will have on the overall
performance of the Internet? (Or 6th, or...) Mike Schwartz's recent
experiments in Internet connectivity have made me wonder what kind of
load will be on the different networks during early and mid
September--anybody gonna have meters running, to see how things flow?
It'd make for a pretty good experiment, though it's probably too late
by now to start anything sizeable.
--
Brendan Kehoe - Widener Sun Network Manager - brendan@cs.widener.edu
Widener University in Chester, PA A Bloody Sun-Dec War Zone
"And clever rogues with far less valid cause, have trapped their victims
in a web of laws." --- Moliere
-----------[000187][next][prev][last][first]---------------------------------------------------- Date: 17 Aug 91 22:46:57 GMT From: coates@UC780.UMD.EDU To: comp.protocols.tcp-ip Subject: Re: X11R5 Release -- Net Lag?
Would briefly explain X11R5? Thanks. --- coates@uc780.umd.edu
-----------[000188][next][prev][last][first]---------------------------------------------------- Date: 17 Aug 91 22:49:12 GMT From: henry@zoo.toronto.edu (Henry Spencer) To: alt.sys.sun,comp.protocols.ppp,comp.protocols.tcp-ip Subject: Re: Diskless Sun 3/50 as X-terminal over SLIP/PPP. How to boot?
In article <1991Aug17.182614.23792@lth.se> kenny@dit.lth.se (Kenny Ranerup) writes: > 1. Hack a new boot-prom with possibility to boot via serial port. > (Can you get source code for existing proms?). Much (all?) of the PROM source was included with Sun educational-institution source distributions at one time. (Maybe it still is, but we haven't kept up with the 4.n follies.) However, be warned that the hardware is undocumented -- well, actually, some documentation does exist, but you can't get it -- and some aspects of the boot process are subtle. -- Any program that calls itself an OS | Henry Spencer @ U of Toronto Zoology (e.g. "MSDOS") isn't one. -Geoff Collyer| henry@zoo.toronto.edu utzoo!henry
-----------[000189][next][prev][last][first]---------------------------------------------------- Date: 18 Aug 91 00:48:05 GMT From: jg@crl.dec.com (Jim Gettys) To: comp.protocols.tcp-ip Subject: Re: X11R5 Release -- Net Lag?
In article <kar6paINNhf8@cs.widener.edu> brendan@cs.widener.edu (Brendan Kehoe) writes: >I was just thinking ... what kind of an effect do you think the >announced X11R5 release on September 5 will have on the overall >performance of the Internet? (Or 6th, or...) Mike Schwartz's recent >experiments in Internet connectivity have made me wonder what kind of >load will be on the different networks during early and mid >September--anybody gonna have meters running, to see how things flow? >It'd make for a pretty good experiment, though it's probably too late >by now to start anything sizeable. >-- Probably alot, but not for very long, is my guess; and folks are way ahead of you. The IETF was informed of the date of the distribution becoming available. I believe the folks who run the internet will be watching carefully, and everyone is supposed to make the distribution available at the same moment. This should be an interesting experiment. At least two of the ftp sites (crl.dec.com and gatekeeper.dec.com) plan to have 25 MIP machines with tons of memory which will have the entire distribution in main memory and which are directly connected to the regional networks by 10megabit connections (NEARnet and BARRnet). In previous releases, the fact that so many people try to ftp at once meant that bandwidths were reduced to that of disk drives being driven into random seek patterns (if 50 people are ftp'ing at once, and your memory cache is less than the size of the distribution, you're generally having to go to disk to get data), and the machines we had as ftp sites were pretty wimpy. Last time here at CRL, we had lots of hassles, needing to add more swap space to our ftp machine (a poor Microvax II, of all things), build a new kernel with lots of processes, etc, given the load. This time we intend to be prepared! No such bottlenecks should happen this time; we should be about to send out around a distribution every minute or so from our site. Given the number of ftp sites (many more than for R4 (around 30) and much better distributed (on 3 or 4 continents), given the experience we all had with it), and the number of minutes in a day, I expect a large, but short, transient. If memory serves, in R4 we were amused to watch four different hosts inside of Sun Microsystems simultaneously FTP'ing distributions from two different Digital servers; this is particularly ironic, since Consortium members already had the bits sent to them. But the internet in the U.S. is now really quite high bandwidth (T3), so I suspect it will survive ok; it should still be an observable blip in the statistics, I'll bet. What happens in Europe, England, Australia, and Japan, is less clear, given the lower speed links in those parts of the world. Should be fun. Looking forward to it... :-). - Jim Gettys Digital Equipment Corporation Cambridge Research Lab. -- Digital Equipment Corporation Cambridge Research Laboratory
-----------[000190][next][prev][last][first]---------------------------------------------------- Date: 18 Aug 91 06:41:34 GMT From: romkey@ASYLUM.SF.CA.US (John Romkey) To: comp.protocols.tcp-ip Subject: ruptime and multiple networks
You desparately *don't* want UDP broadcasts to make it through a router, unless they're a directed broadcast for another network. Imagine the amount of bandwidth consumed if you broadcast a message across the entire Internet. ruptime's behaviour is correct; IP broadcasts are limited to a single network. - john romkey Epilogue Technology USENET/UUCP/Internet: romkey@asylum.sf.ca.us voice: 617 942-0915
-----------[000191][next][prev][last][first]---------------------------------------------------- Date: 18 Aug 91 06:52:24 GMT From: romkey@ASYLUM.SF.CA.US (John Romkey) To: comp.protocols.tcp-ip Subject: Proxy ARP (was Re: Gratuitous ARP)
I generally complain that proxy ARP is evil, as well, but I think there are two different situations that should be distinguished. The first is when you have a device like the old Kinetics box which allows a few hosts on one network to appear to be on another network - and this is the *only* IP connectivity the original network has. For instance, you've got some Macs on a localtalk network, and a K-box connecting them to an ethernet. The Mac's can use IP addresses that belong on the ethernet, and the K-box can proxy ARP for them and pass the packets on through. Almost like an IP-level bridge. In this scenario, the only thing that you're doing with proxy-ARP is hiding the fact that some hosts are really on the network next door. The second is where you're using proxy ARP to compensate for the fact that you have hosts that don't really know how to route packets (don't understand subnet masks), and further, as a general routing facility. I think the former is alright, when strictly adhered to, and I've found that the latter leads you into all sorts of wonderful twilight zone scenarios of routing loops and packets wandering off to distant galaxies, never to be seen again. - john romkey Epilogue Technology USENET/UUCP/Internet: romkey@asylum.sf.ca.us voice: 617 942-0915
-----------[000192][next][prev][last][first]---------------------------------------------------- Date: 18 Aug 91 08:23:14 GMT From: bill@unixland.natick.ma.us (Bill Heiser) To: comp.protocols.tcp-ip Subject: Re: X11R5 Release -- Net Lag?
brendan@cs.widener.edu (Brendan Kehoe) writes:
>I was just thinking ... what kind of an effect do you think the
>announced X11R5 release on September 5 will have on the overall
Anyone have "Release Notes" for the X11R5 release?
--
bill@unixland.natick.ma.us ...!uunet!{think,world}!unixland!bill
Dial: 508-655-3848(2400) 508-651-8723(96-HST) 508-651-8733(PEP-V32)
Shell Accounts for USENET (1,491 groups) and E-mail are Still Available!
-----------[000193][next][prev][last][first]---------------------------------------------------- Date: 18 Aug 91 11:27:22 GMT From: beyo@beyonet.UUCP (Steve Urich) To: comp.sys.3b1,comp.protocols.tcp-ip Subject: Re: Printing out 'ipctut' from osu archive
In article <260@zebra.UUCP> vern@zebra.UUCP (Vernon C. Hoxie) writes: > ->I recently downloaded a file from the AT&T-7300/3B1 archive at osu-cis ->which is called 'ipctut'. It is a tutorial originally issued by the ->Regents of the University of California. It contains no programming ->code but does have a Makefile to be used in printing out the document. <*> I got this file also and had the same problem. I hacked it to nroff but it didn't look pretty. Anyone willing to reformat the file to nroff? >vern >-- Steve Urich WB3FTP
-----------[000194][next][prev][last][first]---------------------------------------------------- Date: 18 Aug 91 14:37:32 GMT From: bob@MorningStar.Com (Bob Sutterfield) To: comp.protocols.tcp-ip Subject: Re: X11R5 Release -- Net Lag?
In article <1991Aug18.004805.13343@crl.dec.com> jg@crl.dec.com (Jim Gettys) writes: But the internet in the U.S. is now really quite high bandwidth (T3), so I suspect it will survive ok; [X11R5] should still be an observable blip in the statistics, I'll bet. Since the T3 links are not entirely stable yet, X11R5 could be either (a) an observable statistical blip, or (b) a major practice routing meltdown exercise for ANS's network engineers. I'm not betting...
-----------[000195][next][prev][last][first]---------------------------------------------------- Date: 18 Aug 91 18:24:11 GMT From: verber@pacific.mps.ohio-state.edu (Mark Verber) To: alt.sys.sun,comp.protocols.ppp,comp.protocols.tcp-ip Subject: Re: Diskless Sun 3/50 as X-terminal over SLIP/PPP. How to boot?
You have somne Sun 3/50 that you would like to boot an Xkernal via a serial line using PPP? You are kidding, right? The options you thought of were: > 1. Hack a new boot-prom with possibility to boot via serial port. > (Can you get source code for existing proms?). I believe that the source code to the boot proms was on an early SunOS source tape to educational sites. If you are going to the trouble of burning PPP into the PROMs, why not go all the way and burn an X server? I wouldn't look forwarder to watching an extremely stripped SunOS (I assume the Xkernal you are talking about is the one from Columbia and not the OS research from Arizona) booting via serial lines. I believe this would be a lot more trouble than it is worth. > 2. Buy a cheap SCSI-disk large enough for Xkernel & SLIP/PPP. Not a bad option. Here in the US you could easily do this for a few hundred US$ since disk requirements are so small. The preformance for either of these options will not be great. I have run X11 over a SLIP w/ VJ header compression on a 38.4kb line. It is usable, but far from great. I have had better luck with terminals that use some serial line X protocol like GraphOn or NCD Xremote. I personally would rather drop ~US$1000 for an Xterminal that is small, has no fan, and is a supported product that mess around will a jury-rigged Sun 3/50. Cheers, Mark Verber
-----------[000196][next][prev][last][first]---------------------------------------------------- Date: 18 Aug 91 18:51:26 GMT From: oldera@twg.com (Ed R. Alcoff) To: comp.protocols.tcp-ip Subject: Re: Protocol analyzers
Well, I dug thru my archives and I found the article that compares Protocol Analyzers. It was in May 1991 issue of Data Communications magazine. If you would like a copy call (212) 512 - 2000.
-----------[000197][next][prev][last][first]---------------------------------------------------- Date: 18 Aug 91 23:28:31 GMT From: pte900@jatz.aarnet.edu.au (Peter Elford) To: comp.unix.sysv386,comp.protocols.tcp-ip Subject: Re: Making the DNS work on System V Release 4 System
In article <1991Aug16.183050.6987@atc.SP.Unisys.COM>, mike@atc.SP.Unisys.COM (Mike Grenier) writes: |> From article <lcz.682273098@dptspd>, by lcz@sat.datapoint.com (Lee Ziegenhals): |> > pte900@jatz.aarnet.edu.au (Peter Elford) writes: |> > |> >>I have been trying to help a site with Intel's (?) System V Release 4 |> >>We had no problems running up the name server, but have been unable to |> >>make the IP applications (ftp, telnet, ping, etc) use the DNS rather |> >>than the /etc/hosts file. The /etc/netconfig file has had the resolver |> >>routines added to the name-to-address mapping field: |> > |> > Peter, you have to REBUILD those utilities with the resolv library to get them |> > to use DNS :-(. AT&T took the BSD versions of these utilities and ported them |> > almost verbatum. They call gethostbyname() to resolve host names, but the |> > utilities as distrbuted are linked with the non-DNS library. For some reason, |> > they did not provide a single compatibility library that uses the netconfig |> > entries to resolve host names. To use the netconfig stuff, an application must |> > call the new SVR4 name-to-address functions. |> > |> |> I don't believe thats true. Simply move /usr/lib/libsocket.so to |> somewhere safe and then move /usr/lib/socketdns.so to |> /usr/lib/socket.so. This will allow the already compiled utilities to |> use the DNS routines. That does not look to be an option they have ... $ ls /usr/lib/*dns* /usr/lib/*dns*: No such file or directory As a previous posting suggested, I think their version of SVR4 is not quite up to it ... they are trying to get an updated release form thei supplier. Peter Elford, e-mail: P.Elford@aarnet.edu.au Network Co-ordinator, phone: +61 6 249 3542 Australian Academic Research Network, fax: +61 6 247 3425 c/o, Computer Services Centre, pager: +61 6 245 3035 Australian National University post: PO Box 4 Canberra, AUSTRALIA Canberra 2601
-----------[000198][next][prev][last][first]---------------------------------------------------- Date: 18 Aug 91 23:32:52 GMT From: pte900@jatz.aarnet.edu.au (Peter Elford) To: comp.unix.sysv386,comp.protocols.tcp-ip Subject: Re: Making the DNS work on System V Release 4 System
In article <1991Aug16.182025.2862@ns.network.com>, clayh+@MUDLHEAD.NETWORK.COM (Clayton Haapala) writes: |> This won't apply unless the TCP on the system is Wollongong-derived, such as |> I've seen on ATT 3B2s and NCR Towers (some of them, anyway), but in these |> cases, there is an environment variable called NONAMESERVER that gets set by |> default to "true" or "yes" or something to turn the DNS function off. I've |> spent some time getting all the config files right and got named running, but |> still couldn't get lookup to work right until that variable got changed. I have not seen any reference to this in the (voluminous) documentation, and it does not work if I try it ... The derivation of the system in question is: Copyright (C) 1984, 1986, 1987, 1988, 1989, 1990 AT&T Copyright (C) 1987, 1988 Microsoft Corp. UNIX System V/386 Release 4.0 Version 2.0 From what others have said the weak link is the "Version 2.0" - apparently things work better in 3.0. |> Again, I've never seen the V.4 TCP. I'm beginning to think it's not something I want to have a lot to do with either ... Peter Elford, e-mail: P.Elford@aarnet.edu.au Network Co-ordinator, phone: +61 6 249 3542 Australian Academic Research Network, fax: +61 6 247 3425 c/o, Computer Services Centre, pager: +61 6 245 3035 Australian National University post: PO Box 4 Canberra, AUSTRALIA Canberra 2601
-----------[000199][next][prev][last][first]---------------------------------------------------- Date: 19 Aug 91 09:56:20 GMT From: myn%myn.computerland.kiev.ua@relay.USSR.EU.net (Yuri N. Muraviov) To: comp.protocols.tcp-ip Subject: (none)
unsubscribe Yuri Muraviov
-----------[000200][next][prev][last][first]---------------------------------------------------- Date: 19 Aug 91 11:27:15 GMT From: kuyper@cside1.uucp (Kuyper Hoffman) To: comp.protocols.tcp-ip Subject: Broadcasting with datagrams
I am fiddling with an example from Doug Comer's Internetworking with TCP/IP book. One of the code fragments he provides is a simple "whois" client/server pair. He uses the Berkeley sockets library, specifically, connected TCP sockets. I have subsequently converted this from TCP to UDP (Datagrams) in the hope of building a broadcast client. When sending directed Datagrams (ie filling a specific host address into the address field) it works great, I can send from a client on any machine to a server on any machine, the server receives the request and where it came from, services the request and sends back the reply. This is the picture (simplified IP numbers): A client may be run on either machine, a server is already running on both machines. |--T------------------T----------------T--| | | | Machine A Machine B Netwatch 192.9.200.1 192.9.200.2 192.9.200.3 3 basic scenarios exist: **** 1 **** Client on A sends message to 192.9.200.1 (Machine A itself) Netwatch indicates NO TRAFFIC (this is fine, a local call to the server) Server on A recvs message from 192.9.200.1 Server on A sends reply to 192.9.200.1 Netwatch indicates NO TRAFFIC (this is fine, a local call to the server) Client on A recvs reply from 192.9.200.1 **** 2 **** Client on A sends message to 192.9.200.2 Netwatch indicates message from 192.9.200.1 -> 192.9.200.2 Server on B recvs message from 192.9.200.1 Server on B sends reply to 192.9.200.1 Netwatch indicates message from 192.9.200.2 -> 192.9.200.1 Client on A revs reply from 192.9.200.2 **** 3 **** Client on A sends message to 192.9.200.255 (or 255.255.255.255) Netwatch indicates message from 192.9.200.1 -> 192.9.200.255 Server on B sees nothing And that's where it all stops.... Additional info: UNIX hosts running Intel or Interactive UNIX, with respective TCP/IP implementation, PC/IP Netwatch v9.6, Western Digital Ethernet cards, PC running Packet Driver v9.7, etc.... All pretty standard stuff. Sockets are opened as, address family AF_INET, type SOCK_DGRAM, protocol IPPROTO_UDP, in both the client and server. The client process has turned on SO_BROADCAST with the setsockopt system call, have I missed something, is this not enough? BTW turning this on in the server made no difference either.... Ultimately, I'd like to use this from PC/TCP, with a process on the PC broadcasting to a whole bunch of UNIX hosts. I'd really appreciate any help with this. Please e-mail responses and I'll post a summary when it's all in. -- | Kuyper Hoffman | Life is just a bowl of All-Bran | | kuyper@cside1.UUCP | You wake up every morning | | ....!ddsw1!olsa99!oct1!cside1!kuyper | And it's there.... | \--------------------------------------/ \--------------------------------/ -- | Kuyper Hoffman | Life is just a bowl of All-Bran | | kuyper@cside1.UUCP | You wake up every morning | | ....!ddsw1!olsa99!oct1!cside1!kuyper | And it's there.... | \--------------------------------------/ \--------------------------------/
-----------[000201][next][prev][last][first]---------------------------------------------------- Date: 19 Aug 91 11:58:50 GMT From: cattelld@prlhp1.prl.philips.co.uk (David Cattell) To: comp.protocols.tcp-ip Subject: IP source code request
Has anyone out there got or know where I can get the source code for an
IP gateway, preferably in C and for a PC ?
I need to be able to connect the Ethernet side of the PC to some serial
lines probably using a intelligent multiple line card like a Digiboard.
The PC needs to be able to gateway UDP/IP packets to/from the Ethernet
down the serial lines (possibly PSTN connections) from/to remote UDP/IP
users.
Unfortunately, I have to use email addresses to get the code as I can't
do an anonymous FTP from this site.
Any help would be appreciated.
Dave Cattell. cattell@prl.philips.co.uk
Philips Research Laboratories,
Redhill,
Surrey,
England.
-----------[000202][next][prev][last][first]---------------------------------------------------- Date: 19 Aug 91 12:54:56 GMT From: mark@TELESYS.NCSC.NAVY.MIL (Williams) To: comp.protocols.tcp-ip Subject: Re: Using both /etc/hosts and domain name server to get host addrs
Mark: I may be able to offer some info on your question. I'll respond privately (unless net users ask to see the thread...) Mark L. Williams Head, Telecommunications Branch Code 7630 Naval Coastal Systems Center Panama City, FL 32407-5000 (904)235-5153 (mark@telesys.ncsc.navy.mil)
-----------[000203][next][prev][last][first]---------------------------------------------------- Date: 19 Aug 91 13:16:18 GMT From: kevin@msa3b.UUCP (Kevin P. Kleinfelter) To: comp.unix.aix,comp.protocols.tcp-ip Subject: Slipping on SLIP
I'm setting up a system where many different workstations dialup an RS/6000, and communicate via TCP/IP with SLIP. Each serial port to be used with SLIP has a specific internet address assigned to it. Each workstation dials the SAME phone number, and the PBX rolls over to the first available modem. The problem: I need to assign the internet address for the port to the workstation. I *thought* I'd just have the workstation send a BOOTP. Unfortunately, BOOTPD simply does a table lookup from a "hardware" address shipped from the workstation to an internet address. I was hoping that BOOTPD would use the hardware address assigned to the serial port that the BOOTP came in on. So I set off to program my own version of BOOTPD. I did a bind to port 67, and a recv_mesg. I still get the address supplied from the workstation. How can I find out what serial port a UDP packet came from? Is it possible to use AIX as a dial-in SLIP server? -- Kevin Kleinfelter @ DBS, Inc (404) 239-2347 ...gatech!nanovx!msa3b!kevin Dun&Bradstreet Software, 3445 Peachtree Rd, NE, Atlanta GA 30326-1276 WARNING: I have been advised that email to kevin@msa3b.UUCP may bounce. It looks like email will have to go via 'gatech' because that is well-known.
-----------[000204][next][prev][last][first]---------------------------------------------------- Date: 19 Aug 91 13:31:34 GMT From: agodwin@acorn.co.uk (Adrian Godwin) To: comp.sys.3b1,comp.protocols.tcp-ip Subject: Re: Printing out 'ipctut' from osu archive
In article <210@beyonet.UUCP> beyo@beyonet.UUCP (Steve Urich) writes: >In article <260@zebra.UUCP> vern@zebra.UUCP (Vernon C. Hoxie) writes: >> >->I recently downloaded a file from the AT&T-7300/3B1 archive at osu-cis >->which is called 'ipctut'. It is a tutorial originally issued by the >->Regents of the University of California. It contains no programming >->code but does have a Makefile to be used in printing out the document. > > <*> I got this file also and had the same problem. I hacked it > to nroff but it didn't look pretty. > I printed this quite readably using (as per the makefile) tbl tutor.me | nroff -me and equally using psroff instead of nroff. However, this was on a BSD system (though I don't have ditroff) and the -me macros are available. I've had problems trying to use macro packages between systems - printing the DDDGuide using psroff on the BSD system with ms macros from CTIX was a disaster - so I don't know if just installing BSD macros on SysV will fix up the problem. Does anyone know if BSD nroff differs from AT&T nroff ? -adrian -- -------------------------------------------------------------------------- Adrian Godwin (agodwin@acorn.co.uk)
-----------[000205][next][prev][last][first]---------------------------------------------------- Date: 19 Aug 91 15:59:46 GMT From: louie@sayshell.umd.edu (Louis A. Mamakos) To: comp.protocols.tcp-ip Subject: Re: TCP FIN and window
In article <16378@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes: > Also, I thought I'd point out, since it's a pet peeve [:-)], the probe >time should be the same as the retransmission time, with exponential backoff, >and not 2 minutes (!). Berkeley uses a minimum of 5 seconds (as much as a >1000 times too large on an Ethernet), which makes for pretty poor performance >if you do drop a probe. Maybe they'll fix it in 4.4. :-) But, what does how fast the receiving process can empty the queue have to do with the retransmission time? When the processing receiving the data empties the queue, the TCP one that host should transmit a window update to the other end causing it to transmit more segments into the window. Probing every RTT seems pretty extreme, given that the user might have suspended his telnet client and has a complete TCP window's worth of data already "backed up". The only time you should need do a probe is when the ACK containaing the window update is lost. It will also detect a broken connection. It might be convinced that you could measure the flow rate of the connection, and use that to estimate how long the other end takes to consume the data, but that could only be taken as a starting point. > If you have an implementation that uses 2 minutes for a probe time, >or anything more than the smoothed rtt, you should complain to the vendor, >because dropped packets will give you unnecessary and noticeable delays. This has not been a noticable problem for us. Perhaps the solution is to have the remote TCP emit a window update whenever another MSS worth of data can be transmitted? louie
-----------[000206][next][prev][last][first]---------------------------------------------------- Date: 19 Aug 91 17:11:07 GMT From: dls@mentor.cc.purdue.edu (David L Stevens) To: comp.protocols.tcp-ip Subject: Re: TCP FIN and window
In article <1991Aug19.155946.3930@ni.umd.edu>, louie@sayshell.umd.edu (Louis A. Mamakos) writes: > But, what does how fast the receiving process can empty the queue have > to do with the retransmission time? When the processing receiving the > data empties the queue, the TCP one that host should transmit a window > update to the other end causing it to transmit more segments into the > window. Probing every RTT seems pretty extreme, given that the user > might have suspended his telnet client and has a complete TCP window's > worth of data already "backed up". I won't defend RFC 1122-- the authors can do that. What is important is that 5 seconds is inordinately long, and not adaptive. It isn't "every RTT", either, though-- it is exponentially backed off, and that, again, is the feature missing from many implementations. See my answer to below for some likely motiviation for the RTT relationship. > The only time you should need do a probe is when the ACK containaing > the window update is lost. It will also detect a broken connection. Not really true. As I recall (though I have to hedge my bets, since I'm not looking at RFC 793 now), window updates, while mentioned and perhaps even recommended, are not at all required. It is the *transmitter's* responsibility to make sure data flows. A completely conforming TCP can choose NOT to send window updates and if the probe time is some fixed (and long) constant, that delay will be guaranteed every time the window is closed. If, on the other hand, the receiver uses the RTT to judge whether a) a window update was lost, or b) window updates are not being sent, it can respond quickly to closed windows and see only the delay used to empty the receive buffer. Even if the RTT isn't the ideal starting point, it doesn't beat on the machine because of the exponential backoff, and it's much better than a constant (large or small) when network speeds vary as much as they do. I found out about the Berkeley 5 second delay because an early version of my TCP didn't do window updates (does now), and we saw the 5 second pauses when talking to BSD machines with enough data to fill the window. When talking to each other, however, because I used RFC1122, they'd recover from closed windows just fine. It should only occur among "most" implementations if the window update is lost, but 5 seconds is a big price for one lost packet. -- +-DLS (dls@mentor.cc.purdue.edu)
-----------[000207][next][prev][last][first]---------------------------------------------------- Date: 19 Aug 91 17:32:13 GMT From: pjj@interlink.com (Patrick Johnston) To: comp.protocols.tcp-ip Subject: rdump and rrestore for System V
I have heard of public domain or comercially available sources for rdump and rrestore but have not been able to find any. Can anyone help me in locating sources for these utilities for System V? Thanx, ------------------------------------------------------------------ Patrick Johnston Manager, International Marketing & Support pjj@interlink.com Interlink Computer Sciences sun!ntrlink!pjj 47370 Fremont Blvd Fremont, California 94538 voice: 415/657-9800 fax: 415/659-6381
-----------[000208][next][prev][last][first]---------------------------------------------------- Date: 19 Aug 91 18:22:05 GMT From: alpha@hubcap.clemson.edu (Shekhar Borde') To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains Subject: TCP Port Assignment
I am writing a client-server application that uses sockets. The port I need to use for this application has two restrictions. (1) It should be unassigned (obviously) (2) It's use should be restricted to the super-user. The rfc's on my machine list unassigned ports but do not tell if any are restricted for use by root only. Does anyone know how to determine a suitable port using the two aforementioned constraints. Any help will be greatly appreciated! -Shekhar Borde alpha@hubcap.clemson.edu
-----------[000209][next][prev][last][first]---------------------------------------------------- Date: 19 Aug 91 22:00:19 GMT From: donp@novell.com (don provan) To: comp.protocols.tcp-ip Subject: Re: TCP FIN and window
In article <16378@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes: > But it is a special case, as illuminated above. If you have exactly >4K of buffer space, you can't advertise 4K+1, because it'll force you to drop >the last byte of data (you can't tell a priori it'd be a FIN) during normal >flow and force a retransmit for that 1 byte, but you *can* accepted 4K of >data and the FIN. Well, i don't want to belabor the point, but what you're saying that FIN is a special case in your implementation. My point is that FIN isn't a special case in the protocol and, in fact, it could very well use up a byte of buffer space in any given implementation. I don't mean to contradict any of your proposed optimization techniques for FIN: they all look perfectly reasonable. But let's not start writing code that assumes all implementations will behave that way. For example, it's not a good idea to advertise a zero window when you're expecting a FIN because that may delay the FIN's transmission. > Also, I thought I'd point out, since it's a pet peeve [:-)], the probe >time should be the same as the retransmission time, with exponential backoff, >and not 2 minutes (!) What i said was that rfc793 recommended a 2 minute probe time (page 42). Of course, rfc1122 (page 92) corrected this to be as you described, but some TCP implementations predate rfc1122. In article <16460@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes: > Not really true. As I recall (though I have to hedge my bets, since >I'm not looking at RFC 793 now), window updates, while mentioned and perhaps >even recommended, are not at all required. It is the *transmitter's* >responsibility to make sure data flows. A completely conforming TCP can choose >NOT to send window updates and if the probe time is some fixed (and long) >constant, that delay will be guaranteed every time the window is closed. While it is the transmitter who ultimately knows if there's any data to be flowing and to insure that it flows, *both* parties are responsible for seeing that it flows efficiently. A completely conforming TCP can also choose to send a probe packet once an hour. Of course, that would be silly. Even waiting two minutes (initially) between probes would be silly. But it's just as silly not to send a window update signaling an open window after the window's been closed. don provan donp@novell.com
-----------[000210][next][prev][last][first]---------------------------------------------------- Date: 20 Aug 91 00:45:29 GMT From: revell@uunet.uu.net (James R Revell Jr) To: comp.protocols.tcp-ip Subject: Re: X11R5 Release -- Net Lag?
In article <1991Aug18.004805.13343@crl.dec.com> jg@crl.dec.com (Jim Gettys) writes:
} This should be an interesting experiment. At least two of the ftp
} sites (crl.dec.com and gatekeeper.dec.com) plan to have 25 MIP machines
} with tons of memory which will have the entire distribution in main memory
Plans so far here include using two workstations of similar ability as
special ftp servers just for X11R5. Although uucp folks will have
access via uunet.uu.net, no ftp access to X11R5 on uunet.uu.net will be
allowed. We remember the load due to ftping X11R4 when it came out all
too well...
--
James Revell sr uunet postmaster <revell@uunet.uu.net> /8^{~
-----------[000211][next][prev][last][first]---------------------------------------------------- Date: 20 Aug 91 02:23:01 GMT From: visjanap@ubvmsb.cc.buffalo.edu (Jan A. Pisanczyn, SUCB) To: comp.protocols.tcp-ip Subject: Programming C with TCP/IP
Posting this for a friend who does not have net access at this time, please
reply to him at his e-mail address listed at the end of the message, thanks!
-------------------------------
Hello!
I am taking an independent study next semester "advanced C", and will be
writing an application program in C using TCP/IP. My intents are to write
a client and a server obviously... I have done research papers on TCP/IP
so I understand the basic concepts behind the protocol suite, however, I
have no clue as how to write a client and server using the protocol. I am
looking for:
*Example programs in C
*Names of books I could buy
*Places on the network I could access with FTP with examples
OR documentation...
Please reply if you can help out with any of the above... Thanks in advance!
Rob Lizak Jr.
lizak98@snybufva.bitnet <= E-Mail address...
-----------[000212][next][prev][last][first]---------------------------------------------------- Date: 20 Aug 91 03:35:36 GMT From: dnichols@ceilidh.beartrack.com (Don Nichols (DoN.)) To: comp.sys.3b1,comp.protocols.tcp-ip Subject: Re: Printing out 'ipctut' from osu archive
In article <9265@acorn.co.uk> agodwin@acorn.co.uk (Adrian Godwin) writes: >In article <210@beyonet.UUCP> beyo@beyonet.UUCP (Steve Urich) writes: >>In article <260@zebra.UUCP> vern@zebra.UUCP (Vernon C. Hoxie) writes: >>> >>->I recently downloaded a file from the AT&T-7300/3B1 archive at osu-cis >>->which is called 'ipctut'. It is a tutorial originally issued by the >>->Regents of the University of California. It contains no programming >>->code but does have a Makefile to be used in printing out the document. >> >> <*> I got this file also and had the same problem. I hacked it >> to nroff but it didn't look pretty. >> > >I printed this quite readably using (as per the makefile) > > tbl tutor.me | nroff -me > >and equally using psroff instead of nroff. However, this was on a BSD >system (though I don't have ditroff) and the -me macros are available. groff compiles and runs on the 3b1, and includes the '-me' macro package. It is available on osu-cis (I am assured.) Good Luck DoN. -- Donald Nichols (DoN.) | Voice (Days): (703) 664-1585 (Eves): (703) 938-4564 D&D Data | Email: <dnichols@ceilidh.beartrack.com> I said it - no one else | <dnichols@ceilidh.aes.com> --- Black Holes are where God is dividing by zero ---
-----------[000213][next][prev][last][first]---------------------------------------------------- Date: 20 Aug 91 09:20:16 GMT From: simon@liasun2.epfl.ch (Simon Leinen) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains Subject: Re: TCP Port Assignment
In article <1991Aug19.182205.12836@hubcap.clemson.edu> alpha@hubcap.clemson.edu (Shekhar Borde') writes (abridged): The port I need to use for this application has two restrictions. (1) It should be unassigned (obviously) (2) It's use should be restricted to the super-user. The rfc's on my machine list unassigned ports but do not tell if any are restricted for use by root only. Does anyone know how to determine a suitable port using the two aforementioned constraints. Because the RFCs are intended to be OS independent, the notion of root does not make much sense. But if your application needs only be portable to UNIX systems, you will find in RFC 1060 that ports 256 to 1023 are used for "Unix Standard" services by convention. This implies that they are restricted to root in Unix systems. The RFC goes on and lists many such ports, but all in the 512--1023 subrange. Maybe there is a second (unwritten?) convention that reserves ports 256--511 for ``private'' assignments? -- Simon Leinen. Laboratoire d'Intelligence Artificielle Ecole Polytechnique Federale de Lausanne
-----------[000214][next][prev][last][first]---------------------------------------------------- Date: 20 Aug 91 12:35:15 GMT From: ggt@fstgds03.tu-graz.ac.at (Gerhard Thallinger) To: comp.protocols.tcp-ip Subject: Assignment of internet addresses and port numbers
I have two questions : 1) How and where do I have to apply for an official internet address range. Name of the organisation, E-mail address, or surface mail address, or fax and phone number would be fine. 2) Who is assiging the port numbers for tcp or udp communications. Are there any unassigned ones, which can be used by anybody ? Please respond via E-mail. I will summarize if there is enough interest. thanks in advance Gerhard G. Thallinger Internet: ggt@fstgds03.tu-graz.ac.at
-----------[000215][next][prev][last][first]---------------------------------------------------- Date: 20 Aug 91 12:57:13 GMT From: oldera@twg.com (Ed R. Alcoff) To: comp.protocols.tcp-ip Subject: Re: Protocol analyzers
In article <9108121906.AA12798@ftp.com> jbvb@ftp.com writes: >There are a number of software network monitors/protocol analyzers out >there, including LANWatch from FTP Software, WIN/Watch (may have been >renamed recently) from Wollongong and WatchTower from Intercon. These >use an existing PC (or Mac in the case of WatchTower) and network >interface, and tend to cost between 1/10th and 1/100th of the price of >a similarly-equipped high-end product. There's also Netwatch, which >is free as part of the MIT/CMU/Harvard PCIP software package. > >James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 >FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 James, I believe Intercon (Intecon?)'s WatchTower is something of a SNMP Management Station- somewhat similar to your own SNMP Tools. WIN/WATCH is something more akin to a protocol analyzer, I have always considered it a bargain @ $1,000 if you only need the functionality set it provides. Regards, Ed Alcoff Product Manager, VMS & Network Management Products The Wollongong Group, Inc. 1129 San Antonio Rd. Palo Alto, Ca. 94303 ph # (415) 962 - 7240 fax # (415) 969 - 5547 e-mail: oldera@twg.com #include std.disclaimer
-----------[000216][next][prev][last][first]---------------------------------------------------- Date: 20 Aug 91 14:49:26 GMT From: jas@proteon.com (John A. Shriver) To: comp.protocols.tcp-ip Subject: 3rd bit of 802.5 Source-routing RIF
Since there is still no approved IEEE standard for 802.5
source-routing (maybe it just got voted in), one has to rely on IBM's
constantly changing non-standard self-defined "architecture". In the
first versions of their architecture specifications, there was only
one frame type bit in the RIF. If 1 it was broadcast (all-rings, that
is), if 0 it was non-broadcast. I think this is what version 1.x of
IBM's bridge software implemented.
In the next IBM "architecture", there are 3 frame type bits. '0XX' is
non-broadcast, '10X' is all-routes broadcast, and '11X' is
single-route broadcast.
Then in IBM proposals to 802.5 (P802.5D/D15, back in 1989 when
attempts were being made to make the SR-TB to Ethernet a functional
part of the architecture), more combinations of these three bits were
proposed. The bit pattern '111' was proposed as spanning-tree routed
frame. ('10X' was changed to '100', and '11X' to '110'.) I would not
be at all surprised if this is what the 2.x versions of the IBM bridge
software do, since they came out at that time, and they interoperate
with the IBM 8209, which is an implementation of the now extremely
deprecated SR-TB. (The SR-TB, unlike an 802.1D transparent bridge, is
extremely non-idiot proof, and can easily be used to cause fatal
bridging loops!)
In the lastest ballot draft (P802.5M/D4), the bit combinations are
familiar, but the names have been changed to confuse the innocent:
'0XX' Specifially Routed (SR)
'10X' All Paths Explorer (APE)
'11X' Spanning Tree Explorer (STE)
Note that the third bit has returned to undefined.
(I won't even try and explain what they all mean. Consider yourself
lucky if you don't care!)
There is a reason that IEEE drafts say "This is an unapproved draft
which is subject to change and cannot be presumed to reflect the
position of Project 802 or the Institute of Electrical and Electronics
Engerrs. DO NOT SPECIFY OR CLAIM CONFORMANCE TO THIS DOCUMENT."
Implementing drafts can be hazardous to your health and sanity.
-----------[000217][next][prev][last][first]---------------------------------------------------- Date: 20 Aug 91 15:24:36 GMT From: hzessel@hpugrca.HP.COM (Holger Zessel) To: comp.protocols.tcp-ip Subject: Re: RPC/XDR weirdness
/ hpugrca:comp.protocols.tcp-ip / tb@Materna.DE (Torsten Beyer) / 7:45 am Aug 7, 1991 /
Hi Netland,
I'm working on a piece of RPC-software part of which transfers lists between
two machines. While debugging the stuff I realized that my program would
slowly grow ( in terms of memory usage ;-). I first thought that I forgot to
put some xdr_free's in the right place but couldn't find a fault on my side.
Finally I decided to look into the xdr routines generated by rpcgen. I think
I have found a bug but correct me if I'm blind. Consider the dir.x demo
software that comes with rpc. Here's what rpcgen generates of dir.x:
bool_t
xdr_nametype(xdrs, objp)
XDR *xdrs;
nametype *objp;
{
if (!xdr_string(xdrs, objp, MAXNAMELEN)) {
return (FALSE);
}
return (TRUE);
}
bool_t
xdr_namelist(xdrs, objp)
XDR *xdrs;
namelist *objp;
{
if (!xdr_pointer(xdrs, (char **)objp, sizeof(struct namenode), xdr_namenode)) {
return (FALSE);
}
return (TRUE);
}
bool_t
xdr_namenode(xdrs, objp)
XDR *xdrs;
namenode *objp;
{
if (!xdr_nametype(xdrs, &objp->name)) {
return (FALSE);
}
if (!xdr_namelist(xdrs, &objp->next)) {
return (FALSE);
}
return (TRUE);
}
Consider a list of n entries. When calling xdr_free for namenode, it would
free it's nametype entry and - by calling xdr_namelist the next one. But not
further. I'm I right to suspect that in the above case only the second list
element would get free'd by xdr ? Or is there a trick somewhere in
xdr_pointer that enables it to free subsequent list elements ???
Is there any whay to convince rpcgen that a certain struct is part of a list
and that it should generate recursive xdr routines ?? Or do I have to code
all this by hand ???
Any clues greatly appreciated
thanx in advance
-Torsten
--
Torsten Beyer e-mail : tb@Materna.DE
Dr. Materna GmbH VOX : +49 231 5599 225
Vosskuhle 37, D-4600 Dortmund FAX : +49 231 5599 100
"Strahlentod und Mutation durch die schnelle Kernfusion..", Kraftwerk
----------
-----------[000218][next][prev][last][first]---------------------------------------------------- Date: 20 Aug 91 16:13:06 GMT From: NIC@NIC.DDN.MIL (DDN Reference) To: comp.protocols.tcp-ip Subject: Security books
Attached is a description of books that would be of interest to many readers of the TCP-IP list. The subject of security is of ongoing interest in the current internet environment. This announcement is for informational purpose only, and should not be taken as a guarantee or recommendation by SRI or the NIC. Steven ...at the DDN NIC COMPUTER SECURITY BOOKS Two computer security books are now available from O'Reilly & Associates, publishers of the X Window System series and the UNIX Nutshell Handbook series: Computer Security Basics by Deborah Russell and G.T. Gangemi Sr. 464 pages, $29.95 Audience: Users and managers who need to become security-literate. This book provides an easy-to-understand introduction to the many topics encompassed by the term "computer security"--passwords, access controls, cryptography, trusted operating systems, network security, biometric devices, smart cards, and TEMPEST shielding. It provides detailed information on the Orange Book, the government's standard for the development of trusted systems. It also contains quick-reference material, including a security glossary and a summary of government programs, contacts, and legislation. Practical UNIX Security by Simson Garfinkel and Gene Spafford 512 pages, $29.95 Audience: UNIX users and system administrators. This book spells out the many security options for systems running either System V or Berkeley UNIX. It tells how to keep intruders out, how to tell if they've gotten in, how to clean up after them, and even how to prosecute them. It provides numerous scripts, detailed information on defending against network and communications breaches using modems, NFS, Secure NFS, Kerberos, and firewall machines, and a list of other security sources (books, organizations, etc.). To order these books or to discuss corporate discounts, contact O'Reilly & Associates at 632 Petaluma Avenue, Sebastopol, CA, 95472. In the US and Canada, call 1-800-338-6887. Overseas or California, call 707-829-0515. To send a FAX, call 707-829-0104." -------
-----------[000219][next][prev][last][first]---------------------------------------------------- Date: 20 Aug 91 17:06:40 GMT From: skr@ramnad.sps.mot.com To: comp.protocols.tcp-ip Subject: POP3 clients for Mac's and PC's
Hi!
Has anyone heard or seen the " stanford university Macintosh Internet
Protocol MacMH program" and " Personal Computer Internet Protocol MH program". These
programs are mentioned in the popper installation guide which I got from
"ftp.cc.berkeley.edu". I would appriciate any pointer's to these programs.
Thanks in advance
Vincent Shekher
Email address:Shekher-ayhc30@email.sps.mot.com
-----------[000220][next][prev][last][first]---------------------------------------------------- Date: 20 Aug 91 21:19:23 GMT From: gwilliam@SH.CS.NET (George Williams) To: comp.protocols.tcp-ip Subject: Re: EBCDIC ASCII and *much* more
Date: Thu, 08 Aug 91 16:54:54 +0200
From: Andr'e PIRARD <PIRARD@vm1.ulg.ac.be>
Subject: EBCDIC ASCII and *much* more
Thanks for the abundance of reference your writings afford in this area of
of character representation.It is a good paper which raises a couple of issues
the have been long standing in this increasing complex area, the
representation and presentation of transmitted data. I have not read all the
above mentioned writings and offer the following on on the subject.
[..........
Is being a standard justification for usage ? I think there are considerations
that should go into determining code sets and their resulting usage above
and beyond just standardization. I am not against standards but if you look
around us we are about to come full circle on the issue. What started out
to unite is serving to divide and the line of demarcation is based on the
highest yielding currency exchange.
I am in agreement that we should be striving for a network-neutral, or common,
character set. If you don't mind my taking the liberty of extending your
language analogies, however - the whole world does not speak english, french,
german, etc., right ( i,e. one language )?
There should be a global standard and the de facto 8859-1 fills many 'now'
requirements. It fulfills the needs of existing textual ( display and
print data, e.g file transfer, email ) applications, but remember there are
other worlds out there (International Graphics, Product Data, Fax, Video,
etc.) with still evolving data transmission requirements.
Have I been mislead all these years in thinking that syntactical matters of
usage and association; what gets translated, and where, as well as the
semantics associated with usage; what code points, character sets, et al. get
used , would get resolved within the architectural framework of something
called a presentation layer - ISO 8822 ? This is the only way it all serves
to make since. You make your association(s), describe the semantics. Trans-
formation of inbound and outbound PDU to and from host character to network
neutral format is done ( determination how, where and when ) when an
association is made ( please note: association does note imply connection ).
A machine can and should store data as best fits it's machine architecture.
Why, the hardware should be able to store a character as a bit if design
so facilitates. The translation to network neutral format can then be done
in a distributed fashion based on prior element association across
presentation boundaries. That is, data transformation can be looked at as
within the context of a flow association model; wherever the resource resides
is where the work will get done.
..........]
[The opinions and views expressed above are mine, alone.]
George Williams
-----------[000221][next][prev][last][first]---------------------------------------------------- Date: 20 Aug 91 22:17:14 GMT From: bobw@cc.usu.edu To: comp.protocols.tcp-ip Subject: TCP/IP for DEC PRO-350?
Is there a TCP/IP package that runs on a DEC PRO-350? Thanks -- =============================================================================== Bob Wood WA7MXZ bobw@cc.usu.edu Utah State University bobw@usu.bitnet Chemistry and Biochemistry tel. (801) 750-1614 UMC 0300 Logan, Utah 84322-0300 ===============================================================================
-----------[000222][next][prev][last][first]---------------------------------------------------- Date: 20 Aug 91 22:47:21 GMT From: Pezely@hitl.washington.edu (Dan) To: comp.protocols.misc,comp.protocols.tcp-ip,comp.protocol.iso,comp.dcom.lan Subject: Transport Protocols for Operating Environment platforms
I'd like some feed-back from those knowledgeable and experienced in network protocol design and implementations, hence the broad list of cross-postings. For Tele-presence/Operating Environment platforms, we need a rugged transport protocol like in the IP suite since we don't know all of the network types we'll be running on. That is, we would like one transport protocol for LANs and WANs at a wide range of speeds and signal-to-noise ratios. Here's what I had in mind. A lot of thought went into the IP suite and it was changed as necessary-- a sort of maturation. That seems to be a good place to start, considering my lab is not a networking research lab. (However, I would like to deeply persue such research in grad school or industry in about a year...) my idea-- probably not new: The protocol at the transport level is a cross between datagrams and connection-oriented communications models. It's datagrams with configurable options: - toggle acknowledgements on/off and when on, specify the ACK- count size for sequencing; - variable time-outs lengths defaulting to the `slow-start' technique; - variable retransmission attempt counts. Thus, straight datagrams and full connection-oriented models will be supported with the same protocol. Has this been attempted before? Initial implementations will be built on top of UDP/IP for its existing header fields. The application layer protocols are simply messages, but these messages may be larger than one packet, of course. Yes, an everything protocol might be nice but could be a nightmare, but while I'm at it: Synchronization may become a necessary feature for the applications, so working NTP into the picture would be nice. I'm just looking for some quick feedback. (follow-up to comp.protocols.misc) Thanks. -Dan P ps - this would be interesting to specify in Estelle and to simulate with GROPE. gee, I'm not doing too much this week... :)
-----------[000223][next][prev][last][first]---------------------------------------------------- Date: 21 Aug 91 00:03:07 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: export controls
Does anyone know about new export controls to "proscribed destinations"
on anything which uses "datagrams," "adaptive routing", or "fast select",
in a recent Federal Register? I was just asked if my employer's products
uses such high tech stuff. Further exchanges with the guvinment obtained
definitions for all three:
"Fast select" makes no sense to me, except that it sounds x.25-ish.
"Datagrams" seem to be what you would expect, from ethernet or other
LAN frames to IP to UDP to postcards from grandma.
"Adaptive routing" appears to cover everything from routed thru
the latest OSPF-whatnot.
So what's the deal? Are our fearless leaders trying to keep that
super top secret BSD IP and routing code away from Naughty Sadam?
Vernon Schryver, vjs@sgi.com
-----------[000224][next][prev][last][first]---------------------------------------------------- Date: 21 Aug 91 00:24:17 GMT From: root@CABELL.VCU.EDU (System PRIVILEGED Account) To: comp.protocols.tcp-ip Subject: Second posting
This is a second posting....and I'm getting desperate.....:) Several months ago there was several inquiries about a program that would display active tcp connections....tying together process id's and port numbers. At the time our system was a Pyramid 9810. I got a copy of the file and it worked great! Since that time, we have migrated to a DEC 5500 running Ultrix 4.2. Like a dummy I deleted the source code and the location of the original file. I desperately need that program again....can someone out there tell me where I can find such a program? I vaguely remember it being called something like pff or something like that.... Any help will be greatly appreciated.... Bryan Miller Network Manager Virginia Commonwealth University
-----------[000225][next][prev][last][first]---------------------------------------------------- Date: 21 Aug 91 01:16:42 GMT From: coates@UC780.UMD.EDU To: comp.protocols.tcp-ip Subject: Re: Programming C with TCP/IP
In article <87966@eerie.acsu.Buffalo.EDU>, visjanap@ubvmsb.cc.buffalo.edu (Jan A. Pisanczyn, SUCB) writes: >Posting this for a friend who does not have net access at this time, please >reply to him at his e-mail address listed at the end of the message, thanks! > >Hello! > > I am taking an independent study next semester "advanced C", and will be >writing an application program in C using TCP/IP. My intents are to write >a client and a server obviously... I have done research papers on TCP/IP >so I understand the basic concepts behind the protocol suite, however, I >have no clue as how to write a client and server using the protocol. I am >looking for: > > *Example programs in C > *Names of books I could buy > *Places on the network I could access with FTP with examples > OR documentation... > >Please reply if you can help out with any of the above... Thanks in advance! > >Rob Lizak Jr. > >lizak98@snybufva.bitnet <= E-Mail address... Please post replies, Thanks! --- coates@uc780.umd.edu
-----------[000226][next][prev][last][first]---------------------------------------------------- Date: 21 Aug 91 03:29:42 GMT From: cryptkpr@cc.utah.edu (H. CARLTON DOE III) To: comp.protocols.tcp-ip Subject: Network Performance Tools Needed--Please forward recent info
I need some recommendations on tools (both hardware and software) to analyze my network performance. It appears as though this has been a fairly recent thread based on one post I saw tonight. What I'd like to get then is a recap of the info posted if anyone has it. What I am trying to do is isolate and look at each part of the transmission and receipt of data and find where potential bottlenecks are. When finished I'd like to be able to know what the load on the CPU is, the network interface card performance etc. for all my machines as well as the load and performance of the transport medium. I'm looking at getting some real screamer machines (in terms of cpu speeds, etc.) but don't want to waste the money if the interface cards can't keep up or the transport layer is maxed out. I'm currently running AT&T 386/486 machines with Sys V R. 3.2 & R. 4. The TCP/IP is a Wollongong product running over a STARlan 10baseT star topology. All the network cards are 10mb/s. If anyone can help me with this request I'd appreciate the e-mail. My thanks in advance to any who reply. Carlton Doe (aka the Crypt Keeper) Spectrum Field Services AT&T Mail: attmail!alexis!carlton Internet: att!attmail!alexis!carlton@uunet.uu.net OR cryptkpr@cc.utah.edu
-----------[000227][next][prev][last][first]---------------------------------------------------- Date: 21 Aug 91 07:12:36 GMT From: AKayser@dnpap.et.tudelft.nl (Alfred Kayser) To: comp.protocols.tcp-ip Subject: Re: Protocol analyzers
oldera@twg.com (Ed R. Alcoff) writes: >In article <9108121906.AA12798@ftp.com> jbvb@ftp.com writes: >>There are a number of software network monitors/protocol analyzers out >>there, including LANWatch from FTP Software, WIN/Watch (may have been >>renamed recently) from Wollongong and WatchTower from Intercon. These >>use an existing PC (or Mac in the case of WatchTower) and network >>interface, and tend to cost between 1/10th and 1/100th of the price of >>a similarly-equipped high-end product. There's also Netwatch, which >>is free as part of the MIT/CMU/Harvard PCIP software package. >> >>James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 >>FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 >James, I believe Intercon (Intecon?)'s WatchTower is something of a >SNMP Management Station- somewhat similar to your own SNMP Tools. >WIN/WATCH is something more akin to a protocol analyzer, I have always >considered it a bargain @ $1,000 if you only need the functionality >set it provides. And there is our very free network monitoring tool called 'The Beholder' It runs on a standard PC with a network card. It supports SNMP, UDP/IP with PING and TFTP. It can monitor network load, type distribution, and length distribution. It has an source/destination matrix. Up to 5000 connections can be online be monitored. It will have protocol analyzers. This is currently being worked on. It will have host profil watchers for operation and security protection. It includes (very soon now) the complete source and is easily extendible. Enough hipe for now. There enough monitors to make a choice. Make sure you make the right choice. (Before paying a lot of coins.) Greetings, Alfred -- -- Ir. Alfred Kayser. PACS, OS/2, TCP/IP. --- Email: AKayser@et.tudelft.nl -- -- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786179 -- -- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 --
-----------[000228][next][prev][last][first]---------------------------------------------------- Date: 21 Aug 91 07:40:03 GMT From: frank@unibi.uni-bielefeld.de (0015) To: comp.protocols.tcp-ip Subject: private MIB for MultiNet
I need the private MIB extensions which are used in LANNETs cabling system MultiNet. Is this available anywhere ? Frank
-----------[000229][next][prev][last][first]---------------------------------------------------- Date: 21 Aug 91 13:01:00 GMT From: heisinger@MDCGWY.MDC.COM To: comp.protocols.tcp-ip Subject: NQS Implementations for IBM MVS
Is anyone aware of an implementation of NQS (Network Queue Service)
on top of KNET for MVS or IBM's MVS TCP/IP product?
Thanks in advance.
Patrick D. Heisinger
W126/3062182
McDonnell Douglas
P. O. Box 516
St. Louis, MO 63166
(314) 232-6349
heisinger@mdcgwy.mdc.com
-----------[000230][next][prev][last][first]---------------------------------------------------- Date: 21 Aug 91 14:20:43 GMT From: poorman@convex.com (Peter W. Poorman) To: comp.protocols.tcp-ip Subject: Re: Programming C with TCP/IP
The best book for learning TCP/IP-on-UNIX programming that I have seen is "UNIX Network Programming" by W. Richard Stevens. (Prentice Hall, 1990, ISBN 0-13-949876-1.) Very lucid explainations, plus plenty of C source code. Includes full implementations of clients and servers. --Pete Poorman poorman@convex.com
-----------[000231][next][prev][last][first]---------------------------------------------------- Date: 21 Aug 91 14:36:53 GMT From: tcwan@umiami.ir.miami.edu To: comp.protocols.tcp-ip Subject: Re: Programming C with TCP/IP
In article <1991Aug21.011642.9491@socrates.umd.edu>, coates@UC780.UMD.EDU writes: > In article <87966@eerie.acsu.Buffalo.EDU>, visjanap@ubvmsb.cc.buffalo.edu > (Jan A. Pisanczyn, SUCB) writes: >>Posting this for a friend who does not have net access at this time, please >>reply to him at his e-mail address listed at the end of the message, thanks! >> >>Hello! >> >> I am taking an independent study next semester "advanced C", and will be >>writing an application program in C using TCP/IP. My intents are to write >>a client and a server obviously... I have done research papers on TCP/IP >>so I understand the basic concepts behind the protocol suite, however, I >>have no clue as how to write a client and server using the protocol. I am >>looking for: >> >> *Example programs in C >> *Names of books I could buy >> *Places on the network I could access with FTP with examples >> OR documentation... >> >>Please reply if you can help out with any of the above... Thanks in advance! >> >>Rob Lizak Jr. >> >>lizak98@snybufva.bitnet <= E-Mail address... > > Please post replies, Thanks! > --- > coates@uc780.umd.edu I just discovered a book by W. Richard Stevens, "UNIX Network Programming", which deals with BSD sockets and SysV TLI/streams (not in as much detail). Seems to be pretty informative, includes C source for servers and clients using BSD sockets, etc. Coverage of SysV is a little scant, possibly as the book was published in 1990. SysVR4 is only mentioned in the Intro, and examples come from SVR3. The ISBN is 0-13-949876-1, published by Prentice Hall. I'm still reading through the book, so I'm not able to give a thorough impression. Definitely a good intro to Unix networking, though. Hope this helps. I'm also interested in other references, etc. On a related question, I can't seem to find any documentation on how to set up STREAMs modules for TCP/IP in SysV. I am using an Apollo running Domain/OS 10.2, and all the docs, (programming with SysV Streams, etc) assumes the existence of the interface, without any description of how to install them. Does anyone have any ideas? T.C. Wan Grad. Student, Dept. of ECE, Univ. of Miami, FL
-----------[000232][next][prev][last][first]---------------------------------------------------- Date: 21 Aug 91 15:09:29 GMT From: revell@uunet.uu.net (James R Revell Jr) To: comp.protocols.tcp-ip Subject: Re: Programming C with TCP/IP
In article <poorman.682784443@convex.convex.com> poorman@convex.com (Peter W. Poorman) writes:
} The best book for learning TCP/IP-on-UNIX programming that I have seen
} is "UNIX Network Programming" by W. Richard Stevens.
Sources from the book are in ftp.uu.net:/published/stevens.netprog.tar.Z
--
James Revell sr uunet postmaster <revell@uunet.uu.net> /8^{~
-----------[000233][next][prev][last][first]---------------------------------------------------- Date: 21 Aug 91 16:21:35 GMT From: lars@spike.cmc.com (Lars Poulsen) To: comp.protocols.tcp-ip Subject: Re: Transport Protocols for Operating Environment platforms
Dan Pezely wrote in comp.dcom.telecom:
> For Tele-presence/Operating Environment platforms, we need a rugged
> transport protocol like in the IP suite since we don't know all of the
> network types we'll be running on. That is, we would like one
> transport protocol for LANs and WANs at a wide range of speeds and
> signal-to-noise ratios.
To which I replied:
> I would suggest that you implement TCP and IP as per the RFC's;
> NO CHANGES. What makes you think you might need to change it ?
And Dan countered:
> We need more than just connection-oriented and straight datagrams; we'd
> like something which is semi-reliable and gives up after a few tries--
> fewer than with TCP. However, we don't know exactly how many tries to give
> up after, and with newer CPUs and networks, the params may change.
> We will, of course, use UDP/IP for its header info for compatibility, but
> some of the organizations funding our lab are willing to run any protocol
> developed for our projects-- protocols which would probably be developed
> jointly with another lab or school.
> Also, IP is being used on the high speed nets, but with gigabit nets, I
> understand that the ID field can get wrapped around while some packets are
> still traveling from coast-to-coast. Some of our projects will definately
> put such things to the test (when, I don't know).
And here I (Lars) speak again:
I am glad to hear that you are willing to use IP; at least this lets
you route through other people's networks, and through local network
built with off-the-shelf components into your (monitoring?) systems.
As to your specific list of issues:
(1) The point at which a TCP implementation gives up and resets the
connection is an implementation issue, not a protocol issue. You
could make it tunable and still stay TCP compatible/interoperable.
(2) If you need a "soft reset" capability to allow data loss to be
recognized without breaking the connection (X.25-like) then you do have
a requirement that TCP cannot handle.
(3) If you have more than 2**32 bytes in flight, you do have a sequence
number wrap-around problem. I respectfully submit, though, that if
you expect to carry gigabits per second over a SINGLE connection, you
will have MANY technical obstacles to overcome, and you had better have
beaucoup funding.
>> Thank you! Does this criteria alter your opinion at all?
Actually, Rockwell is probably fairly indifferent ... but your note
sounded very much like the usual calls for "reliable datagram
protocols" which usualy turn out to require more overhead and work
less well than TCP. In fact the biggest shortcoming of TCP for most
applications that claim to need to invent another protocol, is the
lack of record boundaries. And these can usually be inserted by
prefixing each record with a byte count, and sending the last buffer
of the record with a PUSH bit.
If you need to get something operational with two years, I still think
TCP is your best bet. If you have funding for long-term research, you
could take a look at XTP, and if that doesn't work for you either, you
could start an IETF working group towards a "super-TCP" with the extra
features that you need.
> ps - I'd like to post this to the list of newsgroups which the
> moderator of comp.dcom.telecom forgot to cross-post to:
> comp.protocols.misc, comp.protocols.tcp-ip, comp.protocol.iso,
> comp.dcom.lan, and comp.dcom.telecom
> is this ok with you?
I personally have no objection, but be forewarned, that as a matter of
editorial policy, TELECOM does not accept crosspostings. In my
opinion, the "right" place for this discussion is on the TCP-IP
mailing list, also seen as comp.protocols.tcp-ip. Thus, I have cc'd
this to both TELECOM and TCP-IP.
Lars Poulsen, SMTS Software Engineer CMC Rockwell lars@CMC.COM
--
/ Lars Poulsen, SMTS Software Engineer
CMC Rockwell lars@CMC.COM
-----------[000234][next][prev][last][first]---------------------------------------------------- Date: 21 Aug 91 17:27:10 GMT From: Mark_McFadyen@mindlink.bc.ca (Mark McFadyen) To: comp.protocols.tcp-ip Subject: Beame and Whiteside PC-NFS
Does anyone have any experience with setting up B&W PC-NFS? We have the NFS drive working fine, but we cannot seem to be able to link a local device (ie LPT3) to a remote printer. The command we are using (trying to use) is: NET LINK LPT3 \hostname\HPJET where HPJET is defined in the /dev/printcap file. This gives us a "Invalid remote device." error message and refuses to link. Does anyone have any suggestions? Or is my PRINTCAP file setup wrong? What is the format? Thanks. -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* I could be the Walrus. It still wouldn't change the fact that I have to bum rides off people. - Ferris. MRM.
-----------[000235][next][prev][last][first]---------------------------------------------------- Date: 21 Aug 91 21:25:24 GMT From: jbvb@FTP.COM (James B. Van Bokkelen) To: comp.protocols.tcp-ip Subject: Re: pc-nfs
We are trying to set up a class room of IBM LEO ie PS2/55 machines
packaged with a modified Western Digital Ethernet board.
1) is there a packet driver for this IBM/wd ether board?
They changed the Microchannel ID value in the version IBM OEM'ed, so any
drivers which use the ID value to obtain the board's POS configuration
(instead of making the user type it twice) need to try all four possible
values. Our WD8003 kernel does this since v2.05...
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000236][next][prev][last][first]---------------------------------------------------- Date: 21 Aug 91 22:42:48 GMT From: fillmore@EMR.CA (Bob Fillmore 992-2832) To: comp.protocols.tcp-ip Subject: unreliable ping with PC-NFS
A client just reported to me a strange problem with PC-NFS: using the ping comand supplied with that package, he can ping some hosts reliably, but ping replies "host not responding" for a couple of others. When he goes to those hosts and pings back in the other direction all is OK. Also, Telnet and FTP work OK from PC-NFS to any host. Does anyone know why this is happening? -- Bob Fillmore, Systems Software & Communications email: fillmore@emr.ca Information Technology Branch, BIX: bfillmore Energy, Mines, & Resources Canada Voice: (613) 992-2832 588 Booth St., Ottawa, Ontario, Canada K1A 0E4 FAX: (613) 996-2953
-----------[000237][next][prev][last][first]----------------------------------------------------
Date: 22 Aug 91 01:21:06 GMT
From: almquist@JESSICA.STANFORD.EDU ("Philip Almquist")
To: comp.protocols.tcp-ip
Subject: Re: What's your IP Time to Live?Bob, The official recommended value for IP Time-to-Live can always be found in the Assigned Numbers RFC. The current version of that document, RFC-1060, recommends a TTL of 32. Philip
-----------[000238][next][prev][last][first]---------------------------------------------------- Date: 22 Aug 91 06:36:48 GMT From: j.onions@XTEL.CO.UK (Julian Onions) To: comp.protocols.tcp-ip Subject: Re: Finger server as a requirement for all Internet hosts
> In favor for the world wide electronic directory I must argue against Henry,
> and make the folowing statement instead.
>
> In the near future the correct answer will hopefully be: Look him up
> in "the directory" (read X.500).
>
> This have the potential to work better. For example, if he is on
> vacation he will not answer his phone. Also, in the directory there
> could, possibly, be included information on how often he reads his
> mail.
One of the attibutes of a person in the X.500 schema is
preferredDeliveryMethod, which will tell you how the person prefers to
have their messages arrive. It is an ordered sequence of possibilities
that is made up of
ANY - obvious
MHS - electronic mail to me and you
PHYSICAL- postal mail
TELEX - do people still use this?
TELETEX - someone must use this but I have no idea who...
G3FAX - everyone uses this
G4FAX - everyone wants to use this
IA5 - I don't quite no what this means (strict translation is
"ascii")
VIDEOTEX- call 'em up on the video phone... oh, don't you have one?
TELEPHONE work this one out yourself.
So, IF people make sensible use of this attribute you can take a good
guess at how they want to be contacted. (I guess there are a couple of
missing ones such as
DONT - I don't want to talk to anyone, I'm a recluse; or
alterntively "if you have to ask, don't bother".
INPERSON - make an appointment with my secretary and we'll "do lunch"
)
Julian.
-----------[000239][next][prev][last][first]---------------------------------------------------- Date: 22 Aug 91 09:58:00 GMT From: wolf@grasp1.univ-lyon1.fr (Christophe Wolfhugel) To: comp.mail.sendmail,comp.protocols.tcp-ip Subject: Address / protocol family (sendmail SVR4)
[not sure whether this problem is sendmail specific or not]. I'm trying to use the tcp mailer of a SVR4 sendmail. The mail seems to be correctly interpreted and when it's time to deliver it over SMTP, sendmail indicates following error: (sent) 1000ad50 1 050 wolf@itesec... Connecting to itecom via ether... Trying 192.70.106.1... addr= c0466a01 port= 25 family=2 zero=0 Address family not supported by protocol family (send) 1000ad50 1 554 wolf@itesec... Service unavailable: Address family not supported by protocol family wolf@itesec... Service unavailable: Address family not supported by protocol family (sent) 1000ad50 1 554 wolf@itesec... Service unavailable: Address family not supported by protocol family (send) 1000ad50 1 050 Saving message in //dead.letter I have absolutely no idea where this error could come from. When I manually telnet to itecom everything goes fine. Any suggestion? Chris
-----------[000240][next][prev][last][first]---------------------------------------------------- Date: 22 Aug 91 12:24:21 GMT From: koelman@issun3.stc.nl (Ton Koelman) To: comp.protocols.tcp-ip Subject: cisco X.25, suspected bug
From koelman Wed Aug 14 16:44:53 1991 Return-Path: <koelman> Received: by comsun9.stc.nl (4.1/SMI-4.1) id AA00212; Wed, 14 Aug 91 16:44:50 +0100 Date: Wed, 14 Aug 91 16:44:50 +0100 From: koelman (Ton Koelman) Message-Id: <9108141544.AA00212@comsun9.stc.nl> To: customer-service%cisco.com@hp4nl.nluug.nl Subject: suspected bug: clearing of non IP X.25 VCs Cc: gerrits@issun3, koelman, robinson@issun3 Status: RO Hello, We're setting up an X.25 service across an AGS+ and a CGS (release 8.2) connected with a 64 kbit/s PPP serial line. A 'pure' (i.e. not using IP) X.25 terminal is connected to each of the routers. When setting up VCs between the X.25 terminals we experience unexpected clearing by the routers with the diagnostics 0x30 (timer expired) on one side and 0x77 (International Routing Problem) on the other side. We have strong suspicion that this is caused by the X.25 idle timeout used by IP because by disabling that (x25 idle 0) the problem disappears. This is however costly because the VCs used by IP (which we also have) stay up indefinitely increasing the X.25 charges from our local PTT... The fundamental problem seems to be that the X.25 idle timeout function is associated with the interface and therefore, incorrectly also operates on VCs that do not carry IP. This must be a known bug because the X.25 service is not of much use this way. If possible could you please confirm our findings and inform us about potential workarounds.... Regards, Ton Koelman koelman@stc.nl SHAPE Technical Centre The Netherlands
-----------[000241][next][prev][last][first]---------------------------------------------------- Date: 22 Aug 91 13:37:37 GMT From: gary@sci34hub.sci.com (Gary Heston) To: comp.protocols.tcp-ip Subject: Re: IP source code request
In article <1417@prlhp1.prl.philips.co.uk> cattelld@prlhp1.UUCP (David Cattell) writes:
> Has anyone out there got or know where I can get the source code for an
> IP gateway, preferably in C and for a PC ?
Do you mean a real gateway, that interfaces between a domain and an
internet, or something along the lines of a router or bridge?
> I need to be able to connect the Ethernet side of the PC to some serial
> lines probably using a intelligent multiple line card like a Digiboard.
> The PC needs to be able to gateway UDP/IP packets to/from the Ethernet
> down the serial lines (possibly PSTN connections) from/to remote UDP/IP
> users.
Please clarify--does this code need to think about what packets go
where, or does it simply repeat everything in each direction? If no
intelligence is required, then something like PCBridge should work
fine. It'll bridge between ethernet and serial, although you may need to
work on the serial interface, since it expects one standard COM port
instead of many. If you need to do routing, perhaps a pre-license copy
of PCRoute would help. Both are copyrighted, but available. Note that I
specified the pre-license version of PCRoute; NWU made some licensing
agreement with Lanport for a commercialized version and changed the
copyright notice on the later versions back around February to require
licensing. Don't get that version. (The agreement was made without even
mentioning it to the author, Vance Morrison; he found out when someone
emailed him asking about the change. We can expect a posting from someone
at NWU that believes they can make retroactive copywright changes.)
> Unfortunately, I have to use email addresses to get the code as I can't
> do an anonymous FTP from this site.
In the same situation myself--alleviated somewhat by a direct link to
uunet. They have both packages there.
--
Gary Heston System Mismanager and technoflunky uunet!sci34hub!gary or
My opinions, not theirs. SCI Systems, Inc. gary@sci34hub.sci.com
Become a pheresis donor. Loan your blood to the Red Cross for a couple
of hours. They, and cancer patients, will appreciate it.
-----------[000242][next][prev][last][first]---------------------------------------------------- Date: 22 Aug 91 16:21:54 GMT From: rpcfod@nimbus@UUNET.UU.NET (Robert Patt-Corner) To: comp.protocols.tcp-ip Subject: SLIP and data compress/correction
We're having some problems getting slip links to work on a v.32bis/v.42bis modem pair using anything other than data compression and correction turned off. Is there any inherent thing in the SLIP protocol that prevents this? Result with compression or correction is checksum errors on sender and/or receiver. We're testing with KA9Q.
-----------[000243][next][prev][last][first]---------------------------------------------------- Date: 22 Aug 91 17:11:26 GMT From: lars@spectrum.cmc.com (Lars Poulsen) To: comp.protocols.tcp-ip Subject: TCP-IP@NIC.DDN.MIL vs USENET's "comp.protocols.tcp-ip"
I originally submitted the message just before this one to TCP-IP@NIC.DDN.MIL, and it has not been returned as undeliverable, but after 24 hours, it has not shown up on comp.protocols.tcp-ip yet. It appears that the mailing list has become separated from the newsgroup, perhaps intentionally. If so, when did that happen ? Or is NIC in bad shape ? -- / Lars Poulsen, SMTS Software Engineer CMC Rockwell lars@CMC.COM
-----------[000244][next][prev][last][first]---------------------------------------------------- Date: 22 Aug 91 17:19:50 GMT From: blknowle@aragorn.jdssc.dca.mil (Brad L. Knowles) To: comp.protocols.tcp-ip Subject: Request assistance with /etc/sendmail.cf configuration...
Folks,
I recently posted a question to the Sun-Managers mailing list that I
have since decided is more appropriate here.
I have a fairly new Sun SPARCstation 2/GX, with 16M RAM, 32M swap,
207M Quantum internal hard drive, and 669M Seagate external hard drive
that I have been trying to set up as the primary mailhost for the domain
JDSSC.DCA.MIL (our previous mailhost bit the dust, and the guy that set it
up no longer works on that project).
I took the plain vanilla /usr/lib/sendmail.main.cf and copied it to
/etc/sendmail.cf, and made two changes -- I defined the "m" macro to be
JDSSC.DCA.MIL, and changed the primary Mailer to be "ddn", as opposed to
"smartuucp" (all of this, as per the Sun documentation). The primary
relay mailhost was set to be ddn-gateway, which I have not changed, but I
defined ddn-gateway to be an alias for NIC.DDN.MIL in /etc/hosts on the
NIS Master Server (and thus, for our entire NIS domain). This proved to
be unreliable, so I changed it to be uunet.uu.net, but they soon stopped
accepting SMTP connections from me.
Obviously, I am doing something wrong, because when I mentioned my
plight on Sun-Managers, I got two responses. One of them said (in effect)
"With a properly set up DNS, you should be able to deliver mail directly,
and not have to foist it off on to some unsuspecting host." The other
said (in effect) "We made some minor changes to our /etc/sendmail.cf file,
commenting out a few things that forward mail to a mailhost, when we want
this particular machine to BE the mailhost."
Now, I think I set up the DNS properly on this machine, but something
was mentioned about "hostresorder" that could be used to force the
resolver to resolve addresses in a specific order -- would some of you out
there be kind enough to help me set up my hostresorder to be correct?
Also, if there are any "tricks" to setting up /etc/sendmail.cf on a
primary mailhost, would you be kind enough to share some of them with me?
I guess my biggest problem is that the documentation I have available to
me just doesn't give me enough information, and that without
documentation, the only way you know if things have been set up properly
is to have already done it (nice little Catch-22, huh?).
I don't suppose this problem is somewhere in the FAQ list? Do we even
have an official FAQ list?
I would be happy to RTFM, if someone would be kind enough to point me
at the right one (I've read *all* of the appropriate SunOS 4.1.1B
documentation I can find, but may have missed something).
BTW, I don't know if this helps, but recently, any time I ping a host
not directly on Milnet (like LCS.MIT.EDU, NS.NASA.GOV, UUNET.UU.NET), all
I get is an error bounced back that says:
ICMP Host Unreachable from gateway GW.NIC.DDN.MIL (26.31.0.73)
for icmp from aragorn (137.130.4.4) to XX.LCS.MIT.EDU (18.26.0.36)
Or something along these lines (I once got a message to this effect back
from moffett-fld-mb.ddn.mil when I tried to ping 192.52.195.10, another
address for NS.NASA.GOV). I don't know if GW.NIC.DDN.MIL is down, if they
are having problems with their NSFnet connection, or what, but I do know
that I seem to be completely disconnected from anything other than Milnet,
as a result (fortunately for me, the TCP-IP Mailing List is hosted from
NISC.NIC.DDN.MIL). I understand from Peter Welch (pjw@USNA.NAVY.MIL) that
the two Milnet-Internet gateways get *extremely* congested during the day,
but this shouldn't affect my inbound mail at night, should it? (I got
only two mail messages last night, and with the mailing lists I am on, 20
to 30 overnight is much more common)
Oh, BTW, don't ask me to use traceroute to figure out what's
going on -- I don't have it yet. My lack of Internet connectivity is
greatly hindering my ability to get it, too!
I hope my tone of "voice" hasn't offended you, I'm just getting a
little desperate right now!
Please respond via e-mail. I will summarize and re-post, if appropriate.
_________________________________________________________________________
| Brad Knowles | Internet: blknowle@frodo.jdssc.dca.mil |
| DISA/DSSO/JNSL | Ph: (703) 693-5849 Fax: (703) 693-7329 |
| The Pentagon, Room BE685 |============== DSN: 223-5849 =============|
| Washington, D.C. 20301-7010 | Speaking from, not necessarily for DISA! |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----------[000245][next][prev][last][first]---------------------------------------------------- Date: 22 Aug 91 17:20:44 GMT From: andy@cs.caltech.edu (Andy Fyfe) To: comp.sys.3b1,comp.protocols.tcp-ip Subject: Re: Printing out 'ipctut' from osu archive
In article <1991Aug20.033536.19016@ceilidh.beartrack.com> dnichols@ceilidh.beartrack.com (Don Nichols (DoN.)) writes: >>>In article <260@zebra.UUCP> vern@zebra.UUCP (Vernon C. Hoxie) writes: >>>> >>>->I recently downloaded a file from the AT&T-7300/3B1 archive at osu-cis >>>->which is called 'ipctut'. It is a tutorial originally issued by the >>>->Regents of the University of California. It contains no programming >>>->code but does have a Makefile to be used in printing out the document. > groff compiles and runs on the 3b1, and includes the '-me' macro >package. It is available on osu-cis (I am assured.) "groff -Txxx -t -me tutor.me" (where xxx is ascii, dvi or ps) works fine. Groff binaries for the 3b1 are available for anonymous ftp on csvax.cs.caltech.edu:/pub/3b1/. If they aren't yet on OSU, I'll copy the file to the Temp directory there. Andy Fyfe andy@cs.caltech.edu
-----------[000246][next][prev][last][first]---------------------------------------------------- Date: 23 Aug 91 03:52:21 GMT From: mrc@Tomobiki-Cho.uucp (Mark Crispin) To: comp.protocols.tcp-ip Subject: Re: SLIP and data compress/correction
In article <2026@nimbus.UUCP> rpcfod@nimbus@UUNET.UU.NET (Robert Patt-Corner) writes:
>We're having some problems getting slip links to work on a v.32bis/v.42bis
>modem pair using anything other than data compression and correction turned
>off. Is there any inherent thing in the SLIP protocol that prevents this?
I use SLIP on a V.32/V.42bis modem pair with no problems. I get about
20KB with FTP. I doubt there is anything with V.32bis that would
change this; I hope not since I'm upgrading to V.32bis very soon!
>Result with compression or correction is checksum errors on sender and/or
>receiver.
One thing to check is to make sure you have flow control set up
properly. I'll be willing to bet this is your problem. You should
*not* be using software flow control (XON/XOFF) in any form. Most
computers can not handle a steady stream of 38,400 baud data on their
serial port without some flow control, so you need to have hardware
flow control (CTS/RTS) set up.
For more information, check the manuals for your modem and for your
serial port.
-+-+- | -++- --|-- /__ Mark ("Gaijin") Crispin "Gaijin! Gaijin!"
+-|-|-+ -+-++++ +-|-+ / / R90/6 pilot; DoD #0105 "Chigau. Omae ha gaijin."
+-+-+-+ |\|||| |===| / / Atheist & Proud "Iie, boku ha nihonjin."
--|-- /| |/\| -+===+- /\ (206) 842-2385/543-5762 "Souka. Yappai gaijin!"
/|\ | |__| / \ / \ FAX: (206) 543-3909
Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo.
-----------[000247][next][prev][last][first]---------------------------------------------------- Date: 23 Aug 91 07:18:46 GMT From: gagrawal@sparc18.cs.tamu.edu (Gopal Agrawal) To: comp.protocols.misc,comp.protocols.tcp-ip Subject: A clarification needed on FDDI's Protocol.
--
Hi everybody.
I had certain doubts on FDDI's protocol. I couldn't decipher any
answers to these from the papers of Marjory Johnson, McCool,
F. Ross etc. Could some one help me out ?
Q1) A station on receiving a token early transmits synchronous
and then asynchronous messages for THT time - right ? Suppose
Initially there are no synchronous messages and the station goes
ahead to transmit its Asynchronous messages. Synchronous messages
come at some time during the transmission of the asynchronous
messages. Now will the transmission of Asynchronous messages be
prempted by the higher priority synchronous messages ? Or is it
that the synchronous messages will not be transmitted.
Q2) A node recives a token LATE. It wishes to send synchronous
messages for its allocated bandwidth 'B'. But the amount of time
left before the TRT expires (lets call it 'A') is less than B.
So does the node transmit synchronous messages for time A or B ?
Please e-mail / reply rather than posting answer.
Thanks in advance,
--------------------------------------------------------------------------------
______ _
/ ____/ ___ ____ ___ | | |\/\/\/| Life is complex.
| | __/ _ \| _ \/ _ \ | | | | It has both
| |_| ||(_)||(_)||(_)|_| | | \ /| real
_____ \_____/\___/| _/\____/|_| _ | (o)(o) and
/ _ \ ___ ___ __| | _ _ ___ | | C _) imaginary
| (_) |/ _ \/ __\/ _ \|| | | |/ _ \ | | | \___| parts.
| ___ ||(_)|| | |(_)|_| |/\| ||(_)|_| | | /
|_| |_|\__ ||_| \____/\__/\__/\____/|_| /____\
__| | / \
\___/ E-MAIL : gagrawal@cs.tamu.edu All Std. disclaimers apply.
--------------------------------------------------------------------------------
-----------[000248][next][prev][last][first]---------------------------------------------------- Date: 23 Aug 91 10:18:45 GMT From: REDREC@UNAMVM1.BITNET (Cristina Casimiro) To: comp.protocols.tcp-ip Subject: Re: NFS and UID mapping
Peter : It exists in CRAY machines . In UNICOS 6.0 there is an ID mapping that can help you for solve your problem . It is part of the UNICOS NFS and permits the use of NFS in several administratives environments . There are two types of ID maps : user ID maps and group ID maps . Also I think there is a similar facility in Sun Microsystems Network It maybe help you . Cristina Casimiro redrec@unamvm1.dgsca.unam.mx
-----------[000249][next][prev][last][first]---------------------------------------------------- Date: 23 Aug 91 15:09:26 GMT From: mcneill@eplrx7.uucp (Keith McNeill) To: comp.protocols.tcp-ip Subject: routing problem from hell
I have a routing problem.
The site on which I work has a large bridged ethernet with many hosts on it.
A class B address has been assigned to the site (call it XXX.YYY.0.0). The
network owners have assigned each building a subnet number. Hosts that sit
on the large bridged ethernet do no use subnetting (i.e. subnet mask
255.255.0.0).
My network is a separate ethernet. My network was assigned subnet 252 within
the XXX.YYY.0.0 network. All hosts on my ethernet, including both interfaces
on the router, use a subnet mask of 255.255.255.0. My router is a Sun
Workstation running proxy arp. Proxy arp is used to enable communication
between the subnetted (my network) and non-subnetted (everybody else)
portion of the XXX.YYY.0.0 network.
Communications within the XXX.YYY.0.0 network work perfectly. The problem
occurs when another network is added, a class C, (call it AAA.BBB.CCC.0).
My router cannot add a route to the new AAA.BBB.CCC.0.
confused...how about a map...
Topology map:
My Network
XXX.YYY.252.0
--------------------------------
|
| IP addr: XXX.YYY.252.10
|
| Sun Workstation/router running proxyarpd
|
| IP addr: XXX.YYY.78.1
| hundreds of nodes....
-----------------------------------------------------------------
Large bridged ethernet |
XXX.YYY.0.0 | IP Addr: XXX.YYY.10.1
|
| IP Router to AAA.BBB.CCC.0 network
|
| IP Addr: AAA.BBB.CCC.3
|
--------------------------------------------
AAA.BBB.CCC.0 network
On my router I have added a default route pointing to the 78 subnet interface.
netstat -r on my router:
Routing tables
Destination Gateway Flags Refcnt Use Interface
127.0.0.1 127.0.0.1 UH 3 19989 lo0
default XXX.YYY.78.1 U 5 2295226 ie3
XXX.YYY.252.0 XXX.YYY.252.10 U 78 1681671 ie0
XXX.YYY.78.0 XXX.YYY.78.1 U 0 4851 ie3
ifconfig -a on my router:
ie0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
inet XXX.YYY.252.10 netmask ffffff00 broadcast XXX.YYY.252.255
ie3: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
inet XXX.YYY.78.1 netmask ffffff00 broadcast XXX.YYY.78.255
lo0: flags=49<UP,LOOPBACK,RUNNING>
inet 127.0.0.1 netmask ff000000
The root of the problem is that my router sits on subnet 78 and the router
to the AAA.BBB.CCC.0 network sits on subnet 10. When I try to add a route
on my router, this is what happens:
sun-router>> route add net AAA.BBB.CCC.0 XXX.YYY.10.1 1 add net
AAA.BBB.CCC.0: gateway XXX.YYY.10.1: Network is unreachable
My router is confused because subnet 78 & 10 (and many others) are on the
same physical wire. Now my router can ping/telnet/ftp to XXX.YYY.10.1. My
router just won't let me add a route through it to AAA.BBB.CCC.0.
Non subnetted machines sitting on the bridged ethernet have no problem
communicating with the AAA.BBB.CCC.0 network.
This leads to 2 questions:
1) Is my router (i.e. the Sun IP code) acting correctly.
2) One way to solve this would be to change the subnet mask on the 78
side of my router to 255.255.0.0. Can the Sun IP code deal with a
machine with 2 different subnet masks for the same class B network.
I've asked both of these questions with sun support and have yet to receive
an answer.
Any help is greatly appreciated....
Keith
--
Keith McNeill | Du Pont Company
eplrx7!mcneill@uunet.uu.net | Engineering Physics Laboratory
(302) 695-9353/7395 | P.O. Box 80357
| Wilmington, Delaware 19880-0357
--
The UUCP Mailer
-----------[000250][next][prev][last][first]---------------------------------------------------- Date: 23 Aug 91 15:37:39 GMT From: pv0618@hertz.njit.edu (Paranjothi Varadarajan) To: comp.protocols.tcp-ip Subject: tn3270 bugs ...
Posting for a friend who do not have access to net. I am working on tn3270 (4.1.1) on an hp-ux and having a problem, which to me looks like a bug in telnet code used to build tn3270. I would be more than happy to give details . Also if any body out there knows of bugs in tn3270 code , please let me know... thanks ! you can reply here/ post on the net or call Kamlesh Shah at (919) 481 7877. Thanks !
-----------[000251][next][prev][last][first]---------------------------------------------------- Date: 23 Aug 91 17:16:24 GMT From: jmb@ideas.com (Jonathan M. Bresler) To: comp.protocols.tcp-ip Subject: IPI3 (a protocol ?)
I'm looking for information and references to further details on "IPI3". Please respond by direct email. I will summarize if requested. If someone knows of a better mail group for posting this note, please tell me. Jon Bresler jmb@ideas.com
-----------[000252][next][prev][last][first]---------------------------------------------------- Date: 23 Aug 91 19:13:55 GMT From: peter@plato.austin.ibm.com (Peter Jeffe 512.838.4019) To: comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip Subject: .netrc, .rhosts, and FQDNs
I'm sure this has already been discussed, but obviously not
resolved. It seems there has always been an inconsistency in the
way that hostnames are treated in the .rhosts, hosts.equiv, and
.netrc files, and depending on the application.
This is how it stands in BSD reno:
A. compares using hostname as supplied by user/application
B. compares using hostname from gethostbyname() of supplied host
C. adds local domain to non-FQDN hostname from file
D. does case-insensitive compare
A B C D
----------
ruserok (.rhosts, hosts.equiv) Y N Y Y
rexec (.netrc, env) N Y N N
ftp (.netrc) Y Y Y Y
There may be other cases, but these are the ones I'm aware of.
I propose that:
1. All of these mechanisms should act the same; even though
.netrc is outgoing and the others are incoming, I can't see
any reason to deal with them differently.
2. They should obviously do case-insensitive comparisons, as per
rfc 952.
3. They should do a gethostbyname() on BOTH the supplied hostname
and the one from the file; this will canonicalize it if using
DNS and gather aliases if using a hosts file.
4. They should compare the h_name of one with the h_name and
h_aliases of the other.
I think this should satisfy everything, but there are probably
issues that I'm not seeing. Any comments?
--
peter jeffe ...cs.utexas.edu!ibmchs!ski.austin.ibm.com!peter
-----------[000253][next][prev][last][first]---------------------------------------------------- Date: 23 Aug 91 20:17:38 GMT From: ben@moncol.UUCP (Bennett L. Broder) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: What is the name of the packet driver for the NE2000
I know this is probably a simple question, but I am new to Novell hardware and software. I am trying to bring up NCSA telnet (a public domain tcp/ip program for the pc) on some machines currently running Novell netware. The machines have Novell NE2000 LAN cards, which according to the documentation supplied with NCSA telnet, are supported via the packet driver. What is the name of the packet driver for the NE2000, and on what Novell disk would I find it? Thank you for any help you can render. Ben Broder uucp ..princeton!moncol!ben inet moncol!ben@princeton.edu -- Bennett Broder Monmouth College ..princeton!moncol!ben Computer Services ..tsdiag!moncol!ben W. Long Branch, NJ 07764
-----------[000254][next][prev][last][first]---------------------------------------------------- Date: 23 Aug 91 21:29:45 GMT From: richb@kronos.com (Rich Braun) To: comp.mail.sendmail,comp.mail.uucp,news.admin,comp.protocols.tcp-ip Subject: Domain registration for e-mail?
I've been running in circles with NIC trying to figure out how to register my system as an MX record on the network, so here I am turning to USENET to figure this one out (sorry for the posting to probably-inappropriate groups). In order to prevent the usual problems associated with bang-style addressing, I want Internet e-mail users to address people at my company as user@kronos.com instead of kronos!user@eclectic.com or any of about thirteen variants. I have an AIX system connected to two Internet systems via frequently-polled UUCP. NIC tells me they don't handle MX records and refers me to my local administrator. The administrator of my Internet gateway system doesn't know the process for doing this. It makes NO logical sense to me that NIC shouldn't be the entity to assign non-Internet domains. To whom do I go to get an MX record registered in all Internet domain name servers? I want a top-level domain in the "com" namespace. We do not buy service from one of the big companies with experience in this area (like UUNET). Thanks, -rich
-----------[000255][next][prev][last][first]----------------------------------------------------
Date: 24 Aug 91 01:20:50 GMT
From: schoff@mail.psi.net ("Martin Schoffstall")
To: comp.protocols.tcp-ip
Subject: (none)There is a mailing list to discuss the NREN which is available at nren-discuss@uu.psi.com To be added the Internet standard of sending a request to nren-discuss-request@uu.psi.com Marty >DATE: Wed, 14 Aug 91 10:38:24 -0400 >FROM: Chi Chu <chi@sparta.com> > >Subject: NREN > >Hey folks, > Can someone tell me what the NREN email address is? >Thanks. > >Chi - SAIC >
-----------[000256][next][prev][last][first]---------------------------------------------------- Date: 24 Aug 91 10:21:08 GMT From: asbjorns@stud.cs.uit.no To: comp.protocols.tcp-ip Subject: TCP/IP versus LAT
I believe that some time ago there was a discussion in this group on whether TCP/IP was a good choice for handling terminals, in particular compared to LAT. If someone has kept a summary of this thread, could you please mail it to me? Or, failing that, could someone please summarize the conclusions of the discussion. asbjorns@stud.cs.uit.no (Asbjoern Saetran).
-----------[000257][next][prev][last][first]---------------------------------------------------- Date: 24 Aug 91 14:01:54 GMT From: nelson@sun.soe.clarkson.edu (Russ Nelson) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: What is the name of the packet driver for the NE2000
In article <6220@moncol.UUCP> ben@moncol.UUCP (Bennett L. Broder) writes: The machines have Novell NE2000 LAN cards, which according to the documentation supplied with NCSA telnet, are supported via the packet driver. What is the name of the packet driver for the NE2000, and on what Novell disk would I find it? I'm quite sure that Novell doesn't distribute any packet drivers. Here's how to get the Clarkson collection of packet drivers: The Clarkson packet driver collection Availability The Clarkson collection of packet drivers is available by FTP, by archive-server, and by modem. They come in two flavors -- executables only (drivers.zip), and source+executables (driverss.zip). All of the following instructions apply to both drivers.zip and driverss.zip. Mail: I distribute the packet drivers on two 360K 5.25" disks, or a 720K 3.5" disk. I charge a fee for the service of copying and mailing these disks. You can send me a check for $20, or you can send me a purchse order and I will bill you for $22. NY residents add 7% sales tax, overseas orders add $3 for shipping. If you send a check, please be sure it is in US dollars -- the bank charges me $15 to convert checks drawn in foreign currencies. Russell Nelson 11 Grant St. Potsdam, NY 13676 FTP: sun.soe.clarkson.edu:/pub/ka9q/drivers.zip grape.ecs.clarkson.edu:/pub/msdos/tcpip/drivers.zip E-mail: Send mail to archive-server@sun.soe.clarkson.edu and put the following command as the body of your message: help This will send you a help message. Reading this help message will tell you how to fetch the packet drivers. Modem: Call the Clarkson Heath User's Group's BBS: (315)268-6667, 8N1, 1200/2400 Baud, 24 hours. You may need to press break, or simulate it using several nulls. Download pub/msdos/tcpip/drivers.zip. -- --russ <nelson@clutx.clarkson.edu> I'm proud to be a humble Quaker.
-----------[000258][next][prev][last][first]---------------------------------------------------- Date: 24 Aug 91 14:26:43 GMT From: ken@achilles.coral.com (Ken Benstead) To: comp.protocols.tcp-ip Subject: Decnet IV Implementation
Hello World,
I known this is probably not the "right place" to ask this question
but I'm not sure where "right place" would be, so here goes anyway. Does
anyone know of a Decnet IV router implementation suitable for porting
(ie includes source code)? A public domain implementation would be
nice but any information (including commercial packages) would be much
appreciated. Please E-Mail reponses directly to me.
Thanks in anticipation,
Ken Benstead
kbenstead@coral.com
PS: I have heard a rumor that the University of Texas has an implementation.
Is there any truth to this?
-----------[000259][next][prev][last][first]---------------------------------------------------- Date: 24 Aug 91 15:00:18 GMT From: jcurran@NNSC.NSF.NET (John Curran) To: comp.protocols.tcp-ip Subject: Re: NREN (looking for email address)
] Hey folks,
] Can someone tell me what the NREN email address is?
] Thanks.
The NREN hasn't evolved far enough to accept mail "in general".
The organizations participating in the planning activites are well
represented on this list (tcp-ip), and also on the com-priv mailing
list. There are also several study groups organized by the NSF to
look at particular issues in the NREN architecture.
Until the NREN is fully realized, you might want to send mail to the
information services groups of the current NSFNET (which serves as
the Interim NREN). The contacts are:
NSF Network Service Center (NNSC)
nnsc@nnsc.nsf.net
Merit Information Services
nsfnet-info@merit.edu
They will be able to answer or refer you to the correct people depending
on the question.
/John
-----------[000260][next][prev][last][first]---------------------------------------------------- Date: 24 Aug 91 17:27:07 GMT From: faunt@CISCO.COM (Doug Faunt N6TQS 415-688-8269) To: comp.protocols.tcp-ip Subject: Finger server as a requirement for all Internet hosts
My feeling is that "finger" is an invasion of privacy. Why should anyone on the internet be able to look and see what my habits are? There's a fair amount of obfucation in some finger services these days, but they still give away more information then I'm happy with. What would make me feel much more comfortable with finger was a finger server that defaulted to no information (even their existence), but would allow the user to control what information was given about them. Is there such readily and easily available? thanx, doug
-----------[000261][next][prev][last][first]---------------------------------------------------- Date: 24 Aug 91 18:16:31 GMT From: dboyes@is.rice.edu (David E Boyes) To: comp.protocols.tcp-ip Subject: Re: Finger server as a requirement for all Internet hosts
In article <9108150145.AA03269@gaak.LCS.MIT.EDU> MAP@LCS.MIT.EDU (Michael A. Patton) writes: > >What I do in this case is send mail to Postmaster at that site and ask >them. I usually include something along the lines, "Because your site >doesn't run a finger server, I am required to waste your time and mine >by sending this request for an address to you. You should consider >running such a server to cut down on the amount of time you spend >answering such queries." You assume 2 things: 1) all hosts connected to the Internet are capble of supporting a "finger" service and can store the necessary information to respond to such queries with impunity, and 2) user identification information is considered publically available information. Neither assumption is universally valid, and while it's annoying to have to trouble a human to do the lookups, it's better to have a fully reliable service than one that cannot be authoritative. > Michael A. Patton, Network Manager > MIT Laboratory for Computer Science >P.S. On the other hand, even though MIT does run such a service, it's >amazing how many people don't think to try and just send to Postmaster >anyway. At least having the service makes it easy for me to reply. Sending mail to postmaster@<site> is supposed to be guaranteed to reach a knowledgeable human responsible for the mail system, according to custom and RFC. It amazes me how many sites use postmaster@site as the mail-daemon, or cause it to be a black hole for problem reports. -- David Boyes dboyes@rice.edu |There is nothing true but silence and darkness.
-----------[000262][next][prev][last][first]---------------------------------------------------- Date: 25 Aug 91 00:14:36 GMT From: dalton@pine.circa.ufl.edu (DALTON) To: comp.protocols.tcp-ip Subject: NFS vendors, addresses or phones
Does anyone know the phone number or address for info about PC/TCP Interdrive, ftp Software, Inc. or Beame & Whitside's, B&W NFS? Thanks, Ron Dalton
-----------[000263][next][prev][last][first]---------------------------------------------------- Date: 25 Aug 91 02:30:34 GMT From: jholmes@mcb.UUCP (jim holmes) To: comp.mail.sendmail,comp.mail.uucp,news.admin,comp.protocols.tcp-ip Subject: Re: Domain registration for e-mail?
richb@kronos.com (Rich Braun) writes: > To whom do I go to get an MX record registered in all Internet domain > name servers? I want a top-level domain in the "com" namespace. We > do not buy service from one of the big companies with experience in > this area (like UUNET). > > Thanks, > -rich uunet will do it for you anyway for $35. write to uunet!info -jlh **** Standard junk**** I don't work for uunet i'm just a customer.
-----------[000264][next][prev][last][first]---------------------------------------------------- Date: 25 Aug 91 04:35:33 GMT From: clewis@ferret.ocunix.on.ca (Chris Lewis) To: comp.sys.3b1,comp.protocols.tcp-ip Subject: Re: Printing out 'ipctut' from osu archive
Someone mentioned a problem printing ipctut using the -me macros
with psroff, when (I believe) the -me macros were borrowed
from another machine. Please note that some C/A/T troffs has a slight
incompatibility with other troffs regarding the format of .if's and
associated \{\'s and this problem often hits when using a ditroff version
of -me with C/A/T troff. This is noted in the psroff TROUBLE file, and
can be fixed by modifying the -me macros according to the instructions.
It's a fairly simple fix (text from the TROUBLE file):
ME macros don't seem to work:
A friend noted:
In order to make them useable, I had to modify them somewhat. The
problem was with the following syntax:
.if t \
\{
. zz
.\}
Our (Xenix) troff required the following instead:
.if t \{\
. zz
.\}
This was required for all occurances of "\{". It seems "\{" MUST
terminate a line, and MUST be followed by a "\<NEWLINE>". Even a ".\{"
didn't help any.
This can be done with an ed, sed or perl script, but I don't
think there's that many to change.
--
Chris Lewis; UUCP: ...!{cunews,uunet,latour}!ecicrl!clewis;
DOMAIN: clewis@ferret.ocunix.on.ca; Phone: Canada 613 832-0541
Psroff info: psroff-request@ferret.ocunix.on.ca
Ferret mailing list: ferret-request@ferret.ocunix.on.ca
-----------[000265][next][prev][last][first]---------------------------------------------------- Date: 25 Aug 91 05:33:06 GMT From: dyer@spdcc.COM (Steve Dyer) To: comp.mail.sendmail,comp.mail.uucp,news.admin,comp.protocols.tcp-ip Subject: Re: Domain registration for e-mail?
In article <1991Aug23.212945.16789@kronos.com> richb%kronos.uucp@eclectic.com writes:
>It makes NO logical sense to me that
>NIC shouldn't be the entity to assign non-Internet domains.
The NIC will maintain name server records representing hosts which will
be authoritative for the kronos.com domain. It's up to these hosts which
act as nameservers for kronos.com to contain whatever RR data is appropriate;
in your case, MX records. Presumably, you will have negotiated this
function in advance with the administrators of the hosts acting as name
servers.
>To whom do I go to get an MX record registered in all Internet domain
>name servers? I want a top-level domain in the "com" namespace. We
>do not buy service from one of the big companies with experience in
>this area (like UUNET).
UUNET will gladly do all this for you for a small fee (< $50, I think)
and act as your nameserver if you like, and you don't even have to be
one of their UUCP customers.
Since spdcc.com is one of your two UUCP sites connected to the Internet,
and since I'd mentioned to you that I was already providing this exact
service to several other UUCP sites, I really don't know why you didn't
approach me with your questions before going ballistic and assuming that
the NIC was stonewalling you or somehow failing you. What they said was
absolutely correct.
--
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
"Proletarii vcex stran, izvinite!" -- Anon.
-----------[000266][next][prev][last][first]---------------------------------------------------- Date: 25 Aug 91 15:46:23 GMT From: rwskubow@GRAND.WATERLOO.EDU (Rog Skubowius) To: comp.protocols.tcp-ip Subject: Removal from list
Please remove me from this distribution list. Thankyou, Roger Skubowius
-----------[000267][next][prev][last][first]---------------------------------------------------- Date: 25 Aug 91 19:06:13 GMT From: VANCE@TGV.COM (L. Stuart Vance) To: comp.protocols.tcp-ip Subject: Re: connection between mac and vax
>I tried to connect to VAX by using NCSA Telnet 2.3 MacTCP. "Sometimes" the >cursor freezed during the connection and then, after a while, VAX kicked me >out automatically. "Sometimes" my mac crushed right after above situation. >(screen freezed and no error massage) But everytinging works well when I >tried to connect to a unix machine. I also tried to use NCSA Telnet 2.4 and >it didn't help. I have no idea how to fix the problem. It looks like >something wrong with the VAX. > >I am running 6.0.7 on SE/30 with Dove FastNet SE/30. Does anyone have similar >experiences? I'd appreciate any suggestions. Thanks in advance. It might be a TELNET option negotiation problem between NCSA Telnet and the VAX. Does NCSA Telnet give you the ability to display TELNET options as they are negotiated with the server system? If so, that'll tell you at least if it is an option problem. Probably the best thing to do would be to get an Ethernet protocol analyzer (or even a Sun with etherfind or a system with TCPDUMP) and monitor the dialog between the Mac and the VAX. Also, whose IP software on the VAX are you running? Have you tried contacting the vendor directly to see if they know of any problems communicating with NCSA Telnet? Regards, -----Stuart
-----------[000268][next][prev][last][first]---------------------------------------------------- Date: 26 Aug 91 15:08:15 GMT From: prakash@beast.sme.siemens.com (Veera Prakash) To: comp.protocols.tcp-ip Subject: Removal
Please remove me from this mailing list.
-----------[000269][next][prev][last][first]---------------------------------------------------- Date: 26 Aug 91 15:50:47 GMT From: gmckee@cpqhou.uucp (George McKee) To: comp.protocols.tcp-ip,biz.sco.general Subject: SCO vs RFC1122 TCP urgent pointer
First the big question: how do you get a vendor to follow the standard rather than some broken product(s), when the broken stuff works for their other customers? Here's the story: Sybase's client-server system provides a dbcancel function to stop the execution of a database query that you change your mind about (in case you said "select * from everything" and you don't have all day). They implement it using TCP urgent data; but RFC1122 fixed an off-by-one error in the definition of the urgent pointer in RFC793. This means that an implementation of TCP according to the new spec won't interoperate with an implementation that follows the old RFC if they use urgent data. In fact, the connection will generally hang irrecoverably. This is ungood for production work. At Compaq, we have an environment that induces us to use for our database clients FTP software's PC/TCP, which precisely follows RFC1122. But we also have a relation with SCO that leads us to use their dialect of Unix on our servers, and their TCP/IP implementation is "mostly compliant" to 1122, where "mostly" excludes TCP urgent data. As a consequence, we can't use any software that utilizes this feature of the protocol. SCO claims that they do this because "everybody else's" implementation also follows the broken part of RFC793 (namely ATT SysVr4, SunOS, Sun PC/NFS, ISC 386/ix, etc.). They also say they don't intend to fix the problem until about 3 versions from now, say in 1994. Several questions are now in the air: - are we going to be stuck on this for 3 years? - is this off-by-one problem really so difficult that it takes 3 years to fix? - what implementations of Unix do TCP urgent data the right way? - are there any implementations on any platform that can do it both ways? - George George McKee gmckee@cpqhou.se.hou.compaq.com Systems Programmer uunet!cpqhou!gmckee Information Management Voice: 713 378 7991 Compaq Computer Corporation Fax: 713 374 1740 P.O. Box 692000 M010301 disclaimer: facts are facts, Houston, TX 77269-2000 Compaq is Compaq, my opinions are mine. ...and a fine how-de-do to anyone who can derive this from quantum mechanics.
-----------[000270][next][prev][last][first]---------------------------------------------------- Date: 26 Aug 91 17:55:42 GMT From: marcus@cpva.saic.com (Mark Jenkins, SAIC/CIR Network Services) To: comp.protocols.tcp-ip Subject: Sun gateway proxy ARP software?
I have some people on the network who would like to use Sun workstations as routers, using two Ethernet interfaces with one on one network, and one on another network. The networks that will be behind these Sun workstations are small, much smaller than our subnet mask's network size. I would like them to just use a portion of a subnet instead of assigning a whole subnet. In order to accomplish this, the Sun workstation has to respond to ARP requests for all of the nodes it is routing for. This is generally called proxy ARP. I have also been told that there is software available for the Sun which allows it to act as a gateway doing proxy ARP in this manner. Can anyone give me a pointer to this software or another way of setting this up? Thanks in advance - Mark -- Mark Jenkins <Marcus@CPVA.SAIC.Com>| My views do not necessarily match yours. Science Applications | I've never met an iguana I didn't like. International Corporation | But that goes without saying. San Diego, CA USA (619) 458-2794| -------- This space for rent ----------
-----------[000271][next][prev][last][first]---------------------------------------------------- Date: 26 Aug 91 18:07:47 GMT From: fab@MD.INTERLINK.COM (Fred Bohle) To: comp.protocols.tcp-ip Subject: Re: TCP FIN and window
>From: rosevax!atc!hawkmoon!nightowl!s5000!kurt@uunet.uu.net (Kurt Matthys x5693) >Organization: Unisys - Roseville, MN >Subject: TCP FIN and window >Message-Id: <240@s5000.rsvl.unisys.com> >I have recently run into a TCP question that I would like some input on. It >concerns whether a TCP can send a FIN when the window is closed. I have seen >at least two implementations that do this, but RFC 793 would appear to say >that it should not be done. The following is my interpretation of the issue: >On page 25 of RFC 793 it states that the segment length is "the number of >octets occupied by the data in the segment (including SYN and FIN)". >On page 69 the table shows that if the segment length > 0 and the received >window = 0, the received segment is not acceptable. A couple of lines later >it says that "If the RCV.WND is zero, no segments will be acceptable, but >special allowance should be made to accept valid ACKs, URGs and RSTs". >Then it states that "if an incoming segment is unacceptable, an acknowledgment >should be sent in reply ... After sending the acknowledgment, drop the >unacceptable segment and return". >On page 70 it talks about trimming an incoming segment so that it is >completely inside the window by "trimming off any portions that lie outside >the window (including SYN and FIN)". >From the above the FIN is included in the segment length and a TCP that >receives a FIN when the window is closed should discard it (at least this is >how I interpret it). Any comments? >Kurt Matthys >Unisys Corp. >Roseville MN >kurt@s5000.rsvl.unisys.com This raises an interesting question. Our implementation (SNS/TCPaccess) on MVS established all its FTP data connections with a zero receive window when sending. No data was expected in the reverse direction, so this seemed reasonable. It worked fine for years, with many other implementations. Then a XEROX user complained that the data connections hung. Their code would not send the FIN into a zero window. The workaround was to artificially set the window to 1 in our FIN packet. Then the connection closed OK. This seems to be a method of informally testing other implementations to see how they handle sending a FIN into a zero window. Since the code worked for years with many other implementations, it would seem the consensus is that it is acceptable to send a FIN into a zero window. But I agree, the RFC's do not spell out if it is 'required' to be able to do so. Any comments? Fred ------------------------------------------------------------------------ Fred Bohle EMAIL: fab@leo.md.interlink.com Interlink Computer Sciences AT&T : 301-317-6600 9145 Guilford Road, Suite 175 Columbia, MD 21046 ------------------------------------------------------------------------
-----------[000272][next][prev][last][first]---------------------------------------------------- Date: 26 Aug 91 18:24:33 GMT From: jbvb@FTP.COM (James B. Van Bokkelen) To: comp.protocols.tcp-ip Subject: Re: telnet and AS400/NCSA/CUTCP/Packetdrivers/AT&T etc
has anyone heard of a tn5250 for unix and/or PC's ?
OpenConnect Systems of Carrolton TX (formerly Mitek) has a DOS TN5250
which uses our PC/TCP kernel as the transport layer. I've heard it said
that IBM offers TN5250 clients for various systems, but I don't think
they have one for either DOS or SysV.
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000273][next][prev][last][first]---------------------------------------------------- Date: 26 Aug 91 18:42:07 GMT From: bob@MorningStar.Com (Bob Sutterfield) To: comp.text.tex,comp.protocols.tcp-ip Subject: rfc.bib?
Has anyone made a bibliography database, digestible by BibTeX or
Scribe, of the Internet ``Requests for Comments'' series? I'd like to
just say \cite{rfc1149} and have all the Right Things happen.
-----------[000274][next][prev][last][first]---------------------------------------------------- Date: 26 Aug 91 19:08:35 GMT From: beame@maccs.dcss.mcmaster.ca (Carl Beame) To: comp.protocols.tcp-ip Subject: Re: Beame and Whiteside PC-NFS
In article <7131@mindlink.bc.ca> Mark_McFadyen@mindlink.bc.ca (Mark McFadyen) writes: >Does anyone have any experience with setting up B&W PC-NFS? >We have the NFS drive working fine, but we cannot seem to be able >to link a local device (ie LPT3) to a remote printer. The command >we are using (trying to use) is: > > NET LINK LPT3 \hostname\HPJET >where HPJET is defined in the /dev/printcap file. >This gives us a "Invalid remote device." error message and >refuses to link. > >Does anyone have any suggestions? >Or is my PRINTCAP file setup wrong? What is the format? >Thanks. >-- The line in your file /etc/printcap not /dev/printcap should read HPJET|laser printer:\ ... Note that the case is important and that BWNFSD must be restarted after adding this line to the /etc/printcap file. - Carl Beame
-----------[000275][next][prev][last][first]---------------------------------------------------- Date: 27 Aug 91 02:00:30 GMT From: raj@hpindwa.cup.hp.com (Rick Jones) To: comp.protocols.tcp-ip Subject: Is this IP address "local?"
Has anyone put together a routine that will take as input an IP address, and return a simple true/false answer to the question "Is this IP address on a Directly Connected network?" for "BSD" networking implementations? I can do the summary thing if folks like... rick jones raj@cup.hp.com
-----------[000276][next][prev][last][first]---------------------------------------------------- Date: 27 Aug 91 06:54:30 GMT From: craig@SICS.SE (Craig Partridge) To: comp.protocols.tcp-ip Subject: TCP/IP on OS/2
Hi folks:
Query for a friend. I'm looking for TCP/IP products for PCs running
OS/2. I dunno if this matters, but the PCs are currently connected via
Ethernet (Thin Wire) and use LAN Manager (which I understand they'd like
to continue to be able to use in parallel with TCP/IP, if possible).
I'd be interested in any products one can recommend.
Thanks!
Craig Partridge
craig@sics.se
-----------[000277][next][prev][last][first]---------------------------------------------------- Date: 27 Aug 91 14:51:09 GMT From: jfjr@mbunix.mitre.org (Freedman) To: comp.protocols.tcp-ip Subject: KEEPALIVE
This may not be the appropriate place for this since it may be
really a BSD socket issue - if so I apologize.
The KEEPALIVE option seems to me to be vaguely funky (kludgy).
What are your views on it. Does it really do what it is supposed to
do? If not why? What would you use in its place?
Jerry Freedman,Jr
-----------[000278][next][prev][last][first]---------------------------------------------------- Date: 27 Aug 91 16:07:55 GMT From: jona@ils.nwu.edu (Kemi Jona) To: comp.os.msdos.programmer,bit.listserv.ibm-nets,bit.listserv.ibmtcp-l,comp.lang.smalltalk,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.windows.ms.programmer Subject: Help UNIX-IBM PS/2 TCP communications
I am trying to develop a system that will allow a UNIX box (IBM RS/6000) to communicate via TCP to PS/2's. Since I'd like to graduate sometime this decade, I'd prefer not to have to write the low-level networking code on either end (esepecially the PS/2 end). I would appreciate any source code or tips that will help me accomplish this. Misc. notes: The PS/2's will be running Smalltalk, so a Smalltalk interface to TCP would be great, but making foreign-function calls from smalltalk to C would be OK too. Thanks in advance for any pointers, --Kemi Jona (jona@ils.nwu.edu)
-----------[000279][next][prev][last][first]---------------------------------------------------- Date: 27 Aug 91 16:15:26 GMT From: cudcv@warwick.ac.uk (Rob McMahon) To: comp.protocols.nfs,comp.protocols.tcp-ip Subject: PC-NFS FTP TTL / NIS
Configuration: PC-NFS 3.5 / Dell 316SX / RM Ethernet 16 / MPS Driver 2.00c A couple of problems, easy (?) one first. When using FTP, conections to some sites fail (`ftp: connect: Unknown error'). A tcpdump makes it look suspiciously like the TTL is expiring. The TTL starts at only 15, is there any way to increase this ? The more tricky one is this: We run RARP and NIS. When the file \nfs\hosts doesn't contain any entries, we get: C:\>NET START RDR NFS029F : Unable to obtain the name of the NIS server. net: Unable to get hostname by ip addr (137.205.192.202) Putting the PCs own address in the hosts file seems to cure this second message, and seems to be completely necessary to get it to work at all, but why can't it find the NIS server ? I can use a NET NISSET to set the NIS server to a host, which must also be in the hosts table, and then PC-NFS starts working okay, although we still get that first message from `NET START RDR'. Any clues ? I'd rather not wire these things in. Rob -- UUCP: ...!mcsun!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick INET: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England
-----------[000280][next][prev][last][first]---------------------------------------------------- Date: 27 Aug 91 16:41:29 GMT From: pv0618@hertz.njit.edu (Paranjothi Varadarajan) To: comp.protocols.tcp-ip Subject: Bug in tn3270 !
Hi Folks !
As the subject says I am using tn3270 ( 4.1.1) to get to an IBM
mainframe machine (running MVS),, and having a prob with it. Here is the
further description of it :
We have a system on IBM MVS where user can get to help screen by using
PF1 and get back to prev screen using PF5. Now, this works fine under
all different screens of the system , except one particular screen,
where once the user goes to help and hits PF5 to backup and the whole
system hangs. ie, it does not recognise any keyboard or any other input.
It doew , however give an error message "Invalid Control sequence" if we
hit certain keys , while it is hung.
BTW , We are running hp-ux 7.05 on the unix side.
The Tn3270 TCP server on the other side is version 1.0.
or rather I should say the Telnet server on the IBM side is v 1.0.
Now, I have the tn3270 code and tried to debug the code to see what may
be wrong. But not much success, however, I did debug the code using xdb
(dbx on some unix) , and the following is the out put of the 'T' stack
with local variables command ....
On one instance :
0 _Host + 0x9a8 (0x1, 0x1, 0, 0x1, 0x1)
1 __v1prot_donext + 0x1aa (0x7, 0x82408, 0x1, 0x2, 0x1)
2 ttyflush (drop = -1069292) [../../telnet/Source/terminal.c: 98]
n = 2
n0 = 27320
n1 = 7
3 __writechars + 0x268 (0x1, 0xffeff7b8, 0x1d640, 0, 0x3)
4 __cleanup + 0xc (0, 0x3, 0x2c, 0x3, 0x33ab4)
5 __writechars + 0x160 (0x2, 0xffeff7cc, 0xffeff7d8, 0xffeff8cc,
0xffeff8d0)
************************************************************************
and on other ...
0 ttyflush (drop = 0) [../../telnet/Source/terminal.c: 83]
n = 80
n0 = 1
n1 = 1
1 EmptyTerminal () [../../telnet/Source/utilities.c: 233]
src = 0x4dae4
count = 80
o = 0
2 FastScreen () [termout.c: 661]
i = 1
columnsleft = 80
i = 0
End = 0
tmp = 0xe4000000
tmpend = 0x5860c
tmpbuf = 0xffeff6dc
newfield = 256889
p = 0x40504
fieldattr = 240
upper = 0x3fd83
3 DoTerminalOutput () [termout.c: 1044]
4 telnet () [../../telnet/Source/telnet.c: 889]
schedValue = 0
5 tn (argc = 2, argv = 0xffeff7cc) [../../telnet/Source/commands.c:
1260]
oerrno = 3564
sp = 0x4d640
sin = 0x20017
host = 0x4dae4
hnamebuf = 0x490d4
6 main (argc = 2, argv = 0xffeff7cc) [../../telnet/Source/main.c:
156]
***************************************************************************
I know it sound CRAZY... but this is really the BEST way I could
figure-out to discuss the problem.
I sure will be willing to give more info, But, DOES THIS SOUND LIKE
SOMETHING KNOWN TO ANY BODY OUT THERE !!
Thanks a bunch folks..
- Kamlesh
-----------[000281][next][prev][last][first]---------------------------------------------------- Date: 27 Aug 91 17:24:02 GMT From: andi@uni-paderborn.de (Andreas Sorgatz) To: comp.protocols.tcp-ip Subject: Change Size of Ethernetpackets ?
Hi, I'm asking this question for someone without an e-mail-address. SITUATION: ---------- andi> netstat -i Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue le0 1500 131.234.104.0 planck 3766490 2083 4501105 371 1532 0 ie1 1500 131.234.2.0 planck-bb 4901944 295 3529696 0 156567 0 lo0 1536 loopback localhost 984816 0 984816 0 0 0 As default, the ethernet-device uses a maximal transfer unit (Mtu) of 1500 Bytes. THE QUESTION: ------------ How can I change this value on a sparc-workstation under SunOS 4.1.1, without generating a new kernel ? They told me, under System 4.1 there was a file (don't know the name) in which the Parameter MTU could be redefined, but under System 4.1.1 there isn't. Can anybody help me ? Please send your answers to: andi@plato.uni-paderborn.de If I get any solutions, I will summarize. Thanks in advance Andreas Sorgatz
-----------[000282][next][prev][last][first]---------------------------------------------------- Date: 27 Aug 91 18:13:10 GMT From: karl@ddsw1.MCS.COM (Karl Denninger) To: comp.protocols.tcp-ip Subject: CISCO phone number?
Does anyone have CISCO's phone number? -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Data Line: [+1 312 248-0900] Anon. arch. (nuucp) 00:00-06:00 C[SD]T Request file: /u/public/sources/DIRECTORY/README for instructions
-----------[000283][next][prev][last][first]---------------------------------------------------- Date: 27 Aug 91 18:21:10 GMT From: spurgeon@ccwf.cc.utexas.edu (Charles Spurgeon) To: comp.protocols.tcp-ip Subject: Network reading list available
A new version of the document "Network Reading List: TCP/IP, UNIX, and
Ethernet" is now available from the Network Information Center at the
University of Texas at Austin. The list may be found on host
ftp.utexas.edu (128.83.185.16). This is version 3.0 of the reading
list, dated August, 1991.
-- What is it? --
The network reading list is an annotated list of books and other
resources focusing on three networking technologies that are in wide
use: TCP/IP, UNIX, and Ethernet. A mix of resources is presented
ranging from introductory information to in-depth technical details.
Version 3.0 of the list has been completely rewritten and updated, and
now includes nearly 70 items. The list is weighted towards resources
that cover the territory well, and that deal with real-world problems
found on growing networks. A copy of the table of contents is
included below.
-- How do I get a copy? --
You can retrieve a copy of the list in either PostScript format or as
a plain ASCII text file. The PostScript format is recommended. The
PostScript file is 34 pages long, and the ASCII text file contains 51
pages.
Copies of the list may be retrieved using anonymous FTP or a
mail-based archive server program.
The hostname for anonymous FTP is ftp.utexas.edu, and the files are in
the pub/netinfo/docs and pub/netinfo/ps directories as net-read.txt
and net-read.ps respectively.
The address of the archive server program is
"archive-server@ftp.utexas.edu". You can retrieve copies of the list
by sending the archive server program a command line in the body of an
electronic mail message. The command line:
send ps net-read.ps
will cause the archive server program to send you a copy of the
PostScript file, while the command line:
send docs net-read.txt
will retrieve the ASCII text file. The command line should be placed in
the body of an mail message sent to archive-server@ftp.utexas.edu.
The archive server is just a simple program, so make sure to send the
command line exactly as shown here.
-- Table of Contents --
Section 1 -- TCP/IP
Introduction To TCP/IP ................................ 1.1
Guides To The TCP/IP Internet ......................... 1.2
Electronic Mail and the Internet ...................... 1.3
TCP/IP Network Administration and Management .......... 1.4
The Request for Comments (RFCs) ....................... 1.5
Some Useful RFCs ......................................1.5.1
Section 2 -- UNIX
UNIX In General ....................................... 2.1
UNIX Networking In Detail ............................. 2.2
Section 3 -- Ethernet
Introduction To LAN Concepts ......................... 3.1
Introduction to Three Ethernet Varieties .............. 3.2
Vendor Guides ......................................... 3.3
Hewlett-Packard Manuals ...............................3.3.1
DEC Manuals ...........................................3.3.2
MOD-TAP ...............................................3.3.3
LAN Troubleshooting ................................... 3.4
Ethernet Standards .................................... 3.5
The DIX Standard ......................................3.5.1
The IEEE 802.3 Standard (ISO 8802.3) .................3.5.2
IEEE Supplements ......................................3.5.3
Twisted-Pair Ethernet Specifications ..................3.5.4
Ethernet Numbers ...................................... 3.6
Ethernet Type Numbers and Addresses ...................3.6.1
Assigned Numbers RFC ..................................3.6.2
Administration of Ethernet Numbers ....................3.6.3
Ethernet Performance Analysis ......................... 3.7
Ethernet Hardware and Vendors ........................ 3.8
Section 4 -- Interest Groups, Periodicals, and
Conferences
Interest Groups ....................................... 4.1
SRI List of Lists .....................................4.1.1
BITNET ................................................4.1.2
Usenet Groups .........................................4.1.3
Periodicals ........................................... 4.2
Conferences ........................................... 4.3
Access to the Internet ................................ 4.4
Access to Books ....................................... 4.5
--
Charles Spurgeon Computation Center Networking Services
c.spurgeon@utexas.edu University of Texas at Austin
(512) 471-3241 ex 265 Room COM1, Austin TX 78712
-----------[000284][next][prev][last][first]---------------------------------------------------- Date: 27 Aug 91 19:22:20 GMT From: steveo@world.std.com (Steven W Orr) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards Subject: Need help selecting Ethernet cards for very high throughput rates.
We are trying to configure an SCO Unix system running some type of IP, (maybe TCP, maybe UPD) to operate at maximum throughput. Our goal is to get up to _6_ Megabits/Sec. We realize that we need EISA bus machines with 32-bit Ethernet cards to do this. We also realize that we will need multiple cards to accomplish this goal. We have no problems spending whatever it takes to make this machine as fast as possible, given the SCO/[34]86/EISA constraints. Another important detail is that each computer will be talking over a Cisco router with one ethernet card per computer. This way we completely eliminate packet collisions. Does anyone have SCO running with multiple cards? Which cards are you running? How many? What's your throughput? We have been in touch with Racal Interlan. They recommended their 6510 card. They told us that it has bus mastering and that it is a 16 bit card. Is this not a contradiction in terms? They said it would run at 6 Megabits/Sec. All the wisdom so far says that no 16 bit card will average over 1/4 Mb/sec. They also told us about their ES3210 card, which they claim can operate at _13_ Megabits/Sec. I thought that the cable can't operate faster than 10 Megabits/Sec. Am I missing something? How do I get real numbers that will tell me what to expect in the field? I don't know how obvious my lack of network expertise is, but if you see any questions that I'm not asking, I need to know that also. I'm sure I'm not asking everything I need to know. Many thanks in advance. -- ----------Time flies like the wind. Fruit flies like bananas.------------------ Steven W. Orr steveo@world.std.com uunet!world!steveo ----------Everybody repeat after me: "We are all individuals."-----------------
-----------[000285][next][prev][last][first]---------------------------------------------------- Date: 27 Aug 91 19:31:26 GMT From: jmb@ideas.com (Jonathan M. Bresler) To: comp.protocols.tcp-ip Subject: IPI3
for lack of a better place, i'm sending this request to tcp-ip. waht is IPI3? where is documentation and other additional info available on IPI3? thanx in advance, Jon Bresler
-----------[000286][next][prev][last][first]---------------------------------------------------- Date: 27 Aug 91 20:52:32 GMT From: wayne@ultra.com (Wayne Hathaway) To: comp.protocols.tcp-ip Subject: Re: TCP FIN and window
Following this discussion on "Can you send a FIN into a zero window?"
has been fascinating, because it is amazing to see how easy it is for
things like a particular networking model can become jumbled up with
the protocol itself.
I'd like to point out (as at least one other person has) that there is
no requirement that a TCP advertise a nonzero window if it does not
expect to receive data (other than to accommodate implementations that
won't send a FIN into a zero window, that is). For example, my
company makes a very fast network that gains a large amount of its
speed by moving data directly from one user buffer to another; it does
NOT buffer data in the kernel at either end (a true "zero copy" model
if ever there was one! :-). Using this networking model, the
receiving TCP advertises a zero window at any time the user has not
posted a read buffer, since it in fact does not have a place to put
any arriving data (no kernel buffering, remember). So when the
receiver has done its last read and received its last data, the window
will stay zero for the duration. We'd sure like the transmitter to go
ahead and send us its FIN, however. (Some people might say that it is
a shortcoming of TCP that it REQUIRES a nonzero window in order to be
able to close a connection. That simply points out that dependence on
particular models should be avoided when DESIGNING protocols as well!)
And as an aside, others have mentioned that this is similar to zero
window probing, which I don't think is quite right. A zero window
probe is really an attempt to elicit a retransmission of the PREVIOUS
ACK (which might have had a nonzero window and been lost), and not so
much an attempt to get the receiver to accept new data. However,
sending a FIN into a zero window is clearly an attempt to get the
receiver to accept the FIN itself.
Finally, I'd like to close by imploring people to separate out things
like operating system characteristics and particular data movement
models when discussing protocols. (For example, the receive window
size is NOT how much data the receiving operating system is able to
buffer for the user, in spite of such a description in many texts!)
To do otherwise will at best limit your creativity, and it may well
lead to outright broken protocols and/or implementations.
Wayne Hathaway domain: wayne@Ultra.COM
Ultra Network Technologies uucp: ...!ames!ultra!wayne
101 Daggett Drive phone: 408-922-0100 x132
San Jose, CA 95134 direct: Hey, you!
-----------[000287][next][prev][last][first]---------------------------------------------------- Date: 27 Aug 91 21:30:35 GMT From: donp@novell.com (don provan) To: comp.protocols.tcp-ip Subject: Re: TCP FIN and window
In article <1991Aug27.205232.7303@ultra.com> wayne@ultra.com (Wayne Hathaway) writes: >So when the receiver has done its last read and received its last >data, the window will stay zero for the duration. Just out of curiousity, if the application protocol is such that the receiver knows when it's done reading, why does it bother with a graceful close? Why doesn't it just reset the connection? (In case this seems irrelevant: if Mr. Hathaway's protocol depended on the FIN to indicate the end of the transmission, the reader would have to post one last receive buffer since it wouldn't know that it wasn't needed, and that would provide window for the FIN.) don provan donp@novell.com
-----------[000288][next][prev][last][first]---------------------------------------------------- Date: 27 Aug 91 23:16:45 GMT From: mlong@IASTATE.EDU (Michael C Long) To: comp.protocols.tcp-ip Subject: Re: Bug in tn3270 !
In article <1991Aug27.164129.19108@njitgw.njit.edu>, pv0618@hertz.njit.edu (Paranjothi Varadarajan) writes: > > Hi Folks ! > > As the subject says I am using tn3270 ( 4.1.1) to get to an IBM > mainframe machine (running MVS),, and having a prob with it. Here is the > further description of it : > > We have a system on IBM MVS where user can get to help screen by using > PF1 and get back to prev screen using PF5. Now, this works fine under > all different screens of the system , except one particular screen, > where once the user goes to help and hits PF5 to backup and the whole > system hangs. ie, it does not recognise any keyboard or any other input. > It doew , however give an error message "Invalid Control sequence" if we > hit certain keys , while it is hung. > > BTW , We are running hp-ux 7.05 on the unix side. > The Tn3270 TCP server on the other side is version 1.0. > or rather I should say the Telnet server on the IBM side is v 1.0. > ....... > > I know it sound CRAZY... but this is really the BEST way I could > figure-out to discuss the problem. > > I sure will be willing to give more info, But, DOES THIS SOUND LIKE > SOMETHING KNOWN TO ANY BODY OUT THERE !! > > Thanks a bunch folks.. > > - Kamlesh WE HAD SOMETHING VAGUELY SIMILAR TO WHAT YOU SEEM TO BE DESCRIBING HERE. WE WERE USING IBM'S TCP/IP FOR THE PC FEATURE OF THE TCP/IP FOR VM AND WERE TELNETING TO THE VM MACHINE. WHEN WE WOULD GET INTO CMS AND X-EDIT A FILE THE 'F' KEYS WOULD CAUSE A LOCK-UP, BUT TYPEING IN THE X-EDIT COMMAND (LIKE QQUIT) WOULD NOT CAUSE A LOCKUP. THE ONLY WAY WE COULD MAKE THIS WORK WAS TO SET THE PC'S 'TCP RECEIVE BUFFER' AND 'TCP LOW WINDOW' TO 220 BYTES. THEN OUR X-EDIT WORKED PERFECTLY. AS WE HAVE JUST PUT ON VER. 2.0 ONTO OUR VM MACHINE, I WAS EXPIRIMENTING TODAY WITH X-EDIT'S F KEYS AND THE PC'S BUFFER SIZES, BUT I COULD NO LONGER DUPLICATE THIS PARTICULAR PROBLEM. HOPE THIS HELPS MIKE LONG CENTER FOR AGRICULTURAL AND RURAL DEVELOPMENT IOWA STATE UNIVERSITY AMES, IA 50011
-----------[000289][next][prev][last][first]---------------------------------------------------- Date: 27 Aug 91 23:26:35 GMT From: thomson@hub.toronto.edu (Brian Thomson) To: comp.protocols.tcp-ip Subject: Re: TCP FIN and window
In article <1991Aug27.205232.7303@ultra.com> wayne@ultra.com (Wayne Hathaway) writes: >Using this [Ultranet] networking model, the >receiving TCP advertises a zero window at any time the user has not >posted a read buffer, since it in fact does not have a place to put >any arriving data (no kernel buffering, remember). So when the >receiver has done its last read and received its last data, the window >will stay zero for the duration. We'd sure like the transmitter to go >ahead and send us its FIN, however. (Some people might say that it is >a shortcoming of TCP that it REQUIRES a nonzero window in order to be >able to close a connection. That simply points out that dependence on >particular models should be avoided when DESIGNING protocols as well!) As a supporter of FIN-outside-WIN, I would agree that the RFC's position on this question is unfortunate. I don't know if you can attribute it to "dependence on particular models", though, since the RFC authors in fact used exactly the same model as you when describing their hypothetical implementation: they advertise a window only when read buffers have been posted by the application, and mention that another possible implementation *might* provide extra buffering in the host. So, given that they do consider a model like yours, I have to conclude that their requiring a nonzero window is a protocol bug. I, and presumably you, would be happier if the spec allowed a FIN just past the right edge, or at least a standalone FIN into a closed window. But, it don't, and, like it or not, the question remains of what to do with the standard as she be. Some implementation out there just might not send a FIN into a closed window, or not accept the one you send, and its implementers appear to be within their rights to build it that way. What to do? Well, you should certainly send the FIN, and if the other guy keeps throwing it away, I guess that's his problem. There doesn't seem to be any way out of it, except RST, which I would call innapropriate. Interestingly, BSD4.2 appears to willingly send a lone FIN, retransmit it, *and* drop the connection for too many retries, even if it was to a closed window (assuming I'm reading it right). This seems antisocial to me. The other side of the question is what to do if he won't send his FIN to your closed window. One way out is to advertise a one octet window and, if you receive real data, shrink it back to zero. But, we are strongly advised against window shrinking, so this is not a nice solution. A second approach is to supply at least one octet of system buffering. If it fills up and the window closes anyway, that's fine. The presence of real data implies that the application should read it at some point, opening the window up again - the problem we really needed to avoid was the closed window when the application *wasn't* going to try to read. I guess that second approach will work for most implementors, because most of them will have system buffering anyway. In UltraTechnology's case, and perhaps in others, it may be very unattractive. If so, it will come down to "how important is it to interoperate cleanly with these RFC sticklers?" which, in turn, depends on how many and who they are. Certainly, many implementations are based on the Berkeley one, which sends the FIN in spite of the RFC. Are there significant ones that don't? -- Brian Thomson, CSRI Univ. of Toronto utcsri!uthub!thomson, thomson@hub.toronto.edu
-----------[000290][next][prev][last][first]---------------------------------------------------- Date: 28 Aug 91 00:54:16 GMT From: mailinfo@netcom.COM (Will Estes) To: comp.mail.misc,comp.protocols.tcp-ip Subject: Where Can I Get PCMAIL (RFC1056) Clients And Servers?
Can someone point me to an FTP source for any SunOS implementations of RFC1056 (the PCMAIL server) and any clients for same? Thanks, Will Estes Internet: mailinfo@netcom.com P.S. Please courtesy copy your response to me directly as I do not always read this newsgroup.
-----------[000291][next][prev][last][first]---------------------------------------------------- Date: 28 Aug 91 10:52:34 GMT From: PIRARD@VM1.ULG.AC.BE (Andr'e PIRARD) To: comp.protocols.tcp-ip Subject: Re: EBCDIC ASCII and *much* more
On Tue, 20 Aug 91 17:19:23 -0400 you said:
>Thanks for the abundance of reference your writings afford in this area of
>of character representation.It is a good paper which raises a couple of issues
>the have been long standing in this increasing complex area, the
>representation and presentation of transmitted data. I have not read all the
>above mentioned writings and offer the following on on the subject.
Although it mentions ISO 10646, my document does not deal with general
character representation. In short, the point is that:
- we've had virtually no support of our national characters until about
the introduction of the PC and the Mac 10 years ago, on IBM mainframes
4 years ago and now that Unix enters the game.
- this support is purely local, telecommunication support is virtually null
because of 7-bit restrictions and the differences in character codes despite
similar character sets.
- I expect many years before a world wide code will be used effectively.
- all it takes to implement an extremely valuable solution right now is:
- to get "convinced" that a character is coded on 8 bits and modify
programs accordingly (easy for many essential protocols).
- to realize that the difference in character codes is a pain in the neck
and that translation is "needed somewhere" when data is moving from one
machine to another, *exactly* like EBCDIC is translated to ASCII. EBCDIC
software is often easy to adapt because translation is always present.
>Is being a standard justification for usage ?
At least usage is justification for a standard, but when there's only one
official standard that's justification enough to use it.
The point is that it is not reasonable to expect that any machine be able
to recognize any 8-bit code coming its way but that each must translate
to and from a standard code instead. ASCII has proved useful enough, hasn't
it, and you don't use a pile of dictionaries to read this conference.
So, because we restrict ourselves to single-octet codes for now and because
an octet has not enough code points for all languages of the worlds, we must
admit different codes should be used according to the language, but only
one per language.
ISO 8859 is just that: a palette of 8-bit codes covering the widest range of
languages it can. As I am speaking French, I use ISO 8859/1 but I won't be
surprised to receive ISO 8859/7 if some Greek tries to speak to me.
Unhappily, I speak very very little Greek, and I'd reply that in English,
which is all-right in ISO 8859/7. But if I did, I'd surely manage to type
and display that code.
This is the least-annoyance solution to implement to-day, and it's easy
if the principles are agreed.
Now in aix1.segi.ulg.ac.be:iso/iso8859.notes
Thanks for your interest.
Andr'e PIRARD SEGI, Univ. de Li`ege 139.165 IP coordinator
B26 - Sart Tilman B-4000 Li`ege 1 (Belgium) +32 (41) 564932
pirard@vm1.ulg.ac.be alias PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU
-----------[000292][next][prev][last][first]---------------------------------------------------- Date: 28 Aug 91 12:55:20 GMT From: dls@mentor.cc.purdue.edu (David L Stevens) To: comp.protocols.tcp-ip Subject: Re: TCP FIN and window
In article <1991Aug27.213035.10980@novell.com>, donp@novell.com (don provan) writes: > Just out of curiousity, if the application protocol is such that the > receiver knows when it's done reading, why does it bother with a > graceful close? Why doesn't it just reset the connection? (In case > this seems irrelevant: if Mr. Hathaway's protocol depended on the FIN > to indicate the end of the transmission, the reader would have to post > one last receive buffer since it wouldn't know that it wasn't needed, > and that would provide window for the FIN.) I think you're making too many assumptions about the protocol here. Suppose I design a protocol where the server accepts one request, answers it, and then goes away. Suppose further that the server keeps a log of successful queries, so in the server I need to know with reasonable surety that the data I sent was in fact delivered to the client. On the server side, once I've read the request, I know I no longer need to read anything. But I still want to (reliably) write stuff. That doesn't mean I can do a RESET, even after I've written the reply, because that will throw away any buffered data that I really do want delivered to the other end. I need a synchronous close() in the server for the server to know the data was delivered-- a RESET doesn't cut it. So there's a counter-example. -- +-DLS (dls@mentor.cc.purdue.edu)
-----------[000293][next][prev][last][first]---------------------------------------------------- Date: 28 Aug 91 13:39:10 GMT From: pv0618@hertz.njit.edu (Paranjothi Varadarajan) To: comp.protocols.tcp-ip Subject: tn3270 Bug. Follow-up..
Thanks for replying folks ... I received following response from somebody on the net regarding my earlier posting, but am not sure how to map this onto my hp-ux tcp stuff. Some further tips would be of great help.... WERE USING IBM'S TCP/IP FOR THE PC FEATURE OF THE TCP/IP FOR VM AND WERE TELNETING TO THE VM MACHINE. WHEN WE WOULD GET INTO CMS AND X-EDIT A FILE THE 'F' KEYS WOULD CAUSE A LOCK-UP, BUT TYPEING IN THE X-EDIT COMMAND (LIKE QQUIT) WOULD NOT CAUSE A LOCKUP. THE ONLY WAY WE COULD MAKE THIS WORK WAS TO SET THE PC'S 'TCP RECEIVE BUFFER' AND 'TCP LOW WINDOW' TO 220 BYTES. THEN OUR X-EDIT WORKED PERFECTLY. AS WE HAVE JUST PUT ON VER. 2.0 ONTO OUR VM MACHINE, I WAS EXPIRIMENTING TODAY WITH X-EDIT'S F KEYS AND THE PC'S BUFFER SIZES, BUT I COULD NO LONGER DUPLICATE THIS PARTICULAR PROBLEM. HOPE THIS HELPS MIKE LONG CENTER FOR AGRICULTURAL AND RURAL DEVELOPMENT IOWA STATE UNIVERSITY AMES, IA 50011 Thanks once again...
-----------[000294][next][prev][last][first]---------------------------------------------------- Date: 28 Aug 91 13:52:56 GMT From: a20@nikhefh.nikhef.nl (Marten Terpstra) To: comp.protocols.tcp-ip,comp.protocols.iso Subject: Any results from Gbits testbeds ?
Hi all, Couls anyone tell me if there are any (preliminary) test results or other conclusions available somewhere on the NSF net sponsored Gigabit testbeds ? And now that I'm more or less on the subject, can anyone suggest some reading material on ATM and other of these goodies that are to come ? Thanks, -Marten -- Marten Terpstra Email : terpstra@nikhef.nl National Institute for Nuclear Phone : +31 20 592 5102 and High Energy Physics (NIKHEF-H), Fax : +31 20 592 5155 PO Box 1882, NL-1009 DB Amsterdam, The Netherlands Bus error (passengers dumped)
-----------[000295][next][prev][last][first]----------------------------------------------------
Date: 28 Aug 91 15:08:00 GMT
From: A563700@CUCSC.BITNET ("C.H. Cheng, The Chinese Univ. of Hong Kong")
To: comp.protocols.tcp-ip
Subject: Support of Multiple Logical Subnetwork by RoutersHi all, Is anyone out there using 3Com Brouter (BR/2000)? I think we have the latest version (V3.0.2.3). Unfortunately, although the manual mentions that it supports Multiple Logical Network (Subnetwork?!) for IP, we are not able to implement subnet routing through a single port when we set up two addresses (with different subnet no. of course) to this port. It seems that the secondary address is of no use with this brouter. I personally think that it's quite ridiculous that even UCX 1.3a of DEC running on VMS can support it successfully although it is critized by many people as one of the worst TCP/IP implementation for VMS. Have you experienced the same problem with 3Com Brouter? Any solutions to this? Is there anyone running Multiple Logical (Sub)network successfully with other brand of bridging router? Any other comments are welcome also. Thanks in advance. Regards, C.H. Cheng Computer Services Center The Chinese Univ of Hong Kong P.S. This mail is cross-posted to BIG-LAN list.
-----------[000296][next][prev][last][first]---------------------------------------------------- Date: 28 Aug 91 16:45:23 GMT From: dmc@doc.Lanl.GOV (dave clark) To: comp.protocols.tcp-ip Subject: unsubscribe
Please remove me from the mailing list. Thanks! Dave Clark
-----------[000297][next][prev][last][first]---------------------------------------------------- Date: 28 Aug 91 17:22:47 GMT From: trey@ut-emx.uucp (Trey Garlough) To: comp.protocols.tcp-ip Subject: Re: NFS vendors, addresses or phones
In article <30686@uflorida.cis.ufl.EDU> dalton@pine.circa.ufl.edu writes: >Does anyone know the phone number or address for info about > >PC/TCP Interdrive, ftp Software, Inc. or >Beame & Whitside's, B&W NFS? FTP Software in Mass (617) 246-0900 B&W in Ont (416) 648-6556
-----------[000298][next][prev][last][first]---------------------------------------------------- Date: 28 Aug 91 17:33:14 GMT From: jlawton@stardent.com (Jennifer Lawton) To: comp.protocols.tcp-ip Subject: Re: Diskless Sun 3/50 as X-terminal over SLIP/PPP. How to boot?
Why serial lines? We have a lot of 3/50 as X-terminals but they are all over ethernet. I can detail, to you, how to do this if you are interested. Jennifer Lawton Stardent Computer jlawton@stardent.com 521 Virginia Road (508)287-0100 x305 Concord, MA 01742
-----------[000299][next][prev][last][first]---------------------------------------------------- Date: 28 Aug 91 21:55:04 GMT From: zweig@cs.uiuc.edu (Johnny Zweig) To: comp.protocols.tcp-ip Subject: Re: TCP FIN and window
How about advertizing a one-octet window? There's no law that says that you have to actually _accept_ data -- so advertize a teensy window when you expect a FIN (I leave it as an exercise to figure a way for the TCP module to know when to do this) and eat the FIN which doesn't need to be buffered since it isn't actually a data octet. If there is more than one octet in the last packet, something is wrong. I don't see the problem. -Johnny Singleton
-----------[000300][next][prev][last][first]---------------------------------------------------- Date: 28 Aug 91 22:32:21 GMT From: mju@mudos.ann-arbor.mi.us (Marc Unangst) To: comp.protocols.tcp-ip,comp.dcom.lans Subject: How to connect to the Internet?
Although I've been dealing with Usenet and Unix for quite a while, I haven't had to deal with the Internet until recently. I've used it, of course, through dialup connections to Internet-connected machines, but I don't know a whole lot about actually setting up the hardware end of stuff. However, the higher-ups at the company have decided that they want an Internet connection, and it is upon my shoulders that the responsibility falls, so... We currently have a small (3 workstation) TCP/IP network with two Open Desktop machines and an MS-DOS box running NCSA Telnet. I understand TCP/IP pretty well on the single-subnet level, and have gotten things like BIND, ftp/telnet, etc. to work properly. However, I haven't done a whole lot with internetworking, routing between subnets, etc. I also don't have a whole lot of experience with gateways, routers, and other such devices, since we currently only have one Ethernet segment. My question is: How would I go about connecting this network to the Internet? What hardware (gateways, leased-line modems, etc.) is necessary? Who should I contact in my area (SE Michigan) to get hooked up? Will I need any software (routing, etc.) that isn't included with Open Desktop (which includes things like named, routed, etc.)? And finally, what would be a rough estimate of startup costs and continuing costs for a 56Kbps leased-line connection to the Internet? Thanks a lot, and I suppose I'll post a summary when the replies stop flooding in... -- Marc Unangst | "I _do_ love my country. It's my government mju@mudos.ann-arbor.mi.us | that I'm scared of." ...!hela!mudos!mju | -Seen on a bumper sticker
-----------[000301][next][prev][last][first]---------------------------------------------------- Date: 29 Aug 91 02:02:35 GMT From: mshiels@TMSoftware.ca (Michael A. Shiels) To: comp.protocols.tcp-ip Subject: 2nd release of BSD networking code etc
Does anyone have the 2nd release of BSD networking code etc up for FTP access? -- --- Michael A. Shiels | mshiels@masnet.uucp MaS Network Software and Consulting | mshiels@tmsoftware.ca
-----------[000302][next][prev][last][first]---------------------------------------------------- Date: 29 Aug 91 04:03:28 GMT From: crum@alicudi.usc.edu (Gary L. Crum) To: comp.protocols.tcp-ip Subject: Scientific American networking issue
I saw in a library yesterday a special issue of Scientific American devoted to computer communications. It includes an article by Senator Al Gore on "Infrastructure for the global village" and an article on network technologies by Vint Cerf. (Excuse me but I can't remember the title of the latter article.) Don't miss it -- I think the issue is particularly appropriate for recommendation to people not directly involved in computer networking research and development. Is the National Research and Education Network (NREN) effort going well? NREN is mentioned in the article by Al Gore. Gary
-----------[000303][next][prev][last][first]---------------------------------------------------- Date: 29 Aug 91 04:17:08 GMT From: martin@unislc.uucp (Martin Cryer) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards Subject: Re: Need help selecting Ethernet cards for very high throughput rates.
In article <1991Aug27.192220.20958@world.std.com> steveo@world.std.com (Steven W Orr) writes: >We are trying to configure an SCO Unix system running some type of >IP, (maybe TCP, maybe UPD) to operate at maximum throughput. Our goal >is to get up to _6_ Megabits/Sec. We realize that we need EISA bus >machines with 32-bit Ethernet cards to do this. We also realize that >we will need multiple cards to accomplish this goal. We have no >problems spending whatever it takes to make this machine as fast as >possible, given the SCO/[34]86/EISA constraints. > >Another important detail is that each computer will be talking over a >Cisco router with one ethernet card per computer. This way we >completely eliminate packet collisions. > >Does anyone have SCO running with multiple cards? Which cards are you >running? How many? What's your throughput? > >We have been in touch with Racal Interlan. They recommended their >6510 card. They told us that it has bus mastering and that it is a 16 No, you can have ISA bus masters (eg Adaptec 1542 SCSI) but be aware they don't always work in all PCs and often have a memory DMA speed limit around 5.0MBytes/s (which is below what you may want...) >bit card. Is this not a contradiction in terms? They said it would >run at 6 Megabits/Sec. All the wisdom so far says that no 16 bit card >will average over 1/4 Mb/sec. Not true, the Adaptec 1542 can do sustained SCSI I/O at around 2.5 MBytes/s to multiple drives (the EISA 1740 board though does much better and hogs the I/O bus much less). > >They also told us about their ES3210 card, which they claim can >operate at _13_ Megabits/Sec. I thought that the cable can't operate >faster than 10 Megabits/Sec. Am I missing something? How do I get >real numbers that will tell me what to expect in the field? Mmmm, they may be quoting the burst speed from memory to the controller across the EISA bus. You will be lucky to get over 75% of 10MBits/s out of Ethernet really. > >I don't know how obvious my lack of network expertise is, but if you >see any questions that I'm not asking, I need to know that also. I'm >sure I'm not asking everything I need to know. > >Many thanks in advance. > I think you are asking too much of a timesharing O/S even with an EISA PC to get sustained 6Mbytes/s. If you only want it for bursts, you may have better luck. Or you might want to try using SCSI as a LAN and use 2 EISA SCSI controllers (in target and initiator mode) to send the data between systems, though the range will be limited to 25metres for differential SCSI. Martin Cryer Unisys Europe Africa Unix SVR4 Development Unisys Salt Lake City All opinions are my own and not those of my employer.
-----------[000304][next][prev][last][first]---------------------------------------------------- Date: 29 Aug 91 07:08:05 GMT From: craig@sics.se (Craig Partridge) To: comp.protocols.tcp-ip,comp.protocols.iso Subject: Re: Any results from Gbits testbeds ?
>Couls anyone tell me if there are any (preliminary) test results or other
>conclusions available somewhere on the NSF net sponsored Gigabit testbeds ?
Marten:
Sure, there are lots of results beginning to come out. There are various
sources. The testbeds produce annual reports on their work and some of them
are publicly available. Some papers are beginning to be published -- there
will be a few at SIGCOMM '91 in Zurich next week. I believe we'll see some
articles in the March '92 issue of IEEE Network (though this is still being
worked out).
>And now that I'm more or less on the subject, can anyone suggest some reading
>material on ATM and other of these goodies that are to come ?
Gack -- that's harder. I teach a course on this material for INTEROP
have found it hard to pull together a good reading list despite requests
from students. Turner's paper is still the best one for the philosophy
underlying cell-switching (and thus ATM). What other goodies are you
interested in?
If you're willing to wait there's lots of stuff coming. There's currently a
plan to do special gigabit issues of all the major IEEE Comm. Soc. magazines
this spring -- which should give you some useful reading. Also, there are
a couple of books on gigabit networking in preparation (I'm writing one of
them) but they won't appear til late next year.
Craig Partridge
Incoming Editor-in-Chief, IEEE Network Magazine
-----------[000305][next][prev][last][first]---------------------------------------------------- Date: 29 Aug 91 08:29:58 GMT From: J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) To: comp.protocols.tcp-ip Subject: Re: Transport Protocols for Operating Environment platforms
>For Tele-presence/Operating Environment platforms, we need a rugged >transport protocol like in the IP suite since we don't know all of the >network types we'll be running on. That is, we would like one transport >protocol for LANs and WANs at a wide range of speeds and signal-to-noise >ratios. have a look at ST-II, PVP and NVP, but also lots of people are looking into modifiying IP and TCP to have timestamps that can be used to provide delay skew control, and people are looking at resource guarantee IP gateways...try end2end-interest@isi.edu >The protocol at the transport level is a cross between datagrams and >connection-oriented communications models. yes - agree with this > - toggle acknowledgements on/off > and when on, specify the AC >K- count size for sequencing; > - variable time-outs lengths defaulting to the `slow-start' technique; > - variable retransmission attempt counts. yep, agree with trying these, but there's more (like one to many communication >Synchronization may become a necessary feature for the applications, so >working NTP into the picture would be nice. see ACM SIGCOMM last year - paper by liskov et al plus also multipath synching etc etc...there is lots of work at berkeley on this (prof ferrari's group) >ps - this would be interesting to specify in Estelle and to simulate with >GROPE. gee, I'm not doing too much this week... :) or use bellcore's SPIN system... cheers jon ------------------------------ End of forwarded message 1
-----------[000306][next][prev][last][first]---------------------------------------------------- Date: 29 Aug 91 10:08:11 GMT From: DAVID@wcc.govt.nz (David Richards) To: comp.protocols.tcp-ip Subject: What are the spec's for T3?
Can someone tell me what T3 spec's are. AdvTHANKSance --- David P.S. My return address is screwed, please SEND not REPLY, to "david@ccc.govt.nz" +------------------------------------------------------------------------------+ | David Richards, Systems Programmer, | e-mail "david@ccc.govt.nz" | | MIS unit, Christchurch City Council | PSI PSI%0530130010083::DAVID | | P.O. Box 237, Christchurch, | Phone +64 3 711-689, Fax +64 3 796-706 | | New Zealand "Do it tomorrow, you've made enough mistakes today" | +------------------------------------------------------------------------------+
-----------[000307][next][prev][last][first]---------------------------------------------------- Date: 29 Aug 91 13:07:30 GMT From: Y.Murayama@CS.UCL.AC.UK (Yuko Murayama, +44-71-387-7050 ext.3721) To: comp.protocols.tcp-ip Subject: a minconfigured host
Suppose that an IP host is miconfigured with a forwarding capability, i.e. the host would try to forward a packet received which was not destined to this host, would it decrease the TTL of the packet? Yuko Murayama Dept of Computer Science University College London
-----------[000308][next][prev][last][first]---------------------------------------------------- Date: 29 Aug 91 13:15:48 GMT From: mike@tredysvr.Tredydev.Unisys.COM (Mike Marciniszyn) To: comp.unix.sysv386,comp.protocols.tcp-ip Subject: TCP/IP - C compiler BUG
This article documents a problem with the Lachman TCP/IP implementation
concerning the sequence number macros contained in netinet/tcp_seq.h.
(The problem may also exist in other TCP/IP implementations based on the
original BSD4.3 source.) A bug exists in the standard AT&T C compiler that
prevents the macro
#define SEQ_GT(a,b) ((int)((a)-(b)) > 0)
from working properly when the macro is given "a" with the value 0x7fffff6c and
"b" with the value 0x80000520. In that case the code generated is as follows:
movl 0x8(%ebp),%eax # load of a
subl 0xc(%ebp),%eax # subtract b
jle 0x1c <1c6> #
The subtract with the above values sets the SF (sign flag) and the OF
(overflow flag). The jle in spec in the Intel manual jumps when ZF = 1
or SF != OF. In this particular case SF and OF are both one so the test
falls through erroneously saying the SEQ_GT is true. This bug causes
the tcp driver to send erroneous urgent data when the snd.una is equal
to 0x7fffff6c and snd.nxt is equal to 0x80000520. Code in tcp_output()
then erroneously sends a whole packet marked as urgent data causing the
connection to hang. (This may not be the only manifestation of the problem!).
There are really two possible solutitons to the problem:
1. Fix the compiler to do the zero compare properly. In fact the Free Software
Foundation's compiler gcc (1.39) works correctly because it generates
the following code:
movl 0x8(%ebp),%eax
subl 0xc(%ebp),%eax
testl %eax,%eax # different from standard C
jle 0x1c <1f9>
Note the test before the jle. This zeros out the OF so that the jle
correctly branches whenever the SF is set or the ZF is set! All V3.x
versions of the standard C compiler and the V4.0 version that we have
exhibit the problem.
2. Fix the macros for the i386 in netinet/tcp_seq.h to the following:
#define SEQ_LT(a,b) (((a)-(b))&0x80000000)
#define SEQ_LEQ(a,b) (!SEQ_GT(a,b))
#define SEQ_GT(a,b) SEQ_LT(b,a)
#define SEQ_GEQ(a,b) (!SEQ_LT(a,b))
This patch is changing the test to always key off of bit 31 of the a - b
result which is always the sign bit on systems with 2's complement
arithmetic. The fix for tcp is to just recompile the tcp driver with the
an updated netinet/tcp_seq.h. (Released versions of the V4.0 version of
netinet/tcp_seq.h have the above fix).
Unisys suppport may have supplied a CTIX TCP/IP version or patch with
the macros in netinet/tcp_seq.h as follows:
#define SEQ_LT(a,b) ((a) < (b))
#define SEQ_LEQ(a,b) ((a) <= (b))
#define SEQ_GT(a,b) ((a) > (b))
#define SEQ_GEQ(a,b) ((a) >= (b))
This fix is not correct when for example a has the value 0xffffff6c and
b has the value 0x520. The same problem will occur!
Attached is a shell archive with contains a client and server program which
can be started through the loopback interface or between two systems to see
if a particular TCP/IP implementation has the problem. The client program
should be run on the suspect system. Also contained in the archive is a test
to see if the standard C compiler has the bug. The archive contains the
follows members:
clnt.c - client side of TCP/IP test program
seqtest.c - compiler test program
seqtest.h - header file with alternate macros
seqtest.mk - make file for seqtest programs
srvr.c - server side of TCP/IP test program
When make -f seqtest.mk is entered vaxtest, ctixtest, and v40test are
generated. The output of the three macro alternatives on our system
with the buggy standard 386 C compiler are as follows:
vaxtest: (The original BSD4.3 defines)
1 Not Greater than 2 diff = ffffffff
7fffff6c Not Greater than 7fffff6c diff = 0
7fffff6c Not Greater than 7fffff6d diff = ffffffff
7fffff6c Greater than 80000520 diff = fffffa4c
7fffff6c Greater than 80000520 diff = fffffa4c
ffffff6c Not Greater than 520 diff = fffffa4c
80000520 Not Greater than 80000521 diff = ffffffff
ctixtest: (CTIX's TCP/IP support patch)
1 Not Greater than 2 diff = ffffffff
7fffff6c Not Greater than 7fffff6c diff = 0
7fffff6c Not Greater than 7fffff6d diff = ffffffff
7fffff6c Not Greater than 80000520 diff = fffffa4c
7fffff6c Not Greater than 80000520 diff = fffffa4c
ffffff6c Greater than 520 diff = fffffa4c
80000520 Not Greater than 80000521 diff = ffffffff
v40test: (V40's correct fix)
1 Not Greater than 2 diff = ffffffff
7fffff6c Not Greater than 7fffff6c diff = 0
7fffff6c Not Greater than 7fffff6d diff = ffffffff
7fffff6c Not Greater than 80000520 diff = fffffa4c
7fffff6c Not Greater than 80000520 diff = fffffa4c
ffffff6c Not Greater than 520 diff = fffffa4c
80000520 Not Greater than 80000521 diff = ffffffff
All tests should have note Not Greater!
Mike Marciniszyn
Maintenance Subsystem Development
Unisys Tredyffrin
DOMAIN: mike@tredysvr.tredydev.unisys.com UUCP: tredysvr!mike
----------------------------- cut here for archive -----------------------
#! /bin/sh
# This is a shell archive. Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file". To overwrite existing
# files, type "sh file -c". You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g.. If this archive is complete, you
# will see the following message at the end:
# "End of shell archive."
# Contents: clnt.c seqtest.c seqtest.h seqtest.mk srvr.c
# Wrapped by mike@tredysvr on Thu Aug 29 09:02:58 1991
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f 'clnt.c' -a "${1}" != "-c" ; then
echo shar: Will not clobber existing file \"'clnt.c'\"
else
echo shar: Extracting \"'clnt.c'\" \(1889 characters\)
sed "s/^X//" >'clnt.c' <<'END_OF_FILE'
X#include <sys/types.h>
X#include <sys/socket.h>
X#include <sys/time.h>
X#include <netinet/in.h>
X#include <netdb.h>
X#include <stdio.h>
X#include <errno.h>
X
X#define TRUE 1
X#define DATA "Half a league,half a league ..........."
Xchar bufr[20100];
Xchar bufs[20100];
X
Xint sock, length,count;
Xstruct sockaddr_in server;
Xstruct hostent *hp ,*gethostbyname();
Xint rval;
Xstruct timeval to;
Xint rslt;
X
X
X
Xmain(argc,argv)
Xint argc;
Xchar **argv;
X{
Xint i, rslt;
X for(i=0; i<20100;i++) bufs[i] ='a';
X sock = socket(AF_INET,SOCK_STREAM,0);
X if (sock < 0)
X {
X perror("opening socket");
X exit(1);
X }
X
X server.sin_family = AF_INET;
X hp =gethostbyname(argv[1]);
X if (hp == 0)
X {
X perror("gethostbyname ");
X exit(2);
X }
X bcopy(hp->h_addr,&server.sin_addr,hp->h_length);
X server.sin_port = htons(atoi(argv[2]));
X
X if (connect(sock,&server,sizeof(server)) < 0)
X {
X perror("connect error");
X exit(2);
X }
X
X do
X {
X send_msg();
X }
X while(TRUE);
X}
X
X
Xsend_msg()
X
X{
Xint rval;
X {
X errno = 0;
X rval =write(sock,bufs,sizeof(bufs));
X if (rval == -1)
X {
X perror("wrting stream message");
X exit(4);
X }
X else
X if (rval == 0)
X {
X perror("write error\n");
X printf("\nEnding Connection.");
X exit(5);
X }
X
X else
X /* if((count/1000)*1000 == count) */
X {
X /*
X printf("message sent length = #%d\n",rval);
X printf("errno = #%d\n", errno);
X */
X }
X count+=1;
X }
X}
Xrecv_msg()
X{
Xint rval;
X {
X rval = read(sock,bufr,20100);
X
X if (rval == -1)
X {
X perror("reading stream message");
X exit(1);
X }
X else
X if (rval == 0)
X {
X printf("\nEnding Connection.");
X exit(5);
X }
X
X else
X /* if ((count/20100)*20100 == count) */
X {
X printf("message recvd length = #%d\n",rval);
X printf("errno = #%d\n", errno);
X rslt = strncmp(bufr,bufs,rval);
X if (rslt)
X {
X printf("buffers did not compare\n",rslt);
X }
X }
X
X count+=rval;
X }
X}
X
END_OF_FILE
if test 1889 -ne `wc -c <'clnt.c'`; then
echo shar: \"'clnt.c'\" unpacked with wrong size!
fi
# end of 'clnt.c'
fi
if test -f 'seqtest.c' -a "${1}" != "-c" ; then
echo shar: Will not clobber existing file \"'seqtest.c'\"
else
echo shar: Extracting \"'seqtest.c'\" \(515 characters\)
sed "s/^X//" >'seqtest.c' <<'END_OF_FILE'
X#include "seqtest.h"
X
Xmain(argc, argv)
Xint argc;
Xchar **argv;
X{
X testit(0x01, 0x02);
X testit(0x7fffff6c, 0x7fffff6c);
X testit(0x7fffff6c, 0x7fffff6d);
X testit(0x7fffff6c, 0x80000520);
X testit(0x7fffff6c, 0x80000520);
X testit(0xffffff6c, 0x00000520);
X testit(0x80000520, 0x80000521);
X}
X
Xtestit(val1, val2)
Xunsigned long val1, val2;
X{
X if (SEQ_GT(val1, val2)) {
X printf("%lx Greater than %lx diff = %lx\n",val1,val2, val1-val2);
X } else {
X printf("%lx Not Greater than %lx diff = %lx\n",val1,val2, val1-val2);
X }
X}
END_OF_FILE
if test 515 -ne `wc -c <'seqtest.c'`; then
echo shar: \"'seqtest.c'\" unpacked with wrong size!
fi
# end of 'seqtest.c'
fi
if test -f 'seqtest.h' -a "${1}" != "-c" ; then
echo shar: Will not clobber existing file \"'seqtest.h'\"
else
echo shar: Extracting \"'seqtest.h'\" \(502 characters\)
sed "s/^X//" >'seqtest.h' <<'END_OF_FILE'
X#ifdef V40
X#define SEQ_LT(a,b) (((a)-(b))&0x80000000)
X#define SEQ_LEQ(a,b) (!SEQ_GT(a,b))
X#define SEQ_GT(a,b) SEQ_LT(b,a)
X#define SEQ_GEQ(a,b) (!SEQ_LT(a,b))
X#endif
X#ifdef VAX
X#define SEQ_LT(a,b) ((int)((a)-(b)) < 0)
X#define SEQ_LEQ(a,b) ((int)((a)-(b)) <= 0)
X#define SEQ_GT(a,b) ((int)((a)-(b)) > 0)
X#define SEQ_GEQ(a,b) ((int)((a)-(b)) >= 0)
X#endif
X#ifdef CTIX
X#define SEQ_LT(a,b) ((a) < (b))
X#define SEQ_LEQ(a,b) ((a) <= (b))
X#define SEQ_GT(a,b) ((a) > (b))
X#define SEQ_GEQ(a,b) ((a) >= (b))
X#endif
END_OF_FILE
if test 502 -ne `wc -c <'seqtest.h'`; then
echo shar: \"'seqtest.h'\" unpacked with wrong size!
fi
# end of 'seqtest.h'
fi
if test -f 'seqtest.mk' -a "${1}" != "-c" ; then
echo shar: Will not clobber existing file \"'seqtest.mk'\"
else
echo shar: Extracting \"'seqtest.mk'\" \(258 characters\)
sed "s/^X//" >'seqtest.mk' <<'END_OF_FILE'
Xall: ctixtest vaxtest v40test
X
Xctixtest: seqtest.c
X $(CC) -g -o ctixtest -DCTIX seqtest.c
Xvaxtest: seqtest.c
X $(CC) -g -o vaxtest -DVAX seqtest.c
Xv40test: seqtest.c
X $(CC) -g -o v40test -DV40 seqtest.c
Xclean:
X rm -f ctixtest vaxtest v40test
Xclobber: clean
X
END_OF_FILE
if test 258 -ne `wc -c <'seqtest.mk'`; then
echo shar: \"'seqtest.mk'\" unpacked with wrong size!
fi
# end of 'seqtest.mk'
fi
if test -f 'srvr.c' -a "${1}" != "-c" ; then
echo shar: Will not clobber existing file \"'srvr.c'\"
else
echo shar: Extracting \"'srvr.c'\" \(1985 characters\)
sed "s/^X//" >'srvr.c' <<'END_OF_FILE'
X#include <sys/types.h>
X#include <sys/socket.h>
X#include <sys/time.h>
X#include <netinet/in.h>
X#include <netdb.h>
X#include <stdio.h>
X#include <errno.h>
X
X#define TRUE 1
X
Xint sock, length, count;
Xstruct sockaddr_in server;
Xint msgsock;
Xchar bufr[20100];
Xchar bufs[20100];
Xint rval,rslt;
Xstruct timeval to;
X
X
Xrecv_msg()
X{
Xint rval;
X {
X rval = read(msgsock,bufr,20100);
X
X if (rval == -1)
X {
X perror("reading stream message");
X exit(1);
X }
X else
X if (rval == 0)
X {
X printf("\nEnding Connection.");
X exit(5);
X }
X
X else
X /* if ((count/2010000)*2010000 == count ) */
X {
X /*
X printf("message recvd length = #%d\n",rval);
X printf("errno = #%d\n", errno);
X */
X rslt = strncmp(bufr,bufs,rval);
X if (rslt)
X {
X printf("buffers did not compare\n",rslt);
X }
X }
X
X count+=rval;
X
X }
X}
X
X
Xsend_msg ()
X{
Xint rval;
X
X {
X errno = 0;
X rval =write(msgsock,bufs,sizeof(bufs));
X if (rval == -1)
X {
X perror("wrting stream message");
X exit(4);
X }
X else
X if (rval == 0)
X {
X perror("write error\n");
X printf("\nEnding Connection.");
X exit(5);
X }
X
X else
X /* if((count/1000)*1000 == count) */
X {
X printf("message sent length = #%d\n",rval);
X printf("errno = #%d\n", errno);
X }
X count+=1;
X }
X}
X
Xmain()
X{
Xint i;
X
X for(i=0; i<20100;i++) bufs[i] ='a';
X sock = socket(AF_INET,SOCK_STREAM,0);
X if (sock < 0)
X {
X perror("opening socket");
X exit(1);
X }
X
X server.sin_family = AF_INET;
X server.sin_addr.s_addr=INADDR_ANY;
X server.sin_port = 0;
X if (bind(sock,&server,sizeof(server)))
X {
X perror("bind error");
X exit(2);
X }
X length = sizeof(server);
X if (getsockname(sock,&server,&length))
X {
X perror("getsockname error");
X exit(3);
X }
X printf("socket has a port number #%d\n",ntohs(server.sin_port));
X
X listen(sock,5);
X msgsock = accept(sock,(struct sockaddr *) 0, (int *) 0);
X if (msgsock == -1)
X {
X perror("accept");
X exit(4);
X }
X
X do
X {
X recv_msg();
X }
X while(TRUE);
X}
END_OF_FILE
if test 1985 -ne `wc -c <'srvr.c'`; then
echo shar: \"'srvr.c'\" unpacked with wrong size!
fi
# end of 'srvr.c'
fi
echo shar: End of shell archive.
exit 0
-----------[000309][next][prev][last][first]---------------------------------------------------- Date: 29 Aug 91 13:18:58 GMT From: rawe@iwisp1.iwi.uni-sb.de (Ralf Wein) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: Route problems
Hi everybody, I have a problem with my router between Token-Ring and Ethernet. Both have their own subnets, but only Ethernet is working fine. The router is an PS/2 with AIX Rel. 1.2 and TCPIP is Version 1.2. In the Token-Ring are some UNIX-machines (IBM RTs, AIX PS2s, RS/6000), an IBM AS/400 and DOS-PC with AADU (AIX Access for DOS Users). When starting the systems, communications work. But when two machines in the Token-Ring talk together (ping is enough) they loose their route-entry to the router. This had been static defined with oroute add net <subnet> <router> 1o. The only way to solve this problem was a static host-route entry on my router for every machine in the Token-Ring (dont know why but it works). The second problem is: AADU does not recognize the computers in the Token-Ring since I have installed the router. Ralf Please mail me to address rawe@iwisp1.iwi.uni-sb.de (this computer is in the ethernet, uff)
-----------[000310][next][prev][last][first]---------------------------------------------------- Date: 29 Aug 91 13:21:58 GMT From: ssanbeg@visual.spk.wa.us (Scott Sanbeg) To: comp.os.os2.misc,comp.protocols.tcp-ip Subject: Building a LAN around OS/2 -- Newbie asks advice
Hello All, I'd like suggestions/advice for configuring a LAN around OS/2 v1.3 now, v2.0 later. Please reply via email. A current project I'm working on involves a SLIP line, one high-speed modem at each end (Intel 9600EX?), a WD8003 Ehternet card and a seperate PC used as a router -- this is what has been suggested to me. Basically, I don't know if PPP is more efficient than SLIP, if TELENET is better, if I want something NCSA, if the OS/2 machine can also background the router functions, do I want to use FTP as much as I'd like to, how well the WD8003 card works with OS/2, if there is a more efficient LAN I can build than outlined above? You get the picture... So if you can help, please do. Scott ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Scott Sanbeg Spokane, Wa. Voice:509/535-2561 BIX: ssanbeg ssanbeg@visual.spk.wa.us (or) visual!ssanbeg@tau-ceti.isc-br.com
-----------[000311][next][prev][last][first]---------------------------------------------------- Date: 29 Aug 91 13:47:49 GMT From: bill@connection.prospect.com (Bill Poitras) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards Subject: Re: Need help selecting Ethernet cards for very high throughput rates.
In article <1991Aug29.041708.29784@unislc.uucp> martin@unislc.UUCP (Martin Cryer,D1Z01,5754) writes:
>I think you are asking too much of a timesharing O/S even with an EISA
>PC to get sustained 6Mbytes/s. If you only want it for bursts, you
>may have better luck.
Are you kidding? I have seen 100Mbytes/s when ftping a file to a PS/2
running AIX with a ESDI controller and 16 bit ethernet controller. I can
consitently get 20Mbytes/s. Hell, I can get 11Mbytes/s sometimes to a PC
running DOS. This is a ISA machine with a 16bit RLL controller. I don't
see your problem.
+-----------------+---------------------------+-----------------------------+
| Bill Poitras | Polygen Corporation | {princeton bu}!polygen!bill |
| (bill) | Waltham, MA USA | - This space for rent - |
| | FAX (617)890-8694 | bill@polygen.com |
+-----------------+---------------------------+-----------------------------+
-----------[000312][next][prev][last][first]---------------------------------------------------- Date: 29 Aug 91 13:54:35 GMT From: jjohnson@HNS.COM (Jayne Johnson) To: comp.protocols.tcp-ip Subject: IP performance evaluation
I'm evaluating the network performance of a single board computer running a single ethernet controller and TCP/IP. The board supports the Intel 82596 ethernet controller. Before I start the performance test, I thought I could ask the community if anyone has tested the CPU overhead in the IP layer for fragmenting and reassembling frames to and from the ethernet device interface. Thanks in advance for your help in this matter. I am using Wind River System's BSD4.3 tahoe release of TCP/IP. I am interested in measurements for both TCP and UDP messages. Has any other the TCP/IP founders written any papers concerning this subject? The numbers I am looking for are ballpark , does it take N millisecs/frame vs N microsecs / frame ? Jayne F. Johnson email: jjohnson@hns.com
-----------[000313][next][prev][last][first]---------------------------------------------------- Date: 29 Aug 91 14:19:02 GMT From: ajayshah@alhena.usc.edu (Ajay Shah) To: comp.protocols.tcp-ip Subject: Re: Need help selecting Ethernet cards for very high throughput rates.
In article <1991Aug29.134749.5982@ctr.columbia.edu> bill@connection.prospect.com (Bill Poitras) writes:
>Are you kidding? I have seen 100Mbytes/s when ftping a file to a PS/2
>running AIX with a ESDI controller and 16 bit ethernet controller. I can
>consitently get 20Mbytes/s. Hell, I can get 11Mbytes/s sometimes to a PC
>running DOS. This is a ISA machine with a 16bit RLL controller. I don't
>see your problem.
I thought Ethernet was hardcoded to max out at 10 million _bits_
per second. Have I been away and missed a lot of action, or is
something going wrong?
Does someone have data of FDDI performance on Suns? That should
be interesting...
--
_______________________________________________________________________________
Ajay Shah, (213)734-3930, ajayshah@usc.edu
The more things change, the more they stay insane.
_______________________________________________________________________________
-----------[000314][next][prev][last][first]---------------------------------------------------- Date: 29 Aug 91 14:42:06 GMT From: jbvb@FTP.COM (James B. Van Bokkelen) To: comp.protocols.tcp-ip Subject: Re: TCP FIN and window
...the probe time should be the same as the retransmission time, with
exponential backoff, and not 2 minutes (!). Berkeley uses a minimum of
5 seconds (as much as a 1000 times too large on an Ethernet), which makes
for pretty poor performance if you do drop a probe.
Is this the same logic that prevents them from sending a segment if the
foreign window isn't as large as their minimum segment size, even if all
outstanding data is already ack'ed? If so, there's more than one reason
to work on it...
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000315][next][prev][last][first]---------------------------------------------------- Date: 29 Aug 91 14:46:09 GMT From: dwex@cbnewsj.cb.att.com (david.e.wexelblat) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards Subject: Re: Need help selecting Ethernet cards for very high throughput rates.
In article <1991Aug29.134749.5982@ctr.columbia.edu> bill@connection.prospect.com (Bill Poitras) writes:
> In article <1991Aug29.041708.29784@unislc.uucp> martin@unislc.UUCP (Martin Cryer,D1Z01,5754) writes:
> >I think you are asking too much of a timesharing O/S even with an EISA
> >PC to get sustained 6Mbytes/s. If you only want it for bursts, you
> >may have better luck.
>
> Are you kidding? I have seen 100Mbytes/s when ftping a file to a PS/2
> running AIX with a ESDI controller and 16 bit ethernet controller. I can
> consitently get 20Mbytes/s. Hell, I can get 11Mbytes/s sometimes to a PC
> running DOS. This is a ISA machine with a 16bit RLL controller. I don't
> see your problem.
>
> +-----------------+---------------------------+-----------------------------+
> | Bill Poitras | Polygen Corporation | {princeton bu}!polygen!bill |
> | (bill) | Waltham, MA USA | - This space for rent - |
> | | FAX (617)890-8694 | bill@polygen.com |
> +-----------------+---------------------------+-----------------------------+
Am I missing something here? Isn't Ethernet a 10Mb/sec network? How,
exactly, does one one 100Mbytes/sec over a medium that only supports
10Mb/sec? Or are you using FDDI? Or maybe I have no clue?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
David Wexelblat | dwex@mtgzz.att.com | I asked her her name.
AT&T Bell Laboratories | ...!att!mtgzz!dwex | She said her name was
200 Laurel Ave - 4B-421 | | 'Maybe'
Middletown, NJ 07748 | (908) 957-5871 | --Damn Yankees
-----------[000316][next][prev][last][first]---------------------------------------------------- Date: 29 Aug 91 15:39:30 GMT From: ats@phoenix.udev.cdc.com (alex t stagg x4718) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards Subject: Re: Need help selecting Ethernet cards for very high throughput rates.
In article <1991Aug29.134749.5982@ctr.columbia.edu> bill@polygen.com (Bill Poitras) writes: >Are you kidding? I have seen 100Mbytes/s when ftping a file to a PS/2 >running AIX with a ESDI controller and 16 bit ethernet controller. I can >consitently get 20Mbytes/s. Hell, I can get 11Mbytes/s sometimes to a PC >running DOS. This is a ISA machine with a 16bit RLL controller. I don't >see your problem. Hmmm. 100Mbytes/second * 8bits/byte = 800Mbits/second. Pretty good for a 10Mbit/second media. Roll over, Einstein. Alex. ---------------------------------------------------------------- A. T. (Alex) Stagg/ARH215 | INTERNET: ats@udev.cdc.com Control Data Corporation | 4201 Lexington Ave.N. | fax: 01-612-482-2791 Arden Hills, MN USA 55126-6198 | Voice: 01-612-482-4718
-----------[000317][next][prev][last][first]---------------------------------------------------- Date: 29 Aug 91 16:15:21 GMT From: chip@osh3.OSHA.GOV (Chip Yamasaki) To: comp.protocols.tcp-ip Subject: Oops, I missed it. . .
Sorry for the extra chatter, but about three days ago I was reading a very interesting posting here in this group that must have been about a 3 weeks to a month old. This posting seemed to be explaining something about TCP-IP and/or the Internet. While I was reading it my very attentive but not very polite C News software expired the article so I couldn't get a chance to save a copy. I realize there are a huge number of "very interesting" postings here, but if anybody can guess what it could have been and where I can get a copy (or if the Author can re-post it). I would appreciate it. Please DON'T E-Mail them directly without contacting me first. I'm affraid with all of the well meaning people out there I might get hundreds of copies of a sizeable document. Thanks! -- -----------------------+--------------------------------------------------- Charles "Chip" Yamasaki| The opinions expressed here are my own and are not chip@oshcomm.osha.gov | supported or even generally accepted by OSHA. :-) -----------------------+---------------------------------------------------
-----------[000318][next][prev][last][first]---------------------------------------------------- Date: 29 Aug 91 16:39:46 GMT From: ghelmer@dsuvax.dsu.edu (Guy Helmer) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards Subject: Re: Need help selecting Ethernet cards for very high throughput rates.
In <1991Aug29.134749.5982@ctr.columbia.edu> bill@connection.prospect.com (Bill Poitras) writes: >In article <1991Aug29.041708.29784@unislc.uucp> martin@unislc.UUCP (Martin Cryer,D1Z01,5754) writes: >>I think you are asking too much of a timesharing O/S even with an EISA >>PC to get sustained 6Mbytes/s. If you only want it for bursts, you >>may have better luck. >Are you kidding? I have seen 100Mbytes/s when ftping a file to a PS/2 >running AIX with a ESDI controller and 16 bit ethernet controller. I can >consitently get 20Mbytes/s. Hell, I can get 11Mbytes/s sometimes to a PC >running DOS. This is a ISA machine with a 16bit RLL controller. I don't >see your problem. I'd be more inclined to think you're kidding, Mr. Poitras! You may have seen 100 K (KILOBYTES!) per second. If you've really seen 100Mbytes/sec doing anything on a PC over any network, there are a lot of people out here who'd like to k