|
|
ARCHIVE: TCP-IP Distribution List - Archives (1987)
DOCUMENT: TCP-IP Distribution List for September 1987 (352 messages, 164442 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1987/09.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: Tue, 1-Sep-87 11:00:16 EDT From: cpw%sneezy@LANL.GOV (C. Philip Wood) To: comp.protocols.tcp-ip Subject: Help with broken TCP
What follows is a TCP scenario observed on our local ethernet. The ftp application (A) has just pushed out the last data block to (B) and is closing the connection. The first FIN from (A) is lost. An ACK from (B) for the last data block arrives. Then there begins a conversation of FIN(A) then ACK(B) with longer and longer time intervals between each set of FIN(A)/ACK(B) as if the ACK is being dropped and a retransmit timer is backing off, firing and a FIN being sent. Notice that the sequence number set in the retransmitted FIN packets is one less than that set in the lost FIN packet. Are both peers broken or just the sender of the FINs? This is a tcpdump. I added an * to indicate the lost packet. (In case your curious, the packet is lost because of an inability to handle back to back packets on the part of B) 15:31:36.86 A > B: S -1063845887:-1063845887(0) win 4096 <mss 1024> 15:31:36.86 B > A: S 253698321:253698321(0) ack -1063845886 win 384 <mss 1024> 15:31:36.86 A > B: . ack 1 win 4096 15:31:37.12 A > B: P 1:146(145) ack 1 win 4096 15:31:37.12 A >* B: F 146:146(0) ack 1 win 4096 15:31:37.38 B > A: . ack 146 win 384 15:31:39.12 A > B: F 145:145(0) ack 1 win 4096 15:31:39.14 B > A: . ack 146 win 384 15:31:41.12 A > B: F 145:145(0) ack 1 win 4096 urg 1 15:31:41.14 B > A: . ack 146 win 384 15:31:45.12 A > B: F 145:145(0) ack 1 win 4096 urg 1 15:31:45.14 B > A: . ack 146 win 384 15:31:53.12 A > B: F 145:145(0) ack 1 win 4096 urg 1 and so on... Phil Wood (cpw@lanl.gov)
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: Tue, 1-Sep-87 16:19:32 EDT From: ccruss@ucdavis.UUCP (Russ Hobby) To: comp.protocols.tcp-ip Subject: Re: Where can I find SLIP server for 4.2/3?
Here at UC Davis this summer we have been working on a project to allow
PCs to make dialup SLIP connections to the campus IP network. We are
also working on abbreviated serial line IP (ASLIP) packeting that will
make dialup IP networks more efficient.
Here is how the system works. The user logs on to the host that is
acting as the gateway, a 4.3 bsd system. He then types in the command
"slip" and he becomes a host on the network. He can then use all the
programs that come with the CMU/MIT PC/IP or Phil Karn's system. To make
connecting to the network a little easier, we have written a program
that will do the complete login automatically. The program has a user
configurable script file that specifies a sequence of strings to send
out the serial line and responses to wait for comming back. It has its
own simple language with branching depending on if the correct response
came back. The net result is that after the script has been set up, the
user types in one command on the PC to connect to the network.
Unlike some PC/IPs, our system assumes that each PC (or actually each
user) has its own, permanent IP address. Security is provided by logon
security on the gateway host. The IP address of the PC is associated
with the usercode on the gateway host. The network connection for that
PC's IP address can only be started from a user logged in with the
correct usercode. The system also makes sure that the IP address is not
already connected before making a new connection.
The way we have set up IP address for the PCs is to have a separate
subnet that contains all the PCs. This way the gateway host needs only
to advertise that it is a route to that subnet and all the PCs are
covered. In essence the gateway host is the network for all SLIP
connections on that subnet.
The abbreviated packets work on the assumption that the connecting
computer is an end-node and will not be doing any routing. In this case
many of the fields in the IP packet are unnecessary. ASLIP uses the
minimum header size based on this assumption. With ASLIP the header size
is either 8 or 4 bytes, much smaller than the standard 40 bytes. The
host that is acting as the ASLIP gateway rebuilds the outgoing packets
to legal IP packets before sending them out the network and abbreviates
the incoming packets from the network.
The login capabilities are currently working. I frequently connect my
PC at home via dialup modems( one command "netcon") and use telnet,
ftp, whois and smtp. Code for ASLIP is now being written and hopefully
will be done by the end of September. At that point we will package up
everything necessary to make it work and it will be available to anyone
that is interested.
Also there have been some terminal server vendors interested in this
project. It should not be much work to turn a terminal server into an
ASLIP or SLIP server and that would make it cheaper than using a VAX as
the gateway. Plus there would not be as much maintainance and downtime
with a simple server box.
This Fall's project is to take the best of CMU's PC/IP, Phil Karn's IP
and Stanford's PC/IP and make a PC package that has the networking
interface and services(SMTP,FTP...) running in the background. Client
software will run in foreground but will use the background interfaces
for connection to the network.
Russell Hobby
Data Communications Manager
U. C. Davis
Computing Services BITNET: RDHOBBY@UCDAVIS
Davis Ca 95616 UUCP: ...!ucbvax!ucdavis!rdhobby
(916) 752-0236 INTERNET: rdhobby@ucdavis.ucdavis.edu
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: Tue, 1-Sep-87 16:28:54 EDT From: cpw%sneezy@LANL.GOV (C. Philip Wood) To: comp.protocols.tcp-ip Subject: Re: Help with broken TCP
4.3BSD network bug (#9, tcp_output) had a fix for an undetected data loss during connection closing. This may well have fixed the data loss due to lost data segments, but, apparently it will cause the symptom I reported if the data segment with FIN is lost. If the test: if (flags & TH_FIN && tp->t_flags & TF_SENTFIN && len == 0) succeeds the #9 code decremented tp->sndnxt by one. Instead, I set tp->snd_nxt = tp->snd_una, and the symptom went away. I'm not saying this is a fix, but it may point more to the problem. Phil Wood (cpw@lanl.gov)
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: Tue, 1-Sep-87 18:04:13 EDT From: andrew@mitisft.UUCP To: comp.protocols.tcp-ip Subject: Dialup SLIP (was Re: Where can I find SLIP server for 4.2/3?)
in article <8708311459.AA25432@oswego>, beadel@oswego.UUCP (Edward F. Beadel, Jr.) says: > Does anybody know of a 4.3( or 4.2)bsd version that has been hacked > to allow dialup use? We are having "campus political problems" getting a We have had such a system running internally here at Convergent Technologies for about a year. In that time, it has run under both 4.2 and 4.3 based CTIX (Convergent's UNIX), and will soon be released with our System V.3.1 Streams / 4.3 BSD (with RFS & NFS) product. If you cannot find a non-commercial source, I can put you in touch with someone here and maybe we can get you one of the earlier mbuf-based versions. However its possible you'd have to buy it, either with hardware from us (or one of our customers) or possibly from Lachman Associates. I intend to post some more detailed experiences/queries regarding address selection and routing in this environment sometime in the near future, when I have more time to work on this project... Andrew Knutsen (408) 435-3623
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: Tue, 1-Sep-87 18:33:38 EDT From: karels%okeeffe@UCBVAX.BERKELEY.EDU.UUCP To: comp.protocols.tcp-ip Subject: Re: Help with broken TCP
Right you are! I knew that we had such a problem at one time, but didn't think it had made it out of Berkeley. Your fix is fine; our current version does: if (flags & TH_FIN && tp->t_flags & TF_SENTFIN && tp->snd_nxt == tp->snd_max) tp->snd_nxt--; which should be equivalent. Mike
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: Tue, 1-Sep-87 18:55:39 EDT From: ron@celerity.UUCP To: comp.protocols.tcp-ip Subject: Re: SUN 3.4 problems
In article <8708290110.AA13873@ucbvax.Berkeley.EDU> "Jerry Scott" <jerry@twg.arpa> writes:
>I think your problem has to do with ICMP Mask Requests from your Sun 3.4.
>In release 3.3 and 3.4, diskless suns starting asking the net for
>network masks. This is all well and good, but when you have hosts
>on your net giving you the wrong answer...
.
.
.
>
>Hope this helps, I think this was discussed earlier but your message
>shows the symptom from the sun's point of view. I hope Sun support
>is taking note of this.
>
>Jerry Scott
>
>------
Not really Sun's problem. The M68000 family uses net order already.
R. L. (Ron) McDaniels
CELERITY COMPUTING . 9692 Via Excelencia Way . San Diego, California . 92126
(619) 271-9940 . {decvax || ucbvax || ihnp4 || philabs}!sdcsvax!celerity!ron
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: 1 Sep 87 19:45:13 GMT From: barnett@im4u.utexas.edu (Lewis Barnett @ home on the range) To: tcp-ip@sri-nic.arpa Subject: Need 3Com 3C300 UE interface
I have a somewhat unusual and rather urgent request to make.
I need to find a 3Com 3C300 UE (Unibus Ethernet) interface.
This was, I believe, 3Com's first Ethernet interface, and has
the unusual feature of handling the collision backoff in
software. This made it something of a CPU hog, but it is
also uniquely suited for experimenting with data link level
protocols -- which is what I'm doing. I work with a testbed
of four machines with these interfaces, but I have recently
discovered that one of our interfaces is a pre-release version
with slightly different firmware. The difference causes the
older board to dominate the ether at high loads when it
resides on a network with the newer boards. This skews
performance results. Therefore, I need to replace this board
with one matching the hardware revision level of the other
three boards.
The details: the pre-release board is revision PCB 267-01 Rev. E 21.4;
I need a board of revision level PWA 268-01 Rev. A or later.
I understand that pre-release revision PCB 267-01 Rev. E 21.7
is identical to this revision, so I'd settle for that.
I would need to board for a maximum of six months. I am willing
to trade the early revision board in the meantime. It works fine
under normal network loads (anything under about 150% offered load)
and does significantly better than a "normal" board in higher
loads.
The firmware change: Ethernet spec says that when attempting to
transmit, an interface checks carrier sense, and if it is clear,
waits 9.6 usec. then transmits, regardless of the state of
carrier sense. The earlier board checks carrier sense *again*
after waiting and before initiating transmission. This means
that when it is stuck in an environment with boards that follow
spec., it avoids a lot of collisions that the other don't.
If you have any of these boards and would be willing to do a
temporary trade, or know of anyone who might, please contact
me by email or phone [(512) 471-9708] as quickly as possible.
Lewis Barnett,CS Dept, Taylor Hall 2.124, Univ. of Texas, Austin, TX 78712
-- barnett@im4u.UTEXAS.EDU, barnett@im4u.UUCP,
{ihnp4,harvard,seismo,gatech,ctvax}!im4u!barnett
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: Wed, 2-Sep-87 00:56:51 EDT From: enger@sccgate.scc.COM.UUCP To: comp.protocols.tcp-ip Subject: RE Need old 3Com unibus/ethernet adapter
If the firmware on the board is the only difference, why not pull the prom from a "good" board, and burn a copy. Perhaps 3Com would be willing to help? At least they should be able to tell you for sure that firmware IS or IS NOT the only difference. (and maybe they'll be willing to mail you a couple of the old proms, or cut some new ones for you, if you lend them one of the "good" boards. This may be some what idealistic, but it should be good business for the manufacturers to support their customers; perhaps especially researchers. I hope 3Com (or a competitor perhaps) comes forward to help you out. Sorry I can't, Bob
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: Wed, 2-Sep-87 10:09:14 EDT From: bdale@winfree.UUCP (Bdale Garbee) To: rec.ham-radio.packet,comp.os.minix,comp.protocols.tcp-ip Subject: New release of KA9Q Internet Package
Announcing an update to the KA9Q TCP/IP software package release of 870526.0,
bringing the current release date up to 870829.0. This update adds fixes bugs,
and adds some minor functionality. A new release will occur in a couple of
weeks with support for 4bsd and sysV unix machines, this version still supports
only the PC and PC clone class of machines.
The changes:
- Improved KISS bits for the TNC1 from Gerard, PA0GRI.
- the ASCII text at the top of one of the TNC2 hex files is gone now.
- Minor tweaks to BM from Gerard, PA0GRI, Phil KA9Q, and yours truly.
Biggest noticeable differences are that BM no longer looks at the
hosts.net file at all, but instead passes symbolic hostnames to
the smtp client in net... and we once again changed the text entry
code. It's more like bsd Mail now. Default is a silly text entry
routine, a "~e" gets you into your favorite editor, and a "~p"
shows what you've typed so far.
- NET.EXE understanding of symbolic hostnames ala the hosts.net file
has been extended. You now need to wrap numeric IP addresses in
square brackets, as in "[44.32.0.16]", as you can use symbolic names
anywhere you need to use an IP address (including in the autoexec.net
file!)
- Since BM no longer deals with IP addresses, a "gateway" command has
been added to NET.EXE, so that it knows where to send mail that
fails the lookup in hosts.net.
- Internal changes and a fix to the ftp server so that it now handles
NLST command properly, all from Phil, KA9Q. Bugs that were in the
870526.5 interim release that was only distributed in a limited
fashion apparently disappeared with the latest tweaks...
- documentation has (as usual) been updated somewhat.
- some other random tweaks I'm sure I've forgotten...
What to do once you have software, aka "getting an IP address":
Users of this software package become part of the "global IP
internet", and as such need to obtain unique IP address assignments
for each host they plan to put on the air, or "on the wire". Major
metropolitan areas in the US, and countries with active TCP-using
groups probably already have blocks of addresses in amateur radio
44.X.X.X block assigned to them. Ask around locally before you go
any further.
If there is no local address block in your area, and/or noone is
coordinating address assignments for your local net, contact Wally
Linstruth WA6JPR. Wally is the global top-level address administrator
for the ham radio 44.X.X.X subnet. Wally may be reached by email at
wally%net1.ucsd.edu@sdcsvax.ucsd.edu
or wally@net1.ucsd.edu
or ...!sdcsvax!net1!wally
or via the new forwarding mechanism I have set up for those sites who
know how to reply via mail to this message, but can't reach Wally's
machine directly:
winfree!wally -or- wally@winfree.uucp
or wally%winfree.uucp@flash.bellcore.com
How to obtain the KA9Q Internet software:
- Via uucp, the files are on winfree in tar archives as:
/usr/spool/uucppublic/pub/ka9q_all.tar.Z 16 bit Compress 4.0
/usr/spool/uucppublic/pub/ka9q_all.t12.Z 12 bit Compress 4.0
For Anonymous UUCP login, use phone number 303/593-0696, at 2400
baud (it will do 1200 if you send a return to rotate it down),
"standard Unix login sequence", username of "Uanon", password of
"notFTP". An example L.sys entry ala winfree's uucp would be:
winfree Any ACU 2400 13035930696 ogin: Uanon word: notFTP
I've never run an anonymous login for uucp before, so let me know
if I got it wrong!
A reasonable command to issue to pick up the 12-bit distribution
would be
uucp winfree!~/pub/ka9q_all.t12.Z /usr/spool/uucppublic
- ***** My BBS is currently down with a dead hard drive. If anyone
***** has a spare drive they would be willing to donate to the cause,
***** *please* get in touch with me ASAP! Cashflow around here is
***** a joke... :-( Normally,
Via Opus, log in to my BBS and download from the appropriate files
area. There are several .ARC files for the full distribution, one
for each of the directories. SeaDog file requests are ok.
I have configured my BBS to allow first time users ample resources to
download the full distribtuion at 1200 baud. The phone number is
303/593-0766.
If you have any trouble downloading from the BBS, please let me know.
Speeds that are supported include 300, 1200, and 2400.
- Via US Snail, Andy Freeborn N0CCZ has agreed to make floppy copies.
To get a copy from him, send $5 AND a completed return address mailing
label (orders without a mailing label will be considered
contributions to the BBS hard drive fund, see above... :-) to:
Andy Freeborn, N0CCZ
5222 Borrego Drive
Colorado Springs, CO 80918
USA
What you get for the $5: 5 floppies, including two of RFC's and IEN's
that relate to the code, two that include the actual release, and one
that is intended to be a sort of "plug and play" disk for getting on
the air immediately...
For those who just want the RFC/IEN disks, Andy will send you just
those two disks for $2 and a mailing label. If you want any particular
RFC or IEN, contact Andy to find out what archive it is in (we have
them all packed up, one ARC per 360k pc disk), and he will send you
that RFC or IEN, along with many others, on a floppy for $1/disk. You
can't mix and match, you get the block of documents that are in a
given archive.
DO NOT SEND floppies, mailers, postage, etc... but DO send the mailing
label!
Andy is also reachable as
winfree!andy or andy%winfree.uucp@bellcore.com
if you need more information (?). Andy is within an on-air FTP of
me, so we should be able to keep his bits up to date!
- on the ARPAnet, or attached portions of the Internet, look on
louie.udel.edu
via anonymous FTP for the files in the directory
pub/ka9q
- Within a day or two of a new release, the code should also be available
from the following additional secondary distribution points:
from Doug KD4NC in Atlanta, GA
uucp: winfree!kd4nc!dug
from Bob Hoffman N3CVL in Pittsburgh, PA
arpa: rbh@cadre.dsl.pittsburgh.edu
uucp: pitt!hoffman
from Wally Linstrugh WA6JPR in Santa Barbara, CA
arpa: wally@net1.ucsd.edu
from Brian Kantor at UCSD. (via anonymous FTP?)
arpa: tcp-group-request@sdcsvax.ucsd.edu
uucp: sdcsvax!tcp-group-request
Unreleased (read: under development) versions are often available
on louie.udel.edu, generally alongside official releases...
caveat emptor...
If anyone has any trouble getting hold of a copy of the code, please let me
know!
How to contact me:
Bdale Garbee, N3EUA
1433 Territory Trail
Colorado Springs, CO 80919
303/590-2868w, 303/593-9828h
*** go easy on the phone calls please, I'm not getting much sleep! ***
uucp: {bellcore,crash,hp-lsd,ncc,pitt,vixie}!winfree!bdale
arpa: bdale%winfree.uucp@flash.bellcore.com
bdale@net1.ucsd.edu
fido: Bdale Garbee at 128/19, 303/593-0766, 300/1200/2400 baud, 24hrs (*DOWN*)
packet: n3eua @ k0hoa
--
Bdale Garbee, N3EUA phone: 303/593-9828 h, 303/590-2868 w
uucp: {bellcore,crash,hp-lsd,ncc,pitt,usafa,vixie}!winfree!bdale
arpa: bdale%winfree.uucp@bellcore.com
fido: sysop of 128/19 packet: n3eua @ k0hoa, Colorado Springs
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Wed, 2-Sep-87 11:39:47 EDT From: minshall@OPAL.BERKELEY.EDU To: comp.protocols.tcp-ip Subject: Re: Are simultaneous TCP opens useful?
Eric,
Whether "simultaneous" opens will always succeed or randomly
fail depends on how the underlying TCP service is implemented. If
the user code needs to look like this:
{
if (connect() == FAIL) {
listen();
}
}
then there is a race condition in which both sides may hang
in listen(). Side A fails to connect, but before A issues listen, side
B tries to connect and fails.
However, if the underlying TCP service allows this:
{
connect_or_listen();
}
as a primitive, then the simultaneous case seems to me to be
guaranteed to win. Note that I don't know of any underlying services
that allow the second form.
Greg Minshall
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: Wed, 2-Sep-87 12:31:28 EDT From: asjoshi@phoenix.PRINCETON.EDU (Amit S. Joshi) To: comp.protocols.tcp-ip,comp.sources.wanted,comp.sys.ibm.pc Subject: Wanted: TCP/IP for an IBM PC/AT
Hi,
As a part of a simulator being built here I have to connect up an Iris
(running UNIX) and an IBM PC/AT running DOS 3.2. I thought of using a serial
link but it turns out to be too slow. The Iris does not have a parallel port
(and to get an optional one costs around $4k I'm told). The IBM PC/AT has got
a 3-Com board and has the MIT TCP/IP package. The Iris also has a complete
TCP/IP package. I want to use this to hook up the Iris and the AT. Now the
Iris has Socket libraries which simplify opening ports from programs. I was
looking for something similar at the AT end of the business.
I DON'T have the source to the MIT package but the binaries definitely do
not come with a socket library (or its equivalent).
Anybody know of anything out there? Preferably Public Domain, if not at a
reasonable cost. Also preference is for sources. There is a restriction :
I have only Lattice C v3 and Turbo C v1 compilers so binary libraries should
be compatible with these compilers.
Thanks.
--
Amit Joshi | BITNET : Q3696@PUCC.BITNET
| USENET : ...seismo!princeton!phoenix!asjoshi
"There's a pleasure in being mad ...which none but madmen know!" St.Dryden
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: 2 Sep 1987 1628-PDT (Wednesday) From: Glenn Trewitt <trewitt@miasma.Stanford.EDU> To: tcp-ip@sri-nic.arpa Cc: Glenn Trewitt <trewitt@miasma.Stanford.EDU> Subject: Research on large packet-switched network behavior
I am trying to find out about people who are doing or have done research related to my own. Read on if you think you might have some pointers... When not working in the various network management activities, I am supposed to be writing a thesis describing the results of my studies of the Stanford Ethernet's behavior and performance. The particular areas that I am interested in are: micro-level behavior of networks/links interarrival times packet size distribution traffic volume behavior of routers (gateways) packet delay congestion macro-level behavior of the whole internetwork traffic matrices conclusions from this data suitablility of the topology for the presented load saturation point for routers performance as load increases performance as size/complexity increases Yes, I realize that this is a lot of stuff, and I don't expect to actually cover it all, but it's a starting point. What I am interested in finding out from the people on this list is to see if there has been published research on these topics based upon Internet experience. I realize that many of these parameters (such as saturation point:-) have been determined by actual experiment in the Arpanet, but has anyone actually written about it. [I suspect that people may be too busy fending off the aligators to actually write reports, but I can hope.] Thanks in advance, Glenn Trewitt If you can't reply to miasma.Stanford.EDU, try amadeus.Stanford.EDU or shasta.Stanford.EDU.
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: 2 Sep 87 10:56:21 GMT From: bpa!sjuvax!bbanerje@burdvax.prc.unisys.com (B. Banerjee) To: tcp-ip@sri-nic.arpa Subject: Replies to "Rarp under 4.3 BSD"
Hi,
Some time ago, I posted an article enquiring as to the
availability of RARP under 4.3 BSD to this newsgroup. Several
people were kind enough to respond. In the event that you were
waiting with bated breath (unlikely!), here's what I learned.
a. 4.3 BSD doesn't support RARP, in any way shape or form.
b. Sun Unix 3.x ( Lim x->4) does support RARP. In order to
turn this on, you have to fiddle with /etc/ethers, reconfigure
the kernel to include the NIT code , and start an rarpd from
rc.local.
c. Rarp can be added to 4.3 BSD.
Now, as the prospect of writing a rarp daemon doesn't excite me,
I'm going to go with the path of least resistance -- running it
on the Sun.
If, on the other hand, you are in a similar dilemna without
recourse to a Sun; all is not lost. You can write a rarp daemon
with the aid of the 'enet' ethernet packet filter software that
was part of the ``user contributed software '' that came with 4.3
BSD. This essentially gives you access to ethernet packets that
haven't been snarfed up by IP or ICMP in the kernel. You can then
handle the 'rarp' packets yourself.
I personally believe that it makes the most sense to place the
rarp handling stuff along with the 'arp' handling stuff in the
kernel (netinet/if_ether.c). Consider the following facts:
i) The internet-address to ethernet-address mappings
already exist in the kernel.
ii) Proxy arp is supported.
Now suppose that a RARP packet is received. The code could check
it's tables to see if it was a 'published' entry, performing the
rarp service if it was. The table could be updated via 'arp -s'
as with proxy arp.
If you want to write a RARP daemon, but don't know where to
start; I recommend Doug Comer's excellent book "Internetworking
with Xinu". He has some code in there that you could almost steal
verbatim.
I would like to thank the following people for taking the time to
respond to my query; and answering questions or giving me
pointers on where to look.
bzs@bu-cs.bu.edu (Barry Shein)
karels%okeeffe@berkeley.edu (Mike Karels)
raj@purdue.edu (Raju Yavatkar)
sun!guy (Guy Harris)
milazzo@rice.edu (Paul Milazzo)
emory!tony (Tony Vincent)
matt@oddjob.uchicago.edu (Matt Crawford)
narten@purdue.edu (Thomas Narten)
sdcsvax!brian (Brian Kantor)
If you sent me mail and I haven't mentioned your name -- my apologies.
The first few letters were read, replied to and then deleted
before I realized that I would receive so many replies. Thanks again
to anyone who helped with this one.
Regards,
Binayak Banerjee
{allegra | astrovax | bpa | burdvax}!sjuvax!bbanerje
bbanerje%sjuvax.sju.edu@relay.cs.net
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: Wed, 2-Sep-87 17:06:05 EDT From: grandi@NOAO.ARIZONA.EDU (Steve Grandi) To: comp.protocols.tcp-ip Subject: A routing mystery
I have a mystery I don't understand; perhaps someone out there with more
knowledge can enlighten me.
My building Ethernet is network 192.31.165 (noao-tucson). One VAX 11/750,
noao.arizona.edu, running 4.3BSD serves as gateway between my net and the
University of Arizona net (univ-ariz, 128.196). A gateway machine on
univ-ariz, jvax.ccit.arizona.edu is linked to the Princeton Supercomputer
center (jvnc-net, 128.121.0) where a gateway machine, fuzz.csc.org,
connects to the NSFnet. Hosts on noao-tucson have default routes to
noao.arizona.edu which has a default route to jvax.ccit.arizona.edu which
has a default route to fuzz.csc.org.
noao.arizona.edu serves as a central TCP/IP mail machine for our facility;
thus I spend a lot of time watching mail queues. What I see is an almost
total inability to communicate to wiscvm.wisc.edu, the Bitnet mail gateway
(at least for a couple more months). Since the other astronomers here beat
on me to get the Bitnet mail flowing, I've been poking around and have
discovered the mystery.
From noao.arizona.edu (128.196.4.1 and 192.31.165.2), pings and telnet
attempts to wiscvm.wisc.edu fail. Yet, simultaneously, pings and telnet
connections from aquila.noao.arizona.edu (192.31.165.6) to wiscvm work
fine, even though the packets from aquila have to go through
noao.arizona.edu to reach wiscvm! Similar attempts from
jvax.ccit.arizona.edu to contact wiscvm also fail.
The only explanation I can come up with is that there is bad routing
information somewhere in the Internet for net 128.196, but good routing
information for net 192.31.165. How can I investigate this possibility?
Or am I missing something obvious?
Steve Grandi, National Optical Astronomy Observatories, Tucson AZ, 602-325-9228
UUCP: {arizona,decvax,hao,ihnp4}!noao!grandi or uunet!noao.arizona.edu!grandi
Internet: grandi@noao.arizona.edu SPAN/HEPNET: 5356::GRANDI or DRACO::GRANDI
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: Wed, 2-Sep-87 17:10:44 EDT From: kzm@ACC-SB-UNIX.ARPA.UUCP To: comp.protocols.tcp-ip Subject: Re: Are simultaneous TCP opens useful?
As Art Berggreen said in an earlier message, ACC has a product called SIMON which provides a TCP-based service for peer subscribers (as opposed to the more common Client/Server model). Several years ago when we were implementing this, we needed a scheme which avoided the race condition which Greg Minshall pointed out. So, we asked Jon Postel about the validity of using the primitive which Greg calls "connect_or_listen", which we call a "symmetric" (as opposed to passive or active) open. Jon said if we wanted to enhance our ULP interface like this, then fine. This single primitive requests an active open with an "automatic" fallback to passive if the active fails. When both subscribers use this primitive, the ability to fallback immediately eliminates the race condition. Keith.
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: Wed, 2-Sep-87 19:28:00 EDT From: trewitt@MIASMA.STANFORD.EDU.UUCP To: comp.protocols.tcp-ip Subject: Research on large packet-switched network behavior
I am trying to find out about people who are doing or have done research related to my own. Read on if you think you might have some pointers... When not working in the various network management activities, I am supposed to be writing a thesis describing the results of my studies of the Stanford Ethernet's behavior and performance. The particular areas that I am interested in are: micro-level behavior of networks/links interarrival times packet size distribution traffic volume behavior of routers (gateways) packet delay congestion macro-level behavior of the whole internetwork traffic matrices conclusions from this data suitablility of the topology for the presented load saturation point for routers performance as load increases performance as size/complexity increases Yes, I realize that this is a lot of stuff, and I don't expect to actually cover it all, but it's a starting point. What I am interested in finding out from the people on this list is to see if there has been published research on these topics based upon Internet experience. I realize that many of these parameters (such as saturation point:-) have been determined by actual experiment in the Arpanet, but has anyone actually written about it. [I suspect that people may be too busy fending off the aligators to actually write reports, but I can hope.] Thanks in advance, Glenn Trewitt If you can't reply to miasma.Stanford.EDU, try amadeus.Stanford.EDU or shasta.Stanford.EDU. -------
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: Wed, 2-Sep-87 22:01:19 EDT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: IP assigned protocol numbers
Kurt, GGP is used only by the LSI-11 core gateways, who would be sore vexed, indeed, if some host tried to horn in that protocol. Don't worry about the number (it really is 3), just destroy all references to it, wherever found. Dave
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: 3 Sep 87 01:00:00 EST From: "GBURG::ENGER" <enger%gburg.decnet@bluto.scc.com> To: "grandi" <grandi@[128.196.4.1]> Cc: tcp-ip@sri-nic.arpa,enger Subject: RE A routing mystery -- some small input
Being curious, I did some pinging from my direct net-10 host, SCCGATE.SCC.COM (10.11.0.20). It has its DEFAULT route set to PURDUE-CS-GW.ARPA. I ping successfully off of FUZZ.CSC.ORG (128.121.50.20) JVAX.CCIT.ARIZONA.EDU (128.121.50.100) JVAX.CCIT.ARIZONA.EDU (128.196.1.1) NOAO.ARIZONA.EDU (128.196.4.1) I could not raise a response from NOAO.ARIZONA.EDU (192.31.165.2) for quite some time. I made a number of attempts over a 10-15 minute period. I found this curious, as this is simply the address on the 192.31.165 network for the machine I had just heard from using the 128.196 network. Further, I had initially been unable to raise any hosts on 192.31.165, and after I started to hear from the 192.31.165 side of NOAO.ARIZONA.EDU, I also found that I could reach those back hosts, but the ping echo times were much longer than those obtained from the 128 addressed gateways/hosts. I checked my routing table. Here is what I found. destination net gateway 128.121.0 psc.psc.edu 128.196.0 psc.psc.edu 192.31.165 DCEC-MILNET-GW.ARPA It appears that I'm routing through a MILNET gateway to reach net 192.31.165. Hope this info can be of some help to you, Bob ------
-----------[000018][next][prev][last][first]----------------------------------------------------
Date: Thu, 3-Sep-87 02:00:00 EDT
From: enger%gburg.DECnet@BLUTO.SCC.COM ("GBURG::ENGER")
To: comp.protocols.tcp-ip
Subject: RE A routing mystery -- some small inputBeing curious, I did some pinging from my direct net-10 host, SCCGATE.SCC.COM (10.11.0.20). It has its DEFAULT route set to PURDUE-CS-GW.ARPA. I ping successfully off of FUZZ.CSC.ORG (128.121.50.20) JVAX.CCIT.ARIZONA.EDU (128.121.50.100) JVAX.CCIT.ARIZONA.EDU (128.196.1.1) NOAO.ARIZONA.EDU (128.196.4.1) I could not raise a response from NOAO.ARIZONA.EDU (192.31.165.2) for quite some time. I made a number of attempts over a 10-15 minute period. I found this curious, as this is simply the address on the 192.31.165 network for the machine I had just heard from using the 128.196 network. Further, I had initially been unable to raise any hosts on 192.31.165, and after I started to hear from the 192.31.165 side of NOAO.ARIZONA.EDU, I also found that I could reach those back hosts, but the ping echo times were much longer than those obtained from the 128 addressed gateways/hosts. I checked my routing table. Here is what I found. destination net gateway 128.121.0 psc.psc.edu 128.196.0 psc.psc.edu 192.31.165 DCEC-MILNET-GW.ARPA It appears that I'm routing through a MILNET gateway to reach net 192.31.165. Hope this info can be of some help to you, Bob ------
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: 2 Sep 87 23:28:54 GMT From: gatech!mcdchg!usenet@hplabs.hp.com (Yvonne Sun) To: tcp-ip@sri-nic.arpa Subject: "select" problem
Systems: 4.3 BSD UNIX, ULTRIX 1.2, Sun UNIX 4.2 Machines: VAX 750, VAX 8600, Sun 2 I have a problem in my program. In one of the routines, I use "select" on several opened sockets inside a for loop. One of the sockets(call it S) is a passive one, i.e. it is there to accept connections from other sockets. If S is selected, an "accept" will be executed, trying to accept the connection. Since "select" is used, S should be selected only when there is a pending connection request. My problem is that, after the program is executed for a while, socket S is always selected and the accept call will return unsuccessfully with the error code being 60( i.e. ETIMEOUT). After that, S will be selected again and again and accept will fail every time it is called. What troubles me is that S is selected even I haven't tried to connect to it. I am sure that I reset the input mask used in the select everytime right before select is called. Have you seen something like that before? Or do you have any idea about what causes this phenomenon? I would appreciate any opinion and suggestions. Yvonne Sun at UC Davis address: sun@iris.ucdavis.edu
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: Thu, 3-Sep-87 13:18:21 EDT From: moore@UTKCS2.CS.UTK.EDU (Keith Moore) To: comp.protocols.tcp-ip Subject: request for mailer information
[Apologies if this isn't strictly within the scope of this group] I'm looking for a better mailer! I'm tired of using the mail programs supplied with VMS and Berkeley Unix (Ultrix 1.2). I'd like something that can keep track of large numbers of old messages, with database-like searching and query capabilities. It would also be nice if it would keep messages in order, remember which messages have been replied to, follow message chains, etc. And I'm sure a sophisticated mailer would have other useful features I haven't dreamed about. So I'm soliciting information on alternative mail management programs for both VMS and Unix systems. I'm especially interested in anything that's cheap or free, and easily available. Please respond by mailing directly to me. If someone wants the results, send me mail and I'll send a summary. Keith Moore Internet: moore@utkcs2.cs.utk.edu UT Computer Science Dept. CSnet: moore@tennessee Knoxville Tennessee BITNET: moore@utkcs1
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: Thu, 3-Sep-87 17:03:48 EDT From: cam@columbia-pdn (Chris Markle acc_gnsc) To: comp.protocols.tcp-ip Subject: Multiple 331 password responses in FTP protocol
Folks, ACC distributes an MVS implementation of the Internet protocol suite called ACCES/MVS. We are in the process of adding support to interface ACCES to various MVS security packages using the MVS-provided SAF (Security Authorization Facility) interface. SAF allows an application subsystem to use a common interface to the access control facility, be that RACF, ACF2, Top Secret or Alert/MVS (and possibly others). One problem has emerged that I want to present to this group for comments and/or suggestions. Systems like RACF will expire a user's password after a certain period of time; this is quite commonly used at the average MVS site. We coded the changes in the FTP server to detect this (after USER and PASS FTP commands have been issued) and if the password is expired to prompt the Client FTP for a new (second) password. If the Client is 4.3 BSD, it assumes that the second password prompt (331 response) is really a 332 response, prompts the user for an account, and sends an ACCT FTP command in response to our 331 password prompt. It looks something like this: ACCES/MVS UNIX 220 service ready ---> <--- USER chris 331 ok; need password ---> <--- PASS chris_pswd (obtained with Client FTP password prompt) 331 expired; need new password ---> At this point, 4.3 BSD prompts the Unix FTP user for an account and if one is entered in, sends it in an FTP ACCT command. Obviously the 4.3 FTP client is not vigorously checking the reply code; the "need acct" reply code is 332 not 331. By the way, if you send the USER, PASS, and 2nd PASS with the QUOTE command, everything works properly. Now before you tell me to look at the state diagrams in the FTP spec (which show a transition to the ACCT state after receipt of a 3xx response to the PASS command) let me point out that the spec section with state diagrams states: "Here we present state diagrams for a VERY SIMPLE MINDED FTP implementation. Only the FIRST DIGIT of the reply codes is used" (Capitalization is mine) This suggests to me that the spec does not say "implement your FTP using these simple-minded state diagrams" but "here are SAMPLE state diagrams to help you understand the FTP protocol". So --- a couple of questions for you folks to ponder (and hopefully to respond to): 1) Our position is that if the FTP server sends more than one 331 response in a row, this is legitimate and Client FTP implementations should properly handle this. Do you wise folks agree? 2) If you don't agree, what brilliant ideas can you give us on how to do this? (Please don't say that we should accept the ACCT info following the 1st PASS as the 2nd PASS!?!) Please respond to me or to this group; I will summarize at the end. Thanks in advance for your advice in this matter. Chris Markle - cam@acc-sb-unix.arpa - (301)290-8100 PS - Do not try to respond to me at acc-md-unix.arpa; use acc-sb-unix.arpa which will forward to me at acc-md-unix PS - I know this isn't very exciting stuff but it is a real problem that will affect real users at real sites.
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: Thu, 3-Sep-87 17:17:18 EDT From: jmr@philabs.Philips.Com (Joanne Mannarino) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: There is a solution to my SUN 3.4 problem
Thanks for all your responses to my 3.4 problem. We have finally found a solution. The 3.4 release introduced subnetting. The way the networking software for 3.4 works is that the diskless client comes up and requests a subnet mask. It waits for a response from the server. The TCP/IP software (we're running XLAN but problems have occured with Wollongong also) responds with a subnet mask that is invalid. The diskless client is supposed to check it, determine that it is invalid, disregard it, and wait for the server to respond with the correct subnet mask. BUT with the 3.4 release, the client wasn't ignoring the invalid subnet mask so thus it would hang. SUN has provided a patch to the kernel software to take care of this. If anyone else is still having this problem, you should call SUN support and ask for the fix to bug id 1006127. This solution was sent to me by Bill Nowicki, Network Software Developer at SUN. According to him, they have a guard against this in the 3.5 release. -Joanne Mannarino -- joanne mannarino uunet!philabs!jmr philips laboratories or (914)945-6008 jmr@philabs.philips.com
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: Thu, 3-Sep-87 17:21:19 EDT From: jmr@philabs.Philips.Com (Joanne Mannarino) To: comp.protocols.tcp-ip Subject: There is a solution to my SUN 3.4 problem
Thanks for all your responses to my 3.4 problem. We have finally found a solution. The 3.4 release introduced subnetting. The way the networking software for 3.4 works is that the diskless client comes up and requests a subnet mask. It waits for a response from the server. The TCP/IP software (we're running XLAN but problems have occured with Wollongong also) responds with a subnet mask that is invalid. The diskless client is supposed to check it, determine that it is invalid, disregard it, and wait for the server to respond with the correct subnet mask. BUT with the 3.4 release, the client wasn't ignoring the invalid subnet mask so thus it would hang. SUN has provided a patch to the kernel software to take care of this. If anyone else is still having this problem, you should call SUN support and ask for the fix to bug id 1006127. This solution was sent to me by Bill Nowicki, Network Software Developer at SUN. According to him, there will be a guard against this in the 3.5 release. -Joanne Mannarino -- joanne mannarino uunet!philabs!jmr philips laboratories or (914)945-6008 jmr@philabs.philips.com
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: Thu, 3-Sep-87 17:50:25 EDT From: SATZ@MATHOM.CISCO.COM (Greg Satz) To: comp.protocols.tcp-ip Subject: Re: Replies to "Rarp under 4.3 BSD"
A rarp daemon exists for 4.3BSD using the enet packet filter. It was developed and used extensively at Stanford. The enet device code should just "drop in" to the distributed 4.3BSD system. The only major change would be to the ethernet driver to insert the hooks to pass the packet off to the enet code instead of just pitching it. If you are interested in the daemon, drop me a note and I will give you the name of people within Stanford who may be able to help. Note that I cannot provide code since I am not affiliated with Stanford. -------
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: 4 Sep 1987 07:38:48 CDT From: AFDDN.TCP-IP@GUNTER-ADAM.ARPA To: tcp-ip@SRI-NIC.ARPA Subject: Unisys 5000, Unix, and TCP/IP
Just a request for any information out there. Does anybody have any experience with internetting Unisys 5000s? These beasts run some flavor of Unix. The words filtering through the grapevine are that Unisys wrote TCP/IP, FTP, SMTP and Telnet from scratch, and that there are a few problems with it. Any comments are welcome. Darrel Beach -------
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: Fri, 4-Sep-87 08:38:48 EDT From: AFDDN.TCP-IP@GUNTER-ADAM.ARPA To: comp.protocols.tcp-ip Subject: Unisys 5000, Unix, and TCP/IP
Just a request for any information out there. Does anybody have any experience with internetting Unisys 5000s? These beasts run some flavor of Unix. The words filtering through the grapevine are that Unisys wrote TCP/IP, FTP, SMTP and Telnet from scratch, and that there are a few problems with it. Any comments are welcome. Darrel Beach -------
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: Fri, 4-Sep-87 09:54:00 EDT From: ejc@SPAM.ISTC.SRI.COM To: comp.protocols.tcp-ip Subject: Re: request for mailer information
Keith- We have been using MH and Gueuemacs as a mail handler on UNIX systems (Vaxen and Suns). The combination has most of the general features you mentioned, although I think there are still holes, especailly when dealing with large volumes of mail. Since both programs originated elsewhere, I am sure you will receive ample descriptions from others. I am interested in the results of your survey, so please send me a summary. Earl Craighill SRI International
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: Fri, 4-Sep-87 12:21:00 EDT From: NS-DDN@DDN3.ARPA To: comp.protocols.tcp-ip Subject: Re: Multiple 311 password responses in FTP protocol
Chris, you err in not carefully reading section 5.4 of RFC959. The table of replies to the PASS command (which must be "strictly adhered to") does NOT include 331. I would suggest you avoid the trap of trying to support the password change function through FTP and generate an appropriate 5xy reply to the PASS command with text from the security package. Best regards, Dave Craig Network Solutions, Inc.
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: 4 Sep 87 12:21 EDT From: NS-DDN @ DDN3.arpa To: cam @ acc-sb-unix.arpa Cc: tcp-ip @ sri-nic.arpa Subject: Re: Multiple 311 password responses in FTP protocol
Chris, you err in not carefully reading section 5.4 of RFC959. The table of replies to the PASS command (which must be "strictly adhered to") does NOT include 331. I would suggest you avoid the trap of trying to support the password change function through FTP and generate an appropriate 5xy reply to the PASS command with text from the security package. Best regards, Dave Craig Network Solutions, Inc.
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: Fri, 4-Sep-87 12:34:21 EDT From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) To: comp.protocols.tcp-ip Subject: Re: Multiple 331 password responses in FTP protocol
UNIX uses the simple minded approach. Only the first digit is checked. (This is for infomration). I think ACCESS/MVS is doing the wrong thing. The reply strings are supposed to be informative only, the client is supposed to be able to make it's decisions based on the numbers alone. The only defined acceptable replies in the spec are 3XX meaning send account, 2XX Success, and 5XX error. Doing anything else is just asking for trouble. The last two digits are there to provide a finer differentiation of the error, but not to change the flow of control. Beyond that conceptual problem, if I understand what is going on here, you're second password string actually changes the password? This is a horrendous security problem and really ought not to be done in FTP. Better to just return an error (EXPIRED PASSWORD) and leave the user to correct the situation through other channels. -Ron
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: Fri, 4-Sep-87 12:39:22 EDT From: mo@maximo.UUCP (Mike O'Dell) To: comp.protocols.tcp-ip Subject: Unisys 5000
I think that is the Arete box remarketed by Unisys. If so, they use an Excelan 201 board for the TCP-IP support. This code is derived from the 4.1a TCP code, but has had some bugs fixed and some features added. As to which ones, however, ask Unisys, Arete, and possibly Excelan. -Mike
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: 4 Sep 1987 18:01-PDT From: STJOHNS@SRI-NIC.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Multiple 331 passwd responses in FTP protocol
No, no, no!!! DO NOT extend the meaning of the USER command or for that matter that of the PASS command. They have very specific meanings. Instead, create your own extension commands "XCPW" and "XGRP". These can be specified via the "quote" command that is supposed to be part of all FTP implementations. This is within the scope of the standard. Please, be sensible - standards are there for a reason, interoperability. Mike
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: 4 Sep 87 12:51:32 GMT From: mtune!codas!ablnc!gil@RUTGERS.EDU (Gil Widdowson) To: tcp-ip@sri-nic.arpa Subject: HELP: select() under sockets
I am trying to modify an application to use select(3w) to manage
incoming data. I am working on 3B2s, 3B20s, and UTS using sockets
under Wollongong's/AT&T's TCP/IP over Ethernet. 3Bs are running
TCP release 1.1. Anyway, it does not seem to work at all. So I set
up a little client/server model where the server uses select() to
determine when the client has sent it data on an established virtual circuit.
When I use block mode, it pends forever, though if I break out using sbd(1),
data is there. If I use timed polling mode, it always returns
zero forever. Is it me or our sockets service??
code fragment
...
set up connection on file descriptor nfd
/*
***********************************************
** Select test code
** if timed_select FALSE
** pend until our fd is ready for readying
** else
** do polling once a second
** until our fd is ready for readying
***********************************************
*/
readfds = (1<<nfd); writefds = 0; eventfds = 0; numfds = 1;
if (timed_select == 0) {
numfds = select(numfds, &readfds, &writefds, &eventfds, 0);
if (numfds == -1) {
perror("select() error");
exit(1);
}
fprintf(stderr, "numfds = %d and readfds = %X\n",numfds, readfds);
}
else {
int sav_readfds; int sav_numfds;
sav_readfds = readfds;
sav_numfds = numfds;
nodata = 1;
while (nodata) {
readfds = sav_readfds;
numfds = sav_numfds;
numfds=select(numfds, &readfds, &writefds, &eventfds, &timeout);
if (numfds == -1) {
perror("select() error");
exit(1);
}
else {
if (numfds == 0) { continue; }
else { nodata = 0; }
}
}
}
Do recv() of data.
...
Please send any/all humiliating/enlightening responses via email.
thanks,
Gil Widdowson AT&T DP&CT Maitland FL
{allegra,amdahl,clyde,codas,cuae2,garage,houxm,ihnp4,mtune,research}!abfli!gil
(305) 660-6123 (8-754)
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: Fri, 4-Sep-87 16:59:07 EDT From: cam@columbia-pdn (Chris Markle acc_gnsc) To: comp.protocols.tcp-ip Subject: Re: Multiple 331 passwd responses in FTP protocol
Folks,
A number of people have quickly pointed out to me that section 5.4
"Sequencing of Commands and Replies" in RFC 959 specifically states the
responses that are valid after a PASS command, and guess what, 331 is
not one of them.
So, if the password specified on the PASS command has expired we will do the
following:
1) send a "530 passwd expired; retry with passwd/newpasswd"
2) extend the syntax for the PASS text to allow specification of a new passwd
PASS passwd[/newpasswd] [GROUP(xxx)]
(GROUP is another piece of user id the user may want to specify in a usual
MVS security environment)
3) while we're at it, extend the syntax of the USER command also
USER userid[/passwd[/newpasswd]] [GROUP(xxx)]
This will screw up 4.x users who use .netrc files to allow auto-login
when 4.x client FTP connects to a remote host, in the case where the passwd
has expired, but that's life in the big (BLUE) city!
Chris Markle - cam@acc-sb-unix.arpa - (301)290-8100
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: Fri, 4-Sep-87 20:14:22 EDT From: bdale@winfree.UUCP (Bdale Garbee) To: rec.ham-radio.packet,comp.os.minix,comp.protocols.tcp-ip Subject: winfree anonymous uucp fixed
To those who have unsuccessfully tried to uucp the KA9Q Internet Package
from uucp host winfree as per the information in the release posting...
I have fixed the problem that caused requests from unknown hosts to fail.
Two sites have gotten the bits this afternoon, so I think it's fixed. If
you tried before and it bombed, try again now with the same login info!
--
Bdale Garbee, N3EUA phone: 303/593-9828 h, 303/590-2868 w
uucp: {bellcore,crash,hp-lsd,ncc,pitt,usafa,vixie}!winfree!bdale
arpa: bdale%winfree.uucp@bellcore.com
fido: sysop of 128/19 packet: n3eua @ k0hoa, Colorado Springs
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: Fri, 4-Sep-87 20:54:54 EDT From: ROODE@BIONET-20.ARPA (David Roode) To: comp.protocols.tcp-ip Subject: Re: request for mailer information
I think you are refering to a mail user agent rather than a mailer. A mailer is usually the delivery agent and the interface to the transports used. I too would like to see a better mail program. However, perhaps you would find the MM program available for Unix and VMS which is derived on the version for TOPS-20 to be superior to what you are using. I suggest contacting Kashtan@IU.AI.SRI.COM for more information. -------
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: Fri, 4-Sep-87 21:01:00 EDT From: STJOHNS@SRI-NIC.ARPA To: comp.protocols.tcp-ip Subject: Re: Multiple 331 passwd responses in FTP protocol
No, no, no!!! DO NOT extend the meaning of the USER command or for that matter that of the PASS command. They have very specific meanings. Instead, create your own extension commands "XCPW" and "XGRP". These can be specified via the "quote" command that is supposed to be part of all FTP implementations. This is within the scope of the standard. Please, be sensible - standards are there for a reason, interoperability. Mike
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: Sat, 5-Sep-87 00:27:52 EDT From: mkhaw@teknowledge-vaxc.ARPA (Mike Khaw) To: comp.protocols.tcp-ip Subject: Re: request for mailer information
> perhaps you would find the MM program available for Unix and VMS
> which is derived on the version for TOPS-20 to be superior
> to what you are using. I suggest contacting Kashtan@IU.AI.SRI.COM
> for more information.
TOPS20 MM is a fine program in its environment. Unix MM doesn't feel
like Unix: it feels like a little TOPS20 island plopped into the midst
of Unix. You may consider that a plus. I don't.
It uses its own format for mail files, different from what Unix mail
uses, so I haven't found a way to make it read Unix mail files. (It reads
incoming mail into ~/mail.txt, making alterations to suit its format in
the process.) MM also seems to think that "/" is a TOPS20 switch
metacharacter or some such, so it doesn't understand Unix pathnames. The
built-in help uses TOPS20 terminology to the extent of referring to
documentation files in TOPS20 syntax (e.g., DOC:<FOO>BAR.DOC;1).
Mike Khaw
--
internet: mkhaw@teknowledge-vaxc.arpa
usenet: {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge-vaxc.arpa
USnail: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: Sat, 5-Sep-87 15:36:46 EDT From: LYNCH@A.ISI.EDU (Dan Lynch) To: comp.protocols.tcp-ip Subject: Re: Multiple 331 password responses in FTP protocol
From my reading of this topic I could not tel if the password was being changed on a high frequency basis (like hourly) or on a low frequency basis (like monthly). If monthly, then returning an error is probably fine, but if it is hourly (or less) then something has to change so the user does not get completely frustrated. What are the facts? Dan -------
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: 5 Sep 1987 15:36:46 EDT From: Dan Lynch <LYNCH@A.ISI.EDU> To: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) Cc: tcp-ip@SRI-NIC.ARPA, LYNCH@A.ISI.EDU Subject: Re: Multiple 331 password responses in FTP protocol
From my reading of this topic I could not tel if the password was being changed on a high frequency basis (like hourly) or on a low frequency basis (like monthly). If monthly, then returning an error is probably fine, but if it is hourly (or less) then something has to change so the user does not get completely frustrated. What are the facts? Dan -------
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: Sun, 6-Sep-87 00:02:46 EDT From: sun%iris@ucdavis.UUCP (Yvonne Sun) To: comp.protocols.tcp-ip Subject: problem on "select()"
Systems: 4.3 BSD UNIX, ULTRIX 1.2, Sun UNIX 4.2 Machines: VAX 750, VAX 8600, Sun 2 I have a problem in my program. In one of the routines, I use "select" on several opened(including tcp and upd sockets) sockets and a pseudo- terminal device inside a for loop. One of the sockets(call it S) is a passive one, i.e. it is there to accept connections from other tcp sockets. If S is selected, an "accept" will be executed, trying to accept the connection. Since "select" is used, S should be selected only when there is a pending connection request. My problem is that, after the program is executed for a while, socket S is always selected and the accept call will return unsuccessfully with the error code being 60( i.e. ETIMEOUT). After that, S will be selected again and again and accept will fail every time it is called. What troubles me is that S is selected even I haven't tried to connect to it. I am sure that I reset the input mask used in the select everytime right before select is called. Have you seen something like that before? Or do you have any idea about what causes this phenomenon? I would appreciate any opinion and suggestions. Yvonne Sun at UC Davis address: sun@iris.ucdavis.edu
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: Sun, 6-Sep-87 12:18:54 EDT From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) To: comp.protocols.tcp-ip Subject: Re: HELP: select() under sockets
The definition of the first argument to the socket is the maximum file descriptor that can be specified in any of the other fields. You set it to one (presumably because you are assuming the value was supposed to be the number of things selecting on). Setting this value to one means that you can only select on file descriptor 0. Set the value to something larger like the maximum number of file descriptors (NFILE). -ROn
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: Mon, 7-Sep-87 07:38:07 EDT From: murayama@CS.UCL.AC.UK (Yuko Murayama) To: comp.protocols.tcp-ip Subject: ISO8473 vs. IP
Could anyone let me know about the difference between ISO 8473 (protocol for providing the connectionless-mode network service) and the DARPA IP? Yuko Murayama a Ph.D. student Dept of Computer Science University College London
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: Mon, 7-Sep-87 08:54:00 EDT From: NS-DDN@DDN3.ARPA To: comp.protocols.tcp-ip Subject: Re: ACC's FTP Protocol Modification Proposal
Mike, by "quote", don't you mean a command at the topmost UI layer, not the PI layer which the RFC lays down the law for? The RFC provides the "SITE" command for local vagarities. Since I see nothing in the RFC which would preclude the SITE command before the USER command, I should think that would be the way for ACC to go with this interoperable difficulty. However, I am in total agreement with your strong statement on the bending of command syntax. Chris, I would think again about supporting this type of service. Although the FTP protocol is intentionally designed for interactive use by the owner of the password, the world is obviously moving toward unattended file transfer (and other traditionally interactive tasks). The better approach is to insist that the security system merely request the user to change his password and continue to accept the existing password until the human being explicitly changes it. Note that if several batch FTPs are queued and the first one changes the password, the remaining FTPs will fail... Best regards, Dave Craig Network Solutions, Inc.
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: 7 Sep 87 08:54 EDT From: NS-DDN @ DDN3.arpa To: STJOHNS @ SRI-NIC.ARPA, cam @ ACC-SB-UNIX.ARPA Cc: tcp-ip @ SRI-NIC.ARPA Subject: Re: ACC's FTP Protocol Modification Proposal
Mike, by "quote", don't you mean a command at the topmost UI layer, not the PI layer which the RFC lays down the law for? The RFC provides the "SITE" command for local vagarities. Since I see nothing in the RFC which would preclude the SITE command before the USER command, I should think that would be the way for ACC to go with this interoperable difficulty. However, I am in total agreement with your strong statement on the bending of command syntax. Chris, I would think again about supporting this type of service. Although the FTP protocol is intentionally designed for interactive use by the owner of the password, the world is obviously moving toward unattended file transfer (and other traditionally interactive tasks). The better approach is to insist that the security system merely request the user to change his password and continue to accept the existing password until the human being explicitly changes it. Note that if several batch FTPs are queued and the first one changes the password, the remaining FTPs will fail... Best regards, Dave Craig Network Solutions, Inc.
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: Mon, 7-Sep-87 14:44:56 EDT From: ks@a.cs.okstate.edu (Kurt F. Sauer) To: comp.protocols.tcp-ip Subject: Re: Multiple 331 password responses in FTP protocol
In article <8709041634.AA11908@topaz.rutgers.edu>, Ron Natalie writes: >Beyond that conceptual problem, if I understand what is going on here, >you're second password string actually changes the password? This is >a horrendous security problem and really ought not to be done in FTP. >Better to just return an error (EXPIRED PASSWORD) and leave the user >to correct the situation through other channels. I absolutely concur. Implementations of FTP were designed to perform file transfers, not the changing of authenticators used in login situations. This leaves one with a situation where subversion of local software (not normally regarded as a trusted implementation) would render distant-end protection useless. I suggest you think this design issue out with a security engineer, and I suspect that the median solution will probably be something like Ron's suggestion above. We would never allow user programs to control foreign host access; this is somewhat akin to doing just that. A couple of guidelines which might be helpful from a more generic stand- point: [PassMgtGuide85] 4.2.2.3 [Password] Change Procedure ...If the change is necesary due to an expired password, the user should be so informed. The user should be pre- sented with a brief summary of the major steps in changing a password, including a caution that the user should ensure that no one else is watching what the user is doing. ... The user should then enter the new password twice so the procedure can verify that the user can con- sistently enter the password correctly. The new password should be obliterated by techniques such as overprinting or terminal screen erasing. ... While it is true that many (tho not all!) UNIX implementations include a passwd program that gives instructions, some do. The more important con- sideration is immediate: Few FTP implementations here (none?) keep the value supplied for ACCT from being displayed. Further, it's true that several implementations of FTP don't even protect the PASS value when it's entered (unlike 4.3bsd UNIX implementations)! 4.3.2 [Password] Entry ... It is recommended that the system not echo pass- words that users type in. When the system cannot pre- vent a password from being echoed ..., it is recommen- ded that a random overprint mask be printed before or after the password is entered, as appropriate, to con- ceal the typed password. The complete password as entered by the user should be an exact match, character for character, with the user's current password. And, of course, using the ACCT feature won't allow for retyping the password for correctness, which is a big "lose." Think this out again and let us know what you decide. Kurt F. Sauer Tulsa, OK ---------- References: [PassMgtGuide85] National Computer Security Center, _ D_ e_ p_ a_ r_ t_ m_ e_ n_ t_ _ o_ f_ _ D_ e_ f_ e_ n_ s_ e _ P_ a_ s_ s_ w_ o_ r_ d_ _ M_ a_ n_ a_ g_ e_ m_ e_ n_ t_ _ G_ u_ i_ d_ e_ l_ i_ n_ e, Report CSC-STD-002-85 (Fort George G. Meade, MD: NCSC), April 1985.
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: Mon, 7-Sep-87 15:17:18 EDT From: hubcap@hubcap.UUCP (Mike S Marshall) To: comp.protocols.tcp-ip Subject: CMU/tektronix tcp/ip software...
greetings... The answer to my question has been posted before, but alas, I didn't care then :-). Who can I contact to get the CMU/tek tcp/ip sofware... Can I run it in shared deqna mode on a microvax? Is it really a good, well documented product? thanks -Mike Marshall hubcap@hubcap.clemson.edu ...!hubcap!hubcap
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: Mon, 7 Sep 87 12:21:51 GMT-0:00 From: Yuko Murayama <murayama@Cs.Ucl.AC.UK> To: iso@nrtc.northrop.com, tcp-ip@sri-nic.arpa Cc: murayama@Cs.Ucl.AC.UK Subject: ISO8473 vs. IP
Could anyone let me know about the difference between ISO 8473 (protocol for providing the connectionless-mode network service) and the DARPA IP? Yuko Murayama a Ph.D. student Dept of Computer Science University College London
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: Tue, 8-Sep-87 05:05:00 EDT From: GBELING@A.ISI.EDU To: comp.protocols.tcp-ip Subject: unbix or rmx
hello,
can anyone help me answer the following questions:
a) how small can an unix-system be made which should run on an 80286
processor ( from intel) ?
b) when using rmx (from intel) as operating system instead
are ther the protocols telnet/tcp/ip available somewhere ?
thanks gerd beling west-germany
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: Tue, 8-Sep-87 09:06:22 EDT From: tsuchiya@GATEWAY.MITRE.ORG (Paul Tsuchiya) To: comp.protocols.tcp-ip Subject: Re: ISO8473 vs. IP
The simple reply is that they are very similar functionally, but different in terms of header format and all that. I would be hard pressed to say what the important differences were since that depends on ones priorities. However, the ISO8473 address is much bigger (up to 20 bytes vs. 4 for DoD IP). I like the partial source routing of ISO8473 because I am involved in routing. However, that feature can bite you if you are not careful, and I wouldn't be surprized if it never gets widely implemented. If one consideres ICMP to part and parcel of DoD IP, then there are a couple more differences. ICMP has the Echo function, which ISO8473 does not, and has the Redirect. However, ISO9542 (the ES-IS routing protocol for use with ISO8473) has the redirect function, so its tit for tat. I will be interested to see what others perceive as the major differences between the two. I have never sat down and made a blow by blow comparison. Paul Tsuchiya tsuchiya@gateway.mitre.org The MITRE Corp. tsuchiya@mitre-gateway.arpa
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: Tue, 8-Sep-87 10:01:00 EDT From: jim@b-mrda To: comp.protocols.tcp-ip Subject: TCP/IP and Unix file servers
does anyone know of a unix file server for pc's that uses the intelligent ethernet cards, as intelligent cards, with TCP/IP protocols and msnet support ? Or am I asking for to much ??? jim sadler 206-575-7125 hpubvwa!b-mrda!jim P.O. Box 3707 ms 9C-38 Seattle, Wa. USA 98124 Any opinions expressed are mine and mine only and not that of my employer. Also add in whatever else should be said at this point.
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: Tue, 8-Sep-87 11:49:00 EDT From: berger@datacube.UUCP To: comp.protocols.tcp-ip Subject: Terminal Server Questions?
Looking for recommendations and suggestions on a Ethernet - TCP/IP
Serial port sever. These are the gadets that concentrate and connect
several RS-232 ports to a TCP/IP ethernet backbone. We have a
network of Sun's, Pyramid, generic 68020 Unix and OS-9 systems as
well as PC's on our network. We have run out of genric serial ports
and are looking at this as a mechanism to distribute serial ports
around the company.
We have an immediate need for additional ports, but we are thinking
that for the mondo growth we are experiencing that we will
standardize on using these concentrators for connecting serial ports
to various Unix boxes. Is this a good idea? The serial port traffic
is primairly terminals but a chunk of the traffic is high speed
binary download modules.
We are looking at the Encore Annex, the Cisco ASM Communications
Server and the Micom Ethernet Terminal Server. Are there others out
there worth looking at? Are there known good/bad things about the
above devices? I'm looking for tips, hints and experiences. Please
send via E-Mail and I will synopsize to the net.
Bob Berger
Datacube Inc. Systems / Software Group 4 Dearborn Rd. Peabody, Ma 01960
VOICE: 617-535-6644; FAX: (617) 535-5643; TWX: (710) 347-0125
UUCP: berger@datacube.COM, ihnp4!datacube!berger
{seismo,cbosgd,cuae2,mit-eddie}!mirror!datacube!berger
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: Tue, 8-Sep-87 12:02:20 EDT From: bhanji@GATEWAY.MITRE.ORG To: comp.protocols.tcp-ip Subject: Re: ISO8473 vs. IP
Date: Mon, 7 Sep 87 12:21:51 GMT-0:00 From: Yuko Murayama <murayama@Cs.Ucl.AC.UK> Could anyone let me know about the difference between ISO 8473 (protocol for providing the connectionless-mode network service) and the DARPA IP? Yuko Murayama a Ph.D. student Dept of Computer Science University College London A document put out by the National Research Council in 1985 briefly describes the differences between the DoD IP and ISO IP pp 18-24. The report is mostly dedicated to the comparison between TCP and TP4 but has a small section on the two IP comparison. "Transport Protocols for Department of Defense Data Networks", Report to the Department of Defense and the Bureau of Standards. Committee on Computer-Computer Communication Protocols, Board on Telecommunications and Computer Applications, Commission on Engineering and Technical Systems, National Research Council. NATIONAL ACADEMY PRESS, Washington, D.C. February 1985. Hope this is helpful. Shiraz Bhanji.
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: Tue, 8-Sep-87 12:04:45 EDT From: zeeff@b-tech.UUCP (Jon Zeeff) To: comp.protocols.tcp-ip Subject: Re: Where can I find SLIP server for 4.2/3?
In article <8708300436.AA03739@beno.CSS.GOV> rick@SEISMO.CSS.GOV (Rick Adams) writes: > >Note: SLIP is ONLY a device driver. You have to come up with >your own IP, TCP, ICMP, ETC > So it seems that to use 4.xbsd machine as a slip server (ie. I want a 4.x machine to talk to a PC via slip, giving a PC network access), there would be some simple software needed to pass packets from the slip driver to the regular ip driver. Has anyone written such software? >To answer the other popular question, no there is no RFC describing the >"protocol" (I hesitate to call it a protocol. Its a simple framing >scheme.) Perhaps there is some other documentation of the framing scheme? -- Jon Zeeff Branch Technology, uunet!umix!b-tech!zeeff zeeff%b-tech.uucp@umix.cc.umich.edu
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: Tue, 8-Sep-87 12:37:55 EDT From: hagens@JANEB.WISC.EDU (Robert Hagens) To: comp.protocols.tcp-ip Subject: Re: ISO8473 vs. IP
Comparison of DoD IP and ISO IP: As Paul pointed out, functionally the same. Here are some other differences: - No upper layer protocol ID in ISO8473. - Headers in ISO8473 can be 255 octets (vs. 60 for DoD IP). - Support of header parameters is optional in ISO8473, mandatory in DoD IP. - Time to live in ISO8473 is 1/2 sec as opposed to 1 sec for DoD IP. (It will still end up being used as a hop count.) - No timestamp parameter in ISO8473. - Fixed part of ISO8473 header has odd byte aligned, 2 byte fields. - DoD IP fragmentation is called segmentation in ISO. Identical function, however all ISO8473 optional parameters are carried with fragment. (Called a derived PDU). Only in ISO8473: - Error Report PDU. Sent when a data PDU is discarded. Almost identical to data pdu except it contains the reason for discard. Data of error report PDU is header of discarded PDU. Error report contains ICMP functionality of destination unreachable, ttl expired and parameter problem. - 'congestion experienced'. Set by a router, when a router experiences congestion. The two biggest differences I see are the address part and lack of upper layer proto id. Rob Hagens UW Madison Computer Science
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: Tue, 8-Sep-87 12:38:45 EDT From: jgh@root.co.uk (Jeremy G Harris) To: comp.protocols.tcp-ip,comp.unix.wizards,comp.bugs.4bsd Subject: IP options
Are there any known problems in the 4.3 code dealing with IP options?
I can't understand it....
Specifically, in routine ip_dooptoptions, file ip_input.c:
1) Strict source route with record
appears to record an address for the receiving
interface rather than the transmitting one.
2) Record route
appears to route the datagram based on a garbage address,
bouncing an ICMP "source route failed" if this fails or
recording an address for the bogus transmitting interface
if it succeeds.
Are these bugs or have I missed something?
Has anybody fixed them?
Does anybody use IP options anyway?
Do I have an out-of-date RFC?
Thanks in antici... . . . pation,
Jeremy
Reference: RFC 791: IP protocol spec. Sept '81 pp. 20,21
"... address as known in the environment into which
this datagram is being forwarded"
(identical wording in two places)
--
Jeremy Harris jgh@root.co.uk
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: Tue, 8-Sep-87 13:02:44 EDT From: geof@apolling.UUCP (Geof Cooper) To: comp.protocols.tcp-ip Subject: Re: Re: HELP: select() under sockets
> The definition of the first argument to the socket is the maximum file
> descriptor that can be specified in any of the other fields. You set
> it to one (presumably because you are assuming the value was supposed to
> be the number of things selecting on). Setting this value to one means
> that you can only select on file descriptor 0. Set the value to something
> larger like the maximum number of file descriptors (NFILE).
Umm, I just looked into /usr/include/stdio.h on our apollo system:
Changelog entry:
10/01/82 jrw increased _NFILE from 20 to 128.....
So using NFILE is probably NOT the way to go, unless you declare
readfds, et al as arrays (this leads one to wonder, of course, why
the existing apollo software works at all -- since I know of no code
that actually uses arrays with select. Probably because no one actually
opens more than 32 file descriptors and only THEN creates a socket...).
In a separate note to Mr. Widdowson, I suggested:
min( 8 * (sizeof readfds), NFILE )
so that the argument really does reflect the size of the data
being passed to it. Actually,
8 * (sizeof readfds)
is probably sufficient, since you will never actually turn on
a bit that is beyond NFILE (hmmm... maybe little-endian vs
big-endian affects things... comments?).
Unfortunately, this is non-portable, since the size of a char is
not necessarily 8 bits. But I suspect that all network software
would break if char != octet.
- Geof
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: Tue, 8-Sep-87 14:02:13 EDT From: tsuchiya@GATEWAY.MITRE.ORG (Paul Tsuchiya) To: comp.protocols.tcp-ip Subject: Re: ISO8473 vs. IP
> > Comparison of DoD IP and ISO IP: > > As Paul pointed out, functionally the same. Here are some other differences: > > - No upper layer protocol ID in ISO8473................... > > The two biggest differences I see are the address part and lack of > upper layer proto id. > > Rob Hagens > UW Madison Computer Science > This is not to say that ISO8473 cannot distinguish between upper layer protocols. The address in ISO8473 is used to do the distinguishing (the address is called the Network Service Access Point Address, which defines the boundary between the transport thing and the network thing. I don't want to get into what "thing" is). Practically speaking, one reserves a byte (sorry, octet) in the NSAP address, usually called the NSAP selector, to do the job of the protocol id field in DoD IP. Boils down to the same thing as far as I can tell. (I'm wondering if it is kosher to use the NSAP selector byte to distinguish between different transport classes (TP0, TP1, ...., TP4). Something tells me it isn't, but I don't see how someone could stop you. I'll have to bring that up at the next 3.3 meeting). Paul Tsuchiya tsuchiya@gateway.mitre.org The MITRE Corp. tsuchiya@mitre-gateway.arpa
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: Tue, 8-Sep-87 14:38:21 EDT From: tsuchiya@gateway.mitre.ORG (Paul Tsuchiya) To: comp.protocols.tcp-ip Subject: Re: ISO8473 vs. IP
> From: "Marty Schoffstall" <schoff@nic.nyser.net> > Status: R > > > - 'congestion experienced'. Set by a router, when a router > experiences congestion. > > The infamous "DEC Bit", which reports to the recipient of the packet > that there is congestion. This bit has debatable merit, would the > two camps like to expound? > > Marty Ok, I'll bite. The DEC bit is used, at least in DECNET (phase 4 or 5, I don't know) to control the transport window such that the network doesn't get congested. It is a "congestion avoidance" mechanism. As far as I know, the algorithm assumes it knows the round trip time. I don't know if DEC measures this or assumes a value. (I understand the problems associated with trying to measure it.) The algorithm seems to be a good one, and works as long as all of the parts are there and everyone participates. (Please, someone from DEC correct me if I have this screwed up). DEC has released there algorithm for doing this (until recently, it was proprietary). In their IS-IS routing proposal, they have said when to set the bit. I am not sure how or if they intend to standardize the part that tells the transport machine what to do. I suppose this could be done right in ISO, or in one of the profile organizations like COS. Tsuchiya PS. We may be in two camps, but lets face it: if it rains, all of our campfires are going to go out.
-----------[000060][next][prev][last][first]----------------------------------------------------
Date: Tue, 8-Sep-87 14:42:52 EDT
From: schoff@NIC.NYSER.NET ("Marty Schoffstall")
To: comp.protocols.tcp-ip
Subject: Re: ISO8473 vs. IP
- 'congestion experienced'. Set by a router, when a router
experiences congestion.
The infamous "DEC Bit", which reports to the recipient of the packet
that there is congestion. This bit has debatable merit, would the
two camps like to expound?
Marty
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: Tue, 8-Sep-87 14:57:55 EDT From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) To: comp.protocols.tcp-ip Subject: Re: unbix or rmx
I know of no RMX TCP/IP implemenations. However, the XENIX (UNIX) for the 286 doesn't really have TCP/IP either. You can buy inteligent protocol cards from a company like CMC (they have the software for XENIX) to talk to the Ethernet with TCP/IP. You ought to be able to write a RMX interface for this if you know enough about RMX. As for how small XENIX can get? I'm not sure. I only had a single memory card in my 310 but I have no idea how much was on it (a meg?). As for disk space, a minimal system comes on a single floppy disk so that you can load in the rest of the baseline system which comes on around 20 360K floppies. This means that the baseline system takes up less than 7 MEG, but you could probably reduce that even smaller by throwing away things like /usr/dict/words and other large systems that aren't used. UNIX also needs somewhere to swap but you can probably get by with a few meg for this. -Ron
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: Tue, 8-Sep-87 15:45:26 EDT From: zben@umd5.umd.edu (Ben Cranston) To: comp.protocols.tcp-ip Subject: Re: HELP: select() under sockets
In article <8709061618.AA14584@topaz.rutgers.edu> ron@TOPAZ.RUTGERS.EDU (Ron Natalie) writes:
> The definition of the first argument to the socket is the maximum file
> descriptor that can be specified in any of the other fields. You set
> it to one ... Set the value to something
> larger like the maximum number of file descriptors (NFILE).
(Hiya Ron!) People have been talking about setting NFILE bigger than 32,
so I think it is worth mentioning that the first argument to select is used
to tell it the width of the bitmaps in the succeeding arguments. So if they
are INTs you probably want to set it to 32. Of course, if your system DOES
have NFILE set bigger than 32 and you happen to get a FD with a higher number,
that (1<<nfd) suddenly turns into a zero and the code no longer does what
one thought it would... So waddya want to do?
if (nfd>31)
diehorribly("fix this mess")
else {
num = select( 32 , (1<<nfd) , ...)
}
or what? Idunno...
--
Copyright 1987 Ben Cranston (you may redistribute ONLY if your recipients can).
umd5.UUCP <= {seismo!mimsy,ihnp4!rlgvax}!cvl!umd5!zben
zben @ umd2.UMD.EDU Kingdom of Merryland UniSys 1100/92
umd2.BITNET "via HASP with RSCS"
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: Tue, 8-Sep-87 17:16:40 EDT From: rcallon@PARK-STREET.BBN.COM (Ross Callon) To: comp.protocols.tcp-ip Subject: re: ISO8473 versus (DARPA) IP
Yuko;
I think we need more experience in actually using the ISO IP before we say
which differences are the most important, but here are a few that come to mind.
I hope this is a useful start.
If you are doing a study of the differences between the DARPA IP and the ISO
IP, or looking at implementation issues with the ISO IP, I would be very
interested in seeing any result which you may come up with.
(1) As Paul mentioned, the ISO uses variable length addresses up to
20 octets, while the DOD uses fixed length 4 octet addresses. The
ISO addresses are much more flexible. For example, they may be used
to explicitly encode something like an "autonomous system" number,
and/or the IEEE 802 link address.
I think that the difference in addresses make the ISO IP more appropriate
for worldwide use with potentially hundreds of thousands of networks, but
make it more costly to run (bigger headers and more processing).
(2) The IPs use different checksums. The ISO checksum is computationally
more costly, but has a higher probability of detecting errors in which
only a small number of bits are changed (i.e., random bit errors as
opposed to burst errors). In addition, the ISO checksum can be "turned
off" by using all zeroes in the checksum field.
(3) The ISO IP doesn't have a source quench. This is because at the time
no one who went to the meetings where it was defined believed that
source quench was useful.
(4) The ISO IP has a small difference in the way that source routing is
implemented. The "destination address" field in the ISO IP always
contains the true final destination address, rather than the "next
hop" source routing address. This means that all of the gateways need
to implement source routing for it to work (rather than only those
gateways which are actually mentioned in the source route). Since
implementation of source routing is optional in the ISO IP, it is
unlikely that all gateway vendors will actually implement it.
(5) The ISO IP doesn't have an echo packet. The idea was that you could
get the same effect by source routing a packet to another gateway and
then back to yourself. Unfortunately, as mentioned in (4), this is not
likely to work since implementation of source routing is optional.
People in ANSI are aware of this problem and thus it is likely to be
fixed eventually (I hope).
(6) The encoding of many of the fields are different. For example, the
fields needed for reassembly (fragment offset, etc..) are only present
in the ISO IP if fragmentation is permitted. Similarly, the "security"
option had to take into account the fact that the ISO IP is standardized
for worldwide use, and therefore needs greater flexibility. Generally,
the ISO IP has opted for greater flexibility, and the cost of larger
packets and possibly greater cost in parsing the headers.
Ross
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: Tue, 8 Sep 87 17:16:40 EDT From: Ross Callon <rcallon@PARK-STREET.BBN.COM> To: murayama@CS.UCL.AC.UK Cc: iso@NRTC.NORTHROP.COM, tcp-ip@SRI-NIC.ARPA Subject: re: ISO8473 versus (DARPA) IP
Yuko;
I think we need more experience in actually using the ISO IP before we say
which differences are the most important, but here are a few that come to mind.
I hope this is a useful start.
If you are doing a study of the differences between the DARPA IP and the ISO
IP, or looking at implementation issues with the ISO IP, I would be very
interested in seeing any result which you may come up with.
(1) As Paul mentioned, the ISO uses variable length addresses up to
20 octets, while the DOD uses fixed length 4 octet addresses. The
ISO addresses are much more flexible. For example, they may be used
to explicitly encode something like an "autonomous system" number,
and/or the IEEE 802 link address.
I think that the difference in addresses make the ISO IP more appropriate
for worldwide use with potentially hundreds of thousands of networks, but
make it more costly to run (bigger headers and more processing).
(2) The IPs use different checksums. The ISO checksum is computationally
more costly, but has a higher probability of detecting errors in which
only a small number of bits are changed (i.e., random bit errors as
opposed to burst errors). In addition, the ISO checksum can be "turned
off" by using all zeroes in the checksum field.
(3) The ISO IP doesn't have a source quench. This is because at the time
no one who went to the meetings where it was defined believed that
source quench was useful.
(4) The ISO IP has a small difference in the way that source routing is
implemented. The "destination address" field in the ISO IP always
contains the true final destination address, rather than the "next
hop" source routing address. This means that all of the gateways need
to implement source routing for it to work (rather than only those
gateways which are actually mentioned in the source route). Since
implementation of source routing is optional in the ISO IP, it is
unlikely that all gateway vendors will actually implement it.
(5) The ISO IP doesn't have an echo packet. The idea was that you could
get the same effect by source routing a packet to another gateway and
then back to yourself. Unfortunately, as mentioned in (4), this is not
likely to work since implementation of source routing is optional.
People in ANSI are aware of this problem and thus it is likely to be
fixed eventually (I hope).
(6) The encoding of many of the fields are different. For example, the
fields needed for reassembly (fragment offset, etc..) are only present
in the ISO IP if fragmentation is permitted. Similarly, the "security"
option had to take into account the fact that the ISO IP is standardized
for worldwide use, and therefore needs greater flexibility. Generally,
the ISO IP has opted for greater flexibility, and the cost of larger
packets and possibly greater cost in parsing the headers.
Ross
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: Tue, 8-Sep-87 18:14:35 EDT From: carrs@TROUT.NOSC.MIL (Stephen M. Carr) To: comp.protocols.tcp-ip Subject: Re: ISO8473 vs. IP
-------
Ref: (a) National Research Council, "Transport Protocols for
Department of Defense Data Networks", RFC942, National
Academy Press, Washington, D.C., February 1985
Yuko,
1. Reference (a) document which Shiraz Bhanji referred to is
online at sri-nic.arpa. The path name is <RFC>RFC942.TXT. So if
you have FTP capability, you can download it. It is in excess of
217,000 bytes.
2. I am assuming that you don't have FTP capability from your
host into the ARPANET/MILNET. Therefore, if you would like, I or
one of your colleagues could try to forward it to you via SMTP.
3. Here is a list of other recent RFCs which might interest you
on related subjects. All of these documents are online in the
same directory.
RFC INDEX
(RFC1008)
Jun 87 (McCoy) Implementation Guide for the ISO
Transport Protocol
(RFC1007) Jun 87 (McCoy) Military Supplement to the ISO
Transport Protocol
(RFC1006)
May 87 (Rose) ISO Transport Services on top
of the TCP Version:3 (Obsoletes RFC 983)
(RFC995)
Jan 87 (ANSIx353.3) End System to Intermediate System
Routing Exchange Protocol for use in conjunction with ISO 8473
(RFC994)
Jan 87 (ANSIx353.3) Final Text of DIS 8473, Protocol
for Providing the Connectionless Mode Network Service (Obsoletes RFC 926)
(RFC962)
... Nov 85 (Padlipsky) TCP-4 Prime
(RFC945)
... Apr 85 (Postel) DOD Statement on NRC Report
(RFC942)
... Mar 85 (NRC) Transport Protocols for Department
of Defense Data Networks
(RFC939)
... Feb 85 (NRC) Executive Summary of the NRC Report
on Transport Protocols for Department of Defense Data Networks
(RFC905)
... Apr 84 (ISO) ISO Transport Protocol Specification
(ISO DP 8073) (Obsoletes RFC 892)
4. I hope this is of some help.
Steve Carr
LCDR, SC, USN
Navy Management Systems Support Office (Code 33C)
Naval Air Station
Norfolk, Virginia 23511-6694
DDN: carrs@trout.nosc.mil
DDN: navmasso30tc@nardacva.arpa
-------
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: Tue, 8-Sep-87 18:40:17 EDT From: cam@columbia-pdn (Chris Markle acc_gnsc) To: comp.protocols.tcp-ip Subject: Once More on FTP Password Expiration, Etc.
Folks, I thought I could lay this subject to rest after my last response but people still seem confused by what we're talking about here. The average security package for MVS implements facilities to age passwords and to not allow the user access to the system after his password has expired UNLESS a new password is also provided; note that the expired password must still be provided WITH a new password in order to login. These packages also allow the user to change his/her password for whatever reason. In addition, a user may exist in multiple "groups", each of which permits the user different access privileges. These features are part of the security package and are not a creation of ACC or ACCES/MVS (our software). Now, given this, all well-behaved IBM subsystems that gather a userid/password and validate that against the security system, provide a way for the user to specify an optional new password and group at signon. The new password can be specified to change your existing password at any time, or to change your password if the old one has expired. The group can be specified to select a group from the set of groups in which that user is a member. This list of well-behaved subsystems is large and includes CICS, IMS, TSO, and NCCF. In other words, the standard MVS environment supports the sort of thing we're talking about here; we at ACC are merely trying to integrate our product into that environment. Regarding the notion that ACC has proposed an "FTP protocol modification": 1) The current FTP specs suggest that the USER/PASS command arguments are "that which is required by the SERVER for access to its file system". The specs do not say that the USER or PASS arguments take any particular form. In fact, the USER argument is specified as a string of any of the 128 ASCII characters except CR and LF; ditto for the PASS argument. In my opinion, the argument "oldpass/newpass GROUP(xxx)" does not violate or modify the FTP spec. I am suggesting (strongly) that this is valid syntax for a PASS argument, per the spec; whether or not this fits your notion of what a userid or password "looks like" depends on whether you regularly work on an MVS system or not. Regarding the notion that we are creating a Server FTP that will not interoperate with other Client FTP implementations: 1) Assuming that you are the average user who is only in one group and whose password is not expired, all you will need to send our server is "USER chris" and "PASS chris-pswd", just as is done now. Even if you are in multiple groups, there is a default group associated with each user that will be in effect if no group is specified. I see no interoperability problem here. Regarding specification of new passwords and groups via the SITE command, I see two problems: 1) Not all FTP Client implementations provide a SITE command, which is understandable, but worse, not all those non-SITE providers provide a "quote" facility either. 2) The use of the SITE command to provide new password group information creates a second, unrelated place where this information must be specified; the logical, intuitive place is in the USER/PASS command text. Regarding the notion that people could access the MVS system via Telnet to change their password if it expired: 1) This doesn't address the need to optionally specify a group name together with a userid. 2) A site may allow a user to use the MVS system through FTP but not allow the user access to any subsystem (eg. TSO, CICS, IMS) which would allow him to change his password. Clearly this sort of user would have limited capabilites, but it is not hard to envision this sort of environment. Regarding ignoring the expired password condition and allowing the user to login anyway: 1) This would not be popular with MVS customers that want to mandate the use of aged passwords. MVS security auditors are not very keen on making exceptions for certain security situations. In conclusion, all ACC is trying to do is to integrate ACCES/MVS into the MVS environment as a well-behaved software product (from the MVS perspective). So long as we do this without violating the FTP spec (which I contend we haven't) and without affecting interoperability with other implementations (which I contend we don't) we should be free to make our product fit as nicely and logically into MVS as possible. Chris Markle - cam@acc-sb-unix.arpa - (301)290-8100
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: Tue, 8-Sep-87 18:43:00 EDT From: CDC-DDN@DDN3.ARPA To: comp.protocols.tcp-ip Subject: Sendmail message delays and timeout
We are having a problem using UNIX 4.3 sendmail. It will send messages to our CYBER quickly (1 sec) for a while, and then will gradually take longer and longer to send a message until finally it takes so long (7 minutes) to send the message that some UNIX timer kicks in and aborts the connection. When this happens, all subsequent messages time out in this manner, and we cannot send messages to the CYBER until we re-boot the VAX. We have looked at this with both an Ethernet analyzer and using the debug facility within sendmail. In the slow transactions, there is a delay of several minutes between the time that UNIX TCP receives the 354 reply to the DATA command, and the time that UNIX TCP sends the message text. The delay is always at this one point, and there is no other difference between slow and fast transactions. Even in sessions that time out, the sendmail debug output indicates that sendmail believes it has sent the message text, but it never appears on the Ethernet. There are no retransmission packets or ICMP messages to indicate some lower-level problem. Does anyone know what might be causing this problem? Any pointers will be appreciated. Mike Sanders CDC-DDN@DDN3
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: 8 Sep 87 18:43 EDT From: CDC-DDN @ DDN3.arpa To: tcp-ip @ sri-nic.arpa Cc: cdc-ddn @ ddn3 Subject: Sendmail message delays and timeout
We are having a problem using UNIX 4.3 sendmail. It will send messages to our CYBER quickly (1 sec) for a while, and then will gradually take longer and longer to send a message until finally it takes so long (7 minutes) to send the message that some UNIX timer kicks in and aborts the connection. When this happens, all subsequent messages time out in this manner, and we cannot send messages to the CYBER until we re-boot the VAX. We have looked at this with both an Ethernet analyzer and using the debug facility within sendmail. In the slow transactions, there is a delay of several minutes between the time that UNIX TCP receives the 354 reply to the DATA command, and the time that UNIX TCP sends the message text. The delay is always at this one point, and there is no other difference between slow and fast transactions. Even in sessions that time out, the sendmail debug output indicates that sendmail believes it has sent the message text, but it never appears on the Ethernet. There are no retransmission packets or ICMP messages to indicate some lower-level problem. Does anyone know what might be causing this problem? Any pointers will be appreciated. Mike Sanders CDC-DDN@DDN3
-----------[000069][next][prev][last][first]---------------------------------------------------- Date: Tue, 8-Sep-87 21:00:15 EDT From: mts@EMPTYS.CC.UMICH.EDU (Michael T. Stolarchuk) To: comp.protocols.tcp-ip Subject: Re: HELP: select() under sockets
Umm, I just looked into /usr/include/stdio.h on our apollo system:
Changelog entry:
10/01/82 jrw increased _NFILE from 20 to 128.....
So using NFILE is probably NOT the way to go, unless you declare
readfds, et al as arrays (this leads one to wonder, of course, why
the existing apollo software works at all -- since I know of no code
that actually uses arrays with select. Probably because no one actually
opens more than 32 file descriptors and only THEN creates a socket...).
How about 4.3? Where select is:
nfound = select(nfds, readfds, writefds, exceptfds, timeout)
int nfound, nfds;
fd_set *readfds, *writefds, *exceptfds;
struct timeval *timeout;
And you have:
FD_SET(fd, &fdset)
FD_CLR(fd, &fdset)
FD_ISSET(fd, &fdset)
FD_ZERO(&fdset)
And fd_set is:
typedef struct fd_set {
fd_mask fds_bits[howmany(FD_SETSIZE, NFDBITS)];
} fd_set;
And FD_SETSIZE is 256.
mts. the snail. imagine him at 100 mhp.
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: Tue, 8-Sep-87 21:59:00 EDT From: mogul@DECWRL.DEC.COM (Jeffrey Mogul) To: comp.protocols.tcp-ip Subject: More on RARP under 4.x BSD
> From: bbanerje@sjuvax.UUCP (B. Banerjee) ... > c. Rarp can be added to 4.3 BSD. ... > You can write a rarp daemon > with the aid of the 'enet' ethernet packet filter software that > was part of the ``user contributed software '' that came with 4.3 > BSD. Yes, probably. I doubt that the "enet" code distributed on the 4.3 tapes will actually work without modification (actually, the modification required is to the interface driver code for whatever interface you are using). As Greg Satz said in a recent message, you can probably get the working code from someone at Stanford ... but I don't know who (it is NOT either Greg or myself, so don't bother asking). People at Stanford (different people, probably) also have a "rarpd" that uses the packet filter. You could try to get that, although it really is a fairly simple program to write. > I personally believe that it makes the most sense to place the > rarp handling stuff along with the 'arp' handling stuff in the > kernel (netinet/if_ether.c). Unfortunately, this is infeasible in a large campus, since the ARP tables in the kernel are meant to be small and, when the overflow, it is normally safe to throw away old entries (they will be restored if they are used again). At a site like Stanford, where there may be hundreds or even thousands of diskless workstations eventually, the current kernel ARP table is clearly not going to work. RARP is not a performance-critical protocol; a user-mode server is the right way to go. It's sad that 4.xBSD has no mechanism to write such servers (i.e., no link-level access mechanism); that's what the packet filter or NIT is meant to provide. With such a mechanism, it's trivial to put the RARP server in the right place. Maybe 4.4BSD will do something about this. -Jeff Mogul (co-author of the packet filter code and of the RARP RFC)
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: Wed, 9-Sep-87 02:49:24 EDT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: ISO8473 vs. IP
Marty, The "congestion experienced" bit has to be a good idea, since it has been suggested repeatedly by Jack Haverty (name one) and several others at BBN for darn near ten years. So, let's do it. We need to swipe a bit from the IP header. Any suggestions on which one? That bit decided, give me ten seconds and the fuzzballs will concur in the madness... Dave
-----------[000072][next][prev][last][first]---------------------------------------------------- Date: Wed, 9-Sep-87 06:13:00 EDT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: ISO8473 vs. IP
RE: DEC Bit (Congestion Experienced) When I talked with Tony Lauck about this notion, the idea was that you could tell the receiving party "sooner" than the sending party about this congestion problem and that the receiving party might use the window mechanism to reduce the sender's ambition level until the congestion had died away. The sender probably needs to know about the congestion explicitly, too, if there is any option for re-routing the traffic from the origin via an alternate path which is less congested. It would be helpful to hear from Digital about their experiences with the dynamics of their DECNET with and without the use of this signal. Vint
-----------[000073][next][prev][last][first]---------------------------------------------------- Date: 9 Sep 1987 06:13-EDT From: CERF@A.ISI.EDU To: schoff@NIC.NYSER.NET Cc: hagens%janeb.spool.wisc.edu@GREMLIN.NRTC.NORTHROP.COM, iso@NRTC.NORTHROP.COM, murayama@CS.UCL.AC.UK tcp-ip@SRI-NIC.ARPA, tsuchiya@GATEWAY.MITRE.ORG Subject: Re: ISO8473 vs. IP
RE: DEC Bit (Congestion Experienced) When I talked with Tony Lauck about this notion, the idea was that you could tell the receiving party "sooner" than the sending party about this congestion problem and that the receiving party might use the window mechanism to reduce the sender's ambition level until the congestion had died away. The sender probably needs to know about the congestion explicitly, too, if there is any option for re-routing the traffic from the origin via an alternate path which is less congested. It would be helpful to hear from Digital about their experiences with the dynamics of their DECNET with and without the use of this signal. Vint
-----------[000074][next][prev][last][first]----------------------------------------------------
Date: Wed, 9-Sep-87 07:11:28 EDT
From: schoff@NIC.NYSER.NET ("Marty Schoffstall")
To: comp.protocols.tcp-ip
Subject: Re: ISO8473 vs. IP
The "congestion experienced" bit has to be a good idea, since it has been
suggested repeatedly by Jack Haverty (name one) and several others at BBN
for darn near ten years. So, let's do it. We need to swipe a bit from the
IP header. Any suggestions on which one? That bit decided, give me ten
seconds and the fuzzballs will concur in the madness...
Dave, I don't know how to take the above message. I don't believe I have
a fully-formed opinion on this due to the fact that I have
not seen the DEC "paper" however
I have some philosophical questions about this in the ISO stack:
Isn't this mechanism a bit indirect? Does anyone have some
thoughts about latency in a live ISO INTERNET?.
Your transmitter is hosing the net, Mr. Gateway
(whoops IS), 4 PDN's away determines there is
congestion toggles the bit and we arrive at
the receiver. The receiver then takes this
Layer3 information exports it to the Layer4
machine who does something bright with it
like communicating with the transmitter Layer4.
[ My recollection of this is that Layer4 had
to be TP4, ie this wasn't going to
be effectiv