|
|
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.